Ильенко Федор Вячеславович

Факультет: компьютерных наук и технологий

Кафедра: компьютерной инженерии

Специальность: «Системное программирование»

Тема магистерской работы: «Безопасность web-сайтов»

Научный руководитель: к.т.н., доцент Приходько Татьяна Александровна

Реферат по теме выпускной работы

Содержание

Введение

Разработка новых ВЕБ-приложений часто фокусируется на опыте заказчика и наиболее часто она сводится к обеспечению необходимой функциональности и качественного интерфейса для пользователей. Достаточно часто внимание уделяется и системе серверной интеграции приложений. Вопросами обеспечения безопасности в то же время часто пренебрегают или откладывают их решение на последнюю стадию - стадию тестирования приложения.

Многолетний опыт различных компаний показывает, что обеспечение безопасности ВЕБ-приложений должно начинаться еще на ранних стадиях процесса проектирования и разработки приложений [1].

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

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

При разработке ВЕБ-приложений необходимо выполнить следующие задачи:

1. Актуальность

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

Тестирование безопасности - это тип тестирования, основное предназначение которого – убедится, что конфиденциальные данные останутся конфиденциальными, а пользователь системы сможет сделать только то, что ему положено по правам доступа. Оценка защищенности Web-приложений может выполняться как с использованием методики «черного ящика», так и путем анализа исходных кодов. Второй способ более эффективен, но и более трудоемок. Метод «черного ящика» заключается в проведении работ по оценке защищенности информационной системы без предварительного получения какой-либо информации о ней со стороны владельца. Метод «белого ящика» заключается в том, что для оценки защищенности информационной системы используются все необходимые данные о ней, включая исходный код приложений.

2. Постановка задачи

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

Более подробно они рассмотрены в разделе 3.

В рамках магистерской работы планируется получение актуальных научных результатов по следующим направлениям:

3. Обзор исследований и разработок

Среди тестируемых ресурсов встречаются веб-приложения, написанные на различных языках программирования; при этом для каждого языка характерен свой набор наиболее значимых уязвимостей (по данным исследования группы Positive Technologies [2]. Большинство разработчиков предпочитают PHP: на нем написано 63% всех протестированных сайтов. Значительны доли ASP.NET (19%) и Java (14%). Остальные языки программирования встречаются гораздо реже. Распределение сайтов — участников тестирования по лежащему в их основе языку программирования визуально представлено на рис. 1.

Рис. 1. Статистика использования языков программирования при создании динамических Web-страниц

Лично у меня работа с сайтами началась еще на третьем курсе. Вместе с научным руководителем мы разрабатывали портал для первокурсников факультета КНТ. В планах это была своего рода библиотека методических обеспечений по все специальностям и направлениям факультета. На момент написания магистерской работы этот ресурс еще не окончен. Его планируется запустить и разместить на хостинге официального сайта факультета. Так как данный проект считается довольно перспективным и полезным для студентов, ожидается огромное количество посещений и в связи с этим вероятность нападения вероятность потери информации увеличивается. Поэтому прежде чем выкладывать его на всеобщий доступ целесообразно побеспокоится о безопасности самого ресурса и проверить его на наличие уязвимостей. Для этого встала задача изучить типы уязвимостей и написать собственный сканер для тестирования сайта.

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

CSRF (англ. Сross Site Request Forgery — «Подделка межсайтовых запросов», также известен как XSRF) — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника). Для осуществления данной атаки, жертва должна быть авторизована на том сервере, куда отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, который не может быть проигнорирован или подделан атакующим скриптом.

Это атака, при которой злоумышленник пытается вынудить браузер жертвы создать запрос к целевому серверу, втайне от самой жертвы. Схематично это предствалено на рисунке 2 [3].

Рис. 2 Схема получения информации от пользователя
(анимация: 45 кадров, 5 циклов повторений, 96 килобайта)

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

Опасность CSRF в том, что данное поведение браузеров и всего HTTP протокола является нормальным. К примеру, ведь нормально то, что сайт может на своих страницах содержать картинки с другого сайта. А браузеру неизвестно заранее что именно пытаются заставить его загрузить, действительно картинку, или под видом данной загрузки будет выполнено какое то действие на целевом сайте.

XSS (англ. Сross Site Sсriрting — «межсайтовый скриптинг») — тип атаки на уязвимые интерактивные информационные системы в вебе, внедрение выполняемых на клиентском компьютере вредоносных скриптов в выдаваемую системой страницу. Специфика подобных атак заключается в том, что для атаки на сервер в качестве средства атаки используется авторизованный на этом сервере клиент. К сожалению, межсайтовые скриптовые атаки происходят, в основном, потому, что разработчики не в состоянии обеспечить безопасный код [4].

4. Предотвращение Cross-Site сценариев атак

К счастью, провести XSS-атаку можно так же легко как и защититься от нее. Прежде всего, нужно думать о том, что вы пишите. Первое правило, которое нужно знать в любой веб-среде (будь то разработка, постановка задач, или производство) никогда не доверять данным, поступающим от пользователя или от любых других сторонних источников. Каждый бит данных должны быть проверен на входе. Это золотое правило предупреждения XSS [9].

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

4.1 Проверка достоверности данных

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

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

 ( ?php
// проверка номера телефона Украины
if (preg_match('/^((1-)?\d{3}-)\d{3}-\d{4}$/', $phone)) 
{
    echo $phone . " это правильный формат.";
}

 

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

4.2 Санитарная обработка данных (нормализация)

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

( ?php
// удаление HTML из комментариев
$comment = strip_tags($_POST["comment"]);
 

Иногда, проверки данных и санитарная обработка / нормализация могут идти рука об руку.

( ?php
// нормализация и проверка телефона США
$phone = preg_replace('/[^\d]/', "", $phone);
$len = strlen($phone);
if ($len == 7 || $len == 10 || $len == 11) {
    echo $phone . " это правильный формат.";
}

4.3 Экранирование данных

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

( ?php
echo "Вы искали: " . htmlspecialchars($_GET["query"]);

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

4.4 Использование функции secureInnerData

Использование стандартной функции secureInnerData, позволяет защитить от атак типа SQL injection и XSS. Чаще всего их проводят используя GET или POST запросы которые не фильтруются на стороне сервера. Используя данную функцию в качестве фильтра входящих данных, вы сможете частично обезопасить себя [8].

Исходный код функции secureInnerData

Алгоритм предельно простой:

Допустим нам надо отфильтровать параметр data который передается на сервер с помощью GET запроса. Выглядеть фильтрация будет так:

$data=secureInnerData($_GET['data']);

О реализации

rtrim(), ltrim() удаляют из конца и начала строки соответственно:

" " (ASCII 32 (0x20)), символ пробела.

"\t" (ASCII 9 (0x09)), символ табуляции

"\n" (ASCII 10 (0x0A)), символ перевода строки.

"\r" (ASCII 13 (0x0D)), символ возврата каретки.

"\0" (ASCII 0 (0x00)), NUL-байт.

"\x0B" (ASCII 11 (0x0B)), вертикальная табуляция.

htmlspecialchars() преобразует специальные символы в HTML сущности:

'&' (амперсанд) преобразуется в '&'

'"' (двойная кавычка) преобразуется в '"' when ENT_NOQUOTES is not set.

''' (одиночная кавычка) преобразуется в ''' только в режиме ENT_QUOTES.

'<' (знак "меньше чем") преобразуется в '<'

'>' (знак "больше чем") преобразуется в '>'

Таким образом, можно обезопасить себя и свои данные от данного типа атак.

Выводы

В работе была проведена классификация самых распространенных WEB-уязвимостей. Результаты показали, что среди выявленных уязвимостей на наибольшем количестве сайтов лидером является — Cross-Site Request Forgery (CSRF).

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

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

1. Возможность вынудить жертву перейти на страницу с дополнительным кодом. Или возможность модификации злоумышленником часто посещаемых жертвой страниц (как говорится, если гора не идет к Магомету, то...).
2. Отсутствие защиты от CSRF на целевом сайте.
3. Пользователь в момент атаки должен быть авторизован для действия, которое мы хотим выполнить от его имени.

И на основе этих требований необходимо попытаться построить защиту.

При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: декабрь 2013 года. Полный текст работы и материалы по теме могут быть получены у автора или его руководителя после указанной даты.

Список источников

1. Безопасность web-приложений http://www.fortconsult.net/ru/ваши-трудности/безопасность-веб-приложений
2. Positive Technologies – безопасность,консалтинг http://www.ptsecurity.ru
3. Уязвимость CSRF. Введение http://intsystem.org/768/learn-about-csrf-intro/
4. Издательство БХВ-Петербург, Тактика защиты и нападения на Web-приложения – 2005. – 432с
5. Уязвимости | информационный портал о безопасностиhttp://www.securitylab.ru/vulnerability
6. Козлов Д. Д., Петухов А. А. "Методы обнаружения уязвимостей в web- приложениях" / Программные системы и инструменты: тематический сборник ф-та ВМиК МГУ им. Ломоносова N 7. П/р Л.Н. Королева. М: Издательский отдел ВМиК МГУ. Изд-во МАКС Пресс, 2006 г.
7. Межсайтовый_скриптинг http://ru.wikipedia.org/wiki/Межсайтовый_скриптинг
8. Защита от SQL injection и XSS (функция secureInnerData ) http://n3info.blogspot.com/2013/05/sql-injection-xss-secureinnerdata.html
9. XSS атака сайта и способы защиты. Как сделать и проверить XSS уязвимость http://consei.ru/xss-ataka-sajta-i-sposoby-zashhity/