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>
