5 ms·
This is correct: The vulnerability lies in the management of emails when resetting passwords. An attacker can provide 2 emails and the reset code will be s
by nightpool 3y ago
This is correct:
The vulnerability lies in the management of emails when resetting passwords. An attacker can provide 2 emails and the reset code will be sent to both. It is therefore possible to provide the e-mail address of the target account as well as that of the attacker, and to reset the administrator password.
Here's an example payload:
user[email][]=my.target@example.com&user[email][]=hacker@evil.com
(per this POC github: https://github.com/Vozec/CVE-2023-7028 https://github.com/Vozec/CVE-2023-7028)
- tptacek 3y agoYep, so it's the classic Rails bug pattern.
- chatmasta 3y agoThis is such a rarely used feature that I wonder if it would be helpful to have a CSP or preflight header that restricts the browser from sending multiple values for the same parameter.
- janpieterz 3y agoIf you'd want to configure this you'd probably want it as some kind of configuration in the backend that disables it.
- 5- 3y agoa browser is typically not used to exploit this class of bugs.
- chatmasta 3y agoThere is precedent for deputizing the browser to stop this kind of bug with Access-Control-Allow-Headers. If the backend wants to default to ignoring multiple GET/POST parameters with the same name, then the browser could helpfully fail to make a request that attempts to send them.
- talkin 3y agoThe attacker doesnt’t use a compliant browser to make the request. User agent protections only help in situations where a regular user (or their software) is being tricked
- tptacek 3y agoIt's pretty commonly used in Rails form handling logic though, isn't it?
- jeremymcanally 3y agoProperly used white list parameter controls (i.e., strong parameters) that are the default Rails behavior at this point would have prevented this bug completely.
- tptacek 3y agoThis is a little like saying the best way to avoid this bug is to not have the bug. But that's true of all bugs. The C apologists used to say, "just bounds check properly!"
- jordinl 3y agoHard to tell what the issue is without actually seeing the code. If I had to guess what they did was: user = User.find_by(email: params[:emails]) params[:emails].each { |email| send_recovery_email(user, email) } Instead of: user = User.find_by(email: params[:emails]) send_recovery_email(user, user.email) if user
- usr1106 3y agoIt's open source, so we should be able to see the code? Edit: Someone has digged it out: https://news.ycombinator.com/item?id=39162126 https://news.ycombinator.com/item?id=39162126
- simonw 3y agoIt's a great feature that's been supported by browsers for decades. <select multiple> uses it. You can use it for checkboxes to select multiple items too. If you changed it now you would break a whole lot of stuff. I use it extensively in my own Datasette application, eg here: https://datasette.io/content/plugins?_facet=owner&_facet=is_tool&_facet_array=tags&tags__arraycontains=SQL+Functions&tags__arraycontains=Geospatial https://datasette.io/content/plugins?_facet=owner&_facet=is_...
- chatmasta 3y agoYou wouldn't need to change it. But if you made it a CORS header like Access-Control-Allow-Headers, then websites would be able to provide a default policy forbidding it so that their code that actually requires it would need to explicitly opt into the behavior.
- j-bos 3y agoBut how would that affect a malicious actor deliberately invoking the behavior?
- charrondev 3y agoContent Security Policy is a User-Agent feature. The vulnerability here is server-side. A malicious actor exploiting this will be using their own HTTP client that does not respect a CSP.
- technion 3y agoStrong parameters has been a core security feature of rails for a long time, and all the guides go into detail about the boilerplate you need just to accept a form input past the strong parameter filters. It's weird to me that the pattern doesn't also include a "must he a string" option. I know you can add to_s everywhere, but making it part of the existing strong params would actually incentivise use.
- kevinmchugh 3y agoIt's weird, as I recall with strong params one of the only things it really makes you decide is whether a value is a scalar, array, or Hash. You can certainly allow a value to be scalar or array, but it's not very natural in strong params. I mostly hate the way strong params gets used - it's a bad compromise between letting Ruby people do Ruby things and trying to plug up a category of vulnerability that's been biting rails apps for a decade. Now I do all my api definitions in openapi and it's way easier. I haven't tried it with a rails app but I think it'd work well there.
- simonw 3y agoA tiny little piece of Django design that I'm pleased to have participated in is this: emails = request.POST.getlist("email") Django doesn't mix lists and single string values, because I'd been burned by that problem in PHP.
- EGreg 3y agowait, what do you mean by in PHP?
- stephenr 3y agoIn php it would be trivial (and expected) to have a `string` type on a parameter that's expected to be a string - thus negating this issue. But then using the email address from the request rather than the already verified address in the DB seems like a weird design decision to me anyway.