Если хакер изменил blog_charset на UTF-7, это делает WordPress уязвимым для дальнейших атак?

19

У меня был клиент, которого недавно взломали, и я заметил, что на ее сайте появляются странные персонажи, такие как Â и Æ. Оказывается, хакеры изменили blog_charset на UTF-7 в wp_optionsтаблице в базе данных. Я установил его обратно в UTF-8, но мне было интересно, может ли это привести к появлению каких-либо уязвимостей в течение времени, когда он был установлен в UTF-7?

Я провел небольшой поиск и обнаружил, что раньше была уязвимость WordPress UTF-7, исправленная в версии 2.0.6 . Мы используем самую последнюю версию WordPress, поэтому они не могли использовать этот эксплойт, но есть ли другие эксплойты, связанные с UTF-7? В самом деле, есть ли причина, по которой хакеры могли бы изменить blog_charset, кроме как быть болью? Я пытался определить, как они вошли, и мне интересно, если это как-то связано.

Jennette
источник

Ответы:

23

<и >кодируются как +ADw-и +AD4-в UTF-7 . Теперь представьте следующее:

  1. Кто-то отправляет в +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-качестве комментария текст. Он пройдет всю санитарию без помощи.

  2. База данных ожидает и обрабатывает все входящие данные как UTF-8. Поскольку все UTF-7 потоки действительны UTF-8 тоже, это никогда не приведет к ошибке SQL, и mysql_real_escapeили htmlspecialcharsне трогать.

  3. WordPress отправляет заголовок text/html;charset=utf-7.

  4. WordPress отображает комментарий, ожидая экранированных данных. Но так как это рассматривается браузером как UTF-7, JavaScript будет выполняться.

Так что да, это проблема безопасности.

UTF-7 поддерживается не всеми браузерами, большинство будет отображать текст как Windows-1252 (или любую кодировку по умолчанию в их ОС) или как UTF-8. Основная проблема: побег больше не будет работать.


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

Фуксия
источник
Благодарность! Я скрестил пальцы, что исправление этой записи в базе данных закрыло дыру в безопасности.
Дженнет
Не волнуйтесь, я уже предпринял несколько действий, чтобы закрыть дыры в безопасности. Я просто не мог понять, как они все еще входили. Похоже, за последние несколько дней ничего не было взломано, так что, надеюсь, изменение кодировки обратно на UTF-8 было последним шагом в закрытии всех дыр.
Дженнет