Denial of Service (DoS) Attack

What is a DoS attack?
A Denial of Service (DoS) attack is focused on making a service unavailable for its intended use. There are numerous ways to accomplish this attack. The two Gruyere specifies are quit the server and overload the server.

Exploit:
Protecting a web application against DoS attacks is outside the scope of Gruyere's tutorials and attacking Gruyere in this fashion is considered malicious to the app engine. Because of the many ways to perform a DoS attack, Gruyere only provides brief, Gruyere specific, exploit information.

Quit the server:
(This is a form of white box hacking where we have access to the system's source code). This exploit takes advantage of a bug in the system where a user does not have to have admin rights in order to request to "quit server". This is identified by looking at the server management source code and simply requesting the following url:

http://google-gruyere.appspot.com/123/quitserver

Overloading the server:
This exploit takes advantage of a bug in Gruyere's system that allows users to inject their own files into Gruyere's source code. The purpose of this attack is to make server resources unavailable to ordinary requests by either sending more requests than a server can handle or using all the servers resources (memory, CPU, storage).

Fix:
There are a large variety of DoS attacks that are specific to each web application, so Gruyere doesn't detail any fixes. For more information visit:

https://www.owasp.org/index.php/Denial_of_Service

http://google-gruyere.appspot.com/part4#4__denial_of_service

Path Traversal

What is Path Traversal?
Path Traversal is using knowledge of file paths and directories to gain access to information a user should not have access to. In both Windows and Linux file systems '..' represents the parent directory. Using ../../secretFile.txt, a user can access secretFile.txt without the knowledge of specific directory information.

Exploit:
An attacker simply needs to know the name of the file stored on the server to gain access to it. According to Gruyere, most developers don't even change the default file structure for their web application.

If an attacker knows the structure of your file system, then they can craft a URL that will traverse out of the installation directory to /etc. For example, if Picasa was vulnerable to path traversal and the Picasa servers use a Unix-like system, then the following would retrieve the password file:

http://www.picasa.com/../../../../../../../etc/passwd

Fix:

Most web browsers, like Chrome and Firefox, optimize out '..' in urls, but this can be circumvented by using a different browser or a web proxy.

Gruyere suggests to serve only specific resource files. This can be accomplished by hardcoding a list of accessible files when the application starts. Only requests for those files will be accepted.

For more information on Path Traversal: https://www.owasp.org/index.php/Path_Traversal

http://google-gruyere.appspot.com/part4#4__path_traversal

Cross-Site Script Inclusion (XSSI)

What is Cross-Site Script Inclusion (XSSI)?
Web browsers prevent web pages from one domain from reading information from a page on another domain, but browsers do allow images to be loaded from another domain and for scripts to be run from another domain. This can be exploited to read user data from one domain when that user is accessing another domain.

Exploit:
Say www.amazon.com has a script that reads your private account information from its servers. That script can be added to www.hackersite.com. When you access www.hackersite.com, it will pull information included in your private account from Amazon's server and can store it HackerSite's server.

Example:

Step 1: You can run a script from another website by including a

<script src="www.domain.com"></script> 

to your web application


Step 2: So I can use the example script

<script src="http://amazon.com/accountstuff/info.gtl"></script> 

and add that to my website (www.hackersite.com) to access your Amazon account information when you access my site (www.hackersite.com).

Fix:
OWASP details fixes on their website:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

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

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.