Чем грозит склейка данных?
От: Аноним  
Дата: 21.10.09 10:10
Оценка:
Чем конкретно может грозить склейка строк в перловом скрипте из данных, полученных из пользовательской формы? Если можно, приведите пример пожалуйста, например, для такого кода:

my $url = CGI::param( 'url' );
$url = 'http://'.$url;
Re: Чем грозит склейка данных?
От: Ziaw Россия  
Дата: 21.10.09 10:17
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Чем конкретно может грозить склейка строк в перловом скрипте из данных, полученных из пользовательской формы? Если можно, приведите пример пожалуйста, например, для такого кода:


А>
А>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>Здравствуйте, <Аноним>, Вы писали:


А>>Чем конкретно может грозить склейка строк в перловом скрипте из данных, полученных из пользовательской формы? Если можно, приведите пример пожалуйста, например, для такого кода:


А>>
А>>my $url = CGI::param( 'url' );
А>>$url = 'http://'.$url;
А>>


Z>Сама по себе ничем. Все зависит от того, как будет дальше использоваться $url/


Дальше $url будет заэскейплен/заквочен и добавлен в базу данных.
Re[3]: Чем грозит склейка данных?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 21.10.09 10:47
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Дальше $url будет заэскейплен/заквочен и добавлен в базу данных.

Тогда уязвимость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: Чем грозит склейка данных?
От: DOOM Россия  
Дата: 21.10.09 11:01
Оценка: 60 (1)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:


А>>Дальше $url будет заэскейплен/заквочен и добавлен в базу данных.

S>Тогда уязвимость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.

Вообще есть 2 стратегии защиты от кривых данных пользователя:
1) Пытаться вырезать (заквотить) все "опасные" символы.
2) Пытаться все-таки понять, что ожидается от пользователя и прикрутить строгие валидаторы.

Почему второй способ правильнее? Да очень просто — при вставке в БД символы \r\n будут вполне себе невинными, а когда этот URL будет извлечен из БД и попадет, например, в HHTP response — то эти символы позволят провести атаку под названием HTTP Response splitting.

Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).
Re[5]: Чем грозит склейка данных?
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.10.09 13:52
Оценка: 77 (3)
Здравствуйте, DOOM, Вы писали:
ость возникает в момент ескейпленья/квочения. Если сделать его неаккуратно, то можно получить всё, что угодно.

DOO>Вообще есть 2 стратегии защиты от кривых данных пользователя:

DOO>1) Пытаться вырезать (заквотить) все "опасные" символы.
DOO>2) Пытаться все-таки понять, что ожидается от пользователя и прикрутить строгие валидаторы.

DOO>Да очень просто — при вставке в БД символы \r\n будут вполне себе невинными


А также, например, символы %0d+%0a ...

DOO>Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).


Есть еще:

а) продолжение второй стратегии: понять что ожидается отдавать пользователю и прикрутить такие же строгие валидаторы на выходе, как и на входе.

б) третья стратегия (параноидальное развитие идей второй): реализовать в приложении строгую типизацию параметров всех точек входа (т.е. нарисовать на собственном DSL или в конфиге или чистом XML и т.п., контракты всех точек входа в веб-приложение и тестировать данные, получаемые в запросах, на предмет соответствия их типов, декларированных для данной конкретной точки входа, бросая исключение несоответствия типов, если нам пытаются подсунуть что-то другое). Вкупе со строгой валидацией форматов параметров (в т.ч. соответствия, скажем строк, конкретным регуляркам, диапазонов числовых типов и т.п. и тестированием строк на НЕсоответствие конкретным регуляркам, типа этих) это дает лучший эффект. Главное, результаты проверок типов и форматов где-нибудь кэшировать, а то DOS будет обеспечен.

Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[6]: Чем грозит склейка данных?
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.10.09 13:56
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.


Встраиваемые I[P|D]S с типизированным HTTP, короче.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[6]: Чем грозит склейка данных?
От: Mamut Швеция http://dmitriid.com
Дата: 21.10.09 14:55
Оценка:
k> НЕсоответствие конкретным регуляркам, типа этих)

Вау. Срочно в копилку.
avalon 1.0rc3 rev 304, zlib 1.2.3 (13.10.2009 10:16:48 EEST :z)(Qt 4.5.3)


dmitriid.comGitHubLinkedIn
Re[7]: Чем грозит склейка данных?
От: DOOM Россия  
Дата: 22.10.09 04:02
Оценка:
Здравствуйте, Mamut, Вы писали:

k>> НЕсоответствие конкретным регуляркам, типа этих)


M>Вау. Срочно в копилку.


Невнимательно ты форумы, Мамут, читаешь. PHP-IDS Владимир рекламировал уже с полгода назад
Re[6]: Чем грозит склейка данных?
От: DOOM Россия  
Дата: 22.10.09 04:08
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

DOO>>Вывод: данные единожды полученные от пользователя могут использоваться в заранее непредсказуемом количестве мест, соответственно, единовременная очистка от опасных символов ничего не гарантирует и в коде придется проводить такую очистку каждый раз для всех данных, которые хотя бы потенциально содержат полученные от пользователя значения. Понятно, что это нереально — поэтому лучше использовать вариант 1 — строгие валидаторы (естественно, на стороне сервера — но лучше и там, и там, чтобы пользователи не материли).


KV>Есть еще:

KV>а) продолжение второй стратегии: понять что ожидается отдавать пользователю и прикрутить такие же строгие валидаторы на выходе, как и на входе.
А это вопрос. Если ты доверяешь своей проверке на входе и самостоятельно генерируемым данным, то проверка на выходе нужна только, если ты не до конца себе доверяешь
Понятно, что в реальной жизни при наличии ошибок реализации это будет полезно, но есть же еще один момент: все проверки должны осуществляться одним модулем, который вызывается при необходимости во всех участках кода (собственно, как это PHP IDS предлагает делать), так что пропущенный косячек на входе в большой вероятностью будет пропущен и на выходе...


KV>б) третья стратегия (параноидальное развитие идей второй): реализовать в приложении строгую типизацию параметров всех точек входа (т.е. нарисовать на собственном DSL или в конфиге или чистом XML и т.п., контракты всех точек входа в веб-приложение и тестировать данные, получаемые в запросах, на предмет соответствия их типов, декларированных для данной конкретной точки входа, бросая исключение несоответствия типов, если нам пытаются подсунуть что-то другое). Вкупе со строгой валидацией форматов параметров (в т.ч. соответствия, скажем строк, конкретным регуляркам, диапазонов числовых типов и т.п. и тестированием строк на НЕсоответствие конкретным регуляркам, типа этих) это дает лучший эффект. Главное, результаты проверок типов и форматов где-нибудь кэшировать, а то DOS будет обеспечен.

Прям-таки кое-то напомнило:

, а целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации;

В общем-то ты это требование и изложил с учетом специфики web приложений

KV>Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.

Схожую стратегию реализуют и навесные системы, типа mod_security — в том числе и на продуктивных приложениях
Re[8]: Чем грозит склейка данных?
От: Mamut Швеция http://dmitriid.com
Дата: 22.10.09 07:56
Оценка:
DOO> k>> НЕсоответствие конкретным регуляркам, типа этих)

DOO> M>Вау. Срочно в копилку.


DOO> Невнимательно ты форумы, Мамут, читаешь. PHP-IDS Владимир рекламировал уже с полгода назад


Позор на мои седины
avalon 1.0rc3 rev 304, zlib 1.2.3 (13.10.2009 10:16:48 EEST :z)(Qt 4.5.3)


dmitriid.comGitHubLinkedIn
Re[7]: Чем грозит склейка данных?
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 22.10.09 15:28
Оценка: 19 (1)
Здравствуйте, DOOM, Вы писали:


DOO>А это вопрос. Если ты доверяешь своей проверке на входе и самостоятельно генерируемым данным, то проверка на выходе нужна только, если ты не до конца себе доверяешь

DOO>Понятно, что в реальной жизни при наличии ошибок реализации это будет полезно, но есть же еще один момент: все проверки должны осуществляться одним модулем, который вызывается при необходимости во всех участках кода (собственно, как это PHP IDS предлагает делать), так что пропущенный косячек на входе в большой вероятностью будет пропущен и на выходе...

Я имел ввиду, что на входе мы организуем валидацию данных, полученных от пользователя в разрезе бизнес-логики нашего приложения (т.е. если ожидаем e-mail, то это должен быть e-mail, если ожидаем номер телефона, это должен быть номер телефона и т.п.). На выходе же мы проверяем данные в несколько ином разрезе — если это url для редиректа, то в нем должны быть символы, валидные для url'а, если текст какого-либо сообщения, то в нем не должно быть скриптов и т.п.

Это дает возможность в какой-то степени закрыть глаза на то, что происходит с данными, проверенными на входе, внутри нашего приложения.

DOO>Прям-таки кое-то напомнило:

DOO>

DOO>, а целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации;

DOO>В общем-то ты это требование и изложил с учетом специфики web приложений

Особой связи, если честно, не уловил

KV>>Третью стратегию видел (точнее участвовал в реализации ) уже на двух продуктивных приложениях, причем одно из них позиционируется как high-load. Всей группой тестили — замечаний так и не выкатили.

DOO>Схожую стратегию реализуют и навесные системы, типа mod_security — в том числе и на продуктивных приложениях

Да, стратегия аналогична, разница лишь в том, что навесные системы дают большую производительность (т.к. реализованы, как правило, в виде модулей к веб-серверу), а встраиваемые — позволяют тесно интегрироваться с логикой приложения и реализовывать, например, корреляцию событий безопасности (что особенно актуально для веб-приложений, т.к. один запрос, который матчится с сигнатурой XSS, еше не говорит о том, что нас хотят атаковать).

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.