4 ms·

This 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 value

This 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 ago
If you'd want to configure this you'd probably want it as some kind of configuration in the backend that disables it.
5- 3y ago
a browser is typically not used to exploit this class of bugs.
- chatmasta 3y ago
  There 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 ago
    The 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 ago
It's pretty commonly used in Rails form handling logic though, isn't it?
- jeremymcanally 3y ago
  Properly 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 ago
    This 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 ago
  Hard 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 ago
    It'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 ago
It'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 ago
  You 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 ago
    But how would that affect a malicious actor deliberately invoking the behavior?
charrondev 3y ago
Content 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.

This 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 ago

If you'd want to configure this you'd probably want it as some kind of configuration in the backend that disables it.

5- 3y ago

a browser is typically not used to exploit this class of bugs.

chatmasta 3y ago
There 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 ago
  The 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 ago

It's pretty commonly used in Rails form handling logic though, isn't it?

jeremymcanally 3y ago
Properly 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 ago
  This 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 ago
Hard 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 ago
  It'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 ago

It'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 ago
You 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 ago
  But how would that affect a malicious actor deliberately invoking the behavior?

charrondev 3y ago

Content 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.