Mysql Защита от SQL-инъекций в PHP и MySQL

vasinsky

Новичок
угроза минимальна

но по уму использовать real_escape_string() - для строковых значений
и приведение к типу для остальных, например (int)$id

с addslashes - потом запарки с stripslashes

и при выводе (если ты кнечно там исходный код не хранишь) - при выводе использовать htmlspesialchars()
или тупо striptags - при вводе данных в БД - если тебе там нафиг теги не нужны
 

vasinsky

Новичок
addslashes - совершенно всё равну на кодировку, но и использовать её для экранированя данных - предназначенных для БД - накладно, как я и писал выше - есть специальные для этого механизмы
 

vasinsky

Новичок
русские - не русские - а весь цивилизованный мир уже давно работает в юникоде)
 

fixxxer

К.О.
Партнер клуба
Кодировка очевидно не китайская. Либо UTF-8, либо windows-1251 так как мы русские, в моем случае первый вариант.
В случае utf-8/cp1251 ничего страшного не произойдет. В случае иной многобайтовой кодировки (скажем UTF-16) addslashes может банально испортить данные, подписав слэши куда не надо.

Еще экзотический вариант. В mysql есть настройка ANSI-совместимости, которая включает экранирование по SQL-стандарту - удвоением кавычки. Экранирование слэшом при этом не отменяется, но ничто не исключает появления настройки, отменяющей таковое, в будущем. mysql_real_escape_string в случае появления таковой настройки будет ее учитывать, т.к. в курсе контекста соединения.

И, конечно же, лучше использовать плейсхолдеры - забыть где-то сделать явное экранирование очень просто, а найти такое место очень сложно. В олдскульных говнокод-форумах типа IPB подобные уязвимости находили годами.
 
Последнее редактирование:

D_Pavel

Новичок
с addslashes - потом запарки с stripslashes
никаких запарок сейчас нет, в базу данные заносятся без слэшей, в том виде как они были получены, что мне и нужно чтобы не было искажений данных.
 

vasinsky

Новичок
давайте начнём с того - что работать будем в одной кодировке - а не в шести - как на стороне "сервера приложений", так и на стороне БД

в каком месте написано что addslashes() будет работать с кириллицей в юникоде не корректно?

другое дело строковые функции, для которых есть mb_ альтернатива

с addslashes - потом запарки с stripslashes
уф...

т.к. данные экранируются не средствами БД - то они и будут приняты БД в контексте. след-но при выводе - нужно будет рубить эти слэши

по крайней мере года 2 назад так и было. сейчас я уже давно не пересекался с этим моментом
 

vasinsky

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

О'Rally ?

тоже без слеша запишеться?

вообще вот попытка прорыва addslashes http://www.securityscripts.ru/articles/PHP/addslashes_or_mysql_real_escape_string.html
 

D_Pavel

Новичок
mysqli_real_escape_string делает то же самое что и addslashes в моем примере. Не рассматриваю вымышленные невероятные экзотические варианты.
 

D_Pavel

Новичок

D_Pavel

Новичок
Короче, все ясно. Зря некоторые "умники" сомневались. Спасибо, мужики, что помогли прояснить ситуацию.
 

fixxxer

К.О.
Партнер клуба
давайте начнём с того - что работать будем в одной кодировке - а не в шести - как на стороне "сервера приложений", так и на стороне БД

в каком месте написано что addslashes() будет работать с кириллицей в юникоде не корректно?

другое дело строковые функции, для которых есть mb_ альтернатива


уф...

т.к. данные экранируются не средствами БД - то они и будут приняты БД в контексте. след-но при выводе - нужно будет рубить эти слэши

по крайней мере года 2 назад так и было. сейчас я уже давно не пересекался с этим моментом
В финском языке есть такое слово Myötähäpeä, которое можно грубо перевести на английский как shared shame. Означает ситуацию, когда тебе почему-то стыдно за то, что сделал или сказал кто-то другой.
 

vasinsky

Новичок
ты не согласен? любишь кашку из кодирововок?

я думаю знание финского языка - тут некому оценить , скорее всего.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
я думаю знание финского языка - тут некому оценить , скорее всего.
Я думаю тут есть кому оценить знание английского, в контексте описания эффекта Даннинга-Крюгера.

Товарищ знаток PHP / MySQL / MSSQL / JS / AJAX / HTML / CSS / Photoshop / Flash, не шёл бы ты отвечать на форум по фотошопу?
 

vasinsky

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

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
о как мы пошли. завуалированно оскорблять))) ну я то не буду до твоего уровня себя опускать, шагай с миром по миру.
Ты ещё не на форуме по фотошопу, ыксперд? Предлагаю сразу завести там тему "почему настоящие поцаны не пользуются слоями".
 

Absinthe

жожо
ты не согласен?
У тебя полностью отсутсвуют знания по работе с базой и ты не понимаешь, как ини работают ("т.к. данные экранируются не средствами БД - то они и будут приняты БД в контексте. след-но при выводе - нужно будет рубить эти слэши, по крайней мере года 2 назад так и было"), при этом пытаешься спорить. Кончай так делать.
 
Сверху