We build web applications to do useful things for us, but unfortunately there are those that attempt to cause our creations to do something we never intended them to do.
Web application security has been a huge issue over the past few years. There are so many different methods someone can employ to break your application or cause it to do unintended things. One type of attack being utilized more commonly is called a CSRF attack, or cross-site request forgery. This is a method by which an attacker can have your application perform some function as if a valid user requested that function to occur. The trick is that a valid user really did request the function. The attacker simply forges the request and has the unsuspecting user's web browser make the request. It sounds like it would be really complicated, but it really isn't.
To learn how this can happen, let's first create a sample unsecure application so that you can see how this type of attack would be possible. Let's say that on your web application you have a form that allows an authenticated user to change their email address. The form may look something like this (this sample is obviously stripped down):
<?php
if(!is_logged_in()) { // redirect to login page exit; }
Then, you have a script called updateemail.php which looks something like this:
<?php
if(!is_logged_in()) { // redirect to login page exit; }
update_email(); echo "Your email address has been updated.";
?>
Obviously these have been simplified and the real functionality has been hidden behind functions, but this gives you the picture you need to see. At first glance you may be wondering what the problem is. We are checking to make sure the user is authenticated before updating the email address, right? That's why these types of attacks are so dangerous. Many application developers have no idea that their application is vulnerable because it appears that they have done everything right.
Now, let me show you a simple method to exploit this update email script and you'll be able to see just how easily a third party can manipulate your web application. Suppose that on another web site, an attacker has this line of HTML:
Now, anyone that visits their web page, and is authenticated on your web application, has their email address updated to the attacker's email address. The attacker can then update the password on the account (because you require email confirmation for a password reset) and take control. Obviously this example doesn't take into account that you should require some other authorization steps to change a user's email address. It was meant as an example of what could be done.
This same technique can be used to rate stories (this hack was used at Digg.com to digg up stories until Digg implemented a fix), submit comments, delete postings, and do tons of other things that you expect only authenticated users to do. With so many sites offering the ability to stay logged in via a cookie, these attacks are becoming commonplace, with attackers being able to safely assume that many will have cookies stored for the sites they choose to target.
/ 17 