Как защитить запросы Rails API?

#ruby-on-rails #ruby #security #activerecord #ruby-on-rails-5

#ruby-on-rails #ruby #Безопасность #activerecord #ruby-on-rails-5

Вопрос:

У меня есть приложение rails только для API и другое приложение angular в качестве интерфейса

В настоящее время я защищаю API, отправляя X-APP-Token с каждым запросом в заголовках

Другие API, которые вошли в систему пользователя, имеют X-User-Token в заголовках как (JWT)

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

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

Заранее спасибо

Ответ №1:

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

  1. Контроль доступа или управление на основе ролей, это очень важно, если вы хотите защитить свой API, вам нужно включить какие-то «Политики», которые помогут вам управлять доступом к ресурсам в вашем API, чтобы защитить ваши данные (это тоже хорошие варианты, если вы спросите меня Pundit, CanCan,оба хороши, хотя я предпочитаю Pundit), это один из способов избежать того, чтобы пользователь / взломщик, использующий другой пользовательский ключ / токен доступа, получил доступ к ресурсу, который не является частью его «домена».
  2. Вам нужно добавить соответствующие заголовки безопасности к каждому ответу серверной части, эта конфигурация зависит от вашего API и вашего приложения, с учетом сказанного вы можете добавить приведенный ниже код, например, в свой контроллер приложений (ниже приведен хороший пример конфигурации по умолчанию):
 before_action :set_headers

  def set_headers
    response.set_header('Referrer-Policy', 'strict-origin-when-cross-origin')
    response.set_header('X-Content-Type-Options', 'nosniff')
    response.set_header('X-Frame-Options', 'SAMEORIGIN')
    response.set_header('X-XSS-Protection', '1; mode=block')
    response.set_header('Content-Security-Policy', "default-src 'self' https:; " 
        "img-src 'self' https:" 
        "media-src 'none'; " 
        "object-src 'none'; " 
        "script-src 'self'; " 
        "style-src 'self' ")
  end
 
  1. Поскольку вы находитесь в, rails 5.x вы можете перейти к конфигурации вашей среды, скажем, production.rb, и добавить следующую строку: config.force_ssl = true , это принудительно подключит все соединения к вашему API, HTTPS а также добавит этот заголовок ответа strict-transport-security , который повысит безопасность, имейте в виду, что если вы попытаетесь получить доступ к своему API через HTTP свой API, это приведет кпопробуйте принудительно HTTPS и в некоторых сценариях возвращайте код 301 , который означает перенаправление, это хороший намек на случай, если у вас есть проверка работоспособности.
  2. Определенно, вам нужно позаботиться о распространенных проблемах, таких как небезопасная прямая ссылка на объект (IDOR), эта проблема, как указывает его имя, возникает, когда у вас есть прямые ссылки на частные ресурсы, скажем, в URL вашего приложения у вас есть что-то вроде ***/shop/23 , где 23 идентификатор автоинкремента вашей модели, я думаю, я не знаюне нужно объяснять, почему это неправильно, с этого момента вы можете подвергаться атакам перечисления, доступу к информации (чего следует избегать с помощью авторизации), уничтожению объектов и т. Д. В этих случаях одним из возможных подходов является использование косвенных ссылок или изменение этого идентификатора на значение, которое невозможно угадать.
  3. И последнее, но не менее важное: вам необходимо включить надлежащие политики паролей для ваших пользователей. вы можете посмотреть на других сайтах или проконсультироваться с NSA для получения такой информации.

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

Комментарии:

1. Большое вам спасибо за ваш подробный ответ, но прежде чем я смогу пометить его как ответ, мне просто нужно уточнить, что я использую CanCan, который не позволяет пользователям получать доступ к материалам, к которым они не должны обращаться, а что касается SSL, он будет там в производстве, но все же мой вопроспринудительное использование SSL и добавление вышеуказанных заголовков предотвратит ли это доступ к токенам, отправленным в заголовках? В частности, пользовательский токен, это JWT с истекшим сроком действия, но он может быть достаточно длинным, чтобы злоумышленник мог использовать его для доступа к API от имени этого пользователя, если не хватает чего-то еще, я ценю ваше терпение со мной 🙂

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

3. @Amir El-Bashary, да, с принудительным подключением ssl (только для трафика https), а также добавлением надлежащей политики cors и т. Д. (Эта политика зависит от вашего сайта), Вы защитите любые данные, отправленные из вашего интерфейсного приложения (Angular) в ваш API, почему? потому что, делая это, вы сериализуете весь трафик

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

5. Большое вам спасибо, я ценю ваше время, я получил ответы почти на 80% всех своих вопросов 🙂

Ответ №2:

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

Редактировать: Кроме того, может быть, вам нужно уточнить «Мой вопрос здесь, при каждом запросе, отправленном из angular, токен отображается в заголовках, и любой может иметь к ним доступ» — мне любопытно, как кто-либо может иметь доступ к этим заголовкам? Также ваш JWT должен быть подписан и иметь установленное время истечения, которое соблюдается сервером приложений.

Комментарии:

1. Поскольку, когда мы проводили тест без SSL на сервере API и интерфейсном клиенте, я мог видеть заголовки запроса на вкладке сеть, я не уверен, что это проблема во внешнем интерфейсе, поскольку я не являюсь разработчиком внешнего интерфейса. Это то, что я имел в виду под своим вопросом, и под подписанным вы подразумеваете подписанные файлы cookie в ответе API сеансов?