Вопрос по url, xss, security, html-sanitizing – Лучший способ обеспечить безопасность и избежать XSS с помощью введенных пользователем URL

48

У нас есть приложение с высоким уровнем безопасности, и мы хотим, чтобы пользователи могли вводить URL-адреса, которые будут видеть другие пользователи.

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

Каковы лучшие методы борьбы с этим? Достаточно ли хорош один белый список безопасности или шаблон побега?

Любые советы по работе с перенаправлениями (например, сообщение «эта ссылка выходит за пределы нашего сайта» на странице предупреждения перед переходом по ссылке)

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

Разъяснение:

В основном наши пользователи хотят ввести:

stackoverflow.com

И сделайте вывод другому пользователю:

<a href="http://stackoverflow.com">stackoverflow.com</a>

Что меня действительно беспокоит, так это то, что они используют это во взломе XSS. То есть они вводят:

предупреждение ( 'взломан!');

Таким образом, другие пользователи получают эту ссылку:

<a href="alert('hacked!');">stackoverflow.com</a>

Мой пример - просто объяснить риск - я хорошо знаю, что javascript и URL-адреса - это разные вещи, но, позволяя им вводить последние, они могут выполнять первые.

Вы будете удивлены, сколько сайтов вы можете сломать с помощью этого трюка - HTML еще хуже. Если они знают, что делать со ссылками, они также знают, что нужно дезинфицировать<iframe>, <img> и умные ссылки CSS?

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

Вы можете поддержать это, обновив это. Мой ответ очень актуален. Nick Stinemates
Мне нужно второй комментарий @ Ника - Javascript не является синонимом URL. Вы уверены, что это не вопрос очистки пользователя и предотвращения выполнения введенных данных, если это действительно код? warren
Я действительно знаю этот javascript! = Url. Но в большинстве мест, где вы можете получить URL, вы можете втиснуть встроенный JavaScript. Keith

Ваш Ответ

9   ответов
-1

чтобы преобразовать весь URL и отправить его на ваш сервер. Таким образом, клиент не будет понимать содержание на первый взгляд. После прочтения контента, вы можете декодировать контент URL =? и отправьте его в браузер.

Я не понимаю, почему это могло бы помочь, нет проблем с выполнением кода на сервере. Проблема в том, что кодвыглядит как ссылка на сервер, но выполняет вредоносный XSS, когда пользователь нажимает на него. Мой вопрос заключается в том, может ли (учитывая огромное разнообразие возможных перестановок атак) быть достаточно строгой проверкой, чтобы быть уверенным, что контент XSS не может пройти. Keith
Что я понял из моего понимания, так это то, что всегда есть способ преодолеть фильтрацию XSS. Shashi
Ничто не является на 100% безопасным, но нашим клиентам нужна высокая безопасность и пользовательские ссылки, и я хочу знать, как это сделать наилучшим образом. Keith
3

когда вы выводите их. Убедитесь, что вы не позволяетеjavascript: ссылки. (Лучше всего иметь белый список принятых протоколов, например, http, https и mailto.)

Белый список необходим, потому что IE допускает символы табуляции в протоколе, то есть java и x09script: работает в IE и пропускает черные списки. Kornel
1

чтобы не отображать их в виде ссылки? Просто используйте текст.

В сочетании с предупреждением действовать на свой страх и риск может быть достаточно.

прибавление - смотрите такжеСтоит ли дезинфицировать разметку HTML для размещенной CMS? для обсуждения по дезинфекции пользовательского ввода

Это идея, о которой мы подумали, безусловно, безопасная, но наши пользователи относительно низкотехнологичны. Они действительно хотели бы ссылки, которые они могут нажать. Keith
Это тоже не безопасно. Они все еще могут найти способ встроить тег сценария. Joel Coehoorn
понятно, я их вообще предпочитаю, но копирую / вставляюделает заставить меня занять пару секунд, чтобы решить, если яДЕЙСТВИТЕЛЬНО хочу сделать это warren
Почему мы разрешаем теги? Я предполагаю, что он имел в виду поворот любого случая:somesite.com - somesite.com В <a href = "somesite.com "> http://somesite.com </ а> Nick Stinemates
8

PHP -http://code.google.com/p/owasp-esapi-php/Ява -http://code.google.com/p/owasp-esapi-java/.СЕТЬ -http://code.google.com/p/owasp-esapi-dotnet/Python -http://code.google.com/p/owasp-esapi-python/

Прочитайте следующее:

https://www.golemtechnologies.com/articles/prevent-xss#how-to-prevent-cross-site-scriptinghttps://www.owasp.org/http://www.secbytes.com/blog/?p=253

Например:

$url = "http://stackoverflow.com"; // e.g., $_GET["user-homepage"];
$esapi = new ESAPI( "/etc/php5/esapi/ESAPI.xml" ); // Modified copy of ESAPI.xml
$sanitizer = ESAPI::getSanitizer();
$sanitized_url = $sanitizer->getSanitizedURL( "user-homepage", $url );

Другим примером является использование встроенной функции. РНРfilter_var функция является примером:

$url = "http://stackoverflow.com"; // e.g., $_GET["user-homepage"];
$sanitized_url = filter_var($url, FILTER_SANITIZE_URL);

С помощьюfilter_var позволяет вызовы JavaScript и отфильтровывает схемы, которые не являютсяhttp ниhttps, С помощьюOWASP ESAPI Sanitizer это, наверное, лучший вариант.

Еще одним примером является код изWordPress:

http://core.trac.wordpress.org/browser/tags/3.5.1/wp-includes/formatting.php#L2561

Кроме того, поскольку нет способа узнать, где URL-ссылки ссылаются (то есть это может быть действительный URL-адрес, но содержимое URL-адреса может быть вредным), у Google естьбезопасный просмотр API вы можете вызвать:

https://developers.google.com/safe-browsing/lookup_guide

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

Если вы не Джон Скит, код будет иметь ошибки.Существующие API имеют много часов обзора и тестирования.Существующие API валидации URL учитывают интернационализацию.Существующие API будут обновляться в соответствии с новыми стандартами.

Другие вопросы для рассмотрения:

Какие схемы вы разрешаете (являютсяfile:/// а такжеtelnet:// приемлемый)?Какие ограничения вы хотите наложить на содержание URL (допустимы ли вредоносные URL)?
Приветствия, но проблема здесь в том, что OWASP тоже не Джон Скит. Я не хочу раскручивать свои собственные, мой настоящий вопрос о том, в какой степени можно положиться на любой из них. Я проверю OWASP один, ноопределенно не доверяйте никакой безопасности, встроенной в PHP! Keith
Я пытался использовать эту библиотеку для очистки URL-адресов, но не смог найти никаких действий, чтобы сделать это для .net. Здесь я взял код и документациюcode.google.com/archive/p/owasp-esapi-dotnet/downloadsСам проект выглядит несвежим Bogdan
«Это единственный ответ с реальным кодом, который не был назван небезопасным. ИМХО, лучший ответ». Нет, это не так.filter_var($url, FILTER_SANITIZE_URL); позволяет, например,javascript:alert(); Kenji
Если можете, попробуйте Google Safe Browsing API. Это может не подходить для вашей ситуации, но если исходный код доступен, он может послужить отличной отправной точкой. Dave Jarvis
Это единственный ответ с реальным кодом, который не был указан как небезопасный. ИМХО, лучший ответ. antinome
0
3

тогда я предполагаю ASP.NET, и для этого вы можете использоватьБиблиотека Microsoft Anti-Cross сценариев сайта

Он очень прост в использовании, все, что вам нужно, это включить и все :)

Пока вы на тему, почему бы не прочитатьРекомендации по разработке безопасных веб-приложений

Если какой-либо другой язык .... если есть библиотека для ASP.NET, должен быть доступен также для других языков (PHP, Python, ROR и т. Д.)

Мы специально на C # 3.5 и ASP.Net - я проверю эту библиотеку. Keith
13

е шага:

Unescape / перекодировать строку, которую вы дали (RSnake задокументировал ряд трюков наhttp://ha.ckers.org/xss.html которые используют экранирование и кодировки UTF).Очистите ссылку: регулярные выражения - хорошее начало - обязательно обрежьте строку или выбросьте ее, если она содержит "(или все, что вы используете для закрытия атрибутов в выходных данных); если вы делаете ссылки только как ссылки к другой информации вы также можете принудительно применить протокол в конце этого процесса - если часть перед первым двоеточием не является «http» или «https», то добавьте «http: //» в начало. Это позволяет создать пригодный для использования ссылки из неполного ввода, которые пользователь вводит в браузер, дают вам последний шанс споткнуться в любую неприятность, в которую кто-то пытался проникнуть.Убедитесь, что результатом является правильно сформированный URL (протокол: //host.domain [: порт] [/ путь] [/ [файл]] [? QueryField = queryValue] [#anchor]).Возможно, проверьте результат по черному списку сайта или попробуйте получить его с помощью какого-либо средства проверки на вредоносное ПО.

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

Ссылка кажется мертвой, и одно время кажется, что она перенаправлена наowasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet Monkpit
52

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Прочитайте это и плачьте.

Вот как мы это делаем в Stack Overflow:

/// <summary>
/// returns "safe" URL, stripping anything outside normal charsets for URL
/// </summary>
public static string SanitizeUrl(string url)
{
    return Regex.Replace(url, @"[^-A-Za-z0-9+&@#/%?=~_|!:,.;\(\)]", "");
}
Не мешает ли это пользователям предоставлять (обычный) префикс http: // всем веб-адресам? Earlz
Этого недостаточно. Если я что-то упустил, эта строка прошла бы через фильтр: javascript: alert & # x28; & # x27; hacked & # x27; & # x29; Patrick McElhaney
Даже через это можно пройти: javascript: while (true) alert ('Hacked!'); Я протестировал пару мест здесь на SO, и похоже, что SanatizeUrl - это только часть решения. Patrick McElhaney
Отличная ссылка. Время добавлять новые тестовые случаи ... Mnebuerquo
Пять лет спустя я не вижу ответов на комментарии, которые приводят примеры того, как этот ответ небезопасен. Тем не менее, это ответ с наибольшим количеством голосов на вопрос с наибольшим количеством голосов (который я мог найти) по этой теме! Учитывая, насколько обычно это удивительный стековый поток, я удивлен, что до сих пор не уверен, как безопасно реализовать этот относительно распространенный сценарий. antinome
0

написанном на JavaScript, я использую это регулярное выражение в качестве белого списка:

 url.match(/^((https?|ftp):\/\/|\.{0,2}\/)/)

единственное ограничение заключается в том, что вам нужно поместить ./ перед файлами в том же каталоге, но я думаю, что могу с этим смириться.

Похожие вопросы