### Неизменяемость Проблемная область - Проблемы, связанные с целостностью и доступностью данных Проектируя объект, вы должны определиться с тем, каким он должен быть: из- меняемым или неизменяемым. В первом случае его состояние может меняться, а во втором — нет. Это может показаться несущественным, но с точки зрения безопасности этот аспект очень важен. Неизменяемые объекты можно безопасно разделять между потоками выполнения, с их помощью данные можно сделать высокодоступными, что очень значимо для защиты системы от DoS-атак (denial of service — «отказ в обслуживании»). А вот изменяемые объекты рассчитаны на обновление, что может привести к внесению несанкционированных изменений. Поддержка изменяемости зачастую привносится в систему из-за того, что ее тре- буют фреймворки, или потому, что на первый взгляд она делает код проще. Но это опасный подход, за который, возможно, придется дорого заплатить. Чтобы это проиллюстрировать, рассмотрим пример того, как использование изменяемости в архитектуре веб-магазина вызывает проблемы с безопасностью, которые можно легко решить за счет неизменяемости. #### Неявное блокирование ухудшает доступность Вопрос о том, нужно ли запрещать конкурентный и параллельный доступ, зача- стую становится компромиссом между производительностью и согласованностью. Если состояние всегда должно оставаться согласованным, а обновления чередуются с операциями чтения, имеет смысл прибегнуть к механизмам блокирования. Но если данные преимущественно читают, блокирование может привести к излишним конф- ликтам между потоками выполнения. Параллельное и конкурентное чтение, скорее всего, безопасны, но при миними- зации конфликтов нельзя игнорировать операции записи. Вместо отказа от меха- низма блокирования необходимо подумать о другом решении. Например, можно использовать продвинутые средства блокирования наподобие ReadWriteLock, кото- рое учитывает преобладание операций чтения. На самом деле ReadWriteLock — это две блокировки: одна для чтения, а другая для записи. Первая может удерживаться сразу несколькими потоками выполнения, пока какой-то другой поток не запросит блокировку на запись. То есть параллельный и конкурентный доступ к данным позволен в случае, если они не изменяются. Есть более простая и успешная стратегия, состоящая в использовании методик проектирования, рассчитанных на параллельный и конкурентный доступ, таких как неизменяемость. Оказывается, для поддержки измене- ний можно обойтись без изменяемых структур данных. Достаточно лишь отделить чтение от записи и выполнять обновления через отдельные каналы. Это может показаться слишком сложным, но если в вашей системе наблюдается дисбаланс между чтением и записью, результат может стоить приложенных усилий. ### Быстрое прекращение работы с использованием контрактов Проблемная область - Проблемы, связанные с недопустимым вводом и состоянием Одним из принципов, которыми следует руководство- ваться при обеспечении безопасности, является глубина. Даже если не сработает один защитный механизм на границе системы, проникновение могут остановить другие. ### Проверка корректности Проблемная область - Проблемы, связанные с проверкой корректности ввода Использование предварительных условий и контрактов при планировании ар- хитектурных решений помогает четко определить, какие обязанности имеет тот или иной компонент. Многие проблемы с безопасностью возникают из-за того, что разные части системы ожидают друг от друга выполнения какой-то задачи. Как работает проектирование по контракту и что мы под этим понимаем? Для на- чала рассмотрим пример, не связанный с программным обеспечением. Представьте, что вы наняли сантехника, чтобы тот починил неисправный слив в ванной комнате. Сантехник может потребовать, чтобы вы открыли ему двери и перекрыли воду. Это предварительные условия (или предусловия) контракта. Если их не выполнить, могут возникнуть проблемы. В то же время мастер обещает, что по завершении ра- боты слив в ванной будет действовать исправно. Это постусловие контракта. В проектировании контракты объектов работают таким же образом. Контракт определяет предусловия, необходимые для корректной работы метода, и пост- условия, описывающие, как изменится объект после завершения методом работы. Некорректные данные не нужно повторять в исключении. Такое дублирование может быть чревато уязвимостями. Проверяйте предусловия для всех публичных методов — по крайней мере убедитесь в том, что они не принимают null в качестве аргументов.