АК-ВС 3 | Анализатор кода

✖️CWE добрался до AI AI/ML всё чаще становится частью ПО. Модель может распознавать изображение, генерировать текст, помогать пользователю, анализировать данные или участвовать в принятии решения. Теперь это появилось и в CWE. В версии CWE 4.20 добавили три элемента, связанные с AI/ML. 〰️CWE-1446 Категория недостатков, специфичных для AI/ML-технологий. В неё входят недостатки, которые возникают при интеграции AI/ML-компонента в продукт. Например, приложение вызывает AI/ML-модель и недостаточно проверяет её ответ. Или строит промт из внешних данных так, что модель начинает путать пользовательский ввод и системные инструкции. Ещё один пример - настройки работы модели подобраны так, что она слишком часто выдаёт ошибочные или неожиданные результаты. 〰️ CWE-1447 Категория общих программных недостатков, которые могут встречаться в продуктах с AI/ML. Здесь собраны обычные недостатки, которые остаются актуальными при использовании AI/ML-компонентов. Например, если AI-компонент может работать с файлами, становится актуален CWE-22 Path Traversal. Если он может формировать команды или запускать действия во внешней системе, становится актуален CWE-78 Command Injection. 〰️ CWE-1448 Представление недостатков, связанных с AI/ML-продуктами. Представляет собой граф, который объединяет две группы: 1) Специфичные для AI/ML недостатки. 2) обычные недостатки, которые часто встречаются в продуктах с AI/ML. Таким образом, CWE-1446, CWE-1447 и CWE-1448 помогают сгруппировать недостатки, связанные с AI/ML, и найти более точное описание нужного дефекта. 😎AI/ML становится частью продукта, а значит становится частью его безопасности.

Почему временные файлы могут быть опасны?🤔

➡️Исправление требует проверки Нашли уязвимость, внесли правку, закрыли задачу. На этом как будто можно поставить точку. Но на практике такой подход часто оказывается слишком поверхностным. Исправление само по себе еще не гарантирует, что уязвимость действительно устранена. Поэтому после изменения кода важно провести повторные проверки. Причин для этого несколько. ✔️Исправление не всегда решает проблему полностью. Иногда уязвимость закрывают точечно, но не проверяют, используется ли тот же небезопасный подход в других частях проекта. А иногда после изменения кода появляются новые уязвимости, например, в проверке прав, обработке ошибок или бизнес-логике приложения. Поэтому повторная проверка после исправления нужна не только для формальности. Она отвечает сразу на несколько важных вопросов. 〰️Уязвимость точно устранена? 〰️Исправление не привело к новым дефектам? 〰️Продукт после изменений работает так, как должен? 👍Именно поэтому в зрелой разработке ценится не только факт исправления, но и подтверждение его результата. 😎Исправить - это только половина работы. Вторая половина - убедиться, что исправлено действительно то, что нужно, и так, как нужно.

➡️Чем позже найдена уязвимость, тем выше цена

Почему JavaScript называется JavaScript Из-за названия легко подумать, что JavaScript тесно связан с Java. 🤯Но это имя появилось не из-за технического сходства, а во многом из-за популярности бренда Java в середине 90-х. Язык появился в 1995 году в компании Netscape, которая разрабатывала браузер Netscape Navigator - один из самых известных браузеров того времени. Его создавали для сценариев внутри веб-страниц, чтобы страницы в браузере могли реагировать на действия пользователя. Сначала язык назывался Mocha, потом LiveScript, и только затем стал JavaScript. 📝Почему его переименовали именно так? Потому что в тот момент Java быстро набирала популярность, и имя Java уже хорошо привлекало внимание. Для нового языка это было удобное название с точки зрения продвижения. Название JavaScript появилось не случайно. Компания Sun, которой принадлежало имя Java, разрешила Netscape использовать его для нового языка. 🔥Получается интересная ситуация. Язык получил имя, которое помогло ему быстро стать заметным, но заодно запутало много людей. 😎Пожалуй, это один из самых удачных маркетинговых ходов в истории IT. И один из самых запутывающих тоже.

➡️Имя файла — это тоже часть безопасности

➡️Приведение типов и ошибки в логике После приведения типа значение может измениться не так, как ожидает разработчик. В результате проверка в коде начинает работать неправильно. 🧷 Например:

int x = -1;
unsigned int y = x;

if (y > 0) {
    printf("positive\n");
}

📝 Что здесь произошло? x содержит -1. При приведении к беззнаковому типу (unsigned int) это значение преобразуется так, что то же двоичное представление начинает соответствовать большому положительному числу. В итоге условие y > 0 окажется истинным, хотя исходное значение было отрицательным. 🔺Чем это опасно: 1. проверка начинает давать неверный результат 2. код заходит не в ту ветку Из-за этого можно пропустить ошибку или неправильно обработать данные Чаще всего такие проблемы возникают при работе: 〰️со знаковыми и беззнаковыми типами 〰️с целыми и вещественными числами 〰️с типами разного размера ✔️Как этого избежать: 〰️не приводить тип без необходимости 〰️перед приведением проверять, входит ли значение в целевой диапазон, особенно для отрицательных, больших и граничных значений 〰️включать предупреждения компилятора, связанные с приведением типов 😎Приведение типа может изменить значение сильнее, чем кажется на первый взгляд.

➡️Почему ограничения на клиенте не считаются полноценной защитой? Может показаться, что если нужная проверка уже есть на клиенте, то этого достаточно. Например: 〰️нельзя ввести больше 20 символов 〰️нельзя загрузить файл больше 5 МБ 〰️нельзя выбрать произвольное значение параметра 〰️кнопка опасного действия скрыта или недоступна 🔺Но клиентская часть приложения находится под контролем пользователя, поэтому полагаться только на проверки на этой стороне нельзя. Такие ограничения можно обойти: 〰️прямой отправкой запроса в обход интерфейса 〰️отключением или изменением клиентской логики проверки 〰️использованием инструментов вроде curl или Burp Suite Поэтому проверки на клиенте полезны для удобства и помогают избежать случайных ошибок, но не должны быть единственным механизмом защиты. Если проверка выполняется только на клиенте, на сервер всё равно могут попасть некорректные, недопустимые или вовсе опасные данные. На практике действует простое правило: 〰️на клиенте проверки делают для удобства 〰️на сервере проверки делают для безопасности ✔️Вывод Ограничения на клиенте - это не полноценная защита, а лишь вспомогательная проверка. Всё, что важно для безопасности, должно проверяться на сервере.

Почему случайное число не меняется?

➡️IDOR - чужие данные по ID Иногда доступ к объекту зависит от одного идентификатора. Например, есть ссылка /order/1642 по которой пользователь открывает свой заказ. Потом он меняет 1642 на 1643 и вдруг видит уже чужой. 🔺Проблема в том, что идентификатор оказался слишком предсказуемым, а проверка доступа недостаточной или вовсе отсутствующей. Предсказуемые идентификаторы упрощают перебор и открывают доступ к чужим данным. Чаще всего так получают доступ к: 〰️профилям пользователей 〰️заказам 〰️документам 〰️счетам 〰️заявкам Но здесь есть важный момент. Даже если вместо 1642 использовать более сложный и менее очевидный идентификатор, проблема не исчезает. ✔️Безопасность здесь зависит не от того, насколько сложно угадать идентификатор, а в первую очередь от проверки прав доступа к объекту. Если сервер смотрит только на то, существует ли объект, но не проверяет, кто именно запрашивает доступ, этого уже достаточно для инцидента. Поэтому, если система принимает идентификаторы объектов из запроса, стоит проверить: 〰️можно ли перебирать идентификаторы объектов 〰️есть ли для каждого запроса проверка доступа к нужному объекту 😎Иногда хорошая проверка начинается с простого вопроса: "Что произойдет, если просто поменять ID в запросе?"