-->

Sunday, 22 July 2018

What Is XSS(Cross Site Scripting) With Example



XSS also known as Cross-Site Scripting. It is a most common vulnerability in web applications. An attacker can inject malicious code into the web and when a user visits that page, the code is executed. If an attacker is able to inject malicious code into a webpage and whenever a user visits the specially crafted link, the code gets executed. An attacker can perform phishing attacks, Steal accounts and cookies of a user session.

Cross-Site Scripting occurs due to two following reasons:

  1. When the data in the web application enters through an untrusted source, like web requests.
  2. When the data is entered in the web content and is sent to a web user without validation.
  3. The malicious code loaded in a web browser is often in the form of JavaScript, or maybe in the form of HTML and Flash.


Stored and Reflected XSS Attacks


Here are the two types of XSS attacks known as Stored and Reflected. The other one is known as DOM-based XSS attack that we are going to discuss.

Stored XSS Attack


When an attacker injects malicious code into a web page that gets stored permanently. This type of attack is called Stored XSS Attack. Malicious code could be stored In a database, message forum, comment field or in a visitor log. Whenever a victim visits that page, the code is executed automatically. This type of attack is also known as Persistent XSS.

Reflected or Non-Persistent


Reflected XSS attack is a type of attack that is reflected off the web server when the malicious code is injected in a page, such as in search results, in an error message or maybe in another form of input that is sent to the server as a request. Reflected attacks are sent to victims through email messages, or by some other sites. If a user gets tricked into clicking the malicious code, containing a specially crafted form, or maybe browsing to a malicious site, the code redirects the user to a vulnerable site and then reflects the attack back to the user’s browser.

Dom-Based XSS Attacks


The other one attack is DOM Based XSS attack which was found by  Amit Klein in 2005.  It is a type of attack where the tainted data flow from source to sink takes places in the browser. It means that the source data and sink is also in the DOM, that the data flow never leaves the browser.
Now Let’s Look at an example of cross-site scripting:
First Of all, we will look at the example of Stored XSS attack. I will be going to perform this attack on BWAPP.

So let’s open up the Mozilla browser and locate to

 http://localhost/BWAPP_Location


Now Select XSS(Stored) and put the following malicious code and see the magic.


  1.  First Name: Test
  2. Last Name: <script>alert("This is a XSS Exploit Test")</script>
  3. Click Go.
And Here is the result, you can see that XSS pops up. Because the request is not validated properly and this could cause your data to be stolen.


Now Let’s look for the second type of attack that is Stored XSS attack.

 After clicking the submit button you can see the result in the following screenshot. The malicious code is stored on the web. Whenever a user visits the site, he will be prompted with the XSS popup.



How To Determine If Your Web App Is Vulnerable To XSS Attacks


It is difficult to identify XSS vulnerability in web apps. You can do the best is to perform a security review of the code of your search places where the input is supplied through HTTP requests. A variety of HTML and Javascript codes could be used to perform XSS attacks on a web app. You can use Nikto, Nesses and some of the latest tools available on the internet to check for the possible XSS flaws in your web app.

How To Protect Against XSS(Cross Site Scripting)


Here are the primary defenses against Cross Site Scripting in the OWASP XSS Prevention Cheat Sheet.
It's really clamorous that you turn off HTTP TRACE support on all web servers. An attacker can steal cookies even if document.cookie is disabled or not supported by the client with the help of javascript.
This attack is executed when a user posts a malicious code into a forum. When a user clicks the link, an asynchronous HTTP Trace call is triggered which collects the cookie information of the user from the server and sends it to the malicious server that collects the information so the attacker can perform session hijack attack. You can temper it by turning off support for TRACE on the web server.

Alternate XSS Syntax


XSS by using Script in attributes:

An attacker can perform XSS attack without using <Script></Script> tags. For Example:


<body onload=alert('test1')>


or other attributes like: onmouseover, onerror.
onmouseover

<b onmouseover=alert('Yoooo')>click me!</b>  

Onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>


XSS using Script Via Encoded URI Schemes

An attacker can encode string character in UTF-8 form and use it in IMG tag:

<IMG SRC=j&#X41vascript:alert('test2')>

Many other encoding schemes are available that an attacker can use to encode characters in a different form.

XSS using code encoding


An attacker can encode script into base64 and put it in META Tag

<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">
















adcodehere

NEXT ARTICLE Next Post
PREVIOUS ARTICLE Previous Post
NEXT ARTICLE Next Post
PREVIOUS ARTICLE Previous Post
 

Delivered by FeedBurner