Java程序辅导

Secure Programming Lab 3: Web app security
School of Informatics, University of Edinburgh
2pm-5.30pm, 7th March 2014
For this lab we are going to explore web app security vulnerabilities. To do this we are going to use a vulnerable
web app called Gruyere from Google’s Code University1. We are going to focus on a few specific vulnerabilities
but the app contains more bugs than we can cover in this lab. If you are interested you should go try the full
lab available from Google.
The code is available from http://www.inf.ed.ac.uk/teaching/courses/sp/2013/labs/lab3/gruyere-code.zip.
It can be downloaded and run on your own machine. Once downloaded, unzip it (unzip gruyere-code
-d gruyere && cd gruyere) and run python ./gruyere.py in the folder to start the app. It will give
you a URL to visit and a session id for the instance you have spun up. The URL will be of the form
http://127.0.0.1:8008/1234/ where 1234 is your session id. Follow this URL to start Gruyere.
Code for the web pages is written in the Gruyere Template Language. This is a template web programming
language created by Google for the lab and the details of it can be found by reading the source code in gtl.py
(though this isn’t really necessary for this lab). An overview of the other files is bellow
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; as well as any user uploads.
Resetting Gruyere
Gruyere is sand-boxed (somewhat) so it can’t be interfered with or consume all your resources; that said it
is possible (and in fact encouraged) to put it in a state where you need to reset everything and start from
scratch. If this occurs delete the folder containing Gruyere and replace it with a fresh copy from the zip file.
1https://google-gruyere.appspot.com
1
Question 1: Logging in
Try signing up for a new account using the Sign up link in the top right. Look at how it passes the parameters
for the new account. We will leverage this, with other vulnerabilities, to create a new administrator account.
Checkpoint 1. Consider the case where an attacker is listening to network traffic. What is the danger with
the account creation method?
Checkpoint 2. Create another new account but this time do it without using the Sign up form.
Once done login, and navigate to your Profile. This page allows you to edit your account’s settings but
administrators have a few more controls open to them. The code used to generate the page can be found in
resources/editprofile.gtl.
Checkpoint 3. How does the code in editprofile.gtl distinguish between admin users and regular users?
Can we use this information to either turn our unprivileged account into an admin one or create a new admin
account?
Checkpoint 4. To create our admin account we used information we got from the source code. In a real web
app an attacker may not be able to do this. Is it likely that an attacker could figure this out how to do this
without the source code?
Checkpoint 5. Describe how this bug should be fixed.
Question 2: Viewing and uploading
Part 1: Viewing
Log into an unprivileged account again. This time we’re going to try and read and then modify one of the
source files: in particular we’re going to aim to read the secret.txt file in the source’s root directory. Relative
to the other source files this lives at ../secret.txt.
Try using the browser to navigate to http://localhost:8008/1234/../secret.txt (where 1234 is your session
number). On most2 browsers this will cause gruyere.py to crash. The gruyere.py script used to start the
lab displays the requests it receives as its output. Look at this and note the URL requested before the program
crashed.
Checkpoint 1. Why does the requested URL differ from the one you typed in? Who made the change?
Checkpoint 2. Use netcat (nc) to explicitly craft a request for the file using the correct URL. It should work
this time and you should be able to see the file’s contents. Why does it work now? (N.B. this could also be
done using curl or even the w3m browser but if you’ve never hand-written a HTTP GET request it is a useful
experience.)
Checkpoint 3. Describe how this problem should be fixed.
Part 2: Uploading
Sign in as an unprivileged user again. This time click the Upload link. This allows a user to upload and host
a file. We’re going to abuse this to allow us to overwrite the secret.txt file (and in fact any file we want).
Try uploading a file now.
2Safari, Firefox, Google Chrome, Opera.
2
Checkpoint 1. Open the resources folder inside gruyere and have a look at where the file was uploaded
to. Suppose a user  tried to upload a file : where would it be placed?
Checkpoint 2. Using what you know about the location of uploaded files overwrite the secret.txt file with
something new. Verify your upload worked.
Suppose that we can’t create new user accounts3. We can still exploit the upload dialog by uploading a file
with an unusual name. You won’t be able to do this with a regular web browser but you can do this with the
curl command: have a look at the man page for curl, specifically the options -d and -F.
Checkpoint 3. Describe how to overwrite the secret.txt file just by uploading a file with an unusual name.
Why won’t this attack work using a regular web browser?
Checkpoint 4. Describe how this problem should be fixed.
Question 3: Crashing and running
In this section we’re going to show how anyone can stop the Gruyere app and also how we can change it
to run whatever we want. This question will need you to use your solutions from both previous
questions! This question is harder than previous questions and there is less guidance: make sure you have
understood them before attempting.
Part 1: Crashing
Sign in as an administrator, and follow the Manage this server link. Examine what the Quit the server
button does. Sign out and try and Quit the server as an unprivileged or unlogged in user.
Checkpoint 1. Why can an unprivileged user quit the server like this? How should this be prevented?
An alternative way to crash the server is to overload it to the point it becomes unresponsive. This is called a
denial of service attack. To do this an attacker either floods the server with requests or causes it to do an
excessive amount of processing.
Checkpoint 2. Every page on the server includes the menubar.gtl file. Can you alter this file to cause a
denial of service?
After completing this checkpoint you will need to reset Gruyere!
Part 2: Running
The web app uses a Python script (gtl.py) to expand the variables and parameters in the *.gtl files.
Checkpoint 1. Why does the gtl.py script make a more lucrative target than the webapp itself (which is
stored in gruyere.py).
Checkpoint 2. Gain arbitrary code execution by inserting a backdoor (for example a reverse shell) gtl.py.
To do this you should assume you have access to the gtl.py file
Checkpoint 3. Describe how this problem should be fixed.
3This is a hint for the first checkpoint.
3
Question 4: Tools
In this final question we are going to move away from Gruyere and look at how tools can help find web security
vulnerabilities before they are exploited.
Web apps are a nice target for attackers because they are designed to be network accessible. Despite the very
real security thread it is very easy to find people writing exploitable code.
Checkpoint 1. Search Github for PHP code containing the words sudo, exec and $_GET. Pick one example
and explain why it is dangerous. Why do you think this kind of vulnerability is so common?
As we have seen in the other labs static analysis tools can be used to help find these vulnerabilities for you.
We are going to return to the findbugs tool we have seen previously and look at the find-sec-bugs plugin
which adds additional security checks to the tool.
Download the standard distribution of the findbugs tool from http://findbugs.sourceforge.net/downloads.html,
and the Find Security Bugs plugin from https://h3xstream.github.io/find-sec-bugs/. Once extracted you can
start the findbugs GUI by running bin/findbugs. Install the plugin by going through Edit → Preferences →
Plugins → Install new plugin and pointing it to the *.jar file you downloaded.
We’re giving you two example bits of code (taken from find-sec-bugs testcases) to analyze with the tool:
• GetRSAKey.java generates a new RSA key for a user.
• XSSRequestWrapper.java is a J2EE servlet wrapper that aims to prevent cross-site scripting.
Download the examples from http://www.inf.ed.ac.uk/teaching/courses/sp/2013/labs/lab3/examples.zip and
run findbugs on them.
Checkpoint 2. What is the problem with GetRSAKey.java? Why is this potentially dangerous? How should
it be fixed?
Checkpoint 3. Why does find-bugs complain about how you are trying to prevent cross-site-scripting?
How should you fix this?
Submission Instructions
Download a copy of the text file checkpoints.md from http://www.inf.ed.ac.uk/teaching/courses/sp/2013/
labs/lab3/checkpoints.md and edit it to insert your answers. Submit it with the command:
submit sp lab3 checkpoints.md
We will give some feedback about the submissions on Piazza.
Joseph Hallett and David Aspinall, March 2014.
4