Якщо хакер змінив blog_charset на UTF-7, це робить WordPress уразливим для подальших атак?

У мене був клієнт, який нещодавно зламався, і я помітив, що на його сайті з’являються дивні персонажі, такі як and і Æ. Виявляється, хакери змінили блог_charset на UTF-7 у wp_optionsтаблиці в базі даних. Я повернув його до UTF-8, але мені було цікаво, чи могло це створити якісь уразливості безпеки під час, коли він був встановлений на UTF-7?

Я здійснив пошук і виявив, що раніше була вразливість WordPress UTF-7, яка була виправлена ​​у версії 2.0.6 . Ми працюємо над останньою версією WordPress, тому вони не могли використовувати цей подвиг, але чи є інші подвиги, пов'язані з UTF-7? Дійсно, чи є якась причина, щоб хакери змінили blog_charset, крім того, щоб викликати біль? Я намагався визначити, як вони потрапили, і мені цікаво, чи це пов’язано якось.

<і >кодуються як +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. Основна проблема: втекти більше не працюватимуть.

Просто зміна значення кодування назад не є рішенням. Звичайний відвідувач ніколи його не може змінити, тому вам доведеться знайти відкриті двері.

Також це може знадобитися (повторне перетворення всіх кодувань ваших таблиць): /programming/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation- до-utf-8