[OWASP-Security101] Security101 Digest, Vol 7, Issue 2

Jim Manico jim.manico at owasp.org
Mon Aug 20 21:36:00 UTC 2012


How interesting! Thank you!

My thoughts: to stop the replay of the same request, a simple 
per-request transactional token would remove this risk.

But indeed, to remove the risk of data leakage via the back button, it 
does appear that a method like you describe is needed.

I love learning new things, thanks for this gents!

- Jim


> Hello Jim,
>
> No, setting the cache control attributes will not fix this issue. The
> common misunderstanding is that the POST request that contains the
> credentials and other post parameters are picked up from the cache. Whereas
> this is *not true*, these post parameters are stored in browser's volatile
> memory and is destroyed when the browser is closed.
>
> This issue can be fixed by introducing an intermediate page and then
> redirecting to the POST login screen using a 302 redirect mechanism.
>
> Another solution that will prevent this attack is implementing salted
> hashing to protect the password. (For login page only)
>
> This document will help you:
> http://www.infosecwriters.com/text_resources/pdf/Stealing_passwords_via_browsers.pdf
>
> KR,
> Sharath
>
> On Mon, Aug 20, 2012 at 11:51 PM, Jim Manico <jim.manico at owasp.org> wrote:
>
>> Can this problem also be fixed via proper no-cache headers in the response?
>>
>> --
>> Jim Manico
>> (808) 652-3805
>>
>> On Aug 20, 2012, at 11:08 AM, us1903 <sharu89 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> 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.
>>>
>>> Cheers!
>>>
>>> Sharath
>>> *
>>> 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
>>>>         https://lists.owasp.org/mailman/listinfo/security101
>>>> 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
>>>> Message-ID:
>>>>         <
>>>> CAK7e22N7cfyYgaDgg39kwfW4NG_i2FQ69rWFk9ArR6-zkRZd+g at mail.gmail.com>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>
>>>> Hi,
>>>>
>>>> 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.
>>>>
>>>> Thanks,
>>>> Thomas
>>>>
>>>> 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).
>>>>>
>>>>> Thanks,
>>>>> Uncle Bob
>>>>> _______________________________________________
>>>>> Security101 mailing list
>>>>> Security101 at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/security101
>>>>> List Run By OWASP
>>>>> List Admin: Michael.Coates at owasp.org
>>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Security101 mailing list
>>>> Security101 at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/security101
>>>>
>>>>
>>>> End of Security101 Digest, Vol 7, Issue 2
>>>> *****************************************
>>>>
>>>
>>>
>>> --
>>> _______________________________________________
>>> Security101 mailing list
>>> Security101 at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/security101
>>> List Run By OWASP
>>> List Admin: Michael.Coates at owasp.org



More information about the Security101 mailing list