CROSS SITE SCRIPTING XSS tut

Simply put, cross site scripting involves the injection of malicious code into a website. It is the most common method of attack at the moment, as most large sites will contain at least one XSS vulnerability. However, there is more than one type of XSS. The most commonly found isreferred to as "non persistent" XSS. None Persistent XSS Non persistent as the title suggests means that the injectedscript isn't permanent and just appears for the short time the user is viewing the page. The best example of this is a basic coded search engine for a site. Say for example, the site search script is in this format: Site.com/search.php?search=text here Once something has been searched for, the script may display on the page something along the lines of: "Results for text here" Simply echoing your search string straight onto the page without performing any validation checks. What if we were to alter the search string to display html of JavaScript? For example: Site.com/search.php?search=XSS Site.com/search.php?search=alert("XSS"; If no sanitation checks are being performed by the search script, this will just be echoed straight onto the page, therefore displaying an alert or red text. If there was no limit to the size, this could be used to display anything you want. However, since the attacker can only display code on their own pages, this isn't much of a threat to other users. Although if the string was turned into Hex the search string may be slightly more hidden and with a little deception could be used to trick users into thinking the link is legitimate. Next there's persistent XSS Persistent XSS Again as the name suggests, this is the type of XSS attack the attacker would want to get. Persistent attacks are injected permanently into the code of the site, so anyone who views the site will be able to see permanently. In order for these to work, the code has to be made to store itself on the sites server somehow, which can be hard to find. An embarrassing example of this was an XSS vulnerability discovered on this site by one of our users (fixed now, obviously) affecting the page blog.php. The register process wasn't sanitized at all, so all a user had to do was simply put redirection code. This was an obvious vulnerability which should have been spotted from the beginning, but just like XSS on other sites it was missed. If not fixed, this vulnerability would effect index.php as well as the forums and anywhere where the code was displayed on the site. A good place to look out for this vulnerability is basic forum scripts that site owners have made themselves or found off sites designed to help novices. With both of these attacks, it is also possible to run malicious code from another site again making the possibilities of attack endless. Javascript has a lot of features the are not well know, such as changing the images on sites from images[number].src and anyone who uses myspace will know the CSS can be used to remove or replace certain sections of a site based on name.If you have a permanently vulnerable site, injecting code as simple as the one below will allow you to run XSS off another site: Getting Past Basic Protection So what if a site owner knows about XSS, but has provided some but very little protection against it? Well, this is where CharCode comes in. Char code is basically just a simple form of character encoding that can encode blocked characters so they get past the protection but still get displayed normally on thepage. Here is a very common onethat will pop up alerts saying"XSS" if it is vulnerable: ';alert(String.fromCharCode(88,83,83))//'; alert(String.fromCharCode(88,83,83))//"; alert (String.fromCharCode(88,83,83))//"; alert (String.fromCharCode(88,83,83))//-->">'> alert(String.fromCharCode(88,83,83)) This is a very useful XSS to know, as it provides more than one type of attack at once. If you get only one or two alerts, you know that only one of two of them work, so you need to try to eliminate some of them to text which one is affecting the site. The CharCode for "X" is 88 and"S" is 83. As you can see, each provides a slight variation to try to beat character blocking. XSS could also be hidden in a none existent image. This code below would run malicious JavaScript disguised as an image: What if quotes are blocked? No problem, just inject the site like so: The " will be interpreted in html as a " so the code will run fine. The next one below is very likely to work if you find a site is vulnerable.