[OWASP-Security101] Security101 Digest, Vol 7, Issue 2
jim.manico at owasp.org
Mon Aug 20 18:21:44 UTC 2012
Can this problem also be fixed via proper no-cache headers in the response?
On Aug 20, 2012, at 11:08 AM, us1903 <sharu89 at gmail.com> wrote:
> Just to add, in case of a login page when the POST request is re-submitted
> by the browser the user/attacker is logged in with the victim's credentials
> using the Back-and-Refresh method. Without having to install/use any kind
> of proxy or intercepting tools.
> *How to check:*
> 1. Login to the application -> If you can install a web-proxy or a
> intercepting tool then you can observe the 200 OK response.
> 2. Now, logout of the application -> You reach the login page or any
> page after logout.
> 3. Click Back button and then click Refresh button, the browser will ask
> if you want to resubmit the request; say "Resend" (in case of Firefox). You
> will be logged into the application.
> Hope this helps :)
> Let me know if you have any questions.
> Blog:* http://secbloggers.com/
> On Mon, Aug 20, 2012 at 5:30 PM, <security101-request at lists.owasp.org>wrote:
>> Send Security101 mailing list submissions to
>> security101 at lists.owasp.org
>> To subscribe or unsubscribe via the World Wide Web, visit
>> or, via email, send a message with subject or body 'help' to
>> security101-request at lists.owasp.org
>> You can reach the person managing the list at
>> security101-owner at lists.owasp.org
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Security101 digest..."
>> Today's Topics:
>> 1. Re: Don't understand OWASP 2010 A3 redirect after login
>> (Tom Mackenzie)
>> Message: 1
>> Date: Mon, 20 Aug 2012 11:37:27 +0100
>> From: Tom Mackenzie <tom.mackenzie at owasp.org>
>> To: security101 at lists.owasp.org
>> Subject: Re: [OWASP-Security101] Don't understand OWASP 2010 A3
>> redirect after login
>> CAK7e22N7cfyYgaDgg39kwfW4NG_i2FQ69rWFk9ArR6-zkRZd+g at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>> It is more of a physical issue. If someone gets access to the machine and
>> it doesn't use a 302 redirect on the application the credentials will be
>> re-POST when using the back and refresh buttons. Put an intercepting proxy
>> in between and you then see the issue.
>> On Fri, Aug 17, 2012 at 10:15 PM, Uncle Bob <testme47 at gmail.com> wrote:
>>> I got a report from a customer running an OWASP test against my
>>> hand-written web app that it doesn't issue a 302 redirect after
>>> successful login. The customer sent me the description of this
>>> problem included in whatever report he got, but I don't understand it.
>>> I tried putting in a 302 redirect after successful login, but I don't
>>> see that it protects anything; for example, I thought that it might
>>> prevent someone from logging in without knowing the username and
>>> password by using "back" and "refresh" buttons in firefox after
>>> logging out, but it does not protect against that.
>>> Can someone explain this vulnerability better, tutorial style or with
>>> a good example, so I can understand and determine whether my change to
>>> the webapp login really protects against something that needs to be
>>> protected against? I'm not finding a good explanation on owasp.org
>>> (if it's there, maybe all I need is for somebody to point me to the
>>> right page).
>>> Uncle Bob
>>> Security101 mailing list
>>> Security101 at lists.owasp.org
>>> List Run By OWASP
>>> List Admin: Michael.Coates at owasp.org
>> Security101 mailing list
>> Security101 at lists.owasp.org
>> End of Security101 Digest, Vol 7, Issue 2
> Security101 mailing list
> Security101 at lists.owasp.org
> List Run By OWASP
> List Admin: Michael.Coates at owasp.org
More information about the Security101