SS возвращается

Zadoxlik (antichat.ru)

Хакер, номер #092, стр. 092-062-1

Обзор и классификация межсайтового скриптинга

На страницах нашего журнала ты постоянно читаешь о том, как хакер ломает сайты с помощью XSS-атак. С этих пор такого не будет. Эта статья подытожит все твои представления о подобного вида атаках.

XSS? Зачем матом ругаться?

Хотя я и сказал, что статья подытоживает все, что было сказано об XSS, но давай вернемся на землю. Кто знает, вдруг решишь высосать уязвимость там, где ее нет? Всякое бывает. Вот тогда надо будет уже подробно читать (или находить самому) о реализации JS, VBS (и внедрения их в HTML) для каждого отдельного браузера. Однако не расстраивайся заранее — огорчений не будет. Итак, сказал сначала, значит, сначала. Сядь за парту, лекция началась. Первый вопрос: XSS - что это за зверь и с чем его едят? Зверюга эта расшифровывается как Cross Site Scripting (межсайтовый скриптинг). Напрашивается вопрос - почему не CSS? Об этом можно только гадать, но есть устоявшееся мнение о том, что, дескать, если бы его называли CSS, то люди бы путали его с Cascade Style Sheets (каскадные таблицы стилей), что к XSS имеет непосредственное отношение. А заменить первую «C» решили буквой «X», поскольку Cross переводится с английского как «крест», а «Х», согласись, очень даже этот самый крест и напоминает (если пофантазировать).

Функционально межсайтовый скриптинг - это взаимодействие взломщика с пользователем средствами веб-приложения, которым пользуется жертва. То есть взломщик находит в системе возможность внедрения своего HTML'ного кода в страницу, которая будет показана пользователю. А что можно с этим сделать? Если интересно, то отложи мяч в сторону — футбол будет потом — и читай дальше.

Вкусное печенье и тяжелая сессия

Итак, давай действовать и думать вместе. Представим, что мы получили каким-то образом доступ к редактированию HTML-кода страницы, которую посетил пользователь. И не просто какой-то страницы, вроде нашего хомячка, а страницы, принадлежащей сайту, на котором у вышеупомянутого заведен аккаунт. Это значит, что в базе данных сайта хранится логин, пароль и еще кое-какая информация о пользователе. И нам бы, конечно же, хотелось бы получить эту информацию. Давай поэтапно разберем авторизацию пользователя на сайте. Он заходит, вбивает в форму логин и пароль и проходит к себе в личный кабинет/форум/чат и т.д. Фактически в момент авторизации происходит следующее: браузер юзера формирует запрос к серверу, в котором отсылает свой логин и пароль. Сервер принимает этот запрос, вынимает из него вышеуказанные данные и проверяет, есть ли в базе данных такой паренек. На основе этого либо посылает его в Тибет к монахам, либо отвечает, что все хорошо. В ответе, так или иначе, содержится нечто, что будет в дальнейшем отправлять пользователя на сервер, чтобы убедить последнего в том, что он — это именно он, а не какой-нибудь дядя Вася с третьего подъезда, и что авторизироваться ему дальше не обязательно, а достаточно посылать только это что-то. Что же это за мистическое «что-то»? В современных веб-приложениях возможны только 2 варианта (левые скрипты от Васи Пупкина мы не рассматриваем): либо куки, либо номер сессии. Не пугайся сразу, сейчас все объясню. Давай не будем кричать, что все знают про Куки. 80% опрошенных, которые сказали, что знают, выдают ответ порядка «это вот такая типа вещь, где типа такие вот личные данные, гы». Мы же с тобой интеллигентные люди — должны уметь оперировать терминами. Куки (Cookie - печеньки) - это параметры, передаваемые скрипту, равносильные параметрам, передаваемым в POST- или GET-запросе. То есть все, что нас идентифицирует, хранится у нас же самих. А это дает нам возможность не только ходить под своим логином по сайту, но и выйти с него и прийти на следующий день также. Второй вариант - номер сессии. Сессия - это такая хитрая штука. Это вовсе не то, что ты завалил зимой :). Вся информация из сессии хранится на сервере в папке временных файлов. Сессии характеризуются двумя свойствами - срок жизни и привязка к IP. Это нам еще пригодится. В случае с такой авторизацией — не может сделать так, чтобы, зайдя на следующий день на сайт, ему бы не пришлось снова логиниться. Все просто - у сессии маленький срок жизни, и к этому времени на сервере уже не останется файла для нее. Чаще всего номер передается все в тех же куках, как отдельный параметр. Но ничего не мешает передать его через GET, как, например, http://site/?SID=SESSION_NUMBER.

Содержание  Вперед на стр. 092-062-2
ttfb: 8.9190006256104 ms