Как мне обеспечить отдых API?

Question

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

Я пробовал jwt, но не получил желаемого результата. Может быть, я не мог.

Вот это express.js

const app = require('express')()
const express = require('express')
const fs = require('fs')
const cors = require('cors')
const bodyParser = require('body-parser');
app.use(cors())
app.use(bodyParser.json())

app.get('/', (req, res) => {
  res.json({message: 'Rest API Work'})
})

app.get('/list', (req, res) => {
    fs.readFile('data1.json','utf-8',(err,data)=>{
    res.setHeader("Content-Type", "application/json; charset=utf-8")
        data = JSON.parse(data)
        console.log(data)
        res.end(JSON.stringify(data,null,4))
    })
})



app.listen(3002, function(){
  console.log('Server OK')  
})

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

Answer 1

Лучший способ защитить ваш API - начать использовать обратный прокси-сервер, такой как Nginx.Каркасы Javascript в основном одинаковы с точки зрения безопасности.Все они имеют базовый обработчик маршрутизатора, диспетчер (основанный на собственной HTTP-библиотеке Node.js) и некоторые базовые вспомогательные методы, они дают ему хорошее броское имя и все.Я проверил исходный код почти всех основных платформ.Теперь некоторые основные параметры конфигурации Nginx: client_body_buffer_size proxy_buffers и т. Д. Все ваши директивы также должны пересматривать входные данные.Обычно все, что может «фильтровать» вредоносный код, полезно.Cloudflare может как-то помочь и некоторым другим компаниям, которые могут защитить ваше приложение, но они дорогие.Еще один хороший пример - контейнеризация вашего приложения с помощью Docker.
Если у вас есть базовый кусок кода в Node.js, самый простой способ взломать его - это через логику вашего приложения.Вы должны использовать анти-XSS модули, такие как xss или express-sanitizer.Если вы используете базу данных SQL, вам всегда следует избегать значений запроса.

Answer 2

Предположения

Я работаю с приложением Angular.

Я предполагаю, что вы делаете веб-приложение, а не мобильное приложение с чем-то вродеNativeScript.

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

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

ПОЗВОЛЯЕТ ВАШИМ ВОПРОСАМ

На каком языке, библиотеке или фреймворке я могу его защитить?

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

И пользователи используют приложение без членства.

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

Подождите, подождите секунду ... Вы продолжаете ссылаться на WHO и WHAT , вы хотите объяснить это более подробно?

Рад, что вы спросили;)

Разница между ВОЗ и ЧТО имеет доступ к серверу API

Итак, давайте разберемся с общимзаблуждение среди разработчиков о том, что WHO и WHAT обращается к серверу API.

Чтобы лучше понять различия между WHO и ЧТО обращаются к серверу API, давайте используем эту картинку:

Так что замените мобильное приложение на веб-приложение и продолжайте следовать моей аналогии с этой картинкой.

Предполагаемый канал связи представляет собой веб-приложение, используемое, как вы ожидали, легальным пользователем без каких-либо злонамеренных намерений, связывающееся с сервером API из браузера, не использующее Postman или любое другое средство для работы с человеком.в середине (MitM)ack.

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

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

WHO является пользователем веб-приложения, которое мы можем аутентифицировать, авторизовывать и идентифицировать несколькими способами, напримериспользуя OpenID Connect или потоки OAUTH2.

OAUTH

Как правило, OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса.Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных.Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса.Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.

OpenID Connect

OpenID Connect 1.0 представляет собой простой слой идентификации поверхпротокол OAuth 2.0.Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.

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

Теперь нам нужен способ определить, ЧТО вызывает API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. WHAT - это то, что делает запрос к серверу API.Действительно ли это подлинный экземпляр веб-приложения, или это бот, автоматизированный скрипт или злоумышленник, работающий вручную с API-сервером и использующий такой инструмент, как Postman?

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

Ну, чтобы определить ЧТО, разработчики склонны прибегать к API-ключу, который обычно отправляется в заголовках веб-приложения.Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в веб-приложении, внутри запутанного javascript, таким образом, он становится секретом времени выполнения, который может быть подвергнут обратному проектированию с помощью инструментов устранения сбоев и проверки трафика между веб-приложением и APIсервер с инструментами F12 или MitM.

Приведенная выше статья взята из написанной мною статьи под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API? .Хотя в контексте мобильного приложения общая идея остается в силе в контексте веб-приложения.Вы хотите, чтобы вы могли прочитать статью полностью здесь , это первая статья в серии статей о ключах API.

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

Защита сервера API

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

Так что все, что работает на стороне клиента и нуждается в секрете для доступа кС API можно злоупотреблять по-разному, и вы можете узнать больше о этой серии статей о технологиях безопасности мобильного API.Хотя эти статьи относятся к API, обслуживающему мобильное приложение, часть контента применима к API, обслуживающему веб-приложение, и поможет вам понять, насколько хрупок API, когда он отличается от КТО и ЧТО получает к нему доступ.Поэтому в этой серии статей вы узнаете, как можно использовать ключи API, токены доступа пользователей, HMAC и TLS Pinning для защиты API и как их можно обойти.

Теперь, когда вы в большей степени осведомлены о трудностях защиты сервера API, давайте посмотрим, что можно сделать, чтобы уменьшить риски безопасности, с которыми сталкивается в контексте веб-приложения.Для API, обслуживающего веб-приложение, вы можете использовать несколько плотных уровней, начиная с reCaptcha V3 , затем Брандмауэр веб-приложений (WAF) и, наконец, если вы можете себе это позволить Решение для анализа поведения пользователей (UBA).

Google reCAPTCHA V3 :

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

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

WAF - брандмауэр веб-приложений :

Брандмауэр веб-приложений (или WAF) фильтрует, отслеживает и блокирует HTTP-трафик в веб-приложение и из него.WAF отличается от обычного брандмауэра тем, что WAF может фильтровать содержимое определенных веб-приложений, в то время как обычные брандмауэры служат в качестве шлюза безопасности между серверами.Проверяя HTTP-трафик, он может предотвратить атаки, связанные с недостатками безопасности веб-приложений, такими как внедрение SQL, межсайтовый скриптинг (XSS), включение файлов и неправильная конфигурация безопасности.

UBA -Аналитика поведения пользователя :

Аналитика поведения пользователя (UBA) по определению Gartner - это процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества.Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы.Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.Платформы больших данных, такие как Apache Hadoop, расширяют функциональность UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.

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

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

ЗАКЛЮЧЕНИЕ

Мне нужен простой метод защиты, с помощью которого я могу соединиться с Angular.

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

Итак, в конце концов, решение дляиспользование для защиты вашего API-сервера должно быть выбрано в соответствии со стоимостью того, что вы пытаетесь защитить, и с юридическими требованиями к данным такого типа, например, с правилами GDPR в Европе.