Direct URLs & delete confirmation forms

Question

I am seeking a best practice advice for implementing delete confirmation forms.

The following page, among other options, contains delete button...

/website/features/f/123

...when clicked a simple form gets loaded under following url:

/website/features/f/delete/123

A user has to confirm deletion in a simple delete confirmation form. Delete button gets enabled after the 'check to confirm' checkbox is checked.

All good and clear, however I am concerned that providing direct URLs to delete options may lead to... say, situations that could be avoided.

Is there a better way of handling this scenario? Perhaps referer validation?

What exactly is the threat you are thinking of? What do you want to protect against? Also how do you think referer validation would help with that? — Gabor Lengyel, Dec 05 '16 at 23:11
It would be easy to change id in the url to land directly on the delete confirmation page. I was thinking about something like this - /website/features/f/delete/123 would only be loaded if the referer would match /website/features/f/123 — Luke G, Dec 05 '16 at 23:40

score 3 · Answer 1 · edited Oct 07 '21 at 10:53

3

The most common "situations that could be avoided" are:

Bots following links (e.g. to precache results). Avoid this problem by ensuring that the URL requires a request to use an HTTP method that is not safe such as POST and not GET.
CSRF attacks as covered by this other question

edited Oct 07 '21 at 10:53

Community

1
1

answered Dec 06 '16 at 08:11

Quentin

914,110
126
1,211
1,335

score 2 · Answer 2 · answered Dec 06 '16 at 18:20

2

Actually deleting something should required the user to be logged in to the site and you should check that this user has the necessary permission to actually delete something. If your use case permit that something can be delete publicly, then it doesn't really matters if the confirm is checked or not (think trolls). If your user has the permission to delete something, then there shouldn't be any problem except if mistype something in the URL.

To avoid this you can also implement the DELETE http request (think REST). A combination of permission and DELETE should be enough to avoid bypassing the confirm dialog.

Another solution could be to implement validation token. The confirm dialog generate a secret token that needs to be validated by the delete action.

answered Dec 06 '16 at 18:20

Louis Charette

1,325
1
10
34

Yes, from OP's question, it's not clear if this is a _security_ concern, or a _user experience_ concern. Is OP trying to prevent unauthorized deletions (in which case a suitable access control should be implemented), or are they simply concerned about authorized users deleting something by accident, due to a poor interface implementation? It's also worth noting that Eloquent supports "soft deletes", which can allow deleted DB entries to be recovered. – alexw Dec 07 '16 at 17:20
Either way, my answer can tackle both concern. + 1 for soft deletes too. – Louis Charette Dec 07 '16 at 17:38

score 1 · Answer 3 · answered Dec 06 '16 at 08:05

1

I implemented my initial referer idea. But as always I am open for suggestions and constructive criticism.

if(empty($_SERVER['HTTP_REFERER'])) $this->_app->redirect('/website/features', 302);

Note that this is a slim based redirect.

answered Dec 06 '16 at 08:05

Luke G

1,741
6
23
34

1

This way it's not a security feature, it's more like a usability / UX thing. An attacker linking directly to the delete page or opening it in a frame will still succeed as the referer will be filled in. Also against an attacker, checking the referer is of limited use as under some circumstances referer can be forged. – Gabor Lengyel Dec 06 '16 at 12:08

Direct URLs & delete confirmation forms

3 Answers3