1) is mysql_real_escape_string() sufficient to protect against an sql injection? 2) is it safe to use include() ? 3) how do i stop remote inclusion of my files? thanks!!!
1) I would use addslashes(mysql_real_escape_string()) 2) no - it is totally unsafe to use include() - avoid it 3) put register globals on off and avoid using $_GET parameters as well as include() function cheers
look two nice articles about security http://www.devshed.com/c/a/PHP/PHP-Security-Mistakes/ http://www.onlamp.com/pub/a/php/2003/03/20/php_security.html
1) Yeah, its pretty good, sometimes people will use htmlspecialchars() or something too... Not sure if that makes it so no SQL Injections can be done, but it does replace " and ' with entities 2) Why would it be unsafe..? Your including/requiring a file, lots and if not every script you can get (like forum scripts, CMS's, etc) all use require/include so everything is not in one file 3) People can't do require('http://www.yoursite.com/file.php'), well they can, however it will be a already PHP parsed page, so they can't get any variables from it like MySQL password, etc. And variables like $_POST, $_GET, $_REQUEST, etc. are not exactly safe, however, in most scripts today you do, you can't not use them and they are safe if you sanitize them correctly.
Yes, its sufficient and infact, that is its sole task. It is far superior to adding slashes! You can lookup the PHP manual to find how it is superior. Yes, its is safe, if used precautiously. Other sites cannot include your files remotely. If they try to do so, they will see the output(Eg: HTML) of the script, but not the source code of the PHP script.
ok.... I got a few people that said include() is safe and I got people that said include() was absolutely not safe.... thoughts??
I use include regularly, but think how you plan to use it determines how safe/dangerous it is. I would avoid using variables as parameters for include statements if possible. In other words, avoid using something like: $includefilename = "test.php"; include($includefilename); PHP: .. and instead, use .. include("test.php"); PHP: Whenever possible. -Zeras
Whoever said include() isn't safe is an idiot. So long as you aren't using include($_GET['superbadfile']); then you're fine.
It is safe to use include as long as you don't do it using get method. Google "Remote file include vulnerability" for more information.
Yes and no. If used at the right time it does really well against attacks that depend on the attacker being able to alter the logic of a query by adding a closing quote and appending their own logic to the query. An example of using it at the wrong time would be using it on input as soon as you get the input, then performing substitutions or other alterations to the string inbetween then and when it goes to the database. Mysql_real_escape_string should always be the last thing that happens to input before it goes to the database. The difference between mysql_real_escape_string and something like add_slashes, is that mysql_real_escape_string handles escaping any control characters and reacts to changes in MySQL configuration, whereas add_slashes just works with a single character and doesn't respond to changes in MySQL configuration. Again, yes and no. By default there is no risk to using include() or require(). The only difference between the two is that require will stop execution of the script if it can't find the filename listed, whereas include will simply emit a warning and carry on. The risk with using include/require isn't directly related to the functions at all, the risk is one inherant with all functions that can be made to work with input given by an anonymous person on the Internet. That risk is assuming that everyone is honest when they're not. As long as you always check to make sure the path being passed to include/require is a valid path that you would actually want the script to work with, there is no security risk involved with using them. In most situations remote inclusing of files is done via HTTP, meaning the PHP engine is going to interpret the includes and return the result instead of allowing the remote site to include and execute the raw code itself. If you have includes that contian HTML or other content that you just want to prevent others from using, you can use htaccess or similar within your includes directory to prevent access via HTTP with the "Deny" directive.
So how does that add to a flaw in the function mysql_real_escape_string(). Its a bad practice by the coder, so why blame the language? Just because some noob coder makes mistake, how can you say 'PHP sites are insecure?'
rohan_shenoy I think your translator is broken or something bud. I pretty much spelled out a situation that shows how a noob could screw up an otherwise safe function. I have no idea where you got your idea about what I said there.
I was just saying that how can you blame a coder bad practice onto the language or the function. Ofcourse, if you use the function incorrectly, even a great function will not return correct values. Like you said that noobs screw up safe functions, its a case of incompetent coding. No program on this earth is safe from incompetent coding.
I don't get what your point is here. It seems like we're saying the same thing different ways in agreement to me.
alternative to save the include : On master file , put a variable like $var1 = 100; on include file put script to read the $var1. if not 100, die. like : if($var1 != 100) {die;} and make your include file extension .php to avoid read.
About MySQL security in PHP... Always use PDO to handle MySQL. This will take care of almost everything for you. Look for PDO:repare method and learn how to use it efficiently.
Prepare method will be better than mysql_real_escape_string as mysql_real_escape_string can be break by using special characters. ( read at wiki )
PDO is designed to give programmers flexability over which database engine is used by allowing us to use the same program code to handle multiple database engines. Be carefull with treating PDO like a security wrapper for MySQL, if you use any MySQL-specific SQL queries you will end up beating your head against the wall if you ever want to swap the engine PDO is using later on.