Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Правильное написание программ, говорите? 16.05.04 16:09 Число просмотров: 4498
Автор: feldgendler Статус: Незарегистрированный пользователь
|
> ничего нового... разве-что нестандартный взляд на защиту
> перла... хотя как на меня обычное правильное написание
> програм защитит и так...
В статье автор справедливо заметил, что для того, чтобы защитить такой участок кода, как open(f,$filename), приходится быть экспертом по Perl. Я охотно верю, что Вы и есть такой эксперт и знаете обо всех специальных возможностях функции open() и других функций, а, значит, можете произвести все необходимые проверки, чтобы избежать нежелательного задействования таких возможностей (оставим за скобками фактор человеческой рассеянности). Но есть ещё и такой момент: вот эта упомянутая возможность с символом |, наверное, не в первой версии Perl появилась -- просто в какой-то момент её добавили, посчитав, что это полезно и удобно. А если в следующей версии Perl добавят ещё одну новую возможность? Тогда, получается, Вы уже не будете абсолютным экспертом по Perl, и может оказаться, что ваша существующая, правильно написанная программа при запуске под новой версией Perl окажется уязвимой. Следовательно, чтобы писать безопасные программы, нужно быть экспертом по всем возможностям Perl и постоянно быть в курсе всех новых возможностей. Кроме того, существующие программы могут оказаться уязвимыми в свете появления новых возможностей, и их потребуется исправлять
Справедливости ради хочу заметить, что разработчики практически всех серверных программных средств, включая авторов Perl, уже осознали степень риска, вводимого всевозможныминеявными"фишками" вроде упомянутого знака |, и в новых версиях мы вряд ли увидим такие новые автоматические средства, включить которые можно неосторожным движением. Напротив, более вероятно, что каждая новая версия будет более ограниченной в таких "автоматических" средствах при настройках по умолчанию. Я не знаток Perl, но насчёт PHP могу сказать, что именно так и происходит. Когда-то, например, параметры, указанные в HTTP-запросе, автоматически преобразовывались в переменные с такими именами, а это значит, что, если какую-то переменную забыли инициализировать явно, понадеявшись на автоматическую инициализацию пустым значением, есть возможность повлиять на выполнение скрипта, приписав к URL суффикс ?variable=value. Начиная с некоторой версии PHP, такое поведение больше не действует по умолчанию, но доступно по специальной настройке, в основном для обратной совместимости.
Также считаю нужным сказать, что мой комментарий ни в коем случае нельзя рассматривать как утверждение о том, что практика constrain and sanitize (проверки всех входных значений) бесполезная порочная. Напротив, я обеими руками за последовательное применение такой практики, а также за введение в языки и библиотеки автоматизированных средств для этого (таких, как функция htmlescape() в PHP). Во-первых, два рубежа защиты лучше, чем один, и в сочетании с методом, описанным в статье, проверка входных значений даст ещё лучший уровень защищённости. А, во-вторых, далеко не все виды атак принципиально пресекаемы при помощи описанного автором метода; так, например, классическое SQL injection (внедрение SQL-фрагментов во входные данные) невозможно предотвратить таким способом.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
Правильное написание программ, говорите? - feldgendler