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 подобные уязвимости находили годами.

 

[fixxxer]

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

ЛОЛЧТО

 

[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]

а если такую строку в БД записать

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

 

[D_Pavel]

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

Этот тип атаки применим к любой кодировке, в которой есть многобайтовые символы, позволяющие обмануть работу addslashes(). В UTF-8 эта атака не пройдет.

 

[D_Pavel]

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

 

[fixxxer]

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

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

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


уф...

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

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

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

 

[vasinsky]

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

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

 

[Sad Spirit]

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

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

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

 

[vasinsky]

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

 

[Sad Spirit]

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

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

 

[Absinthe]

ты не согласен?

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

 

[vasinsky]

оо до)) знаний у меня ноль. у тебя вагон)) отсыпишь?

 

[vasinsky]

Sad Spirit, флудить любишь? не надо так.