Comments 21
Т.е. мы проверяем, что строка была захардкодена в коде или хотя бы «несильно изменена».
При этом: мы не гарантируем что строка изначально безопасна для любого использования. Т.е. строка может содержать кавычки которые безопасны для html, но небезопасны для sql, или же, безопасны/небезопасны в зависимисоти от того, какие кавычки используют в запросе.
Т.е. что даст эта «защита»?
Гарантии того, что строка написана/прочитана программистами, а не внешними пользователями
Может слышали про принцип "не доверяйте пользовательскому вводу"? Вот эта функция очень хороша для упрощения его реализации
Т.е. мой основной вопрос — даст ли это что то, или это будет очередной «театр безопасности» или «ложное ощущение защищённости».
Очень похоже на плохой костыль. Почему бы не пользовать обычный нормальный query builder?
Это как раз сделано для того, чтобы в query builder нельзя было передать пользовательский ввод. Только через placeholder-ы
А "программистский ввод" что, можно без плейсхолдеров, напрямую? О, сколько нам ошибок чудных...
Увы, да. В RFC как раз есть пример:
$qb->select('u')
->from('User', 'u')
->where('u.id = ' . $_GET['id']); // INSECURE$author="O'Hara"; // OK
$qb->select('u')
->from('User', 'u')
->where('u.id = ' . $author); // SQL errorВроде всё даже ок с точки зрения RFC. Везде — програмист написал код сам. Но… упасть всё может всё равно, и не особо секьюрности это добавляет.
да даже если убрать SQL Injection, это ничего не даст, кавычки то всё равно нужно использовать.
Ощущение защищенности :)
Судя по описанию эта защита не предназначена для того чтобы проверять "безопасна ли строка", для этого есть другие инструменты, она нужна только для того чтобы проверить источник, а уж насколько мы можем доверять программистам написавшим строку в коде - вопрос совсем для другого обсуждения. Это моя маленькая имха.
Меня смущает парочка других вопросов. Как тестировать? В тестах то всё написано программистом. Или юнит тесты тут как-то по особенному писать надо? Как это повлияет на производительность при работе со строками? Как эта функция отреагирует на строку полученную как-то вроде "$val = implode(',', array_map('intval',$_POST['params']))"?
Проблема SQL- и других инъекций всегда была очень острой для безопасности PHP приложений. Данный RFC предлагает частично решить вопрос подобных уязвимостей.
Что только не придумуют, лишь бы не использовать prepared statements.
А я жду Partial Function Application. По мне было бы круто писать все колбеки в едином стиле.
Про Bitrix Framework — смешно. Они D7 запустили в 2016 (могу ошибаться). До сих пор половина админки и ядра на старом API, в компонентах новое практически не используется, т.к. часть функционала, которая работает на старом ядре в новом не реализована, внятной документации — важнейшей части девелопмента — до сих пор нет. В существующей половина методов объявлено deprecated, какие использовать в новом ядре — не указывается. Официальный форум полумертвый.
Я у них недавно спрашивал здесь в комментах за композер, document root и прочее - сказали, что у них и так все хорошо
https://habr.com/ru/company/bitrix/blog/555232/#comment_22996426
Я ждал чего то подобного лет 5, я хейтил битрикс за отсутствие ООП, за передачу тонну элементов в массиве, за отсутствие поддержки php7.3+. Битрикс = это то, что не похоже ни на что. Специалист по битриксу !== специалист по php.
Даже представлять страшно, сколько будет вестись разработка, сколько будет полыхающих пятых точек при обновлении продукта на «новый» битрикс.
Но, по моему мнению, главная опасность для битриксовых студий другая — если человека научить симфонии, то ему придётся платить как симфонисту!
Например, как часто ты будешь использовать пересечения типов? Скорее всего, никогда
А я буду. Вот пример, где оно бы пригодилось (в Симфони все три интерфейса имплементированы в одном классе):
<?php
use Psr\Http\Client\ClientInterface;
use Psr\Http\Message\RequestFactoryInterface;
use Psr\Http\Message\StreamFactoryInterface;
class Dummy
{
public function __construct(private ClientInterface $httpClient)
{
if (!$httpClient instanceof RequestFactoryInterface) {
throw new LogicException(sprintf('HttpClient must implement %s', RequestFactoryInterface::class));
}
if (!$httpClient instanceof StreamFactoryInterface) {
throw new LogicException(sprintf('HttpClient must implement %s', StreamFactoryInterface::class));
}
// ...
}
}Вместо этого я бы в php 8.1 сделал так:
<?php
use Psr\Http\Client\ClientInterface;
use Psr\Http\Message\RequestFactoryInterface;
use Psr\Http\Message\StreamFactoryInterface;
class Dummy
{
public function __construct(
private ClientInterface&RequestFactoryInterface&StreamFactoryInterface $httpClient
) {}
}Можно, конечно, передавать имплементацию трижды в конструктор, но это выглядит так себе.
PHP Дайджест № 206 (15 – 29 июня 2021)