OpenID Authentication 2.0 / OpenID Аутентификация 2.0: 15.1. Preventing Attacks

Прослушивание канала

Reyko32 20.09.12 в 05:35

Есть место в протоколе которое уязвимо для перехватывающих атак.

Reyko32 20.09.12 в 05:37

Если nonce не проверяется, перехватчик может также перехватить положительное утверждение идентификации и повторно его использовать.

Reyko32 20.09.12 в 05:39

Атаки могут быть предотвращены используя шифрование соединения на транспортном уровне для предотвращения перехвата данных. В дополнение, если не используется TLS, эти атаки могут так же быть предотвращены с помощью проверки nonce во время выполнения проверки сообщения. Когда это выполняется, положительное утверждение не может быть повторно использовано.

Reyko32 20.09.12 в 05:45

Атаки "Человек посередине"

Reyko32 20.09.12 в 05:47

Ассоциации предотвращают подделку подписанных полей человеком по середине, за исключением процесса получения информации(discovery), сессии ассоциации и прямая верификация. Изменение подписанных полей без открытого ключа требует разрушения MAC. В настоящее время неизвестно легко осуществимых атак на MAC используемых в этом протоколе. Качество защиты обеспечиваемой MAC зависит от того насколько случайный характер носят открытые MAC ключи, поэтому важно, чтобы использовались неопределяемые значения.

Reyko32 20.09.12 в 07:02

Если разрешения DNS или транспортный уровень находится под угрозой непригодный подписев в сообщении, так как злоумышленник может выдавать себя за Провайдера и выдавать свои собственные ассоциации, или свои собственные решения в режиме Stateless Mode. Если Злоумышленник может вмешаться в процесс получения информации, он может определить любого повайдера, и поэтому не должны обозначать Провайдера. Дополнительно, если злоумышленник может ставить под угрозу целостность информации, возвращаемый в течении процесса получения информации, путем изменения документа XRDS, необходимость «Человека по середине» отпадает. Один метод предотвращения – это цифровая подпись XRDS файла согласно XMLDSIG [RFC3275]. Категория ключей не определены, RP в конечном счете, должна сделать свое собственное решение, стоит ли доверять ключам, используемых для таких подписей.

Reyko32 20.09.12 в 07:33

Использование SSL с сертификатами, подписанными доверительными центрами сертификации, предотвращает эти типы атак с помощью проверки результатов поиском DNS от сертификата. Однажды подтвердив сертификат, подмена становиться невозможной. Подделка SSL сервера требует производства или кражу сертификата, что существенно сложнее сетевых атак.

Reyko32 20.09.12 в 08:11

Для того, чтобы получить защиту от SSL, SSL должно быть использовано на протяжение всех частей взаимодействия, включая взаимодействие с конечным пользователем по средствам браузера. Пока протокол не требует использования SSL, его использование настоятельно РЕКОМЕНДОВАНО. Лучшие современные практики предписывают, что Провайдеру СЛЕДУЕТ использовать SSL с сертификатом, подписанным доверительным центром сертификации, для защиты своей конечной точки (Endpoint URL), а так же свое взаимодействие с пользовательским агентом конечного пользователя. Так же, SSL, с сертификатом, подписанным доверительным центром сертификации, СЛЕДУЕТ использовать, чтобы Зависимая Сторона могла получить URL конечного пользователя безопасным способом. Следуя своей собственной политике безопасности Зависимая Сторона МОЖЕТ выбирать не заканчивать, или даже не начинать взаимодествие, если SSL не правильно используется у некоторых endpoints.

Reyko32 20.09.12 в 08:38

15.1.2.1. Проксирование мошеннической Зависимой Стороны

Reyko32 20.09.12 в 08:43

Особый тип атаки «Человек по середине» - это когда Зависимая Сторона является стороной злоумышленника и действует как MITM(«Человек по середине»). Зависимая Сторона будет производить получение данных по Заявленному Идентификатору(Claimed Identifier) Конечного Пользователя(End User) и вместо перенаправления Пользовательского Агента на Провайдера, вместо этого будет пропускать Провайдера через себя. Это позволит Зависимой стороне получить пользовательские данные предоставляемые Провайдером. Пока есть множество способов избежать данный тип атак, описание которых выходит за рамки этого документа. Каждый метод предотвращения требует чтобы Провайдер предоставил защищенный канал для работы с Конечным Пользователем.

Reyko32 20.09.12 в 09:13