Помогут ли мнемоники от SQL инъекции?

@Риназ · Регистрация: 16.06.2017

Author24 — интернет-сервис помощи студентам

Всем привет! Начал изучать PHP и с ним MySQL. PHP более или менее знаю, а вот MySQL почти нет. В интернете много читал о SQL инъекциях. Чтобы от них защититься помогут ли мнемоники? т.е. вместо кавычек(",'), точек с запятой(

и т.п использовать мнемоники. Например: Пользователь вводит текст, который должен записать в БД. И есть код который проверяет этот текст на кавычки, точки с запятой и т.п и если они есть в тексте, то вместо них заменяет на мнемоники. И в случае, если вместо текста вредоносный код, то он же не будет, если нет кавычек и т.п, т.к вместо них мнемоники. Или я не прав и таким образом все равно может попасть SQL инъекция?

@Jodah · 24.02.2018, 14:30

Сообщение от полудух

да плевать, размер логина чекается при сохранении

А дальше что? Хранить в отдельном поле?

Сообщение от полудух

в итоге именно htmlspecialchars() спасает от XSS на 100%

Да, только зачем обработанные данные в базе? Профит нулевой, геморрой гарантирован.

Сообщение от полудух

вот вам пример инъекции (с участием эскейпинга, кстати):

А есть полный код? Просто этот пример обычно показывают как раз для демонстрации уязвимости htmlspecialchars. У меня есть пример ещё проще:

PHP

mysql_connect('localhost', 'root', '');
mysql_select_db('tester');
 
$login = "\0' /*";
$password = '*/ OR 1 #';
 
$login = htmlspecialchars($login, ENT_COMPAT, 'UTF-8');
$password = htmlspecialchars($password, ENT_COMPAT, 'UTF-8');
 
$sql = "SELECT * FROM `user` WHERE `login` = '$login' AND `password` = '$password'";
 
$r = mysql_query($sql) or die(mysql_error());
 
while($data = mysql_fetch_assoc($r))
    echo $data['id'] . '<br>';

Выведет всех юзеров из базы.

По вашему примеру пока не получается сделать инъекцию. Может где-то косячу, конечно.

@otto-fukin · 24.02.2018, 14:34

странное упорство в желание отказаться от инструмента специально предназначенного для решения конкретной задачи. Наколхозить лишних букв, исказить исходные данные и получить менее производительный код.

@Jewbacabra · 24.02.2018, 14:44

полудух,

PHP

$connect = mysqli_connect('mysql', 'root', 'example', 'test');
$l = mysqli_real_escape_string($connect, "') OR 1=1 /*\\");
$p = mysqli_real_escape_string($connect, "*/--'");
$sql = "SELECT * FROM `users` WHERE (`l`='".$l."' OR `e`='".$l."') AND `p`='".$p."'";
 
echo $sql;

все норм, строки заэкранировались отлично

MySQL

1	SELECT * FROM `users` WHERE (`l`='\') OR 1=1 /\\' OR `e`='\') OR 1=1 /\\') AND `p`='*/--\''

@полудух · 24.02.2018, 15:05

Сообщение от Jodah

А дальше что? Хранить в отдельном поле?

зачем это вам понадобилось размер этот хранить?
просто юзеру сказали, чтобы уменьшил, а если ок, то сохранили (логин, а не размер) и забыли
хранить то зачем?

Сообщение от Jodah

Да, только зачем обработанные данные в базе? Профит нулевой, геморрой гарантирован.

кем гарантирован геморрой? вами?
блин ну что это за разговор:

Сообщение от otto-fukin

получить менее производительный код

Сообщение от Jewbacabra

Все когда-то бывает в первый раз

Сообщение от Jodah

геморрой гарантирован

Сообщение от Jewbacabra

работать проще с сырыми данными

Сообщение от Jewbacabra

выдумка

какой-то набор статейный фраз для начинающих студентов МИРЭА
где вот конкретно вы в своём коде упёрлись в ситуацию, когда вам помешали htmlspecialchars(), м?
вот я не нашёл таких ситуаций, пока писал свои CRM, магазин итд, а вы нашли?

"всё бывает в первый раз", т.е. если за сотни тысяч строк не встретилось, значит это говорит не о том, что это ерунда, а о том, что надо дальше считать это очень важным, потому что обязательно встретится.
OKAY

Добавлено через 6 минут

Сообщение от otto-fukin

странное упорство в желание отказаться от инструмента специально предназначенного для решения конкретной задачи.

это от какого инструмента? я и не отказывался от prepared statements
вы слышите только себя (

@Jewbacabra · 24.02.2018, 15:06

Не по теме:

Сообщение от полудух

какой-то набор статейный фраз для начинающих студентов МИРЭА

Слился и решил перейти на личности? Дальше продолжать наше общение не намерен.

@полудух · 24.02.2018, 15:08

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

@Jodah · 24.02.2018, 15:52

Сообщение от полудух

зачем это вам понадобилось размер этот хранить?

Мне это не нужно. Мне нужно знать длину строки. Вы предложили вычислять её при сохранении, для меня это значит вычислить длину и сохранить с остальными данными.

Может быть я выбрал не самый лучший пример, но проблема-то не ограничивается только им. Я не могу доверять функции LENGTH(). Я не могу найти самый короткий или самый длинный текст, или текст длиной менее 2000 символов. Просто потому что каждый спецсимвол считается за 6 символов.

Да, не в каждом бложике требуется считать длину текста, но время от времени такие задачи встречаются, при вашем подходе нужно использовать более длинный путь - доставать из базы, декодировать, считать. Зачем мне это?

Сообщение от полудух

где вот конкретно вы в своём коде упёрлись в ситуацию, когда вам помешали htmlspecialchars(), м?

Лично я нигде, поскольку использую эту функцию только там, где это необходимо.

Сообщение от полудух

это от какого инструмента? я и не отказывался от prepared statements

Ок, вы используете подготовленные запросы. Тогда тем более зачем вам htmlspecialchars при записи в базу? Ниодного аргумента так и не увидел.

А о минусах сказал выше, плюс всегда нужно держать в голове, что в базе данные лежат в кодированном виде. Значит, когда я захочу вывести данные в PDF/Excel/Что_угодно, отдать через API или куда-нибудь отправить, мне всё время нужно будет сначала эти данные декодировать. Да, это несложно, но блин, зачем?!

Сообщение от полудух

я начал с того, что только htmlspecialchars() может сразу спасти И от инъекции, И от XSS

Чуть выше я показал пример взлома htmlspecialchars(). А вот ещё один пример, как раз по той концепции, которую вы пытались показать с escape_string:

https://stackoverflow.com/ques... nclosed-in

@полудух · 24.02.2018, 16:14

Сообщение от Jodah

Чуть выше я показал пример взлома htmlspecialchars()

это вы про \0 чтоли?
null_byte убирается в первую очередь через str_replace(chr(0), '', $str);

Сообщение от Jodah

А вот ещё один пример, как раз по той концепции, которую вы пытались показать с escape_string:
https://stackoverflow.com/ques... nclosed-in

там мой пример 1 в 1

Сообщение от Jodah

Ок, вы используете подготовленные запросы. Тогда тем более зачем вам htmlspecialchars при записи в базу? Ниодного аргумента так и не увидел.

да я уж понял, что тут только себя слушают

Сообщение от полудух

подготовленные запросы не спасут от XSS

Сообщение от полудух

в итоге именно htmlspecialchars() спасает от XSS на 100%, а всё остальное - костыли и взлом, как результат

Сообщение от Jodah

Значит, когда я захочу вывести данные в PDF/Excel/Что_угодно, отдать через API или куда-нибудь отправить, мне всё время нужно будет сначала эти данные декодировать.

вот, уже какие-то примеры пошли наконец-то
значит, что касается API, там данные должны быть в идеальном виде отфильтрованы. А по хорошему пользовательский ввод через API лучше вообще не передавать.
ну а PDF/Excel -генераторы, насколько я помню, прекрасно справляются с html-entities.

@Jodah · 25.02.2018, 13:20

Сообщение от полудух

null_byte убирается в первую очередь через str_replace(chr(0), '', $str);

Ещё как минимум \b.

Итого htmlspecialchars не даёт защиту от sql-инъекций.

Сообщение от полудух

да я уж понял, что тут только себя слушают

Подайте пример, услышьте меня. Никто не спорит с необходимостью кодирования перед выводом на экран. Я спрашиваю, зачем кодировать данные перед записью в базу данных. Какие конкретно от этого плюсы?

Сообщение от полудух

значит, что касается API, там данные должны быть в идеальном виде отфильтрованы.

Хорошо, а причём тут htmlspecialchars? Без неё нельзя отфильтровать данные? Нельзя записать в базу?

Сообщение от полудух

ну а PDF/Excel -генераторы, насколько я помню, прекрасно справляются с html-entities.

В каком смысле справляются? Автоматически декодят все входящие данные?

@полудух · 25.02.2018, 17:41

Сообщение от Jodah

Ещё как минимум \b.
Итого htmlspecialchars не даёт защиту от sql-инъекций.

в htmlspecialchars() просто мало символов на замену, но сам принцип замены опасных символов на html-коды работает на ура
в html_entity_decode() их наоборот слишком много, поэтому, как я говорил:

Сообщение от полудух

но вообще-то можно вручную сразу отлавливать через str_replace() всякие: & /* */ -- $

мой список выглядит вот так:

PHP

1	array('&','<','>',"'",'"','_','`','$','%','\\','/','/','//','--');

если вам потребуется в CSV куда-то переслать данные, то берёте второй список:

PHP

1	array('&','<','>',''','"','_','`','$','%','\','/','/','//','&dash;&dash;');

и меняете их местами.
Но на практике ваши "сырые данные" вам пригодятся в 100500 раз реже, чем именно безопасные.
А спится с таким подходом гораздо крепче (разумеется в обнимку с pg_query_params()).

Сообщение от Jodah

Подайте пример, услышьте меня. Никто не спорит с необходимостью кодирования перед выводом на экран. Я спрашиваю, зачем кодировать данные перед записью в базу данных. Какие конкретно от этого плюсы?

Потому что одни люди находятся под внушением про "сырые данные это удобно", а другие практики.
Хорошо, что мы хотя бы сошлись на том, что XSS это реальная угроза и кодировать надо в любом случае

Вопрос лишь в том, ГДЕ именно кодировать - ДО или ПОСЛЕ вывода.

Я уже приводил пример про таблицу, но помимо неё есть ещё формы на 50-100 полей, где надо будет каждое поле защищать от кавычек, иначе вам любой input превратят в <script>.
+ ещё надо будет в голове постоянно держать "а что я там вывожу - цифру или текст? А надо ли мне её кодировать?"
А если ещё и в команде работаете, то надо чтобы другой кодер не забыл правильно вывести их и случайно дыру не оставил.
Т.е. вы именно здесь себя обрекаете на геморрой, а не в случае "не сырых данных".

Сообщение от Jodah

В каком смысле справляются? Автоматически декодят все входящие данные?

MPDF, например, всё декодирует на автомате.

зы: Полагаю, я уже достаточно инфы тут дал, чтобы понять суть дела, дальше сами разберётесь.

@Риназ · 25.02.2018, 17:53 **[ТС]**

Сообщение от полудух

в html_entity_decode() их наоборот слишком много

А что в этом плохого? Защиты много не бывает

@otto-fukin · 25.02.2018, 18:09

Сообщение от полудух

есть ещё формы на 50-100 полей, где надо будет каждое поле защищать от кавычек, иначе вам любой input превратят в <script>.

практику уже давно бы стоило написать свой класс модели с подготовкой запросов.. строчек на 50. И грузить формы хоть в 1000 полей.

Сообщение от полудух

ещё надо будет в голове постоянно держать

в голове полезно что-нибудь держать.

@полудух · 25.02.2018, 18:19

Сообщение от otto-fukin

практику уже давно бы стоило написать свой класс модели с подготовкой запросов.. строчек на 50. И грузить формы хоть в 1000 полей.

у меня есть класс на создание/заполнение/валидацию/сабмит форм, который ещё и CSRF учитывает
но, во1, одними формами дело не ограничивается;
а во2, это бессмысленная нагрузка и гемор.

@Jodah · 25.02.2018, 18:52

Сообщение от полудух

сам принцип замены опасных символов на html-коды работает на ура

Даже если он работает, это уже какая-то дичь, составлять списки потенциально опасных символов, вырезать их из данных перед записью в базу... подготовленные запросы защищают от sql-инъекций без лишней возни.

Сообщение от полудух

Потому что одни люди находятся под внушением про "сырые данные это удобно", а другие практики.

Для практики есть готовые библиотеки, где всё продумано и защищено за нас.

Сообщение от полудух

Хорошо, что мы хотя бы сошлись на том, что XSS это реальная угроза

Этого никто не отрицал.

Сообщение от полудух

есть ещё формы на 50-100 полей, где надо будет каждое поле защищать от кавычек

И здесь я не вижу никакой связи с необходимостью использовать htmlspecialchars до записи в базу. Кавычки отлично защищаются с помощью escape_string и подготовленных запросов.

Сообщение от полудух

ещё надо будет в голове постоянно держать "а что я там вывожу - цифру или текст? А надо ли мне её кодировать?"

Думать над этим в любом случае надо. Где-то нужен исходный текст, где-то кодированный.

Сообщение от полудух

А если ещё и в команде работаете, то надо чтобы другой кодер не забыл правильно вывести их и случайно дыру не оставил.

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

@otto-fukin 14 / 60 / 21 Регистрация: 15.06.2017 Сообщений: 572
	24.02.2018, 14:34	22
	странное упорство в желание отказаться от инструмента специально предназначенного для решения конкретной задачи. Наколхозить лишних букв, исказить исходные данные и получить менее производительный код. 0

@полудух 209 / 191 / 49 Регистрация: 15.03.2016 Сообщений: 1,211
	24.02.2018, 15:08	26
	да и в мыслях не было и это не я слился, это вы вот так сливаетесь, хлопнув дверью а я пытаюсь аргументами оперировать, но в ответ какие-то абстракции и обидки. 0

@Jodah 3851 / 3196 / 1343 Регистрация: 01.08.2012 Сообщений: 10,820
	24.02.2018, 15:52	27
	Сообщение от полудух зачем это вам понадобилось размер этот хранить? Мне это не нужно. Мне нужно знать длину строки. Вы предложили вычислять её при сохранении, для меня это значит вычислить длину и сохранить с остальными данными. Может быть я выбрал не самый лучший пример, но проблема-то не ограничивается только им. Я не могу доверять функции LENGTH(). Я не могу найти самый короткий или самый длинный текст, или текст длиной менее 2000 символов. Просто потому что каждый спецсимвол считается за 6 символов. Да, не в каждом бложике требуется считать длину текста, но время от времени такие задачи встречаются, при вашем подходе нужно использовать более длинный путь - доставать из базы, декодировать, считать. Зачем мне это? Сообщение от полудух где вот конкретно вы в своём коде упёрлись в ситуацию, когда вам помешали htmlspecialchars(), м? Лично я нигде, поскольку использую эту функцию только там, где это необходимо. Сообщение от полудух это от какого инструмента? я и не отказывался от prepared statements Ок, вы используете подготовленные запросы. Тогда тем более зачем вам htmlspecialchars при записи в базу? Ниодного аргумента так и не увидел. А о минусах сказал выше, плюс всегда нужно держать в голове, что в базе данные лежат в кодированном виде. Значит, когда я захочу вывести данные в PDF/Excel/Что_угодно, отдать через API или куда-нибудь отправить, мне всё время нужно будет сначала эти данные декодировать. Да, это несложно, но блин, зачем?! Сообщение от полудух я начал с того, что только htmlspecialchars() может сразу спасти И от инъекции, И от XSS Чуть выше я показал пример взлома htmlspecialchars(). А вот ещё один пример, как раз по той концепции, которую вы пытались показать с escape_string: https://stackoverflow.com/ques... nclosed-in 0

@полудух 209 / 191 / 49 Регистрация: 15.03.2016 Сообщений: 1,211
	24.02.2018, 16:14	28
	Сообщение от Jodah Чуть выше я показал пример взлома htmlspecialchars() это вы про \0 чтоли? null_byte убирается в первую очередь через str_replace(chr(0), '', $str); Сообщение от Jodah А вот ещё один пример, как раз по той концепции, которую вы пытались показать с escape_string: https://stackoverflow.com/ques... nclosed-in там мой пример 1 в 1 Сообщение от Jodah Ок, вы используете подготовленные запросы. Тогда тем более зачем вам htmlspecialchars при записи в базу? Ниодного аргумента так и не увидел. да я уж понял, что тут только себя слушают Сообщение от полудух подготовленные запросы не спасут от XSS Сообщение от полудух в итоге именно htmlspecialchars() спасает от XSS на 100%, а всё остальное - костыли и взлом, как результат Сообщение от Jodah Значит, когда я захочу вывести данные в PDF/Excel/Что_угодно, отдать через API или куда-нибудь отправить, мне всё время нужно будет сначала эти данные декодировать. вот, уже какие-то примеры пошли наконец-то значит, что касается API, там данные должны быть в идеальном виде отфильтрованы. А по хорошему пользовательский ввод через API лучше вообще не передавать. ну а PDF/Excel -генераторы, насколько я помню, прекрасно справляются с html-entities. 0

@Jodah 3851 / 3196 / 1343 Регистрация: 01.08.2012 Сообщений: 10,820
	25.02.2018, 13:20	29
	Сообщение от полудух null_byte убирается в первую очередь через str_replace(chr(0), '', $str); Ещё как минимум `\b`. Итого htmlspecialchars не даёт защиту от sql-инъекций. Сообщение от полудух да я уж понял, что тут только себя слушают Подайте пример, услышьте меня. Никто не спорит с необходимостью кодирования перед выводом на экран. Я спрашиваю, зачем кодировать данные перед записью в базу данных. Какие конкретно от этого плюсы? Сообщение от полудух значит, что касается API, там данные должны быть в идеальном виде отфильтрованы. Хорошо, а причём тут htmlspecialchars? Без неё нельзя отфильтровать данные? Нельзя записать в базу? Сообщение от полудух ну а PDF/Excel -генераторы, насколько я помню, прекрасно справляются с html-entities. В каком смысле справляются? Автоматически декодят все входящие данные? 0

@Риназ 12 / 2 / 2 Регистрация: 16.06.2017 Сообщений: 532
		1
	MySQL Помогут ли мнемоники от SQL инъекции? 24.02.2018, 09:14. Показов 2206. Ответов 33 Метки нет (Все метки) Всем привет! Начал изучать PHP и с ним MySQL. PHP более или менее знаю, а вот MySQL почти нет. В интернете много читал о SQL инъекциях. Чтобы от них защититься помогут ли мнемоники? т.е. вместо кавычек(",'), точек с запятой( и т.п использовать мнемоники. Например: Пользователь вводит текст, который должен записать в БД. И есть код который проверяет этот текст на кавычки, точки с запятой и т.п и если они есть в тексте, то вместо них заменяет на мнемоники. И в случае, если вместо текста вредоносный код, то он же не будет, если нет кавычек и т.п, т.к вместо них мнемоники. Или я не прав и таким образом все равно может попасть SQL инъекция? 0

@полудух 209 / 191 / 49 Регистрация: 15.03.2016 Сообщений: 1,211
	24.02.2018, 15:05	24
	Сообщение от Jodah А дальше что? Хранить в отдельном поле? зачем это вам понадобилось размер этот хранить? просто юзеру сказали, чтобы уменьшил, а если ок, то сохранили (логин, а не размер) и забыли хранить то зачем? Сообщение от Jodah Да, только зачем обработанные данные в базе? Профит нулевой, геморрой гарантирован. кем гарантирован геморрой? вами? блин ну что это за разговор: Сообщение от otto-fukin получить менее производительный код Сообщение от Jewbacabra Все когда-то бывает в первый раз Сообщение от Jodah геморрой гарантирован Сообщение от Jewbacabra работать проще с сырыми данными Сообщение от Jewbacabra выдумка какой-то набор статейный фраз для начинающих студентов МИРЭА где вот конкретно вы в своём коде упёрлись в ситуацию, когда вам помешали htmlspecialchars(), м? вот я не нашёл таких ситуаций, пока писал свои CRM, магазин итд, а вы нашли? "всё бывает в первый раз", т.е. если за сотни тысяч строк не встретилось, значит это говорит не о том, что это ерунда, а о том, что надо дальше считать это очень важным, потому что обязательно встретится. OKAY Добавлено через 6 минут Сообщение от otto-fukin странное упорство в желание отказаться от инструмента специально предназначенного для решения конкретной задачи. это от какого инструмента? я и не отказывался от prepared statements вы слышите только себя ( 0

@Jewbacabra
	24.02.2018, 15:06 #25
	Не по теме: Сообщение от полудух какой-то набор статейный фраз для начинающих студентов МИРЭА Слился и решил перейти на личности? Дальше продолжать наше общение не намерен. 0

@Риназ 12 / 2 / 2 Регистрация: 16.06.2017 Сообщений: 532
	25.02.2018, 17:53 [ТС]	31
	Сообщение от полудух в html_entity_decode() их наоборот слишком много А что в этом плохого? Защиты много не бывает 0

@otto-fukin 14 / 60 / 21 Регистрация: 15.06.2017 Сообщений: 572
	25.02.2018, 18:09	32
	Сообщение от полудух есть ещё формы на 50-100 полей, где надо будет каждое поле защищать от кавычек, иначе вам любой input превратят в <script>. практику уже давно бы стоило написать свой класс модели с подготовкой запросов.. строчек на 50. И грузить формы хоть в 1000 полей. Сообщение от полудух ещё надо будет в голове постоянно держать в голове полезно что-нибудь держать. 0

@полудух 209 / 191 / 49 Регистрация: 15.03.2016 Сообщений: 1,211
	25.02.2018, 18:19	33
	Сообщение от otto-fukin практику уже давно бы стоило написать свой класс модели с подготовкой запросов.. строчек на 50. И грузить формы хоть в 1000 полей. у меня есть класс на создание/заполнение/валидацию/сабмит форм, который ещё и CSRF учитывает но, во1, одними формами дело не ограничивается; а во2, это бессмысленная нагрузка и гемор. 0

@Jodah 3851 / 3196 / 1343 Регистрация: 01.08.2012 Сообщений: 10,820
	25.02.2018, 18:52	34
	Сообщение от полудух сам принцип замены опасных символов на html-коды работает на ура Даже если он работает, это уже какая-то дичь, составлять списки потенциально опасных символов, вырезать их из данных перед записью в базу... подготовленные запросы защищают от sql-инъекций без лишней возни. Сообщение от полудух Потому что одни люди находятся под внушением про "сырые данные это удобно", а другие практики. Для практики есть готовые библиотеки, где всё продумано и защищено за нас. Сообщение от полудух Хорошо, что мы хотя бы сошлись на том, что XSS это реальная угроза Этого никто не отрицал. Сообщение от полудух есть ещё формы на 50-100 полей, где надо будет каждое поле защищать от кавычек И здесь я не вижу никакой связи с необходимостью использовать htmlspecialchars до записи в базу. Кавычки отлично защищаются с помощью escape_string и подготовленных запросов. Сообщение от полудух ещё надо будет в голове постоянно держать "а что я там вывожу - цифру или текст? А надо ли мне её кодировать?" Думать над этим в любом случае надо. Где-то нужен исходный текст, где-то кодированный. Сообщение от полудух А если ещё и в команде работаете, то надо чтобы другой кодер не забыл правильно вывести их и случайно дыру не оставил. Другой кодер может сделать ошибку где угодно, это не моя зона ответственности. А если используется шаблонизатор, можно настроить кодирование всех переменных по-умолчанию. 0