Got a tip? Let us know

                 


OWASP top 10 by Example: XSS exploits

July 09,2019 0 comments

The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain secure applications and APIs.The community periodically publishes The OWASP Top 10,  which is a powerful awareness document for web application security. The document represents a broad consensus about the most critical security risks to web applications. Cross-Site Scripting (XSS) attacks are the second most prevalent issue in the OWASP top 10 (after injection attacks), and it’s found in two-thirds of all applications.

What is Cross-Site Scripting?

There is a saying among web developers that goes, “never trust the user.” Any source of data input from a user, be it a signup/login form, a comment field or a normal URI,  must never be trusted by the developer. When a user exploits such fields by pouring in malicious code, and without any sanitizations or validations by the application, the code is used to generate an output making a web application vulnerable to XSS attacks. The aftermath of the attack is very daunting and repercussions include website defacement (when an ‘ugly’ message is permanently displayed on your website), session hijacking through cookie stealing (these lead to account takeovers), database deletion through stored XSS attacks, MFA bypass, DOM node replacement or defacement (such as trojan login panels), malicious software downloads, keylogging and other client-side attacks.

XSS attack diagram

XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user. The actual attack occurs when the victim visits the webpage that executes the malicious script. 

Categories of XSS attacks

There are three forms of XSS attacks namely reflected, stored, and DOM.

Reflected XSS: 

Occurs when a web application includes unvalidated and unescaped (or simply unsanitized) user input as part of HTML output. Usually,  the user will need to interact with some malicious link that points to an attacker-controlled page.

Stored XSS: 

The application or API stores unsanitized user input in the database that is viewed at a later time by another user or an administrator. This is a persistent threat and is often considered a critical risk for it may continue for a very long time without notice.

DOM XSS:

 JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

Environment setup

  • You’ll need a local webserver downloaded and installed. You could use XAMPP.
  • A text editor of choice. I prefer SublimeText.
  • PHP basics
  • Download the zipped source file. Instructions on how to set up the database are included in the README.txt file.

XSS in Action

Vulnerable search form

An easy way to know if your application is vulnerable to XSS attacks is by testing if it’s very easy to deface. Temporary website defacement is done by typing malicious input and seeing how the input affects your web layout. It’s only effective if the input is reflected in the output without sanitization.  Below we will create a vulnerable search form. The complete code and setup is included in the zipped file as “searchform.php”

1. Assumption: You have already set up your local environment and created the databases using the SQL file provided.

2. Create a php file in your text editor named “connect_db.php”. It is for establishing a connection to the database and update it with the code below:

 

$servername = "localhost";
$username = "root";
$password = "";
$dbname = "xss";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn->connect_error) {
	die("Connection failed: " . $conn->connect_error);
}

3. Create another file named “searchform.php” and copy-paste the following code into it.

5. With everything set up correctly, if you visit http://localhost/xss/searchform.php, you should see the form as displayed below.

Exploit

After that, try searching for the legit queries like “kenya”, “book”, “oludhe”, “gikuyu” in order. Do not include double-quotes.

  • “<!-- “. This query will comment out everything after the text ‘search results for “ ‘
  • “<marquee>”. This query will deface the rest of the page to scroll from right to left. It is an unintended behavior by the web developer
  • “<h1”> this text will be a h1 text </h1>”.
  • “<script>alert(‘Hacked by BAT.CMD’)</script>”. If this executes in web application then it’s very vulnerable to XSS attacks.

Stored XSS example: Vulnerable signup form

A hacker may use a signup form to enter malicious code as their credentials. Say a form has email, username, and password fields, one can craft a script code and then enter it as the username. Since the form inputs are not validated properly during the processing, the malicious data is then stored in the database. If the data is displayed on a page where it can be accessed by the public, then the malicious code will be repeatedly executed every time. The form below doesn’t sanitize the user’s input as required.

 

The form should display as below:

exploit

When you sign up with valid credentials, your record will be added to the database and then your name shall be displayed on the right pane. When you attempt to use “<script>alert(12345)</script>” as your username, it will be successfully added to the database. When it gets displayed, however, your browser will execute it a javascript code. Although benign, when crafted carefully, one can store a cookie stealing code say through a forum comment field. Every time a user visits the comment page, their cookie is stolen and sent to the hacker's website who can then use the cookie to login and pretend to be the user. With this, they can change the password and lock you out of your own account. Cookie stealing will be discussed in a future article.

Award-winning XSS attack: Via image

Images exist on almost all web applications. They come in various formats e.g jpg, jpeg, png, gif, svg e.t.c. Generally, a hacker will hide a malicious link in an image so that when clicked, the victim is redirected to the malicious link. SVG images, however, expose more than meets the eye. Scalable Vector Graphics (SVG) is an XML-based markup language for describing two-dimensional based vector graphics. Since it uses XML to construct the image, JavaScript statements are also evaluated as valid constructs. The code below creates a basic rectangle with an inscribed circle upon which is written “SVG”.

One can literally append a script tag within the SVG tags to create an XSS attack. Append the code below and then save the file with the “svg” extension, and then open the image in a browser to see the script being executed within the image.

<script> alert("This is a hack through an SVG image")</script>

You can write any valid javascript code within the image. Assuming you craft an SVG image with a cookie stealing script and then use the image as your profile picture on a social media platform, anyone that views your profile pic has their cookie stolen. 

XSS attacks mitigations

To begin with, one should consider using secure frameworks that have means of evading XSS attacks. Frameworks such as Ruby on Rails, Laravel, Django, Codeigniter and many more have functions designed for user input sanitization and XSS attack mitigators. If you decide to stick to core PHP then at least consider reading the official documentation on how you can mitigate such attacks. PHP comes with many methods for form validation and sanitization.OWASP documentation on XSS also provides a nice guide on how to test if your application is vulnerable to XSS. It also provides a cheat sheet for XSS prevention

Conclusion

It was simply out of curiosity that my interest in XSS attacks was sparked. About a year ago, I decided to find out which bank in my local country offered the best online banking solutions. So I googled the top five. I surfed through web pages for each bank and played with their search forms to see just how well-stocked their knowledge bases are. One of the search forms was so beautifully designed that I stayed on that search form for too long just admiring how they formatted their output. I then decided to type <marquee> and wahlah! The beautiful thing just gave in like that...it scrolled from right to left. I played with it further and soon started crafting my own styles into the search query. The application simply couldn’t ‘resist’ these and it spewed back the results as I commanded it to. Then It dawned on me that it was an online bank web application. Surely!! 



Michael Jaroya

He is a technology enthusiast, a writer, and motivator.An individual with the love for humanity..


More in this category: Arduino as an ISP for AVR Microcontrollers (Atmega32) ยป


Comments

Add Comment