В этой статье я расскажу как обезопасить себя от инъекций нежелательного кода через переводы в WordPress
Иногда мы забываем что переводчики веб-сайта тоже люди и не всегда доброжелательные.
Подменяя файл перевода переводчики могут нарушить работу сайта и украсть персональные данные пользователей.
Проблема
Чтобы разобраться в ситуации давайте вспомним ответ на вопрос — «Как чаще всего мы вставляем перевод в нашу тему или плагин?»
<?php echo '<p>' . __('Sometext', 'mytheme') . '</p>'; Казалось бы что может пойти не так? Давайте подумаем.
Достаточно вставить в файл перевода закрывающуюся скобку ">" или <script>alert('hello');</script> и всё… верстка поехала, сайт выдал ошибку. А всё могло быть даже хуже.
Решение
У WordPress есть две замечательные функции которые позволяют избежать вставки нежелательных символов в текст перевода:
codex.wordpress.org/Function_Reference/esc_html_2
codex.wordpress.org/Function_Reference/esc_html_e
esc_html__ и esc_html_e соответственно.
Отличие лишь в том что esc_html_e не нужно выводить через «echo».
Во всех местах где вы используете конструкцию
__('something', 'mytheme')нужно использовать
esc_html__('something', 'mytheme')А конструкцию
_e('something', 'mytheme')заменить на
esc_html_e('something', 'mytheme')Ещё один момент
Если у нас имеется конструкция с атрибутом вида:
<?php echo '<a href="#" title="' . __('Attribute value', 'mytheme') . '</a>'; То «эскейпить» её нужно функцией esc_attr__()
codex.wordpress.org/Function_Reference/esc_attr_2
Вывод
Правило «не доверяй никому!» должно быть в основе разработки и каждый даже самый минимальный момент ввода-вывода данных должен быть учтен при разработке чтобы избежать печальных последствий. И переводы — не исключение.
И в завершение — Github для чтения
По данной ссылке кратко описана проблема вывода переводов без эскейпов:
github.com/Automattic/_s/issues/231
ссылка на оригинал статьи http://habrahabr.ru/post/266989/
Добавить комментарий