XSS - Will it happen to you?
Saturday, September 13th, 2008XSS stands for Cross Site Scripting and it has become the number one way to exploit web pages.
It used to be that hackers could exploit Web Servers and hack to gain access to either the Web Server or the entire Server itself. But, with security becoming a priority those holes were mostly all patched years ago. The exception is with Windows Servers running IIS — Internet Information Server — which is still plagued with exploited, Microsoft can’t seem to shrug.
But, with the rise of JavaScript powering a Web 2.0 world, using fancy effects and tricks, a new exploit has introduced itself. XSS or Cross Server Scripting, which uses JavaScript to steal user information, notable their cookies.
Being able to steal any bodies cookie information, that accesses the infected web site, can have massive consequences, if the cookie holds username and password information and other personal information. Unfortunately, many web sites do put sensitive information in cookies, thinking they are safe, because browsers do have security rules that prohibit JavaScript from accessing another site or crossing a domain.
Bank Web Sites or merchant sites like PayPal are a perfect example of a prime spot for hackers to inject their JavaScript code to steal all cookie information of any user that logs in.
I will not get into the details of how one can inject JavaScript into a site, but any Web Hacker, using the proper tools to do the work of searching for vulnerable sites eventually find and inject. Then it is just a matter of waiting for someone to access the website and wait for their cookie data to arrive to the web terrorist via email.
What I will describe a way to nearly 100% stop XSS from happening on your site. Most sites are programmed using PHP, so by using the following command on any pages that you are accessing COOKIE data can set a flag called HttpOnly.
session_set_cookie_params(0,0,0,0,1);
and
setcookie(0,0,0,0,0,0,1);
The two PHP functions above have a last, optional parameter, they accept which can be a true or false 0 or 1 value. Setting this to 1 or true, will set a flag in the Set-Cookie header ( a header sent to the browser to create a cookie ) which will look like the following.
Set-Cookie: key=value; path=/; HttpOnly
Note the HttpOnly flag that is set at the end of the cookie header. This instructs the JavaScript in Web Browsers to NOT send cookie data. This essentially blocks JavaScript from accessing and sending cookie data, which is what we want, because this is exactly what most XSS attacks do to get your cookies.
There are two draw backs to this.
1) Each and every Web Master must properly program their Web Site to include this extra HttpOnly flag when creating cookies. In other words, we are at the mercy of how competent the Web Site Webmaster is at making sure they set this value.
2) Not all Web Browsers support this fairly new cookie option called HttpOnly. But, in the next few releases of the major browsers have already queued up this feature to be enabled.
Not to Panic!
This does not mean we need to never go on the Web again. Especially, your banking site. In order for an attacker to get anything useful from the cookies they aquire from you, needs to be data that is sensitive. As I mentioned there are many idiot Web Programmers that may put a plain text password in a cookie on your browser to make it easier for you to log in. But, most the time these are questionable sites, like warez and porn sites.
However, that does not mean that the XSS problem is 100% safe on perhaps your banking site. You may want to contact your Banking Web Sites technical staff and ask them if they have properly test their site to be XSS safe, and at the very least to NEVER place any sensitive personal information about you or your account in any cookies. Also, ask them about HttpOnly flag used in cookie creation time and whether they have it set properly, which will almost 100% stop XSS in it’s tracks. You just may impress them!