Есть ли какая-либо причина для дезинфекции ввода пользователя, чтобы он не мог самостоятельно выполнять межсайтовый скриптинг? - PullRequest
7 голосов
/ 04 марта 2010

Если у меня есть поля, которые будут отображаться только тому пользователю, который их вводит, есть ли какая-либо причина для их очистки от межсайтового скриптинга?

Редактировать: Таким образом, консенсус ясен, что его следует дезинфицировать. Я пытаюсь понять, почему? Если единственный пользователь, который когда-либо может просматривать сценарий, который они вставляют на сайт, это сам пользователь, то единственное, что он может сделать, - это выполнить сам сценарий, что он мог бы сделать без участия моего сайта. Какой здесь вектор угрозы?

Ответы [ 5 ]

4 голосов
/ 13 ноября 2012

Теоретически: нет. Если вы уверены, что только они когда-либо увидят эту страницу, то пусть они пишут все, что захотят.

Проблема в том, что есть много способов, которыми они могут заставить других людей просматривать эту страницу, способами, которые вы не контролируете. Они могут даже открыть страницу на компьютере коллеги и попросить их посмотреть. Это, несомненно, дополнительный вектор атаки.

Пример: пастинка без постоянного хранения; Вы публикуете, вы получаете результат, вот и все. Можно вставить сценарий, который незаметно добавляет кнопку «пожертвовать» для ссылки на ваш счет PayPal. Положите его на компьютер достаточного количества людей, надеюсь, кто-то пожертвует, ...

Я согласен, что это не самый шокирующий и реалистичный пример. Однако, как только вам придется отстаивать решение, связанное с безопасностью, с помощью «это возможно, но оно не звучит слишком плохо», вы знаете, что перешли определенную черту.

В противном случае я не согласен с ответами типа «никогда не доверяйте вводу пользователя». Это утверждение не имеет смысла без контекста. Дело в том, как определить пользовательский ввод, который был весь вопрос. Доверяй как семантически? Синтаксически? До какого уровня; просто размер? Правильный HTML? Подмножество символов Юникода? Ответ зависит от ситуации. Чистый веб-сервер «не доверяет пользовательскому вводу», но сегодня многие сайты взламываются, потому что границы «пользовательского ввода» зависят от вашей перспективы.

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

Это исключает почти все JS и HTML с самого начала.

П.С .: По моему мнению, ОП заслуживает похвалы за то, что задала этот вопрос в первую очередь. «Не доверяйте своим пользователям» не является золотым правилом разработки программного обеспечения. Это плохое эмпирическое правило, потому что оно слишком разрушительно; это умаляет тонкости в определении границы приемлемого взаимодействия между вашим продуктом и внешним миром. Звучит как конец мозгового штурма, а он должен начинаться.

По своей сути, разработка программного обеспечения заключается в создании четкого интерфейса с вашим приложением. Все в этом интерфейсе - это Реализация, все, что за его пределами - это Безопасность. Заставить программу делать то, что вы хотите, настолько занята тем, что человек легко забывает о том, чтобы заставить ее больше ничего не делать.

Изобразите приложение, которое вы пытаетесь создать, в виде красивой картинки или фотографии. С помощью программного обеспечения вы пытаетесь приблизить это изображение. Вы используете спецификацию в качестве эскиза, так что уже здесь, чем более неряшлива ваша спецификация, тем более размыт ваш эскиз. Тем не менее, план вашего идеального приложения очень тонкий! Вы пытаетесь воссоздать это изображение с кодом. Тщательно вы заполняете контур вашего эскиза. По сути, это легко. Используйте широкие кисти: размытый эскиз или нет, эта часть явно нуждается в окраске. По краям это становится более тонким. Это когда вы понимаете, что ваш эскиз не идеален. Если вы зайдете слишком далеко, ваша программа начнет делать то, чего вы не хотите, и некоторые из них могут быть очень плохими.

Когда вы видите размытую линию, вы можете сделать две вещи: присмотреться к своему идеальному изображению и попытаться уточнить эскиз или просто прекратить окрашивание. Если вы сделаете последнее, скорее всего, вы не зайдете слишком далеко. Но вы также в лучшем случае дадите лишь приблизительное представление о своей идеальной программе. И вы все равно можете случайно пересечь черту! Просто потому, что вы не уверены, где это.

У меня есть благословение, когда я посмотрел поближе на эту размытую линию и попытался ее переопределить. Чем ближе вы подходите к краю, тем больше вы уверены, где он находится, и тем меньше вероятность, что вы пересечете его.

В любом случае, на мой взгляд, этот вопрос был не вопросом безопасности, а вопросом дизайна: каковы границы вашего приложения и как ваша реализация отражает их?

Если ответом «никогда не доверять пользовательскому вводу», ваш эскиз размыт.

(и если вы не согласны: что, если OP работает для "testxsshere.com"? Boom! Check-mate.)

(кто-то должен зарегистрировать testxsshere.com)

1 голос
/ 21 апреля 2013

Я не верю, что на этот вопрос был дан полный ответ. Он хочет увидеть внезапную XSS-атаку, если пользователь может атаковать только сам. Это фактически сделано комбинацией CSRF и XSS.

С помощью CSRF вы можете сделать так, чтобы пользователь сделал запрос с вашей полезной нагрузкой. Поэтому, если пользователь может атаковать себя с помощью XSS, вы можете заставить его атаковать самого себя (заставить его сделать запрос с вашим XSS).

Цитата из Веб-приложение Справочник хакера :

ОБЩИЙ МИФ:

«Мы не беспокоимся об этой ошибке XSS с низким уровнем риска. Пользователь может использовать его только для атаки на себя ».

Даже очевидно уязвимые места с низким уровнем риска могут при правильных обстоятельствах проложить путь к разрушительной атаке. Использование глубоко защищенного подхода к безопасности влечет за собой устранение всех известных уязвимостей, какими бы незначительными они ни казались. Авторы даже использовали XSS для размещения диалоговых окон файлового браузера или элементов управления ActiveX в ответе страницы, помогая выйти из системы режима киоска, связанной с целевым веб-приложением. Всегда предполагайте, что злоумышленник будет изобретательнее, чем вы, изобретая способы использовать незначительные ошибки!

1 голос
/ 04 марта 2010

То, что вы не показываете кому-либо поле, не означает, что потенциальная Черная Шляпа не знает, что они там.Если у вас есть потенциальный вектор атаки в вашей системе, закройте дыру.Будет очень сложно объяснить вашему работодателю, почему вы этого не сделали, если его когда-либо эксплуатировали.

0 голосов
/ 04 марта 2010

Если сценарий или служба, которой форма отправляет значения, доступна через Интернет, тогда любой может написать сценарий, который отправит ей значения. Итак: да , очистить все полученные входные данные.

Самая простая модель веб-безопасности довольно проста:

Не доверяйте своим пользователям

Также стоит сослаться на мой ответ в другом посте ( Шаги, чтобы разбираться в веб-безопасности ): Шаги, чтобы разбираться в веб-безопасности .

Не могу поверить, что ответил без обращения к заглавному вопросу:

Есть ли какая-либо причина для дезинфекции ввода пользователя, чтобы он не мог самостоятельно выполнять межсайтовый скриптинг?

Вы не предотвращаете межсайтовый скриптинг пользователя , вы защищаете свой сайт (или, что более важно, вы клиент ), будучи жертвой межсайтового скриптинга. Если вы не закроете известные дыры в безопасности, потому что вас это не беспокоит, вам будет очень трудно получить повторный бизнес. Или хорошая реклама из уст в уста и рекомендации от предыдущих клиентов.

Думайте об этом меньше как о защите своего клиента, думайте об этом - если это помогает - как о защите вашего бизнеса .

0 голосов
/ 04 марта 2010

Да , всегда очищать ввод пользователя:

  1. Никогда не доверяйте пользовательскому вводу
  2. Для этого не нужно много усилий.

Ключевой точкой является 1 .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...