Timeline for How to bypass mysql_real_escape_string to exploit a SQLi vulnerability?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 26, 2016 at 12:13 | history | edited | 700 Software | CC BY-SA 3.0 |
deleted 113 characters in body
|
| Aug 25, 2016 at 22:04 | comment | added | Bacon Brad |
Keep in mind mysql_real_escape_string was deprecated and removed only for the old mysql extension. This is because mysql was phased out in favor of mysqli and pdo. So real_escape_string is still in PHP even as of PHP 7. However, it can be exploited if mysqli_set_charset is not set or unicode character enforcement is not properly set up. Ideally, the best practice is to switch to prepared statements.
|
|
| Aug 24, 2016 at 18:10 | history | edited | 700 Software | CC BY-SA 3.0 |
added 162 characters in body; added 156 characters in body; deleted 22 characters in body
|
| Aug 24, 2016 at 18:06 | comment | added | 700 Software |
Thanks @tim, Note that mysql_real_escape_string was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. That's not to say it is vulnerable (when properly used), but it's a good reason to migrate to a more modern solution.
|
|
| Aug 24, 2016 at 17:19 | comment | added | tim | The combination of real_escape_string and sprintf is also used in the PHP documentation. I'm not saying that it is a good idea - escaping isn't a good idea in itself - or that the PHP documentation never contains vulnerable code, but I would assume that such an issue would have been more widely publicized over the years. | |
| Aug 24, 2016 at 16:54 | history | answered | 700 Software | CC BY-SA 3.0 |