http://wiki.linuxformat.ru/wiki/index.php?title=LXF102:%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_PHP&feed=atom&action=historyLXF102:Доверительный PHP - История изменений2024-03-29T13:40:22ZИстория изменений этой страницы в викиMediaWiki 1.19.20+dfsg-0+deb7u3http://wiki.linuxformat.ru/wiki/index.php?title=LXF102:%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_PHP&diff=8046&oldid=prevCrazy Rebel: Викификация, оформление2009-05-29T04:39:18Z<p>Викификация, оформление</p>
<a href="http://wiki.linuxformat.ru/wiki/index.php?title=LXF102:%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_PHP&diff=8046&oldid=8044">Внесённые изменения</a>Crazy Rebelhttp://wiki.linuxformat.ru/wiki/index.php?title=LXF102:%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_PHP&diff=8044&oldid=prevCrazy Rebel: /* Права доступа и последствия */2009-05-28T09:12:50Z<p><span dir="auto"><span class="autocomment">Права доступа и последствия</span></span></p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr valign='top'>
<td colspan='2' style="background-color: white; color:black;">← Предыдущая</td>
<td colspan='2' style="background-color: white; color:black;">Версия 09:12, 28 мая 2009</td>
</tr><tr><td colspan="2" class="diff-lineno">Строка 48:</td>
<td colspan="2" class="diff-lineno">Строка 48:</td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Следует принять в расчет два сценария:</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Следует принять в расчет два сценария:</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>'''a''' Различные пользователи не должны иметь возможность случайно или умышленно перезаписывать файлы или каталоги друг друга.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>'''a''' Различные пользователи не должны иметь возможность случайно или умышленно перезаписывать файлы или каталоги друг друга.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr>
</table>Crazy Rebelhttp://wiki.linuxformat.ru/wiki/index.php?title=LXF102:%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_PHP&diff=8043&oldid=prevCrazy Rebel: Новая: ==Доверимся ''PHP''== : В определенных кругах разработчиков безопасность ''PHP'' ставится под сомнение. '''Фрэ...2009-05-28T09:12:25Z<p>Новая: ==Доверимся ''PHP''== : В определенных кругах разработчиков безопасность ''PHP'' ставится под сомнение. '''Фрэ...</p>
<p><b>Новая страница</b></p><div>==Доверимся ''PHP''==<br />
<br />
: В определенных кругах разработчиков безопасность ''PHP'' ставится под сомнение. '''Фрэнк Полманн''' развенчивает многие из этих мифов...<br />
<br />
Все мы знаем, что ''PHP'' может быть источником весьма серьезных проблем с безопасностью. Регулярно обнаруживаются новые эксплойты, атакующие непосредственно интерпретатор; ''PHP''-программисты часто имеют дело с системами управления контентом (CMS), нередко становясь при этом жертвами взломщиков.<br />
<br />
Однако существуют весьма простые способы обеспечить безопасность, приняв во внимание то, на чем базируется работа ''PHP'', а именно,<br />
web-сервер. За основу возьмем ''Apache'', хотя часть последующих примеров применима также и к другим серверам.<br />
<br />
===Как запускать ''PHP''-программы===<br />
<br />
Разбираться придется с несколькими различными случаями.<br />
Программы ''PHP'' могут, во-первых, выполняться как ''CGI''-скрипты; во-вторых, запускаться в рамках модуля ''Apache''; и в-третьих, программы<br />
''PHP ''можно писать как ''CGI''-скрипты, но выполнять как часть так называемого модуля ''FastCGI''. Скрипты ''CGI'' вызывают особенно неприятные<br />
проблемы с безопасностью, ибо каждый ''CGI''-скрипт выполняется как<br />
отдельный процесс. А каждый процесс, выполняемый web-сервером,<br />
наследует идентификатор пользователя ('''uid''') web-сервера, что не есть<br />
хорошо, если кто-нибудь заполучит контроль либо над ''CGI''-скриптом,<br />
либо над исполняемым файлом ''Apache'': тогда выполнение ''Apache'' и<br />
всех других ''CGI''-скриптов будут во власти атакующего.<br />
<br />
Существуют, однако, способы держать ''PHP''-скрипты в безопасности без обращения к средствам второй линии защиты, вроде применения ''chroot''’а к ''Apache'' и оставшейся части пакета '''{L,M}AMP'''. Зададимся<br />
вопросом о способах присвоить каждому ''CGI''-скрипту отдельный '''uid''';<br />
в частности, поговорим о ''suEXEC''. Но есть более фундаментальные<br />
приемы, с которыми нужно ознакомиться, прежде чем прибегать<br />
к средствам типа ''suEXEC'' и ''suPHP''.<br />
<br />
===Первичное укрепление ''Apache''===<br />
<br />
Практическую безопасность ''PHP'' можно подразделить на четыре части:<br />
безопасность файловой системы, безопасность ''Apache'', уровень безопасности ''PHP''-интерпретатора и безопасность ''PHP''-клиента. Первыми<br />
тремя мы займемся целиком, а говоря о ''suEXEC'', кратко остановимся<br />
на четвертой. Предположим, имеется стандартная схема размещения<br />
файлов: все файлы ''Apache'' расположены в '''/usr/local/apache2/'''.<br />
<br />
ServerRoot /usr/local/apache2<br />
DocumentRoot /usr/local/apache2/htdocs<br />
Основной конфигурационный файл /usr/local/apache2/conf/httpd.conf<br />
Параметры SSL /usr/local/apache2/conf/ssl.conf<br />
ErrorLog /usr/local/apache2/logs/error_log<br />
AccessLog /usr/local/apache2/logs/access_log<br />
cgi-bin /usr/local/apache2/cgi-bin<br />
Исполняемые файлы Apache /usr/local/apache2/bin<br />
<br />
Можно, а иногда и нужно, иметь несколько каталогов '''cgi-bin'''; этим мы воспользуемся при разговоре о местоположении ''PHP''-интерпретатора.<br />
<br />
===Права доступа и последствия===<br />
<br />
Следует принять в расчет два сценария:<br />
'''a''' Различные пользователи не должны иметь возможность случайно или умышленно перезаписывать файлы или каталоги друг друга.<br />
<br />
'''b''' Каждый пользователь может иметь дело с виртуальной копией ''Apache'', избегая таким образом некоторых, но не всех, проблем с правами доступа. <br />
<br />
Данная возможность отражается на производительности и безопасности, но в данном контексте мы ее обсуждать не будем.<br />
<br />
===Права доступа ''PHP CGI''===<br />
<br />
Когда ''PHP'' скомпилирован для запуска с ''Apache'', и используется<br />
файл конфигурации по умолчанию, рабочий режим ''PHP ''– это режим<br />
''CGI''-скрипта. Каждый ''CGI''-скрипт, независимо от языка программирования, должен иметь необходимые права доступа, чтобы владелец<br />
скрипта мог запустить его. Это значит, что владелец скрипта должен уметь считывать и запускать сам скрипт, а ''Apache'' должно быть<br />
достаточно только прав на запуск. Если верить документации ''Apache'',<br />
права доступа каталогов '''cgi-bin''', где ''Apache'' ищет ''CGI''-скрипты, должны быть таковы:<br />
<br />
drwxrwxrwx<br />
<br />
что также известно как права доступа '''0777'''. Как мы увидим позже, все<br />
сценарии внутри каталогов '''cgi-bin''' должны восприниматься ''Apache'' как<br />
''CGI''-скрипты, и не иначе; отсюда следует, что надо привести в согласие<br />
права доступа всех скриптов, размещенных в каталоге '''cgi-bin''' (о файлах с данными и с контентом речь пока не идет). Права '''0777''' допустимы, но это рискованно, так как если вы предоставите их, любая брешь в защите приведет к тому, что люди смогут запросто перезаписывать<br />
и даже заменять ''CGI''-скрипты, если они вызываются и модифицируются напрямую.<br />
<br />
Строго говоря, единственный пользователь (или группа!), кто во<br />
время разработки и тестирования должен иметь право считывать,<br />
записывать и получать доступ к каталогу '''cgi-bin''' – это web-разработчик, или группа таковых. Тогда права на каталог '''cgi-bin''' снижаются<br />
до<br />
<br />
drwxrwxr-x<br />
<br />
они же – права доступа '''775'''. Имеет смысл также предположить, что<br />
web-разработчику нужно считывать, изменять и выполнять файлы<br />
внутри каталога '''cgi-bin''' (и выводить их список!). По завершении разработки, когда ''CGI''-скрипты попали на сервер, группе web-разработчиков<br />
в целом, по идее, незачем в них писать.<br />
<br />
Выходит, права доступа для '''cgi-bin''' – '''755''', как и сделано по умолчанию на многих установках ''Apache'' и пакета '''LAMP''' (''Linux, Apache, MySQL, и PHP''). Они также подразумевают, что пользователь ''Apache'', если таковой существует, сможет выводить список файлов в данном каталоге,<br />
исполнять и считывать их.<br />
<br />
===Права доступа ''CGI''-скрипта===<br />
<br />
Так как всем остальным пользователям нужно уметь считывать<br />
''CGI''-скрипты, но только ''Apache'' приходится их выполнять, администратор должен установить всем ''CGI''-скриптам права '''644'''.<br />
<br />
$ chmod 644 {любое_имя_файла}.cgi<br />
<br />
===Настройка ''Apache'' для ''PHP''===<br />
<br />
Чтобы заставить web-сервер действовать по заданному сценарию, мы<br />
должны удостовериться, что прописаны определенные директивы<br />
''Apache'', и присутствуют определенные модули. Прежде всего следует<br />
убедиться, что пользователь ''Apache'' – единственный, которому система разрешает запускать ''Apache'', и что этот пользователь – единственный член группы ''Apache''. Назовем этого пользователя '''httpd''', и группу<br />
тоже назовем '''httpd'''.<br />
<br />
$ groupadd httpd<br />
$ useradd httpd -g httpd -d /dev/null -s /sbin/nologin<br />
<br />
Нам нужно создать для Apache нового пользователя, чтобы пресечь<br />
любые попытки взломщиков «угадать» владельца скрипта во время<br />
работы. Мы не дадим самому ''Apache'' многих привилегий: у него даже<br />
не будет отдельного входа в систему. Владельцу скриптов и файлов<br />
данных, конечно, полагается быть web-разработчиком или кем-то из<br />
группы web-дизайна.<br />
<br />
Данная мера безопасности окажется бесполезной, только если кто-нибудь сумеет «угадать» идентификатор web-сервера, но для этого требуется несколько больше, чем способность выполнять ''CGI''-скрипты.<br />
<br />
Еще нам понадобится возможность создавать другие каталоги '''cgi''',<br />
чтобы объединять наши скрипты вместе по типам. Желательно группировать вместе ''PHP''-скрипты, так как можно, а иногда даже нужно,<br />
иметь копию интерпретатора ''PHP'', запущенную внутри ''CGI''-каталогов.<br />
Обычно считается, что это – дыра в безопасности, но с ней можно управиться способом, которым мы потом займемся отдельно.<br />
<br />
'''UID''' и '''GID''' созданного в системе Linux/Unix пользователя '''httpd''', отображаемые в списке Linux-пользователей, должны совпадать с '''UID''' и '''GID''' пользователя и группы ''Apache''.<br />
<br />
Директивы '''http.conf''', присутствующие в главном разделе конфигурации ''Apache'', таковы:<br />
<br />
User httpd<br />
Group httpd<br />
<br />
Позаботимся, чтобы ''Apache'' мог выполнять ''CGI''-скрипты. Это гарантируется модулем ''mod_cgi'' (он доступен как часть базового дистрибутива ''Apache''), но существуют некоторые директивы, которые следует добавить к '''httpd.conf''' еще до работы модуля. Нам нужно сообщить '''httpd.conf''',<br />
что ''CGI''-скрипты могут запускаться, и откуда они могут запускаться. ''PHP'' должен запускаться из какого-либо каталога '''cgi-bin''', независимо от<br />
того, один или несколько пользователей работают с ''CGI''-скриптами. Мы<br />
должны начать с директивы, запрещающей всему, что располагается<br />
за пределами дерева web-сервера, запускаться владельцем или любым<br />
пользователем ''Apache''. Потом мы сможем ослабить наши правила, но<br />
для начала лучше проявить максимум консерватизма.<br />
<br />
Следующие директивы тривиальны, но совершенно необходимы<br />
для безопасных операций ''Apache'':<br />
<br />
<Directory /><br />
Order deny,allow<br />
deny from all<br />
</Directory><br />
<br />
Это – стандартная директива, она гарантирует, что ''Apache'' не сможет обслуживать файлы по всей файловой системе, даже дерево web-<br />
сервера. Конечно, теперь придется потрудиться, чтобы ''Apache'' СМОГ<br />
обслуживать нужные файлы, так что добавим другую директиву, сообщающую, что ''Apache'' может обслуживать файлы данных и контента из<br />
'''DocumentRoot''':<br />
<br />
DocumentRoot /usr/local/apache2/htdocs<br />
<Directory /usr/local/apache2/htdocs><br />
Order allow,deny<br />
Allow from all<br />
</Directory><br />
<br />
Для правильной работы ''PHP''-скрипты обязаны восприниматься как CGI-скрипты.<br />
<br />
Чтобы никто не вздумал разрешить выполнение ''CGI'' с использованием файлов ''PHP'' не из каталога '''/usr/local/apache2/cgi-bin''' (или любого другого, явно прописанного вами в директивах '''Directory'''), добавим</div>Crazy Rebel