Tutorials

PHP Security

by Daniel Egeberg on Jun 30, 2008 12:40:06 PM

8. Cross-site request forgery

Cross-site request forgery (CSRF) is when you trick the user into making a request they have never made. Imagine that in your application it is possible to delete users like this: /user/delete/Joe. That would delete the user with the username "Joe". A malicious user might place this bit of HTML on his website:

This will basically trick the user into making a request to that page without them knowing it. Obviously only people who are logged in as administrators should be able to call this URL and therefore it will fail for most users. However, if a logged in administrator goes to the page where the above piece of HTML is located then the request will be successfully completed and "Joe" will be gone.

How can we prevent this? Well, in this case we could simply ask the admin to verify the action with his password before performing it. Yes, I know, this is kind of like Windows Vista's UAC (User Account Control) that people claim is incredibly annoying and prompts them to verify their action every fifth millisecond, but sometimes you will, unfortunately, have to add just a little amount of nuisance in order to keep your application safe.

Had the account come from a form then we could simply require that the information (in the previous case the username) be submitted using post and read it like $_POST['username']. However, this adds only a minimum of extra security. More sophisticated attacks than the above could just as easily trick the user into performing a POST request instead GET. We could use the "enter your password" method like before, but we could also use another kind of token. Imagine this form:

Here we have added a hidden field called token and stored its content in a session. On the next page we can do something like this:

We simply check that it is a valid token and we have then successfully ensured that the request did in fact come from the form.

Comments

You wrote a very nice tutorial here. I'm going to keep all these security advices in mind.

1. John McKenzie on Jun 30, 2008 4:07:27 PM

a great article,
definitely bookmarked.

2. HoTDaWg on Jul 1, 2008 9:46:22 PM

I actually created a post in the Forums asking where to find a good tutorial on PHP security: it was right here on the home page!

3. rupertrealbear on Jul 2, 2008 6:40:55 PM

Great tutorial - explains alot of technical stuff definately recommended

4. Wasim Ilyas on Jul 11, 2008 8:36:42 AM

about the mysql injection, how would such a user find out the name of the table/structure of the table so they could put something to damage the database?

is there a way of stopping them finding out the database/table structure?

5. Flames on Jul 24, 2008 8:36:44 AM

Flames: It could be guesswork, but there are also queries that will allow you to see how the tables are laid out. It could also be an open source app, and it that case it would be as simple as checking the source.

6. Daniel Egeberg on Jul 24, 2008 10:00:29 AM

k, i've been trying to stop mysql injection and although its taken time i finally got it to work without random apostrophes being put in places :D.

7. Flames on Jul 24, 2008 11:07:42 AM

Views: 17435 lol

8. dezkit on Jul 26, 2008 9:14:19 PM

One part is missing, security problems related to emails.

9. Hervé Thouzard on Jul 27, 2008 3:11:32 AM

good stuff!

10. libertyct on Jul 28, 2008 10:44:46 AM

Im happy I found this tutorial - dont understand lots of stuff but will re-read so that it sits.

11. Dorothy Wegmueller on Aug 5, 2008 6:14:18 PM

Well, feel free to ask in the forums if there is anything specific in the tutorial you need help with :)

12. Daniel Egeberg on Aug 5, 2008 7:53:32 PM

Very nice tutorial indeed. It is very helpful for newbie's like me.

13. cyberbuff on Aug 11, 2008 4:57:40 AM

Excellent tutorial. I've had experience with other scripting languages and decided to try PHP. This is really a great start what to look out for and how to design with these dangers in mind.

One question about the include(), mostly for db access. Some showed using a config.pm that would contain passwords to the db.

Would you consider this secure?

mkdir public_html/secure
chmod 711 public_html/secure
create the config.pm containing the db access

in the php script, I add
include('../secure/config.pm');

Would it be better to not be in the document root at all?
I notice in the tree, the config dir is in the system root, not doc root.

Thanks

14. budman85 on Aug 12, 2008 8:11:32 PM

The safest way would be to not place it within document root at all.

15. Daniel Egeberg on Aug 13, 2008 11:10:32 AM

Daniel, great article, was a good read and learned a lot (implementing some of this stuff as I'm writing this.) In doing so, I've noticed that the error_reporting and error_log statements in .htaccess files seem to not work unless they are preceeded by php_value, and not php_flag as stated in the article. Feel free to correct me if I'm wrong, I just thought I'd point it out in case anyone else ran into the issue.

Thanks again :)

16. vnums on Aug 15, 2008 11:15:05 AM

the pdf article for download just gets a 404

17. Brad Floyd on Sep 17, 2008 11:13:51 PM

Ooops... sorry about that. It's back up now.

18. Daniel Egeberg on Sep 18, 2008 1:25:08 PM

cool :-) Just thought I'd point it out since security is one aspect people need to pay more attention to I agree

19. Brad Floyd on Sep 18, 2008 7:34:22 PM

However, wouldn't RFI only be an issue if PHP - Register globals is turned on?

Note some shared hosts has it disabled by default.

20. BlueBoden on Nov 11, 2008 4:20:41 AM
Login or register to post a comment.