Rather than a manifest, a signature?

[jeremyevans]

Google Group Post: https://groups.google.com/g/ruby-forme/c/QKbiBKB9kB0
Google Group Date: Sun, 1 Jun 2014 02:00:40 -0700
Google Group Sender: [email protected]

As a possible alternative to a manifest for preventing malicious bogus field insertion for form data going to a universal form return routine, what about signing the form? As in, take all the keys/input field names, or maybe all the object ids, or whatever, and generate a salted cryptographic hash, a la MD5 or whatever, and then stick that into the form as a hidden field.

What data, exactly, is used as input for the hash is obviously the key to how to make this work, since it needs to be stuff that is certain to be returned with the form, so I imagine there might be some forms that it would be difficult to create a stable hash, but even if it only worked for a restricted subset of possible forms, it would still be valuable, and RESTful.

[jeremyevans]

Google Group Date: Sun, 1 Jun 2014 16:48:09 -0700
Google Group Sender: [email protected]

On Sunday, June 1, 2014 2:00:44 AM UTC-7, Dave Howell wrote:

As a possible alternative to a manifest for preventing malicious bogus
field insertion for form data going to a universal form return routine,
what about signing the form? As in, take all the keys/input field names, or
maybe all the object ids, or whatever, and generate a salted cryptographic
hash, a la MD5 or whatever, and then stick that into the form as a hidden
field.

What data, exactly, is used as input for the hash is obviously the key to
how to make this work, since it needs to be stuff that is certain to be
returned with the form, so I imagine there might be some forms that it
would be difficult to create a stable hash, but even if it only worked for
a restricted subset of possible forms, it would still be valuable, and
RESTful.

I'm not sure how such a thing would work. Let's say a request comes in,
and you are able to match the signature. Without a specific manifest, how
do you know how to handle the form processing. I don't think you can
assume that everything you need comes via the request parameter keys.

Even if this work fine, I'm not sure it is any less difficult than storing
the full manifest in the form, so I'm not sure what the advantages are.

Personally, I think if you really want to get this idea or the manifest
idea to work, you should attempt to implement it yourself. That will
probably be faster than waiting for someone else to do so.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Mon, 2 Jun 2014 19:10:36 -0700
Google Group Sender: [email protected]

On Jun 1, 2014, at 16:48 , Jeremy Evans [email protected] wrote:

I'm not sure how such a thing would work. Let's say a request comes in, and you are able to match the signature. Without a specific manifest, how do you know how to handle the form processing.

Exactly the same as you handle the form processing, period. You write whatever code would handle it.

Personally, I think if you really want to get this idea or the manifest idea to work, you should attempt to implement it yourself. That will probably be faster than waiting for someone else to do so.

If the signature makes sense, I absoluteiy intend to do it myself. It seems easy.

My current code works based (I thought) on what you told me to do, which is this:

  orderdata = request.params["order"]
  orderdata.delete_empty!
  order_id = orderdata.delete("id").to_i
  order = Order[order_id] 
  order.update(orderdata) 
  orderdata["items_attributes"].each do |k,v|
  	itemdata = v
  	itemdata.delete_empty!
  	item_id = itemdata.delete("id")
  	if itemdata["quantity"] == "0" then 
  		Item[item_id].delete
  	else
  		Item[item_id].update(itemdata)
  	end
  end
  redirect(route(:display, {:id => order_id}), :port=>nil)

It’s a hard-coded manifest: there’s an order, and it will have nested items. The end. So bogus field injection won’t grant access to any other models. But it doesn’t offer any protection against injecting other fields into Order, or into other Orders, or into other Items.

Signing the form would. It would make it extremely difficult to add ANY extraneous fields.

This isn’t about my idea of having a single method handling all returns. That’s why I changed subjects. This is about me listening to your emphasis on security, and proposing a way to improve security of the current Forme library.

[jeremyevans]

Google Group Date: Mon, 2 Jun 2014 22:12:30 -0700
Google Group Sender: [email protected]

On Monday, June 2, 2014 7:10:41 PM UTC-7, Dave Howell wrote:

On Jun 1, 2014, at 16:48 , Jeremy Evans wrote:

I'm not sure how such a thing would work. Let's say a request comes in,
and you are able to match the signature. Without a specific manifest, how
do you know how to handle the form processing.

Exactly the same as you handle the form processing, period. You write
whatever code would handle it.

Personally, I think if you really want to get this idea or the manifest
idea to work, you should attempt to implement it yourself. That will
probably be faster than waiting for someone else to do so.

If the signature makes sense, I absoluteiy intend to do it myself. It
seems easy.

My current code works based (I thought) on what you told me to do, which
is this:

            orderdata = request.params["order"] 
            orderdata.delete_empty! 
            order_id = orderdata.delete("id").to_i 
            order = Order[order_id] 
            order.update(orderdata) 
            orderdata["items_attributes"].each do |k,v| 
                    itemdata = v 
                    itemdata.delete_empty! 
                    item_id = itemdata.delete("id") 
                    if itemdata["quantity"] == "0" then 
                            Item[item_id].delete 
                    else 
                            Item[item_id].update(itemdata) 
                    end 
            end 
            redirect(route(:display, {:id => order_id}), :port=>nil) 

It’s a hard-coded manifest: there’s an order, and it will have nested
items. The end. So bogus field injection won’t grant access to any other
models. But it doesn’t offer any protection against injecting other fields
into Order, or into other Orders, or into other Items.

Signing the form would. It would make it extremely difficult to add ANY
extraneous fields.

This isn’t about my idea of having a single method handling all returns.
That’s why I changed subjects. This is about me listening to your emphasis
on security, and proposing a way to improve security of the current Forme
library.

Sequel's nested_attributes plugin (which Forme is designed to work with)
handles the injection issues (or offers options to handle them if there is
not a secure default that makes sense in all cases).

I'd have to see your implementation of a form signature before I could
offer an opinion on the security benefits or issues.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Tue, 3 Jun 2014 14:42:48 -0700
Google Group Sender: [email protected]

On Tuesday, June 3, 2014 2:14:27 PM UTC-7, Dave Howell wrote:

On Jun 2, 2014, at 22:12 , Jeremy Evans wrote:

Sequel's nested_attributes plugin (which Forme is designed to work with)
handles the injection issues (or offers options to handle them if there is
not a secure default that makes sense in all cases).

Assume a form that lets me edit the list price of an artist’s albums. The
form should return something like this:

{:artist=>{:id=>3425, :albums_attributes=>{0=>{:msrp=>12.99},
1=>{:msrp=>13.99}}}}

and the processing code is

artist.update(params[:artist])

That does block this:

{:artist=>{:id=>3425, :bank_accounts_attributes =>{:id=>1,
account_number=>4362345, :routing_number =>44326453},
:albums_attributes=>{0=>{:msrp=>12.99}, 1=>{:msrp=>13.99}}}}

but not this:

{:artist=>{:id=>3425, :albums_attributes=>{0=>{:msrp=>12.99,
:name=>”Anonymous Was Here”, :tracks_attributes => {:id=>1,
_delete=>true}}, 1=>{, :msrp=>13.99}}}}

Since this is a change form, not a create/add form, I could use signature
= artist.albums.collect{|lp| lp.id + “msrp”}.join.create_hash to build a
signature. When the form comes back, I validate the return by concatenating
every album’s id with every field name (besides the id), and hashing that.
If you’re not confident of being able to retain the field order, then sort
the albums by ID before calculating the hash.

I'd be interested in seeing your create_hash method. This appears to be a
String#create_hash call with no parameters, which seems like an attacker
(i.e. the user) could easily fake the signature if they knew the algorithm
(and the assumption is the attacker does). This assumes you are storing
the signature as a hidden form variable, but I've already explain the
issues with storing it server-side. For security, you either have to sign
that signature with a secret key, or you have to include the secret key as
part of of the signature, pre-hashing (probably easier).

If the form does not contain every album used to build the form, or any

fields besides the ones sent out, the hash fails, and the code rejects the
form data.

For a create/add form, you’d build a signature with the field names. If
the return allows for multiple adds, then somebody could falsify a form
that inserted an indefinite number of rows, but it would not be possible to
assign values to any column that hadn’t been part of the form.

The way nested_attributes handles this is it assumes any already associated
object can be modified, but if the object is not already associated, it
cannot be modified. You can also specify the lists of fields to allow for
the associated objects.

Thanks,
Jeremy