Каждая из предыдущих технологий имеет большое значение для предотвращения случайных сбоев. Если их собрать вместе и правильно применить, то они сокращают шанс необнаруженной непреднамеренной ошибки практически до нуля. (Ну, не совсем до нуля, но до величины того же порядка, как вероятность того, что случайные космические лучи заставят центральный процессор получить 3 в результате сложения 1+1.) Но не все повреждения данных являются непреднамеренными. Что, если кто-нибудь специально предоставит неверные данные в надежде пробить брешь в системе безопасности вашей программы? Думать, как взломщик –вот следующий шаг в защите кода.

Давайте переключимся обратно на образ мышления атакующего и предположим, что приложение, которое мы атакуем, написано на языке программирования Java, использует сторонний код и хранит в XML все внешние данные, которые тщательно проверяются до передачи приложению. Можно ли по–прежнему успешно атаковать такое приложение? Да, можно. Однако наивный подход по случайному изменению байтов в файле вряд ли приведет к успеху. Вам нужен более изощренный подход, который учитывает встроенные в программу механизмы обнаружения ошибок и обходит их.

При тестировании устойчивого к неверным данным приложения произвести чистое тестирование по методу «черного ящика» нельзя, но, хотя и с некоторыми очевидными модификациями, основные идеи по–прежнему будут работать. Например, рассмотрим контрольные суммы. Если формат файла содержит контрольную сумму, то вы просто модифицируете ее так, что она совпадает со случайными данными еще до того, как файл будет передан приложению.

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

По-настоящему ограничительная схема, объединенная с проверкой оставшихся данных на уровне кода, может не оставить вам никакого места для маневра. Это то, чего вы должны добиваться как разработчик. Приложение должно иметь возможность осмысленно обрабатывать любой поток байтов, которые ему посланы и не отброшены как «де–юре» негодные.