Web 2-Point-Owned: Apple.Com's XSS Exploit
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:
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…
This type of exploit is a DOM-based exploit. Wikipedia does a good job of summing it up:
Netcraft featured an XSS vulnerability on PayPal’s website discoverd by a Finnish security researcher in May 2008:
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.
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?