Аннотация:
Очень часто при анализе сторонних скриптов обнаруживается одна и та же распространенная ошибка: отсутствие проверки передаваемых данных в «неизменяемых» полях, таких как <input type=”hidden”>, <input type=”radio”>, <input type=”checkbox”> и, конечно же, <select></select>.
Почему-то начинающие и более опытные программисты, считают, что «неизменяемые» явно поля – никак нельзя отредактировать. Поверьте, это далеко не так!
L>Авторы: L> Landgraph
L>Аннотация: L>Очень часто при анализе сторонних скриптов обнаруживается одна и та же распространенная ошибка: отсутствие проверки передаваемых данных в «неизменяемых» полях, таких как <input type=”hidden”>, <input type=”radio”>, <input type=”checkbox”> и, конечно же, <select></select>. L>Почему-то начинающие и более опытные программисты, считают, что «неизменяемые» явно поля – никак нельзя отредактировать. Поверьте, это далеко не так!
Вообще тема интересная и требующая большего раскрытия. Безопасность Web-приложений очень актуальная тема в настоящее время, а подмена параметров пользователей является самым распространенным путем внедрения зловредного кода на сервер. Причем параметры пользователя это не только тело запроса — есть еще Cookie и заголовки HTTP. Причем чаще всего программисты забывают именно про заголовки HTTP.
Например, система борьбы с накрутками в голосованиях — временно запоминает информацию о пользователе (в базу данных), в том числе его браузер (заголовок User-Agent), при этом никто не фильтрует строку — проблема, думаю, понятна.
Еще достаточно важная тема это фильтрация vs экранирование. Например, многие PHP разработчики полюбили опцию magic_quotes_gpc (кстати, она уже deprecated) и считают, что это защитит их от всех проблем (например, при вставке в таблицу строковых значений у злоумышленника не будет возможности завершить строку раньше времени). Однако это не всегда помогает, особенно, если это единственный способ экранирования данных при вызове команды оболочки. Опять простой пример: допустим вызывается команда оболочки echo "$_POST['data']" и при этом активна опция magic_quotes — казалось бы строку не закрыть? А зачем ее закрывать? magic_quotes не экранирует бэк тики (`), поэтому достаточно передать `rm -rf /var/www` в качестве data.
Ну и так далее. Я бы всем web разработчикам настоятельно рекомендовал ознакомление с моделью SDL (Security development lifecycle) от MS, моделями STRIDE и DREAD и т.п. Ну и очень полезные материалы можно найти на сайтах www.webappsec.org и www.owasp.org.
P.S. приведенные примеры ошибок в этом сообщение мною встречались в реальной жизни, так что это не просто пространные рассуждения.
Вот пример из жизни. Мне нужно было скачать одну песню. Сайт, на котором она лежала, целиком и полностью платный. Но проблема была не в деньгах, а в их количестве, которое запрашивал сайт. Песня стоит 10 центов, а минимальная сумма пополнения счета, которую мне предлагала внести система – 10 долларов! Конечно же, такую сумму вносить на счет из-за одной песни очень не хотелось. Описанным выше способом я поменял в одном из полей выбора 10 долларов на 1 доллар… И что вы думаете? Система спокойно выписала мне счет на 1 доллар, который я оплатил и скачал себе необходимую песню!
И этот человек пишет статью о безопасности?...
Re[2]: Скрытая угроза: «неизменяемые» поля Web-форм
Некоторые проверяют ещё поле referer, чтобы удостовериться, что пользователь не сохранил страницу на локальный диск и затем не отправил скрипту запрос с подправленными данными.
if ($_SERVER['HTTP_REFERER']!='http://www.landgraph.ru/script/test.html')
die('Выполнение скрипта запрещено!');
Я бы не полагался на HTTP_REFERER — т.к. это поле не всегда передаётся браузером клиента, да и подделать его не составляет труда. А упоминание этого метода в статье — может побудить когото его использовать.
И на мой взгляд стоило бы упомянуть о том, что для hidden полей — можно запоминать их контрольную сумму (а не проверять все значения) можно её хранить как на сервере (в сессии) так и на клиенте (опасно! — нужно добавлять "соль", чтобы не подделывали).
Re[3]: Скрытая угроза: «неизменяемые» поля Web-форм
Здравствуйте, Landgraph, Вы писали:
L>Здравствуйте, psg, Вы писали:
psg>>И этот человек пишет статью о безопасности?...
L>Мммм... А что в этом плохого? =)
Извините, но IMHO это поступок того же плана, что и "я стащил упаковку карандашей из офиса, потому что они на мне зарабатывают гораздо больше, чем она стоит"...
Re[4]: Скрытая угроза: «неизменяемые» поля Web-форм
Здравствуйте, psg, Вы писали:
psg>Здравствуйте, Landgraph, Вы писали:
L>>Здравствуйте, psg, Вы писали:
psg>>>И этот человек пишет статью о безопасности?...
L>>Мммм... А что в этом плохого? =)
psg>Извините, но IMHO это поступок того же плана, что и "я стащил упаковку карандашей из офиса, потому что они на мне зарабатывают гораздо больше, чем она стоит"...
Впрочем, я и сам не без греха – копирую content с fiction book и litportal, который только для чтения в browser... Так что извините, погорячился...
На главной странице rsdn.ru, если навести мышку на ссылку на данную статью — появится краткая превьюшка, в которой выводимый HTML не "эскейпится" (вместо тегов видны элементы форм).
Прикольно такое наблюдать, учитывая направленность статьи
Доведите кто-нибудь плиз до администраторов ресурса
Re[2]: Скрытая угроза: «неизменяемые» поля Web-форм
Здравствуйте, Othello, Вы писали:
O>И на мой взгляд стоило бы упомянуть о том, что для hidden полей — можно запоминать их контрольную сумму (а не проверять все значения) можно её хранить как на сервере (в сессии) так и на клиенте (опасно! — нужно добавлять "соль", чтобы не подделывали).
Контрольную сумму тоже можно подделать. Мы у себя делали так: генерировали вектор случайных строк и запоминали его на сервере, дополняли поля значениями из вектора, объединяли все дополненные значения в линейный массив символов, сжимали его и применяли криптоустойчивый хэш (обычно SHA-256). Впрочем, это тоже наверное можно назвать "контрольной суммой"
Здравствуйте, Landgraph, Вы писали:
L>Очень часто при анализе сторонних скриптов обнаруживается одна и та же распространенная ошибка: отсутствие проверки передаваемых данных в «неизменяемых» полях, таких как <input type=”hidden”>, <input type=”radio”>, <input type=”checkbox”> и, конечно же, <select></select>. L>Почему-то начинающие и более опытные программисты, считают, что «неизменяемые» явно поля – никак нельзя отредактировать. Поверьте, это далеко не так!
Мда. Особенно было забавно, когда я однажды увидел свой IP в одном их скрытых полей Надо же, сделать проверку IP и при этом этот IP записать на страницу!
Re[3]: Скрытая угроза: «неизменяемые» поля Web-форм
Можно просто хранить контрольную сумму в сессии — и пересчитывать её по полям что пришли в GET/POST- и тогда не подделать... и не нужно хранить сами поля.
