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

us1903 sharu89 at gmail.com
Mon Aug 20 18:34:18 UTC 2012


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