Web Application Exploits and Defenses (Part 5)

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

Table of Contents

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 arbitrary 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 out Google 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:

Learn how to make web apps more
secure. Do the Gruyere codelab.
<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.)
Learn how to make web apps more
secure. Do the Gruyere codelab.
<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.)

© Google 2010 Terms of Service
The code portions of this codelab are licensed under the Creative Commons Attribution-No Derivative Works 3.0 United States license <http://creativecommons.org/licenses/by-nd/3.0/us>. Brief excerpts of the code may be used for educational or instructional purposes provided this notice is kept intact. Except as otherwise noted the remainder of this codelab is licensed under the Creative Commons Attribution 3.0 United States license <http://creativecommons.org/licenses/by/3.0/us>.