
Guidelines to Lock Down Your Website - ajbatac
http://designreviver.com/tips/php-security-guidelines-to-lock-down-your-website/
======
abyssknight
As much as these guidelines, in general, are good there are a few things that
are just a little wrong.

1\. Addslashses is not a good solution to SQL Injection. It might be good to
invest in a database abstraction layer, or an ORM that will do prepared
statements without thinking twice.

2\. Strip_Tags is not a solution to XSS. I prefer using something like WMD,
Textile, BBCode or Wiki formatting for user input and then kill everything
else with fire.

3\. Removing JS and Flash from output using an RE is not a solution. If you're
blacklisting, it probably won't work. These exploits have been around forever.
Maybe Anti-Samy can help.

4\. Referers can be spoofed. Although, this is a good "honesty first" check.

5\. If you are using crypt, you are doing it wrong. Very, very wrong. After 8
characters, you're practically in plain text.

------
ecaron
Blog about website design + blog post about website security = Excellent
source of well-intended data that perpetuates PHP code that people think is
secure

For a better post on securing PHP scripts, see IBM's post at
[http://www.ibm.com/developerworks/opensource/library/os-
php-...](http://www.ibm.com/developerworks/opensource/library/os-php-secure-
apps/) or just see [http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-
re...](http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-
string) to understand why anyone recommending addslashes should be ignored.

