Pull to refresh

Comments 55

Думал, есть только «гламурное кисо», а, оказывается, есть ещё и «банковское CISO»! :)
Давно уже хочу начать развиваться в этом направлении — какие книги посоветуете «с нуля» или около него?
Вот, любопытно стало: «захайдиться», «либы», «несекьюрно» и так далее — это авторский стиль повествования, или же речь «главного безопасника» действительно настолько богата жаргонизмами?
Речь главного безопасника очень живая и веселая. Инженер же, а не унылый пиджак :).
Пиджаки тоже бывают инженерами и вполне живыми =) Не с теми пиджаками вы общались =)
Почему бы на профессиональные темы не разговаривать на профессиональном жаргоне?
Официальная терминология и сленг — не совсем одно и то же. Первым пользуются профессионалы, вторым обычно злоупотребляют те, кто ими хочет казаться. Из личного опыта. Отсюда и удивление.
100% согласны. Мы подозревали, что Кирилл вместо работы танки качает, а чтобы не выгнали за профнепригодность, рассказывает как «захайдится для блека» и «какие либы заюзать, чтобы не попавнили»
Речь не о сомнениях в профессионализме интервьюируемого (их нет) а о несоответствии действительности ожиданиям. Не стоит ударяться в крайности.
А какие ожидания-то были? По-вашему, в корпсеке только роботы, которые общаются языком статей из журнала «Информационная безопасность»?

Осознавая растущую зависимость от автоматизированных систем, бизнес также готов все больше заботиться об обеспечении информационной безопасности. Причем путь создания системы ИБ зависит от ситуации в данной конкретной организации – от имевших место инцидентов, убеждений конкретных сотрудников – и зачастую формируется «снизу», от отдельных подсистем ИБ к общей картине. В результате создается многоступенчатая единственная в своем роде система, состоящая из различных продуктов и сервисных работ, сложная, как правило, уникальная у каждой компании.
Не впадайте в крайности, GeMir совершенно резонно заметил слишком много жаргонизмов и ка́лек. Для всего этого есть красивые русские слова. Если человек так часто употребляет сленг, или, что хуже, называет себя хакером, я по умолчанию отношусь к нему скептически.

К слову, я и к журналу вашему до сих пор не привык, как-то сразу отдает несерьезностью обращения на «ты».
Не, вы гляньте, ему показали непуганого вайтхата в естественной среде обитания, а он нос воротит
Действительно: «Блек не будет скилляться ради фана», — какая-то фубля
Те, кто блечил, не могут попасть на работу в крупные компании.


Это если нашли. Если успешно блечил какое-то время и об этом никто не узнал — получил работу, денег стало хватать, профит.
Ох золотые слова. Это проблема, да.
Это то самое Qiwi, из которого я два месяца не мог деньги вывести, потому что SMS не приходило на телефон, а служба поддержки упорно делала вид что не замечает меня?
UFO just landed and posted this here
А еще у них уборщица плохо полы моет. Давайте валить все в одну кучу, да.
А еще фишка, когда твой e-mail в системе зарегистрирован, а телефон — «данного агента не существует» или что-то вроде.
Очень круто! Читаю и внутри смешанные чевства говорящие о том, что стоит выключить South Park и пойти позадротить хоть что-то до должного уровня владения. Короче респект Кириллу, материал очень мотивирует.
После прочтения поста создается впечатление, что ты не нормальный разработчик, а только что закончил второй класс школы. Возможно, сленг добавляет завесу тайны в термины, но читалось на одном дыхании как журнал хакер лет 10 назад :)
Да откуда это заблуждение-то, что чем круче специалист, те больше наукообразия в его речи?

Наоборот. Ты — специалист, если можешь простым языком с общепринятым сленгом объяснить сложные (и порой, скучные) вещи людям.
Главная концепция безопасности в том, что мы считаем любой user input вредоносным априори. А девелопер не считает.

Мне кажется это очевидная для каждого девелопера мысль, что любые данные заведомо опасные и их нужно чистить, по крайней мере для веба — точно.
Понимают все, следовать сложно :)

Когда у тебя небольшой проект, одна точка входа и глобальный парсер инпута, несложно написать регулярки на вход. Но со временем появляются костыли, быстрофиксы, новые параметры, и где-то все равно появляется нефильтрованный ввод.

Это, конечно, к организации кода вопрос, но в жизни часто бывает как-то так :).
Дело не в размерах проекта, а в голове разработчика, получил данные — проверь, вставляешь в базу — очисти, это уже на уровне рефлексов должно быть. В идеале конечно же.
Просто было странно читать такое про девелоперов от «главного безопасника QIWI», надеюсь он это не про нынешних своих коллег.

Кавычка в инпуте это совсем детство. Проблемы обычно не из-за этого.
Получил url http://example.com/%s — проверил, валидный, ок, отправил в сервис, который передаст его другому сервису, который через год воспримет его как format string. Всё проверить, предусмотреть, обложить тестами — это очень сложно, потому что часто разработчик даже не знает, из какого компонента системы запрос возник, через что прошёл, кто и чем его проверил, как и где будет обрабатываться через год, когда накрутят функционала в 5 раз больше чем сейчас. Как видим, с этим не справляется ни яндекс, ни гугл — никто. Дело, конечно, в голове, да, но это уже голова не одного человека, а с одновременным представлением работы системы в целом и каждого компонента в частности есть проблемы: в голову всё не влезает.

Я не только про кавычку, ваш пример это проблема принимающего сервиса, который так же должен проверять все входные данные. Это не так сложно, как вы пытаетесь преподнести. А про компоненты системы — если разработчик не знает откуда пришёл запрос, то тем более нужно их проверять и чистить, если вы с ними работаете, а не просто передаёте данные. Проблему всегда можно избежать на «последней миле», просто очистив данные.

Такие проблемы оттого что не договорились / не знали / не придали значения / не так поняли, поэтому валидация скорее всего не поможет. Я что пытаюсь донести: "просто очистить" можно, когда знания о системе укладываются в голове (вот текст инпута, вот база, положи одно в другое — да, предельно просто). Когда связей настолько много, что вызовы могут приходить из компонента, спроектированного удалённой командой, а уходить, пройдя через несколько сторонних решений — их не так просто очистить, надо многое держать в голове.

Сложно определить пользователя. Те же переменные окружения можно считать пользовательским вводом, а можно не считать. Хорошие приложения считают что они запустились на военной базе врага, где вызов системного метода — тоже пользовательский ввод.
Ну, не сгущайте краски. Эдак мы и до доверенной среды исполнения, загрузчика и аппаратных закладок в процессорах дойдем :).

Самый простой способ засекьюрить инпут в типовом проекте (QIWI — не типовой проект!) — просто централизовать ввод, и прямо на уровне middleware проверять инпут по базе регулярок. Чуть что — бросать 400 код, и привет. Так, чтобы до типа-контроллера не долетало. Это если у нас есть какое-то подобие MVC и фреймворка, но без них тоже написать несложно)

Вот эти телодвижения выше круто работают, когда у тебя есть время и возможность делать хотя бы базовую секурити. А когда «надо срочно добавить поле «Описание» на сайт и еще там в корзине верстка разъезжается», вот тут не работает. Задача сделать быстро и чтобы работало. У типового программиста элементарно нет времени (и привычки!) думать о каком-то инпуте. Разве что, фреймворк подумает.

Я не говорю, что это нормальный и правильный подход, я говорю, что в небольших проектах так бывает. А небольшой проект !== нет денег.
Централизовать ввод не всегда возможно — особенно когда у системы с десяток разных интерфейсов/протоколов. Типичный случай — шаблоны читали из файла, стало несколько машин — перенесли в базу, потом сделали микросервис, сейчас переезжаем на платформу у которой такой сервис «из коробки», но с несколько другим АПИ.
Пишите/используйте абстракции (желательно готовые). Абстракции просто не дадут непроверенному варианту записаться в базу, валидации не пройдут.
Если вы про ORM, то я писал об этом выше; но и речь не только о базе. Вредоносный инпут может совсем не относиться к БД, и соответственно проходить мимо слоя валидации ORM. В этом случае ответственность за фильтрацию лежит на разработчике.
«Чистить», «фильтрация» — это все термины, не имеющие ничего общего с безопасностью.

В качестве примера можно противопоставить «чистить данные перед отправкой в sql» (не работает) и «использовать параметризованные запросы» (работает). Дальше, я надеюсь, уже нагуглятся подробности, ну и плюс по остальным темам. Азы как бы.

Чисто по-человечески — рекомендую слова «чистить» и «фильтрация» не употреблять.
Я лично знаю программистов, для которых и git — неподъёмная тяжесть для мозгов, и эту статью читать они не будут вообще. Потому что зачем?
И при этом они пишут сайты на php. Да.
Вся проблема в построении фразы, мне она тоже резанула слух. Звучит, будто каждый программист не считает вредоносными входящие данные. Отнюдь. Просто надо было аккуратней выражаться, смею предположить, что и не каждый безопасник таков, как описывает isox.
Ну фииииг знает… QIWI то дырявое — предырявое, а платить за репорты не хочет-с, абсолютно на все — *Нам уже известно* или вообще не отвечают
Дырявое? Not really.
*Нам уже известно* --> В этот момент обычно добавляют в вотчеры к первичному репорту.
Кидай тикеты в личку, посмотрю что там такое.
Или телеграм — @isox_xx
https://hackerone.com/qiwi ---> Там внизу есть лог. Все, что rewarded = мы заплатили денег. Все, что resolved = мы пофиксили багу.
BB от QIWI платит исправно, но большинство багов фиксятся очень долго, поэтому им обо всём уже известно. Вознаграждения нормальные, заморочится можно, но есть более интересные варианты :)
Отличный текст и мотивация для молодых специалистов. В QiWi одна из сильнейших ИБ-команд в РФ.
Отличная статья, спасибо! Вы кстати когда на сайте Хакера форум вернете? B CMS-ка у вас какая-то на редкость тормозная…
Рады стараться!)

По форуму: как только так и сразу, после нового сайта. Мы выкатимся сразу с новым движком и дизом. Сейчас допиливаем верстку и тюним кеши. Текущая CMS — это тихий ужас, полностью согласен, но, увы, были причины сделать так в свое время. Все понимаем, и работаем в этом направлении. Ждать осталось совсем недолго)

журнал Хакер листал лет 15 там так и писалось все для кулхацкеров-падонкафф — «закодить на дельфях» или «perlовая каша» — как сейчас помню, тогда было прикольно. Думал на хабре они будут ориентироваться на более серьезную (взрослую и тд) аудиторию и как то этот сленг модифицируют, даже если так выражается «главный безопасник»
Поглядите другие статьи из нашего блога на Хабре. Сами убедитесь: мы можем быть очень унылыми и нудными, что, несомненно, говорит о серьезности и взрослости :)

А если без шуток, все от материала зависит. Это интервью с веселым и «живым» человеком, делать из его речи нудятину было бы просто кощунственно, поэтому постарались передать.
Без «блек не будет скилляться ради фана» статья не стала бы унылее или нуднее ни на йоту. Просто было бы приятнее читать.
> Возьми хотя бы VPN. Ты работаешь, павнишь что-то. VPN моргнул на секундочку — и этого хватило. Всего один пакет, и отсветился твой реальный IP.

Откройте для себя уже netns. Вешать роуты триггером на VPN — последнее дело.
Ага, откройте и потом закройте, ибо в подсистеме netfilter в ядре Linux нашли уязвимость как раз затрагивающую user namespaces и network namespaces, сборка ядра с CONFIG_USER_NS=y и CONFIG_NET_NS=y. Пруф http://www.opennet.ru/opennews/art.shtml?num=44669
User Namespace настолько были и продолжают быть дырявыми, что большинство дистрибутивов собирают ядро без них. С остальными неймспейсами, насколько мне известно, особых проблем нет.
> Вайты всегда скилловее блеков
В техническом плане — возможно, в остальном — не факт.
У «блеков» и «вайтов» изначально разные цели. И скилы у них немного различаются. У «блека» главная цель — денежная прибыль. И тут задействуются не столько технические знания, сколько хитрость, умение обманывать, социальная инженерия вообщем. Умение рубить бабло и есть основной скилл «блеков». Остальное их не волнует.
«вайты» могут иметь больше технических знаний, так как, работают за саму идею ИБ и как следствие питают бОльший интерес к изучению программного обеспечения, поиска уязвимостей, реверсинге.
Коротко говоря, у одних цель — деньги, у других — изучение программного обеспечения и его защита. Совершенно разные цели. Как следствие — разные деньги.
Это если сравнивать среднестатического блека и вайта. А так думаю с обоих сторон есть люди, для которых их дело — это работа, хобби, да и вообще смысл жизни. И они наиболее развиты в своем любимом деле.
имхо.
>Надеяться, что тебя не найдут, — это последнее дело. Любую твою активность, даже хорошо закамуфлированную, можно посчитать. Вопрос в >стоимости поисков по сравнению с тем, сколько блек пытается спереть. Это же простая математика: если ты украл 10 000 000 долларов, то эти >люди будут готовы потратить как минимум 9 999 999 долларов, чтобы тебя найти, и все еще останутся в условном плюсе.

Да уж условный плюс, предположим, что хакера поймали, а 10млн $ не нашли, а на поиски потратили 9 999 999 $, итого совокупный убыток
19 999 999 $ и где тут ТС увидел условный плюс непонятно, больше смахивает на что-то, из серии что больше весит килограмм металла или килограмм ваты? :)
Ой вей. Вы правы, сударь. Некорректно передал мысль.
Смысл-то был в том, что деньги в этом случае тратятся на расследование и поимку с целью нейтрализации риска последующего рецидива.
Чаще всего о возмещении убытков можно забыть, но если действовать оперативно, то есть шансы и что-то вернуть.
Фотографии с потрошением «тумбочек» (тесты на вандалоустойчивость?) для прикола или действительно в обязанности Кирилла входит какая-то физическая работа с ними, помимо софтверной?

Вот, например, d0znpp. У него недавно было время, он пошел и поломал чайник. Он теперь у нас главный хакер по взлому чайников, холодильников и другого IoT.
Пошёл в хабраюзерский профиль в надежде, что встречу какую-нибудь блогозапись с подробностями об этом. Не нашёл. Зато выпал в осадок от увиденного женского срача на oxod.ru
К счастью есть whoishistory.ru, который подтвердил догадку, что у домена просто новый хозяин
Я так понимаю Vulners — это как аггрегатор новостей, но про уязвимости? Когда вижу вот такую портянку, криво спарсенную с legalhackers.com, понимаю что так — https://vulners.com/seebug/SSV-92405
Чуть сложнее. Исходник вот тут — https://www.seebug.org/vuldb/ssvid-92405
Там оригинальный контент часто на китайском, поэтому парсер сходит с ума :(
legalhackers.com пока не парсятся, увы.

Смысл vulners в том, что бы структурировать в машиночитаемый вид то, что изначально таким не было.
Вот например патч уязвимости: https://vulners.com/centos/CESA-2016:2850
Вот так он выглядел до сборки:

http://lists.centos.org/pipermail/centos-announce/2016-December/022169.html
http://lists.centos.org/pipermail/centos-announce/2016-December/022170.html
http://lists.centos.org/pipermail/centos-cr-announce/2016-December/003714.html

А вот так он выглядит в JSON: https://vulners.com/api/v3/search/id/?id=CESA-2016:2850
Only those users with full accounts are able to leave comments. Log in, please.