```
И вот, разработчик внедрил в HTML-документ всё, что нужно, настроил сервер, поднял его, и сайт начал функционировать. Через время появился человек, который сделал HTTP-запрос на сервер с целью получить главную страницу. Сервер запрос получает и перенаправляет запрос на дальнейшую обработку к программе-обработчику — например, PHP, фреймворку Flask, Ruby или ASP.NET. Программа внимательно изучает содержимое запроса — например, понимает, в каком формате нужно отправить ответ и какие именно файлы нужны(то есть, надо вернуть html, но html в свою очередь должен содержать и картинки, так что помимо неё нужно ещё отправить определённые картинки из `/var/www/images/`). Программа собирает всё, что нужно, передаёт результат серверу, а сервер передаёт результат уже браузеру пользователя. Браузер распаковывает полученный ответ и постепенно начинает отображать полученный контент на экране пользователя.
У вас может возникнуть вопрос: а зачем всё это было рассказано?
Ну, в моём ответе есть 2 пункта:
1) Вы повторили основы, а это всегда полезно:)
2) Вы теперь имеете представление о том, как на сервере происходит процесс отбора нужных файлов, которые нужно отправить в ответе пользователю. Мы рассмотрели по сути как статично задать то, какие файлики нужно отправить, а что если выборка файлов будет происходить динамично?
## Динамичное
Рассмотрим приложение для покупок, которое отображает изображения товаров для продажи. Изображения загружаются через HTML-тег, как показано ниже:
`
`
В качестве источника изображения у нас указан маршрут `/loadImage` с параметром filename. Он принимает и возвращает содержимое указанного файла. Сами файлы изображений хранятся на диске в папке `/var/www/images/`. Чтобы вернуть изображение, приложение добавляет запрошенное имя файла к этому базовому каталогу и использует API файловой системы для чтения содержимого файла. В приведенном выше случае приложение читает из следующего пути к файлу:
`/var/www/images/218.png`
И в этом не было ничего такого, ну обратывает приложенька пользовательский ввод(значение параметра filename, которое мы можем контролировать) и пусть обрабатывает. Однако, давайте вспомним вот такую интересную штучку:
Как мы помним, чтобы вернуться в родительскую директорию в терминале(linux, windows, mac os) мы можем использовать `../`. Так вот, такой приём также можно спокойно использовать не только в терминале, но и в той же HTML'ке или в HTTP-запросе, вместо того же 218.png можно указать `../../../../../../../../../etc/passwd` и получить не картинку, а информацию об существующих пользователях на сервере, где приложенька работает.
:::info
**Справочка**
Используя `../../../../../../../../../` в примере выше я как бы вышел из папки images, потом из www, потом из var, а потом ещё несколько "подъёмов" вверх, чтобы точно попасть в корневую папку. После я перешёл в директорию etc и попросил мне выдать файлик passwd.
:::
Теперь, после того как вы ознакомились с базой и поняли, что из себя представляет Directory Traversal, предлагаю наконец к ней перейти!
---
# Directory Traversal
:::warning
**Обход каталога** — это уязвимость, которая позволяет злоумышленнику читать произвольные файлы на сервере, на котором запущено приложение. Это может включать код приложения и данные, учетные данные для серверных систем и конфиденциальные файлы операционной системы.
Обычно здесь задействована комбинация из `../`, чтобы выйти из начальной папки и попасть в ту директорию, которая содержит "интересные" для нас файлы.
:::
Причём, чтобы переходить на один уровень вверх в Windows можно использовать и `../` и `..\`, это следует запомнить!
```https://insecure-website.com/loadImage?filename=..\..\..\windows\win.ini```
## Как обойти различные защиты, мешающие исполнить Directory Traversal?
Естественно, в реальной жизни не всё так просто, и разработчики могут попытаться защитить своё приложение от данной уязвимости, используя различные методы, которые можно обойти, давайте ознакомимся с ними!
### Использование абсолютного пути
:::info
**Лабораторная**:
https://portswigger.net/web-security/file-path-traversal/lab-absolute-path-bypass
:::
Если приложение удаляет или блокирует последовательности обхода каталога из имени файла, предоставленного пользователем, то можно обойти защиту, используя абсолютный путь от корня файловой системы, например `filename=/etc/passwd`, для прямой ссылки на файл без использования каких-либо последовательностей обхода.
**ПРИМЕР**
Не катит, так как есть проверка на последовательность обхода:
Использования абсолютного пути без обходов:
### Использование вложенных последовательностей обхода каталогов
:::info
**Лабораторная**:
https://portswigger.net/web-security/file-path-traversal/lab-sequences-stripped-non-recursively
:::
Если приложение удаляет или блокирует последовательности обхода каталога из имени файла, предоставленного пользователем, и при этом нельзя использовать абсолютный путь, то можно обойти защиту, используя вложенные последовательности обхода, такие как `....//` или `....\/`, которые вернутся к простым последовательностям обхода при удалении внутренней последовательности, проще говоря, это альтернатива для `../`
**ПРИМЕР**
Не катит, так как есть проверка на последовательность обхода:
Не катит, так как есть проверка на абсолютный путь:
Использование вложенных последовательностей обхода:
### URL-кодировка
:::info
**Лабораторная**:
https://portswigger.net/web-security/file-path-traversal/lab-superfluous-url-decode
:::
В некоторых контекстах, таких как URL-адрес или параметр filename запроса multipart/form-data, веб-серверы могут удалять любые последовательности обхода каталога перед передачей нашего ввода в приложение(то есть ни одно из перечисленных ранее методов не работает). Иногда можно обойти этот вид очистки с помощью кодирования URL-адресов или даже двойного кодирования URL-адресов, например, символов ../, что приводит к %2e%2e%2f или %252e%252e%252f соответственно.
Можно также использовать различные нестандартные кодировки, такие как ..%c0%af или ..%ef%bc%8f.
**ПРИМЕР**
Вот картинки, благодаря которым можно понять, что ни один из перечисленных ранее методов больше не работает:
А вот что будет, если мы закодируем в URL нашу полезную нагрузку(2 раза закодируем):
### Обход проверки начала пути
:::info
**Лабораторная**:
https://portswigger.net/web-security/file-path-traversal/lab-validate-start-of-path
:::
Если приложение требует, чтобы имя файла, заданное пользователем, начиналось с ожидаемой базовой папки, например /var/www/images, то можно включить требуемую базовую папку, за которой следуют подходящие последовательности обхода.
Например:
`filename=/var/www/images/../../../etc/passwd`
Тут думаю вы сами сможете решить эту лабу, она простая!
### Обход проверки расширения файла
:::info
**Лабораторная**:
https://portswigger.net/web-security/file-path-traversal/lab-validate-file-extension-null-byte-bypass
:::
Если приложение требует, чтобы введенное пользователем имя файла заканчивалось ожидаемым расширением файла, например .png, то можно использовать нулевой байт для того, чтобы опустить всё, что идёт дальше вместе с `.`(.png, .jpg ...).
Например:
`filename=../../../etc/passwd%00.png`
:::warning
Тут %00 - это и есть нулевой байт, закодированный в URL. Его можно сравнить со знаком комментария в ЯП или в SQL-запросах, то есть, всё, что идёт после него - не учитывается. Таким образом, в запросе в конце есть нужное расширение, но когда дело дойдёт до того, чтобы получить файл, исходное `filename=../../../etc/passwd%00.png` преобразуется в `filename=../../../etc/passwd`.
:::
## Как исправить данную уязвимость?
Самый эффективный способ предотвратить уязвимости, связанные с обходом пути к файлу, — полностью отказаться от передачи пользовательского ввода в API файловой системы. Многие прикладные функции, которые делают это, можно переписать, чтобы обеспечить то же самое поведение более безопасным способом. То есть, мы не должны пользовательский ввод "вкладывать" в путь к файлу, чтобы не было такого:
1) Приложение получает пользовательский ввод, например ../../../../../../etc/passwd
2) Приложение получает путь к папке с картинками - /var/www/images
3) Приложение соединяет путь к папке с пользовательским вводом - /var/www/images/../../../../../../etc/passwd
4) В итоге в HTML выходит что-то типа такого:
`
`.
Если же передача пользовательского ввода в API файловой системы считается неизбежной, то для предотвращения атак следует использовать вместе два уровня защиты:
1) Приложение должно проверять ввод пользователя перед его обработкой. В идеале проверка должна сравниваться с белым списком разрешенных значений. Если это невозможно для требуемой функциональности, то при проверке следует убедиться, что входные данные содержат только разрешенный контент, например чисто буквенно-цифровые символы. То есть, можно использовать различные проверки в коде, например, на наличие ../
2) После проверки предоставленных входных данных приложение должно добавить входные данные в базовый каталог и использовать API файловой системы платформы для канонизации пути. Он должен убедиться, что канонизированный путь начинается с ожидаемого базового каталога.
Ниже приведен пример простого кода Java для проверки канонического пути к файлу на основе пользовательского ввода:
```
File file = new File(BASE_DIRECTORY, userInput);
if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) {
// process file
}
```
## Всё?
И тут можно было бы поставить жирную точку и закончить этот топик, но..
Есть один такой момент=)
Directory Traversal это лишь подмножество другой баги, и эта бага уже называется совсем по-другому и умеет она не только читать файлы!
---
# Что такое LFI и RFI, и почему они так похожи на Directory Traversal
На схеме выше вы можете увидеть, что Directory Traversal - это лишь часть уязвимости Local File Inclusion, а она в свою очередь принадлежит уязвимости File inclusion. Давайте разберёмся, что такое File Inclusion и на что он делится!
:::warning
**Для начала давайте резберёмся с Directory Traversal:**
Уязвимость Path Traversal позволяет злоумышленнику получить доступ к файлу, обычно используя механизм «чтения», реализованный в целевом приложении.
*С помощью этой уязвимости мы можем читать файлы!*
**А теперь, что такое File Inclusion:**
Уязвимость File Inclusion(включение файла) позволяет злоумышленнику "включить" файл в ответ, обычно используя механизмы «динамического включения файлов», реализованные в целевом приложении.
*Если файл, который мы включаем в ответ, нельзя исполнить(так как его расширение веб-сервер не исполняет), то по сути мы просто получим его содержимое как в Directory Traversal, а вот если сервер настроен на исполнение файлов с таким расширением, то мы можем этот файл запустить, таким образом заставив, например, сервер исполнять зловредные скрипты!*
:::
А теперь давайте по порядку!
---
# Как использовать LFI
Давайте в качестве примера возьмём таск Саши (@i_013K) с тренировки, которая была в феврале и просто запустим его, после чего зайдём на сайтик.
Зайдя на страницу мы видим шапку, в которой есть разделы сайта, кликая на каждый раздел у нас меняется только основная часть сайта, а всё остальное остаётся таким же:
Также стоит обратить внимание, что при смене каждого раздела меняется и URL сайта:
А что это за файлы такие, которые изменяются?
Давайте глянем в код:
1) В папке с основными файлами у нас есть 5 мини HTML-файлов и один главный php-файл, который потом будет преобразован(после выполнения всего php-кода) в HTML на сервере и отдан именно HTML'кой клиенту.
2) Те самые ссылки в шапке, которые перекидывают то на ?file=1,2,3... Но это до сих пор не отвечает на вопрос, как изменяется контент сам, так как php страница тут одна, а отдельные мини html-файлы не годны для отдельного использования, так как они из себя представляют что-то такое:
3) Раз мини HTML-файлы не могут быть использованы отдельно, но мы их видим на сайте, значит они куда-то ВКЛЮЧАЮТСЯ, и вот тут как раз вступает в игру мини php-код почти в самом низу:
```
```
:::info
**Функция Include в PHP:**
На самом деле любой разрабатываемый ресурс не может поместится на одной странице, так как современный сайт состоит из десятков страниц, связанных между собой. Все файлы проекта можно сравнить с вагонами поезда. При необходимости можно убрать лишний, а при нехватке – удлинить «программный» состав еще на один. Для «сцепки» файлов используется функция **include** в PHP. Именно благодаря этой функции мы включаем контент мини HTML-файлов в наш php-файл!
То есть, мы можем создать 1 шаблон, и в него внедрять другие части, как это и сделано в таске. Шапка и прочее те же, а вот основной контент меняется в зависимости от страницы.
:::
:::warning
**Перед тем как продолжить я хочу разъяснить вот какой момент, он связан опять с базой по вебу, но его стоит упомянуть, так как дальше он сыграет важную роль:**
Как мы видим, в таске есть **1** php-файл, и сколько-то там HTML-файлов. И тут у многих может встать вопрос:
- А как так получилось, что тут основная страница в php, в которую внедряются html-ки, а по факту нам приходит один единый **HTML** файл?
Смотрите, я это упоминал раньше здесь "Сервер запрос получает и перенаправляет запрос на дальнейшую обработку к программе-обработчику — например, PHP, фреймворку Flask, Ruby или ASP.NET". И сейчас мы раскроем это предложение. Обычно сервер может как просто вернуть клиенту какой-то статичный файл(допустим просто обычную HTML'ку, картинку и тд), а может получить запрос на такой файл, который надо сначала **ОБРАБОТАТЬ**, и вот файл с расширением .php - один из таких файлов. Например, в таске у нас есть php-файл, который запрашивает пользователь, точнее он запрашивает не его, а главную страницу, но по факту это одно и тоже. Сервер, который настроен на исполнение .php файлов, дальше выясняет, что пользователь запросил как раз-таки этот файлик и видит, что этот файлик, грубо говоря, сырой, так как надо сначала выполнить весь php-код в нём. Для этого он передаёт данный php-файл с параметрами запроса программе-обработчику, в нашем случае это PHP. Дальше этот php, получив всё это, подставляем, если надо, что-то в этот файлик, а потом преобразует его в **HTML** и передаёт уже именно **его** веб-серверу. А веб-сервер передаёт уже готовый HTML пользователю.
Что сейчас произошло, если кратко:
Сервер настроен на то, чтобы **исполнять** php-файлы, и чтобы их исполнять он передаёт всё, что нужно для этого PHP'шке. После чего он результат исполнения возвращает пользователю.
:::
Так, вернёмся к коду:
```
```
Если разорбрать, что делает тут php-код, то получится следующее:
1) Если есть в запросе параметр file с каким-то значением, то выполняется следующий пункт, в противном случае этот php-код как бы исчезает, файл конвертируется в HTML и отдаётся пользователю.
2) Если всё же есть параметр file, то нужно вернуть такой файлик, который указан в значении параметра, т.е. если значение это 2, то нужно вернуть вернуть файл с именем 2(это как раз мини html'ka, хотя по факту это что угодно может быть, оно всё равно встроится в HTML и теги внутри просто будут как теги для HTML). А под словом вернуть имеется в виду, что в **это** конкретное место в коде "внедриться" этот мини html-файл. А потом этот php-файл конвертнётся в HTML(и весь php-код из него исчезнет) и этот HTML'ка вернётся пользователю.
И в чём тут уязвимость, и зачем мы всё это разбирали?
Да всё просто, тут есть LFI, и она тут есть, так как веб-приложение включает файл без правильной очистки ввода, что позволяет злоумышленнику манипулировать вводом и вводить символы обхода пути, а также включать другие файлы с того же веб-сервера.
И по сути мы можем тут провернуть тот же Directory Traversal!
Но так как тут именно LFI, мы можем не только читать файлы, но и исполнять команды, так как напоминаю о том, что было выше, веб-сервер может и порой должен исполнять некоторые файлы, и в данном случае тут исполняется php-код, а это значит мы можем сделать вредоноснгую нагрузку, связанную с php, чтобы например просмотреть путь до дериктории, в которой мы находимся:
И в результате нам "включится" в HTML файл вывод команды pwd!
Давайте ознакомимся со всеми возможностями LFI, чтобы у вас сложилось полное представление по ней:
## Чтение исполняемых файлов
Если есть LFI, то можно спокойно читать те файлы, которые не исполняемые, так как при попытке прочитать исполняемые файлы веб-сервер просто исполнит файл и вернёт результат, таким образом вы например не увидите секретные креды в php-файле. Однако это ограничение можно обойти с помощью встроенного php-фильтра.
```
php://filter
```
Можно прочитать содержимое исполняемого файла закодиров его в base64, используя следующую полезную нагрузку:
```
vuln.php?page=php://filter/convert.base64-encode/resource=/etc/passwd
```
А можно и без кодирования в base64:
`?page=php://filter/resource=/etc/passwd`
Картинок тут не будет, так как таск слегка ломается, но иногда вообщем и так можно:)
Поэтому многое зависит от конфигурации!!!
## Выполнение команд ОС
С помощью LFI, как я показывал ранее, можно выполнять команды в ОС.
Для этого есть 2 полезные нагрузки:
```
php?page=expect://ls (модуль PHP expect не включен по умолчанию)
```
Если URL-адрес включает =on в конфигурацию php.ini, мы можем легко выполнять команды ОС и получать обратную оболочку по data://text/plain,
```
data://text/plain,&cmd=whoami
```
## Обратная оболочка от LFI
Вообще, такое не приветствуется на стф:)
Но пару вещей скажу. Вообще есть 2 способа сделать обратную оболочку:
1) С помощью data://. Вы используете `data://text/plain, + php-код для обратного ревёрса` и netcat, чтобы включить порты для прослушивания `nc -lvp 1234`. Сначала второе делаете, а потом первое, и вот вы получили обратную оболочку!
2) Отравление логов. Тут советую ознакомиться с [ЭТИМ](https://effortlesssecurity.in/2021/08/01/lfi-rfi-from-basic-to-advance/) сайтом, тут всё подробно расписано!
---
# Как использовать RFI
:::warning
Используя **LFI**, злоумышленник может **получить** файлы с локального сервера, а также **выполнить** файлы локального сервера.
Используя **RFI**, злоумышленник может **запускать** файлы с удаленного сервера.
:::
Помимо того, что исполнять файлы можно локально, это также можно сделать и удалённо. Т.е. мы можем сделать зловредный скриптик где-нибудь на гитхабе и заставить сервер его исполнить!
## Чтение файлов и команды ОС
1) Создать txt или php файл со следующим содержимым: ``
2) Загрузить этот файл с вашего источника, исполняя команды ОС через параметр cmd:
## Reverse shell из-под RFI
Опять-таки не буду вам тут показывать эти гадости, но быстро пройдусь по пунктам:
1) создать файл с расширением txt или php с reverse shell'ом в гит тот же
2) подтянуть этот файл как в примере выше
3) получить оболочку и огрести люлей
---
# Домашка(по желанию)
Ну чтож, вот топик и подошёл к концу, предлагаю вам выполнить следующую домашку, чтобы закрепить материал:
1) Прорешать [раздел Directory Traversal](https://portswigger.net/web-security/file-path-traversal) в PortSwigger'e, он там простой!
2) Сказать, что ещё можно сделать с LFI/RFI.
3) Как исправить LFI/RFI.
4) Какие есть ограничения и моменты, которые следует помнить?
И на этом всё, спасибо вам, что дочитали данный топик, надеюсь вам было интересно и понятно!
Если есть вопросы - пишите в тг @ArroizX
