Блог

Извините за очень широкий вопрос, но у нас есть некоторые проблемы, например, Checkmarx жалуется на внедрение кода примерно следующим образом

 $accesskey = $_GET['accesskey'] ?? $argv[1] ?? null;
if (!$accesskey || !ctype_alnum($accesskey)) {
    throw new RuntimeException(sprintf('Passed accesskey "%s" is invalid', $accesskey));
}

$commandParts = ['echo', $accesskey]
$commandParts = array_map('escapeshellarg', $commandParts);
$command = implode(' ', $commandParts);
$command = escapeshellcmd($command);
system($command);
 

Я думаю, что команды экранируются, и все в порядке, но почему Checkmarx думает иначе?

Метод <?php приложения вызывает команду операционной системы (оболочки) с system в строке 1 ОТРЕДАКТИРОВАНО, используя ненадежную строку с командой для выполнения.

Это может позволить злоумышленнику ввести произвольную команду и включить атаку с использованием командной строки.

Злоумышленник может ввести выполняемую команду через пользовательский ввод, _GET, который извлекается приложением в методе <?php, в строке 1 ОТРЕДАКТИРОВАННОГО.

Мне также интересно, может ли и как Checkmarx понимать код библиотеки или фреймворка, который устанавливается через Composer? Например.

 Assert::oneOf($unsafeUserInput, ['foo', 'bar']); // throws an Exception if $unsafeUserInput is not 'foo' or 'bar'
// $unsafeUserInput is now safe
 

или материалы, связанные с WP, которые также часто ошибочно помечаются как подверженные SQL-инъекциям

 global $wpdb;

$foo = $wpdb->getVar($wpdb->prepare('SELECT foo FROM bar WHERE baz = %s', $_GET['baz'] ?? ''));
 

Если он проверяет методы дезинфекции, есть ли какой-то конкретный способ, которым они должны выглядеть? Я, честно говоря, хочу избежать изменения слишком большого количества кода для Checkmarx.

Ваш вопрос о том, насколько хорошо Checkmarx анализирует PHP-код, может склоняться к субъективному ответу, и ваше восприятие инструмента может быть предвзятым, учитывая, что вы используете методы (escapeshellcmd), которые не распознаются как дезинфицирующие средства, а фреймворк, о котором вы спрашиваете (WordPress и Composer), технически не поддерживается.

Справедливости ради следует отметить, что Checkmarx поддерживает различные фреймворки PHP, такие как Zend, Kohana, CakePHP, Symfony и Smarty, что может привести к меньшим ложным срабатываниям (примечание: я не предлагаю вам переключать платформы)

Для эффективной работы любым статическим анализаторам потребуется помощь ИТ-пользователей. Я бы посоветовал вам исключить файлы Composer из проверки.

На самом деле вам не нужно вносить изменения в код и просто спорить со своей командой AppSec о том, что эти результаты являются ложными срабатываниями, поскольку метод prepare предотвращает атаки SQL-инъекций и что escapeshellcmd кодирует строку. Однако я рекомендую вместо этого использовать escapeshellarg для $accesskey