BEAT THE HACKERS AT THEIR OWN GAME.

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.).

Jarlsberg

This codelab is built around Jarlsberg /yärlz'·bərg/, a small, cheesy web application that allows its users to publish snippets of text and store assorted files. "Unfortunately," Jarlsberg 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 Jarlsberg 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 Jarlsberg. 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 Jarlsberg as if it's open source: you can read through the source code to try to find bugs. Jarlsberg 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 Jarlsberg 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 Jarlsberg source code.

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

Setup

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

The Jarlsberg source code is available online so that you can use it for white-box hacking. You can browse the source code at http://jarlsberg.appspot.com/code/ or download all the files from http://jarlsberg.appspot.com/jarlsberg-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 Jarlsberg 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 Jarlsberg 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://jarlsberg.appspot.com/resetbutton/123