2

SharePoint は、フェデレーション認証のプロトコルとして SAML 1.1 を使用します。ユーザーは信頼できる ID プロバイダーにログインし、SharePoint へのログイン手段として SAML トークンが SharePoint サイトに投稿されます。

SAML トークンの有効期間がユーザーのセッションに直接結びついていることに驚きました。デフォルトでは、これは 10 時間のように見えますが、これは寛大に思えます。

SAML トークンを SharePoint に発行する場合、リプレイ攻撃に対してどのようなガードがありますか? このトークン ポストは、ユーザー セッションの存続期間中再生可能のようです。トークンの有効期間は、認証に十分な長さであると予想していました。不足しているものはありますか、それともセキュリティ ホールですか?

4

1 に答える 1

3

SharePoint でのセッションの有効期間は、SAML トークンの有効期間ではなく、SAML トークンの ValidTo プロパティ (つまり、絶対日時) と等しくなるため、リプレイはその絶対時間まで機能します。

しかし、それだけではありません。SharePoint は、 と呼ばれる内部プロパティ (既定では 10 分) にも依存していますLogonTokenCacheExpirationWindow。私の意見では、それはどのような値よりも混乱を招きますが、それはそこにあり、セッションの有効性はそれに依存することを理解する必要があります

疑似コードでは、これは SharePoint 内で発生することです

SessionToken Lifetime = SAML Token Lifetime (by default)
if (SessionToken Lifetime - LogonTokenCacheExpirationWindow < DateTime.UtcNow)
    Logout()

ここに、LogonTokenExpirationWindow = 40 分、SAML トークンの有効期間 1 時間の図があります。

は次のLogonTokenCacheExpirationWindowように変更できます。

$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1)
$sts.Update()

SAML トークンの有効期間 (ADFS を使用する場合) は、次のように変更できます。

Set-ADFSRelyingPartyTrust -TargetName "My SP2010" -TokenLifetime 5

最後に、SharePoint は既定で永続的な Cookie を発行することに注意してください。そのため、ブラウザーを閉じて再度開くと、その永続的な Cookie が使用されます。設定することで変更できます

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset
于 2013-04-04T17:17:23.843 に答える