Поиск уязвимостей в байткоде Java: что делать с результатами?

[Regis]

Не совсем понял о поиске какого класса уязвимостей в статье идет речь.

[yaleksar]

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

У нас обнаруживаются уязвимости типа «внедрение» (SQL Injection, XSS, Path traversal и так далее), вызовы небезопасных функций (например, хеширования и шифрования), другие шаблонные небезопасные конструкции (например, отключение проверки сертификатов с помощью X509TrustManager), участки, подозрительные на НДВ (или закладки) — всего более 150 различных уязвимостей для языка Java.

[vilgeforce]

В чем небезопасность функций хэширования или шифрования?

[yaleksar]

Я не совсем точно выразился в предыдущем комментарии. Уязвимостью является использование небезопасных функций хеширования и шифрования (типа MD5 или DES) для работы с критичными данными (конфиденциальными данными, для генерации идентифицирующих значений).

[vilgeforce]

При этом, я уверен, у вас не отслеживается использование самописных кривых алгоритмов генерации ключей, хэширования или шифрования. И сразу виден сценарий: меняем относительно стойкий DES на XOR строкой из 2 байт и предупреждение уходит, значит код нормальный :-)

[yaleksar]

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

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

[vilgeforce]

Я, можно сказать, периодически наблюдаю как вместо стандартных небезопасных начинают городить самописное… Такие лапочки прямо! :-)