[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20060225062521.13678.qmail@securityfocus.com>
Date: 25 Feb 2006 06:25:21 -0000
From: webmaster@...kstarlings.com
To: bugtraq@...urityfocus.com
Subject: Re: DarkStarlings.com XSS Vulnerability
While the site does not intensively scrub javascript that is input by the user, XSS vulnerabilities are not a concern.
The worst case scenario (and really only important scenario) is that of a malicious party using javascript to capture cookie information from a user of the site and then using that information to falsely authenticate under the user's account (or to put it garishly, using XSS to "hack" other member's accounts).
Even though an XSS enthusiast of intermediate skill should have little trouble extracting user cookie information on the site using cleverly disguised redirects, the information obtained would be entirely useless.
Not only is the cookie password information hashed with multiple, complex, salted algorithms, it is hashed with unique information (a unique salt that depends upon some network information) that makes using the hashed password to forge a cookie impossible. That is, User A and User B, connecting from different locations but using the same username and password, will have different password hashes. If User B tries to use User A's password hash, authentication will fail.
Given that, I have elected not to pursue heavy scrubbing of javascript on my site.
Why?
I could just as easily disabled the use of javascript site wide, but I wanted to allow members of our community to be more free to use it for various (benign) purposes. Instead of letting a few bad apples ruin the party for everyone, I've carefully considered the consequences of attempted XSS exploits using javascript on my site and have produced solutions to keep everyone's experience on DarkStarlings as secure as possible.
Powered by blists - more mailing lists