Storing previous URL as session data

[eluser]crikey[/eluser]
Hi guys,

Apologies in advance if this has already been covered - but I couldn't find any info about this.

My scenario:

I have a delete function which can be executed from a URL with parameter (eg. mysite.com/thing/delete/1 - where '1' is the id of the item to be deleted). That's cool.

But the delete function can also be called from various other URLs where the ids of the items to be deleted are in a POST variable (from checkboxes). In this case, I use form validation to make sure at least one item has been selected, and if validation fails I need to return to the page that the user was on - it might be a search results page, a page which lists the latest 'things' etc, and show the validation error.

I'm just not sure how to determine what page the user was on to redirect them if validation fails.

I'd like to be able to store the previous URL as a session variable - but not too sure how to do it. If it helps, I'm using a DB to store session data.

Any help greatly appreciated.

Thanks,
Grant

[eluser]erik.brannstrom[/eluser]
I keep on recommending the History library (http://ellislab.com/forums/viewthread/58091/). If you don't want to use the whole library you can always look at the code and see if it gives you any ideas. Check it out!

[eluser]janogarcia[/eluser]
@crikey This is the most simple method I've used:

Save the url string of every controller method that loads a view containing the link to the delete action.

Code:

set_cookie('history', $this->uri->uri_string(), '0');

Then, at the end of your delete action redirect the user back to the calling point.

Code:

redirect(get_cookie('history'));

Of course, you could use session variables instead of cookies.

For more advanced/complex scenarios check these community resources http://delicious.com/janogarcia/codeigniter+history

[eluser]n0xie[/eluser]
[quote author="crikey" date="1271162160"]
My scenario:

I have a delete function which can be executed from a URL with parameter (eg. mysite.com/thing/delete/1 - where '1' is the id of the item to be deleted). That's cool.
[/quote]
This is most likely CSRF exploitable. Never do destructive actions via GET.

[eluser]crikey[/eluser]
Thanks n0xie, I see what you mean (just did some reading on CSRF).

Question: is it possible that the same exploit could happend using CSRF, given that POST requests can also be made via an AJAX call?

I'm doing checks to make sure the user is logged in and the item being deleted belongs to the logged in user.

Thanks,
Grant

[eluser]n0xie[/eluser]
The answer is a bit difficult. There is a security check build in which prevents cross domain POST via Javascript. This used to be part of the whole security against CSRF. But lately it has become much easier to even do cross domain AJAX POST's as shown here and here so basically even though you have to jump through hoops to get it to work, cross domain javascript POST's are possible. The best thing you can do is rely on counter measures. You can read up on the subject here: http://stackoverflow.com/questions/298745/how-do-i-send-a-cross-domain-post-request-via-javascript

I’m doing checks to make sure the user is logged in and the item being deleted belongs to the logged in user.

These checks mean nothing to CSRF. To your webserver/website it will seem as if the user actually wanted to do the action, the browser will send whatever authentication you have on your site (cookie/sessions) and the damage will be done. For normal users, the damage may be as simple as just logging out, but if an administrator were to 'fall' for the exploit, it could mean he deletes every user in the database.

[eluser]Jondolar[/eluser]
It shouldn't be a problem to delete a record via mysite.com/thing/delete/1. Authenticate the user, then check to see if they are authorized to delete the record. If the user goes to the address bar and changes the 1 to a 2, just make sure they are authorized to delete that record. I recommend against using a "POST" vs. "GET" to determine if you are going to delete a record.

[eluser]erik.brannstrom[/eluser]
[quote author="Jondolar" date="1271207896"]If the user goes to the address bar and changes the 1 to a 2, just make sure they are authorized to delete that record.[/quote]

I'm no expert on this subject, but I believe the problem is when someone else than the user makes this change, which constitutes the actual attack. Say, another site that this user happen to visit while being logged into to the original site has an element like this:

Code:

<img src="mysite.com/thing/delete/25" />

Then this url will be loaded and the authentication goes well, since the session is in place, even though the user did not want to delete item #25.

[eluser]Jelmer[/eluser]
erik.brannstrom is correct.

There's nothing wrong with doing destructive actions using get, but you do have to secure against the kind of attack erik mentioned. It's not that hard to prevent:
- Create a unique code on the page from which the delete action is allowed to be undertaken (way to simple example: md5(time()))
- Save the code to a cookie AND put it in either a post variable or in the URL which deletes the entry (example: mysite.com/thing/delete/25/1f3870be274f6c49b3e31a0c6728957f)
- Check whether the cookie value and the URL or Post value match and only allow the deletion when they do match.

More structural ways can be found by Googling, searching the forums on CSRF and looking at the new CI2.0 Security class which includes a CSRF token generator and check function.

Edit: CSRF protection should be taken seriously and you should enable it site-wide. The best way is if you generate a new token on every page-load and include the token in the post or URL by reading the cookie using javascript. Another way is to give each token a limited time of validity before it needs a refresh, but that's more of a stop-gap measure then a really secure one.

[eluser]Jondolar[/eluser]
The point I was trying to make is that you need to validate that the person logged in has the authority to delete record number 25. If the user does have authority, then let them delete the record. If the user changes the url to record 100 and the user DOES have authority, then let them delete that one too. If the user DOES NOT have authority to delete record 100 then don't do the delete.

The key is to validate that the user is logged in AND has authority to delete the requested record. If the user does not own the record, don't let them delete it.