Безопасное программирование [закрывается]

Подобный abyx, в команде я нахожусь на разработчиках, всегда используют поблочное тестирование и кодируют обзоры. В дополнение к этому я также стремлюсь удостоверяться, что я не включаю код, который могут использовать люди - я склонен писать код только для основного набора методов, требуемых для объекта под рукой функционировать, как был spec'd. Я нашел, что слияние методов, которые никогда не могут использоваться, но обеспечивают, функциональность может неумышленно представить "закулисное" или непреднамеренное/непредвиденное использование в систему.

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

Я рекомендовал бы быть защитным для данных, которые вводят "компонент" или платформу. В "компоненте" или платформе нужно думать, что данные "корректны".

Взгляды как это. Это до вызывающей стороны для предоставления корректных параметров иначе, ВСЕ функции и методы должны проверить каждый входящий параметр. Но если проверка только сделана для вызывающей стороны, проверка только необходима однажды. Так, параметр должен быть "корректным" и таким образом может быть передан до более низких уровней.

1. Всегда проверяйте данные из внешних источников, пользователи и т.д.
2. "Компонент" или платформа должны всегда проверять входящие вызовы.

Если существует ошибка, и неправильное значение используется в вызове. Какова действительно правильная вещь todo? Одно единственное имеет признак, что "данные", программа продолжает работать, являются неправильными, и некоторым нравится, УТВЕРЖДАЕТ, но другие хотят использовать усовершенствованное сообщение об ошибке и возможное восстановление после ошибки. В любом случае данные, как находят, являются дефектными, и в немногих случаях хорошо продолжить работать над ним. (обратите внимание, что хорошо, если серверы не перестают работать, по крайней мере),

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

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

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

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

Поскольку примером здесь является наш код для Нормализации вектора. При питании его неправильные данные в разработке, это будет кричать в производстве, это возвращает значение безопасности.

inline const Vector3 Normalize( Vector3arg vec )
{
    const float len = Length(vec);
    ASSERTMSG(len > 0.0f "Invalid Normalization");
    return len == 0.0f ? vec : vec / len;
}

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

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

Другой материал как хеширование паролей, шифрование строк подключения, и т.д. является также стандартом.

Отсюда на, это зависит от реального приложения.

К счастью, если Вы работаете с платформами, такими как .NET, большое средство обеспечения безопасности прибывает встроенное.

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

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

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

1. если они находятся в допустимом состоянии, что они остаются в допустимом состоянии
2. нет никакого способа создать их в недопустимом состоянии
3. При исключительных обстоятельствах они перестанут работать максимально корректно (часто, это - очистка и бросок),

Я - многое мнения, что корректное программирование защитит от этих рисков. Вещи как предотвращение функций устаревших, которые (в библиотеках Microsoft C ++, по крайней мере) обычно удерживаются от использования из-за уязвимостей системы обеспечения безопасности и проверки всего, что пересекает внешнюю границу.

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

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

Инжекция кода является только проблемой, если Ваше приложение может поднять текущего пользователя. Если процесс может ввести код в Ваше приложение затем, это могло бы легко написать код к памяти и выполнить его так или иначе. Не имея возможности получить полный доступ к нападениям инжекции системного кода бессмысленны. (Поэтому приложения, использованные администраторами, не должны быть записываемыми меньшими пользователями.)

Это зависит.

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

Более вероятно код должен использоваться, даже иногда, я увеличиваю уровень проверок.

• минимальные магические числа
• лучшие имена переменной
• полностью проверенный и определенный массив/длины строки
• программирование утверждениями контракта
• проверки нулевого значения
• исключения (в зависимости от контекста кода)
• основные пояснительные тексты
• доступная документация использования (если жемчуг и т.д.)

Я возьму другое определение безопасного программирования как то, которое это защищено Эффективным Java Josh Bloch. В книге он говорит о том, как обработать изменяемые объекты, которые вызывающие стороны передают Вашему коду (например, в методах set), и изменяемые объекты, которые Вы передаете вызывающим сторонам (например, в методах считывания).

• Для методов set удостоверьтесь, что клонировали любые изменяемые объекты и сохранили клон. Таким образом, вызывающие стороны не могут изменить переданный - в объекте после факта для повреждения инвариантов программы.
• Для методов считывания, любой возврат неизменное представление Ваших внутренних данных, если интерфейс позволяет его; или иначе возвратите клон внутренних данных.
• При вызове предоставленных пользователями обратных вызовов с внутренними данными отправьте в неизменном представлении или клоне, как соответствующие, если Вы не предназначаете обратный вызов для изменения данных, в этом случае необходимо проверить его после факта.

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

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

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

Java, БАНКИ со знаком и JAAS.

Java для предотвращения переполнения буфера и использования битья указателя/стека.

Не используйте JNI. (Собственный Интерфейс Java), это подвергает Вас библиотекам DLL / Shared.

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

JAAS может позволить Вашему приложению не доверять никому, даже самому.

J2EE имеет (по общему признанию ограниченный) встроенную поддержку Безопасности на уровне ролей.

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

Простой ответ: Это зависит от . Слишком много защитного кода может вызвать серьезные проблемы с производительностью.