Timeline for How to bypass mysql_real_escape_string to exploit a SQLi vulnerability?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 4, 2017 at 11:41 | history | edited | Anders | CC BY-SA 3.0 |
deleted 74 characters in body; edited title
|
| Aug 26, 2016 at 20:24 | history | tweeted | twitter.com/StackSecurity/status/769269203476021248 | ||
| Aug 24, 2016 at 19:34 | comment | added | tim | @MarkBuffalo every time, not just in some very specific corner cases (which would eg also affect PDO prepared statements)? If that's the case that would probably be a great answer (if you have the time to write it up); I'd definitely be interested in that. | |
| Aug 24, 2016 at 18:32 | comment | added | Mark Buffalo | Please use prepared statements. Also, Unicode/different character set tricks will bypass this every time. | |
| Aug 24, 2016 at 17:07 | comment | added | tim | Of course, there could always be issues in the combination of sprintf and real_escape_string, possibly with some specific character set, but if that were the case, it would be mentioned in any decent advisory. Without any further evidence, there is no reason to assume that this is the case here. | |
| Aug 24, 2016 at 17:06 | comment | added | tim | Except for a few multi-byte issues, escape string is secure if used correctly (it's not recommended though), which it is here, so there is no injection. My guess is that it's a fake advisory, maybe to get people to visit their blog, or to see which mailing lists accept advisories without actually checking them; or maybe the author was just mistaken (their other current LFI/RFI advisories for example seem to assume that register globals - a setting that was removed from PHP 4 years ago - is on, but do not see a need to even mention that fact). | |
| Aug 24, 2016 at 16:54 | answer | added | 700 Software | timeline score: 2 | |
| Aug 24, 2016 at 16:37 | history | asked | user126623 | CC BY-SA 3.0 |