MYSQL / PDO Problem

After executing my php code. i have got a blank page in result !!!

After changing this line:

$q->execute(array("\xbf\x27 OR 1=1 /*"));

To this line:

$q->execute();

The problem resolved!

But to stop sql injections i need the filter

Where should i apply query filter of "\xbf\x27 OR 1=1 /*" in the following example?

I have attached screen shot of my code

tnx

 

Eh... No, you don't need that code to prevent anything. You're using a prepared statement in PDO. No need for anything in the execute function. If you think that, I suggest reading up a bit on what PDO is, and does.

 

You don't need a query filter. The way it is working is sufficient. The query you are using isn't using external/global variables, so you won't have to worry about injection for that query.

 

Thank you but please read the 2nd answer in this link: http://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection

 

And you obviously didn't understand what you were reading.
Do it _right_, and prepared statements are more than enough to prevent any attacks that have even a remote chance to ever being run.

 

That attack in the 2nd answer is BS if you turn off emulated prepares since automatically query fields are values NOT instructions, applied as literals. It's only the dumbass idiotic halfwit default "emulation" crap (which also breaks passing more than one value to limit) that's a problem there.

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

... and boom, your PDO object will be completely immune to injection as the query is sent separate from the data.

It means no matter WHAT is in the data array or bound parameter, it will be properly escaped, so if you send:

\xbf\x27 OR 1=1 /*

That is EXACTLY what will be stored. It's why it exists, and why you can't pass instructions like "SELECT" or "OR" or "WHERE" in parameters.

I think it's monumentally stupid that prepare emulation is the default for all engines just because a couple crappy ones nobody uses doesn't support them. Emulation on, it just does what the old mysql_ functions were crapping together when people were running _escape and blindly pasting values into the query string -- COMPLETELY MISSES THE POINT of the prepare/execute model!

Oh wait, in your picture (that refused to load at first here) you're doing that... so... yeah, you'd be immune; though one bit of advice, lose the "variables for nothing". You also shouldn't need to set the charset on the connect, that should have been done when the table was created... though... oh, duh.

You're doing the dumbest thing possible; using a variable for a table name -- something you should NEVER do and why you are probably so concerned about injection as that DOES make you vulnerable. Solution? Don't use non-static query strings. If you are using variables for field or table names, you're doing something WRONG...

... in a "Doctor, doctor, it hurts when I do this!" kind of way.

 

Thank you all

Also you can check David's answer on the yahoo answer:

What on earth...
OK, after a quick search that led me to StackOverflow, I think you're confusing something. That statement is one which will *cause* a SQL injection vulnerability under certain specific circumstances. But it's also not the only statement that will do so; for example, if you replace the 1=1 with 2=2 it will do the same thing. So you can't just check for that exact string and think that will fix anything.

But since you turned off emulated prepares, that will go a long way towards preventing this sort of vulnerability. And if both sides of the connection are using utf8, then this attack doesn't work, because it depends on half of the connection thinking you're using a vulnerable encoding like gbk and the other half thinking you're using something else.

Source: https://answers.yahoo.com/question/index?qid=20151015191631AA7dMkb​

 

Just beware, that even with emulation switched off, putting that variable into the query string DOES still open up the possibility of being vulnerable. It would hinge on the source of that variable's value and possibly also it's scope.

Prepare/execute does NOTHING to protect you if you are still pasting variables into the query itself... which is why as I said, you don't do that.