
Обычно мы не пишем заметки про выход новой версии анализатора PVS-Studio. Однако в новый релиз вошло много интересных изменений, касающихся анализа C и C++ кода, о которых хочется рассказать нашим пользователям.
Читать полностью »
Сейчас все больше говорят о статическом анализе для поиска уязвимостей как необходимом этапе разработки. Однако многие говорят и о проблемах статического анализа. Об этом много говорили на прошлом Positive Hack Days, и по итогам этих дискуссий мы уже писали о том, как устроен статический анализатор. Если вы пробовали какой-нибудь серьезный инструмент, вас могли отпугнуть длинные отчеты с запутанными рекомендациями, сложности настройки инструмента и ложные срабатывания. Так все-таки нужен ли статический анализ?
Наш опыт подсказывает, что нужен. И многие проблемы, которые возникают при первом взгляде на инструмент, вполне можно решить. Попробую рассказать, что может делать пользователь и каким должен быть анализатор, чтобы его использование было полезным, а не вносило «еще один ненужный инструмент, который требуют безопасники».


Изучая предупреждения анализатора PVS-Studio в процессе проверки различных открытых проектов, мы вновь и вновь убеждаемся, сколь полезен может быть этот инструмент. Анализатор кода невероятно внимателен и никогда не устаёт. Он указывает на ошибки, которые ускользают даже при внимательном обзоре кода. Рассмотрим очередной такой случай.
Читать полностью »
Наша команда проверяет различные открытые проекты с помощью PVS-Studio и пишет о результатах анализа кода. Время от времени мы сталкиваемся со странными обвинениями в предвзятости. Думаем, что часто это «тролли», и вступать в дискуссии с ними не имеет смысла. С другой стороны, оставлять подобные комментарии совсем без ответа тоже не хочется. Поэтому я решил написать небольшую статью, чтобы иметь возможность отвечать одной ссылкой.


Разработка больших сложных проектов невозможна без использования методологий программирования и инструментальных средств, помогающих контролировать качество кода. В первую очередь, это грамотный стандарт кодирования, обзоры кода, юнит-тесты, статические и динамические анализаторы кода. Всё это помогает выявлять дефекты в коде на самых ранних этапах разработки. В этой статье демонстрируются возможности статического анализатора PVS-Studio по выявлению ошибок и потенциальных уязвимостей в коде операционной системы Android. Надеемся, что статья привлечёт внимание читателей к методологии статического анализа кода и они захотят внедрить её в процесс разработки собственных проектов.
Читать полностью »

До недавнего времени в своих статьях мы позиционировали PVS-Studio как инструмент для выявления ошибок в коде. При этом мы почти не рассматривали PVS-Studio в контексте безопасности. Попробуем немного исправить эту ситуацию и взглянем на инструмент с точки зрения тестирования защищённости приложений и DevSecOps практик.
Читать полностью »
Одна из самых популярных тенденций в области защиты приложений нынешнего десятилетия — технология виртуального патчинга (virtual patching, VP), позволяющая защитить веб-приложение от эксплуатации имеющихся в нем известных уязвимостей на уровне межсетевого экрана уровня веб-приложений (web application firewall; здесь и далее под WAF подразумевается выделенное решение, функционирующее на отдельном узле, между шлюзом во внешнюю сеть и веб-сервером). Технология VP основана на построении правил фильтрации HTTP-запросов на стороне WAF по результатам работы средств статического анализа защищенности приложения (static application security testing, SAST). Однако из-за того, что средства SAST и WAF опираются на различные модели представления приложения и различные методы принятия решений, на рынке до сих пор нет по-настоящему эффективных решений их интеграции. В рамках SAST работа с приложением осуществляется по модели белого ящика и, как правило, используются формальные подходы к поиску уязвимостей в коде. Для WAF же приложение представляет собой черный ящик, а для детектирования атак применяются эвристики. Это не позволяет эффективно использовать VP для защиты от атак в тех случаях, когда условия эксплуатации уязвимости выходят за рамки тривиальной схемы `http_parameter=plain_text_attack_vector`.
Но что, если «подружить» SAST и WAF таким образом, чтобы информация о внутреннем устройстве приложения, полученная с помощью SAST, стала доступной на стороне WAF и дала ему возможность детектировать атаки на обнаруженные уязвимости — не угадывая, но доказывая факт атаки?
Читать полностью »
Почему в случае JavaScript приходится обходиться простыми подходами статического анализа, когда есть более интересные подходы к автоматическому анализу кода?
В ответ на этот вопрос, мой коллега Алексей Гончаров kukumumu ответил лаконично: «Java Script это панковский язык» и кинул ссылку на статью Jasper Cashmore «A Javascript journey with only six characters», которая действительно погружает нас в путешествие в эзотерический мир JSFuck и сразу все ставит на свои места.
Мне настолько понравилось, что я решил перевести статью на русский язык.
Читать полностью »
Привет!

Эта статья станет вступительной в моем небольшом цикле заметок, посвященном такой технике анализа программ, как pointer analysis. Алгоритмы pointer analysis позволяют с заданной точностью определить на какие участки памяти переменная или некоторое выражение может указывать. Без знания информации об указателях анализ программ, активно использующих указатели (то есть программ на любом современном языке программирования — C, C++, C#, Java, Python и других), практически невозможен. Поэтому в любом мало-мальски оптимизируещем компиляторе или серьезном статическом анализаторе кода применяются техники pointer analysis для достижения точных результатов.
В данном цикле статей мы сосредоточимся на написании эффективного межпроцедурного алгоритма pointer analysis, рассмотрим основные современные подходы к задаче, ну и, конечно же, напишем свой очень серьезный алгоритм pointer analysis для замечательного языка внутреннего представления программ LLVM. Всех интересующихся прошу под кат, будем анализировать программы и многое другое!
Читать полностью »
В определенный момент в жизни почти каждой финтех-компании настает время, когда количество приложений внутренней разработки начинает превышать число разработчиков, бизнес хочет больше новых фич, а на Bug Bounty продолжают сдавать все новые и новые уязвимости…
Но при этом есть потребность быстро выпускать качественное и безопасное ПО, а не тушить пожары от выявленных ошибок безопасности откатами версий и ночными хотфиксами.
Когда команда ИБ состоит из пары человек, кажется, что так будет всегда, но мы решили выжать из ситуации максимум позитива и раз и навсегда "засекьюрить" свои приложения.
С чего начать? Наш план был прост: