Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115467 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 40265 invoked from network); 19 Jul 2021 01:46:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Jul 2021 01:46:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 69D6C1804C8 for ; Sun, 18 Jul 2021 19:11:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 18 Jul 2021 19:11:36 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id g8so21518397lfh.8 for ; Sun, 18 Jul 2021 19:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GzlKcdL3YIPTIAC8KGfKHyu0hIPauxzcilhaY/t0kog=; b=UmqDmui254fuU4f8wZ6yggwPdxGwCPaFHlDcxS3s/9sSKRu5NFumMDsH5R03PVDKkY CDWO+JoGVBN53j2orxNtnfSobl/Tx1RrFo/0WL7HsUiQT1sWPfM/WCq3zFa+mYGXrP/O 3nDzwlhuMRmJ+73toL55v75dk1YH7mjuj4YUzQ666BsUk1x8GBjkP4n3z0DCtZnIHK5K EA/NQ0HkyGKsGodeDXU0Wi5XJzxgTXLqtDeDomIo2nWAnw1s4e6wxsj0UBwr1WzVQ5Jd KjmGKPSEzsSsjFHaYSeDETwj/iYm5ioWNLZnj1HdwkhEwZtsVKw2pUIdYBVKVLYH9YJc BP4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GzlKcdL3YIPTIAC8KGfKHyu0hIPauxzcilhaY/t0kog=; b=OKZ7VQIITayYHtd1ZKTMakbrLabc0hp64IyPNwjAES5TUZxN408BCP2JvR5z68pjq/ P/eZYod3T+FFEJdiW0dD6I49/XgkKp0hCtAzH/LSiZy5kCnn+Oa/XAdMejA7U4AXKS4K bIYpVjX1swuEx4Pv8YvsfeSpjRZR+Rr6GSgveuWDoPqgwLEukBk2dqifiPkapt2WMwJE WoBsSC1k339yTEmIpAhUOFJWXd7FBk6mngAu6uyZp/rLX4OOQHP0RLO5rQutQEe8h9bT X4rSPbljhA16Lwg7kRTXnIla2xhX/0XOWVthF9qohyUyWxsbI+1XyFYneDAT958Db56d y6eg== X-Gm-Message-State: AOAM532vznY3a/h3MYYrf5g4Dwi27cCCRxUHhosFoUBTD/TBlFV82rQ8 Js1v1XIQYM8NYO2/qrW0TJ68qQCsN4UQem19ZnM= X-Google-Smtp-Source: ABdhPJxGS8pi1t5Q2sM1abgdKGsGKbvaAxSEq2NNOrMCCIojQ2DRTPNxxbEjYb+Al+V+HK+0L7bsA/+hobLXzc4+a8s= X-Received: by 2002:ac2:569e:: with SMTP id 30mr16947265lfr.322.1626660692913; Sun, 18 Jul 2021 19:11:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 18 Jul 2021 19:11:22 -0700 Message-ID: To: Benjamin Morel Cc: AllenJB , Craig Francis , Marco Pivetta , PHP internals Content-Type: multipart/alternative; boundary="000000000000c5725c05c77074c0" Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000c5725c05c77074c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Are there documented SQL injection opportunities when using emulated prepares? I'm not aware of any. This was from my reading of the actual source, which of course may be flawed. It appeared that if emulated prepares were used the values were escaped and then passed as strings as part of the query, the same as if it had been concatenated and wrapped in real_escape_string. I hadn't gone too far in actually debugging it yet to find out how it behaved under different circumstances as I was still trying to figure out how "small" of a change this was from the perspective of internals. On Sun, Jul 18, 2021 at 3:38 PM Benjamin Morel wrote: > There's some BC-breaks to be aware of when switching emulated prepares. >> One example I know of is that when using emulated prepares you can reuse >> the same placeholder (as in the following example), but with emulated >> prepares disabled this does not work. >> >> $sql =3D "SELECT * FROM table WHERE column1 LIKE CONCAT('%', :searchValu= e, >> '%') OR column2 LIKE CONCAT('%', :searchValue, '%');"; >> $params =3D [ >> "searchValue" =3D> "test", >> ]; >> > > This, and do note that from a performance point of view, disabling > emulated prepares is not innocuous : most of the time, you effectively se= nd > twice as many queries to the database : one prepare, one execute. > There is a *small* performance improvement in using prepared statements > if you're executing the same statement many times; but in all other cases= , > you're spending twice as much time waiting for the database. > > Are there documented SQL injection opportunities when using emulated > prepares? I'm not aware of any. > > =E2=80=94 Benjamin > --000000000000c5725c05c77074c0--