Изучение распространенных проблем с безопасностью кода

  • 11 мин

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

Зачем сосредоточиться на проблемах безопасности?

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

  • Нарушения данных: уязвимость конфиденциальных клиентов или бизнес-данных.
  • Финансовые потери: прямые расходы от нарушений, нормативных штрафов и расходов на исправление.
  • Ущерб репутации: потеря доверия клиентов и доверия к бизнесу.
  • Операционные нарушения: системные компрометации могут остановить бизнес-операции.

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

Open Web Application Security Project (OWASP)

Проект безопасности веб-приложений (OWASP) — это некоммерческая организация, ориентированная на повышение безопасности программного обеспечения. OWASP поддерживает широко признанный "OWASP Top 10" - регулярно обновляемый список наиболее критически важных рисков безопасности веб-приложений на основе данных от организаций безопасности по всему миру.

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

  • 2017 OWASP Top 10: Уязвимости инъекций заняли первое место.
  • 2021 OWASP Top 10: инъекция переместилась на 3-е место, поскольку возникли новые угрозы, такие как нарушение управления доступом.

OWASP Топ-10 отражает данные об атаках в реальном мире, а не теоретические вопросы. Уязвимости кода, такие как SQL-инъекция и слабое шифрование, неизменно занимают высокие позиции среди наиболее серьёзных отраслевых проблем безопасности.

Атаки внедрения

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

Внедрение SQL

Внедрение SQL является одним из самых опасных и распространенных атак внедрения. Это происходит, когда приложение включает ненадежные входные данные непосредственно в запросы SQL без надлежащей проверки или параметризации.

Рассмотрим следующий пример кода.

// DANGEROUS: Concatenating user input directly into SQL
string query = "SELECT * FROM Users WHERE Username = '" + userInput + "' AND Password = '" + passwordInput + "'";
SqlCommand command = new SqlCommand(query, connection);
SqlDataReader reader = command.ExecuteReader();

Злоумышленник может ввести ' OR '1'='1 в качестве входных данных имени пользователя, преобразуя запрос в:

SELECT * FROM Users WHERE Username = '' OR '1'='1' AND Password = ''

Так как '1'='1' всегда верно, этот запрос возвращает всех пользователей, обходя проверку подлинности полностью.

Реальные эффекты

Атаки типа SQL-инъекция привели к многочисленным громким утечкам. Злоумышленники могут:

  • Обход механизмов проверки подлинности.
  • Извлеките все базы данных, содержащие конфиденциальную информацию.
  • Изменение или удаление данных.
  • Выполнение административных операций в базе данных.

Безопасная реализация

Безопасный способ обработки запросов SQL — использовать параметризованные запросы (также называемые подготовленными выражениями).

Рассмотрим пример.

// SECURE: Using parameterized queries
string query = "SELECT * FROM Users WHERE Username = @username AND Password = @password";
SqlCommand command = new SqlCommand(query, connection);
command.Parameters.AddWithValue("@username", userInput);
command.Parameters.AddWithValue("@password", passwordInput);
SqlDataReader reader = command.ExecuteReader();

Параметризованные запросы отделяют код от данных. База данных обрабатывает значения параметров только как данные, никогда не как исполняемый код SQL, предотвращая атаки на внедрение.

Другие типы внедрения

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

Хотя внедрение SQL является наиболее распространенным, существуют другие уязвимости внедрения:

  • Внедрение команд: вставка системных команд в входные данные приложения, выполняющие команды оболочки.
  • Внедрение протокола LDAP: управление запросами LDAP для доступа к неавторизованным данным каталога.
  • Внедрение NoSQL: использование баз данных NoSQL с помощью вредоносных запросов.
  • Внедрение XML: вставка вредоносного XML-содержимого для доступа или изменения данных.

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

Слабое шифрование конфиденциальных данных

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

Небезопасное хранилище паролей

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

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

Хранение незашифрованного текста (неприемлемо)

// DANGEROUS: Storing passwords in plaintext
string password = userInput;
database.SavePassword(username, password);

Если база данных скомпрометирована, все пароли пользователей немедленно предоставляются.

Слабое хэширование (недостаточное)

// INSUFFICIENT: Using MD5 or SHA1 without salt
using (MD5 md5 = MD5.Create())
{
    byte[] hash = md5.ComputeHash(Encoding.UTF8.GetBytes(password));
    string hashedPassword = Convert.ToBase64String(hash);
}

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

// SECURE: Using bcrypt with automatic salt generation
string hashedPassword = BCrypt.Net.BCrypt.HashPassword(password);

// Later, for verification:
bool isValid = BCrypt.Net.BCrypt.Verify(userInput, storedHash);

Для безопасного хэширования паролей требуется:

  • Соль: случайные данные, добавляемые к паролям перед хешированием, предотвращая атаки с использованием радужных таблиц.
  • Медленный алгоритм: функции, такие как bcrypt, scrypt или Argon2, требуют значительных вычислительных ресурсов, ограничивая попытки до сотен или тысяч в секунду вместо миллиардов.

Шифрование неактивных данных

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

Конфиденциальные данные, хранящиеся без шифрования, уязвимы, если носитель хранения скомпрометирован.

Уязвимый сценарий

// VULNERABLE: Writing sensitive data in plaintext
File.WriteAllText("customer_data.txt", sensitiveInformation);

Если ноутбук, содержащий этот файл, украден или злоумышленник получает доступ к файловой системе, данные немедленно читаются.

Безопасный подход

// SECURE: Encrypting data before storage
using (Aes aes = Aes.Create())
{
    aes.Key = GetEncryptionKey(); // Securely managed key
    aes.GenerateIV();
    
    using (FileStream fileStream = new FileStream("customer_data.enc", FileMode.Create))
    {
        fileStream.Write(aes.IV, 0, aes.IV.Length);
        using (CryptoStream cryptoStream = new CryptoStream(fileStream, aes.CreateEncryptor(), CryptoStreamMode.Write))
        using (StreamWriter writer = new StreamWriter(cryptoStream))
        {
            writer.Write(sensitiveInformation);
        }
    }
}

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

Проблемы с ведением журнала и обработкой ошибок

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

Ведение журнала конфиденциальных данных

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

Приложения никогда не должны регистрируют конфиденциальную информацию в виде открытого текста.

Опасные методы логирования

// DANGEROUS: Logging sensitive information
logger.LogInformation($"User {username} logged in with password: {password}");
logger.LogInformation($"Credit card processed: {cardNumber}");
logger.LogInformation($"API Key: {apiKey}");

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

Методы безопасного ведения журнала

// SECURE: Logging without sensitive data
logger.LogInformation($"User {username} logged in successfully");
logger.LogInformation($"Payment processed for order {orderId}");
logger.LogInformation($"API call authenticated successfully");

Лучшие практики

  • Никогда не регистрируют пароли, маркеры проверки подлинности или ключи API.
  • Маскирует или редактирует конфиденциальную информацию, например номера кредитных карт или номера социального страхования.
  • Журнал событий и результатов, а не конфиденциальных значений данных.

Чрезмерное раскрытие сведений об ошибках

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

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

Проблематичная обработка ошибок

// PROBLEMATIC: Exposing detailed error information to users
catch (Exception ex)
{
    return $"Error: {ex.Message}\nStack Trace: {ex.StackTrace}\nConnection String: {connectionString}";
}

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

Безопасная обработка ошибок

// SECURE: User-friendly messages with detailed internal logging
catch (Exception ex)
{
    logger.LogError(ex, "Failed to process user request");
    return "An error occurred while processing your request. Please try again or contact support.";
}

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

Атаки обхода пути

Обход пути (также называемый обходом каталога) возникает, когда приложение использует предоставленные пользователем входные данные для создания путей к файлам без надлежащей проверки. Злоумышленники могут использовать специальные последовательности символов для доступа к файлам за пределами предполагаемого каталога.

Рассмотрим следующий уязвимый код:

// VULNERABLE: Using user input directly in file paths
string filename = Request.Query["file"];
string filePath = Path.Combine(@"C:\uploads\", filename);
string content = File.ReadAllText(filePath);

Злоумышленник может предоставить входные данные, такие как ../../../Windows/System32/config/SAM доступ к конфиденциальным системным файлам или ../../web.config чтение конфигурации приложения, содержащей секреты.

Уязвимый код включает следующий механизм атаки:

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

Рассмотрим следующую безопасную реализацию:

// SECURE: Validating and constraining file paths
string filename = Request.Query["file"];

// Remove path traversal sequences
filename = Path.GetFileName(filename);

// Construct full path
string uploadsDirectory = Path.GetFullPath(@"C:\uploads\");
string filePath = Path.GetFullPath(Path.Combine(uploadsDirectory, filename));

// Verify the resulting path is still within the uploads directory
if (!filePath.StartsWith(uploadsDirectory))
{
    throw new SecurityException("Invalid file path");
}

string content = File.ReadAllText(filePath);

Безопасные реализации демонстрируют следующие стратегии защиты:

  • Используется Path.GetFileName() для удаления сведений о каталоге.
  • Разрешенный список разрешенных файлов или шаблонов вместо блокировки опасных символов.
  • Убедитесь, что разрешенные пути остаются в предназначенных каталогах.
  • Реализуйте строгие разрешения доступа к файлам на уровне операционной системы.

Прочие вопросы по безопасности

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

Межсайтовые скрипты (XSS)

Межсайтовые скрипты позволяют злоумышленникам внедрять вредоносный код в веб-приложения, потенциально компрометируя данные пользователей и сеансы.

Хотя это не применимо к консольным приложениям, веб-разработчики должны проверять и кодировать все входные данные пользователя перед отображением в браузерах.

Жестко закодированные секреты

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

Внедрение ключей API, паролей или маркеров непосредственно в исходном коде предоставляет их всем пользователям с доступом к репозиторию. Секреты должны быть:

  • Хранится в защищенных системах управления конфигурацией или ваултах.
  • Никогда не фиксируйте управление версиями.
  • Регулярно вращается.
  • Управление с помощью надлежащих механизмов управления доступом.

Исчерпание ресурсов и отказ в обслуживании

Злоумышленники часто используют приложения, которые неправильно управляют ресурсами. Атаки могут привести к сбоям службы или сбоям системы.

Плохое управление ресурсами может включать атаки типа "отказ в обслуживании". Вот некоторые примеры.

  • Чтение целых больших файлов в память (вызывающее ошибки недостатка памяти).
  • Не ограничивает размер запроса или частоту.
  • Неэффективные алгоритмы, использующие чрезмерный ЦП.
  • Неправильное удаление ресурсов.

Определение проблем безопасности в коде

Для выявления уязвимостей безопасности в коде требуется систематический подход.

Анализ обработки входных данных пользователей

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

Каждый момент, в котором код принимает входные данные пользователя, является потенциальной точкой входа для атак:

  • Ищите: входные данные, используемые в запросах SQL, пути к файлам, системные команды или критическая логика.
  • Спросите: "Я доверяю этому входу слишком много?"
  • Рассмотрим: уязвимости инъекции, траверсирование путей, инъекции команд.

Просмотр криптографических операций

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

Криптографический код требует специального контроля:

  • Найдите: MD5.Create(), SHA1.Create(), открытое хранилище паролей.
  • Спросите: "Считается ли этот криптографический метод защищенным?"
  • Рассмотрим: использование bcrypt, scrypt или Argon2 для паролей; SHA-256 или более поздней версии для проверок целостности.

Изучайте журнальные записи

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

Проверьте исходный код на наличие конфиденциальных данных в логах.

  • Найдите: записи журнала, содержащие переменные с именами password, secret, token, apiKey, cardNumber.
  • Спросите: "Какая информация раскрывается в журналах?"
  • Рассмотрим: что произойдет, если эти журналы будут скомпрометированы или случайно разглашены?

Проверка операций с файлами

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

Код обработки файлов требует тщательной проверки:

  • Найдите: Path.Combine с пользовательскими входными данными, операциями с файлами на основе предоставленных пользователем путей.
  • Спросите: "Может ли пользователь избежать предполагаемого каталога?"
  • Рассмотрим: атаки обхода путей и техники обхода каталогов.

Использование автоматизированных средств

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

Объединение проверки кода вручную с автоматизированным анализом:

  • Статический анализ: инструменты, такие как GitHub CodeQL, сканируют код на известные шаблоны уязвимостей.
  • GitHub Copilot: используйте режим ask для анализа разделов кода: "Существуют ли проблемы безопасности в этом коде?"
  • Линтеры безопасности: средства, специфичные для языка программирования, могут выявлять очевидные ошибки безопасности.

GitHub Copilot может определить множество распространенных проблем безопасности при запросе на анализ кода. Он опирается на шаблоны из миллионов баз кода для распознавания уязвимостей.

Проактивный подход к безопасности

Принцип "сдвиг влево" означает устранение безопасности ранее в жизненном цикле разработки:

  • Этап проектирования: рассмотрите последствия для безопасности архитектурных решений.
  • Этап разработки: написание безопасного кода с самого начала. Выявление проблем во время проверки кода.
  • Этап тестирования: включение тестирования безопасности вместе с функциональным тестированием.
  • Этап развертывания: проверка уязвимостей перед выпуском.

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

Сводка

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