Simon Willison’s Weblog

Blogmarks tagged javascript, security in 2008

Filters: Type: blogmark × Year: 2008 × javascript × security ×


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