Стандарты Американского института нефти API

Что такое американский институт нефти api и его спецификации?

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

В 2021 году Американский институт нефти празднует 100-летие со дня основания!

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

Членами Института являются все ведущие компании, работающие на североамериканском рынке и, следовательно, все ведущие мировые компании нефтегазовой отрасли – Shell, BP, Total, Chevron, и т.д. Стандарты API разрабатываются специалистами  данных организаций.

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

Api key

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

Api как способ обслуживания клиентов

Многие компании предлагают API как готовый продукт. Например, Weather Underground продаёт доступ к своему API для получения метеорологических данных.

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

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

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

Api1:2021 broken object level authorization (недостатки контроля доступа к объектам)

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

Api10:2021 insufficient logging & monitoring (недостатки журналирования и мониторинга)

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

Api3:2021 excessive data exposure (разглашение конфиденциальных данных)

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

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

Api4:2021 lack of resources & rate limiting (отсутствие проверок и ограничений)

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

Для JS существуют средства, позволяющие делать такие проверки автоматически (например,

) и сразу посылать ответ «429 Too Many Requests», не нагружая сервер.

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

Например, сервер ожидает в параметре size число записей:

Api5:2021 broken function level authorization (недостатки контроля доступа на функциональном уровне)

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

Api6:2021 mass assignment (небезопасная десериализация)

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

Api7:2021 security misconfiguration (некорректная настройка параметров безопасности)

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

Api8:2021 injection (внедрение)

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

Атака будет успешна, если сервер выполняет полученные команды без проверки. Чем-то напоминает «небезопасную десериализацию», только используются не дополнительные атрибуты, а SQL код или команды OS. В результате SQL инъекции можно получить несанкционированный доступ к данным.

GET /run

Api9:2021 improper assets management (недостатки управления api)

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

Cache-control

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

Cache-Control: no-store

Content-security-policy

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

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

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

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

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

Access-Control-Allow-Origin: *

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

Insecure cookies and local storage (небезопасные cookies и данные в local storage)

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

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

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

Token-based authentication

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

Using components with known vulnerabilities (использование компонент с известными уязвимостями)

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

X-content-type-options

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

X-Content-Type-Options: nosniff

X-frame-options (защита от clickjacking)

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

X-Frame-Options: deny

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

X-Frame-Options: sameorigin

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

Content-Security-Policy

X-powered-by

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

X-Powered-By: Express

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

Алгоритм token-based authentication

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

Всемирная паутина и удалённые серверы

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

Выгоды от внедрения и сертификации

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

Ещё несколько примеров api

Слово «application» (прикладной, приложение) может применяться в разных значениях. В контексте API оно подразумевает:

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

Любой фрагмент ПО, который можно чётко выделить из окружения, может заменять букву «А» в англоязычной аббревиатуре, и тоже может иметь некоторого рода API. Например, при внедрении в код разработчиком сторонней библиотеки, она становится частью всего приложения.

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

Обучение по стандартам американского института нефти api-u

Сертификация по программам apiqr и monogram

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

Специалисты и эксперты глобал эксперт груп помогут вам:

• Внедрить на производстве требования к продукции и в области менеджмента (API Q1 или Q2), СМК по API Q1 необходимо как при сертификации системы менеджмента, так и при сертификации продукции по программе Monogram!

• Определить цену и сроки оказания услуг.

• Помочь официально купить необходимые спецификации и обеспечить перевод необходимой документации на английский язык для прохождения сертификации. Купить стандарт Американского института нефти Вы можете у одного из официальных дистрибьюторов API). Стоимость документа составляет от 40 до 400 долларов США.

• Подать заявку и организовать оплату услуг American Petroleum Institute за рассмотрение заявки и проведение аудита на площадке,

• Правильно сформулировать, внедрить и предоставить отчет о корректирующих действиях,

• Обеспечить оперативную взаимосвязь по вопросам подтверждения соответствия  с штаб-квартирой Американского института нефти в Хьюстоне.

Мы помогаем пройти процедуру подтверждения соответствия продукции по программам Американского института нефти, попасть в реестр Американского института нефти (API Composite List). Данный реестр является международным инструментом для поиска поставщиков нефтегазовых компаний в разных странах!

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

Желаю всем легкодоступных, но безопасных API! )

It’s only the beginning!

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

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

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

Добавлю пункты, которые

, но относятся к нашей теме:

А также уязвимости из списка другой организации Common Weakness Enumeration (CWE):

И несколько пунктов из других найденных списков:

В результате получился список, который, на мой взгляд, достаточно полно отражает современные проблемы безопасности API. Для проверки того, что список получился общим и применимым для всех технологий я использовал рекомендации по безопасности API, найденные на просторах Интернета (ссылки приведены в конце статьи). Далее рассмотрим все перечисленные пункты.

Чем api google календаря отличается от api любого другого удалённого сервера в сети?

Технически, разница в формате запроса и ответа. Чтобы сгенерировать полную веб-страницу, браузер ожидает ответ на языке разметки HTML, в то время как API Google Календаря вернёт просто данные в формате вроде JSON.

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

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

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

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

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

Чем мы можем вам помочь:

Заключение

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