Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50326 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11197 invoked from network); 18 Nov 2010 09:51:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Nov 2010 09:51:45 -0000 Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 unknown Solaris 10 (beta) Received: from [217.114.211.66] ([217.114.211.66:60980] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 83/A1-32235-527F4EC4 for ; Thu, 18 Nov 2010 04:51:34 -0500 Received: from [192.168.1.31] (ppp-93-104-35-134.dynamic.mnet-online.de [93.104.35.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id BFB4F44C5D; Thu, 18 Nov 2010 10:51:30 +0100 (CET) To: Adam Harvey Cc: Zeev Suraski , Larry Garfield , internals@lists.php.net In-Reply-To: References: <6628E909-5B8E-4FB4-A28F-ECAF7FCA27AB@roshambo.org> <201011172340.37217.larry@garfieldtech.com> <887FE7CFF6F8DE4BB3A9535F53AFD06A2C5A4581@il-ex2.zend.net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 18 Nov 2010 10:51:29 +0100 Message-ID: <1290073889.16819.81.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Magic quotes in trunk From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Thu, 2010-11-18 at 15:40 +0800, Adam Harvey wrote: > Yes, killing magic quotes will likely increase the support workload > for a time, I don't think it would increase support workload. Most people won't notice. What happens is that applications which are _a bit_ secure now will continue to run as before but become _completely_ insecure as there, unfortunately, are many users who don't know about the different issues. Code like mysql_query("SELECT id FROM table WHERE name = '".$_GET['name']."'"); is not too easy to exploit right now. As soon as m_q is gone it's trivial to exploit. And people won't notice. And lots of such code exists. Maybe not with internals subscribers, but there are enough people who learned programming just last week using PHP and have the $1 hosting package ... and many of these things live "forever". I think the default can only be changed in a change which breaks "a lot". To be clear: I am NOT saying that m_q is secure or safe. But dropping it lowers he bar quite a lot. johannes, who said this in multiple threads before ;-)