Simon Willison’s Weblog

Subscribe

59 items tagged “xss”

2024

Weeknotes: Page caching and custom templates for Datasette Cloud

My main development focus this week has been adding public page caching to Datasette Cloud, and exploring what custom template support might look like for that service.

[... 924 words]

2021

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

2020

Datasette 0.51 (plus weeknotes)

I shipped Datasette 0.51 today, with a new visual design, plugin hooks for adding navigation options, better handling of binary data, URL building utility methods and better support for running Datasette behind a proxy. It’s a lot of stuff! Here are the annotated release notes.

[... 2020 words]

2019

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

2017

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

2013

What Javascript tools are there for cleansing input?

Don’t cleanse. Escape instead.

[... 18 words]

2012

What are the best practices to avoid XSS and SQL Injections attacks (platform agnostic)?

Input validation is, in my opinion, a red herring. Sure—if you ask the user for an integer or date you should make sure they entered one before attempting to save it anywhere or use it for processing, but injection attacks often involve text fields (e.g. names, or comments posted on Quora) and validating those on input is a recipe for banning “Tim O’Reilly” from ever creating a proper profile on your site!

[... 316 words]

2010

Why are XSS attacks spreading like fire these days?

XSS attacks are common and easy, and crop up all the time. What’s new is that the number of people who are aware of the potential for XSS worms has increased hugely, so when an XSS does crop up in something popular there’s a much higher chance of someone turning it in to a worm (as happened with Twitter the other day).

[... 96 words]

Why do some people disable JavaScript in their browser?

For security reasons.

[... 159 words]

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

2009

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

2008

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).

Jeremiah Grossman # 3rd November 2008, 12:43 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