To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
Cross-site scripting attacks (abbreviated XSS so that we don't confuse them with cascading style sheets) are one of today's major attack vectors. These attacks exploit vulnerable Web sites that take input from a user and reflect the data right back at the browser. XSS attacks occur when a bad guy runs a malicious browser script inside of other users' browsers. The attacker can then steal cookies -- or even use a vulnerable ecommerce site -- to make the browser engage in transactions as if it were the victim's browser . In our penetration testing work at Intelguardians, approximately 80% of the Web applications we test have XSS flaws.
Enterprises can defend against XSS flaws by carefully filtering user input and output to remove the characters that are associated with scripts, including =<>'"();&. In the past, most organizations focused on controlling and filtering only the input. Certainly, that's a good idea. Still, an attacker could infiltrate an application via an unguarded input stream. Some enticing targets include magnetic stripes, Electronic Data Interchange feeds and paper-based postal mail that gets scanned in and converted via OCR. If Web applications start sending an attacker's malicious browser script, users are in jeopardy. To avoid this, filter the application output for malicious scripts as well. Of course, you should also filter for any legitimate browser scripts that are used and allow them to be sent to browsers. Certain data-pulling functions, however, should never have browser scripts. In these cases, filters should be applied before the final pages are composed and sent back to the browser.
More information:
Learn more about how to deal with cross-site scripting.
Prevent input validation attacks.
|
