The basic idea is that want to scrub and verify all user input before using such data as part of any crucial code. Two big concerns are that you don't want to ever use unsanitized data in database queries, and you also don't want to let users store their own unsanitized custom messages where the messages would be visible to any other user. If you always assume that every bit of data returned from users is tainted, then you're in the right mindset for establishing a secure site.

You want to prevent SQL injections by verifying user data before ever using it as part of queries. The mysql_real_escape_string function is a good start for that, but it does have some obscure weaknesses (like the GBK vulnerability). If you are familiar with regular expressions (regex), you can do even more. I, personally, coded my own scrubbing function, and used the php.ini file to disable functions (mostly those that access the command-line). In addition to this, having properly configured database user accounts will help. Ideally, I like for the database access which is available to my users to only have database-specific SELECT and INSERT privileges; I definitely avoid giving the crucial MySQL global privileges like "FILE", "GRANT", "CREATE USER", "SHUTDOWN", and "SUPER".


The best way to prevent XSS attacks is by stripping all HTML tags from any input that can be entered by users that will be visible to other users -- this includes forum posts or profile page decorations, etc. You'll want to have your own "white list" of allowable script codes, something like [b] for bold and [size=5] for bigger fonts, etc. After stripping out HTML tags, your code can look for these tags that you've custom-defined and replace them with proper HTML. Giving users access to the [script] tag is pretty dangerous. (lol .... I just noticed that Mahalo won't even display the "script" tag if I put it in angle brackets. A perfect example of what I'm referring to here about how you should be careful with it.)


A lot of this stuff will already be handled for you if you use some sort of pre-built CMS package, but of course, they may have bugs that allow security problems.
Source(s):
Basic problems and solutions:
http://www.securityfocus.com/infocus/1768
http://74.125.47.132/search?q=cache:MNkBVKmv8oEJ:php.robm.me.uk/&hl=en&...

MySQL privileges:
http://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html

Multibyte character set vulnerability:
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-strin...

Disable functions:
http://us.php.net/manual/en/features.safe-mode.php#ini.disable-functions

Asker's Rating:

Permalink | Report