[OWASP_PHPSEC] Interview Question
rahul300chaudhary400 at gmail.com
Sun Jul 28 10:00:39 UTC 2013
I will create a separate issue for this and will get to it...thanks..
On Sun, Jul 28, 2013 at 5:55 AM, Sven Rautenberg <sven at rtbg.de> wrote:
> 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:
> > http://codepad.org/StiiHUUe
> > 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
> > be used by developers, should we protect this particular code ???*
> > *Note:* Please first see and understand the code posted here before
> > answering.
> > 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
> >> 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
> >> to have them start as TaintedString, then WHITELIST using a callback or
> >> array to the tainted class.
> >> 2. Non-supported clauses:
> >> for example, LIMIT BY in MySQL 5-, can not accept parameters and
> >> numbers. In these scenarios, type-casting will do the trick.
> >> -Abbas
> >> ______________________________________________________________
> >> *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
> >> AbiusX.com
> >> 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
> >> me that by concatenation, there is problem. But I didn't understood this
> >> fully. Can someone explain this ?
> >> --
> >> Regards,
> >> Rahul Chaudhary
> >> Ph - 412-519-9634
> >> _______________________________________________
> >> OWASP_PHP_Security_Project mailing list
> >> OWASP_PHP_Security_Project at lists.owasp.org
> >> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
> > _______________________________________________
> > OWASP_PHP_Security_Project mailing list
> > OWASP_PHP_Security_Project at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
> OWASP_PHP_Security_Project mailing list
> OWASP_PHP_Security_Project at lists.owasp.org
Ph - 412-519-9634
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP_PHP_Security_Project