Есть куча вещей, которые вы можете сделать.В произвольном порядке ...
Во-первых, если ваш выбор языка поровну (или близок к поровну) между тем, который обеспечивает прямой доступ к памяти, и тем, который нет, выберите тот, который не имеет,То есть используйте Perl, Python, Lisp, Java и т. Д. Поверх C / C ++.Это не всегда вариант, но он помогает вам не выстрелить себе в ногу.
Во-вторых, на языках, где у вас есть прямой доступ к памяти, если доступны классы, которые обрабатывают память для вас, например,std :: string, используйте их.Предпочитайте хорошо выполненные занятия тем классам, в которых меньше пользователей.Более широкое использование означает, что более простые проблемы с большей вероятностью обнаруживаются при регулярном использовании.
В-третьих, используйте параметры компилятора, такие как ASLR и DEP.Используйте любые параметры компиляции, связанные с безопасностью, которые предлагает ваше приложение.Это не предотвратит переполнения буфера, но поможет смягчить последствия любых переполнений.
В-четвертых, используйте инструменты статического анализа кода, такие как Fortify, Qualys или сервис Veracode, чтобы обнаружить переполнения, которые вы не хотели кодировать.,Затем исправьте обнаруженный материал.
В-пятых, узнайте, как работают переполнения и как их обнаружить в коде.Все ваши коллеги тоже должны этому научиться.Создайте общеорганизационную политику, которая требует, чтобы люди были обучены тому, как работают переполнения (и другие уязвимости).
В-шестых, проверяйте код безопасности отдельно от регулярных проверок кода.Регулярные проверки кода позволяют убедиться, что код работает, проходит функциональные тесты и соответствует политике кодирования (отступы, соглашения об именах и т. Д.).Обзоры безопасного кода специально, в явном виде и предназначены только для поиска проблем безопасности.Делайте безопасные проверки кода на весь код, который вы можете.Если вам нужно расставить приоритеты, начните с критически важных вещей, вещей, где вероятны проблемы (где пересекаются границы доверия (узнайте о диаграммах потоков данных и моделях угроз и создайте их), где используются интерпретаторы, и особенно, когда вводится пользовательский ввод /сохраненные / извлеченные, включая данные, извлеченные из вашей базы данных).
В-седьмых, если у вас есть деньги, наймите хорошего консультанта, такого как Neohapsis, VSR, Matasano и т. д., чтобы проверить ваш продукт.Они найдут гораздо больше, чем просто переполнения, и ваш продукт будет для них лучше.
В-восьмых, убедитесь, что ваша команда QA знает, как работают переполнения и как их тестировать.В QA должны быть тестовые наборы, специально предназначенные для обнаружения переполнений во всех входах.Fuzzing обнаруживает удивительно большое количество переполнений во многих продуктах.
Отредактировано, чтобы добавить: Я неправильно понял вопрос.Название гласит: «Каковы методы», а текст говорит: «Почему это сложно?»
Трудно, потому что так легко ошибиться.Небольшие ошибки, такие как отдельные ошибки или числовые преобразования, могут привести к переполнению.Программы - сложные звуки, со сложными взаимодействиями.Там, где есть сложности, есть проблемы.
Или, чтобы снова ответить на вопрос: почему так сложно писать код без ошибок?