- Регистрация
- 31.12.2019
- Сообщения
- 7,550
- Реакции
- 36
Данную статью планировал написать немногим позже, но по скольку она уже лежала готовая в текстовом файлике и тут платят за откровения, а это именно то что я искал
К тому-же статья является следствием того, что "не прошло и года, за то прошла половина" и единственная АВ компания с 3ей статьи именно по теме favicon (стоило на экспе подкинуть идейку - и моментально все начали делать глупые пародии на саму идею, от чего появились две статьи предшественницы с разбором попыток каких-то ноунеймов с экспа очевидно, а время жизни моего решения заметно увеличилось в следствии того, что эксперты видимо не ожидали такой версии реализации подмены favicon.ico.
Цитата из статьи: " The abuse of image headers to hide malicious code is not new, but this is the first time we witnessed it with a credit card skimmer. "
критика в сторону писавшего пост: его удивил не обход запретов браузера на подобные трюки, а то, что трюк применён именно впервые для выполнения скиммера. Это ведь абсолютно не имеет значения? То что подобное используют соц.сети для слежения и аналитики личных данных пользователей - это видимо норма, а эксплуатация коллапса системы безопасности который не решить никак, кроме как переделав все наново - тоже не проблема для писавшего пост. Либо он не разбирается в сути дела, либо, не уловил её. Что еще забавней, он делает отсылку к посту где exif тянется на PHP - что по сути является пустышкой и ничем примечательным не является. А вот то что было сделано до полной работоспособности и дискредитации понятия "***********************************а безопасности" написанном на чистом JS без использования каких либо библиотек - это как по мне трудно превзойти, но, один способ есть, в его корнях уже совсем другие проблемы тех же браузеров, и к ним я еще вернусь в следующей статье.
Статья-обзор основных проблем веб-безопасности и способов их решений и на уровне админов, и на уровне тех, кто лишь использует то что им преподносят.
Пожалуй главная тема завязана на том, что браузер как хранитель многих личных данных, так-же обладает и огромным функционалом благодаря сочетанию всего 2х крайне неуравновешенных и незащищенных технологий: HTML и JS.
Оказалось, что большинство браузеров буквально профилировано под скрытое слежение:
- Скрытые хранилища данных
- Абсолютное отсутствие возможности ограничить внутри HTML доступ к тем или иным данным вводимых форм
- JS превыше всего, а ***********************************а безопасности превыше JS. Итого: все баги аккумулируются вокруг ***********************************и безопасности вокруг ДОПОЛНИТЕЛЬНОГО языка JS. Напоминаю: JS - это лишь дополнение для браузеров, а не основа веб-вёрстки и тут кроется беда: почему JS в работе с данными главнее, а доступ к данным буквально никак не прописан в спецификации стандартов HTML, HTTP/2.0 ... Еще раз и коротко: HTML - должен быть главнее, тогда все проблемы безопасности канут в небытие.
Ввести атрибут для полей (input, select, radio, textarea e.t.c.) запрещающий чтение данных из поля для JS.
Подмена "action" параметра отправляемой формы на прокси сохраняющий и ретранслирующий данные на оригинал
Еще один атрибут запрещающий изменение тех или иных базовых параметров HTML тегов для JS
Таким образом, ограничив JS возможностью указать в HTML-полях запреты - мы возвращаем роль "главного" туда, где этой роли и место.
В качестве примера попробуйте обдумать для себя и такой
Кейлогер на JS не возможен ровно до тех пор, пока не установишь программно бинды на все клавиши и следуя за мышкой создавать вечно активное поле куда эти данные будут попадать.
Попробуйте придумать решение под данную задачу, не затронув при этом сегмент интернета с браузерными играми и прочими интерактивными забинженными скриптами.
Сегодня же я постараюсь коротко разобрать процесс понимания и создания скрипта способного сразу на 3 опасные для всех браузеров функции:
- скрытое получение и выполнение кода замаскированным под медиа-данные
- возможность препятствовать отладке процесса, не давая выполняться коду при открытой консоли. Причем важно: чтобы детект консоли работал вне зависимости от настройки "положения окна".
- полностью безграничный доступ к данным, который ничем не перекроить, и не ограничить. И что хуже: даже специальные хранилища для данных: LocalStorage как самый популярный вариант.
Причем касательно хранилищ данных у меня есть все основания полагать что они нужны только авторам браузеров, чтобы их трекеры, фингерпринтеры и прочие аналитики обрели специальное место для отработки данных, причем именно максимально в удалении от пользователя.
Начну пожалуй с консоли, ведь это буквально то первое решение что пришло ко мне спустя 30 минут гугла и попыток методом тыка. 99% решений работают либо не во всех браузерах, либо с багами, либо не отрабатывают при условиях типа открытой консоли в отдельном окне (поймете если будете гуглить и попадёте сюда).
___---level DEVTOOLS => 15 min of GOOGLE---___
Никакое другое не работает везде, и при любых условиях, причём - при минимально возможном количестве знаков. Причем как Вы видите - снова JS и его "пронзательность" ничем не ограниченная на всех уровнях - позволяют этому коду работать.
Принцип работы кода: создать объект "Картинка", задать свойство с целевым кодом внутри (к примеру изменение статуса переменной "открытая консоль" на "закрытая" и дальнейшая LIVE-отработка именно с этой переменной, безо всяких проблем, и на конец: вывод этого объекта с заданным свойством в консоль. И если консоль открыта - объект будет вызван, по скольку для вывода его в консоли он должен вызваться. Если консоль закрыта - то вывод в неё не станет причиной вызова объекта и соответственно выполнения кода внутри заданного свойства. На самом деле данный код можно улучшить как минимум в 3х пунктах, но, предполагаю те кому надо - разберутся.
И к сожалению решение этой проблемы как по мне не существует. Разве что ограничить работу свойства объектов на предмет возможности выводить их в консоль (или если и выводить - то без передачи информации про вызов именно для функции вывода в консоль). Хотя и эту защиту можно обойти, но это уже целая другая статья
___---level DEVTOOLS => busted---___
Хорошо, консоль заставили саму себя выпиливать - прекрасно (назовём эту ситуацию: охранник чистил дуло заведённого дробовика и решил пронаблюдать выстрел глядя прямо в дуло) теперь пришла пора понять как незаметно получить любой код и выполнить его, причем так, чтобы в консоли браузера это было максимально не заметно, или, если браузер разрешит так, чтобы этот код нельзя было поймать в запросах и при чтении исходных кодов.
И не долго думая в голове назрел список форматов, которые в консоли браузера не читаются как текстовый код: это медиа-файлы, и некоторые специфические файлы (отпадают в силу отсутствия поддержки везде и всегда).
Остаются лишь медиа-файлы, но, вопрос стоит в том - как сделать из настоящего медиафайла, причем желательно уже присутствующего на конечной цели. Вариантов несколько, но выбор пал на favicon.ico как самый популярный файл в интернете, к тому-же медиа.
Теперь как же заставить эту картинку хранить динамический код и посредством чистого JS - код вытянуть и выполнить? Спустя 2 сутки раздумий меня осенило: вспомнилась Windows XP и те времена, когда приходилось заходить во вкладку "Подробно" чтобы поменять ошибочное название песни, которое раздражает потом глаз на дисплее плеера.
Примерно поставив цель вместительности поля в минимум несколько тысячь символов недолгим брутфорсом оказалось что единственное идеально подходящее поле под названием "Комментарии".
Хорошо, код сохраняется, берём теперь настоящую иконку favicon.ico и осознаем, что можно просто отконвертировать её в jpeg (столкнувшись с проблемой минимального размера 32х32 задумаетесь над увеличением картинки до обработки), внести EXIF-тег с кодом и дальше дело за малым: надо эту картинку подгрузить в обход ***********************************и CORS (решается путём no-cors и на стороне клиента (JS формовка запросов) и на стороне приёма (PHP клиент с rewrite_mod трюками)
___---level evalFROMimg => poking around paths ---___
В принципе, решение для чтения EXIF из картинки легко вытащить из гугла. Я лично отталкивался от данного скрипта и сразу же столкнулся с проблемой, что картинка с иного домена буквально отказывалась расчленяться функцией. Браузер требовал, чтобы картинка была внутренняя для того домена, где мы пытаемся сделать разбор и решение было крайне простым: просто вывести картинку в DOM дерево, таким образом решив проблему с ***********************************ой безопасности.
___---level evalFROMimg = ISevalPOSSIBLE? ---___
Успешно разобравшись с получением кода из cross-domain картинки внезапно оказалось что код наотрез отказывается выполняться любым способом по причине того, что браузер против исполнения кода который до этого принадлежал картинке.
3 сутки я полагал, что задача нерешаема и я потратил 2 недели мыслей об этом зря, но меня осенило вновь: а может поиграться с выводом в DOM дерево?
Играясь с сотнями вариантов полей, проведя несколько дней в гугле я наконец-то наткнулся на эту статью. И перепробовав все указанные методы обнаружился один, работающий везде и без запинок. И это выполнение кода помещенного в атрибут onerror="". Тщательно поигравшись с экранизацией символов, получился конечный код, который Вы наблюдаете в статье malwarebytes.
___---level evalFROMimg = Secure ***********************************s? Unsecure greetings ---___
Итого вышло, что браузер конечно имеет ***********************************у безопасности, только такое впечатление, что "***********************************а безопасности" ограничена другой "***********************************ой неприкасаемых и малоизвестных функций", которые буквально стали исключением для всех 3х механизмов противостояния такого явно плохого поведения JS: code execution from cross-domain media-files
Вывод: ***********************************а безопасности скорее костыль - чем закон в браузере, и всемогущий JS это всегда рад справится с внутренними тараканами костыльных разрабов, что под "***********************************ой безопасности" подразумевают частичное ограничение самых популярных функций (напоминаю, для текущей задачи все буквально складывается как на мази: хотел картинку изначально - и без особых усилий браузер позволил мне это реализовать. Ладно бы если пришлось перепробовать пару тройку видов медиафайлов, но черт возьми: браузер забывает что код взялся из картинки, как только появляется не прописанное исключение "onerror" и примерно еще 3 варианта, которые я тестил только в Хроме (но с большой долей вероятности работающие и в других браузерах).
___---level sendingData = still image ---___
Сбор данных до изнеможения простой, там буквально не о чем рассказывать. ну и по скольку вся работа до этого момента вертелась вокруг картинки, мне стало чертовски желанно отправлять данные в виде той-же картинки, и это стало буквально завершающим штрихом
Данный код упаковывает blob как картинку, и дальше простая отправка данных которая в консоли будет смахивать на запрос "image binary data".
Исходя из реакции на эту статью я буду её дополнять по возникшим вопросам у пользователей, потому продолжение с развёрнутыми ответами на ваши вопросы, а так-же развёрнутые примеры с разбором кода будут в случае востребованности.
Цель статьи показать: насколько легко имея опыт и Google - писать скрипты, потенциально работающие в пределах ***********************************и безопасности браузера, заставляя браузер тем самым и быть "вредоносным ПО", по скольку всю работу (по приему, хранению и передаче данных, с трюками мешающими исследовать поведение кода в консоли) он выполняет на чистом JS, без библиотек типа jQuery и что самое главное: на любых OS и любых современных браузерах.
К тому-же, время от времени меня посещали идеи, которые (и каждый раз меня это удивляло будто впервые) работали и работают. Значит материал еще как минимум на 3 таких статьи, где с каждым разом вам будет открываться одна великая тайна: браузер - это абсолютно не способная к самоконтролю система, поддающаяся "обходу" методом тыка и не имеющая спустя десяток лет развития ЭЛЕМЕНТАРНЫХ способов ограничения влияния JS на первичный HTML.
Когда ожидать решения всего указанного? Не раньше глобального обновления движка и стандартов. Костыли лишь сломают сайты, которые используют указанные функции в мирных целях.
Почему столько компаний и лет разработки оставили нас на едине с желанием обезопасить свои данные? Вероятно потому, что Аналитика от Google, Яндекс и остальные мелочные примеры трекеров - напрямую зависимы от этих "дырочек" позволяющих им делать своё дело.
Ведь главное то, что большую часть подсказок и решений и подчеркнул именно пролистывая исходник аналитики, раз за разом мне открывались буквально те решения, против которых и был сделан скрипт Mr.Sniffa, как объединяющий все в одну кучу.
Что делать на данный момент? Смирится с тем фактом, что компании разработавшие браузеры искренне пытались завуалировать сбор и передачу данных. И худший пример абсолютно беспардонной, буквально ВИРУСНОЙ и бесконтрольной передачи данных на серверы Яндекса посредством самого злостного стиллера юзер-принтов, истории и даже куки - Яндекс.Браузер. Попробуйте проснифать процесс браузера так, чтобы браузер не знал что включен снифер запросов
Неужели всё так плохо? учитывая то, что код в пару строк способен обойти все механизмы защиты во всех браузерах на всех ОСях - да, факт фактом, но всё действительно плохо. и подобными трюками пользуются все социальные сети мечтающие показать тебе рекламу по теме твоего последнего запроса в google.
А что насчёт анонимных браузеров? По скольку они работают на той же базовой логике, и вместо борьбы с причиной - борются с следствием, то очевидно что они всего лишь пытаются препятствовать тому, под что браузер заделан. Бессмысленное препятствие на самом деле. Даю подсказку где искать больше всего чудесного кода: Facebook, Google, Яндекс. Если Вы еще ни разу не удосужились пролистать их скриптинг тщательно его почистив и декодировав - то самое время. Так-то, материала для разбора кода там еще на одну большую статью, и я даже не знаю есть ли смысл писать на форуме, где выводы делают раньше чем получат полноценную информацию?) Если оцените - напишу еще пару итоговых статей, так сказать, подарю идеи, которым не суждено было быть реализованным мною, за то другим программистам в радость)
А может быть хуже?
Конечно, на самом деле статья - лишь верхушка айсберга, и спускаться под лёд или нет - ваше дело, но как насчёт того, чтобы все созданные объекты, сразу же после выполнения удалять через parentNode.removeChild например. Или, вместо того чтобы в коде явно был указан домен куда идут запросы - высвечивался фейковый домен, который с помощью массива перестановок символов будет формировать конечный домен для запросов, решая проблему с поиском зловреда через поиск по ключевым словам и рекурсивного декодера зашифрованных строк. (про отладку в консоли можно забыть, ведь сверху не пробиваемая защита от консоли)
И все-же намекну еще раз: я рассказал лишь об одном из полученных "методом тыка" путей сокрытия подобной активности. Если ***********************************а безопасности не будет распространена на все составные части движков, а стандарты зависящие друг от друга не станут наконец-таки взаимо-ограничивающими для гарантии отсутствия утечек данных даже с реализованной XSS - то, этот интернет захлебнётся в слитых базах паролей и единственные пароли, что нельзя будет де факто сбрутить, станут md5 хеши тех самых паролей. Хотя секундочку... вспомнил про радужные таблицы на видеокартах и понял, что даже это не поможет.
Как защищаться от кражи данных с сайта?
Я советую использовать глобальные фильтры на приём данных, которые будут перерабатывать и обезвреживать всю поступающую на всех уровнях переменных информацию. Для каждого дела должно быть свое решение, но как завершающий этап статьи, приведу маленький не полноценный пример что покрывает 90% потребностей в фильтрации данных:
Вы должны понять, что бороться с следствием (внедрённым в базу кодом) бессмысленно. Фаерволлы и т.д. и т.п. на языке аналогий всего лишь по сигнатурам пытаются отсеять трафик, который не обязательно нуждается в отсеве (гибкость системы в 2к20 подавай повсеместно и без компромиссов, антивирусы как Вы поняли способны реагировать с диким замедлением в пол года и они не способны справится с рандомизацией кода, по скольку сигнатуры на каркасе из функций будут затрагивать множество других не вредных скриптов по всему интернету). И бороться с причиной в нашем случае значит - отрезать возможность принятия данных, способных нанести ущерб. Ситуации обычно касаются XSS и SQL, и буквально перелистав все вариации применения обоих типов баг - легко обнаружить то, что нуждается в фильтрации.
Код должен допиливатся Вами под локальные потребности отдельно взятого проекта, но рекомендую обратить внимание не необходимость отработки переменных $_COOKIE, $_SERVER как минимум, а так-же расширения возможностей функций по преобразованию спец.символов в их HTML коды. Побочные эффекты проверяйте сразу с полным набором возможных данных на вход (как и простые данные и то, как они в конце концов выглядят по итогу, так и успешное избежание XSS, SQL)
Примерно таким образом владельцы магазинов (и разработчики движков на которых оные работают - могли бы раз и навсегда решить проблему с входящими данными), но очевидно вместо кастомизации данного решения и возможности с ним работать для тех кому это надо, и отключить для тех, у кого данные не могут проходить сквозь призму фильтрации (к примеру на не дефолтных кодировках, разных алфавитах).
Возможно после этой статьи и разработчики движков, и разработчики браузеров наконец-таки повысят свой уровень, и тогда придёт время для другой статьи. Т.е. ровно в тот день когда все основные браузеры исправят указанные в статье бреши - я опубликую новую тему, с гораздо более тонкими структурными вопросами, чуть меньшим кросс-браузером, но, когда под каждый браузер пишется свое решение - здесь есть своя доля романтики. Особенно если одно другому рознь и костыль
P.S. Статья написана на одном дыхании и без особого старания, по скольку общество на данном форуме вполне вероятно даже и не оценит сей труд. А уж подробно стараться не зная реакции - и вовсе не хотелось. Жду ваших вопросов, и имейте в виду: статья написана в ознакомительных, образовательных целях, и несёт за собой лишь акцент внимания на природе "вредоносного ПО намеренно позволяющего похищать данные" в лице браузеров. По поводу передачи данных типичными браузерами ни для кого не новость, но как насчёт всеми любимых TOR, Sphere?) Я мельком чекал их, и если сфера хотя-бы пытается притворится хорошим браузером (но по факту браузер упускает новомодные заголовки по которым гугл идентифицирует людей. Хотя может и пофиксили. Не в курсе, но, кому интересно - поглядите) Напоминаю: процесс монитора пакетов надо скрыть, чтобы браузер его не видел, ибо они, и это лол, очевидно не делают ничего "плохого" если присутствует открытый процесс отдаленно похожий на снифер пакетов. В общем-то, браузер пытается обмануть ОСь, JS пытается обмануть браузер, а я осознаю и понимаю, что эта ситуация (на примере браузеров, хотя подобные статьи я могу написать практически по любому ПО которое исследовал) продлится еще минимум столько же, а то и гораздо больше.
Так-же передачу данных не стоит ждать на свежих установках браузера и ОСи. Казалось бы, можно же снять галочку про отправку данных? Только эта галочка не влияет на передачу твоих принтов. Не веришь? Убедись сам.
P.S. Самым желанным моим опытом как программиста уходящего на пенсию в трейдинг - была бы возможность денёк другой обсудить с разработчиками стандартов то, чем они озабочены. Если добавлять еще больше не обрабатываемых с должной степенью разграничения доступов функций - это все что они могут выпуская новый стандарт, то им самое место в тюрьме собственной ущербности и беспомощности, как потенциальных вредителей наражающих пользователей на неосознанную опасность. Процесс получения конечного результата был слишком простым, даже в сравнении с реверсингом обновлений лицензеров у всяких Adobe.
P.S.2 Данная статья по сути подчеркивает те проблемы, о которых написана 1001 другая статья на все те же темы, но сделано это на примере выработки решения под определенную задачу с 0.
Хорошим примером статьи по теме но без примеров пожалуй будет эта. Я бы сделал ставку, что фикс 4х основных браузеров включая мобильные версии и учитывая сложность и проблематику решения займёт минимум год, при условии что разрабы начали работу над новым стандартом прямо сейчас. Сколько времени у них займет жесткая переработка приоритетов в ***********************************е безопасности - хз, но по моим представлениям работы там куда больше и побочных багов будет очень много, просто потому что им придется буквально переделать свою матрёшку на новый-старый лад (читайте первичные спецификации симбиоза HTML/JS для понимания сути)
Автор: Bill
К тому-же статья является следствием того, что "не прошло и года, за то прошла половина" и единственная АВ компания с 3ей статьи именно по теме favicon (стоило на экспе подкинуть идейку - и моментально все начали делать глупые пародии на саму идею, от чего появились две статьи предшественницы с разбором попыток каких-то ноунеймов с экспа очевидно, а время жизни моего решения заметно увеличилось в следствии того, что эксперты видимо не ожидали такой версии реализации подмены favicon.ico.
Цитата из статьи: " The abuse of image headers to hide malicious code is not new, but this is the first time we witnessed it with a credit card skimmer. "
критика в сторону писавшего пост: его удивил не обход запретов браузера на подобные трюки, а то, что трюк применён именно впервые для выполнения скиммера. Это ведь абсолютно не имеет значения? То что подобное используют соц.сети для слежения и аналитики личных данных пользователей - это видимо норма, а эксплуатация коллапса системы безопасности который не решить никак, кроме как переделав все наново - тоже не проблема для писавшего пост. Либо он не разбирается в сути дела, либо, не уловил её. Что еще забавней, он делает отсылку к посту где exif тянется на PHP - что по сути является пустышкой и ничем примечательным не является. А вот то что было сделано до полной работоспособности и дискредитации понятия "***********************************а безопасности" написанном на чистом JS без использования каких либо библиотек - это как по мне трудно превзойти, но, один способ есть, в его корнях уже совсем другие проблемы тех же браузеров, и к ним я еще вернусь в следующей статье.
Статья-обзор основных проблем веб-безопасности и способов их решений и на уровне админов, и на уровне тех, кто лишь использует то что им преподносят.
Пожалуй главная тема завязана на том, что браузер как хранитель многих личных данных, так-же обладает и огромным функционалом благодаря сочетанию всего 2х крайне неуравновешенных и незащищенных технологий: HTML и JS.
Оказалось, что большинство браузеров буквально профилировано под скрытое слежение:
- Скрытые хранилища данных
- Абсолютное отсутствие возможности ограничить внутри HTML доступ к тем или иным данным вводимых форм
- JS превыше всего, а ***********************************а безопасности превыше JS. Итого: все баги аккумулируются вокруг ***********************************и безопасности вокруг ДОПОЛНИТЕЛЬНОГО языка JS. Напоминаю: JS - это лишь дополнение для браузеров, а не основа веб-вёрстки и тут кроется беда: почему JS в работе с данными главнее, а доступ к данным буквально никак не прописан в спецификации стандартов HTML, HTTP/2.0 ... Еще раз и коротко: HTML - должен быть главнее, тогда все проблемы безопасности канут в небытие.
Есть интернет-магазин, на котором клиенты вводят свои личные данные. Проблема в том, что эти данные легко улетают с помощью JS.
Ввести атрибут для полей (input, select, radio, textarea e.t.c.) запрещающий чтение данных из поля для JS.
Подмена "action" параметра отправляемой формы на прокси сохраняющий и ретранслирующий данные на оригинал
Еще один атрибут запрещающий изменение тех или иных базовых параметров HTML тегов для JS
В качестве примера попробуйте обдумать для себя и такой
Кейлогер на JS не возможен ровно до тех пор, пока не установишь программно бинды на все клавиши и следуя за мышкой создавать вечно активное поле куда эти данные будут попадать.
Сегодня же я постараюсь коротко разобрать процесс понимания и создания скрипта способного сразу на 3 опасные для всех браузеров функции:
- скрытое получение и выполнение кода замаскированным под медиа-данные
- возможность препятствовать отладке процесса, не давая выполняться коду при открытой консоли. Причем важно: чтобы детект консоли работал вне зависимости от настройки "положения окна".
- полностью безграничный доступ к данным, который ничем не перекроить, и не ограничить. И что хуже: даже специальные хранилища для данных: LocalStorage как самый популярный вариант.
Причем касательно хранилищ данных у меня есть все основания полагать что они нужны только авторам браузеров, чтобы их трекеры, фингерпринтеры и прочие аналитики обрели специальное место для отработки данных, причем именно максимально в удалении от пользователя.
Начну пожалуй с консоли, ведь это буквально то первое решение что пришло ко мне спустя 30 минут гугла и попыток методом тыка. 99% решений работают либо не во всех браузерах, либо с багами, либо не отрабатывают при условиях типа открытой консоли в отдельном окне (поймете если будете гуглить и попадёте сюда).
___---level DEVTOOLS => 15 min of GOOGLE---___
Код:
var element = new Image(); Object.defineProperty(element, 'id', { get: function () { alert('囧'); } }); console.log('%cHello', element);Никакое другое не работает везде, и при любых условиях, причём - при минимально возможном количестве знаков. Причем как Вы видите - снова JS и его "пронзательность" ничем не ограниченная на всех уровнях - позволяют этому коду работать.
Принцип работы кода: создать объект "Картинка", задать свойство с целевым кодом внутри (к примеру изменение статуса переменной "открытая консоль" на "закрытая" и дальнейшая LIVE-отработка именно с этой переменной, безо всяких проблем, и на конец: вывод этого объекта с заданным свойством в консоль. И если консоль открыта - объект будет вызван, по скольку для вывода его в консоли он должен вызваться. Если консоль закрыта - то вывод в неё не станет причиной вызова объекта и соответственно выполнения кода внутри заданного свойства. На самом деле данный код можно улучшить как минимум в 3х пунктах, но, предполагаю те кому надо - разберутся.
И к сожалению решение этой проблемы как по мне не существует. Разве что ограничить работу свойства объектов на предмет возможности выводить их в консоль (или если и выводить - то без передачи информации про вызов именно для функции вывода в консоль). Хотя и эту защиту можно обойти, но это уже целая другая статья
___---level DEVTOOLS => busted---___
Хорошо, консоль заставили саму себя выпиливать - прекрасно (назовём эту ситуацию: охранник чистил дуло заведённого дробовика и решил пронаблюдать выстрел глядя прямо в дуло) теперь пришла пора понять как незаметно получить любой код и выполнить его, причем так, чтобы в консоли браузера это было максимально не заметно, или, если браузер разрешит так, чтобы этот код нельзя было поймать в запросах и при чтении исходных кодов.
И не долго думая в голове назрел список форматов, которые в консоли браузера не читаются как текстовый код: это медиа-файлы, и некоторые специфические файлы (отпадают в силу отсутствия поддержки везде и всегда).
Остаются лишь медиа-файлы, но, вопрос стоит в том - как сделать из настоящего медиафайла, причем желательно уже присутствующего на конечной цели. Вариантов несколько, но выбор пал на favicon.ico как самый популярный файл в интернете, к тому-же медиа.
Теперь как же заставить эту картинку хранить динамический код и посредством чистого JS - код вытянуть и выполнить? Спустя 2 сутки раздумий меня осенило: вспомнилась Windows XP и те времена, когда приходилось заходить во вкладку "Подробно" чтобы поменять ошибочное название песни, которое раздражает потом глаз на дисплее плеера.
Примерно поставив цель вместительности поля в минимум несколько тысячь символов недолгим брутфорсом оказалось что единственное идеально подходящее поле под названием "Комментарии".
Хорошо, код сохраняется, берём теперь настоящую иконку favicon.ico и осознаем, что можно просто отконвертировать её в jpeg (столкнувшись с проблемой минимального размера 32х32 задумаетесь над увеличением картинки до обработки), внести EXIF-тег с кодом и дальше дело за малым: надо эту картинку подгрузить в обход ***********************************и CORS (решается путём no-cors и на стороне клиента (JS формовка запросов) и на стороне приёма (PHP клиент с rewrite_mod трюками)
___---level evalFROMimg => poking around paths ---___
В принципе, решение для чтения EXIF из картинки легко вытащить из гугла. Я лично отталкивался от данного скрипта и сразу же столкнулся с проблемой, что картинка с иного домена буквально отказывалась расчленяться функцией. Браузер требовал, чтобы картинка была внутренняя для того домена, где мы пытаемся сделать разбор и решение было крайне простым: просто вывести картинку в DOM дерево, таким образом решив проблему с ***********************************ой безопасности.
___---level evalFROMimg = ISevalPOSSIBLE? ---___
Успешно разобравшись с получением кода из cross-domain картинки внезапно оказалось что код наотрез отказывается выполняться любым способом по причине того, что браузер против исполнения кода который до этого принадлежал картинке.
3 сутки я полагал, что задача нерешаема и я потратил 2 недели мыслей об этом зря, но меня осенило вновь: а может поиграться с выводом в DOM дерево?
Играясь с сотнями вариантов полей, проведя несколько дней в гугле я наконец-то наткнулся на эту статью. И перепробовав все указанные методы обнаружился один, работающий везде и без запинок. И это выполнение кода помещенного в атрибут onerror="". Тщательно поигравшись с экранизацией символов, получился конечный код, который Вы наблюдаете в статье malwarebytes.
___---level evalFROMimg = Secure ***********************************s? Unsecure greetings ---___
Итого вышло, что браузер конечно имеет ***********************************у безопасности, только такое впечатление, что "***********************************а безопасности" ограничена другой "***********************************ой неприкасаемых и малоизвестных функций", которые буквально стали исключением для всех 3х механизмов противостояния такого явно плохого поведения JS: code execution from cross-domain media-files
Вывод: ***********************************а безопасности скорее костыль - чем закон в браузере, и всемогущий JS это всегда рад справится с внутренними тараканами костыльных разрабов, что под "***********************************ой безопасности" подразумевают частичное ограничение самых популярных функций (напоминаю, для текущей задачи все буквально складывается как на мази: хотел картинку изначально - и без особых усилий браузер позволил мне это реализовать. Ладно бы если пришлось перепробовать пару тройку видов медиафайлов, но черт возьми: браузер забывает что код взялся из картинки, как только появляется не прописанное исключение "onerror" и примерно еще 3 варианта, которые я тестил только в Хроме (но с большой долей вероятности работающие и в других браузерах).
___---level sendingData = still image ---___
Сбор данных до изнеможения простой, там буквально не о чем рассказывать. ну и по скольку вся работа до этого момента вертелась вокруг картинки, мне стало чертовски желанно отправлять данные в виде той-же картинки, и это стало буквально завершающим штрихом
Данный код упаковывает blob как картинку, и дальше простая отправка данных которая в консоли будет смахивать на запрос "image binary data".
Исходя из реакции на эту статью я буду её дополнять по возникшим вопросам у пользователей, потому продолжение с развёрнутыми ответами на ваши вопросы, а так-же развёрнутые примеры с разбором кода будут в случае востребованности.
Цель статьи показать: насколько легко имея опыт и Google - писать скрипты, потенциально работающие в пределах ***********************************и безопасности браузера, заставляя браузер тем самым и быть "вредоносным ПО", по скольку всю работу (по приему, хранению и передаче данных, с трюками мешающими исследовать поведение кода в консоли) он выполняет на чистом JS, без библиотек типа jQuery и что самое главное: на любых OS и любых современных браузерах.
К тому-же, время от времени меня посещали идеи, которые (и каждый раз меня это удивляло будто впервые) работали и работают. Значит материал еще как минимум на 3 таких статьи, где с каждым разом вам будет открываться одна великая тайна: браузер - это абсолютно не способная к самоконтролю система, поддающаяся "обходу" методом тыка и не имеющая спустя десяток лет развития ЭЛЕМЕНТАРНЫХ способов ограничения влияния JS на первичный HTML.
Когда ожидать решения всего указанного? Не раньше глобального обновления движка и стандартов. Костыли лишь сломают сайты, которые используют указанные функции в мирных целях.
Почему столько компаний и лет разработки оставили нас на едине с желанием обезопасить свои данные? Вероятно потому, что Аналитика от Google, Яндекс и остальные мелочные примеры трекеров - напрямую зависимы от этих "дырочек" позволяющих им делать своё дело.
Ведь главное то, что большую часть подсказок и решений и подчеркнул именно пролистывая исходник аналитики, раз за разом мне открывались буквально те решения, против которых и был сделан скрипт Mr.Sniffa, как объединяющий все в одну кучу.
Что делать на данный момент? Смирится с тем фактом, что компании разработавшие браузеры искренне пытались завуалировать сбор и передачу данных. И худший пример абсолютно беспардонной, буквально ВИРУСНОЙ и бесконтрольной передачи данных на серверы Яндекса посредством самого злостного стиллера юзер-принтов, истории и даже куки - Яндекс.Браузер. Попробуйте проснифать процесс браузера так, чтобы браузер не знал что включен снифер запросов
Неужели всё так плохо? учитывая то, что код в пару строк способен обойти все механизмы защиты во всех браузерах на всех ОСях - да, факт фактом, но всё действительно плохо. и подобными трюками пользуются все социальные сети мечтающие показать тебе рекламу по теме твоего последнего запроса в google.
А что насчёт анонимных браузеров? По скольку они работают на той же базовой логике, и вместо борьбы с причиной - борются с следствием, то очевидно что они всего лишь пытаются препятствовать тому, под что браузер заделан. Бессмысленное препятствие на самом деле. Даю подсказку где искать больше всего чудесного кода: Facebook, Google, Яндекс. Если Вы еще ни разу не удосужились пролистать их скриптинг тщательно его почистив и декодировав - то самое время. Так-то, материала для разбора кода там еще на одну большую статью, и я даже не знаю есть ли смысл писать на форуме, где выводы делают раньше чем получат полноценную информацию?) Если оцените - напишу еще пару итоговых статей, так сказать, подарю идеи, которым не суждено было быть реализованным мною, за то другим программистам в радость)
А может быть хуже?
Конечно, на самом деле статья - лишь верхушка айсберга, и спускаться под лёд или нет - ваше дело, но как насчёт того, чтобы все созданные объекты, сразу же после выполнения удалять через parentNode.removeChild например. Или, вместо того чтобы в коде явно был указан домен куда идут запросы - высвечивался фейковый домен, который с помощью массива перестановок символов будет формировать конечный домен для запросов, решая проблему с поиском зловреда через поиск по ключевым словам и рекурсивного декодера зашифрованных строк. (про отладку в консоли можно забыть, ведь сверху не пробиваемая защита от консоли)
И все-же намекну еще раз: я рассказал лишь об одном из полученных "методом тыка" путей сокрытия подобной активности. Если ***********************************а безопасности не будет распространена на все составные части движков, а стандарты зависящие друг от друга не станут наконец-таки взаимо-ограничивающими для гарантии отсутствия утечек данных даже с реализованной XSS - то, этот интернет захлебнётся в слитых базах паролей и единственные пароли, что нельзя будет де факто сбрутить, станут md5 хеши тех самых паролей. Хотя секундочку... вспомнил про радужные таблицы на видеокартах и понял, что даже это не поможет.
Как защищаться от кражи данных с сайта?
Я советую использовать глобальные фильтры на приём данных, которые будут перерабатывать и обезвреживать всю поступающую на всех уровнях переменных информацию. Для каждого дела должно быть свое решение, но как завершающий этап статьи, приведу маленький не полноценный пример что покрывает 90% потребностей в фильтрации данных:
PHP:
function xss_cleaner($input_str) { $return_str = str_replace( array('<','>',"'",'"'), array(htmlspecialchars('<'),htmlspecialchars('>'),htmlspecialchars("'"),htmlspecialchars('"')), $input_str ); $return_str = str_ireplace( '%3Cscript', '', $return_str ); return $return_str; } function filter($data) { //Filters data against security risks. $data = trim(htmlentities(strip_tags($data))); if(get_magic_quotes_gpc()) $data = stripslashes($data); // $data = mysql_real_escape_string($data); return $data; } foreach($_GET as $key => $value) { $_GET[$key] = xss_cleaner(filter($value)); } foreach($_POST as $key => $value) { $_POST[$key] = xss_cleaner(filter($value)); }Вы должны понять, что бороться с следствием (внедрённым в базу кодом) бессмысленно. Фаерволлы и т.д. и т.п. на языке аналогий всего лишь по сигнатурам пытаются отсеять трафик, который не обязательно нуждается в отсеве (гибкость системы в 2к20 подавай повсеместно и без компромиссов, антивирусы как Вы поняли способны реагировать с диким замедлением в пол года и они не способны справится с рандомизацией кода, по скольку сигнатуры на каркасе из функций будут затрагивать множество других не вредных скриптов по всему интернету). И бороться с причиной в нашем случае значит - отрезать возможность принятия данных, способных нанести ущерб. Ситуации обычно касаются XSS и SQL, и буквально перелистав все вариации применения обоих типов баг - легко обнаружить то, что нуждается в фильтрации.
Код должен допиливатся Вами под локальные потребности отдельно взятого проекта, но рекомендую обратить внимание не необходимость отработки переменных $_COOKIE, $_SERVER как минимум, а так-же расширения возможностей функций по преобразованию спец.символов в их HTML коды. Побочные эффекты проверяйте сразу с полным набором возможных данных на вход (как и простые данные и то, как они в конце концов выглядят по итогу, так и успешное избежание XSS, SQL)
Примерно таким образом владельцы магазинов (и разработчики движков на которых оные работают - могли бы раз и навсегда решить проблему с входящими данными), но очевидно вместо кастомизации данного решения и возможности с ним работать для тех кому это надо, и отключить для тех, у кого данные не могут проходить сквозь призму фильтрации (к примеру на не дефолтных кодировках, разных алфавитах).
Возможно после этой статьи и разработчики движков, и разработчики браузеров наконец-таки повысят свой уровень, и тогда придёт время для другой статьи. Т.е. ровно в тот день когда все основные браузеры исправят указанные в статье бреши - я опубликую новую тему, с гораздо более тонкими структурными вопросами, чуть меньшим кросс-браузером, но, когда под каждый браузер пишется свое решение - здесь есть своя доля романтики. Особенно если одно другому рознь и костыль
P.S. Статья написана на одном дыхании и без особого старания, по скольку общество на данном форуме вполне вероятно даже и не оценит сей труд. А уж подробно стараться не зная реакции - и вовсе не хотелось. Жду ваших вопросов, и имейте в виду: статья написана в ознакомительных, образовательных целях, и несёт за собой лишь акцент внимания на природе "вредоносного ПО намеренно позволяющего похищать данные" в лице браузеров. По поводу передачи данных типичными браузерами ни для кого не новость, но как насчёт всеми любимых TOR, Sphere?) Я мельком чекал их, и если сфера хотя-бы пытается притворится хорошим браузером (но по факту браузер упускает новомодные заголовки по которым гугл идентифицирует людей. Хотя может и пофиксили. Не в курсе, но, кому интересно - поглядите) Напоминаю: процесс монитора пакетов надо скрыть, чтобы браузер его не видел, ибо они, и это лол, очевидно не делают ничего "плохого" если присутствует открытый процесс отдаленно похожий на снифер пакетов. В общем-то, браузер пытается обмануть ОСь, JS пытается обмануть браузер, а я осознаю и понимаю, что эта ситуация (на примере браузеров, хотя подобные статьи я могу написать практически по любому ПО которое исследовал) продлится еще минимум столько же, а то и гораздо больше.
Так-же передачу данных не стоит ждать на свежих установках браузера и ОСи. Казалось бы, можно же снять галочку про отправку данных? Только эта галочка не влияет на передачу твоих принтов. Не веришь? Убедись сам.
P.S. Самым желанным моим опытом как программиста уходящего на пенсию в трейдинг - была бы возможность денёк другой обсудить с разработчиками стандартов то, чем они озабочены. Если добавлять еще больше не обрабатываемых с должной степенью разграничения доступов функций - это все что они могут выпуская новый стандарт, то им самое место в тюрьме собственной ущербности и беспомощности, как потенциальных вредителей наражающих пользователей на неосознанную опасность. Процесс получения конечного результата был слишком простым, даже в сравнении с реверсингом обновлений лицензеров у всяких Adobe.
P.S.2 Данная статья по сути подчеркивает те проблемы, о которых написана 1001 другая статья на все те же темы, но сделано это на примере выработки решения под определенную задачу с 0.
Хорошим примером статьи по теме но без примеров пожалуй будет эта. Я бы сделал ставку, что фикс 4х основных браузеров включая мобильные версии и учитывая сложность и проблематику решения займёт минимум год, при условии что разрабы начали работу над новым стандартом прямо сейчас. Сколько времени у них займет жесткая переработка приоритетов в ***********************************е безопасности - хз, но по моим представлениям работы там куда больше и побочных багов будет очень много, просто потому что им придется буквально переделать свою матрёшку на новый-старый лад (читайте первичные спецификации симбиоза HTML/JS для понимания сути)
Ближе к тому моменту когда Вы дочитаете 3-ю статью по браузерам, если она конечно будет актуальна и выпущена у вас тоже поднимется ЧСВ, от того, что мысли станут ценными, а опыт богаче
моё чсв соответствует той ценности инфы что я обладаю, но, об этом вы могли бы знать только увидев мой профиль на linkld, github и ряде других сообществ где публикую свои белые разработки под другим именем. Единственное место где мой формат публикаций не оценили - это хабр, но, они не сильно любят художественный уклон при написании статей. И ЧСВ без репутации на хабре тоже. (ну что, деанонщики, найдёте самое ценное что у меня есть? Дам 3 подсказки: профиль на linkld с января 2013 года, на нём 116 позитива, 0 негатива, и всего лишь 1 строка из описания которую можно было встретить в моем личном телеграме. Перебрав все профили там такой лишь один, только что проверил)
Автор: Bill