Основные понятия модели безопасности ASP.NET

ASP.NET --- Безопасность в ASP.NET --- Основные понятия модели безопасности ASP.NET

Хотя платформа безопасности, предложенная .NET и ASP.NET, достаточно мощная, все же стоит постоянно иметь в виду базовые принципы и правильно применять эти средства в нужный момент. В слишком многих проектах забота о безопасности проявляется запоздало; архитекторы и разработчики не думают о ней на ранних стадиях проекта. Но если не принять во внимание безопасность с самого начала, а именно - при разработке проектного решения и архитектуры приложения, - то как можно будет правильно и вовремя воспользоваться средствами защиты, предлагаемыми .NET Framework?

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

Понятие потенциальных угроз

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

Именно поэтому моделирование угроз становится все более важным в современном процессе разработки программного обеспечения. Моделирование угроз - это структурированный способ анализа среды приложения с точки зрения возможных опасностей, классификация угроз и решение относительно приемов их смягчения. При таком подходе решения относительно технологий безопасности (таких как аутентификация и SSL-шифрование) всегда имеет действительное основание - потенциальную угрозу.

Однако моделирование угроз важно по еще одной причине. Как вы, возможно, знаете, не все потенциальные угрозы могут быть смягчены применением технологий защиты, такими как аутентификация и авторизация. Другими словами, некоторые из них вообще невозможно разрешить технически.

Например, банковское онлайновое решение может использовать SSL для защиты трафика веб-сайта. Но как пользователи могут знать, что они действительно используют банковскую страницу, а не хакерский поддельный веб-сайт? Хорошо, единственный способ убедиться в этом - проверить сертификат, используемый для установки канала SSL. Но пользователи должны быть предупреждены об этом, а потому вы должны каким-то образом их информировать. Поэтому "техника смягчения" угроз - это не только технологии защиты. Она включает требование того, чтобы все пользователи знали, как проверить сертификат. (Конечно, вы не можете заставить их это делать, но если система спроектирована соответствующим образом, все же можно стимулировать к этому большинство из них.) Моделирование угроз - метод анализа, помогающий выявить обстоятельства вроде этих, а не только факторы технического порядка.

Правила безопасного кодирования

Разумеется, только безопасная архитектура и проектное решение не могут сделать приложение абсолютно защищенным. Это лишь один из наиболее важных факторов. После разработки безопасной архитектуры и проектного решения понадобится также написать безопасный код.

При написании кода веб-приложений всегда имейте в виду следующие правила:

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

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

Никогда не используйте конкатенацию строк для формирования операторов SQL

Всегда применяйте параметризованные операторы, чтобы приложение не было уязвимо для атак внедрением SQL, как было описано в статье «SQL-инъекции».

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

Пользователь может ввести некоторые фрагменты кода HTML (например, сценарии), которые инициируют межсайтовую сценарную уязвимость (XSS). Поэтому всегда используйте HttpUtility.HtmlEncode() для отмены специальных символов вроде < или > перед выводом их на страницу или применяйте веб-элемент управления, который выполняет такое кодирование автоматически.

Никогда не размещайте важные данные в скрытых полях веб-страницы

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

Никогда не сохраняйте важные данные в состоянии представления

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

Защищайте свои cookie-наборы

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

Применяйте SSL

В общем случае, если веб-приложение обрабатывает данные, защищайте весь веб-сайт с помощью SSL. Не забывайте защищать даже каталоги с графическими изображениями или другими файлами, которые не управляются приложением напрямую через SSL.

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

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

Конвейер безопасности

Хороший способ повысить степень безопасности приложения - размещать компоненты в таком месте, которое требует защиты. Концептуальный шаблон уровней безопасности применяет модель конвейера к организации инфраструктуры безопасности. Эта модель помогает укрепить безопасность.

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

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

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