We get some interesting correspondence here at Naked Security.
Sometimes we write about the spam we receive, whether in email or as comments.
Sometimes we get requests from readers who would like us to take a deeper look at breaking news stories that have been getting coverage but not much explanation.
And sometimes we get information from the finders of security bugs – and not just those bugs unearthed by well-heeled vulnerability research teams or by well-known security researchers who spend their lives digging for holes.
Here’s one that we assume was spotted by accident, perhaps just in passing, by a security-literate user who was willing to stop and take stock of what he’d just seen.
It’s a reminder that even experts who uncover bugs for a living won’t find every hole, and yet even arcane bugs may show up in real life, and get spotted by alert users for what they are.
Well-meaning users will report those bugs, instead of leaving them behind where crooks might also find them.
XSS revisited
This one was sent to us by Yosi Ovadia, and while it’s not too serious, we thought it was interesting because it’s a Cross-Site Scripting (XSS) detection problem in Chrome that Chrome’s own protective code is supposed to block.
XSS refers to a range of tricks for bypassing browser security, and almost always depends upon poor error-checking, either by the server that produced the reply, or the browser that formulated the request, or both.
Browser security, as you will have read before on Naked Security, depends heavily on what’s called the Same Origin Policy, or SOP.
Simply put, any resources specific to your site that are stored locally by my browser, such as cookies and JavaScript data objects, should only subsequently be visible when my browser is processing content from your site.
In other words, only JavaScript served up from your server should be able to read browser data originally set by your server.
But imagine that I could sneak malicious content into a web request, such as disguised JavaScript, and your server didn’t notice.
Now, just imagine what tricks I could get up to if there were pages on your server that included some (or even all) of my web request in their replies!
That’s common when you’re searching.
For example, if I search for, say…
expialidocious
…but that word doesn’t exist on your site, you might send me a web page in reply that tells me:
Sorry. The word "expialidocious" couldn't be found.
You can see where this is going, because the returned page includes the same text I just sent in.
So, if I’m a hostile sort, I might search for something trickier instead, such as:
<script>about(document.cookie)</script>
When your server fails to find that text, it had jolly well better not send back an HTML page that contains it.
Otherwise your server will be sending back my script that can read your cookies in the browser.
And if I can do that, then in a real-world attack, perhaps triggered by a URL on a booby-trapped site under my control, I’d be able to do a lot worse.
For example, I might well be able to bleed off data items, such as user details or login cookies, that are supposed to be a private matter between you and the visitors to your site.
Heading off XSS attacks
In theory, this sort of attack should be prevented by the server.
But it’s also handy if your browser stops requests of this sort going out in the first place, on the grounds that there isn’t any pertinent reason to allow content like JavaScript in HTTP requests.
→ HTTP requests that include user-supplied data usually package it into the URL, typically following a question mark (“?”), or use a special sort of request called a POST. In an HTTP POST, the user-supplied data is placed into the body of the request, rather than the URL itself.
Google Chrome includes a component called the XSSAdvisor, which aims to emasculate or to block risky content sent in a URL or a POST.
Ovadia found that it was easy to trick XSSAdvisor into missing a sneakily embedded script.
Instead of simply embedding text of the form <script>...</script> into his request, he nested the script inside another sort of tag, like this…
<sometag><script>...</script></sometag>
…and if his nested script just happened to start with a special sequence of characters (we’ll avoid giving the exact details here), then the XSSAdvisor would let it through, even though it wasn’t supposed to.
What to do?
This isn’t really a problem you need to worry about.
The Chrome programmers corrected it almost at once, so it will automatically be patched in the next update of Chrome.
Also, the bug doesn’t give you a direct way to attack a server, because the server also needs not only to ignore the malevolent content, but also to fold it back into the reply.
However, we wrote this article because:
- We thought it was interesting.
- It gave us a chance to revisit the problems of XSS.
- It’s a reminder that writing code to detect bad stuff isn’t easy.
- We want to encourage you to report bugs like this if you find them.
- We want to encourage to you react quickly if someone reports a bug like this to you.
And there you have it.
Leave a Reply