Thursday, May 12, 2011
Users are taught to protect themselves from malicious programs by installing sophisticated antivirus software, but often they may also entrust their private information to websites like yours, in which case it's important to protect their data. It's also very important to protect your own data; if you have an online store, you don't want to be robbed.
Over the years companies and webmasters have learned—often the hard way—that web application security is not a joke; we've seen user passwords leaked due to SQL injection attacks, cookies stolen with XSS, and websites taken over by hackers due to negligent input validation.
Today we'll show you some examples of how a web application can be exploited so you can learn from them; for this we'll use Gruyere, an intentionally vulnerable application we use for security training internally, too. Do not probe others' websites for vulnerabilities without permission as it may be perceived as hacking; but you're welcome—nay, encouraged—to run tests on Gruyere.
Client state manipulation - What will happen if I alter the URL?
Let's say you have an image hosting site and you're using a PHP script to display the images users have uploaded:
https://www.example.com/showimage.php?imgloc=/garyillyes/kitten.jpg
So what will the application do if I alter the URL to something like this and userpasswords.txt is an actual file?
https://www.example.com/showimage.php?imgloc=/../../userpasswords.txt
Will I get the content of userpasswords.txt?
Another example of client state manipulation is when form fields are not validated. For instance, let's say you have this form:
It seems that the username of the submitter is stored in a hidden input field. Well, that's great! Does that mean that if I change the value of that field to another username, I can submit the form as that user? It may very well happen; the user input is apparently not authenticated with, for example, a token which can be verified on the server.
Imagine the situation if that form were part of your shopping cart and I modified the price of a $1000 item to $1, and then placed the order.
Protecting your application against this kind of attack is not easy; take a look at the third part of Gruyere to learn a few tips about how to defend your app.
Cross-site scripting (XSS) - User input can't be trusted
A simple, harmless URL:
https://google-gruyere.appspot.com/611788451095/%3Cscript%3Ealert('0wn3d')%3C/script%3E
But is it truly harmless? If I decode the percent-encoded characters, I get:
<script>
alert('0wn3d')
</script>
Gruyere, just like many sites with custom error pages, is designed to include the path component in the HTML page. This can introduce security bugs, like XSS, as it introduces user input directly into the rendered HTML page of the web application. You might say, "It's just an alert box, so what?" The thing is, if I can inject an alert box, I can most likely inject something else, too, and maybe steal your cookies which I could use to sign in to your site as you.
Another example is when the stored user input isn't sanitized. Let's say I write a comment on your blog; the comment is simple:
<a href="javascript:alert('0wn3d')">Click here to see a kitten</a>
If other users click on my innocent link, I have their cookies:
You can learn how to find XSS vulnerabilities in your own web app and how to fix them in the second part of Gruyere; or, if you're an advanced developer, take a look at the automatic escaping features in template systems we blogged about on our Online Security blog.
Cross-site request forgery (XSRF) - Should I trust requests from evil.com?
Oops, a broken picture. It can't be dangerous—it's broken, after all—which means that
the URL of the image returns a 404 or it's just malformed. Is that true in all of the
cases?
No, it's not! You can specify any URL as an image source, regardless of its content type. It can be an HTML page, a JavaScript file, or some other potentially malicious resource. In this case the image source was a simple page's URL:
That page will only work if I'm logged in and I have some cookies set. Since I was actually logged in to the application, when the browser tried to fetch the image by accessing the image source URL, it also deleted my first snippet. This doesn't sound particularly dangerous, but if I'm a bit familiar with the app, I could also invoke a URL which deletes a user's profile or lets admins grant permissions for other users.
To protect your app against XSRF you should not allow state changing actions to be called via
GET; the POST method was invented for this kind of state-changing
request. This change alone may have mitigated the above attack, but usually it's not enough and
you need to include an unpredictable value in all state changing requests to prevent XSRF. Please
head to Gruyere if you
want to learn more about XSRF.
Cross-site script inclusion (XSSI) - All your script are belong to us
Many sites to