Как защититься от XSS в ASP.NET Core?
В ASP.NET у нас была проверка запросов, но в ASP.NET Core такого нет.
Как мы можем наилучшим образом защитить приложение ASP.NET Core от XSS?
Запрос на подтверждение отправлен:
https://nvisium.com/resources/blog/2017/08/08/dude-wheres-my-request-validation.html
- этот парень рекомендует RegEx на Models, например:
[RegularExpression(@"^[a-zA-Z0-9 -']*$", ErrorMessage = "Invalid characters detected")]
public string Name { get; set; }
... но это не работает для глобализации / интернационализации, т.е. нелатинских символов, таких как æ, ø å 汉字.
X-XSS to do> limited <XSS-защита: https://dotnetcoretutorials.com/2017/01/10/set-x-xss-protection-asp-net-core/ Как это, но есть только ограниченная поддержка afaik:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.Use(async (context, next) =>
{
context.Response.Headers.Add("X-Xss-Protection", "1");
await next();
});
app.UseMvc();
}
Документации от Microsoft два года назад: https://docs.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-2.1, и она не распространяется.
Я думаю сделать что-то простое, например:
myField = myField.Replace('<','').Replace('>','').Replace('&','').Repl...;
- по всем представлениям данных - но это кажется шатким.
Я задал тот же вопрос Microsoft, но мне интересно услышать, как люди решают эту проблему в реальных приложениях.
Обновление: что мы пытаемся выполнить:
В нашем приложении есть веб-формы, в которых люди могут вводить имя, адрес электронной почты, контент и т. д. Данные хранятся в базе данных и будут просматриваться в системе внешнего интерфейса и, возможно, в других системах в будущем (например, RSS-каналы, JSON и т. д.). Некоторые формы содержат редакторы форматированного текста (tinymce) и позволяют пользователям размечать свои тексты. Злоумышленники могли ввести <script>alert('evil stuff');</script> в поля. Как лучше всего избавиться от злых персонажей в ASP.NET Core до того, как он попадет в базу данных? Я предпочитаю, чтобы вредоносные сценарии вообще не сохранялись в базе данных.
Я подумал, что может сработать что-то вроде этого:
const string RegExInvalidCharacters = @"[^&<>\""'/]*$";
[RegularExpression(RegExInvalidCharacters, ErrorMessage = "InvalidCharacters")]
public string Name { get; set; }
[RegularExpression(RegExInvalidCharacters, ErrorMessage = "InvalidCharacters")]
public string Content { get; set; }
...
Пожалуйста, посмотрите это: stackoverflow.com/questions/37923431/…. @Christian Del Bianco имеет хороший ответ
Отвечает ли это на ваш вопрос? AntiXSS в ASP.Net Core
Ответы 5
Вы можете использовать пакет NuGet HtmlSanitizer в ASP.NET Core.
Спасибо за ответ - я обновил свой вопрос, чтобы он был более ясным. Мне нравится HtmlSanitizer для клиентской части, но меня больше интересует предотвращение попадания вредоносных данных в базу данных.
@Sha Вы можете использовать HtmlSanitizer в ResourceFilter, чтобы исключить «злые вещи» перед тем, как попасть в ваш контроллер, тем самым никогда не попадая в базу данных.
Что конкретно вы здесь делаете? Предотвратить сообщения, которые могут содержать контент, который может отображаться при несанкционированной обработке xss-атакой? Если да, то, как я недавно обсуждал с коллегой, вы не можете этого сделать, в зависимости от вашего сайта.
Я имею в виду, вы можете установить ограничения на стороне клиента для публикуемых данных, но это, очевидно, можно обойти, так что вы пытаетесь сделать? Предотвратить публикацию контента, при визуализации без дезинфекции которого является потенциальным риском xss?
За что отвечает ваша конечная точка Почта? Отвечает ли он за то, как другие системы могут отображать полученный результат?
Я бы сказал, что ваш главный риск xss связан с тем, как приложение обрабатывает ваши данные. Если вы не очищаете / не кодируете вывод на основе приложения, которое использует данные, вероятно, вы делаете это неправильно.
Помните, что потенциальная проблема с xss - это реальная проблема, только если вы выводите что-то на веб-страницу или подобное. На самом деле это не та конечная точка, которая получает данные о проблеме.
звучит как в точности случай с элементами управления WYSIWYG. Люди могут публиковать что угодно. И пока я снова показываю это в таком контроле - это нормально. Buit, если я покажу это в форме html, это проблема.
Один из лучших способов предотвратить сохраненный / отраженный XSS - это HTML-кодирование на выходе. Вы также можете кодировать перед сохранением в БД. Поскольку вам в любом случае не нужно, чтобы вывод из этих полей был в HTML.
Решение с Regex не всегда будет работать. Здесь вы полагаетесь на черный список. Всегда лучше и безопаснее полагаться на Белый список (который вам в данном случае не нужен). Или HTML-кодируйте вывод, если это возможно.
как вы используете эту технику, чтобы предотвратить создание xss из данных изображения в строке base64? Не уверен, что это работает.
можешь подробнее рассказать? Если вы говорите, что тег <img может быть введен со строкой base64, он будет закодирован в HTML. Или вы хотите ввести содержимое base64 с помощью какого-либо ввода?
Строка base64 в моем проекте - это содержимое файла изображения (фото профиля), загруженного пользователем. Эти данные base64 идут прямо в атрибут src тега img, к ним добавляются некоторые метаданные (data: image / png; base64, <base64 приходит сюда>). Вы видите здесь шанс xss?
Я знаю, что сейчас исполнился год, но для вашей (и других) справки вы можете взглянуть на создание ResourceFilter или Middleware, которое будет дезинфицировать входящие запросы. Вы можете использовать любые инструменты или настраиваемый код, но главное - все входящие запросы проходят через этот фильтр для очистки от неверных данных.
Убедитесь, что вы используете правильный фильтр для вашего приложения / потребности. ResourceFilter запускается перед привязкой модели, а ActionFilter запускается после привязки модели.
Я знаю, что на это уже был дан ответ, и вполне адекватно, но я хочу добавить свой ответ, чтобы также получить некоторую обратную связь. Это то, что я сделал в этом случае, что очень похоже на рассматриваемый вопрос.
Сценарий У нас есть интерфейсное приложение, построенное на Vue.js, завернутое в Quasar.dev, которое обслуживается API .NET 5.0 на задней стороне.
Решение
У нас есть «общедоступные модели», которые представляют собой объекты, которые мы используем для отправки клиентскому приложению. Они не имеют названий и форматов, как их поля базы данных. Мы используем AutoMapper для сопоставления полей (или моделей) базы данных с общедоступными полями (или моделями). После сопоставления общедоступной модели мы отправляем общедоступную модель пользователю. Затем внутри профиля AutoMapper я добавил расширение к объекту String под названием .Encode(), которое кодирует все, что поступает из базы данных, в поле общедоступной модели, используя следующий код ...
public static string Encoded(this string value)
{
return HttpUtility.HtmlEncode(value);
}
Теперь, каждый раз, когда я добавляю новые профили для общедоступных моделей, я просто добавляю этот вызов для кодирования строк, которым не доверяю.
Как насчет этого?
AFAIK tinymce автоматически защищает от XSS, по крайней мере, он предлагает вам широкий спектр настраиваемых параметров. Вдобавок к этому я бы просто разделил теги, не внесенные в белый список. Несколько примеров разделения / белого списка входных данных 12