PHP Freaks

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

a great article,
definitely bookmarked.

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!

Great tutorial - explains alot of technical stuff definately recommended

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?

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.

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.

Views: 17435 lol

One part is missing, security problems related to emails.

good stuff!

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

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

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

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

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

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 :)

the pdf article for download just gets a 404

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

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

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

Note some shared hosts has it disabled by default.

hi
can you please explain how to build the log_errors file?

I don't understand your question. The log_errors directive simply turns logging of errors on or off.

so there is no need to write a file? you write: error_log: this is the path of the file......
i understood that i need to write some sort of a file. if not how do i know the right path?
best regards

Sorry, I don't quite understand the structure that you are talking about.
/application
/controllers
/models
/views
/library
/public_html <-- document root
/index.php
/media
/images
/javascript
/css
/config
/cache
/tmp
/public_index.php
/logs

I've never really done a live site so I am confused as to how the layout would be on a server that is shared. Lets say I'm on a shared server and they give you your little section that just contains a index.html/php file. How would you set up your site structure?

The structure was just a sample structure. It doesn't have to be laid out exactly like that, obviously. The idea is just that the majority of the files (i.e. all those files that aren't meant to be accessed directly by the user) should be placed above the document root. In that way they can never get to them. Imagine a misconfiguration on the server that would cause all files to be served in plain text. This would expose your configuration files, which would be bad if it contains things like database credentials. It would also expose your source code, which would be a security issue as well (unless you're just using some open source application, which would have the source accessible anyway).

If your host only allows you to store things within the document root then you'll obviously have to - or you could switch to a better host. I believe most proper hosts (that would exclude free hosts) allow you to do that.

Thanks for the reply.