В "Attack scenario" ничего не сказано про Access-Control-Allow-Credentials, а это самый важный момент.
Наглядный пример совершенно не в тему и больше относится к DOM Based XSS.
веб-приложение, с неверно настроенной политикой Access-Control-Allow-Origin
При этом в примере заголовок вообще используется только на сайте злоумышленника.
Упомянутый репорт Twitter'у был отправлен за месяц до того, как они сделали денежные вознаграждения. Подробнее можно про него тут прочитать https://habrahabr.ru/post/272187/
Тут скорее проблема в том, что популярные компании с bugbounty и большим скоупом получают невероятное количество репортов (большинство из которых не очень)… И, насколько я понимаю, их начальной обработкой часто занимаются не технические специалисты.
HTTP-ответ с возможностью сделать CRLF Injection отдавал backend. В случае некорректного ответа frontend отдавал соответствующую ошибку. Но что конкретно было причиной возникновения уязвимости, я не знаю.
Оценили по достоинству. Как можно заметить из других публикаций, Facebook всегда хорошо оценивает уязвимости, которые получились действительно интересными.
В "Attack scenario" ничего не сказано про Access-Control-Allow-Credentials, а это самый важный момент.
Наглядный пример совершенно не в тему и больше относится к DOM Based XSS.
При этом в примере заголовок вообще используется только на сайте злоумышленника.
Мое решение выглядело примерно так:
Sigizmund'=password like _utf8mb4'14eb6641da38addf61%'#Если в выборке возвращается Sigizmund — true.
https://tools.ietf.org/html/rfc3986#section-4.2