mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-15 16:38:54 +00:00
68 lines
2.7 KiB
XML
68 lines
2.7 KiB
XML
|
<?xml version="1.0" encoding="iso-8859-1"?>
|
||
|
|
<!-- $Revision: 1.1 $ -->
|
||
|
|
<!-- splitted from ./index.xml, last change in rev 1.66 -->
|
||
|
|
<sect1 id="security.apache">
|
||
|
|
<title>Installed as an Apache module</title>
|
||
|
|
<simpara>
|
||
|
|
When PHP is used as an Apache module it inherits Apache's user
|
||
|
|
permissions (typically those of the "nobody" user). This has several
|
||
|
|
impacts on security and authorization. For example, if you are using
|
||
|
|
PHP to access a database, unless that database has built-in access
|
||
|
|
control, you will have to make the database accessible to the
|
||
|
|
"nobody" user. This means a malicious script could access and modify
|
||
|
|
the database, even without a username and password. It's entirely
|
||
|
|
possible that a web spider could stumble across a database
|
||
|
|
administrator's web page, and drop all of your databases. You can
|
||
|
|
protect against this with Apache authorization, or you can design
|
||
|
|
your own access model using LDAP, &htaccess; files, etc. and include
|
||
|
|
that code as part of your PHP scripts.
|
||
|
|
</simpara>
|
||
|
|
<simpara>
|
||
|
|
Often, once security is established to the point where the PHP user
|
||
|
|
(in this case, the apache user) has very little risk attached to it,
|
||
|
|
it is discovered that PHP is now prevented from writing any files
|
||
|
|
to user directories. Or perhaps it has been prevented from accessing
|
||
|
|
or changing databases. It has equally been secured from writing
|
||
|
|
good and bad files, or entering good and bad database transactions.
|
||
|
|
</simpara>
|
||
|
|
<simpara>
|
||
|
|
A frequent security mistake made at this point is to allow apache
|
||
|
|
root permissions, or to escalate apache's abilitites in some other
|
||
|
|
way.
|
||
|
|
</simpara>
|
||
|
|
<simpara>
|
||
|
|
Escalating the Apache user's permissions to root is extremely
|
||
|
|
dangerous and may compromise the entire system, so sudo'ing,
|
||
|
|
chroot'ing, or otherwise running as root should not be considered by
|
||
|
|
those who are not security professionals.
|
||
|
|
</simpara>
|
||
|
|
<simpara>
|
||
|
|
There are some simpler solutions. By using
|
||
|
|
<link linkend="ini.open-basedir">open_basedir</link> you can control and restrict what
|
||
|
|
directories are allowed to be used for PHP. You can also set up
|
||
|
|
apache-only areas, to restrict all web based activity to non-user,
|
||
|
|
or non-system, files.
|
||
|
|
</simpara>
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
<!-- Keep this comment at the end of the file
|
||
|
|
Local variables:
|
||
|
|
mode: sgml
|
||
|
|
sgml-omittag:t
|
||
|
|
sgml-shorttag:t
|
||
|
|
sgml-minimize-attributes:nil
|
||
|
|
sgml-always-quote-attributes:t
|
||
|
|
sgml-indent-step:1
|
||
|
|
sgml-indent-data:t
|
||
|
|
indent-tabs-mode:nil
|
||
|
|
sgml-parent-document:nil
|
||
|
|
sgml-default-dtd-file:"../../manual.ced"
|
||
|
|
sgml-exposed-tags:nil
|
||
|
|
sgml-local-catalogs:nil
|
||
|
|
sgml-local-ecat-files:nil
|
||
|
|
End:
|
||
|
|
vim600: syn=xml fen fdm=syntax fdl=2 si
|
||
|
|
vim: et tw=78 syn=sgml
|
||
|
|
vi: ts=1 sw=1
|
||
|
|
-->
|