Межсайтовый скриптинг - недооценка угрозы

Межсайтовый скриптинг (или XSS) — это один из самых распространенных видов хакерской атаки на прикладном уровне. Целью XSS является вставка в страницу скриптов, которые обычно выполняются на стороне клиента (в браузере пользователя), а не на сервере. Угроза XSS обусловлена уязвимостью скриптовых языков на стороне клиента, в основном это касается HTML и JavaScript (а также VBScript, ActiveX, HTML, и Flash). Суть XSS заключается в следующем: злоумышленник воздействует на скрипты веб-приложения на стороне клиента, изменяя их выполнение. В результате в страницу встраивается скрипт, который будет выполняться каждый раз при загрузке страницы или при определенном событии.

Типичный пример XSS: злоумышленник внедряет скрипт в URL существующего интернет-магазина, который, в свою очередь, перенаправляет пользователя на поддельную, но идентичную страницу. На ней выполняется скрипт, который перехватывает значение cookie пользователя, просматривающего сайт интернет-магазина. Затем cookie отсылается злоумышленнику, который использует его для перехвата сессии пользователя. Хотя сайт магазина и не подвергается хакерской атаке, злоумышленник использует уязвимое место скрипта для того, чтобы обмануть пользователя и получить контроль над его сессией. Можно сделать поддельный URL менее заметным, закодировав XSS-часть URL в HEX, или с помощью другого метода кодировки. Это не вызовет подозрения у пользователя, который видит знакомый URL и, как правило, не обращает внимания на последующую закодированную часть.

Владельцы сайтов всегда уверены в себе, хакеры — тоже!

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

Последствия XSS-атак

Анализ различных XSS-атак свидетельствует о том, что, несмотря на постоянное развитие интернет-технологий, безопасность приложений остается на прежнем уровне. Проведя тщательный поиск, можно найти много историй о том, как сайты крупных корпораций были взломаны с использованием XSS-атак; в отчетах последствия таких атак всегда описываются как крайне серьезные.

XSS-атаки обычно используются в следующих преступных целях:

• Кража аккаунта;
• Получение доступа к защищенным или конфиденциальным данным;
• Получение бесплатного доступа к платному контенту;
• Слежение за посещением сайтов пользователем;
• Изменение настроек браузера;
• Публичная клевета в адрес отдельного лица или корпорации;
• Повреждение веб-приложения;
• DOS-атаки

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

Практический пример XSS на тестовом сайте

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

1. Введите в браузере адрес следующей страницы: http://testasp.acunetix.com/Search.asp, Вы увидите, что это простая страница с полем ввода текста поискового запроса.
   Рисунок 1
2. Попробуйте вставить следующий код в поле поиска и обратите внимание на то, как на странице будет отображаться поле регистрации:

   <br><br>Please login with the form below before proceeding:<form action="destination.asp">
   <table><tr><td>Login:</td><td><input type=text length=20 name=login></td>
   </tr><tr><td>Password:</td><td><input type=text length=20 name=password></td>
   </tr></table><input type=submit value=LOGIN></form>

   После вставки кода просто нажмите кнопку «Поиск».

   
   Рисунок 2

Из-за уязвимости страницы к XSS, стало возможным создать поддельную форму регистрации, которое можно использовать для сбора параметров доступа пользователя. На этапе 2 видно, что код содержит элемент «destination.asp». Здесь хакер может определить, куда поддельная форма регистрации будет отсылать параметры доступа для дальнейшего использования в преступных целях.

Хакер также может внедрить данный код, пропустив его через поле адреса браузера, как показано ниже:

http://testasp.acunetix.com/Search.asp?tfSearch=%3Cbr%3E%3Cbr%3EPlease+login+with+the+form+below+before+
proceeding%3A%3Cform+action%3D%22test.asp%22%3E%3Ctable%3E%3Ctr%3E%3Ctd%3ELogin%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+
length%3D20+name%3Dlogin%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3Ctd%3EPassword%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+
length%3D20+name%3Dpassword%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput+type%3Dsubmit+value%3DLOGIN%3E%3C%2Fform%3E

Рисунок 3

Это даст тот же результат, что демонстрирует различные способы применения XSS для достижения одних и тех же целей. После того, как хакер получит параметры доступа пользователя, он может легко вернуть настоящую страницу поиска, и пользователь даже не поймет, что его только что обманули. Также этот метод может применяться и при рассылке спама, который мы получаем каждый день. Очень часто пользователь находит у себя в ящике письмо, в котором сообщается, что на определенном интернет-аукционе кто-то использует аккаунт пользователя с преступными целями. Затем пользователя просят нажать на ссылку для подтверждения личности. Это тот же самый метод, при котором пользователя перенаправляют к поддельной форме регистрации, где его параметры доступа будут скопированы и отосланы хакеру.

Зачем ждать, пока Вас взломают?

Анализируя случаи недавних атак, можно прийти к заключению, что сайты крупных компаний и корпораций взламываются точно так же, как и сайты небольших фирм. Это наглядно демонстрирует то, что проблема безопасности заключается не в недостатке средств, а в отсутствии понимания сути угрозы у большинства компаний разного размера. Согласно статистике, 42% процента веб-приложений, требующих проверки безопасности, уязвимы к XSS-атакам, которые продолжают представлять высокую опасность. Попытки повысить информированность о том, как легко высококлассный хакер может проникнуть в уязвимое приложение, по всей видимости, не увенчались успехом. Все еще можно встретить владельцев сайтов с образом мышления типа: «Будем разбираться с проблемой, когда меня взломают», которые рискуют понести значительный финансовый ущерб и потерять доверие клиентов. Любой, кто захочет изучить эту тему глубже, обнаружит, как люди, называющие себя специалистами по вопросам безопасности, утверждают, что проблему XSS значительно преувеличивают, и с его помощью нельзя нанести серьезный ущерб веб-приложению. Однако дальнейшее исследование покажет, что статистические данные говорят сами за себя, и рост этих цифр в конце концов полностью опровергнет заявления этих скептически настроенных «специалистов».