WebGoat Lab session overview

Initial Setup
Virtual Machine
Tamper Data
Web Goat

Basics
HTTP Basics
Sniffing

Web server attacks

SQL Injection
XSS
INITIAL SETUP
Tamper Data
• Hold alt to reveal the menu in IceWeasel/Firefox.

• Tools > Tamper Data

• In order to perform a manipulated HTTP request, press “Start Tamper”, then perform an
action resulting in a request (clicking a button, link, etc.)

• You can also view the HTTP requests and responses in the ‘ongoing requests’ window.
Wireshark

• Wireshark can also be used to

analyze your HTTP traffic.
• Start Wireshark at command line as
superuser for live capture: sudo
wireshark
• Note: Running Wireshark as
superuser is fine for testing on a
virtual machine, but is not
recommended for real life use.
• Pick the interface “loopback”:
• Captures requests within localhost
(i.e. when both communicating
applications are on the same
machine, as in the local web
server and your browser)
 WEB GOAT – Start (1)
• Close the VM’s Internet Connection (your machine is
extremely vulnerable when WebGoat is running)

• Go to the folder containing the installation: ~/WebGoat

• Execute ./run_webgoat.sh file

 WEB GOAT - Start (2)
• Type the address http://localhost:8080/WebGoat/ in the browser

• Login as username = netsec and pwd = secnet

BASICS
HTTP BASICS
SNIFFING
HTTP Request/Response

• While browsing, every time an action is taken, a HTTP

Request is created
• The HTTP Request goes from the browser to the web
server
• The web server make some elaboration (e.g. verify if you
are a registered user) and send back a HTTP Response

HTTP Request

HTTP Response
HTTP Request

HTTP REQUEST

d
username an
password are
sent (most
!)
likely in clear!
over the
network.
They can be
intercepted
HTTP Response

The response
can be
nd
intercepted a
parameters
e
values can b
changed
HTTP Basics - Exercise

• Goal: meet WebGoat and TamperData.

• Exercise:
• Go to; exercise General à Http Basics
• Start Tamper Data or Wireshark
• Insert your name in the field, press “Go!”
• Inspect the HTTP request and response messages
• Try to locate your name in the message
HTTP Basics - Lesson learned

• When parameters are in clear (i.e. not encrypted)

they can be easily changed by who is listening your
internet traffic.
• In this case it was only your name
• But…
• Assume you want to make a payment of 800 Euro to the
account of your landlord and insert 12345 as the
account number
• The attacker can change such number to 34566 (his
account number)
• In this way he managed to steal 800 Euro from you
 Sniffing - Exercise

• Goal: Steal username and password of the user

• Exercise:
• Go to Insecure Communication à Insecure Login
• Press the button Log in and use Tamper Data to steal the password (or a
packet sniffer)
Sniffing - Lesson learned

• You performed your first sniffing attack

• You intercepted the traffic of your victim and stolen
his password
• If this is the same password he uses for his internet
banking (or email account) you can now easily
access it
• Encryption is necessary to prevent the outsiders
from eavesdropping.
 Parameter Tampering – Exercise

• Goal: change the total amount charged to your credit card

• Exercise:
• Go to Parameter Tamperingà Exploit Hidden Fields
• Purchase the TV for 1$

• Important note: first click Purchase without tampering, this will open another purchase page.
• Perform the tampering on this new page
Parameter Tampering – Solution
• Start Tampering Data then press the button
Purchase
• Change the parameter Price to the value 1.00$
• If successful you will get a Congratulations message
Lesson learned

• You used your recently learned “hacking” skills to

gain personal advantages
• You paid 1$ a product worth 3000$
• Why is that possible?
• The web server is not checking that you’re paying the
right amount of money
• An hacker who knows this vulnerability is able to
exploit it
WEB SERVER ATTACKS
SQL INJECTIONS
XSS
SQL injection by example

Client
internet

webserver

webapplication

database
• The WEBAPPLICATION presents a
form with username and password
• What happens in the database?
In the database…

Client
internet

webserver

webapplication

database
• SELECT … FROM users WHERE
username = ‘$username’ AND
password = ‘$password’
What happens if …

• Username: just any legal user name

• Password: anything' OR 'x'='x
• Recall the MySQL command is:
• SELECT … FROM users WHERE username =
‘$username’ AND password = ‘$password’
• It becomes:
• SELECT … FROM users WHERE username = ‘elisa’
AND password = ‘anything’ OR ‘x’=‘x’
• And it gets parsed the wrong way.
• Just to be clear: the above query selects all users, so
the reply is the list of all users, together with all the
parameters that are in the …
The goal of an SQL injection

• Have the database do

Client something that the
programmer didn’t think
internet

of.
• Particularly useful for
webserver data extrusion (stealing
of data like passwords).
webapplication • But it can also be used
for something else …
database • … like having the
database modify the data
it has.
• Let’s see an example
 SQL Injection – Stealing information

• Go to the exercise Injection FlawsàSQL Injection (lessons 7,8)

• Your goal is to retrieve all users from the user table using
string SQL injection and numeric SQL injection
• (optional) Check how your import is encoded using
TamperData or Wireshark
Solution

• String sql injection:

Smith’ or ‘1’=‘1

• Numerical sql injection

101 or 1=1

5/12/18
SQL Injection: Pulling Data from Other Tables

• Go to the exercise Injection

Flaws à SQL Injection
(advanced) lesson 3
• Your goal is join the
user_system_data table with the
get account info table and figure
out the password of Dave
• You can take a look at a cheat
sheet to see how to perform
union on two tables:
http://www.sql-tutorial.net/sql-
cheat-sheet.pdf
Solution

• Smith’ union select null, user_name, password, null,

null, null, null from user_system_data - -

• Password of Dave: dave

(or)

• Finding password without union

Smith’;select * from user_system_data where ‘1’=‘1

5/12/18
Lesson Learned

• An attacker can use SQL Injection to read and

modify data in a database
• An attacker could, for example, read the account
numbers of all the costumer of a bank

• Web servers should make input sanitations to avoid

SQL injection
• i.e. recognizing the user is inserting SQL or script
commands and not accept such string as input
• Take a look at the SQL injection prevention cheat sheet
https://www.owasp.org/index.php/SQL_Injection_Prevention_C
heat_Sheet
DENIAL OF SERVICE
Denial of Service

• Web servers have limited resources (bandwidth,

processing power, memory, storage, …)

• Eating up these resources can slow down or stop the

server from functioning, i.e. impair its availability.

• Here we look into Denial of Service attack on the

application-layer:
• We try to create more sessions in the server than it can
handle.
Denial of Service - Multiple Logins

• Go to Lessons -> Denial of Service

-> Denial of Service from Multiple
Logins

• The server’s database pool only

allows two logins.

• Create a total of 3 logins to

perform the attack

• Hint: Use SQL Injection to obtain a

list of username/passwords.
XSS – CROSS SITE SCRIPTING
XSS In a nutshell

• While with SQL injection the goal

Client was to hack the DB …
• … now the goal is to hack the
internet

client of your victim …

• … for instance by storing
webserver something in the webserver …
• … that will trigger something in
webapplication your victim’s client when he will
look at the page you tampered
database with.
• … let’s see an example.
/ name of department 12-05-18 PAGE 34
 XSS in WebGoat

• Go to the exercise Cross Site Scripting (XSS)àEx 2

• You have to check, using javascript, the cookies of the Webgoat
webpage
Notice that

• Tom Cat can view his own profile, and he cannot see
the profiles of his colleagues.
• On the other hand, David and Jerry can see the
profiles of a few people.
• In particular Jerry can see Tom’s profile.
• Now, Tom can try to attack Jerry by storing
something a “kind of virus” on his profile.
• In the moment Jerry will look at Tom’s profile, he will
be infected.
Solution

• Open WebGoat in two different tabs and type

• javascript:alert(document.cookie);
• On both tabs the output should look something like this:

• The cookies are the same in every tab

 Reflected XSS in WebGoat

• Go to the exercise 7
• You have to find out which of the fields is susceptible to javascript and
insert the suggested script.
• Forge an URL that contains such script.
Hint

• Inspect the Webpage source code to investigate the property of

the fields
• Use your Tamper Data tool to help you forge the URL
Solution

• The field is “field1” (Credit Card Number):

• 4128 3214 0002 1999<script>alert(‘my javascript here’)</script>

• The URL is:

• http://localhost:8080/WebGoat/CrossSiteScripting/attack5a?QTY1=1
&QTY2=1&QTY3=1&QTY4=1&field1=4128+3214+0002+1999<script>a
lert(‘my javascript here’)</script>&field2=111
 DOM-Based XSS in WebGoat

• Go to the exercise 10 and 11

• Your goal is to find the ‘test route’ of WebGoat.
• Discover the return value of the javascript function
“webgoat.customjs.phoneHome()”
Hints

• Try to locate the javascript GoatRouter.js

• Using the Debugger (Tool -> Web Developer-> Debugger)

should help

• Check the UTF-8 encoding for /

Solution (Ex 10)

• The “Test Route” is:

− start.mvc#test/

• TheWebGoat test route allows to execute command:

• Try typing:
− http://localhost:8080/WebGoat/start.mvc#test/WebGoat_is_fun
Solution (Ex 11)

• The javascript function webgoat.customjs.phoneHome() returns a

random value on the console:

• Correct solution:

• Oh well too bad, let’s just use a packet sniffer J

 Stored XSS in WebGoat

• Go to the exercise 13
• Your goal is to write a comment that calls the javascript function
webgoat.customjs.phoneHome()
Solution

• Write as comment:
• <script>webgoat.customjs.phoneHome()</script>

• Obtaining the return value of webgoat.customjs.phoneHome()

is just the same as Ex 11

• Caution: It is a STORED XSS: The function will be executed

everytime you load the page
Solution (2)

• Now login as Jerry Mouse (password: moe)

• Select Tom Cat and view his profile
• At this point you should see the alert message,
result of the script
Lesson Learned

• As well as for SQL injection, XSS attack are possible

if no input sanitation takes place
• The application should have checked that the street
you inserted was not a legal street name.
• In other words, the application should have sanitized
your input. But it failed to do so.
• Your input was a script in javascript, and when a
user looked at the page, the user’s browser happily
executed the script.
• That script could have done much more harm than
just laughing.
• Could have stolen some information (cookies)
• Could have executed code at the client side
 XSS recap
• Basic idea:
• force the browser to execute a script which has been “injected”
in a web page/application
• Important: malicious code is executed at the client side
• There are two flavors
• Persistent [Stored] (requiring the storage of the script in the
webapplication)
• Non-persistent [Reflected and DOM-Based] (in which the script is
generated on-the-fly)
• #2 problem in the OWASP Top 10 Web Application Security Risks
for 2010 (just under injections). See www.owasp.org
• XSS is one of the most “nasty” vulnerabilities
• Sometimes considered erroneously non-critical due to
(presumed) lower impact compared to SQL Injection
ADDITIONAL EXERCISES
Authentication Flaws; weak passwords

• Go to the exercise Authentication Flawsà Password Strength

• There are 5 password with different security level (some are
much easier to guess than others)
• Use the tool available at
https://www.howsecureismypassword.net to see how much
time an hacker needs to guess such passwords
Lesson learned

• You learned that easy passwords are extremely easy

to guess
• less than a second for the password 123456
• Therefore, they should not be used
• neither accepted by web applications
• It would be ideally to use passwords that have low
and upper case characters, at least one number and
one special symbol
• These kind of password can better resist to brute force
attacks
Blind SQL Injection

• Injection Flaws > Blind

String SQL Injection
• The web form contains a
field that returns a
True/False value.
• Try to find out the name of
a credit card account
holder by injecting SQL
statements.
Blind SQL Injection

• Hint: Check out the SQL

function SUBSTRING.
• SUBSTRING(‘abc’,1,1) would
return ‘a’
• Hint II: Characters can be
compared like numbers, .i.e.
‘a’ > ‘z’ would return FALSE
• Hint III: A FALSE return value
would be represented with the
string “Account number is not
valid”.
• Hint IV: A SELECT statement
can be used to return a string
 Blind SQL - Solution
• Try inputs such as:
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number‘4321432143214321’), 1, 1) <= ‘Z’);
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number‘4321432143214321’), 1, 1) <= ‘a’);
− Gives a clue about the first character. They are
valid letters.
• Try the same input with other characters, ‘a’, ‘h’, ‘H’, etc.
and ‘>’ to pinpoint the first character:
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number=‘4321432143214321’), 1, 1) = ‘J’);
returns True, ‘J’ is the first character of the
name.
• Try for the second character: …
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number=‘4321432143214321’), 2, 1) <‘h’);

• Try with the 3rd, 4th letter etc. until it returns false for
the range a-Z.

Ø Lesson learned: having a

vulnerability that leaks a single bit of
information can be sufficient for an
attacker to steal sensitive data.
 Blind SQL - Solution
• Try inputs such as:
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number‘4321432143214321’), 1, 1) <= ‘Z’);
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number‘4321432143214321’), 1, 1) <= ‘a’);
− Gives a clue about the first character. They are
valid letters.
• Try the same input with other characters, ‘a’, ‘h’, ‘H’, etc.
and ‘>’ to pinpoint the first character:
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number=‘4321432143214321’), 1, 1) = ‘J’);
returns True, ‘J’ is the first character of the
name.
• Try for the second character: …
• 101 AND (SUBSTRING((SELECT name FROM pins
WHERE cc_number=‘4321432143214321’), 2, 1) <‘h’);

• Try with the 3rd, 4th letter etc. until it returns false for
the range a-Z.

Ø Lesson learned: having a

Ø Answer: The name is ‘Jill’
vulnerability that leaks a single bit of
information can be sufficient for an
attacker to steal sensitive data.
Session Fixation

• Go to Lessons -> Session Management Flaws-> Session

Fixation
• Exercise:
• You are Hacker Joe
• You want to pretend to be Jane, when communicating to Jane’s
bank.
• To do so, you want to steal Jane’s session in the moment that Jane
is logged in the bank.
• To do so, you need to know what is the session identifier (SID) of
Janes’ session when she talks to the bank.
• That’s the difficult thing
• One way of getting to know what is Jane’s SID, is to induce her to
start a session with the bank using the session identifier you want.
• This may be less difficult than you think
• ‘WebGoat’ is not the same as ‘webgoat’, change the URL in the
email accordingly
 Session Fixation - Exercise

• Goal: steal Jane’s credit card information.

 Session Fixation in practice

• Stage 1 (Hacker Joe)

• Write an email to Jane, in which you try to convince her to click on
the link you have made:
• ….. <a href=/WebGoat/attack?... &SID=1234567>
• Stage 2 (Jane)
• By reading the email and clicking on the link, Jane will be redirected
to the bank, starting a session with the SID you have determined!
• Stage 3 (Jane)
• If Jane logs in the bank with her username and password, then the
session becomes active
• Stage 4 (Hacker Joe)
• Hacker Joe can now simply connect to the bank using the SID
1234567.
• The bank server will “think” that it is talking to Jane.
Lesson Learned

• You learned how to carry on a (very basic) “phishing

attack” and to use it to steal a session
• This happens because the bank accepts in a silly
way the token to be fixated by the user
• The bank should fix her own token….