W3hobbyist

PHP-MySQL is great server side duo. But when designing an application, utmost care needs to be observed. With time, most web programmers learn about common things such as cannot send headers, mysql_query() is not a valid resource, unexpected T_IF VARIABLE, etc. However, some mistakes are less known and less publicized which leads to repetition of these mistakes.

1. Trusting a cookie: While most programmers will validate GET and POST data, they will often forget to validate COOKIE data. It is easy to forget cookie data because cookies are not so interactive or conspicuous as a form that is supposed to collect GET or POST data. Always use the following 2 functions when the data is supposed to reside in the database: mysql_real_escape_string() and htmlspecialchars().
2. File uploads: Uploaded files should never be stored with their original name and extension. The file name can be a randomly generated string that the user is not aware of. Store the files with an extension which the server is not aware of. Eg: A typical good file manager script will store the uploader file with a name such as hn32hyy3h4oiuc828y3h21ioe409u.ATTACHMENT. Don’t generate this random file name string using the md5() or sha1() or mh5_file() or sha1_file() functions. While serving a download, don’t expose the upload folder on your website. Instead use a download script which commonly takes its inputs like: download.php?file=11e561vc5sdf
3. Error reporting: While error reporting is the only rapid solution to get a clue about errors, it should be switched off on the production server. Obviously, it is needed on the development server though. I have come across multiple websites that generate lots of error and allow the public to read those error lines. You may invite full path disclosure exploits. Use error_reporting(0) to prevent exhibition of errors. The question now is ‘If errors are not displayed how would I know where the error is?’. You can check out your error_log file to get an answer for that question. Remember to check the error_log file in the same directory as the script because every directory has its own error_log file.
4. Timing out of scripts: While it is expected that scripts will do their function within a stipulated amount of time, its not always true. The script can take longer than expected time and may even exceed the tile limit and thus not generating any useful output. Mailing scripts, search scripts and other mass action scripts are more prone to such weaknesses. It can be overcome by time limits over execution using the set_time_limit() function.
5. Editing php.ini file: Whenever possible, avoid editing php.ini file. Not all programmers really look deep into it to check for non-default values and assume default values. So if you change programmers in between a project or the new programmer is unaware of the variations in php.ini file, your application may develop ’security holes’. If you need to change the settings for a particular script or few of them, always prefer using PHP options and information functions.