我想了解Web服務中請求標頭中時間戳的概念,但不知何故仍不能完全理解它是如何工作的。Timestamp如何幫助防止Web服務中的重播攻擊
如果有人能夠解釋Web服務的請求和響應中的時間戳的端到端使用,我將不勝感激。
它真的是防止重播攻擊的萬無一失的方法嗎?
我想了解Web服務中請求標頭中時間戳的概念,但不知何故仍不能完全理解它是如何工作的。Timestamp如何幫助防止Web服務中的重播攻擊
如果有人能夠解釋Web服務的請求和響應中的時間戳的端到端使用,我將不勝感激。
它真的是防止重播攻擊的萬無一失的方法嗎?
時間戳本身並不足夠,但通常它與哈希機制相結合,以保證這些值不被篡改。
這個想法是,客戶端生成參數,並使用他們的私鑰來散列參數。 [hash +原始值+公共密鑰]隨後與請求一起發送。服務器可以使用公鑰查找私鑰,並確保參數是正確的。
使用時間戳和一些閾值來確保特定請求不能多次使用。如果閾值很小(幾百毫秒),那麼重放攻擊實際上是不可能的。
時間戳未加密,它應該在肥皂標題中。
<wsu:Timestamp wsu:Id="timestamp">
<wsu:Created>2014-07-01T11:30:28.123+05:30</wsu:Created>
<wsu:Expires>2014-07-01T11:35:28.123+05:30</wsu:Expires>
</wsu:Timestamp>
如果到期時間創建時間後很少,它可以減少重播攻擊。其實它不只是時間戳。您應該將時間戳的摘要添加到SignedInfo部分。
<ds:Reference URI="#timestamp">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="wsse soap" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>TGgFBvglhb+jZCvjV0+oVnNaivpVBp5iVbJEqkTfaCU=</ds:DigestValue>
</ds:Reference>
所以在服務器端這些摘要必須匹配。即使這並不是全部,那麼您使用私鑰簽署整個signedInfo並將簽名值添加到Signature元素,如下所示。
<ds:SignatureValue>jdO5GIZ9v1VTngFZcMpz5hz62RwToq2W24A9KhJ5JNySZW1AHhd3s+eTduZZPD0Ok6Wtgzu5kquK
IinPdi5IbGjlg6mXGDbVkLd79RBdnbzFxsJFBtRr9r3mQZp9xfU7zSJW3kbizz6Jjk3h+S2nNbUu
f7rFrNN53ciRtj9RlKzQzmW7BDaFuq18DUfcr70muSkmd4DIqxYDGScjEjgIqLE2pYwIdDDRUGPD
MuwuIN3DgB051QwcE75SVrKBKsTHmFADmN3nKzmQ/JUQuLot0vW6WUFRMLVlAcl5C09SGPOcpow2
kjbuWx/bI7Aj4nAaAnmAYsWKIA3xVao+nPBOWmM0Lg7kpC4Dr5DwahmjH0/78aVUU23DEiMc0kR0
YDg5CxD8MUuj24w8tAjuzoHrvcsIYw+vWCTKvucnXwTlZ+K3QFB6gkct2zVOyQeYaPpkAnmPYS3W
DDpNmsx3lDcNr+5QWTsUbSQaFDddjHT/zoOJ8+iZKY/RujOI5vfXVwgN</ds:SignatureValue>
現在我們可以確保重放攻擊是不可能的。由於其他人不能擁有相同的私鑰,因此無法更改時間戳並仍具有有效的簽名。
時間戳的值是否被加密?服務器如何驗證傳入的請求有一個有效的時間戳,並在閾值內 – 2012-04-05 03:43:59
@Kunal - 就像我說的客戶端散列輸入參數並將散列和輸入一起發送。哈希服務器作爲防篡改檢查總和。服務器使用與用戶公鑰對應的私鑰來計算他們自己的參數散列。如果兩個哈希匹配,那麼您知道提供的值是合法的,並且沒有被篡改。 – Josh 2012-04-05 13:38:13
@Kunal,沒有時間戳未加密,它應該在肥皂標題中。 – Don 2014-07-02 05:17:15