4 ms·

Because a well crafted response could write whatever they wanted to your DB as you’ve given the client too much control. If I know, for instance, an admin is i

Because a well crafted response could write whatever they wanted to your DB as you’ve given the client too much control. If I know, for instance, an admin is identified by an `is_admin` flag, I could add this to the allowed params and send my flag. Bam. I’m now an admin. I know the example is a bit simplistic, but it wouldn’t take long to comb your app for a real world example where this would be problematic.

matthewmacleod 4y ago
That’s the point of the signature the above poster suggested - if you use the app secret to generate a signature of the valid parameters, then the client can’t edit this list without invalidating the signature and there is no risk of them modifying other fields. If your secret is compromised such that this becomes possible, you have way bigger problems. I’m not super keen myself as I prefer the implementation to be much more explicit than magic, but there doesn’t seem to be an obvious security hole here.
- latortuga 4y ago
  Precisely. Strong Params is a canonical violation of DRY. When you build your form, you fill it with fields that are allowed to be filled out and submitted. Then you have to duplicate that work in the controller for no obvious benefit. As for "more explicit than magic" I prefer to think of this as "automatic" or "conventional" rather than magic. Much of Rails' "magic" is this exact kind of thing, allowing the right thing to automatically happen with the ability to step in or override manually when the convention isn't what you want. I get why you'd want it to be more explicit. I think that this feature was invented to solve a security problem and the solution was to give devs more work to do. There's no obvious reason why it couldn't be automatically taken care of for the dev and it would definitely make maintenance and legacy app upgrades smoother.
- Izkata 4y ago
  These attacks work by modifying values, not adding parameters. Sounds like they would still work. Besides, you still have to validate the signature server-side, so it's not like it's saving any work. Validation just gets split up between generating the signature, a network round-trip, and validating the signature.
  - derefr 4y ago
    > so it's not like it's saving any work The "work" the GP is trying to save here isn't CPU cycles, but rather developer labor — the redundant labor of writing both a form view that describes form inputs, and a form-value schema validator to be called from the controller that receives the form's submitted input values. Generating the signature, and validating the signature, would both be done transparently by middleware components of the framework, with no marginal developer labor required per form.
    - Izkata 4y ago
      Django forms already do that, and because of product requirements around design everyone I know who has used it has found it more of a pain than just doing the forms directly. You're just going to be in the HTML/CSS anyway to make it look right. Only for internal pages, where we didn't have bother with UI design, was it worthwhile.
  - jdkoeck 4y ago
    No idea why you're getting downvoted. It seems obvious to me too that you still have to validate server-side, so signing the form validation schema on the frontend is a waste of time.

matthewmacleod 4y ago

That’s the point of the signature the above poster suggested - if you use the app secret to generate a signature of the valid parameters, then the client can’t edit this list without invalidating the signature and there is no risk of them modifying other fields. If your secret is compromised such that this becomes possible, you have way bigger problems. I’m not super keen myself as I prefer the implementation to be much more explicit than magic, but there doesn’t seem to be an obvious security hole here.

latortuga 4y ago
Precisely. Strong Params is a canonical violation of DRY. When you build your form, you fill it with fields that are allowed to be filled out and submitted. Then you have to duplicate that work in the controller for no obvious benefit. As for "more explicit than magic" I prefer to think of this as "automatic" or "conventional" rather than magic. Much of Rails' "magic" is this exact kind of thing, allowing the right thing to automatically happen with the ability to step in or override manually when the convention isn't what you want. I get why you'd want it to be more explicit. I think that this feature was invented to solve a security problem and the solution was to give devs more work to do. There's no obvious reason why it couldn't be automatically taken care of for the dev and it would definitely make maintenance and legacy app upgrades smoother.
Izkata 4y ago
These attacks work by modifying values, not adding parameters. Sounds like they would still work. Besides, you still have to validate the signature server-side, so it's not like it's saving any work. Validation just gets split up between generating the signature, a network round-trip, and validating the signature.
- derefr 4y ago
  > so it's not like it's saving any work The "work" the GP is trying to save here isn't CPU cycles, but rather developer labor — the redundant labor of writing both a form view that describes form inputs, and a form-value schema validator to be called from the controller that receives the form's submitted input values. Generating the signature, and validating the signature, would both be done transparently by middleware components of the framework, with no marginal developer labor required per form.
  - Izkata 4y ago
    Django forms already do that, and because of product requirements around design everyone I know who has used it has found it more of a pain than just doing the forms directly. You're just going to be in the HTML/CSS anyway to make it look right. Only for internal pages, where we didn't have bother with UI design, was it worthwhile.
- jdkoeck 4y ago
  No idea why you're getting downvoted. It seems obvious to me too that you still have to validate server-side, so signing the form validation schema on the frontend is a waste of time.