mirror of
https://github.com/php/doc-en.git
synced 2026-03-23 23:32:18 +01:00
115 lines
3.5 KiB
XML
115 lines
3.5 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!-- $Revision$ -->
|
|
<!-- splitted from ./index.xml, last change in rev 1.66 -->
|
|
<chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook">
|
|
<title>User Submitted Data</title>
|
|
<para>
|
|
The greatest weakness in many <acronym>PHP</acronym> programs is not inherent in the
|
|
language itself, but merely an issue of code not being written with
|
|
security in mind. For this reason, you should always take the time
|
|
to consider the implications of a given piece of code, to ascertain
|
|
the possible damage if an unexpected variable is submitted to it.
|
|
<example>
|
|
<title>Dangerous Variable Usage</title>
|
|
<programlisting role="php">
|
|
<![CDATA[
|
|
<?php
|
|
// remove a file from the user's home directory... or maybe
|
|
// somebody else's?
|
|
unlink ($evil_var);
|
|
|
|
// Write logging of their access... or maybe an /etc/passwd entry?
|
|
fwrite ($fp, $evil_var);
|
|
|
|
// Execute something trivial.. or rm -rf *?
|
|
system ($evil_var);
|
|
exec ($evil_var);
|
|
|
|
?>
|
|
]]>
|
|
</programlisting>
|
|
</example>
|
|
</para>
|
|
<para>
|
|
You should always carefully examine your code to make sure that any
|
|
variables being submitted from a web browser are being properly
|
|
checked, and ask yourself the following questions:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<simpara>
|
|
Will this script only affect the intended files?
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
Can unusual or undesirable data be acted upon?
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
Can this script be used in unintended ways?
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
Can this be used in conjunction with other scripts in a negative
|
|
manner?
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
Will any transactions be adequately logged?
|
|
</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
By adequately asking these questions while writing the script,
|
|
rather than later, you prevent an unfortunate re-write when you
|
|
need to increase your security. By starting out with this mindset,
|
|
you won't guarantee the security of your system, but you can help
|
|
improve it.
|
|
</para>
|
|
<para>
|
|
Improve security by disabling convenience settings that obscure input
|
|
data's origin, validity, or integrity. Implicit variable creation and
|
|
unchecked input can lead to vulnerabilities like injection attacks and
|
|
data manipulation.
|
|
</para>
|
|
<para>
|
|
Features like <literal>register_globals</literal> and
|
|
<literal>magic_quotes</literal> (both removed in PHP 5.4.0) once contributed
|
|
to these risks by automatically creating variables from user input and
|
|
escaping data inconsistently. While no longer in PHP, similar risks persist
|
|
if input handling is mismanaged.
|
|
</para>
|
|
<para>
|
|
Enable <link linkend="function.error-reporting">error_reporting(E_ALL)</link> to
|
|
help detect uninitialized variables and validate input. Use strict types
|
|
(<link linkend="language.types.declarations.strict">declare(strict_types=1)</link>,
|
|
introduced in PHP 7) to enforce type safety, prevent unintended type conversions,
|
|
and improving overall security.
|
|
</para>
|
|
</chapter>
|
|
|
|
<!-- 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:"~/.phpdoc/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
|
|
-->
|