Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115091 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9568 invoked from network); 24 Jun 2021 01:04:42 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Jun 2021 01:04:42 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 96AB81804F3 for ; Wed, 23 Jun 2021 18:23:21 -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, 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-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (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 ; Wed, 23 Jun 2021 18:23:21 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id b7so5827139ioq.12 for ; Wed, 23 Jun 2021 18:23:21 -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=Vm3qKPut/dy4GUvkRp/9pdBPqnxkHcoJc8yIml+2R84=; b=IlMWYtqp3TfeWeiv4ASsZR17UJHm1YnF7xaBDVlucjtKdK2GvQZQypgRq/0PVz5NGe f8+BgWsK1nhf/hXYGj7TNzy5t4gOiZpICSKjGt8ZaHo+3FIyO6hH7F5YBUtfeIeU5h54 AAo5myC6aNKE35xJDQMT41+Q97YCh5xjE+OTKAvIpwaMx0VEaaRYveOuS1TBuJt38vn3 5mGIIwwcvJzD1cCMoUxr4NqkfrxMU026QgTmtKCa+bw1mec8UwnCCzAan+0H63LkqU2r e1bC9KS3W/FpSgb6F/Ar9Fnb/mGDrPm7gf/DuXjjwzTwdmet7YfuGOQUFtUs/7fdvXiO rzgQ== 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=Vm3qKPut/dy4GUvkRp/9pdBPqnxkHcoJc8yIml+2R84=; b=eA1L+pyHbsKQCmrLa+Ug6EZmW4YoZTeMWRdG2SP5vty4eFHpgqjur7VzpevjTOwqMy RELOis6EBqdWNBWClYCW6M20psM/MCbIxc0BE0Qy+LU7s+60UDdMlxRDTNCdhyNSazzW wIgSYg2+6FqGJod7829/QBgIM7Yk8jh5LfhuFhIhKwmUDOTly0QfzExruZUs02y4S9Xe KVgY3oTUD/xUKEXbvEM7MLe+hOcnzQOhc7ztvMnOaHoSzHZ0hflK7qBKuqdiTQT+PUh/ f08YXjYB3ow8yDuMoVB70aRs1BBOhQHfar9eKOdZY98QjoyVQw0KfArnyq2aFp80esAZ M+IQ== X-Gm-Message-State: AOAM5319yJf3NO1mijIPxFT4PXcH24l7rWCl8ztg3quVLxxCxKvD/ptL H+78jehLS4oD1SNejza2S+CBzGD4gDh5l8eX3j4= X-Google-Smtp-Source: ABdhPJyQ69lRFi1tlYHFnnyflug5uclNTST0qEcxcdNKLjpshPnAvWQso2jVdVxHoUvryLt9/M7b7inb2UrK94KZQRM= X-Received: by 2002:a6b:fe09:: with SMTP id x9mr1857845ioh.111.1624497799709; Wed, 23 Jun 2021 18:23:19 -0700 (PDT) MIME-Version: 1.0 References: <03f7955c-69a8-4841-9245-449d7851e207@www.fastmail.com> In-Reply-To: Date: Thu, 24 Jun 2021 04:22:53 +0300 Message-ID: To: Scott Arciszewski Cc: Craig Francis , Larry Garfield , php internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted From: weirdan@gmail.com (Bruce Weirdan) On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski wrote: > The failure condition of this query is > "return all rows from the table already being queried", not "return > arbitrary data the attacker selects from any table that the > application can read". Imagine that was a DELETE rather than SELECT and the failure condition becomes 'the table is emptied'. It may have less disastrous consequences (depending on how good your backup / restore procedures are) compared to arbitrary reads you demonstrated, but it is still, quite clearly, a glaring security hole caused by user input in SQL query - AKA SQL injection in layman's terms. > it differs from Injection vulnerabilities in one > fundamental way: The attacker cannot change the structure of the SQL > query being executed. I would say replacing a column name with value is changing the structure of SQL query, and, basically, in exactly the way you describe SQL injection: confusing the code (column name) with data. I wholeheartedly welcome this RFC as it was originally proposed: is_literal() doing exactly what it says on the tin, without any security claims. But it has gone far from there real quick and now people can't even name the thing. -- Best regards, Bruce Weirdan mailto:weirdan@gmail.com