Simon Willison’s Weblog

I stumbled across a nasty XSS hole involving DNS A records. Found out today that an old subdomain that I had assigned an IP address to via a DNS A record was serving unexpected content—turned out I’d shut down the associated VPS and the IP had been recycled to someone else, so their content was now appearing under my domain. It strikes me that if you got really unlucky this could turn into an XSS hole—and that new server could even use Let’s Encrypt to obtain an HTTPS certificate for your subdomain.

I’ve added “audit your A records” to my personal security checklist. # 22nd August 2021, 5:27 am

Reflected cross-site scripting issue in Datasette (via) Here’s the GitHub security advisory I published for the XSS hole in Datasette. The fix is available in versions 0.57 and 0.56.1, both released today. # 5th June 2021, 11:14 pm

What is a Self-XSS scam? Facebook link to this page from a console.log message that they display the browser devtools console, specifically warning that “If someone told you to copy-paste something here to enable a Facebook feature or hack someone’s account, it is a scam and will give them access to your Facebook account.” # 8th April 2019, 6:01 pm

From Markdown to RCE in Atom (via) Lukas Reschke found a remote code execution vulnerability in the Atom editor by taking advantage of a combination of Markdown’s ability to embed HTML, Atom’s Content-Security-Policy allowing JavaScript from the local filesystem to be executed, and a test suite HTML file hidden away in the Atom application package that executes code passed to it via query string. # 23rd November 2017, 4:13 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

apache.org incident report for 04/09/2010. An issue was posted to the Apache JIRA containing an XSS attack (disguised using TinyURL), which stole the user’s session cookie. Several admin users clicked the link, so JIRA admin credentials were compromised. The attackers then changed the JIRA attachment upload path setting to point to an executable directory, and uploaded JSPs that gave them backdoor access to the file system. They modified JIRA to collect entered passwords, then sent password reset e-mails to team members and captured the new passwords that they set through the online form. One of those passwords happened to be the same as the user’s shell account with sudo access, leading to a full root compromise of the machine. # 14th April 2010, 9:08 am

Major IE8 flaw makes ’safe’ sites unsafe. IE8 has an XSS protection feature which rewrites potentially harmful code in HTML pages—I think it looks for suspicious input in query strings which appears to have been output directly on the page. Unfortunately it turns out there’s a flaw in the feature that can allow attackers to rewrite safe pages to introduce XSS flaws. Google are serving all of their pages with the X-XSS-Protection: 0 header. Until the fix is released, that’s probably a good idea. # 22nd November 2009, 3:34 pm

XSS Protection by Default in Rails 3.0. Fantastic news—congratulations, Rails core team. # 8th October 2009, 4:35 pm

Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems (via) The Google Online Security Blog reminds us that simply HTML-escaping everything isn’t enough—the type of escaping needed depends on the current markup context, for example variables inside JavaScript blocks should be escaped differently. Google’s open source Ctemplate library uses an HTML parser to keep track of the current context and apply the correct escaping function automatically. # 14th April 2009, 9:26 am

17-year-old claims responsibility for Twitter worm. It was a text book XSS attack—the URL on the user profile wasn’t properly escaped, allowing an attacker to insert a script element linking out to externally hosted JavaScript which then used Ajax to steal any logged-in user’s anti-CSRF token and use it to self-replicate in to their profile. # 12th April 2009, 7:22 pm

OWASP: XSS Prevention Cheat Sheet. Comprehensive set of rules for avoiding XSS—there’s a bit more to it than just escaping all output variables, since you have to take markup context in to account. # 24th January 2009, 11:58 pm

Web Security Horror Stories: The Director’s Cut. Slides from the talk on web application security I gave this morning at <head>, the worldwide online conference. I just about managed to resist the temptation to present in my boxers. Topics include XSS, CSRF, Login CSRF and Clickjacking. # 26th October 2008, 12:15 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

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

ratproxy. “A semi-automated, largely passive web application security audit tool”—watches you browse and highlights potential XSS, CSRF and other vulnerabilities in your application. Created by Michal Zalewski at Google. # 3rd July 2008, 2:35 pm

IE8 Security Part IV: The XSS Filter (via) IE8 will include an XSS filter to identify and neutralise “reflected” XSS attacks (where malicious code in a query string is rendered to the page), turned on by default. Sounds like a good idea to me, and site authors can disable it using Yet Another Custom HTTP header (X-XSS-Protection: 0). # 3rd July 2008, 9:37 am

Evil GIFs: Partial Same Origin Bypass with Hybrid Files. First there were PNGs that had crossdomain.xml files embedded in them, now there are GIFs that contain Java applets (as JAR files). At this point I’d say don’t even bother trying to validate uploaded files, just make sure they’re served off an entirely different domain instead where XSS doesn’t matter. # 1st July 2008, 8:58 am

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

Django: security fix released. XSS hole in the Admin application’s login page—updates and patches are available for trunk, 0.96, 0.95 and 0.91. # 14th May 2008, 7:49 am

Mass Attack FAQ. Thousands of IIS Web servers have been infected with an automated mass XSS attack, not through a specific IIS vulnerability but using a universal XSS SQL query that targets SQL Server and modifies every text field to add the attack JavaScript. If an app has even a single SQL injection hole (and many do) it is likely to be compromised. # 26th April 2008, 9:12 am

ISPs’ Error Page Ads Let Hackers Hijack Entire Web (via) Earthlink in the US served “helpful” links and ads on subdomains that failed to resolve, but the ad serving pages had XSS holes which could be used to launch phishing attacks the principle domain (and I imagine could be used to steal cookies, although the story doesn’t mention that). Seems like a good reason to start using wildcard DNS to protect your subdomains from ISP inteference. # 21st April 2008, 6:51 am

Flirting with mime types [PDF] (via) Different browsers have different rules for which content types will be treated as active content (and hence could be vectors for XSS attacks). IE uses a blacklist rather than a whitelist and hence rendered active content for 696 of the tested content types. # 14th April 2008, 8:18 am

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

Is your Rails app XSS safe? SafeErb is an interesting take on auto-escaping for Rails: it throws an exception if you try to render a string that hasn’t been untainted yet. # 10th January 2008, 6:46 pm

XSS Vulnerabilities in Common Shockwave Flash Files. Is the word “shockwave” still relevant to Flash? Regardless, it turns out Flash can be a serious vector for XSS attacks, and many commonly used components have recently fixed holes (and hence should be updated ASAP). # 6th January 2008, 9:35 am

Why the h can’t Rails escape HTML automatically? It would be a pretty huge change, but auto-escaping in Rails 2.0 could close up a lot of accidental XSS holes. # 1st December 2007, 8:34 pm

Django Changeset 6671. Malcolm Tredinnick: “Implemented auto-escaping of variable output in templates”. Fantastic—Django now has protection against accidental XSS holes, turned on by default. # 14th November 2007, 5:05 pm