OS Command Injection [Command Execution]

1. Введение:

Инъекция команд ОС (также известная как shell-инъекция) - это уязвимость в веб-безопасности, позволяющая злоумышленнику выполнить произвольные команды операционной системы (ОС) на сервере, на котором запущено приложение, и, как правило, полностью скомпрометировать приложение и все его данные.

2. Типичный уязвимый код:

import os
import sys

file = sys.argv[1]

text = os.system("cat " +  file)
Инъекция команды в действии.

3. Смягчение последствий:

Вам также стоит потратить некоторое время на следующие страницы, поскольку защита от инъекций довольно схожа, независимо от того, с каким уязвимым вектором вы имеете дело.

SQL Injections [SQLi]XML External Entity Injection [XXE]

3.1. Избегайте прямого вызова команд ОС:

Основной защитой в случае инъекции команд ОС является использование встроенных функций, поскольку ими нельзя манипулировать для выполнения какой-либо вредоносной задачи. Вот пример:

Вместо того чтобы использовать os.system("mkdir " + dir_name), мы должны использовать ее альтернативу - os.mkdir(dir_name)

3.2. Экранирование аргументов команд ОС:

Экранируя пользовательский ввод, мы можем убедиться, что капсулируем его в более безопасный формат для выполнения командой os.system. Поскольку экранирование пользовательского ввода должно использоваться поверх уже существующего защитного механизма, рекомендуется избегать использования команд ОС напрямую.

Пример экранирования команд ОС показан в PHP-функции escapeshellarg. Здесь функция добавляет одинарные кавычки вокруг строки и кавычки/эскейп всех существующих одинарных кавычек, что позволяет передавать строку непосредственно в функцию shell и рассматривать ее как единственный безопасный аргумент.

<?php

    system('ls '.escapeshellarg($dir));

?>

3.3. Параметризация с проверкой вводимых данных:

Если вызов команд os на пользовательский ввод неизбежен (хотя это почти всегда так), разработчик может использовать следующие два защитных уровня. Как уже говорилось в разделе SQLi, можно защитить свою конечную точку с помощью:

  1. Параметризация: Если есть возможность, используйте структурированные механизмы, которые автоматически обеспечивают разделение между данными и командами. Эти механизмы могут помочь обеспечить соответствующее цитирование и кодирование.

  2. Проверка ввода: Значения команд и соответствующих аргументов должны быть проверены. Существуют различные степени проверки для фактической команды и ее аргументов:

  • Что касается используемых команд, то они должны быть проверены на соответствие списку разрешенных команд.

  • Что касается аргументов, используемых для этих команд, то они должны быть проверены с помощью следующих опций: 1. Положительная или разрешенная проверка ввода списка: Где явно определены разрешенные аргументы. 2. Список разрешений регулярных выражений: Здесь задается список безопасных, разрешенных символов и максимальная длина строки. Убедитесь, что метасимволы, такие как:

& |  ; $ > < ` \ !

и пробелы не являются частью регулярного выражения. Например, следующее регулярное выражение допускает только строчные буквы и цифры и не содержит метасимволов. Длина также ограничена 3-10 символами: ^[a-z0-9]{3,10}$

3.4. Дополнительные средства защиты:

Помимо основных средств защиты, параметризации и проверки ввода, рекомендуется также использовать все эти дополнительные средства защиты:

  • Приложения должны работать с минимальными привилегиями, необходимыми для выполнения необходимых задач.

  • По возможности создавайте изолированные учетные записи с ограниченными привилегиями, которые используются только для выполнения одной задачи.

4. Выводы:

Избегание прямого вызова команд ОС - это очевидный первый шаг к защите от инъекций команд. Как уже стало стандартом, при работе с пользовательским вводом разработчик всегда должен позаботиться о его экранировании, а также проверке.

Last updated