cvs: phpdoc /en/chapters security.xml

gerzson Mon Feb 4 06:51:23 2002 EDT Modified files: /phpdoc/en/chapters security.xml Log: some spelling errors and typos corrected Index: phpdoc/en/chapters/security.xml diff -u phpdoc/en/chapters/security.xml:1.42 phpdoc/en/chapters/security.xml:1.43 --- phpdoc/en/chapters/security.xml:1.42 Mon Jan 21 09:36:58 2002 +++ phpdoc/en/chapters/security.xml Mon Feb 4 06:51:22 2002 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!-- $Revision: 1.42 $ --> +<!-- $Revision: 1.43 $ --> <chapter id="security"> <title>Security</title> @@ -570,13 +570,13 @@ <sect2 id="security.database.storage"> <title>Encrypted Storage Model</title> <simpara> - SSL/SSH protects data traveling from the client to the server, SSL/SSH + SSL/SSH protects data travelling from the client to the server, SSL/SSH does not protect the persistent data stored in a database. SSL is an on-the-wire protocol. </simpara> <simpara> Once an attacker gains access to your database directly (bypassing the - webserver), the stored sensitive data may be exposed or misused unless, + webserver), the stored sensitive data may be exposed or misused, unless the information is protected by the database itself. Encrypting the data is a good way to mitigate this threat, but very few databases offer this type of data encryption. @@ -613,7 +613,7 @@ $result = pg_exec($connection, $query); if (pg_numrows($result) > 0) { - echo "Wellcome, $username!"; + echo "Welcome, $username!"; } else { echo "Authentication failed for $username."; @@ -653,8 +653,9 @@ <![CDATA[ $offset = argv[0]; // beware, no input validation! $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;"; +// with PostgreSQL $result = pg_exec($conn, $query); -// with MySQL: +// with MySQL $result = mysql_query($query); ]]> </programlisting> @@ -663,22 +664,18 @@ is encoded into the URL. The script expects that the incoming <varname>$offset</varname> is decimal number. However, someone tries to break in with appending <function>urlencode</function>'d form of the - following to the URL (PostgreSQL): + following to the URL <informalexample> <programlisting> <![CDATA[ +// in case of PostgreSQL 0; insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd) select 'crack', usesysid, 't','t','crack' from pg_shadow where usename='postgres'; -- -]]> - </programlisting> - </informalexample> - or in case of using MySQL: - <informalexample> - <programlisting> -<![CDATA[ + +// in case of MySQL 0; UPDATE user SET Password=PASSWORD('crack') WHERE user='root'; FLUSH PRIVILEGES; @@ -698,13 +695,14 @@ </note> <para> A feasible way to gain passwords is to circumvent your search result pages. - What the attacker has to do is only trying if there is a submitted filter - setting handled not properly. These filters are commonly set in a previous - form to customize <literal>WHERE, ORDER BY, LIMIT and OFFSET</literal> - clauses in <literal>SELECT</literal> statements. If your database supports - the <literal>UNION</literal> construct, the attacker may try to append an - entire query to the original one to list passwords from an arbitrary table. - Using encrypted password fields is strongly encouraged. + What the attacker needs only is to try if there is any submitted variable + used in SQL statement which is not handled properly. These filters can be set + commonly in a preceding form to customize <literal>WHERE, ORDER BY, + LIMIT</literal> and <literal>OFFSET</literal> clauses in <literal>SELECT</literal> + statements. If your database supports the <literal>UNION</literal> construct, + the attacker may try to append an entire query to the original one to list + passwords from an arbitrary table. Using encrypted password fields is + strongly encouraged. <example> <title> Listing out articles ... and some passwords (any database server) @@ -714,6 +712,7 @@ $query = "SELECT id, name, inserted, size FROM products WHERE size = '$size' ORDER BY $order LIMIT $limit, $offset;"; +$result = odbc_exec($conn, $query); ]]> </programlisting> </example> @@ -760,6 +759,7 @@ <![CDATA[ // $uid == ' or uid like'%admin%'; -- $query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --"; + // $pwd == "hehehe', admin='yes', trusted=100 " $query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;" ]]> @@ -844,7 +844,7 @@ </listitem> <listitem> <para> - If the application waits for numeric input, consider to verify data + If the application waits for numerical input, consider to verify data with <function>is_numeric</function>, or silently change its type using <function>settype</function>, or use its numeric representation by <function>sprintf</function>. @@ -874,7 +874,7 @@ <listitem> <simpara> Do not print out any database specific information, especially - about the schema, no matter what happens. See also <link + about the schema, by fair means or foul. See also <link linkend="security.errors">Error Reporting</link> and <link linkend="ref.errorfunc">Error Handling and Logging Functions</link>. </simpara>