#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 вот некоторые из наиболее важных мер безопасности, основанных на моем опыте:
- Контроль доступа или управление на основе ролей, это очень важно, если вы хотите защитить свой API, вам нужно включить какие-то «Политики», которые помогут вам управлять доступом к ресурсам в вашем API, чтобы защитить ваши данные (это тоже хорошие варианты, если вы спросите меня Pundit, CanCan,оба хороши, хотя я предпочитаю Pundit), это один из способов избежать того, чтобы пользователь / взломщик, использующий другой пользовательский ключ / токен доступа, получил доступ к ресурсу, который не является частью его «домена».
- Вам нужно добавить соответствующие заголовки безопасности к каждому ответу серверной части, эта конфигурация зависит от вашего 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
- Поскольку вы находитесь в,
rails 5.x
вы можете перейти к конфигурации вашей среды, скажем, production.rb, и добавить следующую строку:config.force_ssl = true
, это принудительно подключит все соединения к вашему API,HTTPS
а также добавит этот заголовок ответаstrict-transport-security
, который повысит безопасность, имейте в виду, что если вы попытаетесь получить доступ к своему API черезHTTP
свой API, это приведет кпопробуйте принудительноHTTPS
и в некоторых сценариях возвращайте код301
, который означает перенаправление, это хороший намек на случай, если у вас есть проверка работоспособности. - Определенно, вам нужно позаботиться о распространенных проблемах, таких как небезопасная прямая ссылка на объект (IDOR), эта проблема, как указывает его имя, возникает, когда у вас есть прямые ссылки на частные ресурсы, скажем, в URL вашего приложения у вас есть что-то вроде
***/shop/23
, где23
идентификатор автоинкремента вашей модели, я думаю, я не знаюне нужно объяснять, почему это неправильно, с этого момента вы можете подвергаться атакам перечисления, доступу к информации (чего следует избегать с помощью авторизации), уничтожению объектов и т. Д. В этих случаях одним из возможных подходов является использование косвенных ссылок или изменение этого идентификатора на значение, которое невозможно угадать. - И последнее, но не менее важное: вам необходимо включить надлежащие политики паролей для ваших пользователей. вы можете посмотреть на других сайтах или проконсультироваться с 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 сеансов?