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

Если сущность имеет конструктор без аргументов, это, скорее всего, означает, что ее инициализация основана на сеттерах. А это становится потенциальным источником проблем. Инициализация на основе сеттеров может оказаться неполной, а неполная инициализация делает объекты несогласованными.

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

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

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

Целостность данных заключается в обеспечении их согласованности и точности на протяжении всего жизненного цикла.

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

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

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

Объект-значение всегда должен оставаться неизменяемым и формировать целостную концепцию.

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

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

Доменная модель — это не просто упрощенная версия реальности: недостаток деталей компенсируется дополнительной строгостью.

Модель — это упрощенная версия реальности, которую мы все же можем воспринимать как корректное представление реальной вещи.

Модель — это упрощенная версия реальности, из которой убрано все то, что вам не нужно.

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

В ходе моделирования не забудьте обсудить верхние пределы — это всегда позволяет получить интересную информацию.

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

простая вещь — представление количества с помощью обычного целого числа — может вызвать серьезные проблемы с безопасностью.

С подозрением относитесь к моделированию, которое заканчивается словами «это целое число»!

Никогда ни в коем случае не представляйте деньги в виде числа с плавающей запятой!

Один из аспектов безопасности относится к целостности данных: это означает, что данные не должны меняться или генерироваться несанкционированным образом.

Согласно закону Постела и шаблону проектирования Tolerant Reader, когда системы взаимодействуют между собой, реализация приема данных должна быть либеральной, а реализация их отправки — консервативной15.

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

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

Многим разработчикам сложно разобраться во всех деталях замысловатых уязви­мостей, поэтому они относят себя к категории профессионалов, которые не занимаются безопасностью. Безопасность — это не их прерогатива. Однако большинство разработчиков понимают и ценят проектирование, и если с его помощью можно обеспечить безопасность, то оказывается, что создавать безопасное ПО может каждый.

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

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

спросить у своих специалистов в предметной области о значении имени пользователя в контексте текущего приложения (рис. 1.4).
Обсудив этот вопрос, вы приходите к выводу о том, что имя пользователя должно содержать только символы [A-Za-z0-9_-] и иметь длину от 4 до 40 символов. Это продиктовано тем, что считается нормальным именем пользователя в создаваемом приложении. Вы исключаете символы < и > не потому, что они могут быть частью XSS-атаки в случае, если имя пользователя выводится в браузере. Скорее, отвечаете на вопрос: «Как должно выглядеть имя пользователя в этом контексте?» В

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

Позже к этим трем факторам присоединился еще один: отслеживаемость (traceability, T) — это необходимость знать, кто и когда получал доступ к данным или изменял их.

В классической информационной безопасности обычно выделяют три основных требования: конфиденциальность, целостность и доступность (confidentiality, integrity, availability — CIA).

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

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

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