Я обновился до PHP5.5, а в PHP.ini теперь short_open_tag=off и я это узнал, потому что некоторые файлы теперь не работают, потому что <? вместо <?php .
Теперь есть два решения, сканирующих для любого php-файла, и изменение открытого тега на <?php или включение short_open_tag=on
Есть ли проблема безопасности со вторым вариантом?
Не является прямой уязвимостью безопасности, но она может стать одной, учитывая надлежащие условия.
Прежде всего давайте рассмотрим стандарты. В PHP 5.4 и выше директива short_open_tag=on применяется ко всем коротким тегам, кроме <?= – тега эха. Как правило, считается, что использование коротких тегов по всему вашему коду является плохой практикой из-за переносимости. Я лично теперь использую короткие теги. Поскольку PHP 5.4 и> = 5.4, короткий тег echo <?= Всегда доступен и не зависит от директивы short_open_tag ini. Я считаю это решение отделить эхо-тег от остальных хорошим.
На самом деле стандарты PSR предлагают это. Итак: PSR-1 предлагает использовать только <?php ?> Или <?= ?> (Echo short tag) – и никаких других вариантов , и PSR-2 предлагает не закрывать теги в файлах PHP. Это может показаться странным, но иногда в вашем коде могут быть непрослеживаемые ошибки из-за одиночного символа ('') перед открытием или сразу после закрытия. Это хорошо известная проблема. Я придерживаюсь обеих практик, поскольку я видел, что все это очень не так из-за использования разных тегов в старых проектах.
Откуда это все началось?
Еще в первые дни работы PHP люди начали понимать, что теги PHP конфликтуют с тегами XML и ASP. Да, вы можете использовать <% //code here %> как тег open / close. Затем было решено, что PHP будет использовать <?php ?> Чтобы отличить себя от XML и ASP – своего рода пространство имен верхнего уровня для PHP-кода. На самом деле теги ASP были введены как удобный способ облегчить принятие PHP разработчиками ASP.
Теги ASP обрабатываются директивой asp_tags ini, и они должны быть отключены.
Опять же – дебаты для коротких тегов были проведены, и именно поэтому теперь существует разделение между короткими тегами и тегом короткого эха. Я считаю, что это хорошо. Просто замените все короткие теги на устаревший код.
Теперь о безопасности .
Единственный случай, о котором вы должны беспокоиться, – это когда у вас есть пользовательский ввод, который каким-то образом заканчивается через интерпретатор PHP. Вам нужно будет снять:
<script language="php"></script> Эта последняя часть – <script language="php"></script> – очень важна, поскольку она не используется сегодня (и нам лучше без нее), но, насколько я помню, она по-прежнему поддерживается PHP переводчик. Таким образом, любой из этих тегов HTML-скриптов будет интерпретироваться как PHP. Все это очень хорошо объяснено здесь .
Что, черт возьми, это инъекция кода с байтовым сдвигом ?
Это трудно объяснить, но основная идея – это запутанная инъекция кода . Поэтому, если злоумышленник каким-то образом может ввести некоторый PHP-код, и он / она не хочет, чтобы сопровождающий / разработчик сразу идентифицировал его, он мог бы сделать что-то вроде следующего:
$smth = 'rpub "lbh ner nggnpxrq naq lbhe jrofvgr unf orra gnxra bire";'; eval(str_rot13($smth));
Идея заключается в том, что «blob of sting» является строкой кода php, но байт сдвинут так, что он запутан. В моем примере eval() получит echo "you are attacked and your website has been taken over" . Я использую str_rot13 (), так как легко обфускать строку назад и вперед, но это может быть пользовательская функция, основанная на chr() или ord() или любых других функциях манипуляции строками.
Лучший способ предотвратить такую атаку – предотвратить выполнение eval() . Вы должны это сделать с помощью директивы disable_functions ini . Разберите свой код, конечно! Но также отключить eval() .
Такой тип атаки может быть очень трудно заметить с помощью таких систем, как WordPress, которые хранят много вещей в БД, причем большинство из них неоправданно. Я лично видел такую инъекцию кода для веб-сайтов (а не те, которые я поддерживал: D) одним из двух способов:
diff ). Надеюсь, это помогло. Поэтому, пожалуйста, приступайте к стандартам PSR .
<?=