Comments 32
Если не брать в расчёт шрифты, то можно комбинировать как префиксный селектор, так и постфиксный + селектор подстроки.
В итоге 1 млрд лет превратился в 20 секунд. Конечно, тут зависит от мощности сервера, лимитов на перебов, капчи и пр., но уменьшение стойкости пароля всё-равно очень серьёзное.
9-символьный пароль сократится с 999 лет (630 квадриллионов вариантов) до 3 мс (59 тыс вариантов).
PS. В расчётах принималось, что сервера сайта могут выдержать 20 млн запросов в секунду (конечно, большинство сайтов столько не выдержат). Трафик примерно от 10 Гбит/с и более.
- Возьмём 12-символьный рандомный пароль по 95-символьному словарю. Его перебор занимает где-то 1 млрд лет (540 секстиллионов вариантов).
- Далее селекторами наличия подстроки (*=) уменьшим размер словаря до 12 символов. Время перебора сократилось до 5 дней (10 трлн вариантов). Мы добавили 95 правил.
- Далее префиксными селекторами узнаём первые 2 символа. Таким образом длина пароля уменьшается на 2 символа, и перебор занимает от 1 часа (62 млрд вариантов). Добавилось +9025 правил.
- Далее постфиксными селекторами узнаём последние 2 символа. Пароль уменьшается ещё на 2 символа, и перебор занимает от 20 секунд (430 млн вариантов). Добавилось +9025 правил, суммарно 18145 правил.
В итоге 1 млрд лет превратился в 20 секунд. Конечно, тут зависит от мощности сервера, лимитов на перебов, капчи и пр., но уменьшение стойкости пароля всё-равно очень серьёзное.
9-символьный пароль сократится с 999 лет (630 квадриллионов вариантов) до 3 мс (59 тыс вариантов).
PS. В расчётах принималось, что сервера сайта могут выдержать 20 млн запросов в секунду (конечно, большинство сайтов столько не выдержат). Трафик примерно от 10 Гбит/с и более.
На счет постфиксного селектора — хорошая идея. Мы можем собирать постфиксным селектором не пароли а именно логины, в качестве которых часто выступают номера телефонов. Бывает так, что номер телефона заранее установлен в поле для ввода, и остается ввести пароль.
В этом случае, постфиксным селектором мы соберем отличную базу номеров.
В этом случае, постфиксным селектором мы соберем отличную базу номеров.
А в курсе ли разработчики CSS таких дыр? И не прикроют ли они в будущем возможность отправлять запросы через url() на удалённые сервера?
Понятно, что это урежет гибкость, но не пожертвуют ли они ей ради безопасности?
Понятно, что это урежет гибкость, но не пожертвуют ли они ей ради безопасности?
Так необязательно же грузить content: url(), можно и backgroung-image: url() и многое другое. Или Вы предлагаете все картинки в html-коде прописывать?
Даже если бы мы всё убрали, ну всё-равно значит можно прописать в html-коде, а потом просто скрыть/открыть элемент с помощью css. Да и какой смысл убирать? Всё то же самое можно сделать и скриптами. Разве что когда кто-то грузит чужой css, но много ли кто так делает?
Даже если бы мы всё убрали, ну всё-равно значит можно прописать в html-коде, а потом просто скрыть/открыть элемент с помощью css. Да и какой смысл убирать? Всё то же самое можно сделать и скриптами. Разве что когда кто-то грузит чужой css, но много ли кто так делает?
Я не имел ввиду вообще запретить url(). Я имел ввиду запретить url() отправлять запросы на удалённые сервера. А запрос на свой же сервер (на котором лежит сам css-файл) оставить. Хотя, действительно, смысл не велик. Если всё тоже самое можно сделать из html, но думаю, ответственных за css, проблемы html не особо волнуют.
Тут скорее логично более агрессивное кэширование сделать. И это будут делать не разработчики CSS, а разработчики браузеров (как закрывали ранее дырки с посещенными ссылками, например)
url не запретят т.к. слишком много сайтов сломается единовременно из-за этого. Да и не логично.
url не запретят т.к. слишком много сайтов сломается единовременно из-за этого. Да и не логично.
форма (с уже заполненными полями) но с списком необходимых исправлений. В таком случае наш метод отработает на 100%.
Поле с паролем обычно принято не заполнять (но такая вероятность все равно остается).
Простите если я чего то не понял, но…
А каким образом код на загрузку такого css будет вставлен в страницу? Если на серверной стороне — то зачем мне морочить голову с таким кейлогером, когда я могу реализовать его гораздо эффективнее на серверной стороне. Если на стороне клиента, то есть есть xss и она работает — то опять нет смысла морочить себе голову с кейлогером на css — эффективнее будет тот же на js.
Единственный сценарий использования это когда разработчик сам вставил ссылку на ваш внешний css к себя на страницу, но это уже очень специфический вектор атаки.
А каким образом код на загрузку такого css будет вставлен в страницу? Если на серверной стороне — то зачем мне морочить голову с таким кейлогером, когда я могу реализовать его гораздо эффективнее на серверной стороне. Если на стороне клиента, то есть есть xss и она работает — то опять нет смысла морочить себе голову с кейлогером на css — эффективнее будет тот же на js.
Единственный сценарий использования это когда разработчик сам вставил ссылку на ваш внешний css к себя на страницу, но это уже очень специфический вектор атаки.
Вы все правильно поняли, это тот самый случай когда на странице-жертве подключен внешний CSS. Или не внешний, а просто есть возможность внедрить стили на страницу-жертву.
XSS предполагает именно скриптинг. Простейшая защита может тупо вырезать теги скрипт, обжект и т. п., оставляя безобидный стайл для оформления.
а точно input[value^=«login»]?
почему не по имени поля?
почему не по имени поля?
Зачем нам выбирать поля по имени? Смысл селектора собрать то, что находиться в атрибуте value — и отправить на внешний сервер с помощью инструкции url(). Посмотрите пример — jsfiddle.net/hcbogdan/1wdky4t6/1
Как долго я ждал выхода этой статьи!
Может, тогда уж сразу SVG через data: uri?
Исполняется, и есть доступ к элементам за пределами SVG
jsfiddle.net/Stalk/v4a7n92h (при вводе в input[type=password] его содержимое копируется в консоль)
jsfiddle.net/Stalk/v4a7n92h (при вводе в input[type=password] его содержимое копируется в консоль)
<?php
from string import Template
Просто python3
docs.python.org/3.1/library/string.html#string.Template
docs.python.org/3.1/library/string.html#string.Template
Вероятно, если файл шрифта не кешировать, то браузер будет постоянно брать файл шрифта на каждый запрос, но это нужно проверять.
Уже проверено. Можете взять приер тут jsfiddle.net/hcbogdan/tbg7wd4n
Кеширующие заголовки имеют влияние только при повторном вводе (в следующем сеансе).
Кеширующие заголовки имеют влияние только при повторном вводе (в следующем сеансе).
Во втором случае фиксируются только значащие символы, а BackSpace/Delete/Left/Right не выходят из тени.
Таким образом, получается, что старые способы запутывания кейлоггеров (ввел пару символов, один удалил, ввел еще три, перевел курсор на вторую позицию, ввел еще несколько) могут получить новое дыхание. Ненадолго ))
Таким образом, получается, что старые способы запутывания кейлоггеров (ввел пару символов, один удалил, ввел еще три, перевел курсор на вторую позицию, ввел еще несколько) могут получить новое дыхание. Ненадолго ))
Sign up to leave a comment.
Создаем CSS кейлоггер