Если нарушитель может записать команду в поле таблицы SQL, означает ли это что он всегда сможет ее выполнить?
Есть обычная таблица базы, с полем скажем birth_place. На фронтэнде, как и на бэкэнде, в это поле можно зафигачить что угодно. Знаю, что это отсутствие валидации - это неправильно - но разве может это представлять какую-то опасность само по себе? Даже если там записано DELETE * from Table1? И если может, то как?
Чтобы от SQL инъекции защитится в строчных полях достаточно заменить одиночные ковычки на две одиночные ковычки.
Например тебе в поле вписали DELETE * from Table1
Не обработано это полетит в базу как 'DELETE * from Table1' код не выполнится.
Но если отправить так Moskow'; DELETE * from Table1;
То сначала выполнится insert а после delete, в лучшем случае вылетит ошибка.
Но если принудительно одну ковычку реплейсить на две одиночные ковычки то этот весь запрос как строка запишется и нечего не произойдет
Slava Rozhnev, Василий Банников, Почему нельзя или не нужно? По мне так очень даже можно и нужно, например с pydantic приходят валидные данные, смысла нет повторную проверку типов делать и можно сразу через f'{}' вставить и строковые подреплейсить.
Сам код намного читабельнее становится, особенно если запрос большой строк на 50 минимум только SQL. либо когда sql код генерируется из разных функций тоже фстроки удобнее.
Когда требуется сделать insert сразу с тысячами строк одним запросом также форматирование удобнее.
В общем я просто написал базовый механизм защиты от инъекций а вы напали, всё можно, посмотрите на свои драйверы что они делают в такиих ситуациях? тоже самое!
Мне кажется наоборот - с параметрами читабельнее, тк не нужно мысленно с одного языка на другой переключаться.
+ база данных лучше кэширует план
+ например если будешь использовать постгрес, то можно передать кучу параметров как массив и от этого запрос не разжиреет
Ты правильно тегировал тему с SQL-Injection. Но ее наличие надо доказать.
Например - взять и вставить какой-то код в ячейку и попробовать воспроизвести.
Одних страхов - недостаточно.
Вадим, найди любую бизнес-логику где пользователь что-то вводит в ячейку. И это "что-то" попадает в билдер запросов. И если это что-то никак не экранируется служебными эскейп-последовательностями - то поздравляю. Ты нашел уязвимость. Заводи critical issue. И тебе дадут бейджик. Или премию.