Pull to refresh

Comments 32

Если не брать в расчёт шрифты, то можно комбинировать как префиксный селектор, так и постфиксный + селектор подстроки.

  1. Возьмём 12-символьный рандомный пароль по 95-символьному словарю. Его перебор занимает где-то 1 млрд лет (540 секстиллионов вариантов).
  2. Далее селекторами наличия подстроки (*=) уменьшим размер словаря до 12 символов. Время перебора сократилось до 5 дней (10 трлн вариантов). Мы добавили 95 правил.
  3. Далее префиксными селекторами узнаём первые 2 символа. Таким образом длина пароля уменьшается на 2 символа, и перебор занимает от 1 часа (62 млрд вариантов). Добавилось +9025 правил.
  4. Далее постфиксными селекторами узнаём последние 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, но много ли кто так делает?
Я не имел ввиду вообще запретить url(). Я имел ввиду запретить url() отправлять запросы на удалённые сервера. А запрос на свой же сервер (на котором лежит сам css-файл) оставить. Хотя, действительно, смысл не велик. Если всё тоже самое можно сделать из html, но думаю, ответственных за css, проблемы html не особо волнуют.
Тут скорее логично более агрессивное кэширование сделать. И это будут делать не разработчики CSS, а разработчики браузеров (как закрывали ранее дырки с посещенными ссылками, например)
url не запретят т.к. слишком много сайтов сломается единовременно из-за этого. Да и не логично.
форма (с уже заполненными полями) но с списком необходимых исправлений. В таком случае наш метод отработает на 100%.

Поле с паролем обычно принято не заполнять (но такая вероятность все равно остается).

Простите если я чего то не понял, но…

А каким образом код на загрузку такого css будет вставлен в страницу? Если на серверной стороне — то зачем мне морочить голову с таким кейлогером, когда я могу реализовать его гораздо эффективнее на серверной стороне. Если на стороне клиента, то есть есть xss и она работает — то опять нет смысла морочить себе голову с кейлогером на css — эффективнее будет тот же на js.

Единственный сценарий использования это когда разработчик сам вставил ссылку на ваш внешний css к себя на страницу, но это уже очень специфический вектор атаки.
Вы все правильно поняли, это тот самый случай когда на странице-жертве подключен внешний CSS. Или не внешний, а просто есть возможность внедрить стили на страницу-жертву.
XSS предполагает именно скриптинг. Простейшая защита может тупо вырезать теги скрипт, обжект и т. п., оставляя безобидный стайл для оформления.
Вот тут кроется рецепт (на будущее) защиты.
Если мы разрешаем внедрять HTML, запрещая некоторые правила по собственному словарю (например, запрещаем теги
Зачем нам выбирать поля по имени? Смысл селектора собрать то, что находиться в атрибуте value — и отправить на внешний сервер с помощью инструкции url(). Посмотрите пример — jsfiddle.net/hcbogdan/1wdky4t6/1
а… видимо немного невъехал в суть.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Исполняется, и есть доступ к элементам за пределами SVG
jsfiddle.net/Stalk/v4a7n92h (при вводе в input[type=password] его содержимое копируется в консоль)
Это в тэге svg исполняется. А вот через img — не должно.
Я понимаю, что Питон, но почему открывающий тег php-то? :)
Тут просто моя невнимательность. Спасибо за замечание — поправил.
Вероятно, если файл шрифта не кешировать, то браузер будет постоянно брать файл шрифта на каждый запрос, но это нужно проверять.
Уже проверено. Можете взять приер тут jsfiddle.net/hcbogdan/tbg7wd4n
Кеширующие заголовки имеют влияние только при повторном вводе (в следующем сеансе).
Получается, что кейлоггер срабатывает только на каждый новый символ, при повторном наборе, запроса не будет, даже если урл не кешируется на стороне сервера.
Как это обойти?
Можно установить по разному шрифту на каждый инпут, но не получится менять шрифт каждого символа, средствами CSS, для одного инпута.
Во втором случае фиксируются только значащие символы, а BackSpace/Delete/Left/Right не выходят из тени.
Таким образом, получается, что старые способы запутывания кейлоггеров (ввел пару символов, один удалил, ввел еще три, перевел курсор на вторую позицию, ввел еще несколько) могут получить новое дыхание. Ненадолго ))
Only those users with full accounts are able to leave comments. Log in, please.