I would consider this a critical priority feature request. After a webform submission, I have webforms configured to send an email to the user (either a registered user, or anonymous user) for later editing of their submission. The problem is the URL contains a submission number that corresponds directly to their actual submission number. E.g.,

http://qqqq.com/node/1111/submission/2292

(where #2292 was the actual submission #)

This presents a security problem because simple URL editing of "2292" to "2291", etc. will show previous submissions. Doesn't take a hax0r user to figure that one out, which obviously compromises data that was thought to be privileged.

Using even a primitive algorithm to move around numbers, increment/decrement digits, change numbers to characters, etc. would probably prevent most hacking of the URL to see other submissions.

Obviously implementing this would screw up the upgrade process for existing webforms...so this could be an option in the webform config so new webforms can use this more secure method.

Comments

mgenovese’s picture

mgenovese CreditAttribution: mgenovese commented

PS - I looked around in the features + bug reports, and didn't see anything addressing this issue. If it's a duplicate, sorry in advance.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Priority: Critical » Normal

Users can't see others submissions, we have permission checking for that. Webform would never leave such data available for such easy viewing of others data. That's why we have permissions for "view own submissions". The only potential reason for changing this number that I've heard in the past is that some administrators don't want users to know how many submissions have been filled out. In which case I'd suggest manually inserting a very high value (like 100,000) so that the auto-increment starts from that value.

mgenovese’s picture

mgenovese CreditAttribution: mgenovese commented

But I can do it when submitted anonymously.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

Yes, all anonymous users are considered the same user. I'd suggest not allowing anonymous users to view/edit their own submissions.

mgenovese’s picture

mgenovese CreditAttribution: mgenovese commented

OK then. However, handling anonymous users is a key feature of the module. I'd still hold to the assertion that a 1-to-1 scrambling / descrambling of the submission ID has obvious benefits...which address my issue, and the other you mentioned (preventing a means to calculate the # of submissions made).

Something simple, like taking the submission ID and turning it into a base-36 value (26 letters + 10 digits), and transposing some digits before and after the conversion would be probably good enough. Just a thought.

Thanks.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

Making a pattern for submissions still wouldn't be very acceptable, since it wouldn't truly be secure if the pattern could be reproduced. I think we've really just crossed over to an existing issue, which proposes a much better and secure solution: #277870: Handle retraction of submission based for anonymous responders via email..

mgenovese’s picture

mgenovese CreditAttribution: mgenovese commented

Yes, a hash would work just as well. The point is we need something, be it something relatively secure, or "more" secure. Thanks...

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Active » Fixed

Being "relatively" secure doesn't really cut it in the Drupal world, lest I get reprimanded by the security team. I'm marking this duplicate since it's the same request as #277870: Handle retraction of submission based for anonymous responders via email..

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Fixed » Closed (duplicate)