IBM Mobile First 8.0 oAuth flow «client_id» и «redirect_uri», выставленные в запросе GET

Мы используем платформу IBM Mobile First 8.0 с нашим приложением IOS. Структура использует поток oAuth2.0 для потока аутентификации.IBM Mobile First 8.0 oAuth flow «client_id» и «redirect_uri», выставленные в запросе GET

Я вижу, что client_id и redirect_uri передаются в конечную точку авторизации в запросе GET. Кажется, что этот поток действительно заботится о платформе Mobile First, и я не контролирую его.

 
    response_type=code 
    scope= 
    client_id=CLIENT_ID 
    redirect_uri=REDIRECT_URL

Каковы уязвимости разоблачения "client_id" и "redirect_uri" в GET запрос?

EDIT:
Я изменил адрес redirect_uri в коде и отправил запрос на конечную точку авторизации.

http://mobilefirstserver:port/mfp/api/az/v1/authorization?response_type=code&client_id=CLIENT_ID&scope=SCOPE&redirect_uri=http://hackerserver:port/context/getdata

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

Это то, что я вижу, authorization_code передается хакерскому серверу. http://hackerserver:port/context/getdata?code=authorization_code

источник

2016-12-22 Vignesh Sn

Эти два параметра не считаются «секретами», поскольку они просто идентифицируют клиента и URL-адрес, на который он будет перенаправлен после успеха авторизации. Отказ от ответственности: Я работал в команде, которая фактически реализовала это на платформе Mobile First Mobile – iddo

, можно ли tweek «redirect_uri» и изменить какое-то другое значение, например evil.com? –

Учитывая, что он использует SSL-транспорт, и значение белого списка на стороне сервера (должно быть, обратитесь в службу поддержки IBM для подтверждения) - это значение следует считать безопасным (если код не исправляется, конечно). В зависимости от вашей конкретной конфигурации (это отличается только при использовании веб-клиента, в отличие от iOS в вашем случае), это значение генерируется и используется внутри платформы платформой, чтобы сигнализировать об успешной авторизации, поэтому я думаю, что вы в безопасности (Я больше не являюсь частью этого проекта, и он, возможно, изменился - я работаю только по моим ограниченным знаниям). – iddo

Известных рисков для этих значений не существует. Эти значения используются с другими зашифрованными данными в клиентском SDK для идентификации клиента. Их самих недостаточно.

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

источник

2016-12-26 07:47:30

- это их белый список, сделанный для redirect_uri на уровне рамки? –

Я изменил redirect_uri в коде и отправил запрос в конечную точку авторизации. http: // mobilefirstserver: port/mfp/api/az/v1/authorization? Response_type = code & client_id = CLIENT_ID & scope = SCOPE & redirect_uri = http: // hackerserver: port/context/getdata Я думал, что это был какой-то белый список, выполненный на уровне фрейма но это не так. Это то, что я вижу, authorization_code передается в хакерсервер. http: // hackerserver: port/context/getdata? Code = authorization_code –

IBM Mobile First 8.0 oAuth flow «client_id» и «redirect_uri», выставленные в запросе GET

ответ

Смежные вопросы