一、配置Apache部分。

配置httpd.conf文件
在根配置节加入：

LoadModule fcgid_module modules/mod_fcgid.so
DefaultInitEnv PHPRC "D:/xampp/php/"
DefaultInitEnv PATH "D:/xampp/php;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;"
DefaultInitEnv SystemRoot "C:/Windows"
DefaultInitEnv SystemDrive "C:"
DefaultInitEnv TEMP "C:/WINDOWS/TEMP"
DefaultInitEnv TMP "C:/WINDOWS/TEMP"
DefaultInitEnv windir "C:/WINDOWS"
AddHandler fcgid-script .php

其中“D:/xampp/php”为你的PHP所在目录。

在网站配置节中加入

FCGIWrapper "D:/xampp/php/php-cgi.exe" .php


二、配置PHP部分。

复制xampp/apache/bin/php.ini到xampp/php目录替换

三、配置应用程序部分。

以ThinkPHP框架为例
原.htaccess文件的：

RewriteRule ^(.*)$ index.php/$1 [QSA,PT,L]

改为

RewriteRule ^(.*)$ index.php?s=$1 [QSA,PT,L]


四、常见错误处理

连接MYSQL时出现Can’t create TCP/IP socket (10106)

检查httpd.conf文件中

DefaultInitEnv PHPRC "D:/xampp/php/"
DefaultInitEnv PATH "D:/xampp/php;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;"
DefaultInitEnv SystemRoot "C:/Windows"
DefaultInitEnv SystemDrive "C:"
DefaultInitEnv TEMP "C:/WINDOWS/TEMP"
DefaultInitEnv TMP "C:/WINDOWS/TEMP"
DefaultInitEnv windir "C:/WINDOWS"

保证里面的目录信息都是正确的就可以

.htaccess 中Rewrite规则有问题

Fastcgi模式下，不支持rewrite的目标网址的PATH_INFO的解析，例如

RewriteRule ^(.*)$ index.php/$1 [QSA,PT,L]

转向的目标地址是index.php/Module/Action，则fastcgi会当作实际的目录查找而并非解析index.php文件，所以要根据程序支持将其修改为类似
RewriteRule ^(.*)$ index.php?s=$1 [QSA,PT,L]

相关内容

• 听小韩聊PHP项目开发(3)–切分你的系统
• 听小韩聊PHP项目开发(2)–观察你的项目
• 听小韩聊PHP项目开发(1)–开题的话

原文：http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx

本文译言地址：http://www.yeeyan.com/articles/view/hanguofeng/8955

（特别感谢Neil Carpenter对本文写作提供的帮助）

近期趋势

从去年下半年开始，很多网站被损害，他们在用于生成动态网页的SQL数据库中存储的文本中被注入了恶意的HTML <script>标签。这样的攻击在2008年第一季度开始加速传播，并且持续影响有漏洞的Web程序。
这些Web应用程序有这样一些共同点：

• 使用经典ASP代码的程序
• 使用SQL Server数据库的程序

应用程序代码根据URI请求字符动态地生成SQL查询（http://consoto.com/widgets.asp?widget=sprocket）这体现了一种新的SQL注入（SQL injection）的途径（http://msdn.microsoft.com/en-us/library/ms161953.aspx）。在过去，SQL注入攻击的目标是具有如下特点的特殊Web应用程序：攻击者知道或者可以探测出后台数据库的漏洞或者结构。这样的攻击（指本文讨论的攻击-译者注）不同，因为它是抽象的，对于攻击来说，任何存在于使用URI请求字符串动态创建SQL查询的ASP页面都可能存在。你可以在 http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到更多的技术详情和简单代码。

这样的攻击并非利用了Window、IIS、SQL Server或者其他底层代码的漏洞，而是利用了在这些平台上运行的由程序员自行编写的代码中的漏洞。Microsoft已经对这些攻击进行了彻底的调查，并且发现，他们和以往的Microsoft产品的补丁和0-day漏洞无关。你可以在http://blogs.technet.com/msrc/archive/2008/04/25/questions-about-web-server-attacks.aspx获取跟多的信息。

 正如上面所指出的，这些攻击在近年来呈现一种增长的趋势。这至少与两个因素有关：

第一，有暴力性的恶意攻击工具自动化进行此类操作。SANS在http://isc.sans.org/diary.html?storyid=4294讨论了这类工具。该工具使用搜索引擎来寻找具有SQL注入漏洞的站点。

第二，一个或多个恶意僵尸正在进行SQL注入攻击，用以广泛传播僵尸。SecureWorks在http://www.secureworks.com/research/threats/danmecasprox/讨论了一个案例。

一旦某台服务器被该漏洞所攻击，它将被插入指向某.js文件的恶意<script>标签。虽然这些文件的内容不同，但是他们都尝试利用已经被修复的Micfosoft产品的漏洞或者第三方ActiveX控件的漏洞。由于这些脚本被单独存储，这些脚本就很容易的被更新以利用更新的客户端漏洞，也更容易按照不同浏览器来定制。

给信息技术/数据库管理员的建议

有很多事情是信息技术管理员或者数据库管理员可以采取的，以减少他们的风险和响应他们的代码和平台中可能出现的事件：

• 检查IIS日志和数据表来寻找未知风险的标志。

由于该漏洞利用方式通过URI请求字符串作用，管理员们可以检查IIS日志来查找尝试利用该漏洞的非正常请求。你可以在http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx找到如何手动进行改操作的详细信息。在 http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436有进行自动化操作的工具。

如果IIS日志表明服务器可能已经被侵害，那么下一步要采取的行动就是审计相应的Web应用程序所使用的数据库中的表，并且查找附加在文本内容中的<script>标签。

提示：IIS服务器不应当在生产环境中关闭日志。存储和适当的管理对于IIS日志都是重要的，缺少IIS日志对于响应安全事件是非常困难的。

• 如果运行了使用后端数据库的第三方代码，则考虑不受SQL注入影响的独立软件开发商（ISV，Independent Software Vendors）。

在使用第三方ASP Web程序的情况下，管理员应当联系应用程序厂商来确定他们的产品不受SQL注入攻击的影响。

• 确认Web应用程序所使用的数据库帐户具有最少的权限。

管理员应当确保Web应用程序所使用的SQL用户具有最小的必要权限。Web应用程序不应当以诸如”sysadmin”的服务器管理员权限或者”db_owner”的数据库权限链接。白皮书”在SQL Server 2005中的最优化安全设置和维护”： http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc 提供了关于SQL Server安全的多方面建议。

给Web开发者的建议

有很多优秀的文档论述在编码时如何防御SQL注入攻击。由于这些攻击者leverage有漏洞的Web应用程序代码，所以完全防御他们的唯一方法是解析在代码中存在的漏洞。程序中任何一个使用外部资源（一般指从URI请求字符串）数据来动态生成SQL请求的地方都应当被认为是可疑的。当代码漏洞被识别出来，他们应当被小心的修复。

• 说明-SQL注入、ASP.NET和ADO.NET ：

http://msdn.microsoft.com/en-us/library/bb671351.aspx
同时，上面的文章包含到相关文章”如何在ASP.NET中避免SQL注入” http://msdn.microsoft.com/en-us/library/ms998271.aspx，该文章同时适用于ASP。

这里有一个非常有用的视频（该视频是针对一篇防御文章的，然而链接可能已经无效了）：http://channel9.msdn.com/wiki/default.aspx/SecurityWiki.SQLInjectionLab。

• 关于SQL注入如何实现的简单信息：

http://msdn.microsoft.com/en-us/library/ms161953.aspx

• ASP代码中的SQL注入（与ASP.NET中的并不相同）：

http://msdn.microsoft.com/en-us/library/cc676512.aspx
如何在ASP中执行SQL Server存储过程： http://support.microsoft.com/kb/q164485

• Microsoft安全部门（The Microsoft Security Development Lifecycle,SDL）对SQL注入的防御进行了一些指导。简单来说有三种策略来应对SQL注入攻击：

1. 使用SQL参数查询
2. 使用存储过程
3. 使用SQL仅执行（execute-only）许可

Michael Howard在http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx谈论了这些内容。

同时，编写安全的代码（第二版）也指导了如何防御此类攻击（请浏览399-411页）。

• 减轻SQL注入：使用参数查询（第一部分和第二部分）。使用参数化查询的好处是它将执行的代码（例如SELECT语句）和数据（由程序使用者提供的动态信息）分开。该途径防御了通过用户传递来执行的恶意语句。

第一部分：
http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx

第二部分：
http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx

在经典ASP代码中过滤SQL注入（或者黑名单中的字符），我们将如下的工作认为是实际中临时性的解决方案，因为它治标不治本。（例如，代码仍然是有漏洞的，他仍然可能被绕过过滤机制而被访问到）
IIS团队中的Nazim解释了如何过滤的详细信息：http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx。

如果你仍然不了解从哪里开始，所有使用特定ASP代码访问数据库，尤其是使用由用户提供的数据的代码应当首先被检测。

给最终用户的建议

最终用户（下简称用户-译者注）应当浏览位于http://www.microsoft.com/protect/default.mspx的信息。另外，这里也有一些你可以采取以保护自己的步骤。

• 通常应当有选择的访问网站-但是也需要了解，该漏洞也会影响用户信任的网站。

有选择的访问网站减少了你暴露在漏洞下的风险，当然即使是你所信任的也有可能被攻击。留意不正常的行为，了解面临的风险，并且实施本节提供的其他建议。

• 针对Microsoft和第三方软件，保持安全更新。

由于恶意代码通常利用了已知的漏洞，因此你应当确保你在运行最新进行安全更新过的的Microsoft和第三方软件。Microsoft安全更新可以通过http://update.microsoft.com了解。http://www.microsoft.com/protect/computer/updates/OS.aspx有更多信息。

• 禁用不必要的ActiveX控件和IE加载项。

你应当禁用所有不必要的ActiveX控件和IE加载项。根据KB883256（http://support.microsoft.com/kb/883256）的方法在Windows XP Service Pack2或者更新版本中来实施本步骤：

1. 打开IE。
2. 在”工具”菜单点击管理加载项。
3. 点击加载项的名称。
4. 使用如下的方法：
   • 点击更新ActiveX来使用最新的版本替换该控件。这个方法并非对所有的加载项都可用。
   • 点击”启用”，而后点击”确定”，来启用加载项。
   • 点击”禁用”，而后点击”确定”，来禁用加载项。

你可能需要重启IE来确保在启用/禁用插件的操作成功。
针对更糟的操作系统，根据KB154036（http://support.microsoft.com/kb/154036）的说明进行操作。

• 减少你所使用的第三方浏览器的受攻击风险的步骤。

如果你使用了IE之外的浏览器，那么你应当确保你安装的是最新的安全更新版本，同时你应当禁用了不必要的扩展和加载项。流行浏览器的信息可以在如下链接找到：

Firefox – http://support.mozilla.com/en-US/kb/Firefox+Support+Home+Page
Opera – http://www.opera.com/support/
Safari – http://www.apple.com/support/safari/

• 更新反恶意程序软件

用户应当确保已经安装了杀毒软件和反间谍软件，并且保持他们的更新。你可以在http://www.microsoft.com/protect/computer/antivirus/OS.aspx和http://www.microsoft.com/protect/computer/antispyware/OS.aspx找到更多信息。你可以在 http://onecare.live.com/standard/en-us/install/install.htm得到一份90天使用的Windows Live OneCare杀毒/反间谍软件。

Del.icio.us : SQL Injection, SQL注入, 翻译

相关内容

• [译文]Google AJAX Language API对象参考
• [译文]Google AJAX Language API开发者参考
• [译文]防止CSRF攻击

译言链接：http://www.yeeyan.com/articles/view/hanguofeng/3994
原文链接：http://www.playhack.net/view.php?id=31

概览：

1. Hello World
2. 介绍
3. 关于认证技术
3.1 Cookies Hashing
3.2 HTTP来路
3.3 验证码
4. 一次性令牌
5. 最后的话

1.Hello World

欢迎来到崭新的Playhack.net的新季度开题项目报告。我非常高兴您能够再次回来让我们的c001项目重现。

希望您能喜欢这个新的短篇论文，我邀请你浏览位于http://www.playhack.net的全部新项目。

开始：几乎没有什么，只是一点香烟!:

呐喊：我向我的playhack m8s null,omni,god and emdel,ofc o str0ke大声呐喊!NEX 回来了。

2.介绍

我对跨站请求伪造（Cross Site Request Forgery，即CSRF）技术有一定研究，但是对网站开发者应当采取的措施研究不深。这些日子在编写一个对用户和管理员（这些人对他们的任务并不明晰:P）有高度安全要求的分布式网站程序时，我被这个话题深刻的纠缠了。

针对这种情况，我必须考虑程序最终可能受到的各个方面的可能的攻击威胁。

给我最多麻烦的就是Session欺骗（或者CSRF，你可以按照自己喜欢的方式称呼），因为这种攻击是完全以用户的身份，因此并没有百分百的可能性来防止它。

如果你对我刚才说所的Session欺骗并不太了解，那么你可以阅读：http://www.playhack.net/view.php?id=30

3.可行措施

Ok，从这里开始，我必须假定你对Session欺骗攻击的实施方法已经深刻领会了:P

让我们开始新的继续。

考虑到一个已经登录到网站的受信用户可以完成一些重要的或者私密的操作，攻击者尝试记性一个可能的登录攻击（但是大多数情况下是不可行的）并且得到已经登录用户的Session来实现其巧妙的行为。

为了劫持用户的Seession，入侵者精心构造一个适当的网页，在这个网页中包含了隐藏的JavaScript函数来重新创造一个原始操作表单，但是攻击者却修改了一些表单值，然后攻击者让受攻击者访问该页面，此时页面加载过程会提交上述表单到一个远程页面，以隐秘地完成一个请求（此时受攻击者并不知道），他们用这种方法利用了用户的受信身份。

这种方式简单解释了Session欺骗攻击是如何工作的，但是一个重要的问题是，“我如何避免我的用户成为这种攻击的受害者？”

现在，你可能想到如下的几种方法：

检查Cookies凭据
检查HTTP请求来路
使用验证码
但是经过一些尝试，你会发现这些方法不是我们应当采取的最合适的解决方式，让我们一个个的来看为什么。

3.1 Cookies Hashing

第一个方案可能是解决这个问题的最简单和快捷的方案了，因为攻击者不能够获得被攻击者的Cookies内容，也就不能够构造相应的表单。

这个问题的实现方法与下面的类似。在某些登录页面我们根据当前的会话创建Cookies：

<!– login.php –>
<?php
// Cookie value
$value = “Something from Somewhere”;
// Create a cookie which expires in one hour
setcookie(“cookie”, $value, time()+3600);
?>
<!– EOF –>

在这里，我们在Cookies中使用了散列来使得这个表单可被认证。

<!– form.php –>
<?php
// Hash the cookie
$hash = md5($_COOKIE['cookie']);
?>
<form method=”POST” action=”resolve.php”>
<input type=”text” name=”first_name”>
<input type=”text” name=”last_name”>
<input type=”hidden” name=”check” value=”<?=$hash;?>”>
<input type=”submit” name=”submit” value=”Submit”>
</form>
<!– EOF –>

此时，后台的动态网页部分可以进行如下操作：

     <!– resolve.php –>
      <?php
      // Check if the “check” var exists
      if(isset($_POST['check'])) {
           $hash = md5($_COOKIE['cookie']);
           // Check if the values coincide
           if($_POST['check'] == $hash) {
                do_something();
           } else {
                echo “Malicious Request!”;
           }
      } else {
           echo “Malicious Request!”;
      }
      ?>
      <!– EOF –>

事实上，如果我们不考虑用户的Cookies很容易由于网站中存在XSS漏洞而被偷窃（我们已经知道这样的事情并不少见）这一事实，这是一个很好的应对对CSRF的解决方案。如果我们为用户的每一个表单请求中都加入随机的Cookies，那么这种方法会变得更加安全，但是这并不是十分合适。

3.2 HTTP来路

检测访问来路是否可信的最简单方法是，获得HTTP请求中的来路信息（即名为Referer的HTTP头—译者注）并且检查它来自站内还是来自一个远程的恶意页面：这是一个很好的解决方法，但是由于可以对服务器获得的请求来路进行欺骗以使得他们看起来合法，这种方法不能够有效防止攻击。

让我们来看看为什么这并不是一个合适的方法。

下面的代码展示了HTTP Referer实现方法的一个例子：

     <!– check.php –>
      if(eregi(“www.playhack.net”, $_SERVER['HTTP_REFERER'])) {
           do_something();
      } else {
           echo “Malicious Request!”;
      }
      <!– EOF –>

这个检测则会轻易的忽略掉来自某个攻击者伪造的HTTP Referer欺骗，攻击者可以使用如下代码：

header(“Referer: www.playhack.net”);

或者其他在恶意脚本中伪造HTTP头并发送的方法。

由于HTTP Referer是由客户端浏览器发送的，而不是由服务器控制的，因此你不应当将该变量作为一个信任源。

3.3 验证码

另外一个解决这类问题的思路则是在用户提交的每一个表单中使用一个随机验证码，让用户在文本框中填写图片上的随机字符串，并且在提交表单后对其进行检测。

这个方法曾经在之前被人们放弃，这是由于验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。

你可以在Secunia的站点上获得关于此缺陷的详细信息：http://secunia.com/advisories/19738/ 。

这里是Secunia关于此Bug解释的概述：

“此缺陷是由于处理“mhtml:”的URL处理器重定向引起的。它可以被用来利用从另外一个网站访问当前的文档”

在同一个页面你会找到来自Secunia工作人员的网站测试方法。

事实上，我们知道，这个Bug已经被微软放出的Windows XP和Windows Vista及其浏览器IE6.0的修复包所解决了。

即使他的确出现了安全问题，这么长时间也会有其他的可靠方案出现。

4.一次性令牌

 现在让我们来看经过研究，我希望介绍的最后一种解决方案：在使用这些不可靠的技术后，我尝试做一些不同然而却是更有效的方法。

为了防止Web表单受到Session欺骗（CSRF）的攻击，我决定检测可能被伪装或伪造的每一个项目。因此我需要来创造一次性令牌，来使得在任何情况下都不能够被猜测或者伪装，这些一次性令牌在完成他们的工作后将被销毁。

让我们从令牌值的生成开始：

     <!– start function –>
     <?php
     function gen_token() {
          // Generate the md5 hash of a randomized uniq id
          $hash = md5(uniqid(rand(), true));
          // Select a random number between 1 and 24 (32-8)
          $n = rand(1, 24);
          // Generate the token retrieving a part of the hash starting from
          // the random N number with 8 of lenght
          $token = substr($hash, $n, 8);
          return $token;
     }
     ?>
     <!– EOF –>

 PHP函数uniqid()允许web开发者根据当前的时间（毫秒数）获得一个唯一的ID，这个唯一ID有利于生成一个不重复的数值。

我们检索相应ID值的MD5散列，而后我们从该散列中以一个小于24的数字为开始位置，选取8位字母、

返回的$token变量将检索一个8位长的随机令牌。

现在让我们生成一个Session令牌，在稍后的检查中我们会用到它。

     <!– start function –>
     <?php
     function gen_stoken() {
          // Call the function to generate the token
          $token = gen_token();
          // Destroy any eventually Session Token variable
          destroy_stoken();
          // Create the Session Token variable
          session_register(STOKEN_NAME);
          $_SESSION[STOKEN_NAME] = $token;
     }
     ?>
     <!– EOF –>

 在这个函数中我们调用gen_token()函数，并且使用返回的令牌将其值复制到一个新的$_SESSION变量。

现在让我们来看启动完整机制中为我们的表单生成隐藏输入域的函数：

     <!– start function –>
     <?php
     function gen_input() {
          // Call the function to generate the Session Token variable
          gen_stoken();
          // Generate the form input code
          echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\”
               value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;
     }
     ?>
     <!– EOF –>

我们可以看到，这个函数调用了gen_stoken()函数并且生成在WEB表单中包含隐藏域的HTML代码。

接下来让我们来看实现对隐藏域中提交的Session令牌的检测的函数：

     <!– start function –>
     <?php
     function token_check() {
          // Check if the Session Token exists
          if(is_stoken()) {
               // Check if the request has been sent
               if(isset($_REQUEST[FTOKEN_NAME])) {
                    // If the Form Token is different from Session Token
                    // it’s a malicious request
                    if($_REQUEST[FTOKEN_NAME] != $_SESSION[STOKEN_NAME]) {
                         gen_error(1);
                         destroy_stoken();
                         exit();
                    } else {
                         destroy_stoken();
                    }
               // If it isn’t then it’s a malicious request
               } else {
                    gen_error(2);
                    destroy_stoken();
                    exit();
               }
          // If it isn’t then it’s a malicious request
          } else {
               gen_error(3);
               destroy_stoken();
               exit();
          }
     }
     ?>
     <!– EOF –>

这个函数检测了$_SESSION[STOKEN_NAME]和$_REQUEST[FTOKEN_NAME]的存在性（我使用了$_REQUEST方法来使得GET和POST两种方式提交的表单变量均能够被接受），而后检测他们的值是否相同，因此判断当前表单提交是否是经过认证授权的。

这个函数的重点在于：在每次检测步骤结束后，令牌都会被销毁，并且仅仅在下一次表单页面时才会重新生成。

这些函数的使用方法非常简单，我们只需要加入一些PHP代码结构。

下面是Web表单：

     <!– form.php –>
     <?php
          session_start();
          include(“functions.php”);
     ?>
     <form method=”POST” action=”resolve.php”>
          <input type=”text” name=”first_name”>
          <input type=”text” name=”last_name”>
          <!– Call the function to generate the hidden input –>
          <? gen_input(); ?>
          <input type=”submit” name=”submit” value=”Submit”>
     </FORM>
     <!– EOF –>

 下面是解决的脚本代码：

     <!– resolve.php –>
     <?php
          session_start();
          include(“functions.php”);
          
          // Call the function to make the check
          token_check();
          
          // Your code
          …
     ?>
     <!– EOF –>

你可以看到，实现这样一个检测是十分简单的，但是它可以避免你的用户表单被攻击者劫持，以避免数据被非法授权。

5.结论

让我们对这篇简短的论文做一个结论，你的Web应用程序没有百分百的安全，但是你可以开始避免绝大多数普通的攻击技术。

我希望您关注的另一个要点是，Web开发者不应当忽视一般的程序错误（例如XSS 浏览器漏洞等等），不将这些考虑为对您的用户的潜在威胁是一个巨大的错误：你应该永远记得它们将影响程序的信任性、安全性和互操作性。

Cya!

nexus

（前面的PHP代码是从Seride项目中参考的，该项目地址为：http://projects.playhack.net/project.php?id=3）

相关内容

• SQL注入攻击-来自微软安全博客的建议
• [译文]Google AJAX Language API对象参考
• [译文]Google AJAX Language API开发者参考