[Catalyst] Re: how to confirm before deleteing

[Aristotle Pagaltzis]

* Jesse Sheidlower  [2009-01-21 15:55]:
> What I typically do is have two separate actions, a "delete"
> and a "do_delete". The "delete" action merely displays the
> record and has a form (link, whatever) asking "Are you sure?",
> and then if they agree, you perform the "do_delete" that does
> the business.
>
> You could also have a single delete action but with a "confirm"
> parameter signalling that you're really deleting, etc. There
> are lots of options.
>
> You can pair this with JS if you want.

Best approach for pairing with JS:

Do the above, ie. if the user GETs the link, you send back a form
with POST and OK/Cancel buttons which they can use to POST the
delete request. *Then*, use inobtrusive JS to modify the links,
so that they first pop up a confirm dialog then submit a hidden
form if the user says OK.

That way users who have Javascript get asked OK/Cancel with a
popup and they send a POST immediately. And users who don’t have
Javascript get asked OK/Cancel on a separate page. And deletion
is safely shielded behind a POST action in both cases.

(I should make a jQuery plugin out of this sometime…)

First rule of web apps: merely following a link (or typing into
the browser address bar and hitting Enter) should NEVER EVER
result in a destructive action, no matter what URL the user
typed.

Remember that following links need not be intentional. Your
browser follows far more links automatically without telling you
than the number of links you ever actively click on: every image,
every stylesheet, every script, every frame, every Flash object
on every page you visit is downloaded automatically. Now consider
what happens if a malicious user puts

http://yourapp.example.org/addressbook/delete/all";>

into a page they control and then send a link to that page to
your users. If you allow destructive actions on GET, you have
just allowed for your users to be screwed over through no fault
of their own.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: how to confirm before deleteing

[Aristotle Pagaltzis]

* Carl Johnstone  [2009-01-22 12:55]:
> Aristotle Pagaltzis wrote:
> > http://yourapp.example.org/addressbook/delete/all";>
> >
> > into a page they control and then send a link to that page to
> > your users. If you allow destructive actions on GET, you have
> > just allowed for your users to be screwed over through no
> > fault of their own.
>
> Note that using POST rather than GET doesn't protect you from
> this specific problem - it's still possible to form a CSRF
> request with a POST action.

Yeah, but POST-based CSRF isn’t as cheap – you have to trick the
visitor into clicking a button or you have to set up the CSRF
attack in a place where you can put Javascript in the page. This
means you have to put some effort into it.

Exploiting non-idempotent-GET-based CSRF is extremely cheap. It
is so cheap that it any prankster can do it within 2 minutes. A
comment on a weblog that allows images in comments will do. A
comment on a LiveJournal posting will do. Shrouding the URL with
TinyURL or other shortening services and posting it to Twitter
or IRC will do. And on and on.

Avoiding GET for non-idempotent actions doesn’t make it difficult
to launch CSRF attacks, but it drastically reduces the number of
venues that can serve as attack vectors, and so excludes most
random pranksters from the pool of potential attackers. It also
avoids a lot of potential for accidental data loss due to various
kinds of programmatic agents. It’s just good web app hygiene.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: how to confirm before deleteing

[Carl Johnstone]

Aristotle Pagaltzis wrote:
> http://yourapp.example.org/addressbook/delete/all";>
>
> into a page they control and then send a link to that page to
> your users. If you allow destructive actions on GET, you have
> just allowed for your users to be screwed over through no fault
> of their own.

Note that using POST rather than GET doesn't protect you from this specific 
problem - it's still possible to form a CSRF request with a POST action.

Carl


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/