-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sendResetPwd, information leak #85
Comments
In case it helps anyone else, I wrote a middleware handler to intercept any 400 errors as a workaround. module.exports = function(app) {
return function(error, req, res, next) {
let refererPath = req.headers.referer.split('/')
refererPath = refererPath[refererPath.length-1]
const resetPwdRequested = refererPath === 'forgot-password'
const userNotFoundError = error && error.code === 400 && error.name === 'BadRequest' && error.message === 'User not found.'
if (resetPwdRequested && userNotFoundError) {
// Don't leak whether or not users exist in your DB to nefarious hackers
// (Make sure this response is the same as when a user is found.)
res.status(201).send({ success: true })
}
next(error)
}
} |
The same applies to error responses which result from unique violation for email. The instance details are revealed which contain the hashed password (well, any fields which were part of the original payload). This enables gathering a map of |
I try to find the 404 response referred above, and would expect it to show up in my chrome network tab in the status column. However I do not get any 404 (just 200) when using a not existing email. Does this mean my app is 'not vulnerable' to this kind of leaking? And why: could it be because I use websockets? Server side I get:
|
Well I am afraid sending 200 when there is actually an error is not really great, how do you let your users (and not attackers) know about any error ? To check the email an attacker can also try to register as it is often required to be unique and check this error, if no error is returned how do you tell your user that he has to provide another email ? Regarding #85 (comment) you probably miss a removeVerification hook to avoid leaking information. |
You set a generic message that your users will receive a password reset email if their details are found in your records.
True, but generally my main aim is to slow down / prevent rapid enumeration of multiple emails - something like a captcha on your registration form can help with this. |
Yes or rate limiting. |
This issue has been moved to feathers-plus/authentication-local-management#5 and feathers-plus/authentication-local-management#6 |
This is an old and closed issue. But in case anybody searches for a solution for this issue that works with REST and Websocket transport: You can always remove the error and unify the result that is returned to the frontend in the error and after hooks of a Feathers service. Here is a simple example for the
|
With the
sendResetPwd
action, if the email address does not exist, a 404 error is thrown.I think this is an information leak, because thanks to that call, an attacker can find if an email address is valid or not (ie in the database). I think this call should not return the user info, and send the same empty response, whatever the case (user exists or not).
Regards.
The text was updated successfully, but these errors were encountered: