| Когда htmlspecialchars() не помигает Теперь рассмотрим другую ситуацию. К примеру, в некоторой системе (форуме), некоторыми методами в каждом сообщении можно оставить ссылку ( … ), на произвольный URL. Так, например, может использоваться слеующие конструкции …. Значение URL находится в двойных кавычках, все опасные символы, такие, как кавычки, знаки больше меньше, фильтруются любым образом, перед вставкой значения в качестве URL. Например, для вывода собственно URL ссылки и текста ссылки используется функция наподобие функции PHP htmlspecialchars(). Таким образом, выбраться за пределы атрибута href, невозможно. И невозможно изменить реакции на события OnMouseClick или OnMouseOver. Другими словами, казалось бы, уязвимость отсутствует. Однако, что если сделать вот так?
[URL=javascript:alert(document.cooke)]click me[/URL] По указанным правилам этот текст конвертируется в следующую строку при выводе в броузер: click me Далее, при клике на эту ссылку, как ни странно, выполниться внедренный JavaScript код. Более того, выполниться он в контексте “неуязвимого” сайта, что влечет за собой все неприятности уязвимости XSS. В частности, это может использоваться для кражи COKIE целевого пользователя. Для того, чтобы обойти, возможно присутствующие на сервере механизмы фильтрации, хакер может использовать некоторое приемы. Например, пробелы в JavaScript коде, могут замениться на последовательности /**/. А от использования кавычек спасет функция string.fromCharCode(), которая принимает коды символов и возвращает строку. Для исключения этой уязвимости достаточно фильтровать слово script в URL ссылки.
Действия администратором Вернемся к нашей ситуации, с возможностью внедрения изображений в сообщения. Допустим, для выполнения некоторых действий администратором системы или модератором, происходит переход по некоторой ссылке. Так, например, допустим, для удаления сообщения, администратору необходимо кликнуть на ссылку типа http://site/forum/delete-post.php?id=12345, где 12345 – это идентификатор сообщения. Теперь представим себе ситуацию, что хакер оставит на форуме сообщение с изображением, имеющим именно такой URL. Результатом будет то, что как только администратор прочитает это сообщение, его броузер сделает запрос к данному URL, и, в том числе, передаст все аутификационые данные (COOKIE) на сервер. Предполагается, что администратор в момент прочтения такого сообщения (например, отправленные ему приватным посыльным), аутифицирован на форуме. В результате, целевое сообщение будет удалено, незаметно для администратора. Допустим, в результате какой либо фильтрации, в сообщениях на форуме невозможно вставлять изображения с таким URL. Тогда хакеру поможет “фокус” с Location. Нападающему достаточно будет вставить в сообщение изображение, находящееся на контролируемом сайте. Контролируемый нападающим сервер при запросе данного изображения должен ответить заголовком 301 (или 302) moved, с Location полем, со значением целевым URL = http://site/forum/delete-post.php?id=12345. В результате, при запросе этого изображения, броузер администратора обратиться по данному URL прозрачно для администратора будет выполнено некоторое действие. Как и ранее, нападающий может полностью скрыть факт выполнения скриптов на сервере, и, кроме того, любые фильтры возможно присутствующие в системе (форуме), могут быть обойдены указанным способом. Более того, просматривая URL изображения (в свойствах изображения в броузере), администратора не заметит ничего удивительного. URL может действительно выгладить как URL обычного изображения. И, кроме того, если в системе предусмотрены методы контроля, и, для выполнения действий администратором, необходимо, чтобы HTTP REFERER, переданный броузером принадлежал форуму, то и эта проверка обходится автоматически. Дело в том, что при запросе изображения, расположенного на сайте, серверу на котором расположено изображение передается HTTP_REFERER равный URL-у страницы с изображением. А при переходе по Location, с заголовком 301 (302) Moved, HTTP-REFERER сохраняется. Внимание. К подобному типу атаки уязвимы ВСЕ системы (форумы, чаты), разрешающие вставку в сообщения изображений со сторонних сайтов, в случае, если для выполнения некоторых действий администратором (модератором), хватит простого HTTP GET запроса. Теперь рассмотрим более сложную ситуацию. Для выполнения некоторых действий администратором необходимо отправить HTTP POST запрос. Примером может служить отправка сообщения от имени администратора, либо другие действия вплоть до перевода определенных пользователей между группами и наделения их привилегиями администратора. Хакер может разместить ссылку (yyy) на некоторое изображение или URL, с целью заманить администратора по указанному URL. Например, URL может быть похож на адрес картинки (*.jpg), чтобы не вызвать дополнительных подозрений у администратора. При переходе по этому URL, администратору может выводиться форма со скрытыми полями, содержащая все необходимые данные, и отправляться методами JavaScript автоматически после загрузки. Для поведения скрытой атаки, форма может находится в iframe объекте, который в свою очередь находится в невидимом слое. В то время, как в видимой части страницы действительно может располагаться какое либо изображение. На мой взгляд описанные возможности являются очень опасными по нескольким причинам. 1) существует огромное количество продуктов, уязвимых к такого рода атакам 2) атака очень легко осуществима 3) атака может быть проведена незаметно для администратора 4) атака может быть проведена с минимальными взаимодействиями с администратором (модератором) системы Как защиту от подобного рода атак я рекомендую каждый раз, для каждых данных, отправленных на форуме, добавлять к ним идентификатор сессии или его хеш, с последующей проверкой на сервере. Если ссылки и содержание форм будут иметь непредсказуемый вид, то это сделает проведение таких атак весьма маловероятным. Заключение
Иногда паранойя – это полезно
Я не Бог и мне всё по х..
| 
