Timeline for Security of code snippets
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:40 | history | edited | Community Bot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Apr 13, 2017 at 12:40 | history | edited | Community Bot |
replaced http://codereview.stackexchange.com/ with https://codereview.stackexchange.com/
|
|
| Jun 24, 2014 at 15:23 | history | edited | Elias Van Ootegem | CC BY-SA 3.0 |
added 398 characters in body
|
| Jun 24, 2014 at 14:51 | comment | added | DaveRandom | Security edge-case ref: stackoverflow.com/questions/5741187/… - if you want to continue this, please come and see me in room 11 so we can avoid junking up the comment thread :-) | |
| Jun 24, 2014 at 14:49 | comment | added | DaveRandom |
Emulated prepares do not have identical security levels, there are edge-case attacks (I'll dig out a ref in a minute). But there is no getting away from the fact that there are a couple of behavioural differences, and that is not acceptable for me in dev vs. live. (If you don't know what diff I'm talking about, see what happens when you prepare and execute SELECT * FROM foo WHERE a=:a OR b=:a with and without emulation)
|
|
| Jun 24, 2014 at 14:45 | comment | added | Elias Van Ootegem |
PDO does address the query result cache issue somewhat. I'm looking through the source to see how the emulated prepares are allocated, but I suspect they are allocated using pemalloc (PHP's internal persistent allocator), effectively caching the prepares, too
|
|
| Jun 24, 2014 at 14:43 | comment | added | Elias Van Ootegem | @DaveRandom: I agree on the last bit (supporting older PHP versions is, sadly, a necessary evil for some). Security-wise: differences between native prepares and emulated ones should be the same (last I checked). Yes, native prepares are more sensitive to malformed queries, I'll grant you that. But it's down to us to write good queries. If you do that, it shouldn't really matter. The main issue I have with MySQL prepared statements is: No Cache! No Query Cache, and on some versions no prepared statements cache! | |
| Jun 24, 2014 at 14:33 | comment | added | DaveRandom |
Disabling emulated prepares is not primarily a performance issue, it is a security issue. Moreover, disabling emulated prepares fundamentally alters the behaviour of PDO, to the point where the exact same code may work in dev but not in production... SET NAMES is less of an issue, I admit, it just looks dirty to me (actually, expecting to run code on <5.3.7 is just generally dirty).
|
|
| Jun 24, 2014 at 14:28 | comment | added | Elias Van Ootegem |
@DaveRandom: not emulating prepares doesn't always mean better performance. In some cases, quite the opposite. I only disable emulation on environments where I know that it'll boost performance. the DSN + SET NAMES is simply because I don't know what the target environment will be: is charset=UTF8 going to be ignored, then if so: SET NAMES will fix that. If not, ah well: that's hardly going to be a noticeable bottleneck, is it?
|
|
| Jun 24, 2014 at 14:18 | comment | added | DaveRandom |
Why would you only disable emulated prepares in production? This should be done always. And personally I'd disagree with always calling set names, I would say you should inspect the current PHP version and use that to either specify the charset in the DSN or issue a SET NAMES.
|
|
| Jun 24, 2014 at 14:15 | history | edited | Elias Van Ootegem | CC BY-SA 3.0 |
added 282 characters in body
|
| Jun 24, 2014 at 14:08 | vote | accept | Rahul Khosla | ||
| Jun 24, 2014 at 14:08 | vote | accept | Rahul Khosla | ||
| Jun 24, 2014 at 14:08 | |||||
| Jun 24, 2014 at 13:07 | history | edited | Elias Van Ootegem | CC BY-SA 3.0 |
added 9 characters in body
|
| Jun 24, 2014 at 10:24 | history | answered | Elias Van Ootegem | CC BY-SA 3.0 |