Ich versuche, das Konzept der Zeitstempel in Request-Header in Web-Services zu verstehen, aber irgendwie kann immer noch nicht vollständig verstehen, wie es funktioniert.Wie hilft Timestamp Replay Attacks in Webservices zu verhindern?
Ich würde es schätzen, wenn jemand die Ende-zu-Ende-Verwendung von Zeitstempeln in Anfrage und Antwort von Webdiensten erklären kann.
Ist es wirklich eine idiotensichere Methode zur Verhinderung von Replay-Angriffen?
Ein Zeitstempel allein wäre nicht ausreichend, aber normalerweise wird er mit einem Hash-Mechanismus kombiniert, um zu garantieren, dass die Werte nicht manipuliert wurden.
Die Idee ist, dass der Client die Parameter generiert und ihren privaten Schlüssel verwendet, um die Parameter zu hashen. Die [Hash + Originalwerte + öffentlicher Schlüssel] werden dann mit der Anfrage gesendet. Der Server kann den öffentlichen Schlüssel verwenden, um den privaten Schlüssel nachzuschlagen und sicherzustellen, dass die Parameter korrekt sind.
Der Zeitstempel wird zusammen mit einem Schwellenwert verwendet, um sicherzustellen, dass bestimmte Anforderungen nicht mehrfach verwendet werden können. Wenn der Schwellenwert klein ist (einige hundert Millisekunden), ist ein Wiederholungsangriff praktisch unmöglich.
Zeitstempel ist nicht verschlüsselt und es sollte in Soap-Header sein.
<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>
Wenn die Zeit abgelaufen ist wird kurz nach Erstellt Zeit, kann es Replay-Attacke minimieren. Eigentlich ist es nicht nur der Zeitstempel. Sie sollten Digest des Zeitstempels zum SignedInfo-Abschnitt hinzufügen.
<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>
Also auf der Serverseite müssen diese Digests übereinstimmen. Auch das ist nicht alles, dann signierst du die gesamte signedInfo mit dem privaten Schlüssel und fügst dem Signature-Element den Signaturwert wie folgt hinzu.
<ds:SignatureValue>jdO5GIZ9v1VTngFZcMpz5hz62RwToq2W24A9KhJ5JNySZW1AHhd3s+eTduZZPD0Ok6Wtgzu5kquK
IinPdi5IbGjlg6mXGDbVkLd79RBdnbzFxsJFBtRr9r3mQZp9xfU7zSJW3kbizz6Jjk3h+S2nNbUu
f7rFrNN53ciRtj9RlKzQzmW7BDaFuq18DUfcr70muSkmd4DIqxYDGScjEjgIqLE2pYwIdDDRUGPD
MuwuIN3DgB051QwcE75SVrKBKsTHmFADmN3nKzmQ/JUQuLot0vW6WUFRMLVlAcl5C09SGPOcpow2
kjbuWx/bI7Aj4nAaAnmAYsWKIA3xVao+nPBOWmM0Lg7kpC4Dr5DwahmjH0/78aVUU23DEiMc0kR0
YDg5CxD8MUuj24w8tAjuzoHrvcsIYw+vWCTKvucnXwTlZ+K3QFB6gkct2zVOyQeYaPpkAnmPYS3W
DDpNmsx3lDcNr+5QWTsUbSQaFDddjHT/zoOJ8+iZKY/RujOI5vfXVwgN</ds:SignatureValue>
Jetzt können wir sicherstellen, dass Replay-Angriffe nicht möglich sind. Da niemand sonst den gleichen privaten Schlüssel haben kann, gibt es keine Möglichkeit, Zeitstempel zu ändern und trotzdem eine gültige Signatur zu haben.
Ist der Wert des Zeitstempels verschlüsselt? Wie validiert der Server, dass die eingehende Anfrage einen gültigen Zeitstempel hat und innerhalb des Schwellenwerts liegt –
@Kunal - Wie ich bereits sagte, hashed der Client die Eingabeparameter und sendet den Hash zusammen mit den Eingaben. Die Hash-Server als Check-Summe gegen Manipulationen. Der Server verwendet den privaten Schlüssel, der dem öffentlichen Schlüssel des Benutzers entspricht, seinem eigenen Hash der Parameter. Wenn die beiden Hashes übereinstimmen, wissen Sie, dass die angegebenen Werte legitim sind und nicht manipuliert wurden. – Josh
@Kunal, kein Zeitstempel ist nicht verschlüsselt und es sollte in Soap-Header sein. – Don