практические последствия увеличения перекоса часов WCF более чем на час с точки зрения безопасности

Я написал службу WCF, которая возвращает «полуприватные» данные, касающиеся имени, адреса и номера телефона людей. Под полуприватным я подразумеваю, что для доступа к данным есть имя пользователя и пароль, и данные должны быть защищены при передаче. Тем не менее, ИМХО, никто не собирается тратить энергию на получение данных, так как в любом случае они в основном доступны в общедоступной телефонной книге и т. Д. На каком-то уровне безопасность — это своего рода «театр» безопасности, чтобы поставить галочки в некоторых навязанных нам полях. государственными органами.

Клиентская часть службы представляет собой приложение, которое выдается зарегистрированным «пользователям» для запуска в рамках их собственных ИТ-настроек. У нас нет контроля над ИТ пользователей, и на самом деле они часто говорят нам «прыгать», если мы предъявляем к их системам слишком много требований.

Одна из проблем, с которой мы сталкиваемся, заключается в том, что многие пользователи имеют неточные системные часы. Это может быть вызвано либо подлинными медленными/быстрыми часами, либо, что более вероятно, ошибкой часового пояса или зоны перехода на летнее время (отставание их машины от «реального» времени на час). Особенность используемых нами привязок WCF заключается в том, что они полагаются на понятие времени для обнаружения повторных атак и т. д.

 <wsHttpBinding>
    <binding name="normalWsBinding" maxBufferPoolSize="524288" maxReceivedMessageSize="655360">
      <reliableSession enabled="false" />
      <security mode="Message">
        <message clientCredentialType="UserName" negotiateServiceCredential="false"
          algorithmSuite="Default" establishSecurityContext="false" />
      </security>
    </binding>
  </wsHttpBinding>

Неточные часы клиента вызывают генерацию исключений безопасности и недовольство пользователей.

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

http://www.danrigsby.com/blog/index.php/2008/08/26/change-the-default-clock-skew-in-wcf/

Мой вопрос: каковы реальные практические последствия увеличения перекоса до 2 часов с точки зрения безопасности? Если злоумышленник может выполнить какую-то атаку повторного воспроизведения, почему окно смещения часов в 5 минут обязательно должно быть безопаснее, чем 2 часа? Я предполагаю, что для выполнения любой атаки с режимом безопасности «сообщение» требуется больше, чем просто захват некоторых данных на прокси-сервере и повторная отправка данных для «воспроизведения» вызова? В ситуации, подобной моей, когда данные только «читаются» пользователями, есть ли вообще какие-либо последствия для безопасности, связанные с разрешением атак «повторить»?


wcf wcf-security
person Andrew Patterson    schedule 11.01.2010    source источник

Ответы (1)


arrow_upward
0
arrow_downward

По умолчанию любые веб-службы, которые вы будете предоставлять через Интернет и которые должны быть доступны в различных географических точках (т. е. в разных часовых поясах) и которые будут проверять временные метки, чтобы избежать повторных атак, должны использовать универсальное время (UTC) для проверки этих временные метки.

В этом случае веб-служба также должна указывать, что любой потребитель, извлекающий данные, также должен использовать UTC для штамповки своих запросов. Это, конечно, устранит любые конфликты часовых поясов между вашими серверами и клиентом.

Что касается перекоса часов между сервером и клиентом. Синхронизируются ли ваши серверы с общим сервером времени в Интернете? Если это так, вы также можете указать в API веб-службы, что любой потребитель также должен синхронизировать свои системные часы с тем же сервером времени, чтобы повысить качество обслуживания и надежность соединений службы.

К сожалению, вы не можете управлять часами в системе клиента! Расширение рассогласования часов на сервере, чтобы попытаться решить проблему подключения клиента, снижает целостность вашей системы, и этого следует избегать любой ценой, даже если данные, возвращаемые системой, являются лишь частично конфиденциальными. Если потребляемые данные достаточно важны для потребителя, он с радостью примет любые изменения, которые улучшат качество обслуживания и доступ к нужным им данным.

person Schleichermann    schedule 14.06.2010