Должен ли один и тот же ответ SAML приниматься дважды, несколько раз?

Должно ли программное обеспечение федерации SAML принимать один и тот же ответ SAML, если он находится в пределах допустимого срока действия токена SAML?

Проще говоря: IDP (определение поставщика) выдает ответ SAML, затем SP (поставщик услуг) принимает/обрабатывает его. Можно ли повторно использовать тот же немодифицированный ответ SAML сразу же после первого использования? При условии, что временная метка выдачи SAML находится в допустимом диапазоне.

С точки зрения безопасности имеет смысл ограничить токен (ответ) SAML только одним использованием, так что даже если он будет украден «злоумышленником посередине», его нельзя будет использовать повторно. Но для того, чтобы реализовать это, программа должна где-то хранить некоторую информацию об ответе SAML: серийный номер, хэш всего этого?

Пожалуйста, предоставьте несколько ссылок с пояснениями о том, что возможно и/или примерами реализации.

Благодарю вас! Алекс.


saml single-sign-on opensaml soa
person Alex Kovshovik    schedule 14.03.2014    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Имеет ли это смысл с точки зрения безопасности? Конечно. И на самом деле вы можете использовать часть утверждения «xs:ID», чтобы помочь вам (программное обеспечение моей компании делает).

Со страницы 9 CORE :

Простой тип xs:ID используется для объявления идентификаторов SAML для утверждений, запросов и ответов. Значения, объявленные как имеющие тип xs:ID в этой спецификации, ДОЛЖНЫ удовлетворять следующим свойствам в дополнение к свойствам, налагаемым определением самого типа xs:ID:

• Любая сторона, присваивающая идентификатор, ДОЛЖНА обеспечить пренебрежимо малую вероятность того, что эта сторона или любая другая сторона случайно назначит тот же идентификатор другому объекту данных.

• Если объект данных объявляет, что он имеет конкретный идентификатор, ДОЛЖНО быть ровно одно такое объявление.

Мы выхватываем этот идентификатор из утверждения и помещаем его в массив со временем «не-после», а затем выбрасываем его по истечении этого времени. Таким образом, одно и то же утверждение не может быть воспроизведено.

В другом программном обеспечении (особенно в доморощенном) это полностью управляется с помощью части ограничения аудитории «Не до» и «Не на или после». Поскольку некоторые программы рассчитывают исключительно на эти значения, предлагаемый метод заключается в том, чтобы установить этот период настолько коротким, насколько это разумно. В идеальном мире все используют серверы времени, и расхождение их часов не превышает пары секунд. Минуты до и минуты после выпуска должно быть более чем достаточно. Хотя здесь не так много «безопасности», ею можно «управлять».

person Andrew K.    schedule 15.03.2014
comment
Спасибо, Энди. Мы действительно полагаемся только на NotBefore и NotAfter для истечения срока действия утверждений SAML. Похоже, что xs:ID — это просто еще один уровень безопасности: чтобы предотвратить повторное использование одного и того же утверждения. Имеет смысл! Благодарю вас! - person Alex Kovshovik; 16.03.2014

arrow_upward
10
arrow_downward

Норма SAML 2.0 предоставляет еще один способ предотвращения повторных атак, которые не подразумевают сохранение в базе данных идентификатора утверждения.

  • SP отправляет запрос с идентификатором = "X" и сохраняет этот идентификатор в сеансе.
  • IDP аутентифицирует пользователя и отправляет ответ с ID="Y" И InResponseTo="X" (который также обычно присутствует в утверждении в SubjectConfirmationData).
  • SP получает ответ и проверяет, что все значения InResponseTo совпадают со значением в сеансе. Если нет, SP отклоняет ответ.
  • SP очищает идентификатор в сеансе, что делает невозможным воспроизведение ответа. В идеальном случае SP должен очистить идентификатор в сеансе, как только получит ответ.

Эта проверка действительно усложняет повторную атаку, так как злоумышленнику также потребуется файл cookie сеанса SP (и даже в этом случае игра уже окончена...). Также рекомендуется подписывать весь ответ.

Очевидно, что этот метод действителен только в сценарии, инициированном SP.

person sk_    schedule 26.03.2014
comment
Это сработало бы для нас, но мы используем так называемый незапрашиваемый ответ SAML — IPD инициирует транзакцию. Спасибо, в любом случае! - person Alex Kovshovik; 27.03.2014
comment
Вы имеете в виду, что IDP инициирует транзакцию. - person Suraj Jain; 02.03.2020