Что такое api ключ

ЧТО ТАКОЕ КЛЮЧ API

Расшифровка API

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

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

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

API-ключи – это ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля. Существует два вида ключей API:

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

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

Как правило, API-ключи выглядят как длинная строка из разных символов. Это затрудняет взлом ключей.

Как работают ключи API

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

Безопасность при работе с API

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

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

Источник

Ключи API и их безопасность

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

Например, если мы возьмем пример ноутбука. Предположим, в ноутбуке 2 пользователя: один — администратор, а другой — ABC. ABC не авторизован для удаления файла. ABC может только создать файл, прочитать файл, изменить файл.
Если пользователь ввел учетные данные администратора. Система сначала сопоставит учетные данные с данными в базе данных, чтобы определить, кто это пользователь или для случая, является ли он законным пользователем или нет. После проверки подлинности учетных данных система узнает, что она является администратором, поэтому она увидит набор разрешений для администратора и предоставит только те привилегии, которые предназначены для администратора. Как и администратор может удалить файл также. Но если это пользователь ABC, то он сможет только создать файл, прочитать файл и изменить файл, удаление не будет разрешено. Это известно как Авторизация.

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

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

На рисунках ниже показано, как работает учетная запись OAuth:

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

Источник

Использование ключей API при выполнении проверки подлинности в Когнитивном поиске Azure

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

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

Авторизация для операций с плоскостью данных с использованием управления доступом на основе ролей (RBAC) в Azure теперь доступна в предварительной версии. Эту возможность предварительного просмотра можно использовать для дополнения или замены ключей API с помощью ролей Azure для поиска.

Использование ключей API в поиске

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

В решениях REST ключ API обычно указывается в заголовке запроса.

Можно просматривать ключи API и управлять ими на портале Azure или с помощью PowerShell, Azure CLI или REST API.

Что представляет собой ключ API?

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

Для доступа к службе поиска используются два типа ключей: ключи администратора (для чтения и записи) и ключи запроса (только для чтения).

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

Поиск существующих ключей

Ключи доступа можно получить на портале или с помощью PowerShell, Azure CLI или REST API.

Выведите список служб поиска для вашей подписки.

Создание ключей запросов

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

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

Выведите список служб поиска для вашей подписки.

выберите службу и на странице обзор щелкните Параметры ключи.

Выберите Управление ключами запросов.

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

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

Повторное создание ключей администратора

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

Если непреднамеренно повторно создать оба ключа одновременно, все клиентские запросы, использующие эти ключи, завершатся ошибкой HTTP 403 Forbidden. Однако содержимое не удаляется, и блокировка устанавливается не на постоянной основе.

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

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

Обеспечение безопасности ключей API

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

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

Источник

Безопасность 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»:

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. Например:

Cookie-Based Authentication

Cookie-Based Authentication использует механизм передачи Cookies в HTTP запросах. В ответ на запрос клиента сервер посылает заголовок Set-Cookie, который содержит имя и значение cookie, а также дополнительные атрибуты: expires, domain, path, secure, httponly. Пример отправки cookie:

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

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

Token-Based Authentication

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

X-Powered-By

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

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

HTTP Strict Transport Security (HSTS)

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

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

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

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

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

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

Content-Security-Policy

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

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

X-Content-Type-Options

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

Cache-Control

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

Заключение

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

Источник