Анализ защищённости приложений

Министерство образования Республики Беларусь
Учреждение образования
«Белорусский государственный университет информатики и радиоэлектроники»
Кафедра интеллектуальных информационных технологий



«Проектирование защищенных систем»
Лабораторная работа № 3
«Анализ защищённости приложений»





Выполнил: Студент гр. 021702
ТелевичР.А.


Проверил: Шалев Е.Г.





МИНСК
2014
1 ЗАДАНИЕ
- Разработать приложение, которое позволяет: добавить пользователя в систему; авторизовать пользователя на основе идентификационных данных; создать, редактировать, удалить, осуществить поиск конфиденциальных данных; создать, редактировать, удалить, осуществить поиск неконфиденциальных данных, деавторизовать авторизованного пользователя.
- Выполнить анализ разработанного приложения с точки зрения: политики безопасности операционной системы; политики безопасности компонентов приложения и их взаимодействия между собой; сетевой политики безопасности; безопасности конфиденциальности данных.
- Оформить отчёт о проделанной работе. 
2 РЕЗУЛЬТАТЫ
Для выполнения лабораторной работы было разработано приложение asp.netmvc.
В приложении реализована регистрация и авторизация пользователей, возможность добавлять комментарии, а также изменять конфиденциальную информацию пользователя.
Проанализировав работу приложения, были выявлены некоторые плюсы, а также уязвимости данного приложения с точки зрения безопасности системы.
Плюсы:
- каждому пользователю выдается своя роль, относительно которой ему доступны или недоступны действия, связанные с изменением конфиденциальной информацией пользователя.
- Ограничение доступа с AuthorizeAttribute
ASP.NET MVC поставляется с атрибутом фильтрацииAuthorizeAttribute, который предоставляет простой и качественный способ для создания правил авторизации. Когда этот атрибут используется в сочетании со схемой аутентификации, он может обеспечивать подтверждение того, что только определенные пользователи имеют доступ к конкретным действиям контроллера.
Простейшее применение AuthorizeAttribute требует только аутентификации текущего пользователя:
[Authorize]
publicActionResult About()
{
return View();
}
Не аутентифицированным пользователям будет запрещен доступ к этому действию, но любому аутентифицированному пользователю доступ будет разрешен.
Чтобы ограничить действие далее, мы можем указать пользователей или роли, которые требуетAuthorizeAttribute. Эти пользователи или роли передаются в атрибут в виде списка строк, разделенных запятыми и содержащих имена пользователей или ролей с правами доступа:
[Authorize(Users = "admin")]
publicActionResult Admins()
{
returnView();
}
- защита от html-javascript.
Автоматическаявалидация ввода.
По умолчанию ASP.NET MVC автоматически проверяет данные запроса, чтобы гарантировать, что они не содержат потенциально опасной разметки. Однако это не всегда желательно. Иногда у вас будут приложения, которые требуют от пользователя ввести HTML-разметку (или другие данные, которые валидатор может принять за HTML, например, XML), поэтому такое поведение можно выключить.
[ValidateInput(false)]
publicViewResult Save(CommentInput form)
{
returnView(form);
}
Когда для него установлено значениеfalse , атрибут ValidateInputуказывает ASP.NET пропустить обычную проверку на наличие вредоносного содержимого. Без этого атрибута будет проведена валидация по умолчанию: проверка строки запроса, формы и куки на наличие вредоносного содержимого. Если этот атрибут не отменяет валидацию, пользователи, отправляющие небезопасные входные данные, увидят исключение, показанное на рисунке.

Рисунок 1 – Ошибка сервера в приложении
- Защита подделка межсайтовых запросов
Применение к действию ValidateAntiForgeryTokenAttribute требует, чтобы входные данные сопровождались специальным маркером, который гарантирует, что они поступают только от отвечающего приложения. За атрибутом обязательно должен следовать специальный вспомогательный метод HTML, который выводит маркер в форме в HTML-источнике.
В следующем коде показан атрибут, примененный к нашему уязвимому действию:
[ValidateAntiForgeryToken]
publicViewResult Save(InputModel form)
{
returnView(form);
}
В нашем представлении мы можем использовать вспомогательный метод AntiForgeryToken:
<form method="post" action="/home/save">
@Html.AntiForgeryToken()
<label for="Name">Name:</label>
@Html.TextBox("Name")
<button type="submit">Submit</button>
</form>
Когда установлены маркер и атрибут, отправленные с сайта данные, имеющие и маркер, и атрибут, будут приняты, но взломщики не смогут формулировать XSRF-атаки.
- При появлении в работе приложения исключения пользователь получить страницу с ее описанием.
Создадим исключение при работе приложения.
publicActionResult Index()
{
List<Comment> c = repository.getAllComments();
ViewBag.Comments = repository.getAllComments();
thrownewDataException();
returnView();
}
Пользователь получит следующую страницу

Рисунок 2 – Исключение при работе приложения
Asp.netmvc позволяет определить страницу, которая будет отображена при появлении того или иного исключения.

Уязвимости:
- возможность подбора пароля простым перебором неограниченное количество раз, потому что нет защиты на то, что при нескольких попытках авторизоваться, пользователь блокируется на некоторое количество времени;
- хранение паролей в открытом виде в базе данных;
- приложение самостоятельно не может гарантировать передачу данных по защищенному каналу, поэтому сервер приложений должен настроен должным образом, чтобы при работе с приложением использовался протокол SSLHTTP.

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