Chromium Blog
News and developments from the open source browser project
Writing Extensions More Securely
pátek 22. července 2011
Extensions are powerful pieces of software in modern browsers, and as such, you should help ensure that your extensions are not susceptible to security exploits. If an attacker manages to exploit a vulnerability in an extension, it’s serious business because they may gain access to the same privileges that the extension has.
The Chrome extensions system has a number of
built-in protections
to make it more difficult to introduce exploitable code, but certain coding patterns can still open up the risk of exploits like a cross-site scripting (XSS) attack. Many of these mistakes are common to web programming in general, so it wouldn’t be a bad idea to check out one of the
many
good
articles
on the net about XSS bugs. Here are some of our recommendations for writing healthier extensions.
Minimize your permissions
The most important thing to consider is whether you’re declaring the minimal set of permissions that you need to function. That way, if you do have a security bug in your code, the amount of permissions you’re exposing to the attacker is minimal as well. Avoid requesting
(*/*) permissions for hosts if you only need to access a couple, and don’t copy and paste your manifest from example code blindly. Review your manifest to make sure you’re only declaring what you need. This applies to permissions like tabs, history, cookies, etc. in addition to host permissions. For example, if all you’re using is
chrome.tabs.create
, you don’t actually need the tabs permission.
Use content_security_policy in your manifest
Starting in Chrome 14, we will begin supporting
Content Security Policy
in extensions via the
content_security_policy
manifest field. This allows you to control where scripts can be executed, and it can be used to help reduce your exposure to cross-site scripting vulnerabilities. For example, to specify that your extension loads resources only from its own package, use the following policy:
"content_security_policy": "default-src 'self'"
If you need to include scripts from specific hosts, you can add those hosts to this property.
Don’t use <script src> with an HTTP URL
When you include javascript into your pages using an HTTP URL, you’re opening your extension up to man-in-the-middle (MITM) attacks. When you do so in a content script, you have a similar effect on the pages you’re injected into. An attacker on the same network as one of your users could replace the contents of the script with content that they control. If that happens, they could do anything that your page can do.
If you need to fetch a remote script, always use HTTPS from a trusted source.
Don’t use eval()
The eval() function is very powerful and you should refrain from using it unless absolutely necessary. Where did the code come from that you passed into eval()? If it came from an HTTP URL, you’re vulnerable to the same issue as the previously mentioned <script> tag. If any of the content that you passed into eval() is based on content from a random web page the user visits, you’re vulnerable to escaping bugs. For example, let’s say that you have some code that looks like this:
function displayAddress(address) { // address was detected and grabbed from the current page
eval("alert('" + address + "')");
}
If it turned out that you had a bug in your parsing code, the address might wind up looking something like this:
'); dosomethingevil();
There’s almost always a better alternative to using eval(). For example, you can use JSON.parse if you want to parse JSON (with the added benefit that it runs faster). It’s worth the extra effort to use alternatives like this.
Don’t use innerHTML or document.write()
It’s really tempting to use innerHTML because it’s much simpler to generate markup dynamically than to create DOM nodes one at a time. However, this again sets you up for bugs in escaping your content. For example:
function displayAddress(address) { // address was detected and grabbed from the current page
myDiv.innerHTML = "<b>" + address + "</b>");
}
This would allow an attacker to make an address like the following and once again run some script in your page:
<script>dosomethingevil();</script>
Instead of innerHTML, you can manually create DOM nodes and use innerText to insert dynamic content.
Beware external content
In general, if you’re generating dynamic content based on data from outside of your extension (such as something you fetched from the network, something you parsed from a page, or a message you received from another extension, etc.), you should be extremely careful about how you use it. If you use this data to generate content within your extension, you might be opening your users up to increased risk.
You can also read a
few more
examples of the issues discussed here in our extension docs. We hope these recommendations help you create better and safer extensions for everyone.
Posted by Erik Kay, Software Engineer
Chrome Extensions: Now with more powerful scripts and improved proxy management.
středa 13. července 2011
In Chrome 13, we added some new capabilities to content scripts and proxy management.
First, you can now make cross-origin XMLHttpRequest calls with the privileges of the extension directly from your content script. You will no longer need to relay these requests through a background page; this should simplify your code. In some cases, it may even eliminate your need to use a background page. Here’s a
sample extension
which demonstrates the old way a content script could make a cross domain request. As you can see, the extension required a
background page
to route the cross-origin calls through a
chrome.extension.onRequest
listener. Using the new content script cross-origin capabilities, we were able to successfully
rewrite the extension
to completely eliminate the background page requirement. This reduces the memory required to run the extension, and reduces code complexity as well. This also means that Greasemonkey scripts that use
GM_xmlhttpRequest
- such as the classic
Book Burro
- will now work in Chrome.
Second, we improved how
match patterns
work. Until this release you could specify a
matches
array for your content script - the URLs over which it should operate. In Chrome 13 you can now also specify an
exclude_matches
array, where you can indicate the pages in which your content scripts should not work. This should allow more precise targeting of your content script.
Finally, we added support for the
@run-at
command for imported Greasemonkey scripts, so you can control when your script is loaded in the same way you’ve been able to do for content scripts. Running scripts at different points in a page's lifecycle can enable additional functionality. For example, we've written
a script
which runs at "document-start" and lists all of the HTTP resources included in the current page.
In addition to these improvements to scripts, we’ve been working hard to allow extensions to manage Chrome’s proxy settings using different configuration options. With the
Proxy Extension API
, you can now configure proxy settings by choosing from several options including auto detection, the host OS’s system default, PAC scripts or fixed
ProxyRules
.
These new configuration options allow for more fine grained proxy controls, which we invite you to try out. There are already several 3rd party extensions available in the Chrome Web Store that showcase the API and its new capabilities, including
Proxy Anywhere
and
Proxy SwitchyPlus
.
Let us know what you think of these new features and what else you might like to see us do by joining the discussion at chromium-extensions@chromium.org.
Posted by Tessa MacDuff and Mihai Parparita, Software Engineers
Using Cross-domain images in WebGL and Chrome 13
středa 6. července 2011
A few weeks ago, we became aware of a
security issue
with WebGL:
shaders could be used
to indirectly deduce the contents of textures uploaded to the GPU. As a result, the WebGL specification was
updated
to be more restrictive when it comes to using cross-domain images and videos as WebGL textures.
As a result, Chrome 13 (and Firefox 5) will no longer allow cross-domain media as a WebGL texture. The default behavior will be a DOM_SECURITY_ERR. However, applications may still utilize images and videos from another domain with the cooperation of the server hosting the media, otherwise known as
CORS
.
CORS support
for MediaElements has also been fully implemented in WebKit by setting a new
.crossOrigin
attribute. This means that sophisticated applications that were using cross-origin textures before, can continue to do so, assuming the hosting image server grants the necessary cross-origin permission using CORS. If you want to enable CORS request on an image, all you have to do is add one line of code:
var img = document.createElement('img');
img.onload = function(e) { … };
img.crossOrigin = ''; // no credentials flag. Same as img.crossOrigin='anonymous'
img.src = 'http://other-domain.com/image.jpg';
Another nice property that we gain from this new setting is the ability to read cross-domain image data set on a 2D canvas. Normally, filling a canvas with a remote image (e.g.
ctx.drawImage()
) flips the
origin-clean flag
to false. Attempting to read back the pixels using
ctx.toDataURL()
or
ctx.getImageData()
throws a SECURITY_ERR. This is to prevent information leakage. However, when
.crossOrigin
is set (and the remote server supports CORS), the read is possible. For example:
var img = document.createElement('img');
img.onload = function(e) {
ctx.drawImage(img, 0, 0, canvas.width, canvas.height);
var url = canvas.toDataURL(); // Read succeeds, canvas won't be dirty.
};
img.crossOrigin = '';
img.src = 'http://other-domain.com/image.jpg';
Unfortunately, this new restriction in WebGL means that some existing content will break. We’ve already started working with external image and video hosting services like Flickr to evangelize the
use of CORS
on their images.
You can test this new behavior today using images from Picasa, which already sends a CORS header allowing cross-origin requests, and the
Chrome dev channel
.
Posted by Eric Bidelman, Developer Advocate
Štítky
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
csrf
1
css
1
cumulative layout shift
1
custom tabs
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2024
srp
čvn
kvě
dub
bře
úno
2023
lis
říj
zář
srp
čvn
kvě
dub
úno
2022
pro
zář
srp
čvn
kvě
dub
bře
úno
led
2021
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2020
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2019
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2018
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2017
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2016
pro
lis
říj
zář
srp
čvn
kvě
dub
bře
úno
led
2015
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2014
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2013
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2012
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2011
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2010
pro
lis
říj
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2009
pro
lis
zář
srp
čvc
čvn
kvě
dub
bře
úno
led
2008
pro
lis
říj
zář
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.