note 105940 added to security.magicquotes

*sigh* People. magic quotes are bad, mmmkay? Not just the implementation -- the whole concept. Emulating them with one of the replacements shown in the comments doesn't make your code any better or less exploitable. In fact, all it does is make handling your data more annoying. Watch this. <form> <input type="text" name="q" value="<?= htmlentities(@$_GET['q']) ?>"> <input type="submit"> </form> Put that in a page on your magic-quotes-enabled server and go to it in a browser. Enter "He'll be here at 12 o'clock". Hit the button a couple of times and watch what happens. See those backslashes? That's what magic quotes are designed to do. In order to fix it, you have to stripslashes() it (and then escape it with htmlentities() or htmlspecialchars(), because you care about preventing XSS injection as well, *right?*). If it's part of a URL, then you need to stripslashes() and then urlencode(). If you write the data to a file, or a socket, or to a console if that's your thing...stripslashes() and then...well...nothing really. Unless your file needs stuff escaped a certain way. But if you just write it, those backslashes will start multiplying. Short version: you have to strip the slashes every. Time. You. Touch. The. Data. unless you're doing nothing but stuffing it into MySQL. Forget once, and the data's either displaying wrong, or hosed internally. Even with the database, though, you have problems. See, addslashes() was designed for 8-bit chars. It doesn't know much about multi-byte chars. And it doesn't really care about locales, or the character set your database is using. The result being, a sequence of bytes like \xbf\x27 can turn into \xbf\x5c\x27 (a multi-byte char followed by a single quote). Hello, SQL injection vulnerability! Short version: addslashes() (and, by extension, magic quotes) is breakable. See http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string for details. If your code relies on a mechanism like magic quotes to protect it, it is broken. It always has been; you just didn't know it. Now that you know, *fix the real problem* instead of duct-taping over the hole. mysql_real_escape_string has been around for...what...10-15 years? And mysqli and PDO come with built-in support for prepared statements. They've been around for close to that. Either one is far more secure and far less error-prone than either magic quotes or your roll-your-own reinvention of them. ---- Server IP: 192.41.42.26 Probable Submitter: 96.228.3.109 ---- Manual Page -- http://www.php.net/manual/en/security.magicquotes.php Edit -- https://master.php.net/note/edit/105940 Del: integrated -- https://master.php.net/note/delete/105940/integrated Del: useless -- https://master.php.net/note/delete/105940/useless Del: bad code -- https://master.php.net/note/delete/105940/bad+code Del: spam -- https://master.php.net/note/delete/105940/spam Del: non-english -- https://master.php.net/note/delete/105940/non-english Del: in docs -- https://master.php.net/note/delete/105940/in+docs Del: other reasons-- https://master.php.net/note/delete/105940 Reject -- https://master.php.net/note/reject/105940 Search -- https://master.php.net/manage/user-notes.php