Earlier today, we got a glimpse of what happens when a big company forgets to cross their t’s and dot their i’s. And in programming, that means failing to validate user-entered data before displaying it on-screen.
My friend Peter Bukowinski first brought the exploit to my attention, posting a link to Apple.Com’s iTunes affiliate search interface. The link he sent me led to a page that looked like this:
Notice that the url in the browser bar is actually apple.com – this was not a parody site.
Evidently, Apple’s developers had neglected to validate the data being sent through the query string. The actual url was:
http://www.apple.com/itunes/affiliates/download/?artistName=your+mom&thumbnailUrl=http://www.moneysavingmom.com/money_saving_mom/images/2008/09/02/joblogo.gif&itmsUrl=http://www.bjs.com/&albumName=a+better+blowjob
So by editing the variables passed through the url, you could have a little harmless fun at Apple’s expense:
As you can see, by editing the query string and changing the variables for artistName, thumbnailUrl and itmsUrl, we could make the page hosted on Apple.Com’s server display whatever mischief we want. The variables were being echoed out directly on the page without any validation, filling in the blanks in their iTunes affiliate page template: [image] Looking for [blank] by [blank]?
But What is XSS?
Honestly, if you’re a web developer and you don’t know what XSS is by now, you suck at your job and should probably go back to spanking it to porn in your mom’s basement and leave the coding to the grownups. It’s been around long enough that you forfeit your right to call yourself a web-anything if you don’t know what it is by now. That said…
From the Cross-Site Scripting FAQ on cgisecurity.com:
Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website. Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. If for example I was logged in as “john” and read a message by “joe” that contained malicious javascript in it, then it may be possible for “joe” to hijack my session just by reading his bulletin board post.
Cross-Site Scripting is nothing new, not even on large, popular websites. While this example on Apple.Com resulted only in a humorous page being available under a large company’s domain, many XSS attacks can be far more sinister – and the attack had far more potential than our harmless prank, as users on Reddit.Com noticed that the exploit did allow malicious scripting including JavaScript injection and IFrame injection (thanks to @shocm for bringing the Reddit thread to my attention).
It looks as though Apple’s server sanitized the <script></script> tag, but there are at least a half-dozen ways to inject javascript without using a <script> tag, many of which are outlined on the XSS Cheat Sheet.
This type of exploit is a DOM-based exploit. Wikipedia does a good job of summing it up:
Traditionally, cross-site scripting vulnerabilities would occur in server-side code responsible for preparing the HTML response to be served to the user. With the advent of web 2.0 applications, a new class of XSS flaws emerged, however: DOM-based vulnerabilities come to be during the content processing stages delegated to the client, typically in client-side JavaScript. The name refers to the standard model for representing HTML or XML contents, called the Document Object Model or DOM for short. The model is the primary way for JavaScript programs to manipulate the state of a web page, and populate it with dynamically computed data.
A typical example is a piece of JavaScript accessing and extracting data from the URL via the location.* DOM, or receiving raw non-HTML data from the server via XMLHttpRequest, and then using this information to write dynamic HTML without proper escaping, entirely on client side.
Netcraft featured an XSS vulnerability on PayPal’s website discoverd by a Finnish security researcher in May 2008:
An exploit was reported in March 2007 on YouTube’s website, allowing a similar type of JavaScript attack:
And an XSS exploit of eBay was documented in this YouTube video, also in 2007, and Twitter has suffered several XSS exploit attacks as recently as this year. But those are just a small handful of examples from a really long list.
In fact, just today, an article came out in The Register, detailing an XSS cookie hijacking attack that affects many large websites, including Google and Facebook. From the article:
A security researcher has discovered a weakness in a core browser protocol that compromises the security of Google, Facebook, and other websites by allowing an attacker to tamper with the cookies they set.
The weakness stems from RFC 2965, which dictates that browsers must allow subdomains (think www.google.com) to set and read cookies for their parent (google.com). The specification also states that if a cookie for a subdomain doesn’t already exist, the browser should use the cookie belonging to the parent instead.
The arrangement makes it possible for attackers to steal or even alter the cookies that websites use to authenticate their users. Attackers would first have to identify an XSS, or cross-site scripting, bug in some part of the site they are targeting. But because virtually any subdomain will suffice, the scenario isn’t unrealistic, two web security experts said.
Apple’s development team responded quickly to the exploit on their site – a little too quickly in my opinion, since I was preparing to have a little more fun with it, but they had patched it by the time I got home. It should still serve as a reminder to developers of just how important data scrubbing and validation is, no matter whether your site is big or small, with 2 hits a day or 2 million.
XSS Vulnerabilities Compromise User Data – And Your Reputation
As the eBay exploit video shows (and as anyone on Twitter saw this year), XSS attacks are not just embarrassing – they can be used for phishing scams, tricking users to login to a fake site, exposing their login credentials or worse. PayPal and bank phishing schemes often prompt the user to “confirm” their bank account information or credit card information “for security purposes”.
Other XSS exploits may trick users into thinking their computer has been infected by a virus, prompting them to download “free software” to clean their system – meanwhile the software the panicking user is downloading actually is the virus. And even though you might never fall for something so blatantly obviously, lots and lots of people do, every day.
Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user in order to gather data from them. Everything from account hijacking, changing user settings, cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks. XSS exploits can even be used to facilitate “Denial Of Service” attacks (or DoS attacks), and potential “auto-attacking” of hosts if a user simply reads a post on an infected message board.
While XSS attacks themselves cannot compromise files on your server, XSS holes can allow Javascript insertion, which may allow for limited execution. If an attacker were to exploit a browser flaw (browser hole) it could then be possible to execute commands on the client’s side. If command execution were possible it would only be possible on the client side. In simple terms XSS holes can be used to help exploit other holes that may exist in your browser or server.
User-Submitted Data and Your Database
Trusting user variables without cleaning or validating them opens you up to a whole host of problems if your application is powered by a database.
For example, the following SQL command is used to validate user login requests:
[sourcecode language=”sql”]$sql_query = “select * from users where user=’$user’ and password=’$pass'”[/sourcecode]If the user-submitted data is not properly validated, an attacker can exploit this query and pass the login screen by simply submitting specially crafted variables.
For example, attacker can submit the following data as a $user variable: admin’ or ‘1’=’1 . When this $user variable is glued together with the query, it will look as followed:
[sourcecode language=”sql”]$sql_query = “select * from users where user=’admin’ or ‘1’=’1′ and password=’$pass'”[/sourcecode]Now, the attacker can safely pass the login screen because or ‘1’=’1′ causes the query to always return a “true” value while ignoring the password value.
Using similar techniques, an attacker can retrieve database records, pass login screens, and change database contents, for example by creating new administrative users. Using similar techniques, a malicious attack will be able to execute arbitrary shell commands, read or write arbitrary commands, and more.
It is our responsibility to protect our users (and the trust they put in us, deserved or not), and XSS vulnerabilities open the doors to all manner of mischief. At their most benign, they can result in a site defacement. At their worst, they compromise the very safety and livelihood of the people that fall for them – not to mention the impact on your company’s reputation.
If you think your site is too small for hackers to bother with, think again. There are plenty of script kiddies out there that will happily run their exploit toolkit scripts and crawl page after page, testing for exploits. They are able to find common exploits in sites they have never physically even visited through this method. And once they find a vulnerability, word spreads fast.
It should also serve as a reminder to us as a internet users to be a little less trusting. It seems obvious, but we are so trained to respond to visual cues and prompts for activities we do every day – logging into a website, checking out with PayPal, etc – that we can sometimes become careless. We sometimes trust the big guys a little too much, assuming that because they’re that big, they’ve got to have their shit together. Even when we know better, our interactions online have become somewhat mechanical.
While browsers are getting better at helping us realize if we’re entering data into a site that is suspect, ultimately the responsibility falls back upon us to pay attention to what we’re doing and to whom we give our valuable information.
So as a developer, what can you do to protect your software and sites from XSS attacks?
Here are a few good places to start.
Stuff to Read:
- Learn more about XSS and how it works on the Cross-Site Scripting FAQ on cgisecurity.com.
- Learn more about Backdooring a Webserver using MySQL, which details how a user could read/write files to your server and execute commands using mySQL.
- Check out the OWASP (Open Web Application Security) website and stay up to date
Stuff to Do:
Always clean and validate ANY data you receive from the user
Use the appropriate escaping for the programming languages and databases you use
Educate yourself on as many examples of XSS (both theoretical and in-the-wild) as you can, so you know what to look for. Wikipedia details a few common methods worth checking out on their Cross-Site Scripting page. The only real defense you have against attacks is to keep yourself informed and current on what the bad guys are up to. This isn’t one of those things that you can read about once and rest on your laurels. You must be vigilant and aggressive about staying on top of what’s going on. It’s your job.
Bookmark and test your scripts against the code samples on the XSS Cheatsheet on ha.ckers.org. This cheatsheet is specifically geared towards exploits that can potentially get past standard filtering that developers might do on their data, such as strip_tags. Also check out the MySQL Injection Cheat Sheet and the SQL Injection Cheat Sheet.
Periodically check your webserver access logs and error logs and look for anything that looks like someone might be trying to find a backdoor. Look for people trying to pass data that doesn’t belong, sending variables that are common configuration file names, and so on.
Turn OFF error reporting displayed to the browser on production environments, and instead log errors to a file. Error messages can expose information about your file structure and your database structure.
Pay attention! Keep your ear to the ground on sites like ha.ckers.org and other (mostly) whitehat exploit blogs and communities. This is your livelihood. Do your job.
If you’re using open source software, make sure you keep up to date with new releases. Many popular open source projects (such as WordPress, phpNuke, phpBB, etc) are frequent targets for malicious scripting. Be sure to hide references to your software version numbers from the public, since certain versions may have exploits that are well known, and attackers will know exactly how to target your site if they know what version you’re running.
Shell out the $39 for the 300 page e-Book Detecting Malice, written by Robert Hansen (aka RSnake, on Twitter at @RSnake) and actually read it. I can’t believe I’m actually endorsing a freaking e-Book, but its really that good. I don’t know Robert personally, I’m not endorsing it as a favor or because I like him as a person. For all I know he eats puppies for breakfast. But his book is fantastic.
And finally, Test test test test test!
There’s even an interesting Twitter account that highlights high-profile XSS exploits – it’s low-volume, but it’s surprising how many turn up that never make the news.
Incidentally, something I discovered while having a little fun on Apple.Com’s site – if you do a Google Images search for ‘hot tar enema”, only four images come up, and one of them is a photo of Rush Limbaugh. I’m not even making that up. Also funny, since I tweeted about that this afternoon, my tweet is now the number one Google search result for “hot tar enema”. Aren’t you jealous?
