Comments 55
Осознавая растущую зависимость от автоматизированных систем, бизнес также готов все больше заботиться об обеспечении информационной безопасности. Причем путь создания системы ИБ зависит от ситуации в данной конкретной организации – от имевших место инцидентов, убеждений конкретных сотрудников – и зачастую формируется «снизу», от отдельных подсистем ИБ к общей картине. В результате создается многоступенчатая единственная в своем роде система, состоящая из различных продуктов и сервисных работ, сложная, как правило, уникальная у каждой компании.
К слову, я и к журналу вашему до сих пор не привык, как-то сразу отдает несерьезностью обращения на «ты».
Те, кто блечил, не могут попасть на работу в крупные компании.
Это если нашли. Если успешно блечил какое-то время и об этом никто не узнал — получил работу, денег стало хватать, профит.
Главная концепция безопасности в том, что мы считаем любой user input вредоносным априори. А девелопер не считает.
Мне кажется это очевидная для каждого девелопера мысль, что любые данные заведомо опасные и их нужно чистить, по крайней мере для веба — точно.
Когда у тебя небольшой проект, одна точка входа и глобальный парсер инпута, несложно написать регулярки на вход. Но со временем появляются костыли, быстрофиксы, новые параметры, и где-то все равно появляется нефильтрованный ввод.
Это, конечно, к организации кода вопрос, но в жизни часто бывает как-то так :).
Просто было странно читать такое про девелоперов от «главного безопасника QIWI», надеюсь он это не про нынешних своих коллег.
Кавычка в инпуте это совсем детство. Проблемы обычно не из-за этого.
Получил url http://example.com/%s — проверил, валидный, ок, отправил в сервис, который передаст его другому сервису, который через год воспримет его как format string. Всё проверить, предусмотреть, обложить тестами — это очень сложно, потому что часто разработчик даже не знает, из какого компонента системы запрос возник, через что прошёл, кто и чем его проверил, как и где будет обрабатываться через год, когда накрутят функционала в 5 раз больше чем сейчас. Как видим, с этим не справляется ни яндекс, ни гугл — никто. Дело, конечно, в голове, да, но это уже голова не одного человека, а с одновременным представлением работы системы в целом и каждого компонента в частности есть проблемы: в голову всё не влезает.
Такие проблемы оттого что не договорились / не знали / не придали значения / не так поняли, поэтому валидация скорее всего не поможет. Я что пытаюсь донести: "просто очистить" можно, когда знания о системе укладываются в голове (вот текст инпута, вот база, положи одно в другое — да, предельно просто). Когда связей настолько много, что вызовы могут приходить из компонента, спроектированного удалённой командой, а уходить, пройдя через несколько сторонних решений — их не так просто очистить, надо многое держать в голове.
Самый простой способ засекьюрить инпут в типовом проекте (QIWI — не типовой проект!) — просто централизовать ввод, и прямо на уровне middleware проверять инпут по базе регулярок. Чуть что — бросать 400 код, и привет. Так, чтобы до типа-контроллера не долетало. Это если у нас есть какое-то подобие MVC и фреймворка, но без них тоже написать несложно)
Вот эти телодвижения выше круто работают, когда у тебя есть время и возможность делать хотя бы базовую секурити. А когда «надо срочно добавить поле «Описание» на сайт и еще там в корзине верстка разъезжается», вот тут не работает. Задача сделать быстро и чтобы работало. У типового программиста элементарно нет времени (и привычки!) думать о каком-то инпуте. Разве что, фреймворк подумает.
Я не говорю, что это нормальный и правильный подход, я говорю, что в небольших проектах так бывает. А небольшой проект !== нет денег.
В качестве примера можно противопоставить «чистить данные перед отправкой в sql» (не работает) и «использовать параметризованные запросы» (работает). Дальше, я надеюсь, уже нагуглятся подробности, ну и плюс по остальным темам. Азы как бы.
Чисто по-человечески — рекомендую слова «чистить» и «фильтрация» не употреблять.
И при этом они пишут сайты на php. Да.
*Нам уже известно* --> В этот момент обычно добавляют в вотчеры к первичному репорту.
Кидай тикеты в личку, посмотрю что там такое.
Или телеграм — @isox_xx
По форуму: как только так и сразу, после нового сайта. Мы выкатимся сразу с новым движком и дизом. Сейчас допиливаем верстку и тюним кеши. Текущая CMS — это тихий ужас, полностью согласен, но, увы, были причины сделать так в свое время. Все понимаем, и работаем в этом направлении. Ждать осталось совсем недолго)
А если без шуток, все от материала зависит. Это интервью с веселым и «живым» человеком, делать из его речи нудятину было бы просто кощунственно, поэтому постарались передать.
Откройте для себя уже netns. Вешать роуты триггером на VPN — последнее дело.
В техническом плане — возможно, в остальном — не факт.
У «блеков» и «вайтов» изначально разные цели. И скилы у них немного различаются. У «блека» главная цель — денежная прибыль. И тут задействуются не столько технические знания, сколько хитрость, умение обманывать, социальная инженерия вообщем. Умение рубить бабло и есть основной скилл «блеков». Остальное их не волнует.
«вайты» могут иметь больше технических знаний, так как, работают за саму идею ИБ и как следствие питают бОльший интерес к изучению программного обеспечения, поиска уязвимостей, реверсинге.
Коротко говоря, у одних цель — деньги, у других — изучение программного обеспечения и его защита. Совершенно разные цели. Как следствие — разные деньги.
Это если сравнивать среднестатического блека и вайта. А так думаю с обоих сторон есть люди, для которых их дело — это работа, хобби, да и вообще смысл жизни. И они наиболее развиты в своем любимом деле.
имхо.
Да уж условный плюс, предположим, что хакера поймали, а 10млн $ не нашли, а на поиски потратили 9 999 999 $, итого совокупный убыток
19 999 999 $ и где тут ТС увидел условный плюс непонятно, больше смахивает на что-то, из серии что больше весит килограмм металла или килограмм ваты? :)
Вот, например, d0znpp. У него недавно было время, он пошел и поломал чайник. Он теперь у нас главный хакер по взлому чайников, холодильников и другого IoT.Пошёл в хабраюзерский профиль в надежде, что встречу какую-нибудь блогозапись с подробностями об этом. Не нашёл. Зато выпал в осадок от увиденного женского срача на oxod.ru
К счастью есть whoishistory.ru, который подтвердил догадку, что у домена просто новый хозяин
Там оригинальный контент часто на китайском, поэтому парсер сходит с ума :(
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
Кирилл «isox» Ермаков, главный безопасник QIWI, рассказывает о своей работе, о блеке, об анонимности и о взрослой ИБ