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

Для целых и дробных чисел, значений времени и тому подобных типов данных запись производится всегда в фиксированном объеме (2 байта, 4 байта, 10 байт). А вот для .- строк и массивов данных проверки  длины перед операциями записи необходимы. Для того, чтобы заставить ЭВМ выполнить код или записать данные туда, куда У него нет прав записи, злоумышленник специально заставляет систему обрабатывать строки очень большой длины, либо помещать в массив количество элементов большее; чем его объем. В случае успеха возможно либо попадание части строки в сегмент кода или стека с последующим исполнением, либо модификация каких-либо служебных данных, что позволит затем злоумышленнику войти в систему в обход системы защиты. Естественно, что содержимое конца строки (оказывающееся после переполнения буфера в ненадлежащей области памяти) подбирается специальным образом. Сами данные или строки могут быть абсолютно бессмысленными.

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

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

Основные положения по разработке программного обеспечения

Общие рекомендации по написанию устойчиво работающих алгоритмов (необходимое, но не достаточное условие их информационной безопасности):

•  не используйте экзотические и недокументированные возможности языка программирования: вы не уверены в том, как они реализуются на самом деле;
•  оформляйте исходный текст ясно и четко, используйте необходимые комментарии;
•  используйте скобки для явного указания порядка операций: компилятор может оптимизировать выполнение выражений и начать, скажем, сложение F(1)+F(2)+F<3) со второго знака «+»,тем самым вызвав сначала функцию F от 2, затем от 3, а только затем от 1 — если в функции изменяются какие-либо глобальные переменные это может привести к непредсказуемым последствиям;
•  при всех удобных случаях используйте передачу параметров функции в качестве аргументов, а не в глобальных переменных;
•  используйте структурное программирование: разбивайте сложные блоки кода на процедуры с ясной . структурой и легко контролируемым набором параметров;
•   никогда не программируйте недокументированные возможности: технология «reverse engineering» — «дизассемблирование и обратная компиляция» — на сегодняшний день достигла огромных результатов, особенно в отношении высокоуровневых языков программирования;
•  закрывайте файлы сразу же по окончании работы с ними, а если Вы записываете важную информацию в течение долгого времени — периодически вызывайте функции сброса файлового буфера на дисковый накопитель;
•  проверяйте свободное место на диске перед записью в файл: некоторые операционные выдают ошибки при записи на переполненный диск нестандартным образом, результат этого может быть плачевным;
•  блокируйте файлы и наборы данных, если вы обращаетесь к ним по записи из нескольких параллельно работающих процессов или программ;
• старайтесь как можно сильнее сократить время записи в совместно используемые файлы, а, следовательно, и время их блокирования;
•  не будьте заранее уверенными, что программа запущена из той директории, где расположен ее исполнимый файл, — одной из первых команд после запуска программы явно смените каталог на желаемый;
•  при работе с внешними и сетевыми устройствами и дисками стройте циклы ожидания таким образом, чтобы из них был возможен выход по истечении определенного периода ожидания ответа — тайм-аута;
•  очень тщательно разрабатывайте схему синхронизации параллельно работающих с одними и теми же данными процессов;
•  тщательно проверяйте алгоритмы на синдром «мертвой петли» — это ситуация, когда процесс А, начав изменять объект 1 и заблокировав его в связи с этим, ожидает снятия блокирования с объекта 2, в то время как процесс В, в то же самое время начавший изменять объект 2 и заблокировав его, ожидает снятия блокировки с объекта 1 — подобная проблема при такой схеме синхронизации теоретически неразрешима, единственный выход из нее — рассматривать объекты 1 и 2 как единое целое с возможностью только совместной блокировки;
• аккуратно выделяйте и очищайте объекты в динамической памяти;
•  при необходимости используйте криптографию;
•  никогда не передавайте пароль открытым текстом;
• используйте криптостойкие алгоритмы шифрования и хеширования;
• вычищайте блоки оперативной памяти после того как информация (пароли, ключи, конфиденциальные данные), находившаяся в них, стала ненужной;
•  встраивайте в ваши системы требование регистрации каждого оператора с уникальным паролем и записью как можно большего количества информации о сеансе в лог-файл, недоступный для изменения операторам;
•  тщательно тестируйте ваши приложения, в том числе на больших и неправильных входных данных.