Friday, May 29th, 2009
Category: Security
Scott Schiller looks like he had some fun taking apart Analyzing Javascript Malware: Obfuscated Evil where he takes a peak into a gnarly JavaScript piece of malware that was just seen in the wild on Facebook:
Since Javascript must be downloaded to run on the client, its source is easily accessible. The code can be captured either during transport, from within the browser, or on disk from cache. For this and other reasons, Javascript malware writers - admittedly a special breed - must resort to all sorts of dirty tricks to hide their particularly-special brand of internet douchebaggery.
Obfuscation not only discourages casual reverse-engineering of the exploit used and its inner workings, it also makes it more difficult for internet security/virus-scanners to corrently identify and prevent the malware from running. If your code appears to be constructing a very large string with hex-encoded data (ie., attempting a buffer overflow condition with "shellcode" to execute arbitrary commands), then you're due to get flagged. If on the other hand you have some innocent-looking strings compressed or encrypted so as not to reveal their evil nature at first glance, your dirty work may in fact fly under the radar, undetected.
Scott takes apart the code that has a lot of source looking like:
JAVASCRIPT:
-
-
figoeei = (3., saltem)(('3' <= 8.3e1 ? solant + 'x': 384.), (funere, aequi) + (6661 <= movens ? .4138 : solant + 'u' + uisae + merui + inibis + solant) + (178., beroen + 'o' + 'ca' + 'n' + campo + gladie + 'x' + ')'));
-
After the analysis Scott says:
I suspect if this code did work, it would execute a JS payload or would dynamically fetch (via xmlHttpRequest), decode/decrypt and execute a payload. (A key/passphrase or decoding loop is suggested, given the output above.) On the other hand and in the words of comedian Dennis Miller, "'Course that's just my opinion, I could be wrong."
Want to give someone a bugger of an interview? Take some snippets and ask them to tell you what they do.
Monday, May 4th, 2009
Category: JavaScript, Security
One of the dirtiest secrets of the Internet is that it runs on ads for monetization. All of us who surf the web and use systems had lots and lots of free lunches because of advertisements being shown on web sites. The only difference to TV is that they are less obtrusive and you can choose to ignore or skip them (for now).
Self-righteous developers who do not quite grasp this dirty secret use all kind of tricks to remove adversiting from web sites they surf. This could be because of not wanting to support the corporate machine but also because of security reasons. Ad code on the internet is dire - it is built to support every possible imaginable environment and work around restrictions of setups - the ads need to show, no matter what.
Basically there are two extensions for Firefox that allow you to get rid of this potentially dangerous but definitely annoying code. Ad Block Plus specifically targets advertising and removes it and NoScript goes much further by blacklisting all scripts and asking you as a user to allow what you want to allow.
From a paranoid, security-aware point of view NoScript is a great idea - you cannot trust any JavaScript until we have sandboxed scripting environments.
However, as mentioned in a discussion on SlashDot and commented in detail by Scott Schiller there has been a - quite ironic - incident lately.
NoScript had ads on their homepage (which gets loaded in your browser every time it gets upgraded, which is quite often) and the problem was that AdBlock Plus would block these - after all this is what it was built for. What people found out is that a build of NoScript actually detected the presence of AdBlock Plus and added its own homepage to the whitelist of AdBlock Plus programatically (the code that did this was obfuscated).
This poses some interesting questions:
Is AdBlock Plus a useful tool, if it can be changed that easily? On the other hand, seeing that the community found out the change this fast is a good sign.
Are changes to other installed software OK if the software that does it is free and makes the web a safer place?
Are free extensions a safe and useful way to battle unsafe advertising or is this the job of browser vendors?
Is the time of ads on web sites injected with JavaScript over?
What do you do about malware and ads on web sites?
Friday, March 27th, 2009
Category: Security
Gareth Heyes has released XSS Rays, an open source library for detecting XSS holes via a bookmarklet:
The code works by creating connections to the target links/paths using iframes, each iframe is assign a name which is the url to return to on successful execution (the originating url). This allows cross domain links to be checked.
The vectors are stored in a simple object, each vector has the following properties:- input, name, browser, form, url, path (there’s a optional second input). Input is the XSS vector, the string “XSS” is used to replace with a logger or a poc url and is required by all vectors.
Name is just a meaningful name applied to the vector, browser supports ALL|FF|IE and helps to save time when testing specific browser vectors as XSS Rays will only target those versions for the vector.
Gareth also shows how he enables the onload event of a dynamic iframe in a way that works with IE:
JAVASCRIPT:
-
-
var ieLoader = "document.getElementById('"+'ray'+self.uniqueID+"').ieonload()";
-
if(self.isIE()) {
-
try {
-
var iframe = document.createElement('<iframe name="'+location + '#xss'+'" onload="'+ieLoader+'">');
-
} catch (e) {
-
var iframe = document.createElement('iframe');
-
}
-
} else {
-
var iframe = document.createElement('iframe');
-
}
-
Thursday, March 26th, 2009
Category: Security
Kent Brewster couldn't hold back anymore and posted on a vulnerability on the Amazon Wish List system that means that anyone can play with your wish lists. You can imagine people "having fun" and adding a huge number of porn elements to your setup.
Kent tells us:
Old friends may remember the How to Tell if a User is Signed In to Service X series, which ended last year around this time. As you can see from the comments in Patching Privacy Leaks, I advised users to sign out of Amazon.com on 17 October 2008, but did not say why.
Six months and multiple warnings later, nothing's been done.
If you are signed in to the United States version of Amazon.com and have a wish list, the button on this site should add an item. You'll see an alert with a success or failure message, and then this paragraph will change to tell you what happened and where to go to see it. If you're using Firefox or IE, we will be able to determine your Amazon login status, by watching onError. If all else fails, we will assume after a few seconds of inactivity that something went wrong.
Kent then shows us how it is simply done:
By examining the source of Amazon's Universal Wish List toolbar bookmarklet, we find something suspicious: an HTTP GET that seems to modify data on behalf of the signed-in Amazon user. This is trouble, since Amazon is depending only on browser cookies to verify user identity. Anyone can create an URL, like this:
http://www.amazon.com/gp/wishlist/add/ref=wl_bm-add
?submit=1&operation=add&mode=JS&priceInput=&id=
&imageUrl.0=http%3A%2F%2Fi2.ytimg.com%2Fvi%2FE62DXiL_8Vs%2Fdefault.jpg
&name.0=Raccoon%20Party
&itemComment.0=amazon%20wishlists%20are%20dreadfully%20insecure
&productUrl.0=http%3A%2F%2Fwww.youtube.com%2Fwatch%21v%3eDeQ1DN7n2Eg
... and fire it off on behalf of the signed-in user. Here I'm being polite and requiring the user to click a button, but it would be trivial to list it as the SRC attribute of a SCRIPT or IMG tag.
Adding a bunch of porn is bad, but what if we put"Pragmatic Ajax" in from Ajaxian? Or SEO sneakiness?
Wednesday, March 25th, 2009
Category: CSS, Security
Jesse Ruderman, security extraordinaire, has created many fuzzers in his time including a JavaScript one, and this time he has created a CSS gramar fuzzer:
I wrote a CSS grammar fuzzer to test Gecko's CSS parser. This fuzzer's tricks:
Declarative context-free grammar. This makes it easy to add new CSS features to the fuzzer, or even use it to test grammars other than CSS. Each symbol can be a star, concatenation, or list of alternatives. Unlike a parser, a fuzzer has to make decisions about what to create, so alternatives can be given weights and stars have a suggested number of repetitions. This alone was enough to find at least one bug in Gecko.
Breaking rules. Like any good fuzzer, it doesn't always follow the given context-free grammar. Sometimes it does weird stuff, such as inserting a random symbol, to throw the parser off. I was surprised that this only found one additional bug in Gecko. Perhaps this reflects the comprehensive error handling requirements of the CSS specifications and the corresponding test suites.
Grammatical recursion. When the fuzzer notices that a symbol is the same as an ancestor, it can repeat the parts of the final string between the two symbols. This is effective at finding bugs where large input can cause a recursive algorithm to run out of stack space and crash. This found four grammar-recursion crashes in Gecko.
CSS serialization. The fuzzer makes sure that any text that comes out of the browser's stylesheet serializer survives another trip through the parser and serializer. This is the same trick jsfunfuzz uses to test the JavaScript engine decompiler. This helped fine four incorrect-serialization bugs in Gecko.
None of these Gecko bugs seem to be security holes. I shared the fuzzer with other browser vendors privately for over a month, and nobody asked me to delay the release, so I believe it didn't find security holes in other browsers either. But I think this has more to do with CSS parsing being fairly simple and self-contained than any weakness in the fuzzer.
Thursday, February 12th, 2009
Category: Security
Twitter is currently running hot with tweets that announce that you shouldn't click followed by a tinyurl. The page behind the tinyurl has a button that tells people not to click it - which of course they do. When they click the button they send the tweet telling other gullible people not to click the button - which of course those people do.
The whole thing is a wonderful example of clickjacking. The page is constructed to have a button that does exactly nothing. The button however is covered by an IFRAME pointing to your twitter homepage with a prefilled form with the tweet to invite others to be a rebel and click the button that shouldn't be clicked. The IFRAME has an opacity of 0 and is so positioned that the real button you click on is the update button.
CSS:
-
iframe { position:absolute;width:550px;height:228px;top:-170px;left:-400px;z-index: 2;opacity: 0;filter: alpha(opacity=0); }
-
button { position:absolute;top:10px;left:10px;z-index:1;width: 120px; }
Scott Schiller explains with a screenshot how the trick works:
It is going to be interesting if Twitter will stay up or how this can be stopped. I guess asking tinyurl to cut the lifeline of the two URL used will do it - but there are others already out there - in French and German. *Update:* TinyUrl did suspend the urls now. However, there will be a lot of copycats.
In any case this shows several things:
- Don't trust any button
- Reverse psychology always works (do not send me money on paypal, please!)
- Staying authenticated in browsers is a bad thing
- Maybe an Air client is a better solution for using Twitter.
Thursday, January 29th, 2009
Category: Security
This morning I had a fun email (in 60 pixel letters) concerning TweetEffect - a Twitter analysis tool I've written (details on my blog). In essence I was being accused of making protected updates of the Twitter user available to the world.
I tried it out and couldn't reach their updates. I then started wondering what on earth would have given that person the idea that a tool that needs no authentication and uses the API output of the user timeline could breach the security of their protected updates. If I tried to access the timeline of a protected user, the API rightfully asks me to authenticate.
However it then dawned on me: the complaining user was logged into Twitter and thus could see the data without being asked to authenticate. So I was about to dismiss the problem and explained that this is not much more of a security breach as the old trick of showing someone a web page with an iframe pointing to their harddrive content via file://.
However, things are not as easy - as followers of this person that are allowed to see the updates - friends so to say - can also get to this data via the API. So in order to get to someone's protected updates I could do the following:
- Sign into Twitter
- Click the followers link of the user and find a trusting person
- Send this person a "look at the cute kitten" link that contains some clever code
All this clever code would need to do is to call the user_timeline in JavaScript, populate a hidden field or DOM element, read out its value and post it somewhere else (either via Ajax or an image or whatever else).
This is a problem, especially as disallowing that would break most Twitter clients. I can think of a few solutions: disallow the listing of followers of users with protected updates for non-followers or instead of doing a "protected updates" replace this feature with "trusted friends" groups and an own API.
In any case, it shows again that staying logged in and trying to protect information from going out when using a browser environment is simply not a clever idea.
Saturday, January 24th, 2009
Category: Canvas, Security
Everybody's favourite glass shield to protect web apps are CAPTCHAS. These are the distorted characters displayed on a page that a user has to enter before gaining access or sending off a form. They annoy normal users, are largely inaccessible to blind users or dyslexic people and are not that safe as we think they are. PWNtcha continually reports successful cracks of various captchas on the web using OCR algos and backend systems.
What is pretty amazing though is that now you can even crack the images using JavaScript and Canvas. ShaunF wrote a GreaseMonkey script that automatically solves captchas of the file hosting site Megaupload. There's a demo of it available.
As John Resig explains in his analysis of the script there's some pretty nifty work going on:
- The HTML 5 Canvas getImageData API is used to get at the pixel data from the Captcha image. Canvas gives you the ability to embed an image into a canvas (from which you can later extract the pixel data back out again).
-
The script includes an implementation of a neural network, written in pure JavaScript.
-
The pixel data, extracted from the image using Canvas, is fed into the neural network in an attempt to divine the exact characters being used - in a sort of crude form of Optical Character Recognition (OCR).
True, Megaupload's CAPTCHA is pretty basic, but it is still very impressive that you can use JavaScript to crack it. Seems like the getImageData API is something to have a closer look at.
Thursday, January 15th, 2009
Category: Flash, Library, Security
Following the bombshell of Adobe announcing that Flash 10 will not support unsolicited clipboard access from Flash and JavaScript as malicious flash ads flooded clipboards a lot of developers were wondering how to make the "copy to clipboard" still work without having to do it in Flash itself.
An interesting and also slightly creepy approach to the problem is the JavaScript library Zero Clipboard:
The Zero Clipboard library provides an easy way to copy text to the clipboard using an invisible Adobe Flash movie, and a JavaScript interface. The "Zero" signifies that the library is invisible and the user interface is left entirely up to you.
This library is fully compatible with Flash Player 10, which requires that the clipboard copy operation be initiated by a user click event inside the Flash movie. This is achieved by automatically floating the invisible movie on top of a DOM element of your choice. Standard mouse events are even propagated out to your DOM element, so you can still have rollover and mouse down effects.
So in other words, zero clipboard is a legitimate use of the clickjacking trick to cover an element with a transparent element that provides another functionality.
There are detailed instructions how to use the library on the homepage.
I don't know about you, but somehow "copy to clipboard" buttons seem a bit redundant to me and by keeping this functionality working cause more security holes than usability benefits.
Wednesday, January 7th, 2009
Category: Examples, Security
Earlier this week I blogged about a proof of concept that you can detect if a user is logged in to twitter and display their data with a few lines of JavaScript. This could be used to show for example "tweet this" buttons in a blog application.
The trick is easy: use the user_timeline to get the correct data back and provide it with a callback:
JAVASCRIPT:
-
function hasTwitter(data){
-
// gets the user's real name
-
alert(data[0].user.name);
-
// other data is .screen_name, .location and
-
// data[0].text is the latest update
-
}
HTML:
-
-
src="'http://twitter.com/statuses/user_timeline.json&count=1&callback=hasTwitter">
-
</script>
You can see the proof of concept here. The only problem with the code above is that if the user is not authenticated, Twitter's API will prompt an authentication dialog. You can work around this one by providing an extra parameter called "suppress_response_codes" which is meant to be used with apps that can only handle 200 response codes and don't allow for authentication (Flash apps for example):
HTML:
-
-
src="'http://twitter.com/statuses/user_timeline.json&count=1&hasTwitter&suppress_response_codes">
-
</script>
This also means that you need to do your own error handling for cases where the user is not authenticated:
JAVASCRIPT:
-
function hasTwitter(data){
-
if(data.error){
-
alert('No authenticated user');
-
} else {
-
// gets the user's real name
-
alert(data[0].user.name);
-
// other data is .screen_name, .location and
-
// data[0].text is the latest update
-
}
-
}
HTML:
-
-
src="'http://twitter.com/statuses/user_timeline.json&count=1&hasTwitter&suppress_response_codes">
-
</script>
Now, this is pretty cool, but it also caused quite a stir on the twitter developer mailing list as it is a privacy concern. Using this technique I could simulate a user's homepage, fake an error, ask for re-authentication and phish their login data.
Whilst this is a problem, it is not really Twitter's fault - if anything then browsers and the lack of secure sandboxes are to blame. Some questions a proof of concept like this throws up are:
- Do we need something like "tweet this" buttons (as a call to action they can be very effective)?
- If we do, isn't it better to only show them when the user is a twitter user instead of cluttering the interface with all kind of buttons?
- Is a provider-unknown secret like Yahoo's sign in seal a step in the right direction (educating users instead of patching technology)?
- Is oAuth the answer?
Wednesday, December 31st, 2008
Category: Security
The paper on MD5 considered harmful today delivered at the 25th Annual Chaos Communication Congress in Berlin has got people scared again.
The team showed an MD5 collision which is well explained by Simon Willison (he is so good at getting to the meat, a tough skill indeed):
Use an MD5 collision to create two certificates with the same hash, one for a domain you own and another for amazon.com. Get Equifax CA to sign your domain’s certificate using the outdated “MD5 with RSA” signing method. Copy that signature on to your home-made amazon.com certificate to create a fake certificate for Amazon that will be accepted by any browser.
Mozilla Security folks issued an advisory which included the impact to users:
If a user visits an SSL site presenting a fraudulent certificate, there will be no obvious sign of a problem and the connection will appear to be secure. This could result in the user disclosing personal information to the site, believing it to be legitimate. We advise users to exercise caution when interacting with sites that require sensitive information, particularly when using public internet connections.
Status
This is not an attack on a Mozilla product, but we are nevertheless working with affected certificate authorities to ensure that their issuing processes are updated to prevent this threat. Mozilla is not aware of any instances of this attack occurring in the wild.
Microsoft also advised.
Then we get SSL in perspectives which talks us through 2008:
- Dan Kaminski shook world’s faith in DNS. BTW, you already checked your DNS hardness or switched to OpenDNS, didn’t you? Anyway, DNS security or not, you cannot trust non-SSL traffic when you’re traveling, or you’re behind a proxy you can’t control (TOR, for instance), or otherwise not using a trusted ISP… wait, do you really trust your ISP? OK, you should not trust non-SSL traffic, period.
- But then, Mike Perry demonstrated how cookies can be stolen from SSL-secured sites (and NoScript deployed some countermeasures).
- Unfortunately, a shameful incident revealed that you can easily buy a valid SSL certificate for a web site you’re not related with, if you find an unscrupulous enough vendor: in this case, a mozilla.com certificate has been obtained by Eddy Nigg of StartCom Ltd. from the Certstar Comodo reseller, no question asked. Of course, as a work-around, you could remove the offending CA root, but you must expect side effects (I discovered this breaks cleverbridge e-commerce back-ends, for instance). And, most important, are you sure this is the only sloppy CA out there?
- As if this didn’t suck enough, a speech has been given today at 253c by Alex Sotirov, Arjen Lenstra and other high-profile researchers, who managed to leverage known MD5 weaknesses and not-safe-enough practices of some certificate issuers to build their own rogue CA.
It then talks about Perspectives the Firefox plug-in that compares cert hashes with a database of known fingerprints to detect false certs.
Phew. Two Web security pieces almost in a row :/
Tuesday, December 30th, 2008
Category: Security
Jeremiah Grossman, our number one Web security chap, has some interesting words as we jump into 2009:
It’s unanimous. Web application security is the #1 avenue of attack according to basically every industry data security report available (IBM, Websense, Sophos, MessageLabs, Cisco, APWG, MITRE, Symantec, Trend Micro, SecureWorks, ScanSafe, IC3). This is in addition to reports specifically focusing on custom Web application vulnerabilities (WhiteHat Security, WASC, Accunetix). SQL Injection and Cross-Site Scripting are routinely cited as the biggest issues, the ones we can’t apply patches to defend against. Perhaps what we’ve learned in 2008, as pointed out by Gunnar Peterson and Gary McGraw, is we’re spending on the wrong problem. Roughly $150MM in software security products & services versus the lopsided billions annually on network security. 2009 will give us another opportunity to make a difference.
From the mountain of statistics available I've saved several interesting quotes to reference in 2009.
He goes on to use quotes from various sources to tell the tale. It appears that most of the attacks are there to put something on your machine. With business models where the malware doesn't need to popup and try to sell you something, but rather just use you CPU as part of a botnet. The fight will continue in 2009!
Monday, November 3rd, 2008
Category: Security
Jeremiah Grossman, our go to guy for Web security issues, recently write an interesting piece about how security gets bolted on, and slowly subsumed into the platform:
Whether improving ease-of-use, adding new developer APIs, or enhancing security – Web browser features are driven by market share. That’s all there is to it. Product managers perform a delicate balancing act of attracting new users while trying not to “break the Web” or negatively impact their experience. Some vendors attempt an über secure design - Opus Palladianum as an example, but few use it. Others opt for usability over security, such as Internet Explorer 6, which almost everyone used and was exploited as a result. Then, somewhere in the middle, is fan-favorite Firefox. The bottom line is that any highly necessary and desirable security feature that inhibits market adoption likely won’t go into a release candidate of a major vendor. Better to be insecure and adopted instead of secure and obscure.
Fortunately, the major browser vendors have had security on the brain lately, which is a welcome change. Their new attitude might reflect the realization that a more secure product could in fact increase market share. The online environment is clearly more hostile than ever, as attackers mercilessly target browsers with exploits requiring no user intervention. One need only to look at this year’s massive SQL Injection attacks that infected more than one million Web pages, including those belonging to DHS, U.N., Sony, and others. The drive-by-download malware had just one goal - compromise the browser - with no interest in looting the potentially valuable data on the sites. Of course, we still have the garden-variety phishing sites out there. This leads to questions regarding the benefits of end-user education. Users are fed up. So let’s analyze what the Mozilla and Microsoft camps have done in response.
Buffer overflows and other memory corruption issues in the most recent browsers are declining, plus the disclosure-to-patch timeline is trending properly. Firefox 3 and Internet Explorer 7 now offer URL blacklists that block phishing sites and other pages known to be delivering malware. These features are reportedly a little shaky, but it’s clearly better considering there was nothing in place before. Firefox 3 provides additional visibility into the owners of SSL certificates and make it more challenging to blindly accept those that are invalid or self-signed. IE 7 offers a nice red/green anti-phishing toolbar that works with EV-SSL to help users steer clear of dangerous websites. Overall, excellent progress has been made from where we were just a couple years ago, but before the vendors start patting themselves on the back, there’s also some bad news.
If you ask the average Web security expert if they think the typical user is able to protect themselves online and avoid getting hacked, the answer will be an unqualified “no”. While browser vendors are addressing a small slice of a long-standing problem, most people are not aware of the remaining risks of a default install of the latest version of Firefox or Internet Explorer. When visiting any Web page, the site owner is easily able to ascertain what websites you’ve visited (CSS color hacks) or places you’re logged-in (JavaScript errors / IMG loading behavior). They can also automatically exploit your online bank, social network, and webmail accounts (XSS). Additionally, the browser could be instructed to hack devices on the intranet, including DSL routers and printers. And, if that’s not enough, they could turn you into a felon by forcing requests to illegal content or hack other sites (CSRF). The list goes on, but DNS-rebinding attacks get a little scary even for me, and it’s not like we haven’t known of these issues for years.
Thursday, October 23rd, 2008
Category: Security
The Microsoft Live Labs team has announced a new project: Web Sandbox. The team is lead by Scott Isaacs, someone who we owe thanks to, since he played a large part in the birth of dhtml (and thus, Ajax).
The sandbox takes HTML, CSS, and JavaScript, and puts it in an isolated box. The goal is a little like Caja, AdSafe, FBJS, and other solutions that try to make JavaScript execution more secure in some way.
Take a look at an example, such as the script error sample, which shows how errors are handled and don't blow up the entire page.
The sandbox converts code like this:
HTML:
-
-
-
-
-
-
.sampleTitle
-
{
-
font-family: Segoe UI, Tahoma;
-
font-size: 11pt;
-
font-weight: bold;
-
color: #07519A;
-
}
-
.scriptErrorSample
-
{
-
height: 130px;
-
border: solid 1px lightgrey;
-
background: white;
-
background-repeat: repeat-x;
-
background-position: left top;
-
padding: 10px;
-
overflow-y: auto;
-
}
-
</style>
-
</head>
-
-
<div id="sample" class="scriptErrorSample">
-
-
window.clockelement = "currentTime";
-
function onClick() {
-
// Try to access an inexistent element
-
window.clockelement = "currentTime2";
-
}
-
</script>
-
-
<p>Clicking the button will cause a scripting error. When running outside the sandbox this error effectively crashes the application stopping the clock. Within the Sandbox, the error stops only that instance.
</p>
-
<p>After the error is generated, you can reload this gadget by clicking the [reload] button in the Gadget toolbar.
<input type="button" onclick="onClick()" value="Generate Error!"/></p>
-
<div id="currentTime" style="font-size: 8pt; font-weight: normal; color: Gray">
-
</div>
-
-
-
window.setInterval(function() {
-
document.getElementById(window.clockelement).innerText = new Date();
-
}, 999)
-
</script>
-
</div>
-
</body>
-
</html>
-
and converts it (via server side, or client side with Silverlight-only):
HTML:
-
-
var settings = { css : { ".sampleTitle":{"font-family":"Segoe UI, Tahoma","font-size":"11pt","font-weight":"bold","color":"#07519A"},
-
".scriptErrorSample":{"border-left-width":"1px","border-right-width":"1px","border-top-width":"1px","border-bottom-width":"1px","border-left-style":"solid","border-right-style":"solid","border-top-style":"solid","border-bottom-style":"solid","padding-left":"10px","padding-right":"10px","padding-top":"10px","padding-bottom":"10px","height":"130px","background":"white","background-repeat":"repeat-x","background-position":"left top","overflow-y":"auto"} } };
-
-
var headerJavaScript =
-
function(a)
-
{
-
var b = a.gw(this),
-
c = a.g,
-
d = a.i,
-
e = a.f,
-
f = c(b,"document");
-
d(f,"initializeHTML",[[{"body":{"c":[" ",{"div":{"a":{"id":"sample","class":"scriptErrorSample"},"c":[" ",{"script":"code1"}," ",{"p":{"c":["Clicking the button will cause a scripting error. When running outside the sandbox this error effectively crashes the application stopping the clock. Within the Sandbox, the error stops only that instance."]}}," ",{"p":{"c":["After the error is generated, you can reload this gadget by clicking the [reload] button in the Gadget toolbar. ",{"input":{"a":{"type":"button","onclick":e(function()
-
{
-
d(b,"onClick")
-
}),"value":"Generate Error!"}}}]}}," ",{"div":{"a":{"id":"currentTime","style":{"font-size":"8pt","font-weight":"normal","color":"Gray"}},"c":[" "]}}," ",{"script":"code2"}," "]}}," "]}}]])
-
};
-
-
var metadata = {"author":"","description":"","imagepath":"","title":"Script Error Sample","preferredheight":0,"preferredwidth":0,"location":"","base":{"href":"","target":""},"scripts" : {"code1" :
-
function(a)
-
{
-
var b = a.gw(this),
-
c = a.g,
-
d = a.s,
-
e = a.f,
-
f = a.v;
-
f.onClick = e(function()
-
{
-
d(b,"clockelement","currentTime2")
-
});
-
d(b,"clockelement","currentTime")
-
},"code2" :
-
function(a)
-
{
-
var b = a.gw(this),
-
c = a.g,
-
d = a.s,
-
e = a.i,
-
f = a.n,
-
g = a.f,
-
h = c(b,"document");
-
e(b,"setInterval",[g(function()
-
{
-
d(e(h,"getElementById",[c(b,"clockelement")]),"innerText",f(c(b,"Date"),[]))
-
}),999])
-
}}};
-
-
$Sandbox.registerCode(headerJavaScript, "0", settings, metadata);
-
-
var SandboxInstance = new $Sandbox(document.getElementById('g_0_0_inst'), $Policy.Gadget, "0");
-
-
SandboxInstance.initialize();
-
You may want to note a few things, such as how you can use CSS such as "body { color: red; }" and it only effects that one area, and how you can access the DOM and the same isolation happens.
Although the project talks a lot about security and gadgets/mashups, there are other interesting side benefits.
For example, the team has implemented functionality such as the W3C event model, which means that addEventListener say, works in IE (via this process). If people start to use this, maybe the labs team can get the IE team to implement their work natively!
Finally, Scott kindly gave us a few words on the project:
We focused on going beyond security by exploring a more holistic solution for site extensibility. We are also providing cross-browser support built around existing web standards. The default (and extensible) Gadget policy is modeled after standard HTML pages and the IFrame model. Together, this allows developers to leverage their existing skills, knowledge, and tools.
A robust virtualized environment for Web 2.0 applications is more than just about security. It is important to also protect the site’s integrity by providing QoS monitoring and controls over code execution (the ability freeze and unfreeze code to better manage browser performance and user experience). For host sites, it is necessary to have easy integration and multi-instancing support.
We know performance is a concern. We are still early in the project and have not yet finished optimizing the code and we are still expanding the DOM API support. However, our initial work is showing promise. As one benchmark, consider Google Caja. Not only are we focusing on a complete solution with broad support for DOM APIs, HTML, and CSS, we are also showing better performance at this early stage. Attached a simple script that focuses on measuring the overhead introduced by the sandbox (you can also find it at the bottom). This script is executable in both our Sandbox and the Caja test environment.
Tuesday, September 30th, 2008
Category: Security
Bill Zeller and Ed Felten have published a report on Cross-Site Request Forgery attacks on popular Web sites:
We found four major vulnerabilities on four different sites. These vulnerabilities include what we believe is the first CSRF vulnerability that allows the transfer of funds from a financial institution. We contacted all the sites involved and gave them ample time to correct these issues. Three of these sites have fixed the vulnerabilities listed below, one has not.
CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.
The chaps share deatils on the following attacks:
1. ING Direct (ingdirect.com)
Status: Fixed
We found a vulnerability on ING's website that allowed additional accounts to be created on behalf of an arbitrary user. We were also able to transfer funds out of users' bank accounts. We believe this is the first CSRF vulnerability to allow the transfer of funds from a financial institution. Specific details are described in our paper.
2. YouTube (youtube.com)
Status: Fixed
We discovered CSRF vulnerabilities in nearly every action a user could perform on YouTube. An attacker could have added videos to a user's "Favorites," added himself to a user's "Friend" or "Family" list, sent arbitrary messages on the user's behalf, flagged videos as inappropriate, automatically shared a video with a user's contacts, subscribed a user to a "channel" (a set of videos published by one person or group) and added videos to a user's "QuickList" (a list of videos a user intends to watch at a later point). Specific details are described in our paper.
3. MetaFilter (metafilter.com)
Status: Fixed
A vulnerability existed on Metafilter that allowed an attacker to take control of a user's account. A forged request could be used to set a user's email address to the attacker's address. A second forged request could then be used to activate the "Forgot Password" action, which would send the user's password to the attacker's email address. Specific details are described in our paper.
(MetaFilter fixed this vulnerability in less than two days. We appreciate the fact that MetaFilter contacted us to let us know the problem had been fixed.)
4. The New York Times (nytimes.com)
Status: Not Fixed. We contacted the New York Times in September, 2007. As of September 24, 2008, this vulnerability still exists.
A vulnerability in the New York Time's website allows an attacker to find out the email address of an arbitrary user. This takes advantage of the NYTimes's "Email This" feature, which allows a user to send an email about a story to an arbitrary user. This emails contains the logged-in user's email address. An attacker can forge a request to active the "Email This" feature while setting his email address as the recipient. When a user visit's the attacker's page, an email will be sent to the attacker's email address containing the user's email address. This attack can be used for identification (e.g., finding the email addresses of all users who visit an attacker's site) or for spam. This attack is particularly dangerous because of the large number of users who have NYTimes' accounts and because the NYTimes keeps users logged in for over a year.
Also, TimesPeople, a social networking site launched by the New York Times on September 23, 2008, is also vulnerable to CSRF attacks. We hope the New York Times will decide to fix these vulnerabilities now that they have been made public.
And, what about mitigation?
Our paper provides recommendations for preventing these attacks. We provide a server-side plugin for the PHP MVC framework Code Igniter that can completely prevent CSRF. We also provide a client-side Firefox extension that can protect users from certain types of CSRF attacks (non-GET request attacks).
Saturday, September 27th, 2008
Category: Accessibility, Adobe, Flash, Security
Right now you can use Flash to work around a lot of JavaScript limitations and many products use an invisible Flash movie to for example batch upload files (Flickr, Wordpress), play movies in a screenreader accessible manner (with DHTML controls outside the main movie - Yahoo Video, for example) or automatically add content to the browser clipboard (snipurl.com).
All of these will cease to work without user interaction in flash as reported on the adobe devnet. There are very good reasons for it as explained by Lee Brimelow but it is a real problem that will cease to make Flash a useful tool to patch inaccessible solutions.
As long as you cannot access a Flash movie in non-Internet Explorer browsers via keyboard, there will be no such thing as an accessible flash page. Research findings presented at Scripting Enabled last week showed that for example many screen reader users skip Flash as soon as they hear that there is a movie on the page, regardless of how much effort you put in to make the movie itself keyboard enabled. DHTML controls worked around that issue - a button that cannot be accessed is very secure, but also pointless.
There must be some middle ground there somewhere...
Next Page »
