Блог

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

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

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

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

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

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

Безопасность имеет много уровней, но есть некоторые вещи, которые вам обязательно нужно включить при защите вашего 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
 

3. Поскольку вы находитесь в, rails 5.x вы можете перейти к конфигурации вашей среды, скажем, production.rb, и добавить следующую строку: config.force_ssl = true , это принудительно подключит все соединения к вашему API, HTTPS а также добавит этот заголовок ответа strict-transport-security , который повысит безопасность, имейте в виду, что если вы попытаетесь получить доступ к своему API через HTTP свой API, это приведет кпопробуйте принудительно HTTPS и в некоторых сценариях возвращайте код 301 , который означает перенаправление, это хороший намек на случай, если у вас есть проверка работоспособности.
4. Определенно, вам нужно позаботиться о распространенных проблемах, таких как небезопасная прямая ссылка на объект (IDOR), эта проблема, как указывает его имя, возникает, когда у вас есть прямые ссылки на частные ресурсы, скажем, в URL вашего приложения у вас есть что-то вроде ***/shop/23 , где 23 идентификатор автоинкремента вашей модели, я думаю, я не знаюне нужно объяснять, почему это неправильно, с этого момента вы можете подвергаться атакам перечисления, доступу к информации (чего следует избегать с помощью авторизации), уничтожению объектов и т. Д. В этих случаях одним из возможных подходов является использование косвенных ссылок или изменение этого идентификатора на значение, которое невозможно угадать.
5. И последнее, но не менее важное: вам необходимо включить надлежащие политики паролей для ваших пользователей. вы можете посмотреть на других сайтах или проконсультироваться с NSA для получения такой информации.

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

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

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