informit.com — "Informit.com provides an insiders look at a real life XSS attack and how it was used to bypass the authentication scheme of an online web application, leading to "shell" access, and admin account, and more. XSS attacks are often discussed in theory ? this walk through illustrates just how dangerous these types of attacks can be in reality.
Aug 14, 2006 View in Crawl 4
microbertoAug 15, 2006
Basic take-aways:1. Don't trust anything a user gives you, and certainly don't allow it to be spit out (or executed) in a script! Filter anything you don't need.2. Don't allow users to upload stuff to an executable directory.3. Don't let users a chance of executing a script that they ought not to be.
hypoxideAug 15, 2006
This is simply phishing. Rather useless if you ask me. Its a hacker's last resort.
spjmm0Aug 15, 2006
according to a 16 year old that I was talking to all you need to do is "hack the binary" to hack websites.
fiv3isaliv3Aug 15, 2006
Waste of time to read. Most of it is common sense. Dugg it for the people who don't use common sense.
armboAug 15, 2006
damn, this was good. very informative on not only what he did, but why it worked. where can i find more like this?
duketimeAug 15, 2006
You're right. It is a form of phishing, but it was something that the website itself enabled, I believe.So he set his email to a redirect that would send him the user's cookie such that anybody viewing a page with his email on it would send him session information.This is something like what happened with the new Netscape some time back where you could submit stories with script in it. People exploited this by spawning popups or recommending digg, but you could have the redirect / cookie send in the script.
duketimeAug 15, 2006
To paraphrase your comment:Useless, provides no meaningful content. Recommended because it will provide many with useful information.Edit: Oh I see the bit about the people without common sense. Yeah, judging from some of these comments, I didn't realize web devs were such snobs.
Closed AccountAug 15, 2006
So exactly how would you store the session id since you are such a bad ass web developer? HTTP is stateless. You have two options - Cookie or URL. If you think URL is better, you are fired.
napoleongoldAug 15, 2006
Well that was a lovely intro,I'm new to all this but interested and that article was a nice overview to jump off of.Dugg
utherwaynAug 15, 2006
@jkramlich, sorry how does that prevent the user from being inconvenienced?If I am brute forcing a website authentication through curl my algorithm is going to go for quite a while, that means that while I am attempting a brute force that account cannot be accessed because you are denying even valid logins within n seconds, I do like that idea but I would augment it further to include logging what IP the access is from and checking against if its the same, that would pretty much escalate the time needed to brute force to not in your lifetime. Of course in that case you would want the server to not blacklist the IP because that would indicate that the cracker has failed some sort of security measure. Definitely something I had overlooked.