爱代码也爱生活

Web安全原则1.认证模块必须采用防暴力破解机制，例如：验证码或者多次连续尝试登录失败后锁定帐号或IP。说明：如采用多次连续尝试登录失败后锁定帐号或IP的方式，需支持连续登录失败锁定策略的“允许连续失败的次数”可配置，支持在锁定时间超时后自动解锁。2.对于每一个需要授权访问的页面或servlet的请求都必须核实用户的会话标识是否合法、用户是否被授权执行这个操作，以防止URL

session 数据暴露会话数据常会包含一些个人信息和其它敏感数据。基于这个原因，会话数据的暴露是被普遍关心的问题。一般来说，暴露的范围不会很大，因为会话数据是保存在服务器环境中的，而不是在数据库或文件系统中。因此，会话数据自然不会公开暴露。使用SSL是一种特别有效的手段，它可以使数据在服务器和客户端之间传送时暴露的可能性降到最低。这对于传送敏感数据的应用来说非常重要。SSL在HT

关于包含的一个重要问题是源代码的暴露。产生这个问题主要原因是下面的常见情况： 对包含文件使用.inc的扩展名包含文件保存在网站主目录下Apache未设定.inc文件的类型Apache的默认文件类型是text/plain 上面情况造成了可以通过URL直接访问包含文件。更糟的是，它们会被作为普通文本处理而不会被PHP所解析，这样你的源代码就会显示在用户的浏览器上。 避免这种情况

后门URL是指虽然无需直接调用的资源能直接通过URL访问。例如，下面WEB应用可能向登入用户显示敏感信息：<?php$authenticated = FALSE;$authenticated = check_auth();/* ... */if ($authenticated){ include './sensitive.php';}?>由于sensit

在很多情形下会使用动态包含，此时目录名或文件名中的部分会保存在一个变量中。例如，你可以缓存你的部分动态页来降低你的数据库服务器的负担。<?phpinclude "/cache/{$_GET['username']}.html";?>为了让这个漏洞更明显，示例中使用了$_GET。如果你使用了受污染数据时，这个漏洞同样存在。使用$_GET['username']是一个极端的例子，

一个特别危险的情形是当你试图使用被污染数据作为动态包含的前导部分时：<?phpinclude "{$_GET['path']}/header.inc";?>在这种情形下攻击者能操纵不只是文件名，还能控制所包含的资源。由于PHP默认不只可以包含文件，还可以包含下面的资源（由配置文件中的allow_url_fopen所控制）：<?phpinclude 'http://ww

PHP有一个配置选项叫allow_url_fopen，该选项默认是有效的。它允许你指向许多类型的资源，并像本地文件一样处理。例如，通过读取URL你可以取得某一个页面的内容（HTML）：<?php$contents = file_get_contents('http://www.nowamagic.net/');?>当被污染数据用于include和require的文件指向时，会

使用系统命令是一项危险的操作，尤其在你试图使用远程数据来构造要执行的命令时更是如此。如果使用了被污染数据，命令注入漏洞就产生了。exec()是用于执行shell命令的函数。它返回执行并返回命令输出的最后一行，但你可以指定一个数组作为第二个参数，这样输出的每一行都会作为一个元素存入数组。使用方式如下：<?php$last = exec('ls', $output, $return);

暴力攻击是一种不使用任何特殊手段而去穷尽各种可能性的攻击方式。它的更正式的叫法是穷举攻击——穷举各种可能性的攻击。对于访问控制，典型的暴力攻击表现为攻击者通过大量的尝试去试图登录系统。在多数情况下，用户名是已知的，而只需要猜测密码。尽管暴力攻击没有技巧性可言，但词典攻击似乎有一定的技巧性。最大的区别是在进行猜测时的智能化。词典攻击只会最可能的情况列表中进行穷举，而不像暴力攻击一样去

密码嗅探尽管攻击者通过嗅探（察看）你的用户和应用间的网络通信并不专门用于访问控制，但要意识到数据暴露变得越来越重要，特别是对于验证信息。使用SSL可以有效地防止HTTP请求和回应不被暴露。对任何使用https方案的资源的请求可以防止密码嗅探。最好的方法是一直使用SSL来发送验证信息，同时你可能还想用SSL来传送所有的包含会话标识的请求以防止会话劫持。为防止用户验证信息不致暴

永久登录指的是在浏览器会话间进行持续验证的机制。换句话说，今天已登录的用户明天依然是处于登录状态，即使在多次访问之间的用户会话过期的情况下也是这样。永久登录的存在降低了你的验证机制的安全性，但它增加了可用性。不是在用户每次访问时麻烦用户进行身份验证，而是提供了记住登录的选择。据我观察，最常见的有缺陷的永久登录方案是将用户名和密码保存在一个cookie中。这样做的诱惑是可以理解的——不需

一个与会话暴露类似的问题是会话注入。此类攻击是基于你的WEB服务器除了对会话存储目录有读取权限外，还有写入权限。因此，存在着编写一段允许其他用户添加，编辑或删除会话的脚本的可能。下例显示了一个允许用户方便地编辑已存在的会话数据的HTML表单：  session_start();    ?>          $path = ini_get('sess

你的WEB服务器必须要能够读取你的源确并执行它，这就意味着任意人所写的代码被服务器运行时，它同样可以读取你的源码。在一个共享主机上，最大的风险是由于WEB服务器是共享的，因此其它开发者所写的PHP代码可以读取任意文件。<?php header('Content-Type: text/plain'); readfile($_GET['file']); ?> 通过在你

除了能在共享服务器上读取任意文件之外，攻击者还能建立一个可以浏览文件系统的脚本。由于你的大多数敏感文件不会保存在网站主目录下，此类脚本一般用于找到你的源文件的所在位置。请看下例：  if (isset($_GET['dir']))  {    ls($_GET['dir']);  }  elseif (isset($_GET['file']))  {    ca

没有不会犯错的开发者，PHP的错误报告功能可以协助你确认和定位这些错误，可以提供的这些错误的详细描述，但如果被恶意攻击者看到，这就不妙了。不能让大众看到报错信息，这一点很重要。做到这一点很容易，只要关闭display_errors，当然如果您希望得到出错信息，可以打开log_errors选项，并在error_log选项中设置出错日志文件的保存路径。由于出错报告的级别设定可以导致有些错误无法

关于会话，需要关注的主要问题是会话标识的保密性问题。如果它是保密的，就不会存在会话劫持的风险了。通过一个合法的会话标识，一个攻击者可以非常成功地冒充成为你的某一个用户。一个攻击者可以通过三种方法来取得合法的会话标识：猜测捕获固定PHP生成的是随机性很强的会话标识，所以被猜测的风险是不存在的。常见的是通过捕获网络通信数据以得到会话标识。为了避免会话标识被捕获的风险，可以使用S

使用Cookie而产生的一个风险是用户的cookie会被攻击者所盗窃。如果会话标识保存在cookie中，cookie的暴露就是一个严重的风险，因为它能导致会话劫持。PHP为你处理相关会话管理的复杂过程最常见的cookie暴露原因是浏览器漏洞和跨站脚本攻击（见专题前几部分）。虽然现在并没有已知的该类浏览器漏洞，但是以往出现过几例，其中最有名的一例同时发生在IE浏览器的4.0，

如果你还能记起早期Web应用开发中使用C开发CGI程序的话，一定会对繁琐的表单处理深有体会。当PHP的register_globals配置选项打开时，复杂的原始表单处理不复存在，公用变量会自动建立。它让PHP编程变得容易和方便，但同时也带来了安全隐患。用户输入从何而来？第一个源是 GET、POST 和 COOKIE 数据。一般称为 GPC 数据。此数据的可识别程序依赖于一个有争议的 php

1、一般 1)lamp系统安全设置 2)php.ini安全设置 3)使用MVC框架 2、数据传输 1)在$_GET的$_POST，$_COOKIE，和$_REQUEST中，消毒和验证之前以编程方式操纵数据中包含的所有数据 2)SQL注入定义：代码注入技术，利用一个安全漏洞，在应用程序的数据库层发生。该漏洞是存在的，当用户输入或者不正确的字符串文字转义字符中嵌入SQL

深度防范深度防范原则是安全专业人员人人皆知的原则，它说明了冗余安全措施的价值，这是被历史所证明的。深度防范原则可以延伸到其它领域，不仅仅是局限于编程领域。使用过备份伞的跳伞队员可以证明有冗余安全措施是多么的有价值，尽管大家永远不希望主伞失效。一个冗余的安全措施可以在主安全措施失效的潜在的起到重大作用。回到编程领域，坚持深度防范原则要求您时刻有一个备份方案。如果一个安全措施失

平衡风险与可用性用户操作的友好性与安全措施是一对矛盾，在提高安全性的同时，通常会降低可用性。在你为不合逻辑的使用者写代码时，必须要考虑到符合逻辑的正常使用者。要达到适当的平衡的确很难，但是你必须去做好它，没有人能替代你，因为这是你的软件。尽量使安全措施对用户透明，使他们感受不到它的存在。如果实在不可能，就尽量采用用户比较常见和熟悉的方式来进行。例如，在用户访问受控信息或服务前让他们

过滤是Web应用安全的基础。它是你验证数据合法性的过程。通过在输入时确认对所有的数据进行过滤，你可以避免被污染（未过滤）数据在你的程序中被误信及误用。大多数流行的PHP应用的漏洞最终都是因为没有对输入进行恰当过滤造成的。我所指的过滤输入是指三个不同的步骤：识别输入过滤输入区分已过滤及被污染数据把识别输入作为第一步是因为如果你不知道它是什么，你也就不能正确地过滤它。输入是指所

另外一个Web应用安全的基础是对输出进行转义或对特殊字符进行编码，以保证原意不变。例如，O'Reilly在传送给MySQL数据库前需要转义成O\'Reilly。单引号前的反斜杠代表单引号是数据本身的一部分，而不是并不是它的本义。我所指的输出转义具体分为三步：识别输出 输出转义区分已转义与未转义数据只对已过滤数据进行转义是很有必要的。尽管转义能防止很多常见安全漏洞，但它不能替

在典型的PHP应用开发中，大多数的逻辑涉及数据处理任务，例如确认用户是否成功登录，在购物车中加入商品及处理信用卡交易。数据可能有无数的来源，做为一个有安全意识的开发者，你需要简单可靠地区分两类数据：已过滤数据被污染数据所有你自己设定的数据可信数据，可以认为是已过滤数据。一个你自己设定的数据是任何的硬编码数据，例如下面的email地址数据：$email = 'gonn@now

好奇心是很多攻击者的主要动机，语义URL攻击就是一个很好的例子。此类攻击主要包括对URL进行编辑以期发现一些有趣的事情。例如，如果用户chris点击了你的软件中的一个链接并到达了页面http://example.org/private.php?user=chris, 很自然地他可能会试图改变user的值，看看会发生什么。例如，他可能访问http://example.org/private.ph

有时在除了标准的表单数据外，你还需要让用户进行文件上传。由于文件在表单中传送时与其它的表单数据不同，你必须指定一个特别的编码方式multipart/form-data：一个同时有普通表单数据和文件的表单是一个特殊的格式，而指定编码方式可以使浏览器能按该可格式的要求去处理。允许用户进行选择文件并上传的表单元素是很简单的：该元素在各种浏览器中的外观表现形式各有不同。

跨站脚本攻击是众所周知的攻击方式之一。所有平台上的Web应用都深受其扰，PHP应用也不例外。所有有输入的应用都面临着风险。Webmail，论坛，留言本，甚至是Blog。事实上，大多数Web应用提供输入是出于更吸引人气的目的，但同时这也会把自己置于危险之中。如果输入没有正确地进行过滤和转义，跨站脚本漏洞就产生了。以一个允许在每个页面上录入评论的应用为例，它使用了下面的表单帮助用户进行

跨站请求伪造(CSRF)是一种允许攻击者通过受害者发送任意HTTP请求的一类攻击方法。此处所指的受害者是一个不知情的同谋，所有的伪造请求都由他发起，而不是攻击者。这样，很你就很难确定哪些请求是属于跨站请求伪造攻击。事实上，如果没有对跨站请求伪造攻击进行特意防范的话，你的应用很有可能是有漏洞的。请看下面一个简单的应用，它允许用户购买钢笔或铅笔。界面上包含下面的表单： Item:

制造一个欺骗表单几乎与假造一个URL一样简单。毕竟，表单的提交只是浏览器发出的一个HTTP请求而已。请求的部分格式取决于表单，某些请求中的数据来自于用户。大多数表单用一个相对URL地址来指定action属性： 当表单提交时，浏览器会请求action中指定的URL，同时它使用当前的URL地址来定位相对URL。例如，如果之前的表单是对http://example.org/pat

一个比欺骗表单更高级和复杂的攻击方式是HTTP请求欺骗。这给了攻击者完全的控制权与灵活性，它进一步证明了不能盲目信任用户提交的任何数据。为了演示这是如何进行的，请看下面位于http://example.org/form.php的表单： Please select a color: Red Green Blue 如果用户选择了Red

数据库使用中需要关注的主要问题之一是访问权限即用户名及密码的暴露。在编程中为了方便，一般都会用一个db.inc文件保存，如：<?php $db_user = 'myuser';$db_pass = 'mypass';$db_host = '127.0.0.1'; $db = mysql_connect($db_host, $db_user, $db_pass); ?>

PHP的safe_mode选项的目的是为了解决本小节前后所述的某些问题。但是，在PHP层面上去解决这类问题从架构上来看是不正确的，正如PHP手册所述(http://php.net/features.safe-mode)。当安全模式生效时，PHP会对正在执行的脚本所读取（或所操作）文件的属主进行检查，以保证与该脚本的属主是相同的。虽然这样确实可以防范本章中的很多例子，但它不会影响其它语言编写