Данный тип уязвимости проявляется в веб приложениях, которые не производят экранирование информации, введённой пользователем, перед её помещением в HTML страницы. Это позволяет атакующему вставить определённый HTML код на вашу страницу, обычно это теги <script>.
Злобные хакеры часто используют XSS для кражи cookie и информации о сессии или вводят пользователей в заблуждение, вынуждая их вводить важную информацию (так называемый фишинг — рыбалка).
Данный тип атак может принимать различные формы и бесконечно изменяться, так что мы рассмотрим типичный случай. Рассмотрим чрезвычайно простое представление:
def say_hello(request):
name = request.GET.get('name', 'world')
return render_to_response("hello.html", {"name" : name})
Это представление просто получает имя из параметра
GET и передаёт его в шаблон
hello.html, который может выглядеть так:
<h1>Hello, {{ name }}!</h1>
Таким образом, если мы перейдём по URL http://example.com/hello/name=Jacob, то результатом будет страница, которая будет содержать:
<h1>Hello, Jacob!</h1>
Подождите, а что произойдёт, если перейти на http://example.com/hello/name=<i>Jacob</i>? Тогда мы получим это:
<h1>Hello, <i>Jacob</i>!</h1>
Конечно, хакеры не будут играть с тегами <i>, они могут включить набор HTML кодов, которые наполнят вашу страницу определённым содержимым. Этот тип атак используется для принуждения пользователей выдать, например, информацию о своём банковском счёте, которая затем отправляется атакующему.
Проблема может стать ещё серьёзнее в случае, если вы сохраняете эти данные в базе данных и затем отображаете их на своём сайте. Например, на MySpace однажды нашли уязвимость, которая позволила провести атаку такого типа. Один пользователь вставил в свой профиль JavaScript, который автоматически добавлял этого пользователя в качестве друга, если кто-то посещал его страницу с профилем. За несколько дней у него появились миллионы друзей.
Это может казаться несерьёзным, но следует помнить, что атакующий запустил свой код, не код MySpace, на вашем компьютере. Это нарушает предположение о том, что весь код на сайте MySpace действительно написан этой компанией.
Компании MySpace очень повезло, что этот код не принялся автоматически удалять пользовательские аккаунты, изменять их пароли, заваливать сайт спамом или выполнять какой-нибудь ещё кошмарный сценарий, который позволяет данная уязвимость.
Решение простое — всегда экранируйте любую информацию с помощью тега escape (или его эквивалента) при отображение на вашем сайте информации, введённой пользователем.
Почему Django не делает это автоматически?
«Пусть Django автоматически экранирует все переменные, отображаемые в шаблонах» — эта тема достаточно часто возникает в листе рассылки разработчиков.
Пока шаблонная система Django избегает такого поведения, потому что при этом бы незаметно изменилось бы то, что должно работать прямолинейно — отображать переменные. Это очень хитрая задача, чтобы оценить её реализацию. К тому же, добавление скрытого неявного поведения идёт против основных идеалов Django (да и Python тоже), но обеспечение безопасности также является важной задачей.
Всё, что мы хотим этим сказать, — возможно когда-нибудь Django дорастёт до некоторой формы автоматического (или почти автоматического) экранирования в будущем. Рекомендуем периодически проверять официальную документацию на предмет нововведений. Она всегда будет содержать более актуальную информацию, чем эта книга.
Даже если эта функциональность будет добавлена в Django, вы всё ещё будете должны иметь привычку спрашивать себя каждый раз — «Откуда пришли эти данные?». Никакое автоматическое решение не защитит ваш сайт от XSS атак на 100%.
| Пред. | Уровень выше | След. |
| Внедрение SQL | Начало | Подделка HTTP запросов |
0 comments | Make a comment