Основные типы web – уязвимостей

Введение

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

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

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

Цель работы:

Построение организационной модели обеспечения информационной безопасности web-ресурсов в сети интернет.

Задачи работы:

Анализ web-уязвимостей и их ранжирование по критерию ущерба;

Анализ существующих моделей защиты от web-уязвимостей;

Составление перечня актуальных web-уязвимостей и составление перечня организационных мер защиты;

Разработка Положения по обеспечению информационной безопасности при использовании сети Интернет.

































Глава 1. Общее описание web – уязвимостей, связанных с ними web – атак и методов защиты

1.1. Основные типы web – уязвимостей

В этом разделе мной были рассмотрены основные типы уязвимостей web-приложений согласно OWASP Top 10-2017, а именно:

-  Внедрение кода (SQL инъекция)

-  Некорректная аутентификация и управление сессией

- Межсайтовый скриптинг (XSS)

-  Нарушение контроля доступа

-  Небезопасная конфигурация

-  Утечка чувствительных данных

-  Небезопасная десериализация

-  Внедрение внешних XML-сущностей (XXE)

-  Использование компонентов с известными уязвимостями

-  Недостаточное журналирование и мониторинг

1.1.1. SQL – инъекция

SQL – Почти любой источник данных может быть вектором инъекции, переменными среды, параметрами, внешними и внутренними веб-службами и всеми типами пользователей.  Инъекционные недостатки возникают, когда злоумышленник может отправлять враждебные данные интерпретатору. 

Инъекционные недостатки очень распространены, особенно в устаревшем коде.  Инъекционные уязвимости часто обнаруживаются в запросах SQL, LDAP, XPath или NoSQL, командах ОС, синтаксических анализах XML, заголовках SMTP, языках выражений и запросах ORM.  Инъекционные недостатки легко обнаружить при изучении кода.  Сканеры и фьюзеры могут помочь злоумышленникам найти недостатки в инъекциях.3 Поскольку злоумышленник корректирует свой SQL-запрос, который выполняется СУБД, каждая из которых имеет свои нюансы и поддерживает функции, которые могут не поддерживать другие. Инъекция может привести к потере данных, коррупции или раскрытию информации несанкционированным сторонам, потере подотчетности или к отказу в доступе.  Инъекция иногда может привести к полному поглощению хозяина.  Влияние бизнеса зависит от потребностей приложения и данных. Известно, что большинство систем управления базами данных используют следующие функции:

Таблица 1. Стандартные функции СУБД.

Это стандартные функции, наибольший интерес из них представляют две функции: SELECT и UNION. В данном случае, функция SELECT представляет собой функцию вывода, а функция UNION позволяет объединять вывод двух и более результатов. Дабы внедрить SQL – запрос, изначально необходимо удостовериться, что web – сайт не защищен. Для этого необходимо передавать все возможные параметры, под ними понимаются:3

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

2. Все параметры, передаваемы через строку URL. Параметры находятся в строке адреса после символа “?” и имеют вид имя=значение. Параметры разделяются между собой символом “&”.

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

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

1. Обнаружение SQL – уязвимости.

При обнаружении SQL – уязвимости в скрипте, возможны два случая, а именно когда вывод ошибок включен и когда вывод ошибок выключен.

1.1. Вывод ошибок включен.

Например, скрипт написан таким образом, что в случае ошибки в SQL – запросе в браузер выводится текст этой ошибки и текст запроса. В этом случае, составить правильный SQL – запрос для злоумышленника не составит труда. При передаче параметра id=666’ некоторому скрипту http://test/1.php вывелась следующая ошибка:

http://test/1.php?id=666’

Ошибка при работе с базой данных:

Select * from test1 where id=’666’’

В данной ситуации злоумышленник может сделать сразу же несколько выводов:

- Кавычки не фильтруются системой;

- Значение параметра id используются в скрипте в SQL – запросе без какой-либо фильтрации;

- SQL-запрос имеет вид : select * from test1 where id=’$id’

1.2. Вывод ошибок выключен.

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

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

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

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

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

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

После того, как web – уязвимость обнаружена, наступает второй шаг, сбор информации о системе.

2. Сбор информации о системе.

Для дальнейшей реализации атаки, злоумышленнику необходимо собрать как можно больше информации о системе, а именно:

1. Имя текущей базы данных, всех доступных баз данных;

2. Имена таблиц;

3. Имена полей;

4. Имя пользователя и пароль, от имени которых происходит обращение к базе данных.

Проще всего посчитать количество полей. Для этого злоумышленнику необходимо  два SQL – запроса, объединенные командой UNION. Следовательно, они будут выполнены, только если оба возвращают одинаковое количество полей и типы соответствующих полей имеют совместимый  тип данных.

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

Имя пользователя не составит труда вычислить, поскольку при создании большинства корректных запросов на рекламных сайтах, сайтах компаний, имя пользователя отображается вместе с его записью. Так, например http://test1.ru/?id=1+union+news=1,user  тем самым, злоумышленник получает информацию о том, кто опубликовал запись.

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

3. Использование уязвимости.

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

1. Удаление таблицы: DROP TABLE*Имя таблицы.

2. Удаление данных из таблицы: DELETE FROM * Имя таблицы.

3. Зная поля таблицы, можно обновить либо добавить записи с помощью команд UPDATE и INSERT.

Способы защиты:

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

$id= (int)$id; $total= (float)$total;

Вместо этого можно вставить систему слежения за тестированием на SQL – инъекцию.

if ((string)$id<> (string) (int)$id) {

die (‘ops’);

}

2. Для строковых параметров, которые не используются в like, regexp и т.д., экранируем кавычки.

$str=addslashes ($str); 

так же возможно,

mysql_escape_string ($str)

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

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

1.1.2 Некорректная аутентификация и управление сессией

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

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

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

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

1. Разрешает автоматические атаки, такие как заполнение учетных данных, когда у злоумышленника есть список допустимых имен пользователей и паролей. 

2. Разрешает грубую силу или другие автоматические атаки.

3. Разрешает использование по умолчанию, слабых или известных паролей, таких как «Пароль1» или «admin / admin».

4. Использует слабые или неэффективные процессы восстановления учетных данных и забытых паролей, такие как «ответы на основе знаний», которые нельзя сделать безопасными.

5. Использует простые текстовые, зашифрованные или слабо хешированные пароли.

Способы защиты:

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

2. Не отправляйте и не развертывайте с учетными данными по умолчанию, особенно для пользователей admin.

3. Внедрение проверок с низким паролем, таких как проверка новых или измененных паролей на список 10000 наихудших паролей.

4. Обеспечьте, чтобы регистрация, восстановление учетных данных и пути API были усилены против атак на счету, используя одни и те же сообщения для всех результатов.

5. Зарегистрируйте все отказы и администраторы предупреждений, когда обнаружены учетные данные, грубая сила или другие атаки.

6. Используйте серверный, безопасный, встроенный диспетчер сеансов, который генерирует новый случайный идентификатор сеанса с высокой энтропией после входа в систему.

7. Идентификаторы сеансов не должны находиться в URL-адресе, быть надежно сохранены и аннулированы после выхода из системы, бездействия и абсолютных тайм-аутов.

1.1.3. Межсайтовый скриптинг (XSS)

Межсайтовый скриптинг (Cross Site Scripting) тоже является одной из часто встречаемых web – уязвимостей. Автоматизированные инструменты могут обнаруживать и использовать все три формы XSS, а также имеются свободно доступные схемы использования.

XSS является второй наиболее распространенной проблемой в топ-10 OWASP и находится примерно в двух третях всех приложений.  Автоматизированные инструменты могут обнаруживать некоторые проблемы XSS автоматически, особенно в таких зрелых технологиях, как PHP, J2EE / JSP и ASP.NET. Суть этой уязвимости в том, что данные, веденные одним пользователем и выведенные другим, могут содержать не только текстовую информацию, но и JavaScript, ссылки на другие документы или иные потенциально опасные данные.

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

Существуют три формы XSS, обычно ориентированные на браузеры пользователей:

1. Reflected XSS: приложение или API включает в себя неутвержденный и неэкранированный пользовательский ввод как часть вывода HTML.  Успешная атака может позволить злоумышленнику выполнить произвольный HTML и JavaScript в браузере жертвы.  Как правило, пользователю необходимо взаимодействовать с какой-либо вредоносной ссылкой, которая указывает на страницу, контролируемую атакующем, например, сайты вредоносных веб-сайтов, рекламу и т. д.

2. Хранимый XSS: приложение или API хранит неанитированный пользовательский ввод, который позже рассматривается другим пользователем или администратором.  Хранимый XSS часто считается высоким или критическим.

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

DOM XSS: фреймворки JavaScript, одностраничные приложения и API, которые динамически включают данные, управляемые злоумышленниками, на страницу, уязвимы для DOM XSS.  В идеале приложение не отправляет данные, управляемые атакующим, в небезопасные API JavaScript.

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

Одним из основных методов защиты в данном случае является фильтрация:

1.Вырезание символов < и >. В таком случае смысл сообщения может поменяться.

2. Блокирование сообщений с этими символами. Этот метод не рекомендуется, поскольку могут быть заблокированы добросовестные пользователи.

3. Приведение символов < и > к безопасному виду. Имеется в виду замена этих символом при выводе на соответствующие последовательности < и >. Этот метод более популярен, поскольку не изменяет смысл сообщения.

1.1.4 Нарушение контроля доступа

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

1. Ссылки имеются у пользователей без права доступа.

2. Права на доступ выдаются в хаотичном порядке. Правило необходимость – доступ отсутствует.

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

1. Для того чтобы получить доступ к административной панели какой-либо системы, необходимо зайти по данному адресу http://test/admin-21sas112.php

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

- URL не рассматривается как информация, которая может содержать конфиденциальные сведения;

- URL может попасть в log-файлы HTTP-сервера, прокси-сервера, откуда злоумышленник может его достать.

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

2. Система аутентификации со стороны заказчика

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

3. Аутентификация с использованием только пароля.

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

Способы защиты:

1. Первое и самое главное правило: запрещено всё, что не разрешено.

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

3. Запрещение выполнение команд CREATE TABLE, ALTER TABLE, DROP TABLE.

4. Разрешить удаленное подключение, защищенное с помощью сетевого экрана. Допустим, соединение принимается на порт 3306. Необходимо прописать запрет на доступ к этому порту для всех и разрешить доступ только с определенных IP-адресов, с которых работают администраторы.

5. Использование туннелирования, как итог данные передаются в зашифрованном виде.

6. Использование сложных паролей, как для администратора, так и на доступ к системе управления базами данных.

Web – ресурс уязвим, если:

1. Для прямых ссылок отсутствует стадия проверки прав пользователей к ресурсам, которые они запросили.

2. Благодаря косвенной ссылке, можно перейти к основной, благодаря изменению параметра в запросе.

Обычно, разработчик Web – ресурса не задумывается о возможности появления данной уязвимости, соответственно стадия проверки прав пользователей и запрошенных ресурсов отсутствует.

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

1.1.5 Небезопасная конфигурация

Атакующие часто пытаются использовать неполученные недостатки или получать доступ к учетным записям по умолчанию, неиспользуемым страницам, незащищенным файлам и каталогам и т. Д., Чтобы получить несанкционированный доступ или знание системы.

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

Приложение может быть уязвимым, если приложение:

1. Отсутствует соответствующее упрощение безопасности в любой части стека приложений или неправильно настроенные разрешения для облачных сервисов;

2. Ненужные функции включены или установлены (например, ненужные порты, службы, страницы, учетные записи или привилегии);

3. Учетные записи по умолчанию и их пароли по-прежнему включены и не изменяются;

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

5. Сервер не отправляет заголовки безопасности или директивы или они не настроены на защищенные значения;

6. Параметры безопасности на серверах приложений, инфраструктурах приложений (например, Struts, Spring, ASP.NET), библиотек, баз данных и т.д.;

7. Использует слабое или неэффективное восстановление учетных данных и процессы забытого пароля, такие как «ответы на основе знаний», которые нельзя сделать безопасными;

8. Сервер не отправляет заголовки безопасности или директивы или они не настроены на защищенные значения.

9. Без согласованного, повторяемого процесса настройки безопасности приложений системы подвергаются более высокому риску.

Способы защиты:

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

2. Минимальная платформа без лишних функций, компонентов, документации и образцов.  Удалите или не устанавливайте неиспользуемые функции и фреймворки.

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

4. В частности, просмотрите разрешения облачного хранилища.

5. Сегментированная архитектура приложений, обеспечивающая эффективное, безопасное разделение между компонентами или арендаторами, с сегментацией, контейнерами или облачными группами безопасности (ACL).

1.1.6 Утечка чувствительных данных

Вместо того, чтобы атаковать криптонаправленные атаки, злоумышленники крадут ключи, выполняют атаки «человек в середине» или крадут четкие текстовые данные с сервера, находясь в пути, или от клиента пользователя, например,  браузер.  Обычно требуется ручная атака.  Раньше восстановленные базы данных паролей могли быть грубо вынуждены графическими процессорами (графическими процессорами). Данная уязвимость вытекает из человеческого фактора. Web- сервер уязвим, если:

1. Конфиденциальные данные хранятся в текстовом виде, в долгосрочной перспективе, а так же созданы резервные копии этих данных.

2. Данные передаются в незашифрованном виде, как внутри предприятия, так и за его пределами.

3. Администратор сервера использует старые и слабые криптографические алгоритмы.

4. Использование слабых криптоключей, а так же использование одного ключа для всех типов данных. 

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

Способы защиты:

1. Определите, какие данные чувствительны в соответствии с законодательством о конфиденциальности, нормативными требованиями или потребностями бизнеса.

2. Обеспечьте наличие современных и надежных стандартных алгоритмов, протоколов и ключей;  используйте правильное управление ключами.

3. Шифруйте все данные в пути с помощью защищенных протоколов, таких как TLS с совершенными шифрами прямой секретности (PFS), приоритетом шифрования сервером и безопасными параметрами.

1.1.7 Небезопасная десериализация

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

1. Атаки, связанные с объектами и структурой данных, при которых злоумышленник изменяет логику приложения или выполняет произвольное удаленное выполнение кода, если для приложения доступны классы, которые могут изменять поведение во время или после десериализации;

2. Типичные атаки подделки данных, связанные с контролем доступа, в которых используются существующие структуры данных, но изменяется содержимое.  

Сериализация может использоваться в приложениях для:

1. протоколов удаленного и межпроцессного взаимодействия (RPC / IPC);

2. протоколов веб-сервисов, брокеров сообщений;

3. кэширование / сохранение;

4. базы данных, кэш-серверы, файловые системы;

5. HTTP-файлы cookie, параметры формы HTML, токены аутентификации API.

Способы защиты:

1. Запретить принимать сериализованные данные из ненадежных источников или использовать средства сериализации, разрешающие только примитивные типы данных.

2. Выполнение проверок целостности, например цифровые подписи, для предотвращения создания враждебных данных или их несанкционированная модификация.

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

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

5. Исключение и сбои десериализации журнала, если тип ввода не является ожидаемым, или при десериализации возникает исключения.

6. Контроль входящих и исходящих сетевых подключений из контейнеров или серверов, которые десериализируются.

7. Мониторинг десериализации, оповещение в случае, если пользователь десериализует постоянно.

1.1.8 Внедрение внешних XML – сущностей (XXE)

Данная уязвимость может привести к потере конфиденциальной информации,  получению злоумышленником исходных кодов приложения, конфигурации, файлов и т.п. Злоумышленник может выполнить HTTP – запрос в пределах атакуемой сети.

XXE – Инъекция – это атака на приложение, либо процессор, которые выполняют анализ вводимых XML. Злоумышленник может использовать уязвимые XML-процессоры, в случае если они могут загрузить XML или включить вредоносное содержимое в XML-документ, используя уязвимый код, зависимости или интеграции.

Web – сервисы на основе XML или последующие интеграции могут быть уязвимы для атаки в случае если:

1. Web - сервис принимает XML напрямую или загружает XML из ненадежных источников, или вставляет ненадежные данные в XML-документы, которые затем анализируются процессором XML.

2. XML-процессор в web – службах, основанных на приложении или на основе SOAP, имеет определения типа документа (DTD).

3. Если приложение использует SAML для обработки удостоверений в рамках федеративной безопасности или единого входа (SSO).  SAML использует XML для утверждения идентификаторов и может быть уязвимым.

4. Если приложение использует SOAP до версии 1.2, оно, вероятно, подвержено атакам XXE, если XML-объекты передаются в структуру SOAP.

Способы защиты:

1. Исключить сериализацию конфиденциальных данных;

2. Обновить все XML – процессоры и библиотеки, используемые базовой операционной системой.

3. Отключить внешний XML – объект и обработку DTD во всех анализаторах XML.

4. Включить «белый список» на стороне сервера, фильтрацию для предотвращения враждебных данных в XML – документах

1.1.9. Использование компонентов с известными уязвимостями

Человеческий фактор полностью влияет на данную уязвимость. Существует две задачи исключающие наличие данной уязвимости:

1. Использование самых последних версий модулей, рекомендованных на открытых/закрытых площадках.

2. Недопущение работы с малоизвестными, либо не актуальными модулями. 

1.1.10 Недостаточное журналирование и мониторинг

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

	

1.2 Основные типы атак web-приложений

Здесь мы подробно разберем наиболее часто встречающиеся, на мой взгляд, атаки на web – сервер:5

- Полный перебор (Brute Force)

- DOS и DDOS

- Спуфинг пакетов

- IP-спуфинг

- Заливка Shella

1.2.1 Полный перебор (Brute Force)

Используя известные БД, производится перебор логинов и паролей пользователей, в этом суть атаки Brute Force. Автоматизированный процесс проб и ошибок, использующийся для определения имени пользователя, пароля, номера кредитной карточки, ключа шифрования и т.д., называется подбором. Минусом большинства систем, который активно использует злоумышленник, заключается в том, что пользователи используют слабые пароли и легкоугадываемые парольные фразы. Злоумышленник используя миллионы комбинаций символов, с помощью словаря, получает доступ к системе и может использовать учетную запись. Атака считается успешно выполненной.



Рис.4 Пример настроенного программного обеспечения для перебора паролей

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

На сегодняшний день существует два вида подбора:

1.Прямой – используются различные варианты пароля для одного имени пользователя. Например:

Имя пользователя = Volodya

Пароли = qwerty, 01234, bobik, tuzik, czar

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

Имена пользователей = Pavel, Denis, Oleg, Sveta, Vika09

Пароль = poiuyt

Эта атака, не смотря на свою простоту в использовании  занимает огромное количество времени. Исключить данную атаку очень просто:

1. Увеличение тайм-аута повторного входа.

2. Привязка аккаунта к IP-адресу.

3. Шифрование всех паролей.

1.2.2 DOS и DDOS

DOS (Denial of Service) – это отказ в обслуживании, в основе которой  лежит техника повышения нагрузки на целевую систему. Когда сервер принимает пакеты, все его компоненты участвуют в процессе, делая прием пакета успешным. Сетевая карта исследует все фреймы Ethernet, предназначенные для нее, выравнивает данные и передает их драйверу сетевой карты, который применяет собственные механизмы обработки данных и отправляет их операционной системе, которая в свою очередь передает их приложению. Все компоненты, вовлеченные в обработку пакетов, могут быть подвержены какой-либо уязвимости, а DDoS-атака изобретена как раз для того, чтобы эксплуатировать одну или несколько уязвимостей для проникновения в систему.

Суть DOS атак сводится к основам протокола TCP/IP, который использует рукопожатие между отправителем и принимающей стороной.



Рис.5 Рукопожатие TCP в штатном режиме и при атаке потоком SYN – пакетов.

1. Когда отправитель хочет начать обмен данными, он отправляет SYN – пакет со своим IP – адресом в качестве источника и IP-адресом получателя в качестве цели.

2. Получатель отвечает пакетом SYN-ACK. 

3. Отправитель подтверждает свое намерение при помощи пакета ACK. 

4.Теперь отправитель и получатель имеют гарантию того, что они могут начать обмен данными друг с другом.

5. При дальнейшем общении, отправитель начинает передачу самих данных в виде небольших фрагментов.

6. Для каждого принято пакета с данными получатель отправляет пакет ACK в ответ.

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

На сегодняшний день существует множество методов для осуществления таких атак:

1. Массовая рассылка пакетов с разными MAC-адресами (MAC flood)

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

2.Массовая рассылка SYN-пакетов (SYN flood)

Злоумышленник рассылает множество SYN-пакетов. При приеме SYN-ACK от целевой системы, атакующая система не отправляет ACK, а вместо этого отправляет еще больше SYN-пакетов. Это заставляет TCP/IP стек считать, что происходит перегрузка или отключение сети и ожидать заданный промежуток времени. Таким образом, сетевой стек поддерживает в полуоткрытом состоянии множество соединений в ожидании пакетов ACK.

В другом типе атаки с использованием SYN-пакетов, эти пакеты отсылаются с подмененным адресом отправителя, который заменяется на целевой адрес, на который будут отправляться пакеты SYN-ACK. Поскольку система, расположенная по подмененному адресу никогда не отправляла пакет SYN, она никогда не отправит пакет ACK в ответ на этот пакет, а просто отбросит его. Целевая система не ожидает такого поведения и ожидает пакета ACK, поддерживая соединение в полуоткрытом состоянии.

3. Атака с помощью ping – пакетов (ping of death) – поток специально сформированных ping – пакетов посылается целевой системе. Поскольку стек TCP может отвечать только на определенный тип ping – пакетов, он не может ответить на специально сформированные пакеты и затрачивает ресурсы на их обработку.

4. Атаки с помощью установления соединений TCP – является усовершенствованной атакой массовой рассылки SYN-пакетов, разница в них состоит в том, что в данном случае трехэтапное рукопожатие TCP производится в полном объеме. При этом не производится подмена адресов, не игнорируются ACK-ответы, а просто устанавливаются TCP-соединения, посредством которых не передается никаких данных. По этой причине соединения остаются активными до истечения времени ожидания: большое количество установленных соединений приводит к отказу в обслуживании со стороны атакуемой системы.

5.Атака ICMP-запросами с измененными адресами (Smurf Attack) – атакующий  посылает поток ping – запросов на широковещательные IP-адреса. При этом адрес источника пакетов подменен на адрес атакуемой системы. Следов.......................