-3

I read so much about types to prevent sql injections. I probably don't want to use prepared statements if there is another way to prevent them by 100% of the cases.

Currently I'm sticking to this:

$safe_var = mysql_real_escape_string ( $unsafe_var);
mysql_set_charset("utf8");
$sql = "REPLACE `news` (`id`, `author`, `title`, `text`, `time`)" . "VALUES ('".$id."', '$author', '$title', '$text', UNIX_TIMESTAMP());";
mysql_query ( $sql );

For this example all the variables in the sql statement are constructed as the safe_var at the start. I see many opinions on what is save in sql and what not so I don't know what is right. My question is, is this 100% save and is it save to use this way in every possible sql statement, by using mysql_real_escape_string and putting the variables in single quotes as I did in the statement?

Thanks in advance for help!

PS: I know there are many question likes this but everyone keeps saying diffrent stuff and I still not found anyone that says that my way is safe from sql injections in every possible statement.

Jalau
  • 303
  • 1
  • 2
  • 11
  • 9
    "I probably don't want to use prepared statements" You probably do. – ceejayoz Mar 25 '15 at 21:17
  • 1
    X 1000 what @ceejayoz said. – Jay Blanchard Mar 25 '15 at 21:18
  • 2
    obligatory, stop using mysql_* –  Mar 25 '15 at 21:19
  • mysql and `mysql_real_escape_string` are not *unsafe per se*. However, the API is brittle enough to make it **very hard to apply correctly in practice**. We cannot tell you whether your code is safe without auditing *all* of it at once. That's why prepared statements are so much better, because it's really hard to screw them up. – deceze Mar 25 '15 at 21:19
  • @ceejayoz Okay if that is the only way making it save, do you know any flexible tutorial because if it's possible I don't want to have 20 lines of code each time I'm using mysql. Like a function that is not hardcoded but softcoded? – Jalau Mar 25 '15 at 21:22
  • @Jalau Use an ORM. Laravel's Eloquent ORM is my favorite. – ceejayoz Mar 25 '15 at 21:23
  • 2
    A database call is actually quite a complex action to take. IMO you should stop treating it as an inline action. If it takes 20 lines to do properly, then that's what it takes. Wrap it in a function if you don't want to have it inline. – deceze Mar 25 '15 at 21:23
  • @deceze I read that one already, but there is a part for prepared statements and one for other possibilitys but there are so many that I don't know which of them works the best and if one of them is usable in all sql statements and not just one case of sql statement. – Jalau Mar 25 '15 at 21:24
  • 2
    My advice: learn the PDO prepared statements API. Start with the PHP manual. It's really not hard. And it doesn't typically take 20 lines either. – deceze Mar 25 '15 at 21:25
  • @deceze So prepared statements are 100% save as I read in many answers in other questions already? Thanks for your help and sorry for me asking this. But if 20 answers all say diffrent stuff you can never be sure if one of them is right or if one of them is usable in other cases then the case the answer was made for. – Jalau Mar 25 '15 at 21:32
  • 1
    nothing is 100% safe, and how do you know deceze is right? He's just another human on the internet. So start understanding the issues yourself so you can make your own decisions. (no disrespect @deceze :)) –  Mar 25 '15 at 21:39
  • @deceze So this code now would be fine and save from sql injections?function createNews($author, $title, $text) { global $mysqli; $stmt = $mysqli->prepare("INSERT INTO `news` (`author`, `title`, `text`, `time`)"."VALUES (?, ?, ?, ".UNIX_TIMESTAMP().");"); $stmt->bind_param("sss", $author, $title, $text); $stmt->execute(); $stmt->close(); } – Jalau Mar 26 '15 at 12:24
  • 1
    Apart from your very weird string concatenation it should not be vulnerable to SQL injection, yes. – deceze Mar 26 '15 at 13:03
  • @deceze You mean that I have not formatted the code in the comment to multiple lines? I have no idea how I can do this :/ Or do you mean something else? Thanks – Jalau Mar 26 '15 at 13:15
  • OK, if that's supposed to be multiple lines, it's not *that* weird, although you don't have to break up the string for that. Most notably though: `UNIX_TIMESTAMP()` is not a PHP function, why isn't it part of your string? – deceze Mar 26 '15 at 13:45
  • @deceze I fixed that already because I noticed it right after I posted this ;) Thanks though. Break up what string? – Jalau Mar 26 '15 at 13:55

1 Answers1

-3

At the least you would want to convert to mysqli rather than mysql. You would want to also further test the user input as much as possible to ensure it is legitimate.

Highly recommend pdo and prepared statements

J Hock
  • 129
  • 3