Ways I can protect my site excluding XSS and Sql injection?

Question

Hi,
So, members of my website can post topics, replies, comments, edit them and so on. I always use htmlspecialchars and addslashes for html inputs to protect my site against XSS and SQL injection attacks. Is it enough or is there something more I miss?
Thanks.

Answer 1

A better approach to protect against SQL injection is to use the escape function specifically written for each database - for example, for PostGreSQL use pg_escape_string to escape string fields before inserting them in to the database. Or in your case, use mysql_real_escape_string.

Answer 2

You should use mysql_real_escape_string() for SQL, not addslashes. (Assuming you are using MySQL)

Answer 3

You should use prepared statements (see PDO) to prevent SQL injection. When outputting the content htmlspecialchars() seems sufficient to prevent XSS.

Also take a look at these links for more ways to protect your site:

http://phpsec.org/projects/guide/

http://cwe.mitre.org/top25/#Listing

http://www.owasp.org/index.php/Top_10_2010-Main

Answer 4

When inserting data into database, use prepared statements. PDO are better than mysql_real_espace_string.

When displaying data, such as comments, posts, use htmlentities.

Answer 5

SQL injection:

1. No addslashes nor mysql_real_escape_string could help alone. But only when used according some rules. And even then it's not enough. So, that's why prepared statements are way better for newbies - it require no thinking.

2. Both escaping and prepared statements can help with data only. For the operators/identifiers there are distinct rules. (Not a big deal though - every possible combination must be hardcoded in the script)

XSS:

Do not allow users to use HTML.
To prevent this, both strip_tags() (with no allowed tags) or htmlspecialchars() can be used.
If you want to allow some markup, consider a BB-code use.

CSRF:

Any significant form must contain an unique token, which should be compared to one, saved in the session.

Answer 6

There is a lot that can go wrong with a web application. Other than XSS and SQLi, there is:

1)CSRF - Cross Site Request Forgery
2)LFI/RFI -Local File Include/Remote File Include caused by include(), require()...
3)CRLF injection in mail()
4)Global Variable Namespace Poising commonly caused by register_globals,extract() import_request_variables()
5)Directory Traversal: fopen(), file_get_contents() file_put_conents()
6)Remote Code Execution with eval() or preg_replace() with /e
7)Remote Code Execution with passthru(), exec(), system() and  ``

There is a whole family of vulnerabilities regarding Broken Authentication and Session Management which is apart of the OWASP Top 10 that every web app programmer must read.

A Study In Scarlet is a good black paper that goes over many of these vulnerabilities that I have listed.

However, there are also strange vulnerabilities like this one in Wordpress. The definitive authority on what is a vulnerability is the CWE system which classifies HUNDREDS of vulnerabilities, many of which can affect web applications.