XSS-Good For Java 4

XSS-Good For Java 4

By ghost | 5801 Reads |

0     0

XSS is simply tricking a web server into presenting malicious HTML to the user. Usually the intent is to steal session information.

Scripts may also be used to change the contents of web pages in order to displays false information to the visitor, and it may be used to redirect forms so that secret data are posted to the attacker’s computer. XSS generally attacks the user of the web application, not the application itself. The attacks are possible when the web application lacks proper output filtering.

As cookies are available to a script, Cross-site Scripting may be used to hijack cookie-based sessions. If a “someone” gets access to someone else’s session cookie, he may often appear as that someone to the server by installing the cookie in his own browser.

When people hear about XSS-based Session Hijacking for the first time, sometimes they have a hard time understanding how the process works.It’s important to understand under what context the Session ID cookie is available to the attacker’s script. As you know, a victim that logs into a site gets a unique Session ID cookie assigned to him. The attacker wants that cookie to impersonate the user. And he can’t get it by tricking the victim into visiting the attacker’s own web server: as the domain names do not match, the victim’s browser will not send the cookie to him.

Let’s sum it all up by this step-by-step overview on XSS-based session hijacking that includes the “stealth” method:

1. The attacker somehow makes the good site, on which the victim has a session, include a cookie-stealing JavaScript in a page presented to the victim.

2. The victim’s browser receives the script from the good site and executes it. The script immediately redirects the browser to the web server of the “someone”, taking the session ID cookie with it as part of the URL.

3. Upon receiving the request, the “someone’s” stealing application extracts the cookie from the URL, and generates a reply page containing another redirection script pointing back to the good site.

4. The victim’s browser receives the new web page from the attacker’s server. It then runs the new redirection script, which asks it to fetch a new page from the good server.

5. The attacker inserts the stolen cookie in his own browser, and connects to the good site. The good site will mistake him for the victim.

The user may see a short flicker, but he will otherwise not be able to tell that his browser paid a quick visit to the attacker’s web server. Not even the browser’s history will be able to tell the tale, as document.location.replace overwrites the current history entry with the new URL.

::Steal Passwrods:: Many log-in scripts redisplay the user name if log-in fails. They generate a new log-in form in which the previously entered user name is filled in, in the belief that it was the password that was entered incorrectly. Quite user friendly, and not at all a bad thing to do. Unless you’re vulnerable to XSS.

A system for small payments, created by a large, multi-nationall consulting company in cooperation with a couple of banks, did just that. I read about it about a year and a half ago. And as they did not forbid scripts in the user name, they made it possible to steal other users’ passwords via XSS.

Hope you understand something now