WEb практикум. Web'cepbep
 Скачать 4.76 Mb.
|
ГЛАВА 9 АвторизацияАвторизацию мы рассматриваем в этой книге для понимания очень популярной и достаточно опасной атаки — XSS (Cross Site Scripting — межсайтовый скриптинг). Обновлять информацию на web-сайте через FTP-клиента с помощью закачки новых файлов достаточно неудобно и не всегда возможно например, уже в конце 1990-х мне приходилось работать в сетях, где доступ в интернет осуществлялся только по HTTP. Именно тогда я задумался о системе администрирования web-сайтов посредством web-интерфейса. Сейчас web-интерфейс стал стандартом для управления любым сайтом. Сценарии администрирования позволяют управлять содержимым web-страниц, поэтому должны быть закрыты от постороннего взгляда. Для этого необходима отдельная защита, которая позволит вам спать спокойно и не даст хакеру выполнить привилегированные операции. В качестве такой защиты можно использовать средства аутентификации. Зарегистрированными пользователями проще управлять и контролировать их действия и будет легче защититься от накруток. Авторизация нужна не только администраторам, но и пользователям — им можно предоставлять более персонализированные сервисы, чтобы они могли пользоваться определенными привилегиями. Зарегистрированные пользователи обычно лояльны сайту, но это уже вопрос маркетинга. В любом случае регистрация может быть выгодна и полезна широкому кругу сайтов. Аутентификация на web-сервере Если какой-либо каталог web-сервера должен иметь особые права доступа, то можно создать в нем файл .htaccess. В этом файле описываются разрешения, действующие на каталог, в котором он расположен. При обращении к любому файлу из данного каталога web-сервер будет требовать аутентификации. Да, аутентификации будет требовать именно web-сервер, поэтому дополнительные сценарии не понадо бятся. Таким образом, вы получаете в свое распоряжение эффективный и отлаженный годами метод обеспечения безопасности конфиденциальных данных. Рассмотрим пример содержимого файла .htaccess: AuthType Basic AuthName "By Invitation Only" AuthUserFile /pub/home/flenov/passwd Require valid-user В первой строке задается тип аутентификации с помощью директивы AuthType. В данном примере используется базовая аутентификация (Basic), в этом случае web-сервер при обращении к каталогу отобразит окно для ввода имени и пароля. Текст, указанный в директиве AuthName, появится в заголовке окна (рис. 9.1).  Рис. 9.1. Окно запроса имени и пароля Директива AuthUserFile задает имя файла, в котором находится база имен и паролей пользователей web-сайта. О том, как создавать такой файл и работать с ним, мы поговорим позже. Последняя директива Require в качестве параметра использует значение valid-user. Это значит, что файлы в текущем каталоге смогут открыть только те пользователи, которые прошли аутентификацию. Вот таким простым способом можно запретить неавторизованный доступ к каталогу, содержащему секретные данные или сценарии администратора. Более подробную информацию об этом методе авторизации можно узнать из моих книг "Linux глазами хакера" или "PHP глазами хакера". Такой подход к авторизации неплохо подходит для защиты страницы администрирования. В случае с авторизацией пользователей на сайте такой подход неудобен и неэффективен, поэтому в наше время его мало кто использует. Когда пользователь вводит имя и пароль в такое окно, то браузер запоминает эти данные, кодирует с помощью кодировки base64 и начинает отправлять на сервер с абсолютно каждым запросом в виде параметра authorization (рис. 9.2). Просмот реть это значение можно, если открыть утилиты разработчика в браузере, загрузить страницу и кликнуть на абсолютно любом запросе, который направляется к вашему серверу с базовой защитой.  Михаил ФлёновРис. 9.2. Параметр заголовка с данными авторизации Как видно на скриншоте, у меня в заголовке параметр authorization равен Basic bWZsZW5vdjpwYXNzd29yZA== После слова basic идет код в Base64, который легко превращается в чистый текст. В Google вбиваем Base64 decode, и вы найдете много сайтов, которые умеют декодировать такой код. Воспользовавшись одним из них, вы легко узнаете, что bWZsZW5vdjpwYXNzd29yZA== на самом деле соответствует mflenov:password. До двоеточия идет имя, а после идет пароль. Да, я на самом деле для данного примера задал пароль в виде слова password. Это только для примера, в реальности, конечно, у меня пароли намного сложнее. Помимо того, что этот вид аутентификации неудобен в поддержке, у него еще и серьезный недостаток безопасности, потому что имя и пароль передаются с каждым запросом и их легко декодировать. Если хакер перехватит хотя бы один из запросов, он получит доступ к паролю, поэтому убедитесь, что вы используете протокол с шифрованием HTTPS, который зашифрует все данные и не позволит перехватить имя и пароль. Очень часто используются самостоятельно написанные системы аутентификации, которые могут быть реализованы с нуля или использовать какие-то библиотеки/ API. Чаще всего они основаны на cookie-значении, которое сохраняется в браузе ре пользователя. Именно это значение будет отправляться на сервер с каждым запросом.  В случае с базовой системой аутентификации (см. разд. 9.1) с каждым запросом отправляется закодированное имя и пароль, и если хакер перехватит запрос, то он узнает эти данные. В случае с cookie-авторизацией передается его значение. Если только вы не поместите в cookie имя и пароль, то при перехвате хакер не сможет узнать эти данные.В cookie не должно быть никаких персональных данных, вместо этого должно быть какое-то уникальное значение, которое на сервере будет привязано к имени текущего пользователя. Например, когда мы входим на сайте и успешно вводим имя и пароль, сервер может сгенерировать уникальное значение 3e2c676e-09fb-41d8-a847- de65ff0e3fe1 и поместить его в cookie с именем Auth. Для нас это совершенно странное и непонятное значение, но в реальности это глобальный идентификатор, которые часто использует Microsoft. Эти значения уникальны (рис. 9.3).
Ш Блог Ш Статьи Ш Книги ► Видео Л Подкасты Плюс
Мистер Фикс, у вас есть План обучения? Наконец-то я стал миллионером По дороге из Ванкувера в Банфф Рис. 9.3. Cookie, который хранит уникальный идентификатор сессии Теперь это значение в cookie будет передаваться на сервер с каждым запросом и сервер будет знать, что это я, потому что он создал это уникальное значение для меня и сохранил где-то в базе данных или в другом хранилище для сессий, что 3e2c676e-09fb-41d8-a847-de65ff0e3fe1 соответствует пользователю MikhailFlenov. А что, если хакер увидит один из запросов и украдет это cookie-значение? Он может создать у себя в браузере такое же значение с таким же именем и при отсутст вии дополнительной защиты украдет мою сессию: теперь сервер будет думать, что хакер тоже авторизован как MikhailFlenov, потому что он у него такой же ID. Да, хакер все еще может украсть сессию, если увидит запрос, но по крайней мере он не увидит пароль, и это уже хорошо. А для защиты сессии мы можем добавить дополнительные меры защиты, которые позволят остаться в безопасности даже если хакер украдет сессию. Давайте на практике посмотрим, как можно украсть сессию. На своем сайте flenov.info я не стал делать сложной защиты, потому что это не тот сайт, который может подвергнуться атаке хакеров, поэтому здесь можно украсть сессию, если очень сильно постараться. Загрузите мой сайт flenov.mfo и зарегистрируйтесь. Если у вас уже есть аккаунт, то авторизуйтесь на сайте. Теперь откройте утилиты разработчика и на вкладке Application, найдите cookie для URL flenov.info, а затем элемент с именем PHPSESSID. Это имя по умолчанию для идентификатора сессии в PHP. Теперь можно открыть другой браузер, я буду использовать Safari (рис. 9.4), в котором тоже есть утилиты разработчика. Здесь переходим на вкладку Storage и выбираем слева Cookies и имя моего сайта. Теперь можно добавить новый элемент или изменить существующий. Можете взять любой существующий элемент cookie и изменить его имя на PHPSESSID и значение на то, что вы видите в своем случае. Мое значение, скорее всего, использовать у вас не получится, потому что к выходу книги оно точно уже не будет корректным.  Рис. 9.4. Работа с cookie в Safari Изменив существующий или добавив новый cookie, перезагрузите страницу. Теперь вы должны быть авторизованы с тем же аккаунтом, что и в первом браузере. Таким образом мне удалось украсть свою же сессию на своем же сайте. Как защититься от подобных вещей? Можно привязывать ID сессии к определенному IP-адресу. Если пользователь зашел на сайт с IP-адреса 10.10.10.10, и вдруг по какой-то причине эта же сессия используется с другим IP, то это может быть хакер, и сессию можно закрыть, чтобы хакер не украл информацию. В принципе, это очень хороший вариант защиты для финансовых сайтов, банков. Но если вы работаете с социальной сетью, то тут такой вариант защиты создаст пользователю неудобства. IP-адреса могут меняться даже на стационарных компьютерах. Пользователи могут использовать для доступа к сайту мобильные телефоны и ноутбуки, где адреса меняются достаточно часто: подключился через одну сеть WiFi — получил один адрес, подключился через сотовую сеть — другой адрес. Завершать при каждом переключении сессию и заставлять пользователя снова вводить данные будет не очень эффективно. В случае с социальными сетями сессии пользователей обычно активны месяцами и не нужно каждый день вводить пароль. В случае с банками, где информация более персональная и более важная, сессии должны устаревать максимум в течение часа. Да, пользователь вынужден будет вводить пароль достаточно часто, но это ради его же безопасности. В этом случае даже если хакер украдет cookie и это значение не будет привязано к определенному IP, у хакера будет только ограниченное время, чтобы использовать это значение. Так как же поступать социальным сетям? Закрывать сессии, подобно банкам, они не будут, так неужели все социальные сети небезопасны? У хакера есть два основных метода перехватить cookie — незашифрованный трафик или с помощью JavaScript при наличии XSS-уязвимости. Чтобы хакер не смог увидеть трафик, просто шифруем его, используя HTTPS. А вот чтобы хакер не украл cookie с помощью XSS, нужно просто писать код так, чтобы не было XSS, но об этом мы поговорим в главе 10. Но даже если есть уязвимость XSS, мы можем защитить cookie от хакеров. Откройте утилиты разработчика и перейдите на вкладку Console (рис. 9.5). Здесь можно выполнять JavaScript-команды. Чтобы прочитать cookie, выполните следующую команду: document.cookie В моем случае я получил в результате строку со всеми доступными cookies: fid=db2333d3-48ee-473d-948c-07ceab707857; utmc=18411502; gads=undefined; utma=18411502.50099190.1570832327.1615397634.1615411123.1765; utmt=1; utmb=18411502.1.10.1615411123; gads=ID=1202c48cafd95d86- 2210f15bd2c6008b:T=1615411123:RT=1615411123:S=ALNI_MZhzK_9ES8dvhJ3Sj7iZc2            9 9 9 p| Главная Персональный cat- X <- -> 0 • flenov.info Hi Apps t3 Work t3 Dev ★ О # * Я Other Book та Програмысли Найдется почти все Memory Apptcabon Security document.cookie. id-db23Up*Ree-473d-948c-«7ceat>787857; _utec>18411582; _gads*undefloed: _ute*-184U582.58899198.1578832327.16 15411123.1765: utar*18411582.1615411123.1765.1 .utecs redirect)|uteccna(direct)|uteceda(nonc); _utet«l; 0-1282c48cafd95d86-2218fl! (8b :T=161S411123 :RT= 1615411123 :S»ALNI_(*ZhrK zzGLHxw Рис. 9.5. Выполнение команд в консоли Я разбил большую строку, которую отобразила команда по точке с запятой, и теперь слева от знака равенства это имя параметра, а после равенства — его значения. Обратите внимание, что phpsessid среди параметров нет, хотя на вкладке Cookies мы его видели. Дело в том, что JavaScript не имеет доступа к защищенным cookie, они просто передаются от сервера браузеру и обратно, но в JavaScript-коде их увидеть не получится, а значит, хакер не сможет их украсть, даже если будет XSS- уязвимость. Если посмотреть на рис 9.3, то напротив cookie с именем PHPSESSID в колонке Secure вы увидите галочку. Она свидетельствует о том, что это значение используется только для коммуникации с сервером и не будет доступно для JavaScript-кода. Галочка напротив Secure говорит еще и о том, что значение будет передаваться только по защищенному HTTPS-протоколу. В PHP за создание защищенных cookie отвечает метод setcookie, у которого последние два параметра как раз и позволяют указать, что нужен защищенный и httponly параметр и по умолчанию оба значения равны false: setcookie ( string $name, string $value = "", int $expires = 0, string $path = "" , string $domain ="", bool $secure = false, bool $httponly = false ) Если оставить $secure и $httponly по умолчанию, то значение cookie будет доступно коду JavaScript и будет передаваться по незащищенному HTTP-протоколу, который теоретически можно перехватить и увидеть значение. Это самый небезопасный способ. При разработке кода всегда по умолчанию указывайте true для параметра httponly, и отключайте этот параметр только тогда, когда его действительно нужно использовать в JavaScript. Советы по хранению паролей Никогда не храните пароли в открытом виде ни в базе данных, ни на локальном компьютере пользователя (в виде файлов cookies). О том, что хранение паролей на локальном компьютере пользователя небезопасно, должен знать каждый. Чуть позже мы рассмотрим один из распространенных способов воровства пользовательских данных — XSS уже на практике, но не стоит забывать и про классику в виде троянских программ или просто уязвимости в браузере пользователя, что встречается сейчас не часто, но теоретически может произойти. Хранение паролей на web-сервере в открытом виде также не безопасно. Если хакер найдет уязвимость, позволяющую реализовать SQL-инъекцию, то он сможет получить из таблиц ваш пароль и незаметно пользоваться правами администратора. Если пароль хранится в зашифрованном виде, то подобрать его можно только перебором. Да, хакер может внести новую запись в базу данных и дать ей права администратора (установить определенный признак), но это будет слишком бросаться в глаза, и администратор быстро увидит, что произошел взлом. В случае хранения паролей в зашифрованном виде аутентификация происходит достаточно просто. Получив имя пользователя и пароль, шифруем пароль и сравниваем с уже зашифрованным вариантом из базы данных. Если шифры совпадают, то аутентификация прошла успешно. А как же реализовать возможность восстановления пароля, если в открытом виде он не сохраняется в базе данных? А никак. Все сайты, которые заботятся о своих пользователях и их безопасности, не позволяют увидеть старый пароль, а разрешают только сменить его на новый. По запросу на восстановление пароля необходимо: запросить адрес электронной почты пользователя; найти запись в базе данных, соответствующую данному адресу; сгенерировать случайный код, который отправляется пользователю на почту; ♦ пользователь после этого вводит код на странице восстановления пароля и ему дается разрешение на смену. Можно генерировать пароль на стороне сервера и давать его пользователю. Это действительно может быть безопасно, потому что мы будем уверены, что сгенерирован действительно сложный пароль. Но в этом случае нужно быть аккуратным. Злоумышленник может пошутить над другом и вызвать восстановление пароля для него только для того, чтобы система сгенерировала новый пароль. Никогда не реализуйте возможность автоматического входа в панель администрирования. Это даже нарушает некоторые стандарты безопасности. Соль на рану Если вы храните в базе данных пароли только в зашифрованном виде и восстановление возможно только подбором пароля, то это еще не значит, что систему можно считать защищенной. Да, подбирать пароль очень долгое занятие, но не обязательное. Дело в том, что можно заранее рассчитать все возможные комбинации хеширования и занести их в большую базу данных. Да, база данных получится не очень маленькой, но для современного компьютера это капля в море. Зато любой пароль можно будет взломать за мгновение. Если отсортировать базу данных, то поиск нужного значения сведется к одной лишь операции — получить пароль, соответствующий хешу, без какого-либо шифрования. Самое страшное, что создав одну лишь базу данных, можно будет подбирать к хеш- значениям пароли на любых сайтах и в любых системах. Неужели нет выхода? Выход есть, и он, как всегда, прост. Перед тем как получить хеш для пароля, просто прибавляем к нему какую-то строку: В данном случае строка dfge4sdf является мусором (его часто называют солью), который просто усложняет пароль. Теперь, если хакер воспользуется своей базой данных для поиска пароля по хешу, то он получит строку, которая содержит не только пароль, но и мусор. Не зная, что является мусором, хакер не сможет определить, где же тут действительно пароль. А что если пользователь выбрал очень простой пароль? В этом случае его легко можно будет увидеть. Но даже если пароль сложный типа dfgj k435, то после поиска по своей таблице хакер получит пароль: dfgjk435dfge4sdf. Да, это неверное значение, но найти, что тут является паролем, можно банальным перебором. А давайте посмотрим на следующий вариант соления: Тут хешируется результат сложения двух хешей — пароля и соли. Вот такой вариант соления становится намного сложнее для подбора по словарю, особенно если хакер не знает, что выступает в качестве переменной $salt. Я не специалист в шифровании, но если не ошибаюсь, то, даже зная значение соли, хакеру придется рассчитывать значения новой базы данных для этой соли, а это очень утомительное и затратное для процессора занятие. Это идентично полному перебору паролей. Фиксированная соль потребует от хакера генерации уникальной базы данных всех возможных вариаций паролей, но если сильно постараться, то он может это сделать, просто нужно рассчитать md5 для всех возможных вариаций a + salt, b + salt, c + salt и т. д. Чтобы этот подход сделать бесполезным, можно делать соль уникальной для каждого пользователя и хранить ее в базе данных. Когда я работал над чувствительными к безопасности данными, то у меня в базе пользователей было две колонки: пароль и соль. Соль генерировалась случайным образом и была уникальной для каждого пользователя, потому что это был GUID. Когда пользователь вводил свой пароль для авторизации, допустим user@gmail.com и пароль pass1234, то система искала в базе пользователя с таким e-mail, допустим, это была запись со значениями: Email: user@gmail.com Salt: e776633c-3eaa-4b7f-805c-aa046cd9eaee Password: B1286032C45E3D422F1B1214D4006E0C Теперь я брал соль и объединял ее с введенным паролем — получался код: e776633c-3eaa-4b7f-805c-aa046cd9eaeepass1234 Теперь рассчитывался Hash, для примера можно взять md5, и в результате получалось B1286032C45E3D422F1B1214D4006E0C, что соответствует сохраненному паролю. Да, в базе данных приходилось хранить для каждого пользователя отдельную уникальную соль, но это делает подбор по словарю невозможным и бессмысленным. Генерировать таблицы смысла нет, у каждого пользователя соль своя. Я здесь привожу в качестве примера хеширования md5, как самое простое решение, которое поддерживают все, но он все же уже не рекомендуется к использованию, потому что его перебор не такой уж и сложный. Соль позволяет добиться какой-то защищенности, но для современных компьютеров MD5 уже не является проблемой. Сейчас рекомендуется использовать SHA-2, как более защищенное хеш-решение. Фиксация сеанса или сессии Еще одна интересная атака на авторизацию — когда хакер не ворует существующую сессию, а подсовывает пользователю свою. В разд. 9.2 мы рассматривали авторизацию, когда в cookie сохранялся идентификатор сессии. Тогда задача хакера была украсть ID-сессии. Некоторые фреймворки позволяют передавать ID-сессии через URL, или хакер может интегрировать на сайт JavaScript-код, который будет добавлять cookie-значение со своим идентификатором сессии. Рассмотрим первый вариант, когда идентификатор передается через URL. Хакер может передать идентификатор прямо в строке URL, отправив такую ссылку пользователю, аккаунт которого нужно взломать: http://website/?SID=abc12345def Здесь abcl2345def — это идентификатор сессии. Когда пользователь кликнет по адресу и загрузит сайт, то сайт может установить в качестве идентификатора сессии именно этот идентификатор, и это может стать проблемой. Пользователь заходит на сайт, и теперь сессия abcl2345def становится авторизованной, и хакер может использовать этот же идентификатор. Если в разд. 9.2 задача хакера была украсть идентификатор сессии, то тут это не нужно, он его уже знает, ведь именно хакер подсунул свой код. Если попытаться запретить создание идентификаторов сессии через URL, то это не спасет и не решит полностью проблему. Допустим, что пользователю можно назначать только ID существующей сессии и нельзя указывать что-то свое, о чем сервер не знает и не подозревает. Отлично, но хакер может загрузить один раз сайт и получить идентификатор сессии и использовать уже его. Сайт не должен принимать идентификаторы сессий через URL, и для простых сайтов это возможно, а вот для WebAPI, который использует REST, это может не работать. Тут очень часто используется не cookie, а именно параметры get или post. По возможности нужно отказаться от передачи идентификатора сессии через параметры, особенно через URL, и это необходимая, но не достаточная защита. Допустим, что сайт будет проверять и игнорировать любые идентификаторы и не позволит использовать идентификатор сессии из URL вовсе. Но если на сайте есть XSS-уязвимость (о чем мы будем говорить в главе 10), то с помощью cookie с нужными значениями можно попытаться создать защиту с помощью JavaScript. С помощью обращения к document.cookie можно создавать, менять и удалять cookie. Например, следующий код создает новый cookie с именем sid: document.cookie = "sid=abc12345def "; Если на сайте нет XSS-уязвимости, то теоретически можно пытаться делать обходные защиты, но если говорить о хорошей защите, то самая простая из них - перезапускать сессию после входа на сайт. Когда пользователь авторизуется на сайте, то текущий идентификатор сессии должен всегда уничтожаться, создаваться новый, и именно новый должен быть авторизован. Даже если хакер подкинет идентификатор сессии, пользователь не сможет превратить его в авторизованный. Проблема фиксации сессии иногда встречается с использованием разных подходов к авторизованным и неавторизованным пользователям. Например, мне приходилось сталкиваться с сайтами, где неавторизованные пользователи работали с HTTP- версией сайта без шифрования. Как только пользователь авторизуется, то сразу же его переводят на HTTPS-версию сайта. Но если идентификатор сессии один и тот же, то есть вероятность, что хакер перехватит незашифрованный трафик и получит доступ к идентификатору сессии. Если после входа на сайт тот же идентификатор будет передаваться по HTTPS, это пользователя уже не спасет, потому что идентификатор все же тот же. Закрытые сессии Когда пользователь говорит, что он хочет покинуть сайт, то на сервере для данного пользователя просто убивают cookie, которая отвечает за сессию. Пользователь теряет связь со своей сессией, ему создается новая, которая будет неавторизована. Это достаточно простое и вполне рабочее решение с точки зрения реализации, но если сессия на сервере, идентификатор сессии все еще существует, то пользователь может вручную установить этот идентификатор себе в cookie и восстановить ее. Пользователь этого делать не будет, но вот хакер может. Так что создавая видимость того, что сессия пользователя завершилась, мы обманываем пользователя, а хакер все еще сможет ее использовать. Если вы уничтожаете cookie, то убедитесь, что и сама сессия удаляется или помечается как некорректная. Сессии публичных сайтов Как мы уже отмечали, сессии должны быть короткими и должны устаревать — именно так делают банки. То же самое часто делают и публичные сайты, просто мы это не замечаем. Например, когда пользователь заходит на сайт Super Network, создается две сессии, и обе привязываются к одному и тому же аккаунту. Первая сессия долгосрочная и может быть активной в течение недели или даже месяца. Она дает пользователю право просматривать какую-то информацию или даже выполнять какие-то действия, но как только пользователь пытается выполнить чувствительное к персональным данным действие, то для этого проверяется вторая краткосрочная сессия. Если она устарела, то пользователя просят ввести пароль. Таким образом с помощью двух сессий мы можем контролировать, что сейчас разрешено. В случае с социальными сетями такое не пройдет, тут достаточно много действий, которые чувствительны к персональной информации. Что защищать короткой сессией? Публикацию новых записей нельзя, потому много блогеров публикуют новые записи регулярно. Запретить добавление в друзья тоже нельзя, некоторые это делают регулярно. В таких случаях единственное, что остается делать для защиты пользователей, — защищать аккаунт от смены имени и пароля и какой-то информации, которая относится к аккаунту. Если хакер каким-то магическим образом захватил сессию, то он сможет публиковать новые записи на стене, сможет добавлять других людей в друзья, но мы должны сделать все, чтобы он не смог поменять e-mail и пароль. Именно поэтому для смены e-mail и пароля в социальных сетях регулярно просят подтвердить текущий пароль. Те, кто украл сессию, не будут знать его и не смогут сменить пароль и/или e-mail. А что, если хакер каким-то образом получил доступ к паролю? Возможно, для этого использовалась социальная инженерия, и это не вина разработчиков сайта. Но и в этом случае разработчики пытаются пойти навстречу пользователям ради спасения своей репутации. Просто когда кто-то потеряет доступ к своему аккаунту, то ему будет все равно, по чьей вине это произошло — скорее всего, он будет винить именно разработчиков сайта. При смене логина или пароля обязательно отправьте e-mail с уведомлением, что данные изменились. В случае смены e-mail обязательно отправьте уведомление на старый адрес, который был до смены привязан к аккаунту. ГЛАВА 10 XSSВ последнее время очень много разговоров было о том, нужны ли файлы cookies или нет. Да, они позволяют сохранять web-сайтам информацию на компьютере пользователя и потом использовать ее для предоставления персонализированного содержимого web-страниц. В главе 9 мы уже видели, что одним из способов использования cookies является авторизация пользователя. В большинстве случаев это очень удобно, но далеко не безопасно. Меня не волнует, что web-сайты могут сохранять в таких файлах информацию о том, какие web- страницы я просматривал и чем интересуюсь, если эта информация не привязана конкретно ко мне, а хранится и используется анонимно. Эту информацию можно сохранить и без cookies. Меня волнует то, что эти данные может увидеть хакер. Один из способов воровства — атака XSS. Для реализации этой атаки хакеру необходимы базовые знания языка JavaScript. Этот язык очень прост и на первый взгляд абсолютно безобиден, потому что не имеет доступа к ресурсам компьютера. Единственное, что можно делать с помощью JavaScript, — управлять браузером, но для хакера иногда этого достаточно. Главное — внедрить свой JavaScript-код в web-страницу, а дальше уже действовать по ситуации. А ситуации бывают разные, их изучением мы и займемся в этой главе. 10.1. Основы XSS Опять же, все примеры сценариев в этой главе будут приведены на PHP, но в данном случае важен не язык, а идея, чтобы понять, как все работает. Атака и подход к защите выглядят примерно идентично во всех языках. Чаще всего XSS подвержены web-сайты, в которых используется аутентификация посредством данных, хранящихся в cookies, и есть возможность сохранять данные, которые в дальнейшем будут отображаться на web-странице. Ярким примером такого web-сайта является форум. Давайте рассмотрим простейший пример использования уязвимости. В листинге 10.1 приведен код сценария, который отображает форму для ввода имени пользователя и текста сообщения. Полученные данные со храняются в базе данных и отображаются на web-странице. Получается классическая гостевая книга. Листинг 10.1. Сценарий, уязвимый для атаки XSS XSS test<Ь3>Результат if ($_GET['button'] == 'Send') { ?> } ?> |