Comments 65
Броузер просто не покажет картинку в данном случае. Никаких окон авторизации не будет.
А вы, я посмотрел, не одиноки в написании первого тега к топику.
Вы и в правду думаете что хабралюди будут вводить свой логин и пароль на фишинговом сайте?
а вы и вправду думаете что все заметят разницу в 1 букву, да еще не в адресной строке, а в форме авторизации.
К тому же человек просто зайдет на главную хабра например и врядли будет ожидать подвоха, а там надпись ДДосс фильтр, или что то в этом духе
К тому же человек просто зайдет на главную хабра например и врядли будет ожидать подвоха, а там надпись ДДосс фильтр, или что то в этом духе
Насчет Хабралюдей — он зря сказал. А в общем случае, нужно быть идиотом (или бабушкой), чтобы ввести свой логин и пароль в окно, которого на этом сайте явно никогда не было
Ок, не так выразился. Имелось ввиду, что вход на хабр — это всегда habrahabr.ru/login/
На фишинг в виде HTTP авторизации пользователи технологического сайта просто не поведутся. Если бы вы привели в качестве примера маскировку под эту самую формочку входа и уже с неё записывались вводимые логины и пароли, то я бы и слова вам не сказал. А сейчас…
На фишинг в виде HTTP авторизации пользователи технологического сайта просто не поведутся. Если бы вы привели в качестве примера маскировку под эту самую формочку входа и уже с неё записывались вводимые логины и пароли, то я бы и слова вам не сказал. А сейчас…
1. хабралюди святые и никогда не ведутся на простые уловки?
2. хабралюди все сплош веб-мастера?
3. веб-мастера пишут сайты только для хабралюдей?
Ничего личного, но все эти пафосные хабра-понты слегка поднадоели.
2. хабралюди все сплош веб-мастера?
3. веб-мастера пишут сайты только для хабралюдей?
Ничего личного, но все эти пафосные хабра-понты слегка поднадоели.
Если раскоментировать 3,4,5 строку php скрипта то скрипт будет выплёвывать 401 заголовок, а он свою очередь будет вызывать модальное окно авторизации
не верите? — проверьте!
не верите? — проверьте!
Если сильно захотеть, то можна вставлять ссылку на файл с расширением jpg, а уже на стороне сервера делать rewrite на .php и передавать парсеру.
как выяснилось, Opera, FF, IE выкидывают запрос авторизации.
В гугл хром, страница просто не грузится
В гугл хром, страница просто не грузится
Если так рассуждать, то нужно и переход по ссылкам запрещать. Вводить пароли в левых неожиданных запросах — самое глупое что можно сделать. Такое допущение в вашем механизме заражения не имеет права на жизнь. Это как открывать дверь не глядя в глазок в неблагополучном районе и винить в грабеже, например, застройщика. Если человек сам себе не враг, то у него должны быть инстинкты самосохранения, а если их нет, в игру вступает естественный отбор. И, возможно, это даже хорошо с точки зрения эволюции )
Ничего подобного. Я когда-то ради теста (именно так, ничего плохого) проверял на сайте одного киевского журнала, работает ли это. За день несколько писем падали в ящик (все новые пароли на почту слались)
Ну а итогом такой эволюции будет массовый исход пользователей и массовые вынос мозга владельцам ресурса.
Ладно вам про самосохранение, куча ресурсов тематических, для беременных мамаш, для автолюбителей, для черти-кого еще максимально далекого от понятий безопасности. Но вот эти черти-кто и приносят всю основную прибыль владельцам ресурсов. Поэтому как бы ни были глупы пользователи, вводящие свои пароли куда не попадя, со стороны бизнеса намного глупее давать им такую возможность.
Ладно вам про самосохранение, куча ресурсов тематических, для беременных мамаш, для автолюбителей, для черти-кого еще максимально далекого от понятий безопасности. Но вот эти черти-кто и приносят всю основную прибыль владельцам ресурсов. Поэтому как бы ни были глупы пользователи, вводящие свои пароли куда не попадя, со стороны бизнеса намного глупее давать им такую возможность.
Можно сделать изящнее. Вместо ссылки:
Делаем:
А в настройках веб-сервера прописываем, что в директории /imagez все файлы с раширением .jpg отдавать на обработку php. Тогда и при просмотре исходников никогда не поймете, что вам что-то нехорошее подсовывают.
exEmple.com/evilimage.phpДелаем:
exEmple.com/imagez/evilimage.jpgА в настройках веб-сервера прописываем, что в директории /imagez все файлы с раширением .jpg отдавать на обработку php. Тогда и при просмотре исходников никогда не поймете, что вам что-то нехорошее подсовывают.
в конце скрипта я в коде написал об этом
Хотя если честно — вставлять в статьи на своем сайте картинки и прочие объекты с других сайтов это не очень хорошая идея. Это называется хотлинкинг, а по сути дела воровство траффика. Во времена тощих каналов и платного траффика за это били канделябрами, т.к. хотлинк чужой картинки в статье на раскрученном сайте мог привести к очень не кислому счету для владельца сервера с которого собственно хотлинкнули картинку :(
Сейчас как правило картинки просто лежат на фотохостингах, а не просто левых сторонних сайтах.
А размещать в своей статье картинки с левых сайтов не очень логично: в любом момент картинка будет удалена и будут наблюдаться «битые» картинки.
А размещать в своей статье картинки с левых сайтов не очень логично: в любом момент картинка будет удалена и будут наблюдаться «битые» картинки.
Иногда вероятность получить битые картинки не так важна как забитость канала или счет за трафик. У нас одна контора в городе до сих пор серваки хостит на канале по 2 Мегабита per server — тут хочешь не хочешь, а попытаешься как-то от тяжелого контента избавиться.
boodda не могли бы модифицировать код таким образом что бы в «Basic realm=» автоматически определялась домен в котором отображается это окно авторизации? Т.е. в место «Vulnsite.com» было $sitename.
$vulnsite = parse_url($_SERVER['REFERER']);
а потом в коде ucfirst($vulnsite['host']);
думаю как то так, но это все таки простейший скрипт, напилить там много чего можно.
а потом в коде ucfirst($vulnsite['host']);
думаю как то так, но это все таки простейший скрипт, напилить там много чего можно.
Насколько знаю, негодяи еще и сохраняли cookies на стороне жертвы, а в скрипте проверяли наличие записи. Если запись есть, скрипт уже не срабатывал и зловещее окно авторизации выскакивало только один раз. Мне знакомый рассказывал.
Знакомый, ага :)
Муж сестры жены же рассказывал, а не просто какой-то там знакомый.
Друг подруги телки брата...
Простите, не удержался)
Простите, не удержался)
UFO just landed and posted this here
Habrahabr.ru тут не исключение у него на главной присутствуют посты, с картинками с других ресурсов. Так что просто стоит держать в уме этот трюк и всегда проверять до буквы имя домена требующего авторизацию.
На хабре картинки может постить далеко не каждый зарегистрированный пользователь. Это право надо «заслужить». А забанить аккаунт — 5 секунд.
Все таки фишинг это не сколько техническая уязвимость, сколько человеческий фактор. Невнимательность наказуема.
Года два назад этот метод был очень популярне на форуме 4game. Там можно было вставлять картинки с внешнего домена в сообщениях в личку.
Я вот тут подумал, почему бы на сайтах ссылки на картинки не преобразовывать с указанием имени и пароля?
То есть example.org/evilpict.jpg → user:pass@example.org/evilpict.jpg
Тогда при запросе авторизации, злому скрипту уйдёт бесполезные «user» и «pass».
То есть example.org/evilpict.jpg → user:pass@example.org/evilpict.jpg
Тогда при запросе авторизации, злому скрипту уйдёт бесполезные «user» и «pass».
Как круто! Работает.
Хотя нет, не работает, я сначала опечатался в URL.
(new Image).src = "http://user:pass@echoes.tk/test/auth.php";Даже если я вручную ввожу, мне говорит «имя пользователя и пароль были введены неверно». Предполагалось же, что скрипт «скушает» любую комбинацию, на будет валидировать её.
Сначала уходит запрос с именем и паролем, форма авторизации при этом действительно не показывается. Но когда сервер отвечает на этот запрос отказом, тогда уже браузер показывает незаполненную форму.
Я надеялся он хотя бы имя пользователя будет подставлять, тогда можно было бы вписать туда сообщение об опасности.
Я надеялся он хотя бы имя пользователя будет подставлять, тогда можно было бы вписать туда сообщение об опасности.
Кажется отвечать отказом рушит всю идею — пользователь явно заподоздрит неладное, если введёт верный с его точки зрения пароль.
Нет, не рушит. Во-первых, пользователь не видит первый отказ, он только в консоли показывается как «NetworkError: 401 Unauthorized». Пользователь видит только пустую форму авторизации. Достаточно на первый запрос ответить отказом, а потом уже принимать любые данные.
Во-вторых, когда пароль получен, можно сразу его менять, и пробовать тот же пароль на почтовый ящик. Высока вероятность, что совпадет.
Во-вторых, когда пароль получен, можно сразу его менять, и пробовать тот же пароль на почтовый ящик. Высока вероятность, что совпадет.
Годно.
Намного лучше, чем если сервер при добавлении кода картинки внутри текста будет проверять, какой там код ответа у картинки.
Намного лучше, чем если сервер при добавлении кода картинки внутри текста будет проверять, какой там код ответа у картинки.
Я вот тут подумал, почему бы на сайтах ссылки на картинки не преобразовывать с указанием имени и пароля?
То есть example.org/evilpict.jpg → user:pass@example.org/evilpict.jpg
Тогда при запросе авторизации, злому скрипту уйдёт бесполезные «user» и «pass».
Потому что это костыль вместо правильного решения. Правильнее было бы фильтровать данные вводимые пользователем. Будь это подпись на форуме или что угодно. Дело не в картинке, а в удаленном ресурсе, а ресурс может быть другой, например: стили, скрипты, те же картинки, да что угодно. Та и это не в какие ворота не лазит для картинки указывать логи и пароль.
А если и нужно разрешить удаленные картинки, то загружать их к себе на сервер и показывать со своего сервера. Хотя это более затратно по ресурсам (память) и картинки должны быть статическими. Но это дело можно совместить с белым списком хостов с которых можно загружать картинки (об этом уже писали).
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Злые фишинг картинки