[WAPT]

Оглавление
Аудит информационной безопасности ........................................................................ 2

Виды аудитов ................................................................................................................. 2

Этапы аудита безопасности .......................................................................................... 3
Структура протокола ..................................................................................................... 5
Стартовая строка ............................................................................................................ 6
Методы .......................................................................................................................... 7

Заголовки HTTP ............................................................................................................ 10

Веб –сервер.................................................................................................................. 11
Классификаторы уязвимостей..................................................................................... 13
OWASP .......................................................................................................................... 14
Классификация недостатков CWE ............................................................................... 15

Общие сведения о пентесте

Познакомившись со средой, следующим логичным шагом будет
изучение общей теории пентеста.
Pentest, penetration testing или тестирование на проникновение — метод
оценки безопасности компьютерных систем, сетей или приложений
средствами моделирования атаки злоумышленника. Процесс включает
в себя несколько этапов о которых мы поговорим позднее и направлен
на выявление потенциальных уязвимостей, которые могут
спровоцировать некорректную работу целевой системы, либо полный
отказ в обслуживании. Анализ ведется с позиции потенциального
атакующего и может включать в себя активное использование
уязвимостей системы. Результатом работы является отчет, содержащий
в себе все найденные уязвимости системы безопасности, а также может
содержать рекомендации по их устранению. Основная цель пентеста —

1
оценить возможность осуществления атак на целевую систему и
спрогнозировать экономические потери в результате успешного
осуществления атаки. Пентест является неотъемлемой частью аудита
безопасности.

Аудит информационной безопасности

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

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

2
 Этапы аудита безопасности
Работы по аудиту безопасности включают в себя ряд последовательных
этапов, включающие в себя:
 инициирование процедуры аудита;
 сбор информации о цели;
 анализ данных аудита;
 выработку рекомендаций;
 подготовку аудиторского отчета.
На этапе инициирования процедуры аудита должны быть решены
следующие организационные вопросы:
 права и обязанности аудитора должны быть четко определены и
документально закреплены в его должностных инструкциях, а
также в положении о внутреннем (внешнем) аудите;
 аудитором должен быть подготовлен и согласован с
руководством план проведения аудита;
 в положении о внутреннем аудите должно быть закреплено, в
частности, что сотрудники компании обязаны оказывать
содействие аудитору и предоставлять всю необходимую для
проведения аудита информацию.
На этапе инициирования процедуры аудита должны быть определены
границы проведения обследования. План и границы проведения аудита
обсуждаются на рабочем собрании, в котором участвуют аудиторы,
руководство компании и руководители структурных подразделений.

Запомните самое главное, никогда не выходите за границы аудита,

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

3
Компетентные выводы относительно положения дел в компании с
информационной безопасностью могут быть сделаны аудитором только
при условии наличия всех необходимых исходных данных для анализа.
Первый пункт аудиторского обследования начинается с получения
информации об организационной структуре пользователей ИС и
обслуживающих подразделений. Назначение и принципы
функционирования ИС во многом определяют существующие риски и
требования безопасности, предъявляемые к системе. Далее, аудитору
требуется более детальная информация о структуре ИС. Это позволит
уяснить, каким образом осуществляется распределение механизмов
безопасности по структурным элементам и уровням функционирования
ИС.
Этапы сбора информации будут подробно описаны в следующих уроках.
Рекомендации, выдаваемые аудитором по результатам анализа
состояния ИС, определяются используемым подходом, особенностями
обследуемой ИС, состоянием дел с информационной безопасностью и
степенью детализации, используемой при проведении аудита. В любом
случае, рекомендации аудитора должны быть конкретными и
применимыми к данной ИС, экономически обоснованными,
аргументированными (подкрепленными результатами анализа) и
отсортированными по степени важности. При этом мероприятия по
обеспечению защиты организационного уровня практически всегда
имеют приоритет над конкретными программно — техническими
методами защиты. В то же время наивно ожидать от аудитора, в
качестве результата проведения аудита, выдачи технического проекта
подсистемы информационной безопасности, либо детальных
рекомендаций по внедрению конкретных программно — технических
средств защиты информации. Это требует более детальной проработки
конкретных вопросов организации защиты, хотя внутренние аудиторы
могут принимать в этих работах самое активное участие.

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

Наш курс посвящен очень узкой сфере, а именно аудиту безопасности

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

HTTP— протокол прикладного уровня передачи данных. Основой HTTP

является технология «клиент-сервер», то есть предполагается
существование:
 Потребителей (клиентов), которые инициируют соединение и
посылают запрос;
 Поставщиков (серверов), которые ожидают соединения для
получения запроса, производят необходимые действия и
возвращают обратно сообщение с результатом.

Структура протокола
Каждое HTTP-сообщение состоит из трёх частей, которые передаются в
указанном порядке:
 Стартовая строка (Starting line) — определяет тип сообщения;
 Заголовки (Headers) — характеризуют тело сообщения, параметры
передачи и прочие сведения;
 Тело сообщения (Message Body) — непосредственно данные
сообщения. Обязательно должно отделяться от заголовков пустой
строкой.

5
Тело сообщения может отсутствовать, но стартовая строка и заголовок
являются обязательными элементами.

Стартовая строка
Стартовые строки различаются для запроса и ответа. Строка запроса
выглядит так:

GET URI — для версии протокола 0.9;

Метод URI HTTP/Версия — для остальных версий.
Здесь:
 Метод— тип запроса, одно слово заглавными буквами. В версии
HTTP 0.9 использовался только метод GET, список методов для
версии 1.1 представлен ниже.

 URI определяет путь к запрашиваемому документу.

 Версия — пара разделённых точкой цифр. Например: 1.0.

 Чтобы запросить главную страницу codeby.net , клиент должен

передать строку (задан всего один заголовок):

GET / HTTP/1.0
Host: www.codeby.net
Стартовая строка ответа сервера имеет следующий формат:
HTTP/Версия КодСостояния Пояснение, где:
 Версия — пара разделённых точкой цифр, как в запросе;

 Код состояния (Status Code) — три цифры. По коду состояния

определяется дальнейшее содержимое сообщения и поведение
клиента;

6
  Пояснение (Reason Phrase) — текстовое короткое пояснение к
коду ответа для пользователя. Никак не влияет на сообщение и
является необязательным.

Например, стартовая строка ответа сервера на предыдущий запрос

может выглядеть так:

HTTP/1.0 200 OK

Методы
Метод HTTP — последовательность из любых символов, кроме
управляющих и разделителей, указывающая на основную операцию над
ресурсом. Обычно метод представляет собой короткое английское
слово, записанное заглавными буквами. Обратите внимание, что
название метода чувствительно к регистру.
Сервер может использовать любые методы, не существует
обязательных методов для сервера или клиента. Если сервер не
распознал указанный клиентом метод, то он должен вернуть статус 501
(Not Implemented). Если серверу метод известен, но он неприменим к
конкретному ресурсу, то возвращается сообщение с кодом 405 (Method
Not Allowed). В обоих случаях серверу следует включить в сообщение
ответа заголовок Allow со списком поддерживаемых методов.
Кроме методов GET и HEAD, часто применяется метод POST.
 OPTIONS - используется для определения возможностей веб-
сервера или параметров соединения для конкретного ресурса. В
ответ серверу следует включить заголовок Allow со списком
поддерживаемых методов. Также в заголовке ответа может
включаться информация о поддерживаемых расширениях.

Предполагается, что запрос клиента может содержать тело сообщения

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

7
Для того, чтобы узнать возможности всего сервера, клиент должен
указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут
также применяться для проверки работоспособности сервера
(аналогично ping) и тестирования на предмет поддержки сервером
протокола HTTP версии 1.1.
Результат выполнения этого метода не кэшируется.
 GET - используется для запроса содержимого указанного ресурса.
С помощью метода GET можно также начать какой-либо процесс.
В этом случае в тело ответного сообщения следует включить
информацию о ходе выполнения процесса.

Клиент может передавать параметры выполнения запроса в URI

целевого ресурса после символа «?»:

GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются идемпотентными
Кроме обычного метода GET, различают ещё:
 Условный GET — содержит заголовки If-Modified-Since, If-Match, If-
Range и подобные;

 Частичный GET — содержит в запросе Range.

Порядок выполнения подобных запросов определён стандартами

отдельно.
 HEAD - аналогичен методу GET, за исключением того, что в ответе
сервера отсутствует тело. Запрос HEAD обычно применяется для
извлечения метаданных, проверки наличия ресурса (валидация
URL) и чтобы узнать, не изменился ли он с момента последнего
обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных

ресурса с соответствующей информацией в кэше — копия ресурса
помечается как устаревшая.

8
  POST - применяется для передачи пользовательских данных
заданному ресурсу. При этом передаваемые данные включаются
в тело запроса. Аналогично с помощью метода POST обычно
загружаются файлы на сервер.

В отличие от метода GET, метод POST не считается идемпотентным, то

есть многократное повторение одних и тех же запросов POST может
возвращать разные результаты.
При результате выполнения 200 (Ok) в тело ответа следует включить
сообщение об итоге выполнения запроса. Если был создан ресурс, то
серверу следует вернуть ответ 201 (Created) с указанием URI нового
ресурса в заголовке Location.
 PUT - применяется для загрузки содержимого запроса на
указанный в запросе URI. Если по заданному URI не существует
ресурс, то сервер создаёт его и возвращает статус 201 (Created).
Если же был изменён ресурс, то сервер возвращает 200 (Ok) или
204 (No Content). Сервер не должен игнорировать некорректные
заголовки Content-*, передаваемые клиентом вместе с
сообщением. Если какой-то из этих заголовков не может быть
распознан или не допустим при текущих условиях, то необходимо
вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в

понимании предназначений URI ресурсов. Метод POST предполагает,
что по указанному URI будет производиться обработка передаваемого
клиентом содержимого. Используя PUT, клиент предполагает, что
загружаемое содержимое соответствует находящемуся по данному URI
ресурсу.
Сообщения ответов сервера на метод PUT не кэшируются.
 PATCH - аналогично PUT, но применяется только к фрагменту
ресурса.

9
  DELETE - удаляет указанный ресурс.

 TRACE - возвращает полученный запрос так, что клиент может

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

 CONNECT - преобразует соединение запроса в прозрачный TCP/IP-

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

Заголовки HTTP
Заголовки HTTP (Headers) — это строки в HTTP-сообщении, содержащие
разделённую двоеточием пару имя-значение. Формат заголовков
соответствует общему формату заголовков текстовых сетевых
сообщений ARPA. Заголовки должны отделяться от тела сообщения хотя
бы одной пустой строкой. Эта часть HTTP протокола одна из самых
интересных для пентестера, так как большинство манипуляций
происходит именно с хидерами.
Все заголовки разделяются на четыре основных группы:
 General Headers (рус.Общие заголовки) — используются в
запросах и ответах.

 Request Headers (рус. Заголовки запроса) — используются только в

запросах.

 Response Headers (рус. Заголовки ответа) — используются только в

ответах.

 Entity Headers (рус. Заголовки сущности) — сопровождают каждую

сущность сообщения. Используются в запросах и ответах.

С полным перечнем заголовков вы сможете ознакомиться в методичке

по курсу.

10
 Веб –сервер
Немного освежив память в части работы протокола HTTP, необходимо
переходить к серверной части.
Веб-сервер — сервер, принимающий HTTP-запросы от клиентов, обычно
веб-браузеров, и выдающий им HTTP-ответы, как правило, вместе с
HTML-страницей, изображением, файлом, медиа-потоком или другими
данными.
Клиент, которым обычно является веб-браузер, передаёт веб-серверу
запросы на получение ресурсов, обозначенных URL-адресами.
Ресурсы — это HTML-страницы, изображения, файлы, медиа-потоки или
другие данные, которые необходимы клиенту. В ответ веб-сервер
передаёт клиенту запрошенные данные.

Рассмотрим самые популярные веб-серверные приложения

Open
Название Распространение Особенности
Source
Apache HTTP
бесплатно Да Упор на надёжность и гибкость.
Server
Apache
бесплатно Да Реализован полностью на Java.
Tomcat
Упор на скорость и
Ascet HTTPd бесплатно Да
безопасность.
Исторически первый веб-
CERN httpd бесплатно Да
сервер.
Cherokee Ориентирован на простоту и
бесплатно Да
HTTP Server скорость.
HTTP File Простой сервер для
бесплатно Да
Server выкладывания файлов в сети.

11
Internet
Является частью пакета IIS.
Information вкл. в Win NT Нет
Поддерживает .NET
Services
Jetty бесплатно Да Реализован полностью на Java.
Использование на сильно
нагруженных серверах,
lighttpd бесплатно Да
обеспечение быстроты и
защищённости.
Разрабатывался для
испытывающих большую
nginx бесплатно Да нагрузку серверов.
Включает в себя почтовый
прокси-сервер.
Содержит веб-интерфейс
администрирования, а также
интерфейс пользователя,
который содержит в себе почту,
Sambar календарь, RSS, блог,
shareware Нет
Service фотоальбомы, чат и форум.
Также может выполнять роль
почтового сервера, DNS-
сервера, FTP-сервера, Proxy-
сервера и другое.
Компактный (размер
исполняемого файла около 120
бесплатно для СНГ
Кб), простой и быстрый HTTP-
Small HTTP при условии
Нет сервер. Также может выполнять
Server некоммерческого
роль почтового сервера, DNS-
использования
сервера, FTP-сервера, Proxy-
сервера и другое.
Tiny Web бесплатно Да Исключительно компактный

12
 (размер исполняемого файла 53
Кб), простой и быстрый HTTP-
сервер. Распространяется
вместе с исходным кодом на
Delphi.

Стоить отметить что каким бы надёжным и безопасным не

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

Классификаторы уязвимостей
Для начала требуется выяснить что такое уязвимость. Уязвимость (англ.
vulnerability) - недостаток в коде сайта или программном обеспечении
сервера, используя которые, можно нарушить целостность системы и
вызвать неправильную работу.
Уязвимость может быть результатом ошибок программирования,
недостатков, допущенных при проектировании сайтов, ненадежных
паролей, возможности проведения скриптовых и SQL - инъекций, а
также атак на сайт.
Обычно уязвимость позволяет атакующему «обмануть» web
приложение — заставить его совершить действие, на которое у того не
должно быть прав.
Это делается путем внедрения каким-либо образом в программу
данных или кода в такие места, что программа воспримет их как «свои».
В большинстве случаев уязвимости появляются из-за недостаточной
проверки данных, вводимых пользователем, и позволяют вставить в
интерпретируемый код произвольные команды.

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

OWASP
OWASP Top 10 – перечень наиболее опасных рисков информационной
безопасности для веб-приложений по мнению экспертного сообщества;
OWASP (Open Web Application Security Project) – это некоммерческая
организация, целью которой является повышение осведомленности
всех специалистов отрасли информационной безопасности в вопросах
разработки, эксплуатации и защиты веб-приложений. OWASP Top 10
является одним из наиболее известных проектов организации.
OWASP Top 10 — это рейтинг из десяти наиболее опасных рисков
информационной безопасности для веб-приложений, составленный
сообществом экспертов отрасли. Для каждого пункта рейтинга риск
посчитан экспертами на основе методики OWASP Risk Rating
Methodology и включает оценку по следующим критериям:
распространенности соответствующих уязвимостей в
приложениях (Weakness Prevalence), сложности их
обнаружения (Weakness Detectability) и эксплуатации (Exploitability), а
также критичности последствий их эксплуатации (Technical Impacts). По
понятным причинам в расчетах критичности рисков не учитываются
бизнес-последствия от их реализации. Там, где это возможно, названия
рисков в рейтинге соотносятся с названиями соответствующих
уязвимостей в классификации CWE (Common Weakness Enumeration).
Следует отметить, что в отличие от классификаций, проект
OWASP Top 10 не претендует на охват всех имеющихся рисков, а лишь
представляет самые актуальные из них на момент выпуска рейтинга.

14
Первая версия рейтинга OWASP Top 10 появилась в 2004 году, и с тех
пор документ обновляется каждые три-четыре года. Обновленные
версии публиковались в 2007, 2010, 2013 и 2017 годах.

Последняя версия рейтинга, опубликованная в 2017 году, содержит

следующие риски:

 A1 – Внедрение кода (Injection).

 A2 – Некорректная аутентификация (Broken Authentication).
 A3 – Утечка чувствительных данных (Sensitive Data Exposure).
 A4 – Внедрение внешних XML-сущностей (XXE – XML External Entities).
 A5 – Нарушение контроля доступа (Broken Access Control).
 A6 – Небезопасная конфигурация (Security Misconfiguration).
 A7 – Межсайтовый скриптинг (XSS – Cross-Site Scripting).
 A8 – Небезопасная десериализация (Insecure Deserialization).
 A9 – Использование компонентов с известными уязвимостями (Using
Components with Known Vulnerabilities).
 A10 – Отсутствие журналирования и мониторинга (Insufficient Logging
& Monitoring).

Классификация недостатков CWE

CWE (Common Weakness Enumeration) - общий перечень уязвимостей и
недостатков безопасности программного обеспечения (ПО),
представляет собой иерархический словарь, предназначенный для
разработчиков и специалистов по обеспечению безопасности ПО. CWE
поддерживается MITRE по заказу Министерства внутренней
безопасности США и развивается при широкой поддержке сообщества
экспертов. По словам разработчиков, CWE — это общий язык для
описания недостатков безопасности ПО, который необходим для

15
стандартизации методик оценки программных продуктов с точки зрения
информационной безопасности.
Ошибки в программном обеспечении, которые могут быть
непосредственно использованы злоумышленником для реализации
угроз безопасности называют уязвимостями. Ошибки, которые могут
привести к возникновению уязвимостей – недостатками безопасности.
Примером, иллюстрирующим разницу между этими двумя понятиями,
является уязвимость – СVE-2010-2245 (внедрение внешних XML-
сущностей в веб-сервисе Apache версии ниже 1.1.1) и недостаток
безопасности СWE-611 (неверное ограничение XML-ссылок на внешние
объекты), послуживший причиной этой уязвимости. Главное отличие
принципов, на которых строятся классификации недостатков от
принципов классификации уязвимостей, состоит в том, что особенно
важно сохранить связь между недостатками, ведь ошибки ведут к
новым ошибкам, например, ошибки проектирования ведут к ошибкам в
реализации. Такая связь в CWE воплощена через разные уровни
абстракций и обширные иерархические представления, которые будут
рассмотрены ниже.
На данный момент классификаторов уязвимостей достаточно много,
некоторые повторяют друг друга, выше описаны самые известные и
популярные.

Служба Поддержки

8 800 707 5466

с 8:00 до 20:00 по мск

school@codeby.net

16