Как сделать http запрос с api key

Что такое API-ключ

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

Каковы примеры использования ключей API?

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

Мониторинг использования API

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

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

Устранение неполадок интеграции API

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

Определите проекты

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

Как работает ключ API?

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

Когда приложение отправляет запросы API, процесс работает следующим образом:

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

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

Ограничение вызовов API

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

Объем услуг

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

Выбор функций

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

Количество вызовов

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

В чем разница между ключом API и токеном API?

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

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

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

В Amazon Web Services (AWS) токены API также называются токенами аутентификации или токенами безопасности. Разработчики используют разрешения IAM, авторизатор Lambda или пул пользователей Amazon Cognito для создания токенов API и управления доступом к вашим API.

Каковы рекомендации по использованию ключей API?

При использовании ключей API следует принимать во внимание несколько рекомендаций.

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

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

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

Как AWS может помочь в управлении ключами API?

Amazon Web Services (AWS) предлагает Amazon API Gateway для управления ключами API.

Вы можете использовать API Gateway для создания, публикации, обслуживания, мониторинга и защиты API REST, HTTP и WebSocket любого масштаба. Разработчики API могут создавать API для доступа к AWS или другим веб-сервисам, а также к данным, хранящимся в облаке AWS.

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

Создайте аккаунт прямо сегодня и начните управлять ключами API на AWS

Безопасность REST API от А до ПИ

Умение реализовать грамотное REST API — полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат критические уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.

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

Стандарты безопасности

Начнем со стандартов. Существует несколько стандартов, которые помогут нам сформулировать список требований к безопасности API:

OWASP (Open Web Application Security Project) известна своими списками рисков в разных программных технологиях. Нам интересен список «10 наиболее опасных уязвимостей при разработке API»:

API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам). Другое название этого риска: Insecure Direct Object References (Небезопасные прямые ссылки на объекты)
API2:2019 Broken User Authentication (Недостатки аутентификации пользователей)
API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)
API4:2019 Lack of Resources & Rate Limiting (Отсутствие проверок и ограничений)
API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)
API6:2019 Mass Assignment (Небезопасная десериализация)
API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)
API8:2019 Injection (Внедрение)
API9:2019 Improper Assets Management (Недостатки управления API)
API10:2019 Insufficient Logging & Monitoring (Недостатки журналирования и мониторинга)

Insecure Transport (Небезопасный транспортный уровень)
Insecure Passwords (Небезопасные пароли)
Using Components with Known Vulnerabilities (Использование компонент с известными уязвимостями)

CWE-79 Cross-site Scripting (XSS) (Межсайтовое выполнение сценариев)
CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)

Insecure Cookies and Local Storage (Небезопасные Cookies и Local Storage)
Insecure HTTP Headers (Небезопасные HTTP заголовки)
Improper Cross-origin resource sharing (Неправильное использование CORS)
Clickjacking (Подмена кликов)

API2:2019 — Broken User Authentication (Недостатки аутентификации пользователей)

Тема аутентификации пользователей идет на втором месте в списке OWASP, но я ее поставил на первое, т.к. с этого все начинается. Современные стандарты аутентификации и авторизации я уже рассматривал в своей статье про OAuth 2.0, OpenID Connect, WebAuthn. Здесь кратко опишу основные схемы безопасности и рассмотрим более подробно наиболее надежную на данный момент схему, основанную на токенах.

API key

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

Basic Authentication

В Basic Authentication используется аутентификация по двум строкам, например логину/паролю.

Для передачи информации используется HTTP заголовок ‘Authorization’ с ключевым словом Basic далее пробел и base64 закодированная строка username:password. Например:

Authorization: "Basic dXNlcm5hbWU6cGFzc3dvcmQ xml">Authorization: Set-Cookie: JSESSIONID=123456789; Path=/; HttpOnly

После этого клиент автоматически будет посылать заголовок Cookie при каждом запросе:

Cookie: JSESSIONID=123456789

Для реализации этого механизма необходимо на сервере организовать хранение и проверку сессий пользователей. Подробнее использование Cookies рассмотрено в разделе «Insecure Cookies and Local Storage»

Token-Based Authentication

Также называют Bearer Authentication.

Token-Based Authentication использует подписанный сервером токен (bearer token), который клиент передает на сервер в заголовке Authorization HTTP с ключевым словом Bearer или в теле запроса. Например:

Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjI4Y

При получении токена сервер должен проверять его на валидность — что пользователь существует, время использования не прошло и т.д. Token-Based Authentication может использоваться как часть OAuth 2.0 или OpenID Connect протоколов, так и сервер сам может сформировать токен.

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

Алгоритм Token-Based Authentication

Разберем подробнее последнюю из описанных схем. На схеме представлен упрощенный алгоритм Token-Based Authentication на примере реализации возможности «Зайти с помощью Google аккаунта»

Пользователь заходит на сайт и нажимает кнопку «Зайти с помощью Google аккаунта»
Сервер посылает запрос на Google.
Google показывает пользователю свою форму логина.
Пользователь вводит логин/пароль.
Google проверяет логин/пароль и отправляет на наш сервер приложений access token и refresh token.
Для аутентификации сервер расшифровывает token или получает информацию о пользователе по Google API.
Далее сервер находит пользователя в своей базе, сообщает об успешной аутентификации и сохраняет токены в локальном хранилище пользователя для реализации возможности «Запомнить меня на этом устройстве». В каком конкретно: Local Storage, Session Storage или Cookies, решается в зависимости от требований бизнеса и безопасности. OWASP склоняется к Cookies с реализацией дополнительных механизмов безопасности: JSON Web Token Cheat Sheet. Нужно ли генерировать дополнительный «session token», где его хранить и как использовать — также должно определяться бизнесом, для которого реализуется система.
После этого при каждом запросе к серверу клиент будет передавать access token в запросе, а наш сервер проверять его на валидность в Google и только после этого передавать запрошенные данные.
При окончании срока действия access токена сервер использует refresh токен для получения нового.

Не надо хранить пароли в базе данных на сервере, таким образом сразу избавляемся от уязвимости Insecure Passwords.
В некоторых случаях можно вообще избавиться от базы данных на сервере и получать всю необходимую информацию из Google или других систем.
Нет проблем с безопасностью, характерных для остальных методов:

При компрометации логина/пароля доступ к данным получается сразу и длится пока пользователь сам не заметит факт взлома, у токенов же есть время жизни, которое может быть небольшим.
Токен автоматически не уйдет на сторонний сайт, как Cookie.
Cookie-Based Authentication подвержена атаке Cross-Site Request Forgeries (CSRF) и, соответственно, необходимо использовать дополнительные механизмы защиты.
Можно не хранить сессию пользователя на сервере, а токен проверять каждый раз в Google.

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

API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам)

Другое название этого риска: Insecure Direct Object References (Небезопасные прямые ссылки на объекты). Это самая распространенная проблема с API в настоящее время. Для иллюстрации приведу API, которое в дальнейшем использую еще для нескольких примеров уязвимостей.

Получить одного пользователя с userID:

GET /users/

Получить всех пользователей (может только администратор):

GET /users

Удалить пользователя c userID: DELETE /users/

DELETE /users/1

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

DELETE /users/1

То необходима проверка, что эту команду может вызвать только сам пользователь 1 или администратор, а не, например, пользователь 2 от своего имени, просто изменив значение ID в вызове команды. Чтобы избежать подобных проблем нужно:

Проверять права доступа к объектам при каждом запросе.
Проверять, что залогиненный пользователь имеет доступ только к разрешенным объектам.
ID объектов должны быть сложными для подбора, например в виде UUID, а не простая последовательность 1, 2, 3.

Role-Based Access Control (RBAC)
Discretionary Access Control (DAC)
Mandatory Access Control (MAC)
Permission Based Access Control

API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)

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

GET /users/all

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

API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)

На самом деле пункт называется — предоставление излишних данных, но при этом как раз и может происходить разглашение конфиденциальных или персональных данных. Как такое получается? На запрос клиента сервер, как правило, формирует запрос к базе данных, которая возвращает запись или список записей. Эти данные зачастую сериализируются в JSON без проверок и отправляется клиенту с предположением, что клиент сам отфильтрует нужные данные. Но проблема в том, что запрос может отправить не только клиент, а может сформировать злоумышленник напрямую к серверу и получить конфиденциальные данные. Например, безобидный запрос данных по пользователю с ID 1:

GET /users/1

может вернуть не только имя / возраст, но и ответ на секретный вопрос, который пользователь задал во время регистрации:

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

API6:2019 Mass Assignment (Небезопасная десериализация)

В данном случае ситуация обратная предыдущему пункту Excessive Data Exposure — лишние данные передаются на сервер с целью несанкционированной замены значений. Как это понимать? Предположим у нас есть пользователь-хакер с ID 1 со следующими данными:

Некоторые поля записей пользователь может легитимно менять сам, например, свой возраст. А поля, такие как balance должны устанавливать внешние системы.

Но наш сервер подвержен атаке Mass Assignment и без проверок источника записывает все пришедшие данные. Наш пользователь-хакер может отправить на сервер запрос на изменение возраста, в который добавляет дополнительный атрибут balance:

POST /users/1

После этого баланс увеличится без внесения реальных денег. Чтобы предотвратить данную атаку необходимо:

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

API4:2019 Lack of Resources & Rate Limiting (Отсутствие проверок и ограничений)

Необходимо защитить сервер от атак по подбору пароля (brute force attack). Для этого нужно реализовать следующие ограничения:

Ограничить число неудачных попыток авторизации одного пользователя. Как вариант использовать reCapture или аналогичный механизм.
Блокировать IP, если число неудачных попыток с него превысило определенное значение по всем пользователям.

Необходимо защитить сервер и от отказа в обслуживании (DoS-атаки)

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

/api/users?page=1&size=100

Если на сервере отсутствует проверка size на максимальное значение, то передача в параметре злоумышленником, например, 1 000 000 может привести к исчерпанию памяти на сервере и отказу в обслуживании. Поэтому нужно проверять на сервере все значения параметров на допустимые, даже если на нашем клиенте есть такие проверки. Ведь никто не помешает вызвать API напрямую.

API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)

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

Используются дефолтные настройки приложений, которые могут быть небезопасны.
Используются открытые хранилища данных.
В OpenSourсe попала закрытая информация, например, конфигурация системы или параметры доступа.
Неправильно используются регулярные выражения, что позволяет провести атаку ReDoS (Regular expression Denial of Service)
Неправильно сконфигурированы HTTP заголовки (данная тема рассмотрена далее в разделе «Insecure HTTP Headers»).
Аутентификационные данные (логин/пароль, токен, apiKey) посылаются в URL. Это небезопасно, т.к. параметры из URL могут оставаться в логах веб серверов.
Отсутствует или неправильно используется политика Cross-Origin Resource Sharing (CORS) (данная политика рассмотрена далее в одноимённом разделе).
Не используется HTTPS (использование HTTPS рассмотрено в разделе «Insecure Transport»).
При эксплуатации промышленной системы используются настройки, предназначенные для разработки и отладки.
Сообщения об ошибках содержат чувствительную информацию, например, трейсы стека.

Для пользователей устанавливать только необходимые права доступа.
Открывать только необходимые сетевые порты.
Устанавливать безопасные версии патчей OS и приложений (подробно рекомендации рассмотрены в разделе «Using Components with Known Vulnerabilities»).

API8:2019 Injection (Внедрение)

Внедрение — это выполнение программного кода, не предусмотренного системой. Разделяют внедрения:

SQL команд
Команд OS

GET /run

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

GET /run

Для предотвращения подобных атак:

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

API9:2019 Improper Assets Management (Недостатки управления API)

API может иметь несколько точек входа (endpoints) с разными версиями и функциональными назначениями. Например:

http://localhost:5000/myAPI/v1

http://localhost:5000/myAPI/v2

http://localhost:5000/myTestAPI/v1

Необходимо обеспечить учет и контроль версий API:

Нужно вести список имеющихся API, их версий, назначение (production, test, development) и кто имеет к ним доступ (public, internal, partners).
Необходимо управлять жизненным циклом API и своевременно запускать новые версии, снимать с поддержки старые.
В открытом доступ выставлять только актуальные версии API.
Не оставлять в открытом доступе endpoints, предназначенные для отладки.

API10:2019 Insufficient Logging & Monitoring (Недостатки журналирования и мониторинга)

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

Логировать все неудачные попытки аутентификации, отказы в доступе, ошибки валидации входных данных.
Обеспечить целостность логов, чтобы предотвратить возможность их подделки.
Мониторить надо не только приложения и вызовы API, но и инфраструктуру, сетевую активность, загрузку OS.
Необходимо обеспечить не только мониторинг, но и оперативное оповещение о нарушениях штатной работы системы.
Общие советы по мониторингу можно посмотреть в статье Monitoring Done Right

Insecure Transport (Небезопасный транспортный уровень)

Если не шифровать трафик между клиентом и сервером, то все HTTP данные и заголовки будут передаваться в открытом виде. Чтобы предотвратить утечку данных, надо использовать протокол HTTPS (Hyper Text Transfer Protocol Secure) или реализовывать шифрование самостоятельно. Для использования HTTPS нужен SSL-сертификат. Сайты в интернете должны получать такие сертификаты в доверительных центрах выдачи сертификатов CA (Certificate Authority). Но для целей шифрования данных между нашим клиентом и сервером можно поступить проще:

Самостоятельно сгенерировать, так называемый, self-signed сертификат.
На сервере настроить использование HTTPS протокола.
С клиента формировать запросы, начинающиеся с https.

Обеспечить поддержку HTTPS можно также средствами Apache, Nginx или других веб-серверов.

Insecure Passwords (Небезопасные пароли)

С этой темой все просто:

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

Insecure Cookies and Local Storage (Небезопасные Cookies и данные в Local Storage)

Cookies должны использоваться безопасно:

Нельзя использовать дефолтные имена.
При создании Cookies следует устанавливать следующие опции:

 secure - браузер будет отправлять cookies только по HTTPS протоколу. httpOnly - браузер будет отправлять cookies только по HTTP или HTTPS и не отправлять при запросах из JavaScript, что предотвратит атаки Cross-site Scripting (XSS). domain - определяет domain cookie. path - определяет path cookie. expires - определяет дату устаревания cookies. SameSite - браузер будет отправлять cookies только тому сайту, который их установил.

Европейские сайты должны явно спрашивать разрешение у пользователя о применении Cookies. Так как, например, если в Cookies записать последовательность действий пользователя на сайте, то это уже считается персональной информацией.

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

Using Components with Known Vulnerabilities (Использование компонент с известными уязвимостями)

Компоненты, такие как библиотеки и framework-и выполняются с теми же привилегиями, что и приложение. Поэтому если среди используемых библиотек окажется небезопасный компонент, то это может привести к захвату или выводу из строя сервера. Для проверки безопасности компонент используются специальные приложения, например, для JavaScript можно использовать Retire.

CWE-79 Cross-site Scripting (XSS) (Межсайтовое выполнение скриптов)

Межсайтовое выполнение скриптов считается самой опасной web-атакой. Суть ее в том, что вредоносный скрипт может быть внедрен в нашу страницу, а результат выполнения может привести к утечке конфиденциальных данных или к повреждению сервера. Чтобы защититься от атаки в запрос надо включить HTTP заголовок, который включает Cross-site scripting (XSS) фильтр:

X-XSS-Protection : 1; mode=block

Content-Security-Policy: script-src 'self'

CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)

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

Финансовый сайт успешно проверяет валидность Cookies и выполняет несанкционированную транзакцию. Для защиты от атак CSRF надо:

На сервере реализовать механизм «CSRF токенов». Это такой механизм, когда для каждой сессии пользователя генерируется новый токен и сервер проверяет его валидность при любых запросах с клиента.
На сервере проверять заголовки Origin и Referer, в которых содержится адрес источника запроса. Но эти заголовки могут отсутствовать.
Также можно всегда требовать от пользователя подтверждать критические действия вводом пароля или вторым фактором аутентификации, но возможность таких мер зависит от бизнеса.
При создании Cookies выставлять параметр SameSite, но этот механизм поддерживают не все браузеры.

Cross-origin resource sharing (CORS) (Кросс-доменное использование ресурсов)

CORS — это механизм безопасности, который позволяет серверу задать правила доступа к его API. Например, если на сервере установить заголовок:

Access-Control-Allow-Origin: *

то это позволит использовать API без ограничения. Если это не публичное API, то для безопасности надо явно устанавливать Origin-ы, с которых разрешен доступ к API, например:

Access-Control-Allow-Origin: https://example.com:8080

Также можно ограничивать HTTP методы, которые могут быть использованы для доступа к API:

Access-Control-Allow-Methods: GET, POST, DELETE, PUT

И задать список заголовков, которые сервер может принимать:

Access-Control-Allow-Headers: Origin, Content-Type, Authorization

Insecure HTTP Headers (Безопасность HTTP заголовков)

HTTP протокол включает в себя большое число заголовков, которые можно использовать в HTTP запросах/ответах. Для того, чтобы определить наиболее важные заголовки с точки зрения обеспечения безопасности, я использовал несколько списков:

OWASP Secure Headers Project
Рекомендации Express: Production Best Practices

X-Powered-By

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

X-Powered-By: Express

Отсутствие этого заголовка, конечно, никого не остановит, но сразу давать такую подсказку не стоит. Поэтому передачу этого заголовка надо запретить.

HTTP Strict Transport Security (HSTS)

Strict-Transport-Security заголовок запрещает браузеру обращаться к ресурсам по HTTP протоколу, только HTTPS:

Strict-Transport-Security: max-age=31536000

max-age=31536000 — это год в секундах. Рекомендуется выcтавлять этот заголовок, т.к. он предотвратит атаки, связанные с принуждением браузера перейти на HTTP протокол и начать передавать информацию (например cookies) в открытом виде, которую может перехватить злоумышленник. Запрос к серверу по HTTP и атака возможна только при первом обращении к серверу, при последующих браузер запомнит настройку Strict-Transport-Security и будет обращаться только по HTTPS.

X-Frame-Options (защита от Clickjacking)

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

X-Frame-Options: deny

или разрешить использование только в нашем домене:

X-Frame-Options: sameorigin

А лучше для предотвращения атаки Clickjacking использовать более современный механизм и установить правильную политику безопасности Content-Security-Policy

Content-Security-Policy

Позволяет защититься от атаки Cross-site scripting и других кросс-сайтовых инъекций, в том числе Clickjacking. Требует вдумчивого конфигурирования, т.к. параметров много. Но надо хотя бы поставить дефолтную политику, что предотвратит возможность атаки Cross-site Scripting:

Content-Security-Policy: default-src 'self'

Подробно значения заголовка Content-Security-Policy разбираются, например, по ссылке.

X-Content-Type-Options

Установка данного заголовка запрещает браузеру самому интерпретировать тип присланных файлов и принуждает использовать только тот, что был прислан в заголовке Content-Type. Без этого возможна ситуация, когда, например, посылается безобидный на вид txt файл, внутри которого вредоносный скрипт и браузер его выполняет как скрипт, а не как текстовой файл. Поэтому устанавливаем:

X-Content-Type-Options: nosniff

Cache-Control

Cache-Control позволяет управлять кешом на стороне клиента, рекомендуется запретить кеширование, чтобы в кеше случайно не оставались приватные данные:

Cache-Control: no-store

Заключение

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

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

Ссылки на использованные списки:

API Security Top 10
Top 25 Most Dangerous Software Errors
Рекомендации RedHat: API security
Рекомендации Express: Production Best Practices
Рекомендации Node.js: Security Checklist

It’s only the beginning!

Как на php отправить http-запрос?

Подскажите пожалуйста как будет выглядеть код для отправки этого запроса? Заранее спасибо!

Отслеживать

3,105 1 1 золотой знак 9 9 серебряных знаков 22 22 бронзовых знака

задан 12 сен 2020 в 9:27

Денис Шапошников Денис Шапошников

21 3 3 бронзовых знака

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

 "https://api.api.ru/v2/posting/fbo/get", CURLOPT_RETURNTRANSFER => true, CURLOPT_ENCODING => "", CURLOPT_MAXREDIRS => 10, CURLOPT_TIMEOUT => 0, CURLOPT_FOLLOWLOCATION => true, CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1, CURLOPT_CUSTOMREQUEST => "POST", CURLOPT_POSTFIELDS => array('posting_number' => '1305-0001-1'), CURLOPT_HTTPHEADER => array( "Client-Id: 836", "Host: api.api.ru", "Api-Key: 0296d4f2-70a1-4c09-b507-90005567b9", "Content-Type: application/json" ), )); $response = curl_exec($curl); curl_close($curl); echo $response;

Думаю будет вот так выглядеть запрос

Отслеживать

ответ дан 12 сен 2020 в 9:40

1,018 7 7 серебряных знаков 11 11 бронзовых знаков

Отправляем запросы в Postman

При тестировании конечных точек с различными параметрами, можно использовать один из множества доступных графических интерфейсов для выполнения запросов. (Графический интерфейс пользователя с полями и кнопками, на которые можно щелкнуть.) Также можно использовать curl (о чем мы поговорим в ближайшее время), но графический интерфейс, как правило, упрощает тестирование API REST.

Зачем нужен графический интерфейс?

Возможности графического интерфейса:

Сохраняет ваши запросы (и многочисленные варианты) для легкого запуска в будущем;
легкий ввод информации в правильном формате;
просмотр ответа в формате JSON или в необработанном виде;
легкое включение информации заголовка.

В графическом интерфейсе не нужно переживать о правильности синтаксиса curl и анализировать запрос и ответы в командной строке.

��‍�� Практическое занятие: создаем запрос в Postman

Создаем запрос

Использование инструмента Postman для создания запроса о текущих погодных данных при помощи конечной точки API OpenWeatherMap.

Если еще не установлен Postman, открываем сайт https://www.getpostman.com/ и установите приложение;
Запускаем приложение;
Выбираем метод GET (обычно выбирается по умолчанию);
Вставляем конечную точку https://api.openweathermap.org/data/2.5/weather в ячейку справа от метода;
Открывыем вкладку Params под методом и вписать следующие значения: key: zip / value: 95050 key: units / value: imperial key: appid / value: APIKEY

Вставляем в значение ZIP и appid нужный индекс и ключ авторизации API

Интерфейс Postman будет выглядеть так:

Postman_params

При добавлении параметров они будут отображаются в виде строки запроса к URL-адресу конечной точки в поле GET.

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

Многие API передают ключ API в заголовке, а не в качестве параметра строки запроса в URL-адресе запроса. (Если бы это было так, вы бы кликнули вкладку «Headers» и вставили необходимую пару ключ-значение в заголовок.)

Кликаем на кнопку Send

Ответ появится в нижней панели. Пример:

Postman_response

Сохраняем запрос

В Postman нажать на кнопку Save (правее Send )
В диалоговом окне ввести имя запроса, например: “OpenWeatherMap Current API”
В описании запроса написать краткое описание запроса (опционально), например: “gets the current weather for 95050 in imperial units.”
Проскроллить окно немного вниз и нажать Create collection для создания папки, куда будет сохранен запрос. После создания выбрать созданную папку.

После создания папки кнопка Save станет активной. Диалоговое окно будет выглядеть примерно так:

Save_request

Нажимаем Save to (имя папки)

Сохраненные конечные точки будут видны в панели слева в Коллекциях. Если панель “Коллекции” не видна, нажать кнопку Show/Hide Sidebar в нижнем левом углу.

Создаем запрос на 5-дневный прогноз OpenWeatherMap

Теперь вместо получения текущей погоды, используем другую конечную точку OpenWeatherMap для получения прогноза. Введите данные в Postman для 5-дневного прогноза. В Postman вы можете щелкнуть новую вкладку или щелкнуть стрелку рядом с «Сохранить» и выбрать «Сохранить как». Затем выберите свою коллекцию и запросите название.

Пример конечной точки для 5-дневного прогноза, который указывает местоположение по почтовому индексу, выглядит следующим образом:

https://api.openweathermap.org/data/2.5/forecast?zip=95050,us

Добавим в параметры запроса значения API и units

https://api.openweathermap.org/data/2.5/forecast?zip=95050&appid=APIKEY&units=imperial

В своей ссылке замените APIKEY на ключ API

Создаем еще один запрос OpenWeatherMap

Сделаем еще один запрос API OpenWeatherMap, на этот раз изменив параметры, которые использовали ранее для указания местоположения (для любой конечной точки). Например, если указали местоположение по почтовому индексу, изменим его на географические координаты lat и lon.

https://api.openweathermap.org/data/2.5/weather?lat=37.3565982&lon=-121.9689848&units=imperial&appid=fd4698c940c6d1da602a70ac34f0b147

Аналогичные запросы в Paw вместо Postman

Хотя Postman является популярным REST-клиентом, можно использовать и другие, например Paw.

На следующем рисунке показан тот же запрос API текущей погоды, который был сделан в Paw для Mac.

paw

Как и Postman, Paw также позволяет видеть заголовки запросов, заголовки ответов, параметры URL и другие данные. Здорово, что Paw показывает ответ в расширяемом / разборном виде. Функция “развернуть / свернуть” может облегчить изучение ответа. Но стоит обратить внимание, что Paw относится только к Mac и, как и большинство продуктов Mac, стоит денег.

Вводим несколько запросов для Aeris API в Postman

Теперь давайте посмотрим информацию о погоде из Aeris Weather API, которую изучили исследуя API Aeris. Сконструировать конечную точки для Aeris Weather API немного сложнее, поскольку для конфигурации конечной точки можно использовать много разных запросов, фильтров и других параметров.

Вот несколько предварительно настроенных запросов для настройки для Aeris.

Можно вставить запросы непосредственно в поле запроса URL-адреса в Postman (после настройки значений CLIENTID и CLIENTSECRET ), и параметры будут автоматически заполнены в нужных полях.

Как и в случае OpenWeatherMap API, Aeris API не использует поле заголовка для передачи ключей API — ключ и секрет передаются непосредственно в URL-адресе запроса, как часть строки запроса.

Note: При создании следующих запросов, вставьте свои собственные значения для CLIENTID и CLIENTSECRET (при условии, что вы получили их, выполняя практическое занятие Получаем секретный код и ID Aeris Weather API ). При отсутствии CLIENTID и CLIENTSECRET , можно использовать ключи автора.

Получаем прогноз погоды для своего района, используя конечную точку Observations:

http://api.aerisapi.com/observations/Santa+Clara,CA?client_id=CLIENTID&client_secret=CLIENTSECRET&limit=1

Получаем погоду для города на экваторе — Чимборасо, Эквадор, используя ту же точку Observations:

http://api.aerisapi.com/observations/Chimborazo,Ecuador?client_id=CLIENTID&client_secret=CLIENTSECRET&limit=1

Посмотрим, вся ли музыка кантри в Ноксвилле, штат Теннесси, провоцирует мигрень у жителей, используя конечную точку Indices:

http://api.aerisapi.com/indices/migraine/Knoxville,TN?client_id=CLIENTID&client_secret=CLIENTSECRET

Подумываете о переезде в Аризону и подыскиваете местечко получше? Используем конечную точку normals

http://api.aerisapi.com/normals/flagstaff,az?client_id=CLIENTID&client_secret=CLIENTSECRET&limit=5&filter=hassnow

Tip: И с OpenWeatherMap, и с Aeris Weather API можно сделать эти запросы, просто перейдя по URL-адресу в адресной строке (поскольку API передаются в строке запроса, а не в заголовке). Используйте расширение JSON Formatter для Chrome, чтобы автоматически форматировать ответ JSON в представлении браузера.

Изучив эти два разных API сервисов прогноза погоды, можно увидеть различия в способе вызова и возврата информации. Однако, по сути, оба API имеют конечные точки, которые можно настраивать с помощью параметров. При создании запроса с конечными точками, получаем ответы, которые содержат информацию, часто в формате JSON. Это основа работы REST API: отправляем запрос — получаем ответ.

Автоматический импорт коллекций Postman

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

Коллекция OpenWeatherMap API

Коллекция Aeris Weather API

Для импорта: нужно скопировать адрес ссылки, в Postman нажать Import в верхнем левом углу. Затем перейдите на вкладку Import from link , вставить адрес и нажать Import .

Tip: Если вы хотите узнать больше о Postman, послушайте интервью с основателем Postman. Интервью записано как часть подкаста Write the Docs. Дополнительные сведения о создании кнопок «Выполнить в Postman» см. в разделе Run in Postman button .