Сейчас идет еще один раунд дебатов «Безопасен ли PHP?». Крис обратил на это внимание, указав на пост Эндрю ван дер Сток (который является участником OWASP ): « Небезопасность PHP: отказ от лидерства» .
Поэтому были сделаны обычные опровержения (см. Ответы на статью Криса) — «Черт возьми, новички», «Дыры в приложении на основе PHP! = PHP небезопасен» и т. Д., С которыми я согласен. Но…
Думаю, можно с уверенностью предположить, что заостренные волосы боссов получают сигналы, содержащие слова «PHP» и «уязвимость». На данный момент, возможно, вам все равно — ваша крепость держит заостренных волосатых людей снаружи. Но как только вы однажды наткнулись на эту стену, предлагая цену / споря за PHP (я был в последней ситуации), вы начинаете удивляться.
Итак, давайте немного изменим ситуацию и попробуем немного свежего обсуждения.
Что если у Эндрю есть смысл? Что если мы живем в отрицании? Я думаю, что Эндрю изначально был «убит», потому что его аргументация слишком осторожна, не слишком скандальна. Но позже (см. Его второй комментарий к сообщению Криса ) думаю, что он наконец прибил его;
Struts и .NET по умолчанию упрощают использование метода вывода XSS.
<bean:write ...и
Веб-формы .NET имеют методы проверки страниц, которые автоматически обнаруживают большинство форм XSS-атак без написания кода .
Теперь давайте сопоставим этот невинно выглядящий фрагмент PHP и HTML;
<form action = "<? php echo $ _SERVER ['PHP_SELF'];?>"> <input type = "hidden" name = "submit" value = "1" /> <input type = "submit" value = "Отправить!" /> </ Форма>
Нам даже не нужно принимать какой-либо пользовательский ввод — мы просто отображаем форму, верно? Этот пример распространяется по всей сети — отличный способ избежать жесткого кодирования имени скрипта. Упс — извините за XSS .
Так кто тупее? «Глупый новичок», который не понял отношения между суперглобальным $ _SERVER и CGI или PHP за то, что он не смог представить простое и безопасное решение для этой очень распространенной проблемы: как отобразить форму, которая подчиняется себе, без жесткого кодирования атрибут действия?
Давайте сделаем еще более спорным и выберем короткий открытый тег . Отличный материал, потому что он позволяет вам делать это: <?=$someVar?> Ой, подождите … больше возможностей для XSS. Алан Ноулз подытожил эту тему здесь ;
Вот почему шаблоны стилей PHP — просто плохая идея … — если вы не копируете и не вставляете htmlspecialchars повсюду, в этом случае вам нужно просматривать деревья, чтобы увидеть ошибки …
Выходной слой должен по умолчанию экранировать код, если это возможно, и упростить поиск, где экранирование не выполняется, а не наоборот.
Возможно, «умным» было бы то, чтобы этот стиль коротких тегов автоматически передавал выходные данные через htmlspecialchars ?
Вход в гораздо более серую зону … другая реальность PHP — если вы действительно хотите иметь возможность строго выполнять проверку пользовательского ввода, вам нужны регулярные выражения — в действительности нет никакого способа обойти это.
Регулярные выражения хороши, если вы знаете, как реальные новички (то есть, первое кодирование) предпочитают пробежать милю. Может ли PHP предложить что-то по умолчанию для решения этой проблемы, например, набор функций для проверки общего ввода? Да, я знаю, что это темный путь к функциям с необязательными аргументами, такими как «charset», но с упором на слово common , как в случае общего использования — вероятно, эти парни все еще кодируют эти страницы как ISO-8859-1. Большинство фреймворков PHP, которые дают «дюжину в день», прямо сейчас содержат набор стандартных помощников проверки — почему они это делают?
Альтернативный путь — фильтрация. Дерик упомянул это расширение PECL , над которым он работает с Расмусом. Это вещь из белого / черного списка, и скептики могут утверждать, что это приведет к magic_quotes V2. А как насчет уроков от червя Myspace ?
Тем не менее, Джефф поднимает хорошие моменты на входах и выходах фильтрации входных данных здесь, и это стоит иметь в виду его заключительное замечание;
Я предполагаю, что я программирую около 23 лет. Чем дольше я это делаю, тем больше я неохотно отношусь к пользовательскому вводу. Сверхсанитаризированные, ультраструктурированные данные могут показаться привлекательными для программиста, но это является болью для пользователя, и это лишь вопрос времени, когда придет законное исключение. Европейский номер телефона, 51-й штат, канадский почтовый индекс, новое тысячелетие и т. Д. Исключением является правило. Понятно, что XSS нужно предотвратить, но его легко зайти слишком далеко.
У Марко также есть интересные вещи , которые следует из поста Криса, который сводится к тому,
Я не думаю, что безопасность принадлежит самому языку.
Там вы должны остановиться на этом слове «язык». Стерлинг Хьюз ( блог теперь RIP, но цитируется здесь ) однажды сказал;
Если PHP является чем-то, то это фреймворк, который включает в себя действительно симпатичный язык сценариев
Что бы вы ни взяли на себя, это не имеет значения. Это то, что вы получаете по сравнению с этим.
Так в чем вы суть?
На самом деле у меня его нет. Здесь нет ничего, кроме сложного выбора и тяжелой работы. Нарушение обратной совместимости для «исправления» таких вещей, как $_SERVER['PHP_SELF']; или короткие теги, очевидно, не вариант. Добавление альтернатив и дополнительных функций тоже может не сильно помочь — борьба за их использование — это борьба.
Я думаю, что нам нужно перестать обвинять «глупых новичков» и признать, что есть проблема. Назовите это проблемой обучения, если хотите. Или признаться, что PHP был задуман во времена невиновности сети. Без разницы. Направьте их на доступные книги и предупредите их быть осторожными.
И, вероятно, нам придется делать будущие ставки на основе этой платформы ( выпускать раньше, выпускать часто !) И призывать других делать то же самое. Надеюсь, ради новичков «Extreme Simplicity» и MVC могут вписаться в одно и то же предложение.
Но, чтобы закончить на положительной ноте, с помощью Бьярне Страуструпа ;
Есть только два вида языков: те, на которые жалуются люди, и те, которые никто не использует