mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-16 00:48:54 +00:00
some spelling errors and typos corrected
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@69463 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Gyozo Papp
parent
fc36af5489
commit
33667d61b7
2 changed files with 44 additions and 44 deletions
|
|
@ -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 @@ if (!ereg('^[^./][^/]*$', $username))
|
|||
<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 @@ $query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
|
|||
$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 @@ else {
|
|||
<![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 @@ $result = mysql_query($query);
|
|||
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 @@ FLUSH PRIVILEGES;
|
|||
</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 @@ FLUSH PRIVILEGES;
|
|||
$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 @@ $query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
|
|||
<![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 @@ $result = mssql_query($query);
|
|||
</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 @@ $query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %
|
|||
<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>
|
||||
|
|
|
|||
|
|
@ -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 @@ if (!ereg('^[^./][^/]*$', $username))
|
|||
<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 @@ $query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
|
|||
$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 @@ else {
|
|||
<![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 @@ $result = mysql_query($query);
|
|||
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 @@ FLUSH PRIVILEGES;
|
|||
</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 @@ FLUSH PRIVILEGES;
|
|||
$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 @@ $query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
|
|||
<![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 @@ $result = mssql_query($query);
|
|||
</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 @@ $query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %
|
|||
<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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue