Simon Willison’s Weblog

Blogmarks tagged security, javascript

Filters: Type: blogmark × security × javascript ×


The code injected to steal passwords in Tunisia. Here’s the JavaScript that (presumably) the Tunisian government were injecting in to login pages that were served over HTTP. # 24th January 2011, 6:45 pm

Busting frame busting: a study of clickjacking vulnerabilities at popular sites (via) Fascinating and highly readable security paper from the Stanford Web Security Research group. Clickjacking can be mitigated using framebusting techniques, but it turns out that almost all of those techniques can be broken in various ways. Fun examples include double-nesting iframes so that the framebusting script overwrites the top-level frame rather than the whole window, and a devious attack against the IE and Chrome XSS filters which tricks them in to deleting the framebusting JavaScript by reflecting portions of it in the framed page’s URL. The authors suggest a new framebusting snippet that should be more effective, but sadly it relies on blanking out the whole page in CSS and making it visible again in JavaScript, making it inaccessible to browsers with JavaScript disabled. # 24th May 2010, 11:40 am

Twitter Don’t Click Exploit. Someone ran a successful ClickJacking exploit against Twitter users, using a transparent iframe holding the Twitter homepage with a status message fed in by a query string parameter. Thiss will definitely help raise awareness of ClickJacking! Twitter has now added framebusting JavaScript to prevent the exploit. # 12th February 2009, 7:56 pm

Ehy IE8, I Can Has Some Clickjacking Protection? (via) IE8 has built-in protection against clickjacking, but it’s opt-in (with a custom HTTP header) and IE only. It turns out the usual defence against clickjacking (using framebusting JavaScript) doesn’t work in IE as it can be worked around with a security=“restricted” attribute on an iframe. # 29th January 2009, 1:39 pm

Yahoo, Caja, OpenSocial. Yahoo!’s new application platform uses OpenSocial, and protects itself from malicious JavaScript using Google’s Caja secure JavaScript engine. I hadn’t realised that Caja was ready for production use—this is excellent news. # 30th October 2008, 5:14 pm

Dealing with UI redress vulnerabilities inherent to the current web (via) The best explanation of clickjacking I’ve seen yet, complete with discussion of a number of non-ideal potential solutions. It looks like frame busting JavaScript will defeat it, but only for users who have JavaScript enabled—which means that in this case extensions like NoScript actually make you less safe. UPDATE: NoScript is smarter than I thought; see the comments. # 7th October 2008, 9:59 am

Secure mashups with dojox.secure (via) dojox.secure is brilliant and terrifying at the same time. It provides a full featured API for running untrusted JavaScript in a sandbox, by parsing and validating that code against a variant of Douglas Crockford’s ADsafe JavaScript subset. It could be fantastically useful, but it’s difficult to judge how secure this approach really is. # 24th September 2008, 4:08 pm

When Ajax Attacks! Web application security fundamentals. Slides and notes from my talk on web application security at @media Ajax last Tuesday. # 20th September 2008, 4:16 pm

Frame-Busting Gadgets. I’ve always been slightly suspicious of the Google Gadgets / OpenSocial idea of sandboxing untrusted third party content in an iframe. Sure enough, it turns out iframe busting scripts work in Gadgets, meaning a seemingly harmless gadget could potentially launch a phishing attack. # 17th September 2008, 11:23 pm

When Ajax Attacks! Web application security fundamentals. Slides and (other people’s) notes from my presentation at @media Ajax on Tuesday. # 17th September 2008, 11:18 pm

Coding Horror: Protecting Your Cookies: HttpOnly. Jeff Atwood discovers the hard way that writing an HTML sanitizer is significantly harder than you would think. HttpOnly cookies aren’t the solution though: they’re potentially useful as part of a defense in depth strategy, but fundamentally if you have an XSS hole you’re going to get 0wned, HttpOnly cookies or not. Auto-escape everything on output and be extremely cautious with things like HTML sanitizers. # 29th August 2008, 2:01 am

quipt (via) Extremely clever idea: Cache JavaScript in window.name (which persists between page views and can hold several MB of data), but use document.referrer to check that an external domain hasn’t loaded the cache with malicious code for an XSS attack. UPDATE: Jesse Ruderman points out a fatal flaw in the comments. # 4th July 2008, 3:49 pm

eval() Kerfuffle. The ability to read supposedly private variables in Firefox using a second argument to eval() will be removed in Firefox 3.1. # 2nd July 2008, 9:24 pm

Javascript protocol fuzz results. If your HTML sanitizer uses blacklisting rather than whitelisting here are a few more weird ways of injecting javascript: in to a link that you need to worry about—but you should really switch to whitelisting http:// and https:// instead. # 30th June 2008, 3:57 pm

BUG: XSS Security flaw in BaseCamp Messages (via) BaseCamp lets users include HTML and JavaScript in messages, on the basis that anyone with a BaseCamp account is a trusted party. I’m not convinced: you could use this to circumvent BaseCamp’s access control stuff and read messages you’re not meant to. On the flip side, you could also use this to add brand new features to BaseCamp by using JavaScript in a message as a server-side equivalent to Greasemonkey. # 26th June 2008, 9:39 am

Crossdomain.xml Invites Cross-site Mayhem. A useful reminder that crossdomain.xml files should be treated with extreme caution. Allowing access from * makes it impossible to protect your site against CSRF attacks, and even allowing from a “circle of trust” of domains can be fatal if just one of those domains has an XSS hole. # 15th May 2008, 8:06 am

Session variables without cookies. Brilliant but terrifying hack—you can store up to 2 MB of data in window.name and it persists between multiple pages, even across domains. Doesn’t work with new tabs though, and storing JSON in it and eval()ing it is a bad idea—a malicious site could populate it before sending the user to you. # 13th May 2008, 9:59 pm

Dangers of remote Javascript. Perl.com got hit by a JavaScript porn redirect when the domain of one of their advertisers expired and was bought by a porn company. Nat Torkington suggests keeping track of the expiration dates on any third party domains that are serving JavaScript on your site. # 20th January 2008, 9:49 am

Site-specific browsers and GreaseKit. New site-specific browser tool which lets you include a bunch of Greasemonkey scripts. For me, the killer feature of site-specific browsers is still cookie isolation (to minimise the impact of XSS and CSRF holes) but none of the current batch of tools advertise this as a feature, and most seem to want to share the system-wide cookie jar. # 25th October 2007, 7:56 am

HTTPOnly cookie support in Firefox. Five years after the bug was filed, HTTPOnly cookie support has gone in to the Mozilla 1.8 branch. This is a defence in depth feature that has been in IE for years—it lets you set cookies that aren’t available to JavaScript, and hence can’t be hijacked in the event of an XSS flaw. # 6th September 2007, 6:27 am

Fortify JavaScript Hijacking FUD. Bob Ippolito points out the flaws in the recent widely disseminated JavaScript Hijacking paper. While the paper does miss some important details, it’s good that more people are now aware of the security implications involved in serving JSON up wrapped in an array. # 5th April 2007, 10:51 pm

MySpace: Too Much of a Good Thing? CSS customization really was just the result of forgetting to strip HTML. They “eventually” decided to filter out JavaScript(!) # 17th January 2007, 9:09 am

Silly JavaScript Security. “Sorry, you do not have permission to press this key,” # 5th December 2003, 10:42 pm