Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Modiying values in html form

by taint (Chaplain)
on Nov 03, 2013 at 05:05 UTC ( #1061012=note: print w/replies, xml ) Need Help??

in reply to Modiying values in html form

Greetings, In my humble opinion. It is best to use only the POST method within such forms, and simply drop attempts submitted via GET. This greatly eliminates common methods to alter submissions via the URL/Location field(s) in their web client (browser). eg;


While hidden fields aren't really hidden, should anyone simply choose View->Source, from their browser. It is fairly trivial to encode those fields via base64, or even sha256. All modern browsers will render those fields correctly. But a View->Source will reveal only seeming gibberish. While a savvy seasoned programmer/user might recognize the fields as being "packed". Is it really worth the bother?

Anyway. While it isn't ever really possible to completely secure online form(s)/form data. Things like this, that "raise the bar to entry" will usually thwart most attempts. If for no other reason being, that it simply doesn't seem worth the bother.



Replies are listed 'Best First'.
Re: Modiying values in html form
by GrandFather (Sage) on Nov 03, 2013 at 10:03 UTC

    This question/comment is not much Perl related so probably won't get much comment here. A brief answer is: "Don't round trip prices. Use codes or maintain a session and use a shopping cart".

    There are many tools on CPAN that will help with session management etc.

    True laziness is hard work
Re: Modiying values in html form
by rnewsham (Chaplain) on Nov 03, 2013 at 08:33 UTC

    Although it does hinder casual variable modification, anyone who is knowledgeable enough to attempt such attacks is probably more than capable of sending a valid request if they want. There are many browser plugins that allow for easy editing of forms which makes it hardly any more effort to edit a POST compared to a GET. In my opinion the gains in the slight increase in workload for an attacker do not outweigh the time and effort to implement, maintain and debug the obfuscation.

    I believe it is far more important to whitelist and sanitise any inputs, this is where your efforts should be focused. If a hole exists someone can find it no matter how well you conceal the entrance, far better to close the holes.

    That said if you want the peace of mind and are willing to expend the time and effort, any increase in security can only be a positive thing.

Re: Re: Modiying values in html form (OWASP)
by Anonymous Monk on Nov 03, 2013 at 09:33 UTC
      This was in response to:

      #!/usr/bin/perl -Tw
      use perl::always;
      my $perl_version = "5.12.5";
      print $perl_version;

        This was in response to:

        Nope, it was in response to your post taint :) The original post by kiat is from 2002 and kiat was last here 4 years ago

Re: Modiying values in html form
by Anonymous Monk on Nov 03, 2013 at 18:32 UTC
    You should store anything of value server-side (usually in a database or session), but the other way of protecting those is including a signature as a hidden field in the form. Something like sha1(concatenate($longsecrettoken, %importantformfields)) should be enough (but I'm not a cryptographer so don't quote me on that).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1061012]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (11)
As of 2018-03-22 14:52 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (277 votes). Check out past polls.