Ребятки, у меня освободилось 2-3 места на индивидуальное обучение таким направлениям, как
- Тестирование безопасности (OWASP, ZAP, Postman, SQL, Linux, Programming)
- QA Automation JavaScript Playwright, кому нужно подтянуть знания, пишите, буду рад с вами поработать
Мой Телеграм @faroeman
- Тестирование безопасности (OWASP, ZAP, Postman, SQL, Linux, Programming)
- QA Automation JavaScript Playwright, кому нужно подтянуть знания, пишите, буду рад с вами поработать
Мой Телеграм @faroeman
❤7🔥4🙏2
Разбираем вчерашнюю задачку
В пентесте ключевой документ — scope.
Он определяет:
— какие системы можно тестировать
— какие методы разрешены
— где заканчивается ваша зона ответственности
Если выйти за него, даже случайно, это уже может выглядеть как:
🛑несанкционированный доступ.
——————————————————————————
Поэтому всегда нужно уточнять SCOPE!
ПРАВИЛЬНЫЙ ОТВЕТ - B!
А значит формально:
———————————————————————————
А вообще, есть один лайфхак, который применяют на практике чаще всего:
1️⃣ находим актив
2️⃣ фиксируем его
3️⃣ сообщаем заказчику
4️⃣ получаем подтверждение и продолжаем тестирование
Таким образом, мы защищаем себя юридически, не ломаем инфру и сохраняем прозрачность работы.
В пентесте ключевой документ — scope.
Он определяет:
— какие системы можно тестировать
— какие методы разрешены
— где заканчивается ваша зона ответственности
Если выйти за него, даже случайно, это уже может выглядеть как:
🛑несанкционированный доступ.
——————————————————————————
Поэтому всегда нужно уточнять SCOPE!
Даже если поддомен принадлежит компании,
он не был явно указан в области тестирования.
А значит формально:
у нас нет разрешения его атаковать.
———————————————————————————
А вообще, есть один лайфхак, который применяют на практике чаще всего:
1️⃣ находим актив
2️⃣ фиксируем его
3️⃣ сообщаем заказчику
4️⃣ получаем подтверждение и продолжаем тестирование
Таким образом, мы защищаем себя юридически, не ломаем инфру и сохраняем прозрачность работы.
6🔥4
XSS (Cross-Site Scripting) — это уязвимость веб-приложения, при которой злоумышленник может вставить и выполнить JavaScript-код в браузере другого пользователя.
Проще говоря:
Из-за этого атакующий может действовать от имени пользователя сайта.
Давайте разберемся на практике, как это работает:
в строке поиска видим:
на сайте отображается:
Но если разработчик немного подзабил😐 и не фильтрует ввод, то можно передать немного кода на JS и в браузере выполнится код
⚠️ А дальше уже дело техники злоумышленника:
он может:
— украсть cookie / session токены
— выполнять действия от имени пользователя
— перенаправить пользователя на фишинговую страницу
— внедрить вредоносный JS
— читать данные страницы
Например:
🔍 Основные типы XSS
1️⃣ Reflected XSS
Самый простой тип.
Payload передаётся в URL и сразу отображается на странице.
Пример:
Пользователь переходит по ссылке → код выполняется.
2️⃣ Stored XSS
Более опасный вариант.
Payload сохраняется на сервере (например в комментарии).
Когда другие пользователи открывают страницу — код выполняется у них.
Пример:
— комментарий на форуме
— поле профиля
— сообщение в чате
3️⃣ DOM-based XSS
Здесь ошибка не на сервере, а в JavaScript сайта.
Скрипт страницы неправильно обрабатывает данные из URL или DOM.
Хештеги: #web #owasp
Проще говоря:
сайт отображает пользовательский ввод без фильтрации,
и браузер выполняет этот код как обычный JavaScript.
Из-за этого атакующий может действовать от имени пользователя сайта.
Давайте разберемся на практике, как это работает:
в строке поиска видим:
https://site.com/search?q=test
на сайте отображается:
Вы искали: test
Но если разработчик немного подзабил😐 и не фильтрует ввод, то можно передать немного кода на JS и в браузере выполнится код
<script>alert(1)</script>
⚠️ А дальше уже дело техники злоумышленника:
он может:
— выполнять действия от имени пользователя
— перенаправить пользователя на фишинговую страницу
— внедрить вредоносный JS
— читать данные страницы
Например:
<script>alert(document.cookie)</script>
🔍 Основные типы XSS
1️⃣ Reflected XSS
Самый простой тип.
Payload передаётся в URL и сразу отображается на странице.
Пример:
site.com/search?q=<script>alert(1)</script>
Пользователь переходит по ссылке → код выполняется.
2️⃣ Stored XSS
Более опасный вариант.
Payload сохраняется на сервере (например в комментарии).
Когда другие пользователи открывают страницу — код выполняется у них.
Пример:
— комментарий на форуме
— поле профиля
— сообщение в чате
3️⃣ DOM-based XSS
Здесь ошибка не на сервере, а в JavaScript сайта.
Скрипт страницы неправильно обрабатывает данные из URL или DOM.
Хештеги: #web #owasp
🔥12🙏3❤1
Нашел отчет из bug bounty, как раз по вчерашней теме XSS.
Отчет был сделан для популярного сервиса
XSS находилась в параметре поиска:
Если передать такой payload:
иногда браузер выполнял JavaScript.
Интересно, что данный PAYLOAD срабатывал не всегда.
Иногда страница просто загружается, а иногда появляется alert.
Возможно это было связано, с:
— работа WAF
— кеширование страницы
— фильтрация на стороне сервера
Но тем не менее:
Даже если payload срабатывает 1 раз из 5, этого достаточно для атаки.
Поэтому всегда пробуйте, тестируйте и подходите к атаке творчески и с нескольких сторон😄
🔹 Ссылка на отчет
Отчет был сделан для популярного сервиса
lady.mail.ruXSS находилась в параметре поиска:
https://lady.mail.ru/search/?q=
Если передать такой payload:
-alert(document.cookie)-""
Интересно, что данный PAYLOAD срабатывал не всегда.
Иногда страница просто загружается, а иногда появляется alert.
Возможно это было связано, с:
— работа WAF
— кеширование страницы
— фильтрация на стороне сервера
Но тем не менее:
даже нестабильная XSS — всё равно XSS.
Даже если payload срабатывает 1 раз из 5, этого достаточно для атаки.
Поэтому всегда пробуйте, тестируйте и подходите к атаке творчески и с нескольких сторон😄
🔹 Ссылка на отчет
❤5🔥1🙏1
Broken Access Control: Почему "зеленые" тесты -это самая опасная иллюзия в ИТ?
В последнем рейтинге OWASP Top 10 (2025) категория Broken Access Control (Нарушение контроля доступа) официально признана угрозой #1. И ирония в том, что это самая "невидимая" проблема для стандартного QA-процесса.
Большинство команд живут в парадигме: "Если пользователь залогинился и кнопка работает - значит, всё безопасно".
На самом деле, это только начало.
Что такое Broken Access Control на практике? Это когда система пускает пользователя туда, куда ему нельзя, просто потому что никто не проверил границы.
Вот 3 сценария, которые я постоянно нахожу на тестовых машинах :
--- Insecure Identifiers (Тот самый BOLA): Изменение ID в URL или теле запроса. Если я могу посмотреть профиль коллеги, просто поменяв цифру в ссылке - ваш контроль доступа сломан.
--- Privilege Escalation (Повышение прав): Я захожу как обычный "User", но пробую достучаться до /api/admin/delete_user. Если сервер отвечает 200 OK вместо 403 Forbidden - у вас огромная проблема.
--- Metadata Manipulation: Изменение роли прямо в JWT-токене или Cookie. Если я меняю в браузере role: user на role: admin и система мне верит - это классический провал контроля доступа.
Почему это пропускают? Потому что это логические ошибки, а не технические баги. Автотесты проверяют функционал, но они редко проверяют отсутствие доступа (хотя могут). Мы учим тесты нажимать на кнопки, но не учим их пытаться взл0мать систему.
Мой совет инженерам: Каждый тест должен задавать вопрос: "Имеет ли этот конкретный юзер право на это конкретное действие?".
Если ответа в коде теста нет - вы тестируете вслепую.
Кроме шуток, вероятность пропустить такую багу - крайне большая.
По обучению пишите мне в ТГ @faroeman
В последнем рейтинге OWASP Top 10 (2025) категория Broken Access Control (Нарушение контроля доступа) официально признана угрозой #1. И ирония в том, что это самая "невидимая" проблема для стандартного QA-процесса.
Большинство команд живут в парадигме: "Если пользователь залогинился и кнопка работает - значит, всё безопасно".
На самом деле, это только начало.
Что такое Broken Access Control на практике? Это когда система пускает пользователя туда, куда ему нельзя, просто потому что никто не проверил границы.
Вот 3 сценария, которые я постоянно нахожу на тестовых машинах :
--- Insecure Identifiers (Тот самый BOLA): Изменение ID в URL или теле запроса. Если я могу посмотреть профиль коллеги, просто поменяв цифру в ссылке - ваш контроль доступа сломан.
--- Privilege Escalation (Повышение прав): Я захожу как обычный "User", но пробую достучаться до /api/admin/delete_user. Если сервер отвечает 200 OK вместо 403 Forbidden - у вас огромная проблема.
--- Metadata Manipulation: Изменение роли прямо в JWT-токене или Cookie. Если я меняю в браузере role: user на role: admin и система мне верит - это классический провал контроля доступа.
Почему это пропускают? Потому что это логические ошибки, а не технические баги. Автотесты проверяют функционал, но они редко проверяют отсутствие доступа (хотя могут). Мы учим тесты нажимать на кнопки, но не учим их пытаться взл0мать систему.
Мой совет инженерам: Каждый тест должен задавать вопрос: "Имеет ли этот конкретный юзер право на это конкретное действие?".
Если ответа в коде теста нет - вы тестируете вслепую.
Кроме шуток, вероятность пропустить такую багу - крайне большая.
По обучению пишите мне в ТГ @faroeman
🔥9❤4🙏2👌1
Часто слышу: "Пентестеры - это какие-то гении, которые за пять минут обходят любую защиту".
Реальность куда прозаичнее. 90% успешных проникновений случаются не потому, что хакер -гений, а потому что кто-то на проде поленился сделать свою работу.
Пентест - это когда ты приходишь в систему, которую строили полгода, и находишь там детские косяки, которые просто никто не потрудился проверить.
Топ-3 моих любимых находок за последнее время:
—- Забытые эндпоинты. Разработчики выкатили новую фичу, а старый API /api/v1/debug_info забыли отключить. И там - весь дамп базы в открытом виде. Без пароля. Без регистрации. Просто забыли»
—- Broken Access Control (да, опять он). Система проверяет, что ты залогинился, но ей плевать, чьи данные ты запрашиваешь. Меняешь id в запросе и читаешь переписку гендиректора. Это не взлом, это просто отсутствие одной строчки кода if (user != owner).
—- Хардкодные секреты. В коде приложения зашит API-ключ от облака или пароль от тестовой базы, который по счастливому совпадению подходит и к боевой.
В чем прикол быть пентестером?
В том, что ты - единственный человек в цепочке производства софта, который смотрит на проект глазами плохого парня.
Разработчик думает: Как это запустить?
Тестировщик думает: Как это работает?.
Пентестер думает: Как это сломать и вынести всё ценное?.
Это совершенно другой уровень азарта. Ты не просто ищешь баги, ты ищешь возможности. И когда ты находишь дыру, которая позволяет выкачать данные миллиона пользователей через обычное поле поиска - это дает такой прилив адреналина, который не даст ни один спринт или релиз.
P.S. Самое смешное, что после твоего отчета команда разработчиков сначала тебя ненавидит, а потом благодарит. Потому что лучше, если эту дыру найдешь ты и опишешь в отчете, чем какой-нибудь аноним из Даркнета, который просто выставит базу на продажу.
А какой самый нелепый взлом или баг находили вы? Делитесь в комментариях, обсудим.
👇👇👇👇👇👇👇👇👇👇
Реальность куда прозаичнее. 90% успешных проникновений случаются не потому, что хакер -гений, а потому что кто-то на проде поленился сделать свою работу.
Пентест - это когда ты приходишь в систему, которую строили полгода, и находишь там детские косяки, которые просто никто не потрудился проверить.
Топ-3 моих любимых находок за последнее время:
—- Забытые эндпоинты. Разработчики выкатили новую фичу, а старый API /api/v1/debug_info забыли отключить. И там - весь дамп базы в открытом виде. Без пароля. Без регистрации. Просто забыли»
—- Broken Access Control (да, опять он). Система проверяет, что ты залогинился, но ей плевать, чьи данные ты запрашиваешь. Меняешь id в запросе и читаешь переписку гендиректора. Это не взлом, это просто отсутствие одной строчки кода if (user != owner).
—- Хардкодные секреты. В коде приложения зашит API-ключ от облака или пароль от тестовой базы, который по счастливому совпадению подходит и к боевой.
В чем прикол быть пентестером?
В том, что ты - единственный человек в цепочке производства софта, который смотрит на проект глазами плохого парня.
Разработчик думает: Как это запустить?
Тестировщик думает: Как это работает?.
Пентестер думает: Как это сломать и вынести всё ценное?.
Это совершенно другой уровень азарта. Ты не просто ищешь баги, ты ищешь возможности. И когда ты находишь дыру, которая позволяет выкачать данные миллиона пользователей через обычное поле поиска - это дает такой прилив адреналина, который не даст ни один спринт или релиз.
P.S. Самое смешное, что после твоего отчета команда разработчиков сначала тебя ненавидит, а потом благодарит. Потому что лучше, если эту дыру найдешь ты и опишешь в отчете, чем какой-нибудь аноним из Даркнета, который просто выставит базу на продажу.
А какой самый нелепый взлом или баг находили вы? Делитесь в комментариях, обсудим.
👇👇👇👇👇👇👇👇👇👇
🔥27❤7🙏1
Stored XSS: Почему это критический риск для продукта
Stored XSS - это тип атаки, при котором вредоносный скрипт сохраняется на сервере (в БД) и автоматически исполняется в браузере каждого пользователя, открывшего страницу.
В отличие от обычной XSS, хакеру не нужно присылать жертве ссылку. Достаточно один раз отравить базу данных.
В чем главная опасность:
Кража сессий: Если куки не защищены флагом HttpOnly, скрипт крадет document.cookie. Атакующий получает доступ к аккаунту без логина и пароля.
Атака на админку: Хакер оставляет скрипт в тикете техподдержки или деталях заказа. Когда админ открывает этот тикет, скрипт срабатывает и от его имени создает нового пользователя с правами супер-админа.
Масштабируемость: Один скрипт в популярном товаре или посте может скомпрометировать тысячи сессий за считанные минуты.
Почему это пропускают:
Разработчики часто фильтруют данные на входе (input), но забывают про безопасный вывод (output encoding). Если приложение использует функции вроде dangerouslySetInnerHTML, защита фреймворков просто отключается.
Вопрос к студии:
Вы в своей жизнь хоть раз находили хоть одну XSS?
Stored XSS - это тип атаки, при котором вредоносный скрипт сохраняется на сервере (в БД) и автоматически исполняется в браузере каждого пользователя, открывшего страницу.
В отличие от обычной XSS, хакеру не нужно присылать жертве ссылку. Достаточно один раз отравить базу данных.
В чем главная опасность:
Кража сессий: Если куки не защищены флагом HttpOnly, скрипт крадет document.cookie. Атакующий получает доступ к аккаунту без логина и пароля.
Атака на админку: Хакер оставляет скрипт в тикете техподдержки или деталях заказа. Когда админ открывает этот тикет, скрипт срабатывает и от его имени создает нового пользователя с правами супер-админа.
Масштабируемость: Один скрипт в популярном товаре или посте может скомпрометировать тысячи сессий за считанные минуты.
Почему это пропускают:
Разработчики часто фильтруют данные на входе (input), но забывают про безопасный вывод (output encoding). Если приложение использует функции вроде dangerouslySetInnerHTML, защита фреймворков просто отключается.
Вопрос к студии:
Вы в своей жизнь хоть раз находили хоть одну XSS?
❤6🔥3🙏1
SSTI: Как заставить сервер считать за тебя (и не только)
Представь, что ты заходишь на сайт, вводишь свое имя в профиле, а сервер вместо Привет, Иван! выполняет твою команду. Это и есть SSTI (Server-Side Template Injection) - одна из самых недооцененных, но опасных уязвимостей в вебе.
В чем суть?
Разработчики используют шаблоны (Templates), чтобы динамически собирать страницы. Это как бланки, где есть пустые места для имени пользователя или цены товара. Популярные движки: Jinja2, Twig, Smarty.
Уязвимость возникает, когда ввод пользователя попадает прямо в мозг шаблонизатора без фильтрации.
Как это проверяет хакер?
Классический тест - математика.
В поле имени вбиваем: {{7*7}} (или ${7*7}).
Если после сохранения профиля сайт пишет: Привет, 49! - поздравляю, у нас SSTI.
Почему это фиаско?
Если сервер посчитал 7*7, значит, он выполнил код внутри фигурных скобок. Следующим шагом хакер введет не математику, а команду на доступ к файловой системе или базе данных. Это прямой путь к RCE (Remote Code Execution) - когда ты захватываешь сервак.
Почему в моем последнем аудите это не сработала? 🛡
Я прогнал тесты на одном приложении, и результат был: Привет, {{7*7}}!.
Это значит:
✅ Движок настроен верно.
✅ Весь ввод экранируется.
✅ Сервер воспринимает скобки просто как текст, а не как команду.
Мораль 😀: Разработчики, не склеивайте строки в шаблонах! Используйте передачу данных через контекст. Это сэкономит вам кучу нервов и денег на Bug Bounty.
Представь, что ты заходишь на сайт, вводишь свое имя в профиле, а сервер вместо Привет, Иван! выполняет твою команду. Это и есть SSTI (Server-Side Template Injection) - одна из самых недооцененных, но опасных уязвимостей в вебе.
В чем суть?
Разработчики используют шаблоны (Templates), чтобы динамически собирать страницы. Это как бланки, где есть пустые места для имени пользователя или цены товара. Популярные движки: Jinja2, Twig, Smarty.
Уязвимость возникает, когда ввод пользователя попадает прямо в мозг шаблонизатора без фильтрации.
Как это проверяет хакер?
Классический тест - математика.
В поле имени вбиваем: {{7*7}} (или ${7*7}).
Если после сохранения профиля сайт пишет: Привет, 49! - поздравляю, у нас SSTI.
Почему это фиаско?
Если сервер посчитал 7*7, значит, он выполнил код внутри фигурных скобок. Следующим шагом хакер введет не математику, а команду на доступ к файловой системе или базе данных. Это прямой путь к RCE (Remote Code Execution) - когда ты захватываешь сервак.
Почему в моем последнем аудите это не сработала? 🛡
Я прогнал тесты на одном приложении, и результат был: Привет, {{7*7}}!.
Это значит:
✅ Движок настроен верно.
✅ Весь ввод экранируется.
✅ Сервер воспринимает скобки просто как текст, а не как команду.
Мораль 😀: Разработчики, не склеивайте строки в шаблонах! Используйте передачу данных через контекст. Это сэкономит вам кучу нервов и денег на Bug Bounty.
🔥8🙏2❤1👌1
🚨 Открыт набор сразу на 2 обучения по кибербезопасности. Живое обучение. Практика. Без воды.
Если вы хотите войти в кибербезопасность или начать заниматься пентестом, сейчас есть два формата обучения.
⸻
🤖👁️ Введение в кибербезопасность
От основ до Security Testing
Курс для тех, кто только начинает путь в cybersecurity и хочет понять, как реально устроена безопасность систем.
Что будет на курсе:
• основы кибербезопасности
• как работают атаки на веб-приложения
• базовые методы поиска уязвимостей
• введение в security testing
• практика и разбор реальных сценариев
📚 Длительность: 12 часов
🎯 Уровень: начинающий
💻 Формат: живые онлайн занятия
Подробности:
https://brainupacademy.com/cybersecurity-intro-course.html
—————————————————
🕵️♂️ Специалист по кибербезопасности
Этичный хакинг и OWASP
Практический курс для тех, кто хочет освоить пентест веб-приложений и работу с профессиональными инструментами.
На курсе:
• реальные техники ethical hacking
• поиск уязвимостей из OWASP
• работа с Burp Suite
• анализ запросов и атак на веб-приложения
• практика на уязвимых системах
📚 Длительность: 30–40 часов
🎯 Уровень: начинающий / средний
💻 Формат: только живое онлайн обучение
Плюсы формата:
• можно задавать вопросы прямо во время урока
• разбор ошибок студентов
• дополнительное общение в чате после занятий
Подробности:
https://brainupacademy.com/security-testing-course.html
⸻
📩 Запись и вопросы:
Пишите в Telegram — @faroeman
Количество мест ограничено.
Группы небольшие, чтобы можно было реально разбирать практику каждого участника
Если вы хотите войти в кибербезопасность или начать заниматься пентестом, сейчас есть два формата обучения.
⸻
🤖👁️ Введение в кибербезопасность
От основ до Security Testing
Курс для тех, кто только начинает путь в cybersecurity и хочет понять, как реально устроена безопасность систем.
Что будет на курсе:
• основы кибербезопасности
• как работают атаки на веб-приложения
• базовые методы поиска уязвимостей
• введение в security testing
• практика и разбор реальных сценариев
📚 Длительность: 12 часов
🎯 Уровень: начинающий
💻 Формат: живые онлайн занятия
Подробности:
https://brainupacademy.com/cybersecurity-intro-course.html
—————————————————
🕵️♂️ Специалист по кибербезопасности
Этичный хакинг и OWASP
Практический курс для тех, кто хочет освоить пентест веб-приложений и работу с профессиональными инструментами.
На курсе:
• реальные техники ethical hacking
• поиск уязвимостей из OWASP
• работа с Burp Suite
• анализ запросов и атак на веб-приложения
• практика на уязвимых системах
📚 Длительность: 30–40 часов
🎯 Уровень: начинающий / средний
💻 Формат: только живое онлайн обучение
Плюсы формата:
• можно задавать вопросы прямо во время урока
• разбор ошибок студентов
• дополнительное общение в чате после занятий
Подробности:
https://brainupacademy.com/security-testing-course.html
⸻
📩 Запись и вопросы:
Пишите в Telegram — @faroeman
Количество мест ограничено.
Группы небольшие, чтобы можно было реально разбирать практику каждого участника
BRAINUP ACADEMY
Специалист по кибербезопасности: Этичный хакинг и OWASP | BRAINUP ACADEMY
Станьте специалистом по кибербезопасности Освойте пентест работу с Burp Suite и OWASP TOP 10. Преподаватель - участник CTF.
❤3🔥2🙏1👌1
CSP: Механизм защиты от выполнения стороннего кода
Content Security Policy (CSP) - это HTTP-заголовок ответа, который позволяет администраторам сайта четко ограничить ресурсы (скрипты, стили, изображения), разрешенные для загрузки и исполнения в браузере пользователя.
По умолчанию браузеры доверяют любому коду, который загружается с текущего домена (Same-Origin Policy). Это создает условия для успешных XSS-атак: если злоумышленник внедрит свой JS-код в базу данных или через параметры запроса, браузер исполнит его как доверенный.
Риски при отсутствии CSP:
Эксплуатация XSS (Cross-Site Scripting): Атакующий внедряет скрипт, который считывает данные из форм ввода (логины, пароли, данные карт) или крадет сессионные куки (document.cookie), передавая их на сторонний сервер.
Инъекция стороннего контента: Без ограничений по источникам злоумышленник может подменить легитимные скрипты на свои или добавить на страницу сторонние фреймы (iframe), имитирующие интерфейс платежных систем.
Несанкционированные сетевые запросы: Вредоносный код может инициировать запросы от имени пользователя (CSRF-атаки) или использовать ресурсы браузера для скрытой активности, например, рассылки спама через открытые API.
Как это работает на практике:
Сервер передает заголовок Content-Security-Policy: script-src 'self' https://trusted.com. После этого браузер заблокирует выполнение любого скрипта, который:
- Расположен на другом домене.
- Написан непосредственно внутри HTML-тега <script> (inline).
- Вызывается через eval() или обработчики событий вроде onclick.
В итоге CSP является критическим эшелоном защиты. Он не заменяет фильтрацию ввода, но предотвращает исполнение кода, если уязвимость все же была найдена и использована.
Вопрос к аудитории: кто из вас реально настраивал CSP в режиме report-only, прежде чем включать блокировку? Насколько много легаси-скриптов отвалилось при первой попытке внедрения?
Content Security Policy (CSP) - это HTTP-заголовок ответа, который позволяет администраторам сайта четко ограничить ресурсы (скрипты, стили, изображения), разрешенные для загрузки и исполнения в браузере пользователя.
По умолчанию браузеры доверяют любому коду, который загружается с текущего домена (Same-Origin Policy). Это создает условия для успешных XSS-атак: если злоумышленник внедрит свой JS-код в базу данных или через параметры запроса, браузер исполнит его как доверенный.
Риски при отсутствии CSP:
Эксплуатация XSS (Cross-Site Scripting): Атакующий внедряет скрипт, который считывает данные из форм ввода (логины, пароли, данные карт) или крадет сессионные куки (document.cookie), передавая их на сторонний сервер.
Инъекция стороннего контента: Без ограничений по источникам злоумышленник может подменить легитимные скрипты на свои или добавить на страницу сторонние фреймы (iframe), имитирующие интерфейс платежных систем.
Несанкционированные сетевые запросы: Вредоносный код может инициировать запросы от имени пользователя (CSRF-атаки) или использовать ресурсы браузера для скрытой активности, например, рассылки спама через открытые API.
Как это работает на практике:
Сервер передает заголовок Content-Security-Policy: script-src 'self' https://trusted.com. После этого браузер заблокирует выполнение любого скрипта, который:
- Расположен на другом домене.
- Написан непосредственно внутри HTML-тега <script> (inline).
- Вызывается через eval() или обработчики событий вроде onclick.
В итоге CSP является критическим эшелоном защиты. Он не заменяет фильтрацию ввода, но предотвращает исполнение кода, если уязвимость все же была найдена и использована.
Вопрос к аудитории: кто из вас реально настраивал CSP в режиме report-only, прежде чем включать блокировку? Насколько много легаси-скриптов отвалилось при первой попытке внедрения?
🔥4❤3🙏1
🍪 Что такое cookies и сессии? И как это использовать пентестеру..
Когда вы заходите на сайт и вводите логин и пароль — сервер должен как-то запомнить, что это именно вы.
Но HTTP — статeless протокол.
Каждый запрос для сервера выглядит как новый.
Поэтому используются cookies и сессии.
Давайте разбираться как работает авторизация по шагам:
1️⃣ Пользователь вводит логин и пароль
2️⃣ Сервер проверяет данные
3️⃣ Сервер создаёт сессию пользователя
4️⃣ Пользователю отправляется cookie с идентификатором этой сессии
✏️Пример заголовка:
Теперь браузер будет автоматически отправлять этот cookie при каждом запросе.
✅ Как выглядит запрос после авторизации
Сервер видит sessionid и понимает:
🍪 Что такое cookie?
Cookie — это маленький кусок данных, который сайт сохраняет в браузере.
Он может хранить:
— session ID
— настройки сайта
— язык
— токены авторизации
— tracking данные
Cookie автоматически отправляются браузером при каждом запросе к сайту.
🧾 Что такое сессия
Сессия — это запись на стороне сервера.
Она хранит информацию о пользователе:
— user_id
— права доступа
— время входа
— токен
Cookie просто хранит ID этой сессии.
⚠️Что из этого будет полезно знать нам, как пентестерам?
Хештеги: #web #owasp
Когда вы заходите на сайт и вводите логин и пароль — сервер должен как-то запомнить, что это именно вы.
Но HTTP — статeless протокол.
Каждый запрос для сервера выглядит как новый.
Поэтому используются cookies и сессии.
Давайте разбираться как работает авторизация по шагам:
1️⃣ Пользователь вводит логин и пароль
2️⃣ Сервер проверяет данные
3️⃣ Сервер создаёт сессию пользователя
4️⃣ Пользователю отправляется cookie с идентификатором этой сессии
✏️Пример заголовка:
Set-Cookie: sessionid=ab34f9d91a0f2; HttpOnly; Secure
Теперь браузер будет автоматически отправлять этот cookie при каждом запросе.
✅ Как выглядит запрос после авторизации
GET /profile HTTP/1.1
Host: site.com
Cookie: sessionid=ab34f9d91a0f2
Сервер видит sessionid и понимает:
этот пользователь уже авторизован.
🍪 Что такое cookie?
Cookie — это маленький кусок данных, который сайт сохраняет в браузере.
Он может хранить:
— session ID
— настройки сайта
— язык
— токены авторизации
— tracking данные
Cookie автоматически отправляются браузером при каждом запросе к сайту.
🧾 Что такое сессия
Сессия — это запись на стороне сервера.
Она хранит информацию о пользователе:
— user_id
— права доступа
— время входа
— токен
Cookie просто хранит ID этой сессии.
⚠️Что из этого будет полезно знать нам, как пентестерам?
Если у нас будет cookie сессии, то мы сможем входит в аккаунт без пароля🎉
Хештеги: #web #owasp
🔥7👌7🙏1
Есть тут у меня ребята, кто хотел бы поучаствовать в поиске клиентов(компаний) на пентест (тестирование на проникновение)?
У меня есть классные ребята, кто занимается профессионально пентестом.
У них и у меня есть огромное желание развиваться в этой отрасли в плане выхода на компании.
Начать можно с небольшого аудита.
Так как мы только начинаем, мы достаточно гибкие.
Готовы отдавать процент от продажи с клиента (об этом договоримся, созвонимся).
У меня тут много айтишников, да почти все, может у вас есть какие-то контакты, связи, кому нужно тестировать безопасность, готов посотрудничать.
Желательно клиентов из Европы, но можно рассмотреть и другие варианты.
Мой телеграм @faroeman
У меня есть классные ребята, кто занимается профессионально пентестом.
У них и у меня есть огромное желание развиваться в этой отрасли в плане выхода на компании.
Начать можно с небольшого аудита.
Так как мы только начинаем, мы достаточно гибкие.
Готовы отдавать процент от продажи с клиента (об этом договоримся, созвонимся).
У меня тут много айтишников, да почти все, может у вас есть какие-то контакты, связи, кому нужно тестировать безопасность, готов посотрудничать.
Желательно клиентов из Европы, но можно рассмотреть и другие варианты.
Мой телеграм @faroeman
❤3🙏1
🧠 Викторина | Web Security
Надеюсь, вы уже ознакомились с прошлым постом, где мы простыми словами разобрали, что такое cookies и сессии.
Это важная тема, потому что если злоумышленник получает cookie сессии, он фактически получает доступ к аккаунту пользователя и может действовать от его имени.
Поэтому для пентестера проверка подобных атак обязательно должна быть в чек-листе тестирования.
✏️Представим ситуацию.
Пользователь авторизовался на сайте.
В браузере хранится cookie сессии:
Злоумышленник каким-то образом получил этот cookie
(например через XSS).Как дополнили в комментариях😉
Теперь он отправляет запрос:
❓❓Как называется такая атака? Разбор - завтра!
A) CSRF
B) Session Fixation
C) Session Hijacking
D) Clickjacking
Хештеги: #practice #ctf
Надеюсь, вы уже ознакомились с прошлым постом, где мы простыми словами разобрали, что такое cookies и сессии.
Это важная тема, потому что если злоумышленник получает cookie сессии, он фактически получает доступ к аккаунту пользователя и может действовать от его имени.
Поэтому для пентестера проверка подобных атак обязательно должна быть в чек-листе тестирования.
✏️Представим ситуацию.
Пользователь авторизовался на сайте.
В браузере хранится cookie сессии:
sessionid=ab34f9d91a0f2
Злоумышленник каким-то образом получил этот cookie
(например через XSS).
Теперь он отправляет запрос:
GET /profile HTTP/1.1
Host: site.com
Cookie: sessionid=ab34f9d91a0f2
❓❓Как называется такая атака? Разбор - завтра!
A) CSRF
B) Session Fixation
C) Session Hijacking
D) Clickjacking
Хештеги: #practice #ctf
🔥3🙏2❤1
🔍 Разбор викторины
Правильный ответ:C — Session Hijacking
Все варианты, которые были озвучены в комментариях оказались верными!🎉🎉Значит, мы здесь собрались не только для того, чтобы мемасики пошарить. 😁
При этом:
— пароль знать не нужно
— логин тоже не нужен
Достаточно только валидного session cookie.
👍 Отмечайся реакцией, если ответил так же.
Правильный ответ:
Все варианты, которые были озвучены в комментариях оказались верными!🎉🎉
Session Hijacking — это атака, при которой злоумышленник получает
cookie сессии пользователя и использует её для доступа к аккаунту.
При этом:
— пароль знать не нужно
— логин тоже не нужен
Достаточно только валидного session cookie.
👍 Отмечайся реакцией, если ответил так же.
👌7🙏1
⚠️ Проблемы после обновления Windows 11
Пользователи начали массово сообщать о сбоях после установки обязательного обновления Windows 11 KB5079473.
По данным пользователей и обсуждений на Reddit, после установки апдейта возникают следующие проблемы:
— невозможность установить обновление
— зависания системы
— BSOD (синий экран смерти)
— циклические перезагрузки
— сбои графического интерфейса
Некоторые пользователи отмечают, что временно помогает только перезагрузка компьютера.
При этом в официальной статье поддержки Microsoft пока заявляет, что ей неизвестно о каких-либо проблемах с этим обновлением.
Вероятно, список известных багов появится позже — с момента выхода апдейта прошло меньше недели.
Также ранее разработчики уже подтверждали, что февральское обновление KB5077181 может вызывать ошибку доступа к диску C.
Я надеюсь из вас никто еще не успел обновиться?)😃
#news
Пользователи начали массово сообщать о сбоях после установки обязательного обновления Windows 11 KB5079473.
По данным пользователей и обсуждений на Reddit, после установки апдейта возникают следующие проблемы:
— невозможность установить обновление
— зависания системы
— BSOD (синий экран смерти)
— циклические перезагрузки
— сбои графического интерфейса
Некоторые пользователи отмечают, что временно помогает только перезагрузка компьютера.
При этом в официальной статье поддержки Microsoft пока заявляет, что ей неизвестно о каких-либо проблемах с этим обновлением.
Вероятно, список известных багов появится позже — с момента выхода апдейта прошло меньше недели.
Также ранее разработчики уже подтверждали, что февральское обновление KB5077181 может вызывать ошибку доступа к диску C.
Я надеюсь из вас никто еще не успел обновиться?)😃
#news
🙈12😁2
Мы с вами живём в интересное время…
Помню, когда еще в 2019 году я начинал вникать в разработку, началась корона и с работой на удаленке стало все очень сложно...а потом и в целом с айтишкой все печально🙈
Сейчас ситуация немного другая.
Когда почти всё завязано на ИБ,
нам начинают постепенно ограничивать доступ к источникам знаний:
— Telegram
— YouTube
— разные сервисы
Уже даже есть философы, которые полностью хотят обрубить интернет🤔
Иногда создаётся ощущение,
что нас постоянно кто-то проверяет
и вместе с нами ищет дно.
Подскажите, как у вас сейчас обстоят дела
с доступом к Telegram?
Есть ли проблемы, ограничения, перебои?
Или всё работает стабильно?
Если честно, у меня особых проблем нет,
и даже наоборот — активность в сообществе растёт.
Но мысль всё равно не отпускает:
🤔 Стоит ли уже думать о “запасном аэродроме”?
Или пока рано паниковать?
👌 — всё ок, продолжаем в Telegram, я с вами
👎 — пора подумать о запасной платформе
Помню, когда еще в 2019 году я начинал вникать в разработку, началась корона и с работой на удаленке стало все очень сложно...а потом и в целом с айтишкой все печально🙈
Сейчас ситуация немного другая.
Когда почти всё завязано на ИБ,
нам начинают постепенно ограничивать доступ к источникам знаний:
— Telegram
— YouTube
— разные сервисы
Иногда создаётся ощущение,
что нас постоянно кто-то проверяет
и вместе с нами ищет дно.
Подскажите, как у вас сейчас обстоят дела
с доступом к Telegram?
Есть ли проблемы, ограничения, перебои?
Или всё работает стабильно?
Если честно, у меня особых проблем нет,
и даже наоборот — активность в сообществе растёт.
Но мысль всё равно не отпускает:
🤔 Стоит ли уже думать о “запасном аэродроме”?
Или пока рано паниковать?
👌 — всё ок, продолжаем в Telegram, я с вами
👎 — пора подумать о запасной платформе
👌52👎14❤1
🔐 Кибербезопасность без воды — практика пентеста и подходы из red team.
Здесь ты не просто читаешь — ты начинаешь думать как пентестер.
📚 Что есть на канале:
— простое объяснение сложных тем (XSS, IDOR, CSRF, AD)
— реальные кейсы из bug bounty
— чек-листы и практические разборы
— викторины и задачи для прокачки мышления
— вакансии
— чат пентестеров
🧠 Формируем не просто знания, а подход к пентесту
Подойдёт если ты:
— только начинаешь
— уже в теме и хочешь системности
— интересуешься кибербезопасностью
👉 Подписывайся и прокачивайся вместе с нами
Здесь ты не просто читаешь — ты начинаешь думать как пентестер.
📚 Что есть на канале:
— простое объяснение сложных тем (XSS, IDOR, CSRF, AD)
— реальные кейсы из bug bounty
— чек-листы и практические разборы
— викторины и задачи для прокачки мышления
— вакансии
— чат пентестеров
🧠 Формируем не просто знания, а подход к пентесту
Подойдёт если ты:
— только начинаешь
— уже в теме и хочешь системности
— интересуешься кибербезопасностью
👉 Подписывайся и прокачивайся вместе с нами
👍8🔥4👌2❤1
🔓 Что такое IDOR (Insecure Direct Object Reference)
Мы уже много раз упоминали IDOR в постах и разборах,
но полного объяснения этой уязвимости в нашей базе знаний пока не было. Исправляем!😄
IDOR — это уязвимость контроля доступа, при которой пользователь может получить доступ к чужим данным, просто изменив идентификатор объекта.
Проще говоря:
🔎 Как это выглядит на практике
Представим URL:
Сервер показывает профиль пользователя 1001.
Но если изменить ID:
и сервер всё равно возвращает данные —
значит присутствует IDOR.
Потому что приложение не проверяет:
👉 принадлежит ли этот профиль текущему пользователю.
🧠 Такая уязвимость часто появляется в:
— профилях пользователей
— заказах
— документах
— сообщениях
— API запросах
🧪 Как пентестеры ищут IDOR
Обычно проверяют:
— параметры id
— user_id
— account_id
— order_id
— document_id
Просто меняют значение и смотрят:
👉 изменится ли ответ сервера.
Хештеги: #web #owasp
но полного объяснения этой уязвимости в нашей
IDOR — это уязвимость контроля доступа, при которой пользователь может получить доступ к чужим данным, просто изменив идентификатор объекта.
Проще говоря:
приложение использует ID объекта, но не проверяет, имеет ли пользователь право к нему обращаться.
🔎 Как это выглядит на практике
Представим URL:
https://site.com/profile?id=1001
Сервер показывает профиль пользователя 1001.
Но если изменить ID:
https://site.com/profile?id=1002
и сервер всё равно возвращает данные —
значит присутствует IDOR.
Потому что приложение не проверяет:
👉 принадлежит ли этот профиль текущему пользователю.
🧠 Такая уязвимость часто появляется в:
— профилях пользователей
— заказах
— документах
— сообщениях
— API запросах
🧪 Как пентестеры ищут IDOR
Обычно проверяют:
— параметры id
— user_id
— account_id
— order_id
— document_id
Просто меняют значение и смотрят:
👉 изменится ли ответ сервера.
Хештеги: #web #owasp
👍13❤3🔥1
На прошлой неделе принимал участие в bug bounty по одному из сервисов российского региона.
И, как оказалось, далеко ходить не пришлось 🙂
Одной из первых вещей, которые мы начали проверять — наличие IDOR.
И тут обнаружилась довольно интересная ситуация.
На сайте была найдена уязвимость, которая позволяла скачивать платные архивные документы бесплатно и без регистрации.
Фактически IDOR полностью обходил механизм оплаты.
То есть достаточно было изменить идентификатор запроса — и можно было получать доступ к документам, которые должны были быть доступны только после покупки.
За данный IDOR мы получили награду в размере 15 000 ₽. Еще правда не зачислили, но пообещали, что процедура много времени не займет.Если кому интересно, подкиньте реакций, чуть позже опубликую отчет (частичный).
Не могу сказать, что это какие-то огромные деньги…
но, согласитесь, всё равно приятно 🙂
💬 Кстати, интересно узнать:
— Кто из вас уже участвует в bug bounty программах?
— Какие выплаты вам удавалось получать?
— Есть ли желание объединяться в небольшие команды для поиска багов?
И, как оказалось, далеко ходить не пришлось 🙂
Одной из первых вещей, которые мы начали проверять — наличие IDOR.
И тут обнаружилась довольно интересная ситуация.
На сайте была найдена уязвимость, которая позволяла скачивать платные архивные документы бесплатно и без регистрации.
Фактически IDOR полностью обходил механизм оплаты.
То есть достаточно было изменить идентификатор запроса — и можно было получать доступ к документам, которые должны были быть доступны только после покупки.
За данный IDOR мы получили награду в размере 15 000 ₽. Еще правда не зачислили, но пообещали, что процедура много времени не займет.
Не могу сказать, что это какие-то огромные деньги…
но, согласитесь, всё равно приятно 🙂
💬 Кстати, интересно узнать:
— Кто из вас уже участвует в bug bounty программах?
— Какие выплаты вам удавалось получать?
— Есть ли желание объединяться в небольшие команды для поиска багов?
1👏29🔥11👍2🙏2😁1