repetición informaticos ejemplos ataques ataque wcf web-services security web timestamp

wcf - informaticos - ¿Cómo ayuda Timestamp a prevenir ataques de repetición en servicios web?



ataque de repetición (2)

Una marca de tiempo por sí sola no sería suficiente, pero generalmente se combina con un mecanismo de hash para garantizar que los valores no se hayan alterado.

La idea es que el cliente genere los parámetros y use su clave privada para ajustar los parámetros. Los [valores originales hash + clave pública] se envían con la solicitud. El servidor puede usar la clave pública para buscar la clave privada y asegurarse de que los parámetros sean correctos.

La marca de tiempo se usa, junto con algunos umbrales, para garantizar que una solicitud en particular no se pueda usar más de una vez. Si el umbral es pequeño (algunos cientos de milisegundos), un ataque de repetición es prácticamente imposible.

Estoy tratando de entender el concepto de marcas de tiempo en los encabezados de solicitud en los servicios web, pero de alguna manera todavía no puedo entender completamente cómo funciona.

Agradecería que alguien pudiera explicar el uso de extremo a extremo de las marcas de tiempo en la solicitud y respuesta de los servicios web.

¿Es realmente un método infalible para prevenir ataques de repetición?


La marca de tiempo no está encriptada y debe estar en el encabezado del 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>

Si el tiempo de caducidad es poco después de la hora de creación, puede minimizar el ataque de reproducción. En realidad, no es solo la marca de tiempo. Debe agregar el resumen de la marca de tiempo a la sección 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>

Entonces en el lado del servidor estos compendios deben coincidir. Incluso eso no es todo, entonces usted firma toda la información con la clave privada y agrega el valor de la firma al elemento Firma de la siguiente manera.

<ds:SignatureValue>jdO5GIZ9v1VTngFZcMpz5hz62RwToq2W24A9KhJ5JNySZW1AHhd3s+eTduZZPD0Ok6Wtgzu5kquK IinPdi5IbGjlg6mXGDbVkLd79RBdnbzFxsJFBtRr9r3mQZp9xfU7zSJW3kbizz6Jjk3h+S2nNbUu f7rFrNN53ciRtj9RlKzQzmW7BDaFuq18DUfcr70muSkmd4DIqxYDGScjEjgIqLE2pYwIdDDRUGPD MuwuIN3DgB051QwcE75SVrKBKsTHmFADmN3nKzmQ/JUQuLot0vW6WUFRMLVlAcl5C09SGPOcpow2 kjbuWx/bI7Aj4nAaAnmAYsWKIA3xVao+nPBOWmM0Lg7kpC4Dr5DwahmjH0/78aVUU23DEiMc0kR0 YDg5CxD8MUuj24w8tAjuzoHrvcsIYw+vWCTKvucnXwTlZ+K3QFB6gkct2zVOyQeYaPpkAnmPYS3W DDpNmsx3lDcNr+5QWTsUbSQaFDddjHT/zoOJ8+iZKY/RujOI5vfXVwgN</ds:SignatureValue>

Ahora podemos asegurarnos de que los ataques de repetición no sean posibles. Como cualquier otra persona no puede tener la misma clave privada, no hay manera de alterar las marcas de tiempo y aún así tener una firma válida.