[OWASP_PHPSEC] Interview Question
sven at rtbg.de
Sun Jul 28 09:55:02 UTC 2013
You created the perfect code to demonstrate why prepared statements are
not inherently more secure than the usual SQL query.
Here you have plenty of sources that could possibly be abused for SQL
injection, or at least kill the statement with an unnecessary error.
First: All table and column names should be surrounded by backticks
(valid for MySQL). The backtick will mark the name clearly as name, it
won't get confused with any reserved keywords then. It would then be
possible to name a column "alter", "select", "from" or "into".
Second: All these dynamic names really must undergo some escaping as
well. There is no escape character defined for names, but the valid
characters are defined, so any other character should be removed.
Unfortunately there is no function available for this, no
So the current code is as unsafe as any other unprotected SQL code.
Am 28.07.2013 07:51, schrieb rahul chaudhary:
> After reading this, the code that I have posted here:
> obviously has flaws in it. Becuse then one can write a config file and
> present different DBTable to insert garbage value in that DBTable.
> *However, I am not sure what to make out of this. Since, the libraries will
> be used by developers, should we protect this particular code ???*
> *Note:* Please first see and understand the code posted here before
> On Fri, Jul 26, 2013 at 1:42 PM, Abbas Naderi <abiusx at owasp.org> wrote:
>> Its probably because they read my explanations the wrong way :D
>> There are two scenarios where prepared statements (aka parameterized
>> queries) are unsafe, not considering human errors (i.e we are only talking
>> about proper usages of them, not when you don't use them properly):
>> 1. Dynamic Queries:
>> you have to use table and field names here, by concatenation. Best bet is
>> to have them start as TaintedString, then WHITELIST using a callback or an
>> array to the tainted class.
>> 2. Non-supported clauses:
>> for example, LIMIT BY in MySQL 5-, can not accept parameters and requires
>> numbers. In these scenarios, type-casting will do the trick.
>> *Notice:** *This message is *digitally signed*, its *source* and *
>> integrity* are verifiable.
>> If you mail client does not support S/MIME verification, it will display a
>> file (smime.p7s), which includes the X.509 certificate and the signature
>> body. Read more at Certified E-Mail with Comodo and Thunderbird<http://abiusx.com/certified-e-mail-with-comodo-and-thunderbird/> in
>> On Mordad 4, 1392, at 12:44 PM, rahul chaudhary <
>> rahul300chaudhary400 at gmail.com> wrote:
>> In my interview process I was asked one question, how can you improperly
>> use parameterized queries. I was not able to answer this. Later they told
>> me that by concatenation, there is problem. But I didn't understood this
>> fully. Can someone explain this ?
>> Rahul Chaudhary
>> Ph - 412-519-9634
>> OWASP_PHP_Security_Project mailing list
>> OWASP_PHP_Security_Project at lists.owasp.org
> OWASP_PHP_Security_Project mailing list
> OWASP_PHP_Security_Project at lists.owasp.org
More information about the OWASP_PHP_Security_Project