A Codelab by Bruce Leban, Mugdha Bendre, and Parisa Tabriz
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
data.py you know that
there's a default administrator account named 'admin' with the
'secret'. See http://www.governmentsecurity.org/
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.
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.
Even after implementing the fix described above, an attacker can undo it and execute the attack! How can that be?
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.
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.)
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
(The attack should be triggered after clicking the refresh link and without using XSS or a script.)
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
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.
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.
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:
<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.)
© 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>.