How Can Site Get Hacked If You Protect All Get And Post Inputs ?

[Eritrea]

I just don't get it. If you protect the above two, other than server hacking, or if you have file uploads,

what other ways are there for a user to hack your site. Even if the user knows the directory structure of the site?

 

I built my site, and I'm about to upload it, My hosting company is one of the best, and I don't have file any uploads in the site, So, what more would you watch out for, if you were in my solution?

 

 

btw, I am using mysql so, by inputs I mean all (GET & POST ) are protected with regex, htmlentities, mysql_real_escape_string()

 

functions.

 

 

 

 

 

 

 

thanks in advance

[requinix]

So basically your question is what else you have to worry about besides user input (assuming you're properly set up against that), file uploads, and server intrusion? If you're on a shared hosting machine then other users already have (limited) access to the server; they could quite possibly have read access to all your files by default. The database server is another vector. Of course there's also bugs in PHP, like the recent ?-s and that one floating-point number, but you can't really do anything about those.

[PFMaBiSmAd]

$_COOKIES and some of the $_SERVER variables are also external inputs that would need to be protected against nefarious input in and mysql_real_escape_string doesn't do anything for numerical fields (sql can be injected that doesn't involve any quotes, so there's nothing for escape functions to prevent escaping from.) Numerical data must be validated/cast to prevent sql injection in it.

 

External values that are being used in things like paths/filenames put into include or other file operation statements or for those people that use external values for parts of a database query that are not just the data values in the query (table/column names and logic/condition operators), must specifically be validated to insure they only hold expected values.

[Eritrea]

@PFMaBiSmAd

 

Thanks, Since it is very hard for me to learn PDO now, can you give me an example how to verify a value?

Which means, if I need to get only string or only integer in $_GET[] function, how do I achieve that? I tried is_string, but it only checks the first letter so basically

"abc12 " is also the same as "abcde" so is there any way to check for complete string or integer?

[jcanker]

Because mysql_real_escape_string is a good step toward sanitizing input, but it doesn't go far enough. You really want to use prepared statements to protect against these:

 

http://www.dreamincode.net/forums/blog/1735/entry-3958-why-mysql-real-escape-string-isnt-enough/

 

Additionally, it's not always about hacking per se as much as it is about getting information and causing chaos from there. If, for instance, variables are passed through the URL using GET, then I can see what variables are being named and see the logic behind your variable/value structure. Consider, for instance, a page that lets me view my account settings. I'm already authenticated by the login procedure. I go to my view account settings page and see the url: www.generalsite.com/view_account_settings.php?user=59293222

 

What happens if I start experimenting with random user numbers? Is the code set up to check that the user ID passed is actually the same as the one logged in, or was the programmer lazy and just assumed that a user wouldn't ever try to pass their own values through the URL? What if your change password page uses the same URL structure and doesn't ask for the old password? It would be real easy for a user to change account passwords. Sanitizing input won't stop any of those attempts. Only good planning and responsible coding/design will.

[Psycho]

I tried is_string, but it only checks the first letter so basically

"abc12 " is also the same as "abcde" so is there any way to check for complete string or integer?

 

Um, "abc12" IS a string! From a programmatical sense anything within quotes is a string. Even "123" is a string. In fact, every piece of data passed via POST/GET is a string. If PHP if the language you've had the most experience with then variable types is probably something you're not very familiar with. PHP is a loosely types language. This means that when using values in various means, the PHP parser can interpret if the value should be treated as test an integer a float a Boolean, etc. For example:

$foo = 2 + '3'; //5

is perfectly fine in PHP (although I would never do that). But many other languages would not allow that since the '3' is defined as a string. PHP sees that the 2 is a number and sees the '3' as a string, but because you are trying to add the two values it converts the string of '3' to the number 3 on-the-fly and performs the addition. By the same token, PHP can convert a number into a string if the process requires it

$foo = 2 . '3'; //23

 

So, the is_string() function is specifically used to check if the value is of the string TYPE

is_string('abc'); //true
is_string('123'); //true
is_string(123); //false

 

If you want to ensure that a variable only contains alphabetical characters then use ctype_alpha(). But, if you want to allow puntuation as well, you'll probably need to revert to regex.

[KevinM1]

Also, no one should be using the mysql_* functions any more. They're essentially soft deprecated. Instead, use either MySQLi or PDO. Both have parameterized statements, which is the way to go when attempting to stop SQL injection.

[jcanker]

PDO can be a bit overwhelming when you first run into it, but it's actually not bad once you get a few attempts in under your belt. The included fetch I think actually streamlines things a bit (one gotcha on that: it by default returns both numerical-based index array and an associative array where key=column name. If you just try stepping through the returned results, you'll get double what you expect--the numerical based key=>value and the associative key=>value. If you specific which array type you want, it will parse it appropriately.

 

I recommend strongly that you take a few hours and practice/learn the basics of PDO. Your website security will benefit greatly from it. It's a little time spent up-front to fortify everything in the long haul. I'm going through many of my old projects and replacing the old mysql(i)_connect with PDO, because I've found it to be worth it.