Re: Form submit hash keys

Marcel van der Boom wrote:
> On 23 feb 2009, at 16:46, Jason wrote:
> 
>> *IF*. In the majority of cases it is not.
> Agreed, but security measures cover the minority gaps as as a rule :D
> 
> 
>>> How do you propose to distinguish the accident vs the real abuse?
>>
>> I don't. That is up to the user. The user is given a form with data
>> in, and a
>> message at the top saying "this form was not accepted - please try
>> again or
>> cancel". If the user knows he is trying to submit a form, then they
>> can try
>> again. If the user gets this after clicking a dodgy link, then they
>> can cancel
>> (not only that, they can see the data that was present in the submission
>> attempt, so have a better chance to trace its source).
> 
> Ok, let's take the dodgy url usecase.
> 
> What happens when:
> 1. user clicks dodgy url
> 2. data gets refused because has doesn't match up.
> 3. form is redisplayed to user with data, let's assume the evil is
> hidden cleverly

+------------------------- red -------------------------------+
| KEYS DO NOT MATCH - PRESS SUBMIT IF KNOW WHAT YOU ARE DOING |
+-------------------------------------------------------------+

> 4. user clicks submit.

I guess they know what they are doing?

> Assuming we dont go any further with measures (like a captcha), you now
> have a path to turn a dodgy url into a valid submission, no?

I think the error message will be enough. Just making the hack a two-stage
process, with an obvious message to the user will be enough to offer the
protection that the hash keys are designed to offer.

I guess the real dangers are where the submitted data contains some JavaScript
that, when displayed in the re-presented submit form, could execute some code in
the context of the page (perhaps an auto-submit - dunno - can JS do that?)

-- Jason