Файловый архив студентов. Файловый архив студентов.
1261 вуз, 4625 предмет.
/ Регистрация
FAQ Обратная связь Вопросы и предложения
Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Пензенский Государственный Университет
Предмет:
[НЕСОРТИРОВАННОЕ]
Файл:
книги хакеры / Эдриан_Прутяну_Как_стать_хакером_сборник_практическиз_сценариев.pdf
Скачиваний:
16
Добавлен:
19.04.2024
Размер:
20.34 Mб
Скачать
☆
►Содержание►

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

 

 

C

E

 

 

 

 

 

X

 

 

 

 

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

 

t

 

 

 

F

 

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

 

i

 

 

 

D

 

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

r

 

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

o

 

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

Протоколы передачи данных    281 BUY

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

w Click

to

 

 

 

 

 

 

 

 

 

 

 

 

to

 

 

 

 

 

 

 

 

 

 

 

 

 

m

 

w Click

 

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

o

 

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

g

.c

 

 

 

.

 

 

 

 

g

.c

 

 

 

p

 

 

 

 

 

 

 

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

 

ложении каждый компонент является встроенным,мне не нужно беспокоить-

 

 

e

 

 

 

 

df

 

 

n

e

 

 

 

 

 

df

 

 

n

 

 

 

 

 

-xcha

 

 

 

 

 

 

 

 

 

 

-x cha

 

 

 

 

 

 

 

 

 

 

 

ся об обмене данными с модулем аутентификации,поскольку он находится на

 

 

 

 

 

 

 

 

 

 

 

 

том же сервере, а иногда в одном и том же процессе. Если мой модуль аутен-

 

 

 

 

 

 

 

 

 

 

 

 

тификации был разделен и теперь это веб-служба HTTP, работающая в облаке,

 

 

 

 

 

 

 

 

 

 

 

 

нужно рассмотреть возможность обмена данными по сети между моим поль-

 

 

 

 

 

 

 

 

 

 

 

 

зовательским интерфейсом и экземпляром модуля аутентификации в облаке.

 

 

 

 

 

 

 

 

 

 

 

 

Как API аутентифицирует мой пользовательский интерфейс? Как два компо-

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

был разрешен доступ к другим компонентам?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Разделение оказывает и другие интересные эффекты на безопасность.

 

 

 

 

 

 

 

 

 

 

 

 

Предположим, есть API, разработанный для обработки данных для приложе-

 

 

 

 

 

 

 

 

 

 

 

 

ния Windows. API будет принимать методы запроса, поддерживаемые HTTP-

 

 

 

 

 

 

 

 

 

 

 

 

протоколом (GET, PUT и т. д.), и отправлять ответ в формате JSON либо XML.

 

 

 

 

 

 

 

 

 

 

 

 

Приложение Windows считывает ответ и отображает сообщение об ошибке,

 

 

 

 

 

 

 

 

 

 

 

 

возвращаемое в JSON-объекте. Всплывающее окно Windows, содержащее про-

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

ровать опасный HTML-код в ответе API, потому что функция MessageBox()

 

 

 

 

 

 

 

 

 

 

 

 

библиотеки­

user32.dll не выполняет какую-либо визуализацию отображае-

 

 

 

 

 

 

 

 

 

 

 

 

мой строки. Теперь предположим, что тот же API неожиданно был интегриро-

 

 

 

 

 

 

 

 

 

 

 

 

ван в совершенно новое веб-приложение. Неэкранированные HTML-данные в

 

 

 

 

 

 

 

 

 

 

 

 

ответе в формате JSON могут стать проблемой.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

К концу главы вы освоите:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

различные типы архитектуры веб-API;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

как API обрабатывают аутентификацию;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

веб-токены JSON (JWT);

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

автоматизацию атак на API.

 

 

 

 

 

 

 

 

 

 

 

Протоколы передачи данных

По сути, веб-API – это простые HTTP-среды типа «клиент–сервер». Запрос приходит по протоколу HTTP и получает ответ. Чтобы еще больше стандартизировать ситуацию, разработали пару протоколов, и многие API-интерфейсы следуюттому или иному протоколу для обработки запросов. Это далеко не исчерпывающий список, но вы, скорее всего, столкнетесь с этими протоколами на практике:

Representational State Transfer (REST);

Simple Object Access Protocol (SOAP).

Конечно,существуют и другие типы протоколов,которые API могут использовать,нохотяихпротоколыиразличаются,большинствопроблем,связанных с безопасностью, те же. Самые популярные протоколы – это RESTful API, за которыми следуют SOAP API.

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

NOW!

 

o

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

w Click

to

BUY 282    Глава 11.Атака на API

 

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

 

.c

 

 

 

p

 

 

 

 

g

 

SOAP

 

 

 

df

 

 

n

e

 

 

 

 

 

 

-xcha

 

 

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

 

E

 

 

 

 

X

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

 

to

 

 

 

 

 

w Click

 

 

 

 

 

m

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

 

.c

 

 

 

p

 

 

 

 

g

 

 

 

 

 

df

 

 

n

e

 

 

 

 

 

-x cha

 

 

 

 

SOAP разработала компания Microsoft, потому что модель распреде-

ленных компонентных объектов (DCOM) представляет собой двоичный протокол, который несколько усложняет обмен данными через интернет. Вместо этого SOAP использует XML, более структурированный и понятный для человека язык, чтобы обмениваться сообщениями между клиентом и сервером.

SOAP стандартизирован, и его спецификация доступна для просмотра в полном объеме на странице https://www.w3.org/TR/

soap12/.

Типичный SOAP-запрос к хосту API выглядиттак:

POST /UserData HTTP/1.1

Host: internal.api

Content-Type: application/soap+xml; charset=utf-8

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body xmlns:m="http://internal.api/users"> <m:GetUserRequest>

<m:Name>Administrator</m:Name> </m:GetUserRequest>

</soap:Body>

</soap:Envelope>

Ответ от сервера, как и следовало ожидать,также идет в формате XML.

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset=utf-8

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body xmlns:m="http://internal.api/users">

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

 

F

 

 

 

 

 

 

t

 

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

r

 

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

Протоколы передачи данных   

w Click

to

 

 

 

 

 

 

 

 

 

 

m

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

 

.

 

 

 

 

 

.c

 

 

 

 

p

 

 

 

 

g

 

 

 

 

 

 

df

 

 

n

e

 

<m:GetUserResponse>

 

 

 

 

 

 

 

 

 

 

 

 

-xcha

 

 

 

 

 

<m:FullName>Dade Murphy</m:FullName> <m:Email>dmurphy@webapp.internal</m:Email> <m:IsAdmin>True</m:IsAdmin>

</m:GetUserResponse>

</soap:Body>

</soap:Envelope>

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

E

 

 

 

 

X

 

 

 

 

 

-

 

 

 

 

d

 

 

F

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

r

P

 

 

 

 

NOW!

o

 

 

 

 

 

 

283 BUY

 

 

 

 

 

 

 

w Click

to

 

 

 

 

m

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

o

 

 

.

 

 

 

 

.c

 

 

 

p

 

 

 

g

 

 

 

 

 

df

 

n

e

 

 

 

 

 

-x cha

 

 

 

 

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

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

Хотятеги Envelope,Body иHeader стандартизированы,содержимоетела можетварьироваться в зависимости оттипа запроса,приложения и самой реализации веб-службы. Действие GetUserRequest и его параметр Name относятся к конечной точке /UserData. Для поиска потенциальных уязвимостей нам нужно знать все возможные конечные точки и их соответствующие действия или параметры. Как получить эту информацию, если мы имеем дело с «черным ящиком»?

XML-структура запросов и ответов SOAP обычно определяется в файле WSDL (язык описания веб-сервисов) (рис. 11.1). В случае с общедоступными API он обычно доступен, если непосредственно запросить сам API, добавив ?wsdl к конкретному URL-адресу конечной точки. При правильной настройке веб-сервис ответит бóльшим XML-файлом со всеми возможными действиями и параметрами для этой конечной точки.

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

Последним средством,очевидно,является просто наблюдение веб-,мобиль- ных или нативных приложений, взаимодействующих с API, перехват HTTPтрафика в Burp и воспроизведение его через модули Intruder или Scanner. Конечно, это не идеальный вариант, поскольку уязвимые параметры или действия могут не вызываться при нормальной работе приложения.

Всегда лучше получить файл WSDL напрямую от разработчика.

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

 

E

 

 

 

 

X

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

w Click

to

BUY 284   

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

 

.c

 

 

 

p

 

 

 

 

g

 

 

 

 

 

df

 

 

n

e

 

 

 

 

 

-xcha

 

 

 

 

Глава 11.Атака на API

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

 

E

 

 

 

 

X

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

 

to

 

 

 

 

 

w Click

 

 

 

 

 

m

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

 

.c

 

 

 

p

 

 

 

 

g

 

 

 

 

 

df

 

 

n

e

 

 

 

 

 

-x cha

 

 

 

 

Рис.11.1. WSDL-файл

REST

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

Подобно SOAP, RESTful API работают по протоколу HTTP и интенсивно используют методы запроса, выраженные глаголами:

GET;

POST;

PUT;DELETE.

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

 

 

C

E

 

 

 

 

 

X

 

 

 

 

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

 

t

 

 

F

 

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

 

i

 

 

D

 

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

 

r

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

 

o

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

Протоколы передачи данных    285 BUY

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

w Click

to

 

 

 

 

 

 

 

 

 

 

 

 

to

 

 

 

 

 

 

 

 

 

 

 

 

 

 

m

w Click

 

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

o

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

g

.c

 

 

.

 

 

 

 

g

.c

 

 

 

p

 

 

 

 

 

 

 

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

e

Если нам нужно запросить информацию о пользователе, RESTful API может

 

 

e

 

 

 

 

df

 

 

n

 

 

 

 

 

 

 

 

df

 

 

n

 

 

 

 

 

 

 

 

-xcha

 

 

 

 

 

 

 

 

 

 

-x cha

 

 

 

 

 

реализовать глагол GET с конечной точкой /users. Запрос будет отправлен через URL-параметры.

GET /users?name=admin HTTP/1.1

Host: api.ecorp.local:8081

Content-Type: application/json

Accept: application/json

Authorization: Bearer b2YgYmFkIG5ld3M

Cache-Control: no-cache

В этом запросе следует отметить заголовки Content-Type, Accept и Autho-

rization.

Заголовок Content-Type указывает, в каком формате API должен обрабатывать входящие данные. Заголовок Accept указывает, какой формат клиент примет в ответе от сервера. Типичные API поддерживают форматы JSON или XML, а иногда и оба. Наконец, заголовок Authorization указывает токен на предъявителя и будет необходим для конечных точек, которые обеспечивают аутентификацию. Это позволяет серверу определить, какой пользователь делает запрос и имеетли он на это право.

Некоторые пользовательские API могут применять пользовательские заголовки для аутентификации и авторизации, такие как X-Auth-Token, но принцип тот же.Как только мы узнаем,как токены аутентификации и авторизации передаются между клиентом и сервером,то сможем приступить к поиску слабых мест.

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

HTTP/1.0 200 OK

Server: WSGIServer/0.1 Python/2.7.11

Content-Type: text/json

{"user": {"name": "admin", "id": 1, "fullname": "Dade Murphy"}}

Ответ 200 означает,что все прошло успешно, наш токен действителен, и теперь у нас есть JSON-объект со всеми подробностями,касающимися пользова- теля-администратора.

RESTful API обычно используют формат JSON для запросов и ответов, но жесткого стандарта нет, и разработчики могут использовать собственный XML-протокол или даже необработанный двоичный файл. Это необычно, поскольку совместимость и обслуживание микросервисов становятся сложными, но такое случается.

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