12 / 2 / 2
Регистрация: 16.06.2017
Сообщений: 532
|
|
1 | |
MySQL Помогут ли мнемоники от SQL инъекции?24.02.2018, 09:14. Показов 2206. Ответов 33
Метки нет (Все метки)
Всем привет! Начал изучать PHP и с ним MySQL. PHP более или менее знаю, а вот MySQL почти нет. В интернете много читал о SQL инъекциях. Чтобы от них защититься помогут ли мнемоники? т.е. вместо кавычек(",'), точек с запятой( и т.п использовать мнемоники. Например: Пользователь вводит текст, который должен записать в БД. И есть код который проверяет этот текст на кавычки, точки с запятой и т.п и если они есть в тексте, то вместо них заменяет на мнемоники. И в случае, если вместо текста вредоносный код, то он же не будет, если нет кавычек и т.п, т.к вместо них мнемоники. Или я не прав и таким образом все равно может попасть SQL инъекция?
0
|
24.02.2018, 09:14 | |
Ответы с готовыми решениями:
33
SQL инъекции SQL-инъекции SQL инъекции SQL инъекции в запросах |
3851 / 3196 / 1343
Регистрация: 01.08.2012
Сообщений: 10,820
|
||||||
24.02.2018, 14:30 | 21 | |||||
А дальше что? Хранить в отдельном поле?
Да, только зачем обработанные данные в базе? Профит нулевой, геморрой гарантирован. А есть полный код? Просто этот пример обычно показывают как раз для демонстрации уязвимости htmlspecialchars. У меня есть пример ещё проще:
По вашему примеру пока не получается сделать инъекцию. Может где-то косячу, конечно.
0
|
14 / 60 / 21
Регистрация: 15.06.2017
Сообщений: 572
|
|
24.02.2018, 14:34 | 22 |
странное упорство в желание отказаться от инструмента специально предназначенного для решения конкретной задачи. Наколхозить лишних букв, исказить исходные данные и получить менее производительный код.
0
|
4925 / 3920 / 1620
Регистрация: 24.04.2014
Сообщений: 11,441
|
|||||||||||
24.02.2018, 14:44 | 23 | ||||||||||
полудух,
0
|
209 / 191 / 49
Регистрация: 15.03.2016
Сообщений: 1,211
|
|
24.02.2018, 15:05 | 24 |
зачем это вам понадобилось размер этот хранить?
просто юзеру сказали, чтобы уменьшил, а если ок, то сохранили (логин, а не размер) и забыли хранить то зачем? кем гарантирован геморрой? вами? блин ну что это за разговор: какой-то набор статейный фраз для начинающих студентов МИРЭА где вот конкретно вы в своём коде упёрлись в ситуацию, когда вам помешали htmlspecialchars(), м? вот я не нашёл таких ситуаций, пока писал свои CRM, магазин итд, а вы нашли? "всё бывает в первый раз", т.е. если за сотни тысяч строк не встретилось, значит это говорит не о том, что это ерунда, а о том, что надо дальше считать это очень важным, потому что обязательно встретится. OKAY Добавлено через 6 минут это от какого инструмента? я и не отказывался от prepared statements вы слышите только себя (
0
|
Jewbacabra
|
24.02.2018, 15:06
#25
|
0
|
209 / 191 / 49
Регистрация: 15.03.2016
Сообщений: 1,211
|
|
24.02.2018, 15:08 | 26 |
да и в мыслях не было
и это не я слился, это вы вот так сливаетесь, хлопнув дверью а я пытаюсь аргументами оперировать, но в ответ какие-то абстракции и обидки.
0
|
3851 / 3196 / 1343
Регистрация: 01.08.2012
Сообщений: 10,820
|
|
24.02.2018, 15:52 | 27 |
Мне это не нужно. Мне нужно знать длину строки. Вы предложили вычислять её при сохранении, для меня это значит вычислить длину и сохранить с остальными данными.
Может быть я выбрал не самый лучший пример, но проблема-то не ограничивается только им. Я не могу доверять функции LENGTH(). Я не могу найти самый короткий или самый длинный текст, или текст длиной менее 2000 символов. Просто потому что каждый спецсимвол считается за 6 символов. Да, не в каждом бложике требуется считать длину текста, но время от времени такие задачи встречаются, при вашем подходе нужно использовать более длинный путь - доставать из базы, декодировать, считать. Зачем мне это? Лично я нигде, поскольку использую эту функцию только там, где это необходимо. Ок, вы используете подготовленные запросы. Тогда тем более зачем вам htmlspecialchars при записи в базу? Ниодного аргумента так и не увидел. А о минусах сказал выше, плюс всегда нужно держать в голове, что в базе данные лежат в кодированном виде. Значит, когда я захочу вывести данные в PDF/Excel/Что_угодно, отдать через API или куда-нибудь отправить, мне всё время нужно будет сначала эти данные декодировать. Да, это несложно, но блин, зачем?! Чуть выше я показал пример взлома htmlspecialchars(). А вот ещё один пример, как раз по той концепции, которую вы пытались показать с escape_string: https://stackoverflow.com/ques... nclosed-in
0
|
209 / 191 / 49
Регистрация: 15.03.2016
Сообщений: 1,211
|
|
24.02.2018, 16:14 | 28 |
это вы про \0 чтоли?
null_byte убирается в первую очередь через str_replace(chr(0), '', $str); там мой пример 1 в 1 да я уж понял, что тут только себя слушают вот, уже какие-то примеры пошли наконец-то значит, что касается API, там данные должны быть в идеальном виде отфильтрованы. А по хорошему пользовательский ввод через API лучше вообще не передавать. ну а PDF/Excel -генераторы, насколько я помню, прекрасно справляются с html-entities.
0
|
3851 / 3196 / 1343
Регистрация: 01.08.2012
Сообщений: 10,820
|
|
25.02.2018, 13:20 | 29 |
Ещё как минимум
\b .Итого htmlspecialchars не даёт защиту от sql-инъекций. Подайте пример, услышьте меня. Никто не спорит с необходимостью кодирования перед выводом на экран. Я спрашиваю, зачем кодировать данные перед записью в базу данных. Какие конкретно от этого плюсы? Хорошо, а причём тут htmlspecialchars? Без неё нельзя отфильтровать данные? Нельзя записать в базу? В каком смысле справляются? Автоматически декодят все входящие данные?
0
|
209 / 191 / 49
Регистрация: 15.03.2016
Сообщений: 1,211
|
|||||||||||
25.02.2018, 17:41 | 30 | ||||||||||
в htmlspecialchars() просто мало символов на замену, но сам принцип замены опасных символов на html-коды работает на ура
в html_entity_decode() их наоборот слишком много, поэтому, как я говорил: мой список выглядит вот так:
Но на практике ваши "сырые данные" вам пригодятся в 100500 раз реже, чем именно безопасные. А спится с таким подходом гораздо крепче (разумеется в обнимку с pg_query_params()). Потому что одни люди находятся под внушением про "сырые данные это удобно", а другие практики. Хорошо, что мы хотя бы сошлись на том, что XSS это реальная угроза и кодировать надо в любом случае Вопрос лишь в том, ГДЕ именно кодировать - ДО или ПОСЛЕ вывода. Я уже приводил пример про таблицу, но помимо неё есть ещё формы на 50-100 полей, где надо будет каждое поле защищать от кавычек, иначе вам любой input превратят в <script>. + ещё надо будет в голове постоянно держать "а что я там вывожу - цифру или текст? А надо ли мне её кодировать?" А если ещё и в команде работаете, то надо чтобы другой кодер не забыл правильно вывести их и случайно дыру не оставил. Т.е. вы именно здесь себя обрекаете на геморрой, а не в случае "не сырых данных". MPDF, например, всё декодирует на автомате. зы: Полагаю, я уже достаточно инфы тут дал, чтобы понять суть дела, дальше сами разберётесь.
0
|
12 / 2 / 2
Регистрация: 16.06.2017
Сообщений: 532
|
|
25.02.2018, 17:53 [ТС] | 31 |
0
|
14 / 60 / 21
Регистрация: 15.06.2017
Сообщений: 572
|
|
25.02.2018, 18:09 | 32 |
практику уже давно бы стоило написать свой класс модели с подготовкой запросов.. строчек на 50. И грузить формы хоть в 1000 полей.
в голове полезно что-нибудь держать.
0
|
209 / 191 / 49
Регистрация: 15.03.2016
Сообщений: 1,211
|
|
25.02.2018, 18:19 | 33 |
у меня есть класс на создание/заполнение/валидацию/сабмит форм, который ещё и CSRF учитывает
но, во1, одними формами дело не ограничивается; а во2, это бессмысленная нагрузка и гемор.
0
|
3851 / 3196 / 1343
Регистрация: 01.08.2012
Сообщений: 10,820
|
|
25.02.2018, 18:52 | 34 |
Даже если он работает, это уже какая-то дичь, составлять списки потенциально опасных символов, вырезать их из данных перед записью в базу... подготовленные запросы защищают от sql-инъекций без лишней возни.
Для практики есть готовые библиотеки, где всё продумано и защищено за нас. Этого никто не отрицал. И здесь я не вижу никакой связи с необходимостью использовать htmlspecialchars до записи в базу. Кавычки отлично защищаются с помощью escape_string и подготовленных запросов. Думать над этим в любом случае надо. Где-то нужен исходный текст, где-то кодированный. Другой кодер может сделать ошибку где угодно, это не моя зона ответственности. А если используется шаблонизатор, можно настроить кодирование всех переменных по-умолчанию.
0
|
25.02.2018, 18:52 | |
25.02.2018, 18:52 | |
Помогаю со студенческими работами здесь
34
SQL Инъекции MySqli PDO и sql инъекции Htmlspecialchars и sql-инъекции Защита от SQL-инъекции Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |