JabaT0's Repository

 Web Application Exploits and Defenses


A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz

REFERENCIA:
http://google-gruyere.appspot.com/

Want to beat the hackers at their own game?

• Learn how hackers find security vulnerabilities!
• Learn how hackers exploit web applications!
• Learn how to stop them!

This codelab shows how web application vulnerabilities can be exploited and how to defend against these attacks. The best way to learn things is by doing, so you'll get a chance to do some real penetration testing, actually exploiting a real application. Specifically, you'll learn the following:

• How an application can be attacked using common web security vulnerabilities, like cross-site scripting vulnerabilities (XSS) and cross-site request forgery (XSRF).
• How to find, fix, and avoid these common vulnerabilities and other bugs that have a security impact, such as denial-of-service, information disclosure, or remote code execution.

To get the most out of this lab, you should have some familiarity with how a web application works (e.g., general knowledge of HTML, templates, cookies, AJAX, etc.).

Gruyere

This codelab is built around Gruyere /ɡruːˈjɛər/ - a small, cheesy web application that allows its users to publish snippets of text and store assorted files. "Unfortunately," Gruyere has multiple security bugs ranging from cross-site scripting and cross-site request forgery, to information disclosure, denial of service, and remote code execution. The goal of this codelab is to guide you through discovering some of these bugs and learning ways to fix them both in Gruyere and in general.

The codelab is organized by types of vulnerabilities. In each section, you'll find a brief description of a vulnerability and a task to find an instance of that vulnerability in Gruyere. Your job is to play the role of a malicious hacker and find and exploit the security bugs. In this codelab, you'll use both black-box hacking and white-box hacking. In black box hacking, you try to find security bugs by experimenting with the application and manipulating input fields and URL parameters, trying to cause application errors, and looking at the HTTP requests and responses to guess server behavior. You do not have access to the source code, although understanding how to view source and being able to view http headers (as you can in Chrome or LiveHTTPHeaders for Firefox) is valuable. Using a web proxy like Burp or WebScarab may be helpful in creating or modifying requests. In white-box hacking, you have access to the source code and can use automated or manual analysis to identify bugs. You can treat Gruyere as if it's open source: you can read through the source code to try to find bugs. Gruyere is written in Python, so some familiarity with Python can be helpful. However, the security vulnerabilities covered are not Python-specific and you can do most of the lab without even looking at the code. You can run a local instance of Gruyere to assist in your hacking: for example, you can create an administrator account on your local instance to learn how administrative features work and then apply that knowledge to the instance you want to hack. Security researchers use both hacking techniques, often in combination, in real life.

We'll tag each challenge to indicate which techniques are required to solve them: 

 Challenges that can be solved just by using black box techniques.

 Challenges that require that you look at the Gruyere source code.

 Challenges that require some specific knowledge of Gruyere that will be given in the first hint. 

WARNING: Accessing or attacking a computer system without authorization is illegal in many jurisdictions. While doing this codelab, you are specifically granted authorization to attack the Gruyere application as directed. You may not attack Gruyere in ways other than described in this codelab, nor may you attack App Engine directly or any other Google service. You should use what you learn from the codelab to make your own applications more secure. You should not use it to attack any applications other than your own, and only do that with permission from the appropriate authorities (e.g., your company's security team).

 Web Application Exploits and Defenses (Part 1)

A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz

Setup

To access Gruyere, go to http://google-gruyere.appspot.com/start. AppEngine will start a new instance of Gruyere for you, assign it a unique id and redirect you to http://google-gruyere.appspot.com/123/ (where 123 is your unique id). Each instance of Gruyere is "sandboxed" from the other instances so your instance won't be affected by anyone else using Gruyere. You'll need to use your unique id instead of 123 in all the examples. If you want to share your instance of Gruyere with someone else (e.g., to show them a successful attack), just share the full URL with them including your unique id.

The Gruyere source code is available online so that you can use it for white-box hacking. You can browse the source code at http://google-gruyere.appspot.com/code/ or download all the files fromhttp://google-gruyere.appspot.com/gruyere-code.zip. If want to debug it or actually try fixing the bugs, you can download it and run it locally. You do not need to run Gruyere locally in order to do the lab.

 Running locally

Reset Button

As noted above, each instance is sandboxed so it can't consume infinite resources and it can't interfere with anyone else's instance. Notwithstanding that, it is possible to put your Gruyere instance into a state where it is completely unusable. If that happens, you can push a magic "reset button" to wipe out all the data in your instance and start from scratch. To do this, visit this URL with your instance id:

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

About the Code

Gruyere is small and compact. Here is a quick rundown of the application code:

• gruyere.py is the main Gruyere web server
• data.py stores the default data in the database. There is an administrator account and two default users.
• gtl.py is the Gruyere template language
• sanitize.py is the Gruyere module used for sanitizing HTML to protect the application from security holes.
• resources/... holds all template files, images, CSS, etc.

Features and Technologies

Gruyere includes a number of special features and technologies which add attack surface. We'll highlight them here so you'll be aware of them as you try to attack it. Each of these introduces new vulnerabilities.

• HTML in Snippets: Users can include a limited subset of HTML in their snippets.
• File upload: Users can upload files to the server, e.g., to include pictures in their snippets.
• Web administration: System administrators can manage the system using a web interface.
• New accounts: Users can create their own accounts.
• Template language: Gruyere Template Language(GTL) is a new language that makes writing web pages easy as the templates connect directly to the database. Documentation for GTL can be found in gruyere/gtl.py.
• AJAX: Gruyere uses AJAX to implement refresh on the home and snippets page. You should ignore the AJAX parts of Gruyere except for the challenges that specifically tell you to focus on AJAX.
  • In a real application, refresh would probably happen automatically, but in Gruyere we've made it manual so that you can be in complete control while you are working with it. When you click the refresh link, Gruyere fetches feed.gtl which contains refresh data for the current page and then client-side script uses the browser DOM API (Document Object Model) to insert the new snippets into the page. Since AJAX runs code on the client side, this script is visible to attackers who do not have access to your source code.

Using Gruyere

To familiarize yourself with the features of Gruyere, complete the following tasks:

• View another user's snippets by following the "All snippets" link on the main page. Also check out what they have their Homepage set to.
• Sign up for an account for yourself to use when hacking. Do not use the same password for your Gruyere account as you use for any real service.
• Fill in your account's profile, including a private snippet and an icon that will be displayed by your name.
• Create a snippet (via "New Snippet") containing your favorite joke.
• Upload a file (via "Upload") to your account.

This covers the basic features provided by Gruyere. Now let's break them!

 Web Application Exploits and Defenses (Part 2)

A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz

Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is a vulnerability that permits an attacker to inject code (typically HTML or Javascript) into contents of a website not under the attacker's control. When a victim views such a page, the injected code executes in the victim's browser. Thus, the attacker has bypassed the browser's same origin policy and can steal victim's private information associated with the website in question.

In a reflected XSS attack, the attack is in the request itself (frequently the URL) and the vulnerability occurs when the server inserts the attack in the response verbatim or incorrectly escaped or sanitized. The victim triggers the attack by browsing to a malicious URL created by the attacker. In a stored XSS attack, the attacker stores the attack in the application (e.g., in a snippet) and the victim triggers the attack by browsing to a page on the server that renders the attack, by not properly escaping or sanitizing the stored data.

 More details

XSS Challenges

Typically, if you can get Javascript to execute on a page when it's viewed by another user, you have an XSS vulnerability. A simple Javascript function to use when hacking is the alert() function, which creates a pop-up box with whatever string you pass as an argument.

You might think that inserting an alert message isn't terribly dangerous, but if you can inject that, you can inject other scripts that are more malicious. It is not necessary to be able to inject any particular special character in order to attack. If you can inject alert(1) then you can inject arbitrary script using eval(String.fromCharCode(...)).

Your challenge is to find XSS vulnerabilities in Gruyere. You should look for vulnerabilities both in URLs and in stored data. Since XSS vulnerabilities usually involve applications not properly handling untrusted user data, a common method of attack is to enter random text in input fields and look at how it gets rendered in the response page's HTML source. But before we do that, let's try something simpler.

File Upload XSS

 Can you upload a file that allows you to execute arbitrary script on the google-gruyere.appspot.com domain?

 Hint

 Exploit and Fix

Reflected XSS

There's an interesting problem here. Some browsers have built-in protection against reflected XSS attacks. There are also browser extensions like NoScript that provide some protection. If you're using one of those browsers or extensions, you may need to use a different browser or temporarily disable the extension to execute these attacks.

At the time this codelab was written, the two browsers which had this protection were IE and Chrome. To work around this, Gruyere automatically includes a X-XSS-Protection: 0 HTTP header in every response which is recognized by IE and will be recognized by future versions of Chrome. (It's available in the developer channel now.) If you're using Chrome, you can try starting it with the --disable-xss-auditor flag by entering one of these commands:

• Windows: "C:\Documents and Settings\USERNAME\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" --disable-xss-auditor
• Mac: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-xss-auditor
• GNU/Linux: /opt/google/chrome/google-chrome --disable-xss-auditor

If you're using Firefox with the NoScript extension, add google-gruyere.appspot.com to the allow list. If you still can't get the XSS attacks to work, try a different browser.

You may think that you don't need to worry about XSS if the browser protects against it. The truth is that the browser protection can't be perfect because it doesn't really know your application and therefore there may be ways for a clever hacker to circumvent that protection. The real protection is to not have an XSS vulnerability in your application in the first place.

 Find a reflected XSS attack. What we want is a URL that when clicked on will execute a script.

 Hint 1

 Hint 2

 Exploit and Fix

Stored XSS

 Now find a stored XSS. What we want to do is put a script in a place where Gruyere will serve it back to another user.

The most obvious place that Gruyere serves back user-provided data is in a snippet (ignoring uploaded files which we've already discussed.)

 Hint 1

 Hint 2

 Exploit and Fix

Stored XSS via HTML Attribute

 You can also do XSS by injecting a value into an HTML attribute. Inject a script by setting the color value in a profile.

 Hint 1

 Hint 2

 Exploit and Fixes

Stored XSS via AJAX

 Find an XSS attack that uses a bug in Gruyere's AJAX code. The attack should be triggered when you click the refresh link on the page.

 Hint 1

 Hint 2

 Exploit and Fixes

Reflected XSS via AJAX

Find a URL that when clicked on will execute a script using one of Gruyere's AJAX features.

 Hint 1

 Hint 2

 Exploit and Fixes

More about XSS

In addition to the XSS attacks described above, there are quite a few more ways to attack Gruyere with XSS. Collect them all!

XSS is a difficult beast. On one hand, a fix to an XSS vulnerability is usually trivial and involves applying the correct sanitizing function to user input when it's displayed in a certain context. On the other hand, if history is any indication, this is extremely difficult to get right. US-CERT reports dozens of publicly disclosed XSS vulnerabilities involving multiple companies.

Though there is no magic defense to getting rid of XSS vulnerabilities, here are some steps you should take to prevent these types of bugs from popping up in your products:

1. First, make sure you understand the problem.
2. Wherever possible, do sanitizing via templates features instead of calling escaping functions in source code. This way, all of your escaping is done in one place and your product can benefit from security technologies designed for template systems that verify their correctness or actually do the escaping for you. Also, familiarize yourself with the other security features of your template system.
3. Employ good testing practices with respect to XSS.
4. Don't write your own template library :)

 Web Application Exploits and Defenses (Part 3)

A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz

Client-State Manipulation

When a user interacts with a web application, they do it indirectly through a browser. When the user clicks a button or submits a form, the browser sends a request back to the web server. Because the browser runs on a machine that can be controlled by an attacker, the application must not trust any data sent by the browser.

It might seem that not trusting any user data would make it impossible to write a web application but that's not the case. If the user submits a form that says they wish to purchase an item, it's OK to trust that data. But if the submitted form also includes the price of the item, that's something that cannot be trusted.

Elevation of Privilege

 Convert your account to an administrator account.

 Hint 1

 Hint 2

 Exploit and Fixes

Cookie Manipulation

Because the HTTP protocol is stateless, there's no way a web server can automatically know that two requests are from the same user. For this reason, cookies were invented. When a web site includes a cookie (an arbitrary string) in a HTTP response, the browser automatically sends the cookie back to the browser on the next request. Web sites can use the cookie to save session state. Gruyere uses cookies to remember the identity of the logged in user. Since the cookie is stored on the client side, it's vulnerable to manipulation. Gruyere protects the cookies from manipulation by adding a hash to it. Notwithstanding the fact that this hash isn't very good protection, you don't need to break the hash to execute an attack.

 Get Gruyere to issue you a cookie for someone else's account.

 Hint 1

 Hint 2

 Exploit and Fix

Cross-Site Request Forgery (XSRF)

The previous section said "If the user submits a form that says they wish to purchase an item, it's OK to trust that data." That's true as long as it really was the user that submitted the form. If your site is vulnerable to XSS, then the attacker can fake any request as if it came from the user. But even if you've protected against XSS, there's another attack that you need to protect against: cross-site request forgery.

When a browser makes requests to a site, it always sends along any cookies it has for that site, regardless of where the request comes from. Additionally, web servers generally cannot distinguish between a request initiated by a deliberate user action (e.g., user clicking on "Submit" button) versus a request made by the browser without user action (e.g., request for an embedded image in a page). Therefore, if a site receives a request to perform some action (like deleting a mail, changing contact address), it cannot know whether this action was knowingly initiated by the user — even if the request contains authentication cookies. An attacker can use this fact to fool the server into performing actions the user did not intend to perform.

 More details

XSRF Challenge

The goal here is to find a way to perform an account changing action on behalf of a logged in Gruyere user without their knowledge. Assume you can get them to visit a web page under your control.

 Find a way to get someone to delete one of their Gruyere snippets.

 Hint

 Exploit and Fix

Cross Site Script Inclusion (XSSI)

Browsers prevent pages of one domain from reading pages in other domains. But they do not prevent pages of a domain from referencing resources in other domains. In particular, they allow images to be rendered from other domains and scripts to be executed from other domains. An included script doesn't have its own security context. It runs in the security context of the page that included it. For example, if www.evil.example.com includes a script hosted onwww.google.com then that script runs in the evil context not in the google context. So any user data in that script will "leak."

XSSI Challenge

 Find a way to read someone else's private snippet using XSSI.

That is, create a page on another web site and put something in that page that can read your private snippet. (You don't need to post it to a web site: you can just create a .html in your home directory and double click on it to open in a browser.)

 Hint 1

 Hint 2

 Exploit and Fix

 Web Application Exploits and Defenses (Part 4)

A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz

Path Traversal

Most web applications serve static resources like images and CSS files. Frequently, applications simply serve all the files in a folder. If the application isn't careful, the user can use a path traversal attack to read files from other folders that they shouldn't have access to. For example, in both Windows and Linux, .. represents the parent directory, so if you can inject ../ in a path you can "escape" to the parent directory.
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 (it isn't) and the Picasa servers use a Unix-like system, then the following would retrieve the password file:

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

Information disclosure via path traversal

 Find a way to read secret.txt from a running Gruyere server.
Amazingly, this attack is not even necessary in many cases: people often install applications and never change the defaults. So the first thing an attacker would try is the default value.

 Hint 1

 Hint 2

 Exploit and Fix

Data tampering via path traversal

 Find a way to replace secret.txt on a running Gruyere server.

 Hint 1

 Hint 2

 Exploit and Fix

Denial of Service

A denial of service (DoS) attack is an attempt to make a server unable to service ordinary requests. A common form of DoS attack is sending more requests to a server than it can handle. The server spends all its time servicing the attacker's requests that it has very little time to service legitimate requests. Protecting an application against these kinds of DoS attacks is outside the scope of this codelab. And attacking Gruyere in this way would be interpreted as an attack on App Engine.
Hackers can also prevent a server from servicing requests by taking advantage of server bugs, such as sending requests that crash a server, make it run out of memory, or otherwise cause it fail serving legitimate requests in some way. In the next few challenges, you'll take advantage of bugs in Gruyere to perform DoS attacks.

DoS - Quit the Server

The simplest form of denial of service is shutting down a service. Find a way to make the server quit.

 Hint

 Exploit and Fix

DoS - Overloading the Server

 Find a way to overload the server when it processes a request.

 Hint 1

 Hint 2

 Exploit and Fix

NOTE: After performing the previous exploit, you'll need to push the reset button.

More on Denial of Service

Unlike a well defined vulnerability like XSS or XSRF, denial of service describes a wide class of attacks. This might mean bringing your service down or flooding your inbox so you can't receive legitimate mail. Some things to consider:

• If you were evil and greedy, how quickly could you take down your application or starve all of its resources? For example, is it possible for a user to upload their hard drive to your application? Entering the attacker's mindset can help identify DoS points in your application. Additionally, think about where the computationally and memory intensive tasks are in your application and put safeguards in place. Do sanity checks on input values.
• Put monitoring in place so you can detect when you are under attack and enforce per user quotas and rate limiting to ensure that a small subset of users cannot starve the rest. Abusive patterns could include increased memory usage, higher latency, or more requests or connections than usual.

Code Execution

If an attacker can execute arbitrary code remotely on your server, it's usually game over. They may be able to take control over the running program or potentially break out the process to open a new shell on the computer. From here, it's usually not hard to compromise the entire machine the server is running on.
Similar to information disclosure and denial of service, there is no recipe or specific defense to prevent remote code execution. The program must perform validation of all user input before handling it and where possible, implement functions with least privilege rights. This topic can't be done justice in just a short paragraph, but know that this is likely the scariest results a security bug can have and trumps any of the above attacks.

Code Execution Challenge

 Find a code execution exploit.

 Hint

 Exploit and Fix

More on Remote Code Execution

Even though there is no single or simple defense to remote code execution, here is a short list of some preventative measures:

• Least Privilege: Always run your application with the least privileges it needs.
• Application Level Checks: Avoid passing user input directly into commands that evaluate arbitrary code, like eval() or system(). Instead, use the user input as a switch to choose from a set of developer controlled commands.
• Bounds Checks: Implement proper bounds checks for non-safe languages like C++. Avoid unsafe string functions. Keep in mind that even safe languages like Python and Java use native libraries.
  
  

 Web Application Exploits and Defenses (Part 5)
A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz

Configuration Vulnerabilities

Applications are often installed with default settings that attackers can use to attack them. This is particularly an issue with third party software where an attacker has easy access to a copy of the same application or framework you are running. Hackers know the default account names and passwords. For example, looking at the contents of data.py you know that there's a default administrator account named 'admin' with the password 'secret'. See http://www.governmentsecurity.org/articles/default-logins-and-passwords-for-networked-devices.html for a sample hacker resource.
Configuration vulnerabilities also include features that increase attack surface. A common example is a feature that is on by default but you are not using, so you didn't configure it and the default configuration is vulnerable. It also includes debug features like status pages or dumping stack traces on failures.

Information disclosure #1

 Read the contents of the database off of a running server by exploiting a configuration vulnerability.
You should look through the Gruyere code looking for default configurations or debug features that don't belong there.

 Hint 1

 Hint 2

 Exploit and Fixes

Information disclosure #2

 Even after implementing the fix described above, an attacker can undo it and execute the attack! How can that be?

 Hint

 Exploit and Fixes

Information disclosure #3

 Even after implementing the fixes described above, a similar attack is still possible through a different attack vector. Can you find it?
This attack isn't a a configuration vulnerability, just bad code.

 Hint 1

 Hint 2

 Exploit and Fixes

AJAX vulnerabilities

Bad AJAX code allows attackers to modify parts of your application in ways that you might not expect. In traditional client development, there is a clear separation between the application and the data it displays. That's not true in web applications as the next two attacks will make clear.

DoS via AJAX

 Find an attack that prevents users from seeing their private snippets on the home page. (The attack should be triggered after clicking the refresh link and without using XSS.)

 Hint 1

 Hint 2

 Exploit and Fix

Phishing via AJAX

While the previous attack may seem like a minor inconvenience, careless DOM manipulation can lead to much more serious problems.
 Find a way to change the sign in link in the upper right corner to point to http://evil.example.com.
(The attack should be triggered after clicking the refresh link and without using XSS or a script.)

 Hint 1

 Hint 2

 Exploit and Fix

Other Vulnerabilities

Buffer Overflow and Integer Overflow

A buffer overflow vulnerability exists when an application does not properly guard its buffers and allow user data to write past the end of a buffer. This excess data can modify other variables, including pointers and function return addresses, leading to arbitrary code execution. Historically, buffer overflow vulnerabilities have been responsible for some of the most widespread internet attacks including SQL Slammer, Blaster and Code Red computer worms. The PS2, Xbox and Wii have all been hacked using buffer overflow exploits.
While not as well known, integer overflow vulnerabilities can be just as dangerous. Any time an integer computation silently returns an incorrect result, the application will operate incorrectly. In the best case, the application fails. In the worst case, there is a security bug. For example, if an application checks that length + 1 < limit then this will succeed if length is the largest positive integer value, which can then expose a buffer overflow vulnerability.
This codelab doesn't cover overflow vulnerabilities because Gruyere is written in Python, and therefore not vulnerable to typical buffer and integer overflow problems. Python won't allow you to read or write outside the bounds of an array and integers can't overflow. While C and C++ programs are most commonly known to expose these vulnerabilities, other languages are not immune. For example, while Java was designed to prevent buffer overflows, it silently ignores integer overflow.
Like all applications, Gruyere is vulnerable to platform vulnerabilities. That is, if there are security bugs in the platforms that Gruyere is built on top of, then those bugs would also apply to Gruyere. Gruyere's platform includes: the Python runtime system and libraries, AppEngine, the operating system that Gruyere runs on and the client side software (including the web browser) that users use to run Gruyere. While platform vulnerabilities are important, they are outside the scope of this codelab as you generally can't fix platform vulnerabilities by making changes to your application. Fixing platform vulnerabilities yourself is also not practical for many people, but you can mitigate your risks by making sure that you are diligent in applying security updates as they are released by platform vendors.

SQL Injection

Just as XSS vulnerabilities allow attackers to inject script into web pages, SQL injection vulnerabilities allow attackers to inject arbitarary scripts into SQL queries. When a SQL query is executed it can either read or write data, so an attacker can use SQL injection to read your entire database as well as overwrite it, as described in the classic Bobby Tables XKCD comic. If you use SQL, the most important advice is to avoid building queries by string concatenation: use API calls instead. This codelab doesn't cover SQL injection because Gruyere doesn't use SQL.

After the Codelab

We hope that you found this codelab instructive. If you want more practice, there are many more security bugs in Gruyere than the ones described above. You should attack your own application using what you've learned and write unit tests to verify that these bugs are not present and won't get introduced in the future. You should also consider using fuzz testing tools. For more information about security at Google, please visit our blog or our corporate security page. And check outGoogle Code University for more educational resources on a variety of other topics.
If you'd like to share this codelab with others, please consider tweeting or buzzing about it or posting one of these badges on your blog or personal page:

	xx<a href="http://google-gruyere.appspot.com/"> <img src="//google-gruyere.appspot.com/static/gruyere-badge.png" style="padding:4pt" border="0" alt="Learn how to make web apps more secure. Do the Gruyere codelab."></a> (Line breaks above should be copied verbatim.)
	<a href="http://google-gruyere.appspot.com/"> <img src="//google-gruyere.appspot.com/static/gruyere-40.png" style="padding:4pt" border="0" title="Learn how to make web apps more secure. Do the Gruyere codelab." alt="Learn how to make web apps more secure. Do the Gruyere codelab."></a> (Line breaks above should be copied verbatim.)