Wordpress не использует традиционные одноразовые номера, вместо этого связывает их с определенным действием формы и комбинацией сеанса пользователя и сохраняет их для многократного использования в течение двух тиков (по умолчанию 12 часов каждый), что означает, что они по умолчанию действительны дополный день и может многократно использоваться в течение этого периода времени , а также "обновляться" после использования до , полностью сбрасывая свой период времени .В течение ряда лет специалисты по безопасности постоянно критиковали его за вводящее в заблуждение и небезопасное, а основная команда WordPress отстаивала свою позицию, утверждая, что требование наличия у пользователя как сеанса пользователя, так и фактического одноразового номера делает эту угрозу незначительной.хотя и скомпрометированный хост, и сайт, на котором нет действительной защиты ssl, могут сделать это довольно легко.
Основная проблема, с которой вы сталкиваетесь, является симптомом того факта, что одноразовый номер WordPress не являетсяодноразовый номер вообще.По сути, это хеш-контроль доступа, который многократно используется в течение короткого периода времени для одного действия формы, и не имеет механизма для обеспечения его одноразового использования.Вот почему вы смогли успешно перехватить и повторно использовать одноразовый номер.К вашему сведению, это поведение также может быть легко воссоздано в Zed Attack Proxy, Wireshark, Charles Proxy и многих других подобных утилитах.Отрыжка - не единственный инструмент, который способен выявить эту слабость.
Однако у вас есть возможность исправить это, если хотите, но это довольно сложный процесс, и его не так просто выполнить.
Следующие функции pluggable , что означает, что вы можете переопределить их своими собственными, а также управлять системной интерпретацией того, что такое nonce.Вам нужно будет предоставить собственную систему nonce, используя эти конкретные методы, и возвращать идентичные значения к исходным ожидаемым, чтобы не нарушать функциональность плагинов / кода ядра:
Выможет, например, предоставить собственную реализацию nonce, используя поддержку из пакета, такого как elhardoum / nonce-php или wbswjc / nonce , а затем реализовать его с помощью customплагин , который переопределяет вышеуказанные подключаемые функции и использует их в качестве оберток для вашей собственной реализации nonce, хотя это не невероятно просто и потребует большого количества настраиваемой логики для реализации.
Вам не нужнотолько переопределяют вышеупомянутые подключаемые функции, но также должны будут вызывать apply_filters аналогично их собственному источнику, должным образом аннулируя любые изменения, которые предпринимают плагиныmake, которые привязаны к этим фильтрам, а также возвращают ожидаемое значение в точно таком же формате , что и оригинал, чтобы вы не мешали тому, как другие плагины / темы, которые вы используете, реализовали их.
Если вы считаете, что существует достаточный риск или что данные, которые ваш сайт защищает, имеют достаточную важность, это, вероятно, стоит затраченных усилий.Если вы не обрабатываете финансовые транзакции или конфиденциальные данные, должным образом защищены за ssl или не особенно заинтересованы в написании пользовательской реализации одноразовых номеров и в последующем ведете ее, чтобы обойти способы, которыми она неизбежно ломает многочисленные плагины, ожидающие, что реализация lax по умолчаниюприсутствуйте, тогда вам, вероятно, лучше всего взять на вооружение разработчиков ядра и использовать значения по умолчанию, при условии, что вы часто обновляетесь, имеете надёжный плагин безопасности, такой как wordfence или sucuri, и регулярно запускаете обновления для всех ваших плагинов / тем.
Как абсолютный минимум, вы должны иметь SSL для предотвращения атак MITM и должны использовать надлежащие заголовки контроля доступа для смягчения CSRF.