Кавычка. Страница 4

Как сообщает @x_notes, у древнейшего ресурса по реверс инжинирингу - exelab.ru, ус отклеился (PHP интерпретатор отломился).

А где-то можно не подтверждать email.
Например, популярный ныне сервис Discord. В нем ты можешь завести аккаунт на произвольный email (например [email protected]), и не подтверждая email зайти через него на один из сайтов, если веб-приложение будет ему доверять.

Многие знают про различные фичи oauth, благодаря которым уязвимости появляются из-за излишнего доверия к провайдерам. Например, регистрация в одной из соцсетей с полезной нагрузкой ('-alert()-' в качестве имени), когда как при обычной регистрации спецсимволы использовать запрещено.

Некоторые сервисы позволяют не подтверждать, например, номер телефона. А в момент регистрации через кнопку “Войти через…” - веб приложение забирает поля пользователя, в том числе и телефон, хоть пользователь не подтвердил его. Войдя через такой аккаунт есть вероятность попасть к одному из клиентов веб-приложения, того самого, чей номер был введен.

На случай важных переговоров

#JWT

Какой тип содержимого будет, если веб-приложение ответит следующим заголовком?

Content-Type: text/plain, xml, text/html, json

Оказывается - html! Некоторые браузеры парсят content-type через запятую и берут последний валидный вариант.

Этот и другие трюки с различными типами контента можно глянуть тут.

Один из классических вопросов на собеседование AppSec специалисту - "Как хранить пароли?". И тут будет потрясающим ответ - "пароли хранить не надо, потому что в 2020 мы не должны запускать сервисы с паролями!". За это можно получить хороший плюс. Но если все-таки вернуться к вопросу, то ожидается ответ в духе:
- Давайте использовать Argon2, PBKDF2, Bcrypt, Scrypt с оптимальным количеством раундов
- И харденинг - например использовать HSM (тут долгие холивары в каком режиме), "pepper" и т.д.

Ответы хранить соленный md5/sha1/sha256/sha512 автоматически ставят жирный минус.

Но также есть еще один вопрос, сложный, и ответ на него мало кто знает - *”А как нам хранить пароли так, что если атакующий получит RCE на бэкендах, в т.ч. root привилегии, то не сможет дампнуть табличку с хэшами?”*

Вопрос ставит в тупик, можно начинать придумывать "security through obscurity" решения, но не надо. Есть очень легкий, понятный и технически верный путь, как решить поставленную задачу. Нам нужно отозвать права "select" у бэкенд юзера на таблицу с хэшами и написать 2 хранимых SQL процедуры:

getSalt(user_id)

Вернет «соль» пароля на бэкенд по userId, который пытается войти. Бэкенд возьмет введенный юзером пароль и получит хэш с солью из базы

checkPassword(user_id, hashed_password)

Возвращает true/false на проверке хэша пароля на предыдущем шаге у user_id

Еще нужна процедура на создание пользователя и смену пароля, но они также не позволяет select'нуть хэши паролей пользователей. Хорошая статья по теме(но там не всё): https://www.secjuice.com/secure-password-handling/

Странно, что ни в одном современном решении - типа WordPress или Django это не реализовано. Да и не надо уже, давайте лучше откажемся от паролей!

Смотри. Иногда есть <input>, но нельзя закрыть тег, как сделать срабатывание javascript без пользовательского действия?

Вот тебе пример.

Самый частый вариант - связка события onfocus и autofocus рушится, если autofocus стоит в другом месте. А всякие onmouseover, не подойдут, потому что нужно, чтобы пользователь задел курсором уязвимое поле.






...







На самом деле можно поместить в ссылку якорь (не говори эти слова в общественных местах, а то подумают, что с тобой что-то не так).
Якорем называется закладка с уникальным именем на определенном месте веб-страницы, предназначенная для создания перехода к ней по ссылке. Якоря удобно применять в документах большого объема, чтобы можно было быстро переходить к нужному разделу. Например, после перехода по ссылке и загрузки страницы https://en.wikipedia.org/wiki/Wikipedia#Privacy, браузер перейдет к заголовку "Privacy".

Для создания якоря необходимо поместить в URL символ решетки, а за ним значение уникального идентификатора, который задается в атрибуте id. В wikipedia это был <span class="mw-headline" id="Privacy">Privacy</span>.

Сослаться можно и на другие html теги, браузер будет сфокусирован на них.

А теперь попробуй в первой ссылке вызвать alert при открытии! Но если надо, то решение тут.

При сканировании сети доступен порт tcp/2181? Скорее всего это ZooKeeper - распределенное иерархическое key-value хранилище. Он часто используется для отказоустойчивого хранения конфигураций и сериализованых объектов. Пример эксплуатации уязвимости в ClickHouse через ZooKeeper.

В те времена, когда трава была зеленее, солнце светило ярче, самым крутым браузером был Netscape, а сайты верстали таблицами - не было CORS. Тем более таких штук как postMessage.
Но была крутая фича - имя текущего окна.

window.name - переменная, в которую можно записать данные на одном сайте, а прочитать уже на другом. Поэтому, во времена frameset, олдфаги использовали имя окна для полноценного междоменного взаимодействия. Сейчас это, конечно же, легаси.

Но переменная name все еще доступна! Использование её в рамках одной вкладки позволяет передавать большое количество данных, тем самым минимизируя вектор атаки. А еще на сервере не залогируется, что именно ты выполнил (тоже забавно).
Особенно это полезно в случае CSRF + Reflected XSS, когда ты можешь определить name до того, как отправишь жертву на уязвимую ссылку прямо на странице с формой.

Ведь для полноценного выполнения полезной нагрузки достаточно вызвать eval(name) (10 байт), а для подключения внешнего скрипта в Chrome import(name) (12 байт).

Вот примерчик.

Ставим name с alert'ом на одном домене, а выполняем его на другом.

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

Например, для PoC подойдет переопределение функции toString, а потом её неявный вызов:

toString=alert;window+1

Или интереснее - переопределить ошибку.

onerror=eval;Uncaught=alert;throw'\x28location\x29';

Тут мы определили Uncaught как имя функции, в throw его содержимое (в том числе вызов), onerror можно переопределить в eval, а лучше в setTimeout, дабы всякие WAF'ы не ругались (пример).

А тут еще больше примеров в репозитории XSS-Payloads (самый классный все равно innerHTML)

Websocket - это протокол.
Да, он сделан специально для браузера и работает поверх него, но является всего лишь транспортом для обмена данных, а в браузере для него нет каких-то механизмов безопасности, типа CORS.

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

Если веб-сервер ответил и создал подключение, то подключение произойдет, несмотря на различные заголовки, которые разработчик может попытаться вернуть в ответе, типа X-Frame-Options, Access-Control-Allow-Origin и вот это всё.

Поэтому, подключать пользователя или нет, решает бэкэнд. Именно он должен определить, является ли пользователь и источник подключения легитимным. Обычно проверяют заголовок Origin или используют различные секреты (типа CSRF токена). Иногда это уже реализовано в библиотеках, но далеко не во всех. Еще забавно, что куки могут быть удалены, сессионный идентификатор может уже давно умереть, а подключение к вебсокету все еще работать.

Нет идей, какие уязвимости могут быть в приложении написанном на Golang?
Стоит прочитать пост с примером эксплуатации Request Splitting.

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

Раз сервер настроен так хреново, что читается .env, значит и с высокой вероятностью доступна директория /storage/framework/sessions/


Берешь функцию генерации сессии
@
Находишь самый жирный айдишник из директории
@
Вставляешь секретный токен из .env
@
Генеришь себе cookie администратора

Пример прилагается

SVG - забавная штука. Это формат графики, который представлен в виде XML файла. Поэтому в нем уже делали всякие атаки, типа XXE. С помощью него выполняются XSS атаки при открытии изображения в браузере. Но еще, он странно ведет себя как тег в html страницах.

Совсем недавно, Safari выполнял событие onload в любом элементе, которое находится в теге svg.

<svg><hello onload=alert(1337)>

А Firefox умеет выполнять тег <script>, даже если он не закрытый.

<svg><script href=data:,alert(1) />

На самом деле, при построении DOM-дерева он автоматически закрывает SVG, а для того, чтобы это был корректный XML - все теги внутри него (а еще, ты можешь заметить href, вместо src). Но это можно использовать для обхода некоторых видов защит.

А раз уж мы пошли по статьям, недавняя RCE в ClickHouse

В Gitlab недавно нашли способ чтения произвольных файлов, как следствие, это может привести к выполнению произвольного кода. Забавно, что репорт открыли достаточно быстро, еще не все успели обновиться.
Из привелегий - нужно иметь учетку (ну или открытую регистрацию), так что если у вас есть корпоративный gitlab, вы знаете, что делать.

Bitrix - популярная CMS для стран СНГ. Там есть достаточно неплохая встроенная защита, которую всё-таки можно обойти.
Обойти XSS WAF можно через нульбайт, в блоге deteact есть описание, почему это происходит.
А еще там есть смешная обходка для Open Redirect - некорректный парсинг урла, который проверяет вхождение домена в начале строки, который можно откинуть в basic auth.

1) Год назад в багбаунти программу mailru заслали баг на 10 тысяч $, из публичного описания было понятно лишь то, что ликается какая-то рандомная память https://twitter.com/disclosedh1/status/1189553870801907713
2) Полгода назад samwcyo публикует статью, как ему заплатили 40 тысяч $ за похожую багу https://samcurry.net/filling-in-the-blanks-exploiting-null-byte-buffer-overflow-for-a-40000-bounty/. Т.е. где-то что-то подставил, а в ответ рандомные куски памяти. В 2019 то году!

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

3) И вот вчера появились детали из-за чего был баг #1 и, возможно, баг #2. Причина - неожиданное поведение openResty, при помощи которого можно писать скрипты на Lua в Nginx. Ожидается, что Lua в данном случае - это memory-safe язык, и подобные уязвимости ему не грозят. Но это оказалось не так и из-за этого была уязвимость. Также по ходу расследования оказалось что и "чистый" Nginx к этому уязвим, но Nginx - запатчились, а openResty - нет. Детали теперь в описании https://hackerone.com/reports/513236

Представьте себе, это как на PHP бы функция header() при подстановке %00 начала бы отдавать в ответе случайную память на сервере.