2

The following is a note from Professional ASP.NET MVC 2 by Scott Hanselman ++

You might ask — why did we go through the effort of creating a <form> within our Delete Confi rmation screen? Why not just use a standard hyperlink to link to an action method that does the actual delete operation? The reason is because we want to be careful to guard against Web-crawlers and search engines discovering our URLs and inadvertently causing data to be deleted when they follow the links. HTTP-GET-based URLs are considered safe for them to access/crawl, and they are supposed to not follow HTTP-POST ones. A good rule is to make sure that you always put destructive or data-modifying operations behind HTTP-POST requests.

If web-crawlers and search engine have no access to the page containing deletion button, is it safe to use a standard hyperlink to link to an action method doing the actual delete operation?

skaffman
  • 398,947
  • 96
  • 818
  • 769
Second Person Shooter
  • 14,188
  • 21
  • 90
  • 165
  • Why did they choose the POST method when there are a DELETE http method? I mean, they did go through the hassle to use POST instead of GET. It's no more complex to use the DELETE than POST. – jgauffin Dec 21 '10 at 08:37
  • Answering my own comment: http://stackoverflow.com/questions/165779/are-the-put-delete-head-etc-methods-available-in-most-web-browsers – jgauffin Dec 21 '10 at 08:38

6 Answers6

3

Yes, it's safe if a search engine can't reach it. But make sure to include some sort of confirmation or undo function. Links are easy to mis-click.

John Sheehan
  • 77,456
  • 30
  • 160
  • 194
  • providing undo after committing deletion will be hard, right? – Second Person Shooter Dec 21 '10 at 08:02
  • 2
    Rather than actually deleting the record from the database, set a field such as 'deleted' to true. Only show those items who's 'deleted' flag is false. You can set this flag to false again to undo. – Michael Shimmins Dec 21 '10 at 08:15
  • @Michael, If don't delete rows, and define a "IsDeleted" column for all tables in my database, I will make me do more job such as doing deleted mark cascade rule whenever the parent table row is marked as deleted. – Second Person Shooter Dec 21 '10 at 08:30
  • 1
    Remember that javascript confirmations on links (`onclick="return confirm('Are you sure?');"` will not work with spiders. – jgauffin Dec 21 '10 at 08:41
  • 1
    @xport - yep will result in more work. Gotta assess the trade off - is it something users need? Is it going to add value? If not, don't do it. In our app, trust is a huge deal so we never really delete anything. Our users aren't scared of clicking buttons, cos they know they can 'undo' anything. – Michael Shimmins Dec 21 '10 at 09:38
3

A good rule of thumb is that GET shouldn't change data. If you want to change some data you use POST.

That is why ScottHa etc used a form to submit the delete. If it doesn't work for your app you can use GET if needed.

Alternatively you could use JavaScript to submit the form whe the user clicks link.

Michael Shimmins
  • 19,961
  • 7
  • 57
  • 90
  • 1
    Correct, any GET request should not have side effects (this is called idempotence). Also, if you use a link to delete something, redirect after the delete is done and the user hits back, they won't be prompted to re-submit the action again. But as far as the original question goes, you can safely use a link if no search engine will hit it. – John Sheehan Dec 21 '10 at 08:38
2

I would add what even if admin page is protected by password, delete links could be "clicked" by some locally installed web accelerator software. So using POST method is safer.

Alexander Prokofyev
  • 33,874
  • 33
  • 95
  • 118
  • @alexander, how can we make a get request for a password protected page? it sounds interesting for me! – Second Person Shooter Dec 21 '10 at 09:22
  • 1
    @xport - the same way you make a GET request for a non-password-protected page. – Andrew Barber Dec 21 '10 at 10:21
  • @Andrew, is it really possible? I have not known it before. – Second Person Shooter Dec 21 '10 at 10:28
  • 1
    @xport - that would be because you are not aware that a page being password protected has nothing at all to do with what HTTP method you use to access it. – Andrew Barber Dec 21 '10 at 10:30
  • @Andrew, my terminology of "password protected pages" means only successfully authenticated users can access the pages. I hope we have the same understanding of this term first. – Second Person Shooter Dec 21 '10 at 10:38
  • 1
    @xport - your web sites must be fascinatingly (and needlessly) complex, if password-protected pages can not be accessed via GET... – Andrew Barber Dec 21 '10 at 10:41
  • @Andrew, shortly speaking, can you view someone's paypal page? It is just an example. I don't know whether we are talking the same things. Sorry. – Second Person Shooter Dec 21 '10 at 10:49
  • Yes; mine. Via GET requests, after I log in. Why do you think GET requests don't work for password protected pages? Where do you get that idea from? It's just plain incorrect. – Andrew Barber Dec 21 '10 at 10:53
  • @Andrew, after authenticated, it is a different story :) – Second Person Shooter Dec 21 '10 at 10:55
  • @xport - Umm... now it's my turn to ask you; Do you know what "authenticated" means? *Of course* you have to be authenticated to view a page that requires you to be authenticated... dare I say, "Duh". But again: That has *nothing at all* to do with whether you use GET requests or not. – Andrew Barber Dec 21 '10 at 10:57
  • @Andrew, I am who I said I am. My turn: If you haven't been authenticated using my credential, is your effort harmfull to make a Get request to my paypal page for example? – Second Person Shooter Dec 21 '10 at 11:01
  • @Andrew, I go home now and will be back 2 hours later. – Second Person Shooter Dec 21 '10 at 11:05
  • @xport - No, it's not 'harmful'. You *really* need to find yourself a basic HTTP guide to read or something; you don't seem to be able to grasp even the basic relationships between things involved. – Andrew Barber Dec 21 '10 at 11:08
  • @Andrew, if you are not logged in as an admin for example, how can you click the delete hyperlink on the admin page? you cannot access the page right? – Second Person Shooter Dec 21 '10 at 11:22
  • @xport - Duh. But if the `Delete` is a simple hyperlink, guess what; XSRF! But what about the page that you are viewing that link on in the first place? Even THAT page requires you to be authenticated. Yet, you probably view that page with a simple GET request. **Bam!** There you have it: A GET request for a password-protected page. It's like fairy-dust magic! So beautiful.... – Andrew Barber Dec 21 '10 at 11:24
  • @xport - Seriously; you aren't getting it at all. This isn't helping. Read up in that book about XSRF; it will tell you how someone can even make you "click" a GET link *while you are logged in* from your own browser, without you even knowing. Maybe look up "Confused Deputy" attacks, CSRF/XSRF, etc. – Andrew Barber Dec 21 '10 at 11:30
  • @Andrew, I am figuring out what XSRF is first. – Second Person Shooter Dec 21 '10 at 11:34
  • @Andrew, I think we are talking slightly two different things. I am talking about a situation where you have ABSOLUTELY no access to my protected pages. Or more precisely, you have no chance to do exploitation. How can you make a GET request? We are out of sync. But I admit your info about XSRF is helpful! Thanks for that! – Second Person Shooter Dec 21 '10 at 11:52
  • @xport - My info on XSRF is only helpful if you understand it. Which you clearly do not - otherwise you would not have asked that question. XSRF vulnerabilities are precisely about me making *you* do a GET request via your own login, for me. It's as simple as posting a stray `` tag on a site I know you visit all the time, the `src` of which points to a GET url that *you* will be logged in and authorized to request, and you'll never know I did it. The simplest solution is to maintain those idempotent GETs. – Andrew Barber Dec 21 '10 at 12:17
  • @Andrew, I have read and understand how CSRF works. It works only when you can exploit my session which is beyond the scope of my question. :) – Second Person Shooter Dec 21 '10 at 14:08
  • @xport - Whatever you say. Give me the URL of your first public site sometime, and I'll demonstrate just how little you understand. Otherwise, I'm done here. – Andrew Barber Dec 21 '10 at 14:11
  • @Andrew, I will ask you to exploit my testing site, hopely finished 2 months from now :) I promise! – Second Person Shooter Dec 21 '10 at 14:14
  • Of course I will provide you with a "private or password-protected" page containing a hyperlink to delete my records or more extremely to drop my database. – Second Person Shooter Dec 21 '10 at 14:27
2

If you use GET requests to do any changes to your database at all, you will more than likely get hit with Cross-Site Request Forgery attacks at some point. The book you are reading discusses that more, and I have a few posts about it on my blog. It's an extremely common vulnerability I find these days; as frequent as SQL Injection, and much simpler to exploit.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
1

There's a good reason not to use GET for operations which change data. It's not just for semantic purity. http://haacked.com/archive/2009/01/30/simple-jquery-delete-link-for-asp.net-mvc.aspx

Haacked
  • 58,045
  • 14
  • 90
  • 114
-1

@xport: POST take 2 times to executed one action, and GET only take 1 time. In POST, the first time, it will contact to server for authenticate action, and after that it will executing this action. In GET situation, it only call to action that not authenticate. So in usual, POST spend more time to execute action than GET (2 round trips). If you have some actions as DELETE, UPDATE, ADD,... you must execute it with POST and if some actions only select data from database, only GET. That is my understand in GET and POST.

thangchung
  • 2,020
  • 2
  • 17
  • 28
  • 2
    @ThangChung - Your understanding of GET and POST is not correct. – Andrew Barber Dec 21 '10 at 10:20
  • 1
    I think I wrong when explain about message authentication. The difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body. http://www.cs.tut.fi/~jkorpela/forms/methods.html – thangchung Dec 21 '10 at 11:05
  • "Authentication" has nothing to do with it; do away with that word when talking about GET or POST. Your comment above is basically correct, though worded clumsily. Your answer above, though, mentions things that aren't really related to the difference at all; such as authentication, POST being two requests, POST taking 'more time'. There are related grains of truth here or there, but a comment really can't elaborate on all of that. – Andrew Barber Dec 21 '10 at 11:12
  • 4
    *POST takes 2 times to execute one action* This is not strictly or necessarily true. In fact, the typical pattern is that a GET request happens first, and from that page a POST request is made. Strictly speaking - that is one GET and one POST... not POST taking two times. The essence of what you mean seems to be "you have to make an extra request to do a POST", but even that's not actually correct in this context: To submit the same data via GET in a typical scenario, you would ALSO need to first make another GET request, too. – Andrew Barber Dec 21 '10 at 11:16