Security Holes

[anthonyjpv]

Aside from sql injection

if I sanitize data before querying or sending it to a database

are there any issues that needs to be addressed concerning security of a web app?

im building an e commerce from scratch as part of a school project using notepad++ and xampp.

any recommendations?

is there a site aside from owasp that i could browse?

is there a site that evaluates php code looking for security holes?
thanks!

well, there are great security resources online, but if you can stretch to it, get a book. I bought one a few years ago called PHP and security - really good. I didn't understand half of it though! :)

One piece of advice I've found very useful is keep all your non-visible files, like include and config files, above the document root. Never keep any sensitive data in the doc root.

Perhaps look at CSRF and XSS. Look to nail down your http requests with strict validation and check data types.

Check the chmods of folders and files - make them as strict as possible.

You could spend half your life working on bumping up the security, but as you're doing a school project and limited for time, try:

#form and querystring validation
#place all non-visible php files above docroot
#tighten chmods
#switch off error reporting once live
#trap all errors wherever possible and provide a way for the user to safely return to a navigable page.
#hash all user passwords

I bet there's tons of other stuff too.
//EDIT
perhaps an idea to place a blank index page in each docroot subfolder too.

http://www.wiscocomputing.com/articles/using_htaccess.htm

[weekendrockstar]

ardav gave you good pointers. Beyond those make sure that you make all table columns in your database the correct type so that it will save ONLY the type of data that you want. If you are storing an ID number such as a user's ID number or something like that you'd want that column to use TINYINT or INT depending on how many characters long you believe that an ID number could possibly get. Set maximum characters for each field also. Just think of the largest number of characters that would ever need to be entered in.

If someone tries to enter something that they shouldn't such as PHP to 'hack' your site into a field that is expecting numbers the database won't allow it. And by setting the field's max characters it will chop whatever they were trying to submit at the max number. It is easiest for them to try to enter such code into a textarea which will usually allow the largest number of characters so it is also important to run all kinds of sanitation on data from a textarea also.

And as ardav suggested check the data type such as if an integer was supposed to be entered into a form field that the data sent through the form was, in fact, an integer. This is good practice because even if the database won't save the wrong type of data for the field you'd end up getting mysql errors. But if you test everything and create an error array in an error function and have it run if there were errors...then it is much cleaner for the submitter of the form. Plus if it is someone who is trying to do something malicious the site will signify to them that your code is actually checking the input and that you've made it as hard as you could for them to do what they want.

As is always the case if someone really wants to do something malicious they'll try to find a way and new things pop up. A good idea is to write or find a function online to which you can pass ALL incoming form data to and it will 'sanitize' each variable/string which you send to it and return the cleaned up version which you can then enter into the database. I've found several functions online with good documentation that you can insert into every php page that accepts form input and this way you do not have to code to sanitize each and every piece of data manually. Plus if another vulnerability should ever be uncovered and a way is found to eliminate the threat you can easily add that code into the sanitizing function and you won't have to add it repeatedly for every piece of data that your overall web app accepts.

The general idea is to figure out as explicitly as is possible exactly what an acceptable response would be in a form input and make your code as strict as you can. Basically you want to KNOW what a user will input. Which is why people will write functions to check on submitted input in an e-mail field. You would want the user to enter a valid e-mail address so you want to run as many checks as you can to make sure, to the best of PHP's ability that it is, in fact, a valid e-mail address. They will check to make sure that necessary things that make up an e-mail address are present such as an "@" and will often check to make sure that that it is from a top-level domain. They will check for special characters or anything that isn't allowed in an e-mail address as an appearance of them would suggest that it is a fake e-mail address. Some will even create an array of acceptable top-level domains such as .com, .net, .co.uk, etc but that can go a little far because someone could be using a very real e-mail address but not one that's in your list. So basically they check for everything that a valid e-mail address should have and the only thing that really can't stop is someone inputting a made up e-mail address with an existing e-mail service which may or may not actually belong to someone else even if they made the address up. So to combat that most sites require a validation link to be clicking inside an e-mail sent to that address. So that fully verifies that the e-mail address does indeed exist and that the person HAS access to it. The only thing that doesn't stop is someone using a hacked account. But as a developer you are expected to check everything to a certain extent...but you can't be held responsible if someone creates an account or something where you verify address from a hacked e-mail account.

So again, just figure out the best that you can exactly what should be supplied and do your best to make sure that that is exactly what is entered.

Sorry that this was so long-winded but things just kept popping to mind.