Warning: file_get_contents(/data/phpspider/zhask/data//catemap/7/wcf/4.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Wcf 时间戳如何帮助防止Web服务中的重播攻击_Wcf_Web Services_Security_Web_Timestamp - Fatal编程技术网

Wcf 时间戳如何帮助防止Web服务中的重播攻击

Wcf 时间戳如何帮助防止Web服务中的重播攻击,wcf,web-services,security,web,timestamp,Wcf,Web Services,Security,Web,Timestamp,我试图理解web服务中请求头中时间戳的概念,但不知何故仍然无法完全理解它是如何工作的 如果有人能解释一下在web服务的请求和响应中时间戳的端到端使用,我将不胜感激 这真的是一种防止重播攻击的万无一失的方法吗?时间戳本身是不够的,但通常它与哈希机制相结合,以确保值没有被篡改 其思想是客户端生成参数,并使用其私钥对参数进行散列。然后将[哈希+原始值+公钥]与请求一起发送。服务器可以使用公钥查找私钥,并确保参数正确 时间戳与一些阈值一起使用,以确保特定请求不能被多次使用。如果阈值很小(几百毫秒),则实

我试图理解web服务中请求头中时间戳的概念,但不知何故仍然无法完全理解它是如何工作的

如果有人能解释一下在web服务的请求和响应中时间戳的端到端使用,我将不胜感激


这真的是一种防止重播攻击的万无一失的方法吗?

时间戳本身是不够的,但通常它与哈希机制相结合,以确保值没有被篡改

其思想是客户端生成参数,并使用其私钥对参数进行散列。然后将[哈希+原始值+公钥]与请求一起发送。服务器可以使用公钥查找私钥,并确保参数正确


时间戳与一些阈值一起使用,以确保特定请求不能被多次使用。如果阈值很小(几百毫秒),则实际上不可能进行重播攻击。

时间戳没有加密,应该在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>

2014-07-01T11:30:28.123+05:30
2014-07-01T11:35:28.123+05:30
如果过期时间在创建时间之后很短,则可以最小化重播攻击。 实际上,这不仅仅是时间戳。您应该将时间戳摘要添加到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>

TGgFBvglhb+jZCvjV0+OVNNAIVPBP5IVBJEQKTFACU=
因此,在服务器端,这些摘要必须匹配。即使这还不是全部,您也可以使用私钥对整个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> 
jdO5GIZ9v1VTngFZcMpz5hz62RwToq2W24A9KhJ5JNySZW1AHhd3s+eTduZZPD0Ok6Wtgzu5kquK
IINPDI5IBGJLG6MXGDBVKLD79RBDNBZFXSJFBTRR9R3MQZP9XFU7ZSJW3KBIZZ6JJJK3H+S2nNbUu
F7RFRNN53CIRTJ9RLKZQZMW7BDAFQ18DUFCR70MUSKMD4IQXYDGSCJEJGIQLE2PYWIDDDRUGPD
MUWUIN3DGB051QWCE75SVRKBKSTMFADMN3NKZMQ/JUQULOT0VW6WUFRMVLACL5C09SGPOCPOW2
kjbuWx/bI7Aj4nAaAnmAYsWKIA3xVao+nPBOWmM0Lg7kpC4Dr5DwahmjH0/78AVUUU23DEIM0KR0
YDg5CxD8MUuj24w8tAjuzoHrvcsIYw+vWCTKvucnXwTlZ+K3QFB6gkct2zVOyQeYaPpkAnmPYS3W
DDpNmsx3lDcNr+5QWTSUBSQAFDDJHT/zoOJ8+iZKY/RujOI5vfXVwgN

现在我们可以确保重播攻击是不可能的。因为其他任何人都不能拥有相同的私钥,因此无法更改时间戳并仍然拥有有效的签名

时间戳的值是否加密?服务器如何验证传入的请求具有有效的时间戳并且在threshold@Kunal-就像我说的,客户端对输入参数进行散列,并将散列与输入一起发送。哈希服务器作为防止篡改的校验和。服务器使用与用户公钥对应的私钥来计算他们自己的参数散列。如果两个哈希匹配,则您知道提供的值是合法的,并且未被篡改。@Kunal,没有时间戳未加密,它应该在soap头中。@Don-如果您使用soap。但是时间戳作为校验和的一部分被加密,这正是摘要的目的,它是参数的散列,用于验证它们是否被篡改。时间戳与哈希版本一起作为校验和发送。这不是一种仅适用于SOAP的技术,因为它也用于JSON web服务。