If you search the web, there are many different ways to define a cross site scripting attack. Simply put, XSS vulnerabilities occur when a malicious attacker is permitted to inject a client-side script into a web site that is viewed by other people who become the victims of the attack. Unlike other common attacks against web sites, XSS doesn’t attack the Web application or database server directly. Instead, it uses the web site, or web server, as a launching pad to execute malicious code in the browser of the site’s visitors to:
Steal login credentials
Steal cookies
Track users activity
Exploit browser activity
Exploit user activity
When combined with other exploits, XSS can be used to launch extremely sophisticated, and dangerous, attacks, making a Web application security measures essential.
Cross-Site Scripting Examples :
One of the best examples of how a cross site scripting attack works was the Samy worm that spread its way through MySpace in October of 2005. Exploiting a hole in the MySpace network, this author of this worm created a malicious page that contained an XSS payload. When an unsuspecting user visited the page, the XSS attack would kick in and sent a friend request to the author (manipulating the victim’s browser), and then replicate itself on the victim’s profile page while leaving messages containing the payload on the profile pages of the victim’s friends.
Another common use of cross site scripting occurs when login credentials are stolen. For instance, an attacker notices that an online store is susceptible to an XSS vulnerability where users are encouraged to post product reviews. Instead of a legitimate post, the attacker uploads a script that contains a payload designed to steal the cookie of anyone who reads their review. The information contained in the cookie can then be used by the attacker to impersonate the victims to access their accounts with the store.
Don’t be a Victim of XSS
Since so many web sites have been found to be vulnerable to XSS attacks, you would think that they are extremely difficult to prevent. Fortunately, this is not the case. Cross site scripting attacks can be prevented by escaping and validating any user input. According to the OWASP (Open Web Application Security Project) six out of their eight rules for preventing XSS attacks deal with either escaping or validating user input.
Escaping user input can be done by using the escape_special function to change characters that are not allowed (usually <, >, &, and ") into characters that are allowed as input. The output displayed on a page can also be escaped to prevent visitors to your site from being victimized by XSS attacks launched from your site. For example, turning <script> into <script> disables an attackers ability to use your web site to attack your visitors.
Validation is even easier. Validation makes sure the input is legal. You can whitelist input, for example only allowing a text string, or you can validate legal input is by blacklisting. In a scenario where blacklisting is used, if your site request a text string, you can blacklist numbers and special characters as input.
Steal login credentials
Steal cookies
Track users activity
Exploit browser activity
Exploit user activity
When combined with other exploits, XSS can be used to launch extremely sophisticated, and dangerous, attacks, making a Web application security measures essential.
Cross-Site Scripting Examples :
One of the best examples of how a cross site scripting attack works was the Samy worm that spread its way through MySpace in October of 2005. Exploiting a hole in the MySpace network, this author of this worm created a malicious page that contained an XSS payload. When an unsuspecting user visited the page, the XSS attack would kick in and sent a friend request to the author (manipulating the victim’s browser), and then replicate itself on the victim’s profile page while leaving messages containing the payload on the profile pages of the victim’s friends.
Another common use of cross site scripting occurs when login credentials are stolen. For instance, an attacker notices that an online store is susceptible to an XSS vulnerability where users are encouraged to post product reviews. Instead of a legitimate post, the attacker uploads a script that contains a payload designed to steal the cookie of anyone who reads their review. The information contained in the cookie can then be used by the attacker to impersonate the victims to access their accounts with the store.
Don’t be a Victim of XSS
Since so many web sites have been found to be vulnerable to XSS attacks, you would think that they are extremely difficult to prevent. Fortunately, this is not the case. Cross site scripting attacks can be prevented by escaping and validating any user input. According to the OWASP (Open Web Application Security Project) six out of their eight rules for preventing XSS attacks deal with either escaping or validating user input.
Escaping user input can be done by using the escape_special function to change characters that are not allowed (usually <, >, &, and ") into characters that are allowed as input. The output displayed on a page can also be escaped to prevent visitors to your site from being victimized by XSS attacks launched from your site. For example, turning <script> into <script> disables an attackers ability to use your web site to attack your visitors.
Validation is even easier. Validation makes sure the input is legal. You can whitelist input, for example only allowing a text string, or you can validate legal input is by blacklisting. In a scenario where blacklisting is used, if your site request a text string, you can blacklist numbers and special characters as input.
.png)
