0

Possible Duplicate:
how safe are PDO prepared statements

What does PHP PDO's prepared statement's does not protect against? I have been reading that PDO's prepared statements with bind is completely safe from injection type attacks.

Is this true or does a programmer (me) have to take care of some more things (any type of attacks, html tags inclusion etc..)?

Community
  • 1
  • 1
ThinkingMonkey
  • 12,539
  • 13
  • 57
  • 81
  • @xdazz any type of attacks, html tags inclusion etc.. – ThinkingMonkey Jul 02 '12 at 05:48
  • It doesn't protect against stupid; *that* defeats all. – Jared Farrish Jul 02 '12 at 05:48
  • 2
    @ThinkingMonkey: how html is related to sql? – zerkms Jul 02 '12 at 05:48
  • "any type of attacks" - there is no and will never be a protection from anything. Each particular case requires each particular protection – zerkms Jul 02 '12 at 05:50
  • @zerkms Its not.. I am talking about when the content is used again for display. A html tag inclusion would ruin the readability. – ThinkingMonkey Jul 02 '12 at 05:50
  • @zerkms I agree! I am looking for the cases that are not handled by the PDO's prepared statements. – ThinkingMonkey Jul 02 '12 at 05:51
  • @ThinkingMonkey: "I am talking about when the content is used again for display" -- then how sql is related to the html? It doesn't matter where you get the data to display it – zerkms Jul 02 '12 at 06:00
  • You don't want your SQL connector randomly munging your database-stored content; see *[PHP magic quotes, deprecation thereof*](http://php.net/manual/en/security.magicquotes.php), which amounts to the same idea with the same problem only with GET/POST content. – Jared Farrish Jul 02 '12 at 06:04

1 Answers1

1

It is safe to use to substitute query parameters, thus values for SQL operators

But you should remember that it's not suitable to substitute table, column, or alias names with it. And in this case you have to use whitelists instead

zerkms
  • 249,484
  • 69
  • 436
  • 539
  • You mean those approaches which let you feed in table and col names and it builds the query for you? – Jared Farrish Jul 02 '12 at 05:50
  • @zerkms I agree, that is common sense(I am not being sarcastic). :) – ThinkingMonkey Jul 02 '12 at 05:57
  • @Jared Farrish: I'm not sure I understand you – zerkms Jul 02 '12 at 05:59
  • I guess we're at an impasse. Your last paragraph I was thinking the same thing you just said. – Jared Farrish Jul 02 '12 at 06:00
  • @JaredFarrish You are right about your interpretation of Zerkms's answer. He is talking about the instances where programmers use user data to substitute for table/column names. – ThinkingMonkey Jul 02 '12 at 06:10
  • @ThinkingMonkey - Yeah, well, there's *nothing* inherently insecure about doing ***that***. LOL – Jared Farrish Jul 02 '12 at 06:19
  • @Jared Farrish: that depends on what we mean when we say "security". If the column/table names aren't whitelisted - then blind usage of placeholders (thinking they will protect from anything) is a serious security breach. So you either bind values, or whitelist names. That simple – zerkms Jul 02 '12 at 06:28
  • I wouldn't parse that too literally. I included ["inherently"](http://www.savidtech.com/blog/it-security/risk-management-defining-inherent-risk-vs-residual-risk/) specifically due to immateriality of variance of controls that mitigate or reduce the likelihood a risk; the approach itself is problematic due to it's possible severity. It's my opinion that in most cases avoidance is a better risk strategy for this than trying to mitigate it, but I am perhaps more risk-averse in this aspect than others may be. – Jared Farrish Jul 02 '12 at 06:34