Menu
I am trying to understand the concept of timestamps in request headers in web services but somehow still can't understand fully how it works.
I would appreciate it if someone can explain the end-to-end use of timestamps in request and response of web services.
Is it really a foolproof method of preventing replay attacks?
355
So, the real question is, how can we protect ourselves from such attacks? The first way to prevent replay attacks is to attach timestamps or sequence numbers to each sent message. This will allow the receiver to discard any message with a repeated timestamp or sequence number.
Replay attacks can be prevented by tagging each encrypted component with a session ID and a component number. This combination of solutions does not use anything that is interdependent on one another. Due to the fact that there is no interdependency, there are fewer vulnerabilities.
Stopping a Replay Attack All he or she has to do is capture and resend the entire thing — message and key — together. To counter this possibility, both sender and receiver should establish a completely random session key, which is a type of code that is only valid for one transaction and can't be used again.
If an attacker can capture packets, save them and modify them, and then send them to the destination, then they can impersonate a machine when that machine is not on the network. This is what we call a replay attack. IPSec will prevent this from happening by including the sender's signature on all packets.
A Web service exposed over HTTP can be vulnerable in many ways. The most common attack, and the easy one, is the replay attack. A replay attack is a situation where an attacker gets hold of the Web service request along with the valid input parameters and performs repeated hits, either manually or in an automated fashion.
Or worse, some malicious user intercepts your request, figures out it’s a payment transaction, and repeats it in order to siphon your funds and spite you. In order to prevent a POST request from being repeated, we update the markup to add a hidden field, which will store the token.
Write powerful, clean and maintainable JavaScript. Get the book free! This article was originally published at Ben’s Tech Talks site. Replay attacks, in which attackers intercept and resend network packets that do not belong to them, are extremely dangerous and can in some cases cause serious damage.
A timestamp by itself wouldn't be sufficient, but usually it is combined with a hashing mechanism to guarantee that the values haven't been tampered with.
The idea is that the client generates the parameters, and uses their private key to hash the parameters. The [hash + original values + public key] are then sent with the request. The server can use the public key to look up the private key, and ensure that the parameters are correct.
The timestamp is used, along with some threshold, to ensure that particular request can't be used more than once. If the threshold is small (a few hundred milliseconds) then a replay attack is virtually impossible.
185
Timestamp is not encrypted and it should be in soap header.
<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>
If expires time is little after Created time, it can minimize replay attack. Actually it is not just the timestamp. You should add digest of timestamp to SignedInfo section.
<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>
So at the server side these digests must match. Even that is not all, then you sign whole signedInfo with private key and add signature value to Signature element as following.
<ds:SignatureValue>jdO5GIZ9v1VTngFZcMpz5hz62RwToq2W24A9KhJ5JNySZW1AHhd3s+eTduZZPD0Ok6Wtgzu5kquK
IinPdi5IbGjlg6mXGDbVkLd79RBdnbzFxsJFBtRr9r3mQZp9xfU7zSJW3kbizz6Jjk3h+S2nNbUu
f7rFrNN53ciRtj9RlKzQzmW7BDaFuq18DUfcr70muSkmd4DIqxYDGScjEjgIqLE2pYwIdDDRUGPD
MuwuIN3DgB051QwcE75SVrKBKsTHmFADmN3nKzmQ/JUQuLot0vW6WUFRMLVlAcl5C09SGPOcpow2
kjbuWx/bI7Aj4nAaAnmAYsWKIA3xVao+nPBOWmM0Lg7kpC4Dr5DwahmjH0/78aVUU23DEiMc0kR0
YDg5CxD8MUuj24w8tAjuzoHrvcsIYw+vWCTKvucnXwTlZ+K3QFB6gkct2zVOyQeYaPpkAnmPYS3W
DDpNmsx3lDcNr+5QWTsUbSQaFDddjHT/zoOJ8+iZKY/RujOI5vfXVwgN</ds:SignatureValue>
Now we can make sure that replay attacks are not possible. Since anyone else cannot have the same private key and so there is no way to alter timestamps and still have a valid signature.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
