5 ms·
What are some examples of ways you've seen people screw them up?
by _asummers 11y ago
What are some examples of ways you've seen people screw them up?
- tptacek 11y ago* Not being very careful with the lifecycle of a token. * Encrypting tokens and expecting users to feed back the same encrypted token, and failing to authenticate. * Simple parse errors and SQL injection on the tokens themselves. * Exploitable generation (for instance, non-cryptographic RNGs) for the tokens themselves. * Having multi-page flows starting from the receipt and validation of a reset token, and then having standard web flaws somewhere in that flow (for instance: userid is validated only at the start of the flow). * Mishandling of cases where users have multiple outstanding reset requests. * Accepting the email address to send token to from web user, validating the address, and then using the user input directly as the email address to send the token to; as in: systems that will send token to user@real.com;attacker@evil.com. One bug everyone has in their password resets: they don't cancel outstanding tokens when users change their passwords, so that long after a user has reset their password, their email boxes still contain password-equivalent tokens. That's not a high-severity bug, but it's a meaningful one.
- ghuntley 11y ago* Accepting the email address to send token to from web user, validating the address, and then using the user input directly as the email address to send the token to; as in: systems that will send token to user@real.com;attacker@evil.com. Ouch, that's really devious and extremely clever.
- noir_lord 11y agoI think that might work on one of the apps I maintain. Sigh adds to wunderlist
- __david__ 11y agoI'm missing something here... How does "user@real.com;attacker@evil.com" validate as "user@real.com"? Is this a regexp vs strcmp() issue or is there something more subtle at play?
- pfg 11y agoOne scenario I can imagine is a regex which doesn't properly handle multi-line inputs (quite common issue in ruby[1]). Together with a mail header injection vulnerability, this input could be dangerous: user@real.com\nCc:attacker@evil.com [1]: http://guides.rubyonrails.org/security.html#regular-expressions http://guides.rubyonrails.org/security.html#regular-expressi...
- mpeg 11y agoMight have been validated in step1, but the email goes out to the email in a hidden field in step2, etc.
- mikeash 11y agoTotal speculation, but maybe they're trying to be clever and accept things like "John Doe <john@doe.com>" as being equivalent to "john@doe.com" and end up using a full e-mail parsing library for the matching which is more capable than they realize?
- AUmrysh 11y agoIt may send it to multiple addresses. I know in outlook and in .NET libraries, the semicolon is the delimiter for multiple email addresses.
- prawn 11y agoDoes anyone catalogue best practice for these sorts of functions anywhere?
- mAritz 11y agoOWASP is a pretty good resource: https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
- _asummers 11y ago> * Accepting the email address to send token to from web user, validating the address, and then using the user input directly as the email address to send the token to; as in: systems that will send token to user@real.com;attacker@evil.com If you do a "is this even a valid email?" check and a "exists user by email" check with that input (assuming no SQLi, of course), would this even be possible? I'm failing to see what the vulnerable code would look like in that scenario. > One bug everyone has in their password resets: they don't cancel outstanding tokens when users change their passwords, so that long after a user has reset their password, their email boxes still contain password-equivalent tokens. That's not a high-severity bug, but it's a meaningful one. This is solved by simply deleting the tokens after reset, correct?
- tptacek 11y agoYep, that's what I think you should do.
- SixSigma 11y agoValidating email addresses is non-trivial too.
- tptacek 11y agoIf you have to validate, you're doing something wrong (but this is a something wrong people do sometimes do). You should send email only to the string you saved in the database record for the user.
- ars 11y ago> This is solved by simply deleting the tokens after reset, correct? They should also time out after a day or two and either invalidate or delete.
- TheDong 11y agoIf you're saving a token in the database to delete, you're doing it wrong anyways. The right way to do that is to HMAC a string... see this blog post https://neosmart.net/blog/2015/using-hmac-signatures-to-avoid-database-writes/ https://neosmart.net/blog/2015/using-hmac-signatures-to-avoi... You can get expiration and many other nice things without having to worry about a whole class of other issues. To make a password reset all previous reset tokens, simply include an autincrementing number for "passwordVersion" and stick that sucker in the HMAC as well.
- nchelluri 11y agoWhat is the "lifecycle of a token"?
- Monory 11y agoInvalidating old token after few hours/days or after requesting new token.
- nly 11y agoI'd add: * Not requiring any additional authentication once you have the reset link from the e-mail even reddit is vulnerable to this: https://np.reddit.com/r/funny/comments/3egphk/icets_seen_some_shit/ctexfwq?context=5 https://np.reddit.com/r/funny/comments/3egphk/icets_seen_som...
- hesselink 11y agoHow would you prevent that?
- nly 11y agoThere's no reason you couldn't have the user pick a new password before you send them the token. Just don't activate it. Leaking the reset token in this way looks unlikely, but there could be other vectors... like an attacker poisoning the sites DNS cache to intercept reset emails, or a state or database disclosure bug in your code. It's fairly common to see reset tokens going in to the database verbatim, instead of treating them as passwords and stashing away a hash (single SHA is fine if your tokens are long and random).
- tptacek 11y agoThere is a reason not to do this: at the point where you cache the new password, you have no idea who's making the request. An attacker banks a trivial password into the password reset, triggers the email reset token, and waits for the unsuspecting user to click the link in the email. So you have the user enter the password again after clicking through the token. But now you have a condition where accounts are only as safe as it is difficult to get users to type an attacker-chosen string into a web form.
- nly 11y agoHmm, can you explain how this opens up new phishing vectors?. Sure, you could dress the reset page up like a promotion with an iframe and try and get the mark to enter a 'coupon code' or something, but that isn't going to work without the reset token. Password resets by email are already vulnerable to carefully timed phishing.
- nstart 11y agojust throwing in my experience here. I've seen a few sites that actually had the password reset request send them a url that was formatted as: example.com/password_reset?username=<username> You could basically type that in and replace <username> with any username you wished and reset their password. The sad part was how obscenely long it took them to close those holes (couple of weeks).
- _asummers 11y agoWhoah, that's frightening.