Здравствуйте, vayerx, Вы писали:

DOO>>Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.

V>it depends (c)

Пример такого ТЗ, раз depends



DOO>>А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы?
V>где я говорю только о пользователях системы?
Хорошо переформулируем — ты все ограничиваешь только синхронными данными, не учитывая, например, асинхронные сигналы.
Про обработку отказов оборудования я вообще молчу.


DOO>>У примеру, я видел уязвимость в web приложении, которая заключалась в том, что в таблицу БД складывалось значение HTTP заголовка User-Agent безо всякой предварительной фильтрации.
V>Это не входные данные системы?
По твоим рассуждениям создается такое впечатление.


DOO>>А если речь вообще идет о каком-нибудь race condition (это тоже прокол в построении автомата)?

V>race condition, имхо, трудно отнести к потенциальным уязвимостям перед атаками, разве что только в некоторых случаях для DoS.
Ну я о багах в целом, а уж как эксплуатировать ту или иную ошибку, чтобы получилась законченная атака способы найдутся...



DOO>>Абсолютно одинаково. Если, допустим, речь идет о системе АСУ ТП, которой в результате сбоя в сети пришли искаженные данные от датчика и она помера от этого? Тут даже злого умысла не надо... Тот же clipboard приводит к тому, что приложение потенциально должно быть готово получить из него все, что угодно.

V>в общем-то, не спорю.
V>тем не менее, асутп аэс и асутп арбузорастительного комбината — разные вещи с точки зрения требований к надежности. именно минимальных требований, но, разумеется, никак не верхнего ограничения культуры разработки.
В общем-то да. Но опять же, если речь о коробочном продукте (в смысле для массового использования), то тут ты уже не знаешь будет это АЭС или арбузорастительный комбинат.