Как безопасно передавать аутентификацию в REST API?

Question

Наш веб-сервер реализует безстоящий JSON API (без входа в систему). До сих пор все наши конечные точки не были POST -только с информацией аутентификации, включенной в POST теле:

POST /api/getData 
{ 
    "apiKey": "I5r8ccXa8BLgoO50iZpunOGyf0h5e28L1exNpV5m5LI" 
    "userId": "8A7tRggxWjyQ+grQIwkAswtaityHhtQm0NTFGD5wnmM=" 
    "passwordAuth": "p0/yv/Ptv8kOAY1k2NpR9EhwvGA/n/DF79JGaKJmF/k=" 
    "otpToken": "913012" 
} 

Это не очень REST-FUL, очевидно. Мы хотели бы использовать HTTP GET запросы на наши запросы только для чтения, но это означает, что вы отправляете информацию аутентификации по-другому. Существует много возможностей:

• Положить это в URI?
• Положить это в файл cookie?
• Поместите его в пользовательский HTTP-заголовок Authentication?
• Придумайте наши собственные HTTP-заголовки?

Какой из них лучше, и почему? Или, является ли тело POST безопасным способом передачи произвольной информации аутентификации?

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

Answer 1

Все пять вариантов в основном работают, но каждый из них представляют свои собственные компромиссные решения:

• URI часто попадают в журналы. Если в URI содержится какая-либо конфиденциальная информация, вам придется либо санировать журналы вашего сервера, либо рассматривать их с тем же уровнем безопасности, что и ваша база данных паролей. Оба варианта сосут.
• Браузеры автоматически отправляют файлы cookie с каждым запросом. Если злоумышленник может обмануть пользователя при посещении URI, например your-app.com/resetpassword (например, помещая его в тег <img>), запрос будет полностью аутентифицирован. Злоумышленнику даже не нужно знать, какие учетные данные -, чтобы это работало. Это называется ошибкой CSRF.
• Пользовательские протоколы Authentication действительно разрешены спецификацией HTTP, но многие фреймворки ориентированы на стандартные механизмы. Если вы пройдете этот маршрут, вы можете закончить свои собственные инструменты, чтобы заставить все работать.
• Пользовательские заголовки обычно полезны. Многие методы защиты CSRF полагаются на пользовательский заголовок, например X-Csrf-Token, и нет никаких проблем с совместимостью.

Учитывая все это, пользовательские заголовки HTTP могут быть для вашего приложения.