Сейчас занят созданием пары классов которые должны обеспечивать более менее безопасность пользовательского ввода, как минимум от самых распространённых и известных XSS и SQL injection. Хотел бы попросить поделится опытом более опытных людей. Так как думаю что обычное экранирование обеспечивает лишь самый низкий уровень безопасности от наиболее прямого и тупого запроса. В частности есть пара вопросов. 1. Можно ли заменять все символы которые я считаю не безопасными на их HTML коды вида &#xxx; 2. Достаточно ли будет заменить "0x" на, например "Ox" (вместо нуля буква О) что бы защитится от SQL-hex вставок. 3. Имеет ли смысл взять список SQL команд например (select, drop, order by и тд и тп) и заменять их на что-то так же безопасное. 4. Как предотвратить обход проверки с помощью ANSI кодировки в запросе ? Достаточно ли будет что то делать с выражением вида "%хх", в частности с теми которые совпадают с запрещёнными символами, например менять их на HTML коды ? Вообще хотел бы узнать как именно можно обеспечить хорошую защиту пользовательского ввода, перерыл много чего, но все везде сводится к описанию атак и словам что пользовательский ввод надо фильтровать, но как именно нигде никто особо не пишет. Таким образом хотелось бы обсудить конкретные приемы фильтрации ввода.
конечно можно. надо всё менять не глядя. а то вдруг чо. Да, это решение всех вопросов - совать в базу не то, что прислали. Можно пойти ещё дальше и заменять весь присланный пользовательский ввод на "Ох" или даже на "Ох, блин". Да, конечно. Нормальные люди ведь не используют эти слова в повседневной речи. Ну не знаю. Наверное... ВЫСТАВИТЬ КОДИРОВКУ????
По поводу пункта 4. Если я все понимаю верно то разумеется, есть кодировка страницы и в этой кодировке браузер отдает серверу данные, но я встречал не однократно описание атак где параметры меняли в ANSI, в частности кавычки и прочие и скармливали серверу, в итоге это обходило ряд проверок, может конечно это работало на каких-то старых версиях PHP а может я чего то не понял, посему и спрашиваю
А вообще является ли HTML код вида &#xxx; безопасным ? Ничто его не пытается интерпретировать как символ, за исключением браузера при отображении ? Просто сейчас провел эксперимент, заменил все кавычки на ' , после чего попросил функцию mysql_real_escape_string() отработать строчку с данными кодами, она успешно про экранировала последовательность ' Почему так получается ? ... кодировка соединения стоит UTF8
безопасным для чего? от чего? дык кто ж его знает что там и где чего интерпретирует. зависит от задачи. шут её знает
всегда думай о цели. для для запросов MySQL опасна только одинарная кавычка — обезопась себя или плесхолдерами или подходящим *escape_string. не надо усложнять.
Ну да, следуя ссылке которую дал igordata я как раз и "закопался" сейчас в функционал mysqli, ранее пользовался обычным mysql и не знал что есть такие средства(да еще и имеет ООП функционал, ваще прелесть). Отсюда и попытка "изобрести велосипед", хотя такие попытки даром не проходят, узнаешь много нового Если кому из начинающих интересна тема mysqli то вот нарыл хорошую ссылочку, все доходчиво и на русском : http://www.bvisoft.com/reads/263.php Думаю в сочетании с минимальными разумными проверками, подготовленные sql запросы и sql процедуры, вполне будут способствовать защите от большинства SQL атак.
Думаю это не более чем ошибка времени на сайте Так же, мои поиски защиты от SQL-i привели меня к такой статье на тему экранирования. Так же весьма хорошо написана, будет интересна тем кто копает информацию в данном направлении как я. http://phpfaq.ru/slashes В процессе разбирательств с подготовленными запросами и экранированием, так же получил важный ответ на тему надо или нет экранировать кавычки при составление параметизированных подготовленых запросов. Овтет нашел в документации:
В Yii при выполнении запроса передаю параметры, которые в PDO вызываются через http://www.php.ru/manual/pdostatement.bindparam.html Никаких проблем с sql inj нету. Есть также возможность поставить на apache mod_security, защитит от SQL inj и XSS, но это на крайний случай. p.s руки у разработчиков должны из правильного места быть.
Подготовленные выражения гораздо медленнее простых sql команд).. И их использование правильное не там где надо экранировать переменные для этого quote
http://www.php.ru/manual/pdo.prepare.html#108481 Пишет о 3кратном.. Я почему то доверяю. До этого тоже везде пихнул подготовленные выражения уже не с целью многократного использования, а просто чтоб удобнее кинул массив он сам там проэкрнируется).. А щас так не пользую оно конечно не заметно по скорости, но хочется все же стремитьс к грамотному коду)... Зачем собственная реализация какая-то особая.. Просто создать функцию принимающую параметры и будет норм.. Главная ведь цель и тогда и дает выигрыш многократное использование
artem-Kuzmin, кажется местный парсер опять неудачно подменил ссылку на собственный недомануал. тысяча чертей!
кстати, о (не)эффективности биндинга параметров: плейсхолдеры бывают серверные и клиентские, в PDO по умолчанию клиентские (пруф, глава "Работа с плейсхолдерами"). если вся обработка параметра происходит на клиенте, то от prepare не стоит ждать ускорения! нестандартный подход к prepare, постоянное соединение и любопытные тесты http://habrahabr.ru/post/149613/
каммент какогото неизвестного - я лично не беру в расчет. а если я там щас напишу наоборот - о 3-х кратном превосходстве. вы тоже поверите? )
прочел всю статью)).. человек который пишет, слишком многословен и сам походу не понимает о чем пишет)), хотя почитать не помешало.. Пишет о том, что экранирование гадость. Надо пользовать только плейсхолдеры.. А плейсхолдеры действительно только серверные же бывают, а клиентские та же самая херь, что экранирование), просто делается через функцию... А он так это описывает будто это чем то отличается от обычного экранирования.. Читая комменты к pdo много видел как умные люди просто extends PDO и расширяли как ему надо).. А тут он начал ковырять какие то свои quote функии в которых не вижу смысла проще наслоедовать и допилить.. Добавлено спустя 9 минут 32 секунды: ПРочитал и 2).. Использовать подготовленные выражения думаю вполне подходит для скриптов больших данных.. Хотя там лучше LOAD DATA Там оч много хороших комментариев поэтому это как минимум стоит задуматься). но не написали же)
я прекрасно понимаю, что дополнительные действия(prepare,bind...) - требуют доп. ресурсов (память, процессор..). без этого никуда. также я имею некоторый опыт работы с pdo. и никогда не сталкивался с проблемами вызванными тормознутостью подготовленных выражений. для моих нужд производительности хватает. когда работал в студии - тоже проблем с этим не испытывал никто из знакомых. гнаться за наносекундами - я уже давно бросил. оптимизировать нужно самые тормозные места. а это обычно сами запросы, правильные индексы, денормализация и т.д. т.е. я не отрицаю что они более ресурсоемки. но все в допустимых пределах и реальных проблем это никогда не доставляло.
Та я вижу проблему в другом) даже не в тормознутости маленькой а просто в использовании не по назначению)