Pull to refresh

Comments 21

Не совсем понимаю, что даст "[RFC] Is_Noble"?
Т.е. мы проверяем, что строка была захардкодена в коде или хотя бы «несильно изменена».
При этом: мы не гарантируем что строка изначально безопасна для любого использования. Т.е. строка может содержать кавычки которые безопасны для 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, это ничего не даст, кавычки то всё равно нужно использовать.
Такая ошибка очень быстро обнаруживается на этапе разработки. А вот ->where('u.id = ' . $_GET['id']); всплывет попозже и, вероятно, с большими потерями для бизнеса.

Ощущение защищенности :)

Судя по описанию эта защита не предназначена для того чтобы проверять "безопасна ли строка", для этого есть другие инструменты, она нужна только для того чтобы проверить источник, а уж насколько мы можем доверять программистам написавшим строку в коде - вопрос совсем для другого обсуждения. Это моя маленькая имха.

Меня смущает парочка других вопросов. Как тестировать? В тестах то всё написано программистом. Или юнит тесты тут как-то по особенному писать надо? Как это повлияет на производительность при работе со строками? Как эта функция отреагирует на строку полученную как-то вроде "$val = implode(',', array_map('intval',$_POST['params']))"?

Проблема SQL- и других инъекций всегда была очень острой для безопасности PHP приложений. Данный RFC предлагает частично решить вопрос подобных уязвимостей.

Что только не придумуют, лишь бы не использовать prepared statements.
эта вещь сделана для разработчиков коннекторов к бд, как раз чтобы не давать не использовать prepared statements

А я жду Partial Function Application. По мне было бы круто писать все колбеки в едином стиле.

Про Bitrix Framework — смешно. Они D7 запустили в 2016 (могу ошибаться). До сих пор половина админки и ядра на старом API, в компонентах новое практически не используется, т.к. часть функционала, которая работает на старом ядре в новом не реализована, внятной документации — важнейшей части девелопмента — до сих пор нет. В существующей половина методов объявлено deprecated, какие использовать в новом ядре — не указывается. Официальный форум полумертвый.

смею утверждать, что новость про bitrix — это самая увлекательная из всей подборки.
Я ждал чего то подобного лет 5, я хейтил битрикс за отсутствие ООП, за передачу тонну элементов в массиве, за отсутствие поддержки php7.3+. Битрикс = это то, что не похоже ни на что. Специалист по битриксу !== специалист по php.
Даже представлять страшно, сколько будет вестись разработка, сколько будет полыхающих пятых точек при обновлении продукта на «новый» битрикс.
Но, по моему мнению, главная опасность для битриксовых студий другая — если человека научить симфонии, то ему придётся платить как симфонисту!
Сказку про то что «скоро перепишем красиво» я слышал ещё 10 лет назад, для маркетологов система же, не для разработчиков, так оно и осталось. Хотя наверное есть там люди которые пытаются титаническими усилиями это сдвинуть, но их выкидывают в окна…
Например, как часто ты будешь использовать пересечения типов? Скорее всего, никогда

А я буду. Вот пример, где оно бы пригодилось (в Симфони все три интерфейса имплементированы в одном классе):


<?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
    ) {}
}

Можно, конечно, передавать имплементацию трижды в конструктор, но это выглядит так себе.

Only those users with full accounts are able to leave comments. Log in, please.