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
Protecting against URL Modification
Moderator: General Moderators
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Protecting against URL Modification
That's quite a big question. Can you show me some practical situations or tell me more specifically what are you trying to achieve?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.
Switching from GET to POST prevents nothing.
Re: Protecting against URL Modification
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.
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.
Re: Protecting against URL Modification
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
Re: Protecting against URL Modification
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.
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Protecting against URL Modification
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/CSRFCross89 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.
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.
Re: Protecting against URL Modification
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
Hello Matt!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
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:
If you need help implementing it let us know.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
Leonel Machava