Шаблон предназначен для проверки целостности и безопасности потока данных, поступающих на вход системы, которая позволяет снизить поверхность атаки на сложные элементы системы за счет вынесения функции проверки в специальный изолированный компонент.
Опасно просто так использовать данные, полученные от пользователя или от внешней системы. Их надо фильтровать на потенциально опасные, прежде чем они будут использованы в функциональных блоках.
Проверку надо выносить в отдельный от бизнес-логики блок кода.
Желательно, сделать так, чтобы обработчик нельзя было обойти ни по умыслу, ни по забывчивости разработчика.
Аналогичный механизм может потребоваться и тогда, когда система оперирует конфиденциальными данными и может случайно их выдать не тем получателям. Для этого обработчик проверит выходные данные, прежде чем отправить.
При запуске ПК в момент загрузки операционной системы появляется логотип производителя. Логотип можно поменять на любое изображение. На этапе загрузки картинка обрабатывается специальными программами на уровне загрузчика и обрабатываются только заданные форматы изображения. Исследование показало, что если подкинуть нетипичный файл, то программы его не отфильтруют и все равно попытаются обработать. В итоге возникает ошибка, которая приводит к записи из поддельного изображения в область данных для исполнения. В результате злоумышленник получает доступ к системе на самых базовых уровнях.
Типовые цели безопасности при применении шаблона включают:
Опасно просто так использовать для управления данные, полученные из недоверенных источников (от пользователя или от внешней системы), их надо фильтровать на потенциально опасные, прежде чем они будут использованы в функциональных блоках.
Проверку надо выносить в отдельный от бизнес-логики блок кода.
Также желательно, чтобы проверку нельзя было обойти ни по умыслу, ни по забывчивости разработчика.
Аналогичный механизм может потребоваться и тогда, когда система передает потенциально конфиденциальные данные наружу недовереннным получателям.
Предположения безопасности включают известный формат данных и известный протокол обмена данными.
Предположения и условия, при которых шаблон не может быть применен: данные, которые требуется контролировать, подвергаются шифрованию, и нет возможности расшифровать их на уровне компонента, реализующего проверку и обработку данных.
Крупные и сложные элементы системы (такие как базы данных, микросервисы и т.д.) обладают обширной поверхностью атаки, в связи с чем усложняется задача обеспечения безопасности и проведения проверок для установления доверия. Для уменьшения поверхности атаки следует заранее проводить проверку входных данных на их безопасность относительно этих элементов, в том числе, требуется проводить необходимую очистку этих данных от лексических и синтаксических конструкций, представляющих опасность в отношении потенциальных уязвимостей элементов системы. Подобные проверку и очистку следует вынести в отдельный, небольшой, изолированный компонент, отвечающий следующим требованиям:
Элементы системы, реализующей шаблон:
Взаимодействие элементов шаблона представлено на рисунке 1.
{ search and update or create DB record (receivedValue)}
Прямая угроза.
If (receivedValue contain SQL Injection) ignore; else { search and update or create DB record (receivedValue) }
Велика вероятность ошибки или потери при изменениях кода/алгоритма проверки.
If (IsValidData (receivedValue)) { search and update or create DB record} else ;
Можно забыть вызвать проверку, или проигнорировать результаты проверки.
type UserField
{
UserField (input) { if (input contain SQL Injection) value = «»; else value = input; }
}
import search and update or create DB record (value: UserField); search and update or create DB record (receivedValue);
}
Нет гарантий что канал от проверки к приемнику доверенный. Нет гарантий что нельзя данные напрямую приемнику послать.
Необходимо исключить каналы передачи данных между источником и получателем данных, которые могут быть использованы для передачи необработанных данных. Гарантии отсутствия скрытых каналов или невозможности использования таких каналов элементами системы, реализующими шаблон, могут быть предоставлены на низком уровне относительно реализации шаблона.
Необходимо обеспечить аутентичность и целостность канала передачи данных между компонентом, реализующим очистку данных, и получателем данных для исключения подделки данных и атаки «человек посередине». Гарантии аутентичности и целостности канала передачи данных могут быть предоставлены на низком уровне относительно реализации шаблона.
Необходимо реализовать подходы к обеспечению корректности производимой обработки (очистки) данных, в первую очередь методические и кооперационные подходы, обеспечивающие безопасность и корректность работы программного кода компонента, реализующего проверку и обработку (очистку) данных.
Обработчик должен не только обезопасить входные данные для целевой системы, но и сам не стать жертвой атаки. Методический подход проявляется в поэтапном создании компонента согласно принципам безопасной разработки: следование хорошим практикам в реализации, проверка и тестирование кода, поиск уязвимостей и т.д. (подробнее см. в ГОСТ 56939). Кооперационный подход предполагает, что учитываются требования всех вовлеченных сторон: заказчиков, пользователей, регуляторов. Особенно это касается продуктов массового распространения. Например, если выделенный обработчик будет частью публичной библиотеки.
Применение шаблона может быть ограничено в системах с требованиями к выполнению в реальном времени, а также в системах с повышенными требованиями к функциональной безопасности и надежности вследствие необходимости обработки данных и возможного изменения данных, что потенциально может повлиять на выполнение упомянутых требований.
Допустимо применять шаблон не только для обработки (очистки) данных, но также с целью нормализации или изменения формата данных для обеспечения их корректной интерпретации получателем;
Допустимо применять шаблон с целью мониторинга безопасности данных без их обработки (очистки), только для проверки данных, как показано на рисунке 2.
Допустимость модификаций, не входящих в указанный перечень, должна быть обоснована при проектировании архитектуры и формировании требований, предъявляемых к системе на основе целей и предположений безопасности для этой системы.
