в общем стоит рассмативать это как SSRF через client side - браузер жертвы

при чем не blind

А, вот в чем дело, я думал, что без credentials ответ вообще нельзя передавать, а тут еще это зависит от credentials mode, спасибо вообщем

пытался понять, но не понял. Как оно может быть через клайент сайд

ситуация выше - это по факту CORS * на уязвимом ресурсе, по импакту можно придумать 2 вектора атаки.
Допустим, у нас есть company.com -  уязвимый ресурс с CORS *, attacker.com - сайт со сплойтом, A - атакующий, V - жертва, которая работает в компании company.com

1) Допустим, что на company есть контент, к которому открыли доступ только с IP сотрудников, тогда A сможет сделать запрос на company.com/admin (условно) с attacker.com, когда V его посетит и A получит доступ к контенту или админке
2) Иногда в компаниях, условно company.com, при работе сотрудника из офиса, резолвится во что-то локальное на локальном DNS (или при работе через VPN). Если V будет в офисе или с VPN и зайдет на attacker.com, A сможет достучаться уже из локалки или из-под VPN до этого ресурса, с IP/браузера V.

По факту оба вектора - это “SSRF” через браузер V, что и задумывалось в CORS

но еще раз, если заранее неизвестно о существовании 1 или 2 условия и допущенного ACL по IP/маске или переопределения DNS то это честный N/A ) но, в теории, могло бы где-нить стрельнуть

1) Допустим, что на example.com есть контент, к которому открыли доступ только с IP сотрудников, тогда A сможет сделать запрос на company.com/admin (условно) с attacker.com, когда V его посетит и A получит доступ к контенту или админке

а, ну тогда я вроде правильно понял. Так выходит можно “ссрфить” через HTML иньекции в почте

по целям примерно можно глянуть как работает днс ребиндинг

рассылая их тем кто сидит внутри сети

1) Допустим, что на example.com есть контент, к которому открыли доступ только с IP сотрудников, тогда A сможет сделать запрос на company.com/admin (условно) с attacker.com, когда V его посетит и A получит доступ к контенту или админке

ну да, для этого в т.ч. пилят прокси в почте

точно, очень близко 🙂

ну либо не рассылая, а просто заманив на подконтрольный аттакеру сайт. Но в общем да, забавно, но я бы такое тоже закрыл как N/A

Я правильно понимаю, что если сессионные куки hostOnly, то нельзя сделать csrf? https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies/Cookie#Type

hostOnly
A boolean, true if the cookie is a host-only cookie (i.e. the request's host must exactly match the domain of the cookie), or false otherwise.

Просто никогда о них не слышал

Не совсем, это вроде про видимость куки для поддоменов

А как связан csrf и куки?

А как ты сделаешь csrf если куки не передаются?

А не передаются они ток в этом случае и то не вседа

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

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

toString=alert;window+1

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

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

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

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