Protecting against URL Modification

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
Cross89
Forum Newbie
Posts: 5
Joined: Fri Jun 05, 2009 5:31 pm

Protecting against URL Modification

Post by Cross89 »

Hello folks, new here and I need a little bit of help. I've been developing in PHP for almost a year now. I'm also opening a business and I need to develop some software to help manage some dynamic site content. So I'm being, as the forum descriptions says, "anal" about every spec of my code.

The problem I'm facing is URL modification. I don't want anyone to let's say delete some content, then have the power to change the ID number and delete something else.

The way I'm combating this is by changing my data passing methods to POST as apposed to GET. I like to avoid GET as much as possible. So I wanted to ask some of the more experienced programmers out there how they handle this kind of issue.

P.S. I know I may have answered my own question, but with POST, I have to put hidden form fields in and the code can get a little messy from that.

Thanks,
Matt
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Protecting against URL Modification

Post by kaisellgren »

Cross89 wrote:I don't want anyone to let's say delete some content, then have the power to change the ID number and delete something else.
That's quite a big question. Can you show me some practical situations or tell me more specifically what are you trying to achieve?

Switching from GET to POST prevents nothing.
Cross89
Forum Newbie
Posts: 5
Joined: Fri Jun 05, 2009 5:31 pm

Re: Protecting against URL Modification

Post by Cross89 »

For example: main.php?mode=repair&action=deletereport&id=xx

1) User logs in and goes to view a report. That page has an option to delete that report.
2) User clicks on delete, passes ID through the URL to the final page.
3) User could copy link and continue deleting reports by changing the ID without actually being on the page itself.

Changing that to the POST method would prevent someone from simply changing the ID number in the URL to delete a report, would it not? It would force them to go to the report they actually want to delete, then click on the delete option.

I just want to know what people do to avoid this issue in general.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: Protecting against URL Modification

Post by matthijs »

You should check before deleting anything if the person being logged in has the rights to delete that item. GET or POST doesn't matter in this case
Cross89
Forum Newbie
Posts: 5
Joined: Fri Jun 05, 2009 5:31 pm

Re: Protecting against URL Modification

Post by Cross89 »

Yeah, that's true. I have a permission checker for that. I just want to stop URL modification so someone has to see a report first before they can delete at all. Its just me and my partner using it. But I want it really closed tight, since its for my business.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Protecting against URL Modification

Post by kaisellgren »

Cross89 wrote:I have a permission checker for that. I just want to stop URL modification so someone has to see a report first before they can delete at all.
So, this is not an issue of proper permissions, but rather an issue of CSRF and accidental clicks? Read more about CSRF: http://en.wikipedia.org/wiki/CSRF

Generally people create a random token and pass it into the form in a hidden input field as well as save it into the session. Then when the form is submitted, the token is compared against the value in the session. If the value does not match, the request is not processed.

As what comes to accidental clicks, a JavaScript alert() should be okay or anything similar.
Cross89
Forum Newbie
Posts: 5
Joined: Fri Jun 05, 2009 5:31 pm

Re: Protecting against URL Modification

Post by Cross89 »

Ah great. Thanks for the input Kai; much appreciated.
leonel.machava
Forum Newbie
Posts: 10
Joined: Fri May 15, 2009 4:28 pm

Re: Protecting against URL Modification

Post by leonel.machava »

Cross89 wrote:Hello folks, new here and I need a little bit of help. I've been developing in PHP for almost a year now. I'm also opening a business and I need to develop some software to help manage some dynamic site content. So I'm being, as the forum descriptions says, "anal" about every spec of my code.

The problem I'm facing is URL modification. I don't want anyone to let's say delete some content, then have the power to change the ID number and delete something else.

The way I'm combating this is by changing my data passing methods to POST as apposed to GET. I like to avoid GET as much as possible. So I wanted to ask some of the more experienced programmers out there how they handle this kind of issue.

P.S. I know I may have answered my own question, but with POST, I have to put hidden form fields in and the code can get a little messy from that.

Thanks,
Matt
Hello Matt!

To protect yourself against url modification and unexpected deletions I recommend you to display a message of confirmation to the user.

According to the W3C HTTP Especification, the GET method should be used only for retrieving things and should not cause side-effects on the server (idempontent operations). The POST method should be used for non-idempotent operations (that cause side-effects on the server).

If you use an URL like this http://example.com/main.php?mode=repair ... port&id=xx, then it should lead the user to a form that confirms if he wants to delete the specific item. After submiting the form the item would be deleted (side-effect).
Forms with POST method should be used to cause side-effects on the server. However, beware of CRSF (Cross Site Request Forgery). Please do what was suggested by Kai:
kaisellgren wrote:Generally people create a random token and pass it into the form in a hidden input field as well as save it into the session. Then when the form is submitted, the token is compared against the value in the session. If the value does not match, the request is not processed
If you need help implementing it let us know.

Leonel Machava
Post Reply