php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #68254 PDO lacks design implication discussion
Submitted: 2014-10-17 15:01 UTC Modified: 2023-06-20 16:01 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: uw@php.net Assigned:
Status: Open Package: PDO related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: uw@php.net
New email:
PHP Version: OS:

 

 [2014-10-17 15:01 UTC] uw@php.net
Description:
------------
It seems there is confusion around the PDO documentation with regards to "security" (see below internals ML posting). The PDO general documentation about prepared statements at http://php.net/manual/en/pdo.prepared-statements.php likes to highlight advantages of prepared statements and the bind API offered by PDO. Neither are PS disadvantages discussed nor is there any hint about implications of the PDO design (when PS emulation happens). This bares the risk of giving a false feeling of security.


From - Fri Oct 17 15:12:46 2014
X-Account-Key: account6
X-UIDL: 0001de075098db15
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
Return-Path: <internals-return-78136-ulf.wendel=phpdoc.de@lists.php.net>
X-Original-To: ulf.wendel@phpdoc.de
Delivered-To: m026cece@dd5506.kasserver.com
X-policyd-weight: using cached result; rate:hard: -6.1
Received: from lists.php.net (pb1.pair.com [76.75.200.58])
	by dd5506.kasserver.com (Postfix) with ESMTP id 3D4443121D46
	for <ulf.wendel@phpdoc.de>; Fri, 17 Oct 2014 15:09:14 +0200 (CEST)
X-Host-Fingerprint: 76.75.200.58 pb1.pair.com  
Received: from [76.75.200.58] ([76.75.200.58:13395] helo=lists.php.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 99/F6-30834-7F411445 for <ulf.wendel@phpdoc.de>; Fri, 17 Oct 2014 09:09:12 -0400
Received: (qmail 34839 invoked by uid 1010); 17 Oct 2014 13:09:08 -0000
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Precedence: bulk
list-help: <mailto:internals-help@lists.php.net>
list-unsubscribe: <mailto:internals-unsubscribe@lists.php.net>
list-post: <mailto:internals@lists.php.net>
List-Id: internals.lists.php.net
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 34831 invoked from network); 17 Oct 2014 13:09:08 -0000
Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
X-PHP-List-Original-Sender: lester@lsces.co.uk
X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6
Message-ID: <544114EF.8080903@lsces.co.uk>
Date: Fri, 17 Oct 2014 14:09:03 +0100
From: Lester Caine <lester@lsces.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAAyV7nFciZcsL+AW9W4GbhM+PhM3RhWOJ7G0iBQsEHfSWO2QmA@mail.gmail.com> <CAH-PCH6jVcXNtyySeY4EJZt2sQqhXFV=acO_x3HJb2f7WKtMPQ@mail.gmail.com> <543FE883.2070401@lerdorf.com> <54400765.90802@oracle.com> <5440E696.8050900@lsces.co.uk> <5440ECC4.4070903@phpdoc.de> <544101B9.6080601@lsces.co.uk> <54410970.2020100@phpdoc.de>
In-Reply-To: <54410970.2020100@phpdoc.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default
 for PDO_Mysql
X-KasLoop: m026cece

On 17/10/14 13:20, Ulf Wendel wrote:
>> users know what they are getting and where the real security holes are.
> Hmm, maybe, you could make this world a better one by contributing to
> improve http://php.net/manual/en/pdo.prepared-statements.php ?

PDO does not support management of SQL differences between databases.
This page is a good example of where users run into problems because
they have no idea if what they are copying actually works on their
particular database. Does MySQL need ATTR_EMULATE_PREPARES in order to
convert client side the SQL that it feeds over to the server? If I am
converting from one database to another just what is actually supported
and how?

I don't use PDO with Firebird if I can help it but I am having to work
with this where mysql hosting is the norm and PDO_mysql is an
alternative that gets provided instead of mysqli. *I* have trouble
sorting this stuff out so how do users who currently have working sites
cope when things under the hood change perhaps without them even knowing.

I can quite happily add notes as to what Firebird does with the various
abstractions on that page, but what about every other PDO driver. Which
emulate aspects of the prepares and which do it natively? Just what does
get emulated?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php




Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-01-28 12:47 UTC] cmb@php.net
-Package: Documentation problem +Package: PDO related
 [2020-05-17 16:12 UTC] tiffany@php.net
-Assigned To: +Assigned To: tiffany
 [2023-06-20 16:01 UTC] tiffany@php.net
-Status: Assigned +Status: Open -Assigned To: tiffany +Assigned To:
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC