Логично предположить, что некорректные данные, которые не могут удовлетворить определённые запросы пользователя, могут (и должны) вызывать некий операционный сбой в функционировании ПО. Но что это значит в более широком смысле?

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

Но, в большинстве случаев это крайне маловероятно. Скорее всего, на каком-то этапе сработает специальный перехватчик, который или передаст пользователю информацию об ошибке, или сделает запись в логе, после чего ПО самостоятельно восстановится от системного сбоя и продолжит своё функционирование. Другими словами, [highlight dark=”no”]если валидация не будет выполнена, скорее всего, ничего критического не произойдет.[/highlight]

Но всё же, некоторые некорректные итоги отсутствия валидации могут случиться. Далее как раз разберём их более детально.

1. Нет возможности восстановить работу ПО после сбоя.

Не каждый раз приложение может возвратить всё назад. Может быть, по ходу процесса работы, ПО сможет выполнить некоторые действия, которые не удастся обратить (удалит определенный файл, отправит информацию по сети, напечатает что-то на подключенном к локальному ПК принтере и тому подобное). Но даже если процесс восстановления и возможен, в действиях, применимых для восстановления системы, могут тоже содержаться баги, и время от времени это будет приводить к ряду негативных процессов.

2. Дополнительная нагрузка на ПО.

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

3. Инъекции не влияют на сбои.

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

4. Трудности сопоставления причин возникающих проблем.

Если искомое исключение появилось где-то в приложении, найти причины его появления крайне сложно. И даже если это получиться, скорее всего, будет очень сложно доказать пользователю, что данный сбой связан с данными, которые он ввёл какое-то время назад в абсолютно ином месте. А если проверка произойдет сразу же после ввода информации, трудностей с идентификацией источника дефекта не возникнет!

Краткий вывод

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