Page 1 of 1

Website security problems

Posted: Tue Sep 23, 2003 4:56 pm
by liviu
Hello everybody,

I want to know what are the posibilities for a person to hack my site online and how do i defend myself ? I excluded the option to post html code into posts (preg_replace() etc.) :roll: If no one can tell me then where do i find documentation for this problem of mine ?

the site in discussion is http://www.bitonline.as.ro (it is in romanian so please have mercy... :cry: )

Posted: Tue Sep 23, 2003 5:30 pm
by mr_griff
The Open Web Application Security Project (OWASP) has a good article on the "Top Ten Web Application Security Vulnerabilities". It's not directly related to php, but most of the examples apply.

You can check it out here:
http://www.owasp.org/documentation/topten

Posted: Wed Sep 24, 2003 2:17 am
by McGruff
The top ten applied to php: http://www.sklar.com/page/article/owasp-top-ten

A Study in Scarlet: http://www.securereality.com.au/studyinscarlet.txt

And of course read through the php and mysql manuals.

Are you using a database? The basics for securing the database are:

(1) Never allow your progam to connect as the root user. Create another user with only the minimum privileges required - and perhaps others (non-root) for admin level access. Keep the db conn scripts in an .htaccess protected folder (deny from all). If you can set a <directory> directive do that instead. http://httpd.apache.org/docs-2.0/howto/htaccess.html

(2) Always properly escape strings in db queries - mysql_escape_string, or addslashes.

(3) Always quote vars in queries eg:

Code: Select all

"SELECT col1, col2 FROM table WHERE col1='$var'"
If you expect the var to be an integer, and it originates from GPC input, it might not be an integer at all. An intval($var) strips out any text. I'd recommend always quoting it as well: not strictly required after an intval() but it's another layer of protection if you slip up one day and forget to force type.

I think one of those tutorials covers error reporting - if not, the rule is turn it down as far as possible on a live site so that an attacker cannot glean any useful information. (But always develop locally with the maximum E_ALL).

Posted: Wed Sep 24, 2003 2:26 am
by McGruff
PS: please don't double post.

Posted: Wed Sep 24, 2003 9:34 am
by liviu
OK, thanks'. If it, helps my site is hosted on a free-webhostin service (this means PHP safe_mode=on)