Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87671 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3768 invoked from network); 6 Aug 2015 21:34:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Aug 2015 21:34:30 -0000 Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-la0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:35735] helo=mail-la0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/94-00122-5E2D3C55 for ; Thu, 06 Aug 2015 17:34:30 -0400 Received: by labkb6 with SMTP id kb6so35234380lab.2 for ; Thu, 06 Aug 2015 14:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FNrmGqCrdROnDubLu4M8mIfiiFiUzZUYztkjK9s3OhA=; b=dAJ62DEPvvn6VXMgoNCgCHpWf4hQ75BgO3c1jLf6iRIhcePodTgDwavWeUgQmHjVlu sBBTaDx9wcR95kWWY24PigyiYe/ucqsHoLFlpUo0UI/sIXVBN71o+ajkMinwk7mL6YQi SH9IdPg3bfR/wzGypQz+Z+y1zSO27CfR0g8YxbiJTC+nidW9Ee042Y5A7LzTCW57Eycj V3BxqzDIIcA7+2uWan2dEw811vD0hWlGl+srpVf1xmNmA9CzEnZpCP8AZRhO/LeW4wcc F4LEJbfd3kkwNHLO0X+rbgswJImJGUdrjF0wQFEk/HiPLBCY1Pe8sojpq2KQGjkSCYzD R8AQ== MIME-Version: 1.0 X-Received: by 10.152.170.234 with SMTP id ap10mr4436206lac.28.1438896866726; Thu, 06 Aug 2015 14:34:26 -0700 (PDT) Received: by 10.25.5.215 with HTTP; Thu, 6 Aug 2015 14:34:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Aug 2015 17:34:26 -0400 Message-ID: To: Matt Tait Cc: Julien Pauli , PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack From: ircmaxell@gmail.com (Anthony Ferrara) Matt, > You are of course welcome to disagree with the overwhelming body of security > advice that parameterized queries are the correct, secure way to prevent SQL > injection. In that case, you only need to not enable this feature. This > feature is off-by-default, and only attempts to help secure webapplications > and webdevelopers who do (or are required, for example by PCI compliance > standards) to adopt this security-best-practice to ensure that they do so > systematically across their entire website. You seem to misunderstand me. I'm *not* saying that you shouldn't use parameterized queries. Nor that they are not one of the best tools available. I am simply pointing out that they are not a sure-fire one-stop solution. There is a lot more that goes into it than simply using prepare/bind. As indicated by the two cases I talked about (structural elements not being supported and implementation quirks) as well as others (DOS attacks from wildcards in malformed query parameters, type validation, etc). This is not to say that we should avoid PQ, but that we should recognize that it's not enough to just use one thing and forget about everything else. Anthony PS: w3schools is NOT w3c. And their content is probably the single largest source of security vulnerabilities for PHP, so citing them in a security discussion is more than a little ironic.