Чем конкретно может грозить склейка строк в перловом скрипте из данных, полученных из пользовательской формы? Если можно, приведите пример пожалуйста, например, для такого кода:
my $url = CGI::param( 'url' );
$url = 'http://'.$url;
Здравствуйте, <Аноним>, Вы писали:
А>Чем конкретно может грозить склейка строк в перловом скрипте из данных, полученных из пользовательской формы? Если можно, приведите пример пожалуйста, например, для такого кода:
А>
Сама по себе ничем. Все зависит от того, как будет дальше использоваться $url/
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[2]: Чем грозит склейка данных?
От:
Аноним
Дата:
21.10.09 10:20
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, <Аноним>, Вы писали:
А>>Чем конкретно может грозить склейка строк в перловом скрипте из данных, полученных из пользовательской формы? Если можно, приведите пример пожалуйста, например, для такого кода:
А>>
Здравствуйте, <Аноним>, Вы писали:
А>Дальше $url будет заэскейплен/заквочен и добавлен в базу данных.
Тогда уязвимость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, <Аноним>, Вы писали:
А>>Дальше $url будет заэскейплен/заквочен и добавлен в базу данных. S>Тогда уязвимость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.
Вообще есть 2 стратегии защиты от кривых данных пользователя:
1) Пытаться вырезать (заквотить) все "опасные" символы.
2) Пытаться все-таки понять, что ожидается от пользователя и прикрутить строгие валидаторы.
Почему второй способ правильнее? Да очень просто — при вставке в БД символы \r\n будут вполне себе невинными, а когда этот URL будет извлечен из БД и попадет, например, в HHTP response — то эти символы позволят провести атаку под названием HTTP Response splitting.
Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).
Здравствуйте, DOOM, Вы писали:
ость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.
DOO>Вообще есть 2 стратегии защиты от кривых данных пользователя: DOO>1) Пытаться вырезать (заквотить) все "опасные" символы. DOO>2) Пытаться все-таки понять, что ожидается от пользователя и прикрутить строгие валидаторы.
DOO>Да очень просто — при вставке в БД символы \r\n будут вполне себе невинными
А также, например, символы %0d+%0a ...
DOO>Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).
Есть еще:
а) продолжение второй стратегии: понять что ожидается отдавать пользователю и прикрутить такие же строгие валидаторы на выходе, как и на входе.
б) третья стратегия (параноидальное развитие идей второй): реализовать в приложении строгую типизацию параметров всех точек входа (т.е. нарисовать на собственном DSL или в конфиге или чистом XML и т.п., контракты всех точек входа в веб-приложение и тестировать данные, получаемые в запросах, на предмет соответствия их типов, декларированных для данной конкретной точки входа, бросая исключение несоответствия типов, если нам пытаются подсунуть что-то другое). Вкупе со строгой валидацией форматов параметров (в т.ч. соответствия, скажем строк, конкретным регуляркам, диапазонов числовых типов и т.п. и тестированием строк на НЕсоответствие конкретным регуляркам, типа этих) это дает лучший эффект. Главное, результаты проверок типов и форматов где-нибудь кэшировать, а то DOS будет обеспечен.
Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.
Встраиваемые I[P|D]S с типизированным HTTP, короче.
Здравствуйте, kochetkov.vladimir, Вы писали:
DOO>>Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).
KV>Есть еще: KV>а) продолжение второй стратегии: понять что ожидается отдавать пользователю и прикрутить такие же строгие валидаторы на выходе, как и на входе.
А это вопрос. Если ты доверяешь своей проверке на входе и самостоятельно генерируемым данным, то проверка на выходе нужна только, если ты не до конца себе доверяешь
Понятно, что в реальной жизни при наличии ошибок реализации это будет полезно, но есть же еще один момент: все проверки должны осуществляться одним модулем, который вызывается при необходимости во всех участках кода (собственно, как это PHP IDS предлагает делать), так что пропущенный косячек на входе в большой вероятностью будет пропущен и на выходе...
KV>б) третья стратегия (параноидальное развитие идей второй): реализовать в приложении строгую типизацию параметров всех точек входа (т.е. нарисовать на собственном DSL или в конфиге или чистом XML и т.п., контракты всех точек входа в веб-приложение и тестировать данные, получаемые в запросах, на предмет соответствия их типов, декларированных для данной конкретной точки входа, бросая исключение несоответствия типов, если нам пытаются подсунуть что-то другое). Вкупе со строгой валидацией форматов параметров (в т.ч. соответствия, скажем строк, конкретным регуляркам, диапазонов числовых типов и т.п. и тестированием строк на НЕсоответствие конкретным регуляркам, типа этих) это дает лучший эффект. Главное, результаты проверок типов и форматов где-нибудь кэшировать, а то DOS будет обеспечен.
Прям-таки кое-то напомнило:
, а целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации;
В общем-то ты это требование и изложил с учетом специфики web приложений
KV>Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.
Схожую стратегию реализуют и навесные системы, типа mod_security — в том числе и на продуктивных приложениях
DOO> k>> НЕсоответствие конкретным регуляркам, типа этих)
DOO> M>Вау. Срочно в копилку.
DOO> Невнимательно ты форумы, Мамут, читаешь. PHP-IDS Владимир рекламировал уже с полгода назад
DOO>А это вопрос. Если ты доверяешь своей проверке на входе и самостоятельно генерируемым данным, то проверка на выходе нужна только, если ты не до конца себе доверяешь DOO>Понятно, что в реальной жизни при наличии ошибок реализации это будет полезно, но есть же еще один момент: все проверки должны осуществляться одним модулем, который вызывается при необходимости во всех участках кода (собственно, как это PHP IDS предлагает делать), так что пропущенный косячек на входе в большой вероятностью будет пропущен и на выходе...
Я имел ввиду, что на входе мы организуем валидацию данных, полученных от пользователя в разрезе бизнес-логики нашего приложения (т.е. если ожидаем e-mail, то это должен быть e-mail, если ожидаем номер телефона, это должен быть номер телефона и т.п.). На выходе же мы проверяем данные в несколько ином разрезе — если это url для редиректа, то в нем должны быть символы, валидные для url'а, если текст какого-либо сообщения, то в нем не должно быть скриптов и т.п.
Это дает возможность в какой-то степени закрыть глаза на то, что происходит с данными, проверенными на входе, внутри нашего приложения.
DOO>Прям-таки кое-то напомнило: DOO>
DOO>, а целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации;
DOO>В общем-то ты это требование и изложил с учетом специфики web приложений
Особой связи, если честно, не уловил
KV>>Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили. DOO>Схожую стратегию реализуют и навесные системы, типа mod_security — в том числе и на продуктивных приложениях
Да, стратегия аналогична, разница лишь в том, что навесные системы дают большую производительность (т.к. реализованы, как правило, в виде модулей к веб-серверу), а встраиваемые — позволяют тесно интегрироваться с логикой приложения и реализовывать, например, корреляцию событий безопасности (что особенно актуально для веб-приложений, т.к. один запрос, который матчится с сигнатурой XSS, еше не говорит о том, что нас хотят атаковать).
) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.
