Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
книги хакеры / Эдриан_Прутяну_Как_стать_хакером_сборник_практическиз_сценариев.pdf
Скачиваний:
18
Добавлен:
19.04.2024
Размер:
20.34 Mб
Скачать

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

 

E

 

 

 

 

X

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

w Click

to

BUY 214  Глава 9.Практические атаки на стороне клиента

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

 

.c

 

 

 

p

 

 

 

 

g

 

 

 

 

 

 

 

сложной,но по большей части нас интересует,какой источник разрешает

 

 

 

df

 

 

n

e

 

 

 

 

 

-xcha

 

 

 

 

кретный сайт, являющийся объектом атаки.

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

 

to

 

 

 

 

 

 

w Click

 

 

 

 

 

 

m

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

g

.c

 

 

 

p

 

 

 

 

 

 

 

кон-

 

 

 

e

 

 

 

 

df

 

 

n

 

 

 

 

 

 

 

 

-x cha

 

 

 

 

 

Межсайтовый скриптинг

Еще один распространенный тип атаки, с которым я до сих пор очень часто сталкиваюсь, – это межсайтовый скриптинг (XSS). Существует несколько вариантов данного типа атак, но все они дают злоумышленникам одно и то же: выполнение произвольного кода JavaScript в браузере клиента.

Возможно,это звучитнетак круто,как выполнение кода на реальном сервере приложений, но XSS-атаки могут иметь разрушительные последствия.

XSS-атака,основанная на отраженной уязвимости

Более распространенной является XSS-атака, основанная на отраженной уязвимости (reflected XSS).Эта атака происходит,когда приложение принимает данные, вводимые пользователем либо через параметры в URL-адресе или теле,либочерезHTTP-заголовки,ивозвращаетихпользователюбезпредвари- тельнойочистки.Данныйтипатакиназываетсянеперсистентным,потомучто, как только пользователь уходит с уязвимой страницы или закрывает браузер, эксплойт завершает работу. XSS-атаки, основанные на отраженной уязвимос­ ти, обычно требуют применения методов социальной инженерии ввиду эфемерного характера полезной нагрузки.

Чтобы продемонстрировать, как работают XSS-атаки, мы снова будем использовать проект badguys от Майка Пирната (Mike Pirnat).Код веб-приложения можно скачать на странице https://

github.com/mpirnat/lets-be-bad-guys.

Чтобы продемонстрировать этот тип уязвимости, я загрузил приложение на badguys.local. URL-адрес /cross-site-scripting/form-field уязвим для

XSS-атаки в параметре qs:

http://badguys.local/cross-site-scripting/form-field?qs=test

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

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

 

 

C

E

 

 

 

 

 

X

 

 

 

 

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

 

t

 

 

F

 

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

 

i

 

 

D

 

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

 

r

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

 

o

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

Межсайтовый скриптинг  215 BUY

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

w Click

to

 

 

 

 

 

 

 

 

 

 

 

 

to

 

 

 

 

 

 

 

 

 

 

 

 

 

 

m

w Click

 

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

o

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

g

.c

 

 

.

 

 

 

 

g

.c

 

 

 

p

 

 

 

 

 

 

 

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

e

Чтобы подтвердить наличие уязвимости, можно передать ей «полиглота»

 

 

e

 

 

 

 

df

 

 

n

 

 

 

 

 

 

 

 

df

 

 

n

 

 

 

 

 

 

 

 

-xcha

 

 

 

 

 

 

 

 

 

 

-x cha

 

 

 

 

 

Ахмеда Элсобки (Ahmed Elsobky), описанного в предыдущих главах, и наблюдать за поведением приложения.

jaVasCript:/*-/*’/*\’/*’/*”/**/(/* */oNcliCk=alert()

)//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/-- !>\x3csVg/<sVg/oNloAd=alert()//>\x3e

Кактолько мы сбросим бомбу,сервер приложения не пострадает,а вотстраница, отображаемая браузером, пострадать может. Можно увидеть последст­ вия этой атаки, проверив исходный код приложения вокруг затронутого поля ввода.

Рис.9.3. «Полиглот» обнаруживает уязвимость XSS

Окно оповещения появляется после того, как «полиглот» вставил тег <svg> со свойством onload, установленным для выполнения alert(). Это возможно благодаря тому, что приложение отразило полезную нагрузку без удаления опасных символов. Браузер интерпретировал первую двойную кавычку как часть поля ввода,что привело к уязвимости.

Постоянный XSS

Постоянный XSS (persistent XSS), также называемый хранимым XSS

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

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

 

C

 

E

 

 

 

 

 

X

 

 

 

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

 

t

 

 

F

 

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

 

i

 

 

D

 

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

r

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

NOW!

o

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

w Click

to

BUY 216  Глава 9.Практические атаки на стороне клиента

w Click

to

 

 

 

 

 

 

 

 

 

 

 

 

 

m

 

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

o

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

g

.c

 

 

.

 

 

 

 

g

.c

 

 

 

p

 

 

 

 

 

 

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

щающему уязвимую страницу. Xранимый XSS, как правило, не требует, чтобы

 

 

 

e

 

 

 

 

df

 

 

n

e

 

 

 

 

df

 

 

n

 

 

 

 

 

-xcha

 

 

 

 

 

 

 

 

 

-x cha

 

 

 

 

 

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

Простым примером хранимого XSS является раздел комментариев в блоге. Если пользовательский ввод (комментарий) не очищается перед сохранением, любой пользователь, который читает комментарий, выполнит любой вредоносный код, сохраненный в приложении.

Возможно, наиболее известным примером хранимой атаки XSS является червь Samy (также известный как MySpace Worm или JS.Spacehero).

Из-за отсутствия надлежащей очистки входных данных Samy удалось высвободить фрагмент кода JavaScript, который заставлял жертву, вошедшую в свою учетную запись на MySpace, выполнить ряд действий:

обновитьсвой профиль,включив в него фразу «но самое главное,Сами– мой герой»;

отправить запрос на дружбу в профиль Сами Камкара.

На первый взгляд это выглядит довольно безобидно, и те немногие пользователи, которые посетили профиль Сами, были слегка раздражены и в конечном итоге двигалисьдальше.Однако Сами Камкар (Samy Kamkar) прославился благодарятому,чтопрофильжертвытакжеобновлялсяиполучалтотжевредоносный код JavaScript, который выполнялся в браузере жертвы при просмотре зараженного профиля,что превратило XSS-атаку в XSS-червя.

Всего за 20 часов в профиль Сами поступило более 1 млн запросов на добавление в друзья, что свидетельствует о реальном влиянии этой конкретной атаки.

Полное объяснение того, как была осуществлена эта хитроумная атака,включая окончательный вредоносный код,можно найти на личном сайте Сами Камкара: https://samy.pl/myspace/tech.html.

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

Обнаружение хранимого XSS может оказаться немного сложнее, поскольку мы не всегда знаем, где и когда будет отражена полезная нагрузка. Воттут помогутметоды обнаружения уязвимостей,которые мы рассмотрели в предыдущих главах.

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

 

F

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

 

NOW!

 

o

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

 

 

 

 

 

to

 

 

 

 

 

 

w Click

 

 

 

 

 

 

m

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

 

.c

 

 

 

p

 

 

 

 

g

 

DOM-модели

 

 

 

df

 

 

n

e

 

 

 

 

 

 

-xcha

 

 

 

 

 

Межсайтовый скриптинг 

 

 

 

 

hang

e

 

 

 

 

 

 

 

C

E

 

 

 

 

X

 

 

 

 

 

-

 

 

 

 

d

 

 

F

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

r

P

 

 

 

 

NOW!

o

 

 

 

 

 

 

217 BUY

 

 

 

 

 

 

 

w Click

to

 

 

 

 

m

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

o

 

 

.

 

 

 

 

.c

 

 

 

p

 

 

 

g

 

 

 

 

 

df

 

n

e

 

 

 

 

 

-x cha

 

 

 

 

Данный тип XSS-атаки происходит, когда код приложения на стороне клиента считываетданные из DOM и использует их небезопасным способом.

DOM – это, по сути, структура данных в памяти браузера, которая содержит все объекты натекущей странице.Сюда входятHTML-теги и их свойства,заголовок документа,теги <head>,<body> и даже URL-адрес.JavaScript можетвзаи­ модействовать с DOM и изменять, добавлять или удалять практически любую его часть, немедленно затрагивая саму страницу.

Лучший способ продемонстрировать влияние DOM-модели XSS–использо- вать простое уязвимое приложение.

На приведенном ниже скриншоте у нас есть код JavaScript, который будет приветствовать пользователя на странице.

Рис.9.4. Пример страницы,уязвимой для XSS-атаки через DOM

Это приложение будет сканировать URL-адрес документа для определения положения параметра name с помощью функции document.URL.indexOf(). Затем оно возьмет текст, начинающийся сразу после name = с помощью функции document.URL.substring(), и сохранит значение в переменной name.

В строке 11 выполняется доступ к элементу welcome с помощью метода getElementById().В строке 12 происходит волшебство.Приложение заполнит содержимое элемента втегах <span> содержимым параметра name,полученного ранее, используя свойство innerHTML объекта welcome.

Можно увидеть предполагаемую функциональность приложения на рис.9.5. Элемент span в DOM обновлен с помощью значения, переданного через URL-адрес, и все выглядит хорошо. Приложение предоставляет динамическое содержимое страницы без необходимости программирования на стороне сер-

вера.

XSS-уязвимость существует, потому что мы можем передавать произвольные значения через URL-адрес, который будет отражен в DOM. Приложение анализирует URL-адрес и заполняет элемент welcome, не прибегая к очистке

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

 

hang

e

 

 

 

 

 

 

 

 

C

 

E

 

 

 

 

 

 

C

 

E

 

 

 

 

 

X

 

 

 

 

 

 

 

 

X

 

 

 

 

 

 

 

-

 

 

 

 

 

d

 

 

-

 

 

 

 

 

d

 

 

F

 

 

 

 

 

 

 

t

 

 

F

 

 

 

 

 

 

 

t

 

 

D

 

 

 

 

 

 

 

 

i

 

 

D

 

 

 

 

 

 

 

 

i

 

 

 

 

 

 

 

 

 

 

r

 

 

 

 

 

 

 

 

 

r

P

 

 

 

 

NOW!

o

P

 

 

 

 

 

NOW!

o

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BUY

 

 

w Click

to

BUY 218  Глава 9.Практические атаки на стороне клиента

w Click

to

 

 

 

 

 

 

 

 

 

 

 

 

 

m

 

 

 

 

 

 

 

m

w

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

 

 

 

w

 

 

 

 

 

 

 

 

o

 

 

w

 

 

 

 

 

 

 

 

o

 

 

.

 

 

 

 

g

.c

 

 

.

 

 

 

 

g

.c

 

 

 

p

 

 

 

 

 

 

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

входных данных, что позволяет нам вставлять не только имя и потенциально

 

 

 

e

 

 

 

 

df

 

 

n

e

 

 

 

 

df

 

 

n

 

 

 

 

 

-xcha

 

 

 

 

 

 

 

 

 

-x cha

 

 

 

 

 

выполнять дополнительный код JavaScript.

Рис.9.5. DOM обновлен,чтобы включить в свой состав имя из URL-адреса

Данная атака напоминает XSS-атаку, основанную на отраженной уязвимости, с одним важным отличием: код JavaScript не «отражается» кодом сервера, азаполняетсякодомклиента.Веб-серверпо-прежнемубудетвидетьвредонос- ный код в запросе,и любые брандмауэры веб-приложений могут потенциально блокировать нашу атаку,разорвав соединение,но очистка входных данных приложения здесь не возымеет никакого эффекта.

Еще одна проблема,связанная с этим конкретным фрагментом кода,заключается в том, что параметры GET не анализируются безопасно. Здесь используются строковые функции, чтобы пройти по URL-адресу и получить произвольные данные.

Если мы создаем вредоносный URL-адрес, нам не нужно использовать знак вопроса (?) для разделения параметров. Вместо этого можно использовать символ хештега (#). Это называется хештегом местоположения, и да, это часть DOM, доступная через JavaScript. Браузеры не отправляют хештег-данные вместе­ с HTTP-запросами, что дает нам преимущество, и мы можем не передавать свой вредоносный код на сервер, минуя брандмауэр веб-приложения или XSS-фильтры на стороне сервера, при этом по-прежнему имея возможность выполнять код JavaScript.

Наш URL-адрес полезной нагрузки для осуществления XSS-атаки в DOMмодели будет выглядетьтак:

http://c2.spider.ml/welcome.html#name=<svg/onload=alert(1)>

Код приложения на стороне клиента работает просто отлично и вставляет нашего вредоноса прямо в DOM.