About Cross Site Scripting is currently often read about. It’s no wonder as each day new Webservices appear to catch some fame and traffic of web 2.0. Often they push the product out of the pipe as soon as possible, the security is in this moment just secondary( if they care even about it). After the release of the product, the motivation to hunt XSS flaws is minimal( I know this for myself on bug hunting). And when you send them an Email about it, it seems from time to time that they don’t even care about them when they get notified about some XSS flaw(see http://milw0rm.com for what I mean).

What are XSS flaws

As about XSS flaws is already often enough written I’ll keep this short. A XSS flaw occurs if a PHP script(or some other scripting language) uses an User submission without further checking, or a checking is based on Client side Verifications through JavaScript or similar. This submitted code is then Outputted to the User again. Where the JavaScript can read out cookies and send them to an attacker.

Persistent and Non-Persisten XSS

Non Persisten XSS

The bit less harmful kind of XSS is the Non Persistent XSS, the Attacking Script isn’t saved on the vulnerable Server(as it’s not possible). Therefore the User have to click a vulnerable Link. Which Contains the harmful value for the unchecked variable. A way to see that the Link might be harmful is mostly his length, which is around one line and more. Another thing which can indicate a harmful link is something like this within a URL: %3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28
%22%58%53%53%22%29%3C%2F%73%63%72%69%70%74%3E
This would embedded within the vulnerable website URI only prompt you an alert box with the message XSS. But that shall only demonstrate how it can look like, so be carefully when opening URIs with Hex values in it.
Whatever, maybe some website use legit hex values(why ever…) you can check what the URI will look in plain text by using this: The PlayHack Encoder to encrypt it.
Simply put the suspicious URL into the field Hex-URL and click the Button decode under it to see what the URL will look in real, after it you just have to look for something suspicious( for someone without deeper Web programming knowledge it may still be difficult to determine if the link will be harmful or not). If you’re unsure if it’s harmful better avoid visiting anything with hex Values in it.

Persistent XSS

In my eyes this XSS is a lot more harmful, as potentially any page you visit, where Visitors can contribute Content to it, is vulnerable. To get a Persistent XSS to a website you only need something like a Guestbook or Comment function, which doesn’t check the User Input enough and therefore enables it to insert harmful code without that it will be made harmless. So let’s say you have a Guestbook which doesn’t check the field Username for validity. So an attacker inserts as Name <script>alert("xss")</script> This name is now saved on your vulnerable website. And every user who visits yours guestbook will get a harmless alertbox with the Message XSS, but keep in Mind that it’s no problem to insert some Code which is harmful, when you’re already able to insert harmless code as well.
Now you may see the big potential harm Persistent XSS can have, as every website although trustworthy ones can be taken over. And in the best case you find it out just after the page loaded and some JavaScript box popped up. If it only submits silently your cookie from that website you don’t even find out that something happened.

How to fight XSS

There are in general two ways to fight them. There’s for the developer of Internetapps as well as the user of them, at least one way to protect them from XSS.

The Developer

As theoretical everyone can write a webpage and PHP as long as he has a PHP enabled Webspace, there’s a big chance that XSS will never become some minor problem. As many people start writing PHP files, after just a few tutorials( where mostly none contained security aspects). The newly developer knows nothing about Security issues, nor how to aviod them. Now it’s needed, in order to start fighting XSS from that corner, to put much more attention to the area of writing secure PHP code. Therefore it’s needed to teach beginners already within the first tutorials about security aspects, as well as to show them some general mistakes which causes flaws within PHP code. It’s also important to have some real popular wepapps security revised completely, as some of the code is maybe from a time, where the developer(s) started programming and therefore didn’t know much about holes within their code.
For sure it will never be possible to guarantee that also an absolute genius security senior will never forgot to tidy up some user input, but you can minimize the risk enormous if you practice it in everyday work.

But there’s another problem, which is quite real for developers of plugable code. Normal you can output any data inserted in the database easily without any cleaning of harmful code out of it, as this happened already before the data was stored in the database. But what happens if some 3rd Party developed code doesn’t clean the userinput before it’s stored within the database? And that what get stored isn’t anything which is just used by 3rd Party code? That would allow XSS scripting although the main app may be secure, just because some 3rd Party developer isn’t paying enough attention to it. So a small 3rd Party code can destroy the whole security of the main app. That’s why it’s as well for the Developer important to create a mindful 3rd Party developer base! As the option to clean up the code again before outputting it, slows the whole app down and that will mostly be disliked by the user.

The User

How can now the User help to fight XSS?
The user will mostly never add much value to lower the attraction of XSS, nor can he add anything to prevent them(except he does some security analyses). He can mostly only prevent himself from getting a victim of XSS, this is mostly done by adding more attention to links, before they’re clicked! So you need check if your Link-Source is trustworthy or not. This works only for non persistent XSS as you don’t know about XSS within the next page of the Website you visit.
You can turn off the JavaScript within your Browser, but as there are so many Web 2.0 apps/sites are out it’s really hard to come along without JS turned on. And who wants to miss the comfort added through it as well?
Another option to prevent yourself a bit from becoming a victim of XSS is to logout each time you leave a special Website, where you’re registered at. So you can at least lower the risk to become a victim by visiting external links to that page( based on you’re not clicking external links to that page, while you’re on that website).

Tags: Cross Site Scripting, Vulnerable code, XSS

This entry was posted on Tuesday, July 17th, 2007 at 4:07 pm and is filed under Programming, Webmaster, Wordpress. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.