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.

Resources

Google Gruyere:

Google is kind enough to offer, for free (in typical Google fashion), a series of tutorials to teach users common web vulnerabilities. The only prerequisite is that you have some basic knowledge of web development.

There are two basic forms of hacking: black box and white box. Black box hacking is the attempt to find vulnerabilities in a website by manipulating data fields, URL parameters, and intercepting HTML request and response actions. White box is studying the source code of a web application to find vulnerabilities in that fashion.

Diving more in depth, these are the tutorials Gruyere offers:

• Cross-Site Scripting (XSS)
• Client State Manipulation
• Cross-Site Request Forgery (XSRF)
• Cross-Site Script Inclusion
• Path Traversal
• Denial of Service (DoS)

I plan to complete all of these tutorials to broaden my knowledge of web security. 

Introduction: Beating Hackers at Their Own Game

With all the recent headlines about companies losing their customer's data, I think to myself - why can't I have some fun? Of course I don't want to do any real damage (I'd rather stay out of jail), and I don't want to be the center of an FBI manhunt, but why not learn a new skill set pertaining to a field I eventually want to work in?

Think about the last time you made a purchase online. I almost guarantee you never had any thoughts of your personal data being compromised. Your credit card information, address, name, phone number, email, and in some cases even your birthday is required for a transaction, but do you ever really question the integrity of a company's security infrastructure? We have become so ignorant to the fact that some IT guy locked in the basement of a company, who couldn't care less about his job, may be in charge of keeping your personal data, and the data of millions of other people, safe and secure from outside threats. Even if those thoughts cross your mind, what’s the worst that can happen? Your credit card company places a hold on your card and issues you a new one. Any lost money will be reimbursed. You’ll receive an apology email (how thoughtful).

The data security climate has changed extensively over the past 10 years. It used to be just annoyances: pop-ups, spam, adware, toolbars, downtime, etc. Today, hackers are looking to make a statement. They release classified information to the public, steal financial data from databases containing millions of credit card records, and take websites offline. The goal is to make a financial gain or to draw attention to a cause hackers deem worthy-- not just to inconvenience you, the lowly user.

This is where I step in. My goal is to learn the most common exploits to make sure everything I work on in the future is protected from common web vulnerabilities.