Салют, хабровчане! Подготовили для вас перевод полезного руководства в преддверии старта курса «C# ASP.NET Core разработчик».
С каждым обновлением .Net Core Microsoft доказывает тот факт, что .Net Core является самым мощным, универсальным и полным фреймворком, доступным для разработки мощных десктопных, мобильных, облачных и веб-приложений. В отличие от десктопного или мобильного приложения, веб-приложение работает по общедоступному адресу, что является одной из причин, по которым безопасность веб-приложения имеет огромную важность. Хотя Asp.Net Core разработан с учетом лучших практик безопасности, тем не менее, все же существуют некоторые уязвимости, за которыми мы должны следить до и после релиза нашего Asp.Net Core приложения.
В этой статье мы рассмотрим несколько пробелов в безопасности Asp.Net Core веб-приложений и их возможные решения. Давайте начнем с перечисления некоторых важных моментов для обеспечения безопасности нашего .Net Core приложения.
Страница логина это парадный вход любого приложения. Рассмотрим приложение типа панели администратора. Если неавторизованный человек получает доступ к вашему приложению, он может контролировать всю систему. Таким образом, ваш первый шаг всегда должен заключаться в повышении безопасности логина.
Вот несколько советов как защитить точку входа вашего приложения.
ИСПОЛЬЗУЙТЕ СЛОЖНЫЕ УЧЕТНЫЕ ДАННЫЕ
Никогда не используйте юзернеймы наподобие admin и пароли наподобие 12345, или вашего имени или персональных данных. Кто угодно может воспользоваться этим недочетом, а бот сможет подобрать такие учетные данные в невероятно короткие сроки.
ЗАЩИТИТЕ СВОЙ ЛОГИН ОТ БРУТФОРСА
Брутфорс (Brute Force) является наиболее распространенным типом атак, который заключается в использовании различных алгоритмов перебора комбинаций юзернейма и пароля с целью угадать учетные данные для логина. Кроме того, большое количество попыток входа в систему может перегрузить ваш сервер, что может вылиться в DoS (Denial of service или “отказ в обслуживании”) и простоях для реальных пользователей вашего приложения.
Брутфорс атакам требуется меньше времени, чтобы подобрать простые юзернеймы и пароли, но они также могут угадывать и сложные комбинации, используя банальный перебор вариантов.
Итак, как же защитить ваше Asp.Net приложение от брутфорс атак?
Вот несколько советов по предотвращению брутфорса:
Как реализовать вышеуказанные рекомендации?
Вышеуказанные рекомендации могут показаться сложными в реализации для начинающих Asp.Net Core разработчиков, но не волнуйтесь, существует отличная библиотека HackerSpray, которая поможет вам защитить вашу работу от брутфорс атак. От вас требуется лишь настроить ее.
ВСЕГДА ИСПОЛЬЗУЙТЕ .NET CORE IDENTITY
Asp.Net Core имеет множество встроенных библиотек и инструментов для защиты ваших приложений. Авторизация также имеет замечательную реализацию от Microsoft, которая предоставляет нам полную настройку входа в систему и регистрации в соответствии с лучшими практиками безопасности.
Никогда не отправляйте свои конфиденциальные данные, такие как пароль или учетные данные кредитной карты, для проверки на сервер в явной форме. Хакеры могут украсть эти данные, перехватывая их перед отправкой на сервер.
Всегда используйте алгоритм хеширования, такой как md5 или SHA256, для паролей и алгоритмы шифрования, такие как AES или DES, на стороне клиента, например, используя jQuery.
При входе в систему в приложении Asp.Net Core, мы сохраняем некоторые необходимые данные в Session для поддержания логина пользователя до тех пор, пока он не выйдет из системы. В некоторых приложениях мы устанавливаем таймаут сеанса, а иногда не устанавливаем, когда пользователь отмечает флажок, означающий его желание оставаться в системе, на странице логина.
В то же время, cookie-файл AspNetCore.Session добавляется в браузер для ведения учета вошедшего в систему пользователя.
Поэтому, когда мы выходим из системы, нам также необходимо удалить из браузера cookie-файлы, созданные нашим приложением, поскольку хакер может использовать эту информацию для несанкционированного входа в систему. Это также называется атакой фиксации сессии (Session Fixation).
SSL означает Secure Socket Layer. Он шифрует связь между клиентом и сервером с помощью очень сложного ключа.
Вы можете просто указать в Starup.cs вашего Asp.Net Core приложения всегда использовать безопасную политику для cookie-файлов.
Почти каждое веб-приложение для хранения пользовательских данных нуждается в базе данных, которые хакеры атакуют в большинстве случаев именно для кражи этих пользовательских данных. Итак, допустим, что вы храните учетные данные ваших пользователей, такие как пароли и платежные спецификации, в вашей базе данных очень подробно и в чистом виде. Получается, что любой, кто получит несанкционированный доступ к вашей базе данных, может использовать эти данные в своих корыстных целях.
Поэтому всегда храните конфиденциальные данные в вашей базе данных, используя хеширование или шифрование.
Аудиторские следы или логирование активности очень важны для того, чтобы быть в курсе того что происходит в вашем приложении. Если кто-то генерирует большое количество неудавшихся попыток входа в систему, то администратор должен получить электронное письмо, информирующее его об этом.
Скажем, создает ли пользователь новый инстанс пользователя приложения или меняет роли существующего, каждое его действие должно быть отражено в логах вашего Asp.net Core приложения.
Некоторые исключения могут раскрыть важную информацию о вашем приложении или даже иногда показать несколько строк кода конечному пользователю. Злоумышленники — умные ребята, они могут использовать информацию, предоставленную вашим исключением, чтобы взломать ваше приложение.
Поэтому перед развертыванием приложения в продакшене убедитесь, что вы создали страницу отображения ошибки пользователю для всех видов исключений и корректно сохранили ошибки в логе своего приложения.
В XSS(Cross-Site Scripting)-атаках хакеры в целях кражи учетных данных пользователей и других важных данных засылают вредоносные скрипты через поля ввода.
Допустим, у нас есть форма для добавления товара в заявку. Хакер добавляет новый продукт и в поле описания продукта он просто вставляет JavaScript фрагмент кода. Когда наше приложение отобразит этот продукт на странице продукта с описанием, вредоносный скрипт хакера также запустится, и он получит нужные ему данные.
Я нашел изображение ниже в статье о XSS на Cloudflare. Это поможет вам легче представить XSS.
Итак, как защитить наше Asp.Net Core приложение от атак с использованием межсайтовых скриптов?
Вы можете защитить свое веб-приложение, следуя этим советам:
Вот отличная статья от Microsoft про защиту вашего приложения от XSS.
В каждом HTTP-ответе от сервера, который мы получаем в ответ на наш запрос, отправленный из браузера, всегда есть информация о версии, на которой разрабатывалось приложение. Такая информация облегчает работу злоумышленника, экономя ему время и позволяя ориентироваться на конкретную версию .Net.
Необходимо создавать больше препятствий для хакеров и усложнять их работу, скрывая информацию о версии .Net Framework.
Вот как можно скрыть версию .Net Core:
Установите
Вы можете удалить X-Powered-By, используя этот простой фрагмент кода в вашем
Знаете ли вы назначение атрибута
Сначала нужно разобраться с CSRF (Cross-Site Request Forgery или XSRF), затем мы попытаемся понять цель вышеуказанного тега и атрибута.
Допустим, вы используете функцию электронного банкинга со своего банковского счета для отправки денег своему другу, и внезапно вы получаете ссылку на FaceBook от женщины с красивой аватаркой. Когда вы открываете эту ссылку, она просит вас нажать сюда, чтобы заработать 1000 долларов. Вы просто нажимаете и, поскольку вы залогинены и авторизованы для использования вашего электронного банкинга, эта вредоносная ссылка запускает скрипт и отправляет деньги с вашего аккаунта на аккаунт хакера.
Изображение ниже наглядно демонстрирует CSRF.
Как же защитить ваше приложение от CSRF?
SQL инъекции — один из наиболее часто используемых приемов, наносящих вред данным пользователей за многие годы.
В этом методе хакер помещает некоторые условные или специальные символы в поле ввода, которые вызывают изменение выполнения всего запроса.
Вот наглядный пример, что такое SQL инъекция.
Как обезопасить ваше Asp.Net Core приложение от SQL инъекций?
Вот несколько советов:
Десериализация — это противоположность сериализации, которая представляет собой процесс преобразования объекта в потоки байтов. Сериализация всегда выполняется на стороне сервера для передачи или хранения объектов, а десериализуем мы данные, полученные в нашем приложением из различных источников.
Таким образом, мы открыты для множества вредных потоков.
Чтобы защитить ваше приложение от злоумышленников, нам необходимо проверять данные до и после десериализации.
Всегда обновляйте фреймворки и библиотеки, используемые в вашем проекте. Никогда не используйте устаревшие библиотеки в своем проекте, потому что злоумышленники постоянно находят уязвимости в них.
Проверяйте наличие обновлений для NuGet пакетов, используемых в вашем проекте, и обновляйте их регулярно.
Ничто не бывает на 100% безопасным, но мы должны сделать наше приложение максимально безопасным, следуя лучшим практикам. Хотя .Net Core считается одной из самых безопасных платформ, мы все же должны следить за действиями в нашем приложении и принимать быстрые меры в случае любой вредоносной активности.
Спасибо за чтение моей статьи, надеюсь, она мотивирует вас подумать о повышении безопасности вашего Asp.Net Core приложения.
Я буду рад, если вы захотите оставить свой отзыв в разделе комментариев ниже.
Вот еще несколько статей, которые могут вас заинтересовать:
Узнать подробнее о курсе
С каждым обновлением .Net Core Microsoft доказывает тот факт, что .Net Core является самым мощным, универсальным и полным фреймворком, доступным для разработки мощных десктопных, мобильных, облачных и веб-приложений. В отличие от десктопного или мобильного приложения, веб-приложение работает по общедоступному адресу, что является одной из причин, по которым безопасность веб-приложения имеет огромную важность. Хотя Asp.Net Core разработан с учетом лучших практик безопасности, тем не менее, все же существуют некоторые уязвимости, за которыми мы должны следить до и после релиза нашего Asp.Net Core приложения.
В этой статье мы рассмотрим несколько пробелов в безопасности Asp.Net Core веб-приложений и их возможные решения. Давайте начнем с перечисления некоторых важных моментов для обеспечения безопасности нашего .Net Core приложения.
- Сделайте логин более безопасным
- Передавайте секретные данные только в зашифрованном виде
- Не забывайте чистить cookies при выходе
- Всегда используйте SSL
- Никогда не храните конфиденциальные данные в вашей базе данных в явном виде
- Аудиторские следы и логирование очень важны
- Никогда не показывайте оригинальные технические ошибки конечному пользователю
- Межсайтовый скриптинг (XSS)
- Старайтесь скрывать версию вашего .Net Core
- Межсайтовая подделка запроса (CSRF)
- LINQ может защитить от SQL инъекций
- Добавьте проверки во время десериализации
- Всегда следите за актуальными версиями ваших фреймворков и библиотек
1. Сделайте логин более безопасным
Страница логина это парадный вход любого приложения. Рассмотрим приложение типа панели администратора. Если неавторизованный человек получает доступ к вашему приложению, он может контролировать всю систему. Таким образом, ваш первый шаг всегда должен заключаться в повышении безопасности логина.
Вот несколько советов как защитить точку входа вашего приложения.
ИСПОЛЬЗУЙТЕ СЛОЖНЫЕ УЧЕТНЫЕ ДАННЫЕ
Никогда не используйте юзернеймы наподобие admin и пароли наподобие 12345, или вашего имени или персональных данных. Кто угодно может воспользоваться этим недочетом, а бот сможет подобрать такие учетные данные в невероятно короткие сроки.
ЗАЩИТИТЕ СВОЙ ЛОГИН ОТ БРУТФОРСА
Брутфорс (Brute Force) является наиболее распространенным типом атак, который заключается в использовании различных алгоритмов перебора комбинаций юзернейма и пароля с целью угадать учетные данные для логина. Кроме того, большое количество попыток входа в систему может перегрузить ваш сервер, что может вылиться в DoS (Denial of service или “отказ в обслуживании”) и простоях для реальных пользователей вашего приложения.
Брутфорс атакам требуется меньше времени, чтобы подобрать простые юзернеймы и пароли, но они также могут угадывать и сложные комбинации, используя банальный перебор вариантов.
Итак, как же защитить ваше Asp.Net приложение от брутфорс атак?
Вот несколько советов по предотвращению брутфорса:
- Используйте Captcha на своей странице логина, потому что боты пока не могут справиться с капчей.
- Временно блокируйте IP после нескольких неудачных попыток входа в систему.
- Избегайте использования распространенных имен пользователей, таких как admin или user, потому что брутфорс алгоритмы обычно имеют базу данных распространенных учетных данных и пробуют их в первую очередь.
- Сделайте ваш пароль сложным для подбора, а именно содержащим в себе буквы(A-Z и a-z), цифры(0-9) и специальные символы(!, @,., #, $,%, ^, &, * и т.д.).
Как реализовать вышеуказанные рекомендации?
Вышеуказанные рекомендации могут показаться сложными в реализации для начинающих Asp.Net Core разработчиков, но не волнуйтесь, существует отличная библиотека HackerSpray, которая поможет вам защитить вашу работу от брутфорс атак. От вас требуется лишь настроить ее.
ВСЕГДА ИСПОЛЬЗУЙТЕ .NET CORE IDENTITY
Asp.Net Core имеет множество встроенных библиотек и инструментов для защиты ваших приложений. Авторизация также имеет замечательную реализацию от Microsoft, которая предоставляет нам полную настройку входа в систему и регистрации в соответствии с лучшими практиками безопасности.
2. Передавайте секретные данные только в зашифрованном виде
Никогда не отправляйте свои конфиденциальные данные, такие как пароль или учетные данные кредитной карты, для проверки на сервер в явной форме. Хакеры могут украсть эти данные, перехватывая их перед отправкой на сервер.
Всегда используйте алгоритм хеширования, такой как md5 или SHA256, для паролей и алгоритмы шифрования, такие как AES или DES, на стороне клиента, например, используя jQuery.
3. Не забывайте чистить cookies при выходе
При входе в систему в приложении Asp.Net Core, мы сохраняем некоторые необходимые данные в Session для поддержания логина пользователя до тех пор, пока он не выйдет из системы. В некоторых приложениях мы устанавливаем таймаут сеанса, а иногда не устанавливаем, когда пользователь отмечает флажок, означающий его желание оставаться в системе, на странице логина.
В то же время, cookie-файл AspNetCore.Session добавляется в браузер для ведения учета вошедшего в систему пользователя.
Поэтому, когда мы выходим из системы, нам также необходимо удалить из браузера cookie-файлы, созданные нашим приложением, поскольку хакер может использовать эту информацию для несанкционированного входа в систему. Это также называется атакой фиксации сессии (Session Fixation).
4. Всегда используйте SSL
SSL означает Secure Socket Layer. Он шифрует связь между клиентом и сервером с помощью очень сложного ключа.
Вы можете просто указать в Starup.cs вашего Asp.Net Core приложения всегда использовать безопасную политику для cookie-файлов.
5. Никогда не храните конфиденциальные данные в вашей базе данных в явном виде
Почти каждое веб-приложение для хранения пользовательских данных нуждается в базе данных, которые хакеры атакуют в большинстве случаев именно для кражи этих пользовательских данных. Итак, допустим, что вы храните учетные данные ваших пользователей, такие как пароли и платежные спецификации, в вашей базе данных очень подробно и в чистом виде. Получается, что любой, кто получит несанкционированный доступ к вашей базе данных, может использовать эти данные в своих корыстных целях.
Поэтому всегда храните конфиденциальные данные в вашей базе данных, используя хеширование или шифрование.
6. Аудиторские следы и логирование очень важны
Аудиторские следы или логирование активности очень важны для того, чтобы быть в курсе того что происходит в вашем приложении. Если кто-то генерирует большое количество неудавшихся попыток входа в систему, то администратор должен получить электронное письмо, информирующее его об этом.
Скажем, создает ли пользователь новый инстанс пользователя приложения или меняет роли существующего, каждое его действие должно быть отражено в логах вашего Asp.net Core приложения.
7. Никогда не показывайте оригинальные технические ошибки конечному пользователю
Некоторые исключения могут раскрыть важную информацию о вашем приложении или даже иногда показать несколько строк кода конечному пользователю. Злоумышленники — умные ребята, они могут использовать информацию, предоставленную вашим исключением, чтобы взломать ваше приложение.
Поэтому перед развертыванием приложения в продакшене убедитесь, что вы создали страницу отображения ошибки пользователю для всех видов исключений и корректно сохранили ошибки в логе своего приложения.
8. Межсайтовый скриптинг (XSS)
В XSS(Cross-Site Scripting)-атаках хакеры в целях кражи учетных данных пользователей и других важных данных засылают вредоносные скрипты через поля ввода.
Допустим, у нас есть форма для добавления товара в заявку. Хакер добавляет новый продукт и в поле описания продукта он просто вставляет JavaScript фрагмент кода. Когда наше приложение отобразит этот продукт на странице продукта с описанием, вредоносный скрипт хакера также запустится, и он получит нужные ему данные.
Я нашел изображение ниже в статье о XSS на Cloudflare. Это поможет вам легче представить XSS.
Итак, как защитить наше Asp.Net Core приложение от атак с использованием межсайтовых скриптов?
Вы можете защитить свое веб-приложение, следуя этим советам:
- Используйте регулярные выражения как на стороне клиента, так и на стороне сервера, и сохраняйте в своей базе данных только проверенные данные.
- HTML-шифрование с помощью Razor помогает обрабатывать такие скрипты.
- XXS также можно совершать с помощью URL-шифрования, поэтому проверяйте параметры URL-адреса и шифруйте их с помощью UrlEncoder.
Вот отличная статья от Microsoft про защиту вашего приложения от XSS.
9. Старайтесь скрывать версию вашего .Net Core
В каждом HTTP-ответе от сервера, который мы получаем в ответ на наш запрос, отправленный из браузера, всегда есть информация о версии, на которой разрабатывалось приложение. Такая информация облегчает работу злоумышленника, экономя ему время и позволяя ориентироваться на конкретную версию .Net.
Необходимо создавать больше препятствий для хакеров и усложнять их работу, скрывая информацию о версии .Net Framework.
Вот как можно скрыть версию .Net Core:
- Удалить X-Powered-By из заголовка ответа.
- <a
href="https://www.nuget.org/packages/NWebsec.AspNetCore.Middleware/">NWebsec.AspNetCore.Middleware
Установите
AddServerHeader = false
для удаления заголовка Server: Kestrel.Вы можете удалить X-Powered-By, используя этот простой фрагмент кода в вашем
web.config
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
10. Межсайтовая подделка запроса (CSRF)
Знаете ли вы назначение атрибута
[ValidateAntiForgeryToken]
в ваших .Net Core Web API-интерфейсах? Возможно, вы также замечали код asp-antiforgery="true"
в ваш cshtml
файле?Сначала нужно разобраться с CSRF (Cross-Site Request Forgery или XSRF), затем мы попытаемся понять цель вышеуказанного тега и атрибута.
Допустим, вы используете функцию электронного банкинга со своего банковского счета для отправки денег своему другу, и внезапно вы получаете ссылку на FaceBook от женщины с красивой аватаркой. Когда вы открываете эту ссылку, она просит вас нажать сюда, чтобы заработать 1000 долларов. Вы просто нажимаете и, поскольку вы залогинены и авторизованы для использования вашего электронного банкинга, эта вредоносная ссылка запускает скрипт и отправляет деньги с вашего аккаунта на аккаунт хакера.
Изображение ниже наглядно демонстрирует CSRF.
Как же защитить ваше приложение от CSRF?
asp-antiforgery="true"
создает токен защиты от подделки, а [ValidateAntiForgeryToken]
проверяет на стороне сервера, действителен ли токен, и защищает вас от межсайтовой подделки запросов.11. LINQ может защитить от SQL инъекций
SQL инъекции — один из наиболее часто используемых приемов, наносящих вред данным пользователей за многие годы.
В этом методе хакер помещает некоторые условные или специальные символы в поле ввода, которые вызывают изменение выполнения всего запроса.
Вот наглядный пример, что такое SQL инъекция.
Как обезопасить ваше Asp.Net Core приложение от SQL инъекций?
Вот несколько советов:
- Используйте Entity Framework Core
- Всегда используйте параметризованные запросы.
- Всегда проверяйте ввод на стороне сервера.
- Используйте хранимые процедуры.
12. Добавьте проверки во время десериализации
Десериализация — это противоположность сериализации, которая представляет собой процесс преобразования объекта в потоки байтов. Сериализация всегда выполняется на стороне сервера для передачи или хранения объектов, а десериализуем мы данные, полученные в нашем приложением из различных источников.
Таким образом, мы открыты для множества вредных потоков.
Чтобы защитить ваше приложение от злоумышленников, нам необходимо проверять данные до и после десериализации.
13. Всегда следите за актуальными версиями ваших фреймворков и библиотек
Всегда обновляйте фреймворки и библиотеки, используемые в вашем проекте. Никогда не используйте устаревшие библиотеки в своем проекте, потому что злоумышленники постоянно находят уязвимости в них.
Проверяйте наличие обновлений для NuGet пакетов, используемых в вашем проекте, и обновляйте их регулярно.
ЗАКЛЮЧЕНИЕ
Ничто не бывает на 100% безопасным, но мы должны сделать наше приложение максимально безопасным, следуя лучшим практикам. Хотя .Net Core считается одной из самых безопасных платформ, мы все же должны следить за действиями в нашем приложении и принимать быстрые меры в случае любой вредоносной активности.
Спасибо за чтение моей статьи, надеюсь, она мотивирует вас подумать о повышении безопасности вашего Asp.Net Core приложения.
Я буду рад, если вы захотите оставить свой отзыв в разделе комментариев ниже.
Вот еще несколько статей, которые могут вас заинтересовать:
- TOP OPEN SOURCE ASP.NET CORE CONTENT SYSTEM (CMS)
- CREATING DYNAMIC USER-DEFINED DASHBOARDS USING ASP.NET CORE
- USING NOSQL DATABASE WITH DOTNET CORE EXAMPLE
Узнать подробнее о курсе
Drag13
Признаюсь, первый минус статье поставил я, из-за:
Пожалуйста, никогда, нет — НИКОГДА, нет даже не так: НИКОГДА не используйте регулярные выражения для проверки на XSS. Вот простой пример как хорошие намерения превращаются в уязвимость:
И таких вариантов очень много.
П.С. А да, шифрование на клиенте симметричными алгоритмами это тоже прекрасно. Ключ где клиент возьмет?
SanSYS
Не лишено смысла не передавать пароль от браузера в апишку
Как это представляется:
1. либо всегда sha256, но где же соль брать?)
Либо:
1. Браузер по логину получает публичный ключ с апишки
2. Шифрует им пароль
3. Приватным ключиком расшифровывается в беке и хешируется PBKDF2
Как следствие:
1. «Man in the middle» в пролёте
2. случайным образом в логи пароли пользователей не попадут
3. сами ключи для расшифрования можно хранить в бд пользователей, предварительно зашифровав более общим ключиком (от посторонних глаз имеющих доступ к базе)
Посмотрите пример тут mail.protonmail.com/login, уверен там сложнее, чем я описал, но суть +- та же
П.С. А да, сама статья заслуживает минуса, не стоило переводить, кмк
Drag13
Ну так и я очем, хешировать можно, но без соли малополезно, т.к. qwerty-подобные пароли просто лежат в таблицах.
А второй вариант хорош да, но это немного другой уровень чем в статье, в которой о соли даже нет упоминания. Зато из этого поста получилось три прекрасных твита :D
SanSYS
:D
mjr27
как-то так
salt = randChars(20)
hash = sha256(password + salt) + "." + salt;
Drag13
Потом пользователь перелогинивается и соль потеряна.
SanSYS
Этот вариант сработает, если в БД сохраняется пароль пользователя, что не является приемлемым
Так что вариант не является рабочим.
Хотя вы можете развить идею в ту, что я описал выше, и получать соль с сервера… однако тогда от этой соли нет никакого толку и hashcat отлично поможет подобрать пароль
Politura
А если так?
const killXss = (string) => string.replace(/</, "& lt;");
По статье заголовок 11 параграфа: «LINQ может защитить от SQL инъекций» но в самом параграфе тема вообще не раскрываецца, какжеж линк может защитить-то? :)
Из всех рекомендаций достаточно оставить одну единственную «Всегда используйте параметризованные запросы.». Пункт про энтити это чисто следствие оной ибо энтити использует параметризованные запросы, проверка перед запуском ничего не гарантирует, а вот параметризованные запросы гарантируют, использование хранимок без использования параметризованных запросов к ним ни от чего не защитит.
Тема про проверки десериализации тоже нифига не раскрыта. Что именно там проверять?
Ну вот есть у меня некий десериализер, у которого есть метод, что из строки получает экземпляр некоего класса, типа:
Deserialize(string data);
оный метод создает новый экземпляр класса T затем ищет в данных поля с именами совпадающими с именами полей этого класса и заполняет его значениями поля созданного экземпляра, все остальное что там есть в данных игнорируется.
вот я его использую, передавая ему свой DTO не имеющий методов, чистые данные:
var x = serializer.Deserialize<AccountDTO>("some string");
и что тут мне страшного может подсунуть злоумышленник? на каком этапе и что именно я должен проверять согласно этому пункту рекомендаций?
Drag13
А теперь вам нужно пропускать < потому что мы хотим ставить динамические теги...
Но смысл не в этом. Даже если ваш код на 100% защищает от ХSS сейчас, это не гарантирует что это будет работать и потом. А потом, вы весь код не пересмотрите потому что задачи будут уже другие. И вот, как в анекдоте — "хоть что то у нас в безопасности"
Politura
Ну, может быть, я где-то на 95% бакенд, поэтому не особо в курсе что там за подводные камни с этим ХSS.
Drag13
Не удержался:
Эта красота работала только в огнелисе и только в нескольких версиях. Как с таким бороться я не знаю.
beskaravaev
А что делает эта красота?
Drag13
SVG в base64 внутри которого зашит скрипт с alert('xss')
asjp
Есть уязвимости десериализации, позволяющие выполнять произвольный код (например, при десериализации в объект процесса можно запустить код; видел эту тему сто лет назад, точно не скажу, где, скорее всего на dotnext). Другое дело, что на кой чёрт в системе может понадобиться такая сущность…
y4ppieflu
Небезопасная сериализация возникает, когда атакующий имеет контроль над типом объекта, которые десериализуется на сервере. К «небезопасным» маршаллерам относятся BinaryFormatter, JavascriptSerializer с SimpleTypeResovler, Newtonsoft.Json c TypeNameHandling!=None и т.п. Это бывает иногда нужно, в таких случаях рекомендуется добавлять перед десериализацией guard, который проверит тип переданного объекта по белому списку. Это необходимо, т.к. даже если ваше приложение не ожидает объект другого типа и кинет в ходе десерилиализации исключение — подсунутый код все равно выполнится.
В Вашем случае — если тип заранее предопределен и не передается вместе с самим объектом — проблемы нет.
Тык Тык
Politura
Ну вот мне и интересен сценарий, когда именно это нужно?
Из первой ссылки:
IRunnable run = (IRunnable)fmt.Deserialize(stm);
Неужели на самом деле у кого-то в подобном есть острая необходимость, или это просто теоретические изыскания? Просто за лет 10-15 использования всяких сериализеров в работе ни разу не возникало необходимости в подобном. Ну и я-бы сторонился десериализеров которые возвращают Object, а не генерик метод возвращающий именно то, что я ожидаю получить.
y4ppieflu
Не совсем понял, о чем речь. Любой сериализатор возвращает Object, другое дело, что не всегда есть возможность повлиять на тип этого объекта.
Это не теоретические изыскания. В случае использования нативной бинарной сериализации (там, насколько я знаю, тип всегда передается с объектом) никто просто не задумывается о том, что что-то может пойти не так.
Если речь про JSON/XML — я пару раз сталкивался с ситуацией, когда контроллер должен уметь обрабатывать объекты разных типов, разработчик идет по пути наименьшего сопротивления и включает «polymorphic type handling».
Пара примеров из реальной жизни, например, тут.
y4ppieflu
С чего Вы вообще взяли, что в статье речь про санитизацию?
Регулярки — неплохой способ проверять входные данные. В свою очередь, валидация — один из основополагающих механизмов веб-безопасности, т.к. при правильном применении помогает уменьшить attack surface и является превентивной мерой для целых классов атак. Если в приложении на текстбокс имя-фамилия валидация [a-zA-Z0-9,_]{,20}, то шанс пропихнуть через него хранимую XSS стремится к нулю, даже если где-то на выводе забыли про экранирование.
В том же OWASP ESAPI вся валидация сделана на регулярках, а его разработчики явно понимают в этом вашем аппсеке.
Drag13
Все так. Только вместо раздела валидации, где регулярки вполне применимы, автор пишет о них в разделе про XSS — это раз. Об использование белых списков (как в вашем примере) ни слова — это два. И рядовой дев не имеет такую квалификацию как разработчики в OWASP, это три.
y4ppieflu
Как будто валидация и XSS никак не связаны. Это Вы сами почему-то решили, что «сохраняйте в базе только проверенные данные» значит, что из пользовательского ввода надо вырезать script. Хотя имеется в виду именно валидация. Остальные два аргумента комментировать не берусь, т.к. вообще не понял к чему они.
Статья в целом плохая, но конкретно этот пункт, к которому у вас появились претензии, вполне имеет право на жизнь.
Drag13
В моем понимании — не связаны. Валидация это проверка бизнес правил. Она может, например, допускать наличие тега в биографии пользователя. А санитизация это способо сделать пользовательский ввод безопасным.
Разные задачи, разные инструменты, разные подходы.