Ryan Barnett wrote:
> Correct. The returned HTTP status codes is but one of many methods of
> enumerating valid account credentials. The most common mistake is
> differences in the error message details provided to the user upon
> successful/failed login attempts. Web apps should not inform the user
> whether or not the problem was with the username or password, but
> rather that they failed to authenticate. The 2nd most obvious sign is
> passing parameters in URL or cookie variables (such as
> STATUS=Authenticated).
>
> This being said, there are still problems with using 302 redirects and
> that it is still possible to enumerate successful/unsuccessful
> authentication attempts based on the Location header data returned
> with the 302 status code. If the authentication fails, it will send a
> 302 and the location most likely will be back to the login page. A
> successful attempt, however will send a 302 but the new Location will
> be something other than the login page. This is enough data for a
> scanner/script to automate and trigger on.
>
You mean, other than the fact that there is no longer a login form on
the resulting page?
Mmmm.
Rogan
-------------------------------------------------------------------------
Sponsored by: Watchfire
Watchfire's AppScan is the industry's first and leading web application
security testing suite, and the only solution to provide comprehensive
remediation tasks at every level of the application. Change the way you
think about application security testing - See for yourself.
Download a Free Trial of AppScan 6.0 today!
https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007kaF
--------------------------------------------------------------------------
Received on Apr 05 2006
Intro
