Cross Site Scripting
A Web application vulnerable to XSS allows a user without knowledge to send malicious data to them self through that application.
Attackers often perform XSS exploitation by making malicious URLs and tricking into clicking on them.
These links cause client side scripting languages like VBScript, JavaScript of the attackers choice to execute on the victim's browser.
XSS vulnerabilities are caused by a failure in the web application to properly validate user input.
The simplest description of cross-site scripting can be put as the attack that occurs when a user enters malicious data in a Web site. It can be as simple as posting a message that contains malicious code to a newsgroup. When another person views this message, the browser will interpret the code and execute it, often giving the attacker control of the system. Malicious scripts can also be executed automatically based on certain events, such as when a picture loads. CSS doesn't apply to any single vendor's products, instead, it can affect any software that runs on a web server.
CSS takes place as a result of the failure of the web based application to validate user supplied input, before returning it to the client system. "Cross-Site" refers to the security restrictions that the client browser usually places on data like cookies, dynamic content attributes associated with a web site. This causes the victim's browser to execute malicious code with the same permissions as the domain of the web application, an attacker can bypass the traditional document object model (DOM) security restrictions. The document object model is accessible application interface that allows client-side languages to dynamically access and modify the content, structure and style of a web page.
Cross-Site Scripting (CSS) attacks require the execution of Client-Side Languages (JavaScript, Java, VBScript, ActiveX, Flash) within a user's web environment. Cross Site Scripting can result in an attacker stealing cookies, hijacking sessions, changing of web application account settings and more. The most common web components that are vulnerable to CSS attacks include CGI scripts, search engines, interactive bulletin boards (Forums), and custom error pages with poorly written input validation routines. Also victim does need to click on a link to make the attack happen.
(Attack Example)
Example 1: The IMG tag
http://host/search/search.cgi?query=
Depending on the website setup, this generates html with the image from host2 and feeds it to the user when they click on this link. Depending on the original web page layout it may be possible to entice a user into thinking this is a valid part of the picture.
Example 2:
http://host/something.php?q=
If a user clicks on this link a JavaScript popup box displaying the site's domain name will appear. While this example isn't harmful, an attacker could create a fake form or, perhaps create something that grabs information from the user. The request above is easily questionable to a standard user but with hex, unicode, or %u windows encoding a user could be fooled into thinking this is a valid site link.
Example 3:
http://host/Inserthere
A Web application vulnerable to XSS allows a user without knowledge to send malicious data to them self through that application.
Attackers often perform XSS exploitation by making malicious URLs and tricking into clicking on them.
These links cause client side scripting languages like VBScript, JavaScript of the attackers choice to execute on the victim's browser.
XSS vulnerabilities are caused by a failure in the web application to properly validate user input.
The simplest description of cross-site scripting can be put as the attack that occurs when a user enters malicious data in a Web site. It can be as simple as posting a message that contains malicious code to a newsgroup. When another person views this message, the browser will interpret the code and execute it, often giving the attacker control of the system. Malicious scripts can also be executed automatically based on certain events, such as when a picture loads. CSS doesn't apply to any single vendor's products, instead, it can affect any software that runs on a web server.
CSS takes place as a result of the failure of the web based application to validate user supplied input, before returning it to the client system. "Cross-Site" refers to the security restrictions that the client browser usually places on data like cookies, dynamic content attributes associated with a web site. This causes the victim's browser to execute malicious code with the same permissions as the domain of the web application, an attacker can bypass the traditional document object model (DOM) security restrictions. The document object model is accessible application interface that allows client-side languages to dynamically access and modify the content, structure and style of a web page.
Cross-Site Scripting (CSS) attacks require the execution of Client-Side Languages (JavaScript, Java, VBScript, ActiveX, Flash) within a user's web environment. Cross Site Scripting can result in an attacker stealing cookies, hijacking sessions, changing of web application account settings and more. The most common web components that are vulnerable to CSS attacks include CGI scripts, search engines, interactive bulletin boards (Forums), and custom error pages with poorly written input validation routines. Also victim does need to click on a link to make the attack happen.
(Attack Example)
Example 1: The IMG tag
http://host/search/search.cgi?query=
Depending on the website setup, this generates html with the image from host2 and feeds it to the user when they click on this link. Depending on the original web page layout it may be possible to entice a user into thinking this is a valid part of the picture.
Example 2:
http://host/something.php?q=
If a user clicks on this link a JavaScript popup box displaying the site's domain name will appear. While this example isn't harmful, an attacker could create a fake form or, perhaps create something that grabs information from the user. The request above is easily questionable to a standard user but with hex, unicode, or %u windows encoding a user could be fooled into thinking this is a valid site link.
Example 3:
http://host/Inserthere
No comments:
Post a Comment