|
Defending Against Cross-Site Scripting Attacks.
|
|
|
|
|
Contributed by Chad Brandt
|
|
|
|
Monday, 13 September 2004
Most Web sites process dynamic content. They take user input from HTTP requests, process the request on the server and then give the user new content. The requests are processed using scripted code (JavaScript, VBScript or Perl, for example) and server components (including CGI, JSP, PHP, COM and ASP.Net). When the code runs on the server, it is converted to HTML and sent back to the user's browser.Because on-server script processing depends on user input, a malicious user
can try to inject code in an attempt to control the output. If the attacker
finds this is possible, he or she will know the Web site doesn't validate input
and is vulnerable to a cross-site scripting attack (referred to as XSS, to avoid
confusion with CSS, for cascading style sheets).
Through an XSS vulnerability, an attacker can inject malicious code. The XSS
attack is stored on the Web site and waits for its victim. A click of a link,
and a user browsing the site inadvertently executes the code. The malicious Web
application then unleashes the XSS attack against the user's browser. The user
thinks he is interacting with the trusted Web site while the malicious script
contacts the XSS attacker's site, sending it cookie and credential data, for
instance
Read Full Story Only registered users can write comments. Please login or register. Powered by AkoComment 1.0 beta 2! |