Prevent cross-site scripting hacks with tools, testing

In this tutorial, learn how to prevent cross-site scripting (XSS) attacks, how to avoid a hack, and how to fix vulnerabilities and issues with cross-site scripting prevention tools, system and application testing and several other defense and prevention methods and mechanisms.

Cross-site scripting (XSS) attacks are one of today's major attack vectors, exploiting vulnerable websites and using browsers to steal cookies or engage in financial transactions. Cross-site scripting flaws are common, and require organizations to implement a thorough secure development lifecycle that includes threat modeling, scanning tools and extensive security awareness to achieve best possible posture of XSS protection and prevention....

This article explains how cross-site scripting attacks work and offers advice on how to prevent them from attacking enterprise Web applications.

Cross-site scripting explained: How do XSS attacks work?
Cross-site scripting (XSS) allows attackers to send malicious code to another user by exploiting a flaw or weakness in an Internet server. Attackers use cross-site scripting (XSS) exploits to inject malicious coding into a link that seems to be trustworthy. When a user clicks on the link, the embedded programming is submitted and will execute on the user's computer, which grants a hacker access to steal sensitive data; attackers use XSS to exploit vulnerabilities on a victim's machine and traffic malicious code rather than attacking the system itself.

Attackers are able to alter the HTML that controls the page by using Web forms that return error messages with user-input data. A hacker can insert code into a link in a spam message or use email spoofing in order to trick the user into thinking he or she is a legitimate, trustworthy source.

For example, an attacker could send a victim an email message with a URL that points to a website and provides it with a browser script as input, or post a malicious URL on a blog or social networking site such as Facebook or Twitter. When a user clicks the link, the malicious site, as well as the script, runs in his or her browser. The browser doesn't know the script is malicious, and blindly runs the program, which in turn allows the attacker's browser script to access the site's functionality to steal cookies or complete transactions posing as the legitimate user.

For more information:
Expert Kevin Beaver sheds light on the history of cross-site scripting (XSS) issues and how to find XSS flaws.

In this expert Q&A, John Strand explains which application development best practices can stop cross-site scripting attacks.

How to protect websites against cross-site scripting attacks?
Some general cross-site scripting prevention best practices include testing application code before deployment and patching flaws and vulnerabilities in a quick and concise manner. Web developers should filter user input to remove possible malicious characters and browser scripts and install user-input-filtering code to remove malicious characters. Administrators can also configure browsers to only accept scripts from trusted sites or disable browser scripting in general, although doing so can result in a website with limited functionality.

As time marches on, hackers are only becoming more advanced, using a collection of toolkits to speed up the vulnerability exploitation process. This means simply deploying these general XSS prevention practices simply isn't enough anymore; the protection and prevention process must start from the ground level and move upward. The prevention process must begin during development; Web applications that are built using a solid secure development lifecycle methodology are less likely to exhibit vulnerabilities in the release version, which will improve not only security, but also usability and total cost of ownership, since fixing a problem in the live environment is more expensive than doing so during development.

Threat modeling is an important aspect of XSS prevention that should be incorporated in every organization's secure development lifecycle. Threat modeling evaluates and identifies all the risks to an application during the design stage to help Web developers better understand what kind of protections are necessary and how a successful attack of that application would affect the organization. To identify the threat level to a particular application, it is important to consider its assets, as well as how much sensitive information it accesses. Going through this threat-modeling process will ensure security is strategically incorporated in the application's design and development process and increase Web developers' security awareness.

Source-code-scanning tools and Web application-vulnerability scanners are always an option to increase efficiency and reduce the workload of the Web developers for large projects. Web vulnerability scanners can identify common flaws and vulnerabilities – SQL injection, cross-site scripting, buffer overflows – but custom application code must still be reviewed manually.


WEB APPLICATION ATTACK SECURITY

  Introduction: Web application security
  How to stop buffer-overflow attacks
  Prevent cross-site scripting hacks
  Stopping SQL injection hack attacks
  Distributed denial-of-service protection


This was first published in January 2010

Dig deeper on Application Attacks (Buffer Overflows, Cross-Site Scripting)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close