6

Вопрос по web-services, wcf – Как Timestamp помогает в предотвращении повторных атак в веб-сервисах

Я пытаюсь понять концепцию временных меток в заголовках запросов в веб-службах, но как-то до сих пор не могу полностью понять, как это работает.

Буду признателен, если кто-нибудь сможет объяснить сквозное использование временных меток в запросах и ответах веб-сервисов.

Это действительно надежный метод предотвращения повторных атак?

  • Error: User Rate Limit Exceeded

    от Kunal Uppal
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • 2

    Отметка времени не зашифрована и должна быть в заголовке мыла.

        <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>
    

    Таким образом, на стороне сервера эти дайджесты должны совпадать. Даже если это еще не все, вы подписываете все SignInfo закрытым ключом и добавляете значение подписи в элемент Signature следующим образом.

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

    Теперь мы можем убедиться, что повторные атаки невозможны. Поскольку никто другой не может иметь такой же закрытый ключ, и поэтому нет способа изменить временные метки и при этом иметь действительную подпись.

  • 6

    Временная метка сама по себе не будет достаточной

    но обычно она объединяется с механизмом хеширования, чтобы гарантировать, что значения не были подделаны.

    Идея состоит в том, что клиент генерирует параметры и использует свой закрытый ключ для хеширования параметров. [Хеш + исходные значения + открытый ключ] затем отправляются с запросом. Сервер может использовать открытый ключ для поиска закрытого ключа и проверки правильности параметров.

    Временная метка используется вместе с некоторым порогом, чтобы гарантировать, что конкретный запрос не может быть использован более одного раза. Если порог небольшой (несколько сотен миллисекунд), то атака воспроизведения практически невозможна.