Cross-Site Request Forgery

What is Cross-Site Request Forgery (CSRF)?
A server can't discern between a request coming from a user's deliberate action (such as clicking submit) or from a browser request not stemming from a user's action (loading an image). Also, any cookie associated with a site is sent with a request, regardless of a user's action.


Exploit:
For example let's take Gmail as an example. Say Gmail has a button on its website that deletes your account when clicked. If the url for the delete button is:

https://mail.google.com/deleteaccount.do?accountId=ACCOUNTID

A clever attacker can take advantage of this fact by embedding a piece of code in an arbitrary website (www.malicious-website.com) that contains the url of Gmail's delete button.

<img src="https://mail.google.com/deleteaccount.do?accountId=ACCOUNTID">

When you access the malicious website, your Gmail account will be deleted without your knowledge and without you having any idea what happened. You do not need to log in to Gmail for this to happen because the cookie associated with your Gmail login is automatically passed on to and validated by the server.

Fix:
One common misconception is using POST instead of GET requests will alleviate the threat of CSRF. According to OWASP, there are still ways for hackers to trick a victim into submitting a forged POST request.

One surefire way to eliminate the threat of CSRF is to use tokens in the following manner:

1. Generate a new CSRF token on user login, and add it to the current http session.
2. On any form that need be protected add a parameter/hidden field that calls for the token.
3. On the server side check that the token is from the current session and is legitimate.
4. On logout and session timeout delete the CSRF token from the current http session.

Source:
http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

http://google-gruyere.appspot.com/part3#3__cross_site_request_forgery

Client-State Manipulation

What is client-state manipulation?
Users interact indirectly with web servers. Users must access web servers through browsers (Firefox, Chrome, etc.). Servers are vulnerable to attacks because developers don't have control over which browser a client uses to access their website or what information a user submits to the server. Therefore servers can't trust all requests submitted by the client's browser. Server-side validation needs to take place in order to prevent exploits from users.


Tutorial Part 1: Elevation of Privileges
In this Gruyere tutorial I am going to convert my regular user account to an administrator account with special privileges not normally available to ordinary users.

This can be accomplished by simply editing the url:

• http://google-gruyere.appspot.com/123/saveprofile?action=update&is_admin=True

This exploit works because there is no server-side validation. Validation on the server would notice the request is coming from a user without administrative privileges and will deny the request to update the profile to have admin rights.

Tutorial Part 2: Cookie Manipulation

Since cookies are saved on the client-side, they a vulnerable to manipulations. In this part of the tutorial I will manipulate my cookie object to look like a cookie from another user.  

Google Gruyere issues cookies in the following format: hash | username | admin | author

Because Gruyere does not limit the number of characters in a username I can create the following username: foo|admin|author

The code used to parse cookies on the server-side is tolerant of abnormal cookies-- a cookie string with varying characters and lengths will still be read by the server. This means that an attacker doesn't need to know how cookies are parsed on the server-side to pass a malicious cookie.

By inputing the string (foo|admin|author) into the username field I have successfully created an account which will return a cookie for someone with the username 'foo' and with admin rights.

Fix:

To protect against cookie manipulation a hash function should be implemented into each cookie. A hash algorithm maps data to a specific length. This hash code is stored on the server when a cookie object is issued in a response from the server to the client. The hash value is verified on the server when the client returns the cookie in a request.

Source:
http://google-gruyere.appspot.com/part3#3__client_state_manipulation

Cross-Site Scripting (XSS)

Send your confidential data along with your order.

This vulnerability allows hackers to inject their own code into a website not under their administration in order to execute that code when visitor enters the page. Code can be written to copy every input you make on a website and forward it to the hacker. Imagine if you were checking out with an online shopping cart, and all the data you inputed into a form was sent to a hacker when you clicked submit.






The Tutorial: Basics
The outcome of this tutorial is to inject script into a website (Gruyere's sandboxed site) that will show a pop-up with an alert message. A pop-up isn't the end of the world, but if you can inject code that can trigger a pop-up, you can inject much worse code as well.

File Upload XSS:
This exploit takes advantage of a site's file upload feature. Some sites allow you to upload HTML files (exploit.html). HTML files can contain script. I uploaded the tutorial's example script:

<!DOCTYPE html>
<html>

<h1>You were hacked!</h1>

<script>
alert(1)
</script>

</body>
</html>

The idea is to send someone a link 
(http://google-gruyere.appspot.com/204181329637/jgeorge0210/exploit2.html) 
to the file you uploaded, containing malicious script. Since the file you uploaded is on a trusted site, a user will unknowingly trust the link. 

For example if someone sent you a link that looked like:

http://www.amazon.com/9234890324/username/20%_discount.html

You will likely click the link thinking that Amazon sent you a discount coupon.

Fix:

A simple solution to this problem, when creating your own website, is to host the uploaded content on another domain. 

For example:

Instead of http://www.amazon.com/9234890324/username/20%_discount.html

Use http://www.username.amazon.com/9234890324/20%_discount.html

This way unassuming users can see that the content is uploaded by a user and not Amazon itself.

Source:
http://google-gruyere.appspot.com/part2#2__cross_site_scripting

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Schedule Feasibility

This is what I plan to accomplish in the following weeks:

Cross-Site Scripting (XSS)

• Wed, March 4 (3/5/14)

Client State Manipulation

• Wed, March 12 (3/12/14)

Cross-Site Request Forgery (CSRF)

• Wed, March 19 (3/19/14)

Cross-Site Script Inclusion

• Wed, March 26 (3/26/14)

Path Traversal

• Wed, April 2 (4/2/14)

Denial of Service (DoS)

• Wed April 9 (4/9/14)

This is a tentative schedule-- I may deviate from it, but the plan is to complete the above tutorials within 6 weeks.