我试图理解Web服务中请求标头中的时间戳概念,但不知何故仍然无法完全理解它是如何工作的。
如果有人能够在Web服务的请求和响应中解释时间戳的端到端使用,我将不胜感激。
防止重播攻击真的是一种万无一失的方法吗?
答案 0 :(得分:6)
时间戳本身是不够的,但通常它与散列机制相结合,以保证值没有被篡改。
这个想法是客户端生成参数,并使用它们的私钥来散列参数。然后随请求一起发送[hash + original values + public key]。服务器可以使用公钥来查找私钥,并确保参数正确。
使用时间戳和一些阈值,以确保不能多次使用特定请求。如果阈值很小(几百毫秒),则几乎不可能进行重放攻击。
答案 1 :(得分:2)
时间戳未加密,应该在soap标题中。
<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>
现在我们可以确保无法进行重播攻击。由于其他人不能拥有相同的私钥,因此无法更改时间戳并仍然具有有效签名。