[Owasp-leaders] CSRF Password Change Function

Carlos Sagrero carlos.sagrero at owasp.org
Mon Mar 27 22:31:42 UTC 2017


Thank you very much for your time.

Best regards.

Isaac Sagrero

On Fri, Mar 17, 2017 at 5:27 AM, Ralph Durkee <rd at rd1.net> wrote:

> I think we need to consider the context and be careful not to frustrate
> people by always raising the bar to the highest cryptographic level
> possible.   If the context is citing a vulnerability I would not include a
> page that required a current password as being vulnerable to CSRF.
> Generally you're likely to find other parts of the application to cite
> anyway. If we are talking recommendations, then by all means recommend a
> CSRF token, but we need to be flexible in our *allowed* solutions so that
> App Sec is perceived as doable and mildly stable.  There's plenty of
> alternate defenses against CSRF that are viable.  Check out
> https://www.owasp.org/index.php/Cross-Site_Request_
> Forgery_(CSRF)_Prevention_Cheat_Sheet
>
> -- Ralph Durkee, CISSP, GXPN, GPEN, GCIH, GSEC, GSNA, GCIA, C|EH
> Principal Security Consultant
>
>
>
> On 03/17/2017 06:07 AM, Rogan Dawes wrote:
>
> Let's put it this way:
>
> Having a CSRF token on the password change form would be "best practice",
> as it ensures that an attacker cannot convince you to try change your
> password while you are logged in, even if they do have to brute force your
> current password in the process.
>
> Note that any rate limiting implemented here would impact the legitimate
> user, not the attacker! By this I mean, yes, the attacker would be slowed
> down, but the actual user might be the one impacted, if the slow down
> applies to more than just the password change function!
>
> It would also not be unusual (at least, not surprising) to see rate
> limiting implemented on the login page only, and not the password change
> form, on the assumption that the password change form is only accessible to
> authenticated users, and thus rate limiting is not required.
>
> So, while in theory, the password itself IS a CSRF token, in that it is
> something that the attacker does not know, it is entirely possible that the
> password is easier to brute force than the CSRF tokens in other instances.
> And this fact makes it weaker than a traditional CSRF token would be.
>
> Thanks for the discussion, I have actually changed my position from "the
> password is sufficient as a CSRF token", to "A purely random CSRF token is
> still required".
>
> Rogan
>
> On Fri, Mar 17, 2017 at 11:46 AM Martin Knobloch <
> martin.knobloch at owasp.org> wrote:
>
>> All,
>>
>> I totally agree with Steven! Do not abuse the password for what it is not
>> meant for!
>> Why should you (ab-)use the password?
>>
>> Your CSRF token should be user and session specific!
>> See the Cheat sheet information on CSRF: https://www.owasp.org/index.
>> php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
>>
>> Kind regards,
>> -martin
>>
>>
>> On Fri, Mar 17, 2017 at 10:23 AM, Steven van der Baan <
>> steven.van.der.baan at owasp.org> wrote:
>>
>> Hi all,
>>
>> I disagree that you can use the current password as anti CSRF token.
>> And here is why
>> I see the anti CSRF token as assurance that it's really the user
>> interacting with the application and not some script. An attacker can
>> easily  go through the whole rockyou dictionary and uses all entries as
>> current password to reset it to a known value. There will always be
>> users that fall victim to this as they use insecure passwords.
>>
>> Just my £0.02
>>
>> Steven.
>>
>> On 17/03/17 07:49, Minhaz A V wrote:
>> > Yes, current password can be used as anti CSRF Token, actually if there
>> > old password is needed for changing password there is no need for anti
>> > CSRF logic there, as it's much like login and cookies doesn't play much
>> > role except for username. However if you were to use anti CSRF method
>> > everywhere (let's say on POST request) you'd go for homogeneous method.
>> >
>> > ------------------------------------------------------------
>> ----------------
>> > Kind Regards,
>> > Minhaz
>> > minhazav.xyz <http://minhazav.xyz> | Blog <http://blog.minhazav.xyz>
>> > |Projects <http://github.com/mebjas> | LinkedIn
>> > <https://in.linkedin.com/in/minhazav>
>> >
>> > On Fri, Mar 17, 2017 at 7:15 AM, Ralph Durkee <rd at rd1.net
>> > <mailto:rd at rd1.net>> wrote:
>> >
>> >     I agree that requiring the current password is sufficient for
>> >     anti-CSRF. If the attacker could provide the current password, then
>> >     there would be no need for the attack.  Was there logic provided as
>> >     to why the current password would not be sufficient?
>> >
>> >     -- Ralph Durkee, CISSP, GXPN, GPEN, GCIH, GSEC, GSNA, GCIA, C|EH
>> >     Principal Security Consultant
>> >
>> >
>> >     On 03/16/2017 09:24 PM, Carlos Sagrero wrote:
>> >>     Hello, a few hours ago I had a discussion with several of my
>> >>     co-workers (all of them are Application Security consultant) about
>> >>     whether in a password change function is valid to consider the
>> >>     current password as a anti-CSRF control.
>> >>
>> >>     There is an interesting point that was the main discussion point,
>> >>     at the end the current password is not a control to avoid CSRF.
>> >>
>> >>     What do you think about it? It is required to have a specific
>> >>     control to CSRF?
>> >>
>> >>     Best regards.
>> >>
>> >>     --
>> >>
>> >>     *Carlos Isaac Sagrero Campos*
>> >>
>> >>     *OWASP Mexico City*
>> >>
>> >>     Inline image 1
>> >>
>> >>
>> >>     <https://www.avast.com/sig-email?utm_medium=email&utm_
>> source=link&utm_campaign=sig-email&utm_content=webmail>
>> >>      Libre de virus. www.avast.com
>> >>     <https://www.avast.com/sig-email?utm_medium=email&utm_
>> source=link&utm_campaign=sig-email&utm_content=webmail>
>> >>
>> >>
>> >>
>> >>
>> >>     _______________________________________________
>> >>     OWASP-Leaders mailing list
>> >>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.
>> owasp.org>
>> >>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> >>     <https://lists.owasp.org/mailman/listinfo/owasp-leaders>
>> >
>> >
>> >     _______________________________________________
>> >     OWASP-Leaders mailing list
>> >     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org
>> >
>> >     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> >     <https://lists.owasp.org/mailman/listinfo/owasp-leaders>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > OWASP-Leaders mailing list
>> > OWASP-Leaders at lists.owasp.org
>> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> >
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>
>
> _______________________________________________
> OWASP-Leaders mailing listOWASP-Leaders at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>


-- 

*Carlos Isaac Sagrero Campos*

*OWASP - Líder del capítulo Ciudad de México*

[image: Inline image 1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170327/4e3fa9c8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 44430 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170327/4e3fa9c8/attachment-0001.png>


More information about the OWASP-Leaders mailing list