漏洞名称

SQL注入漏洞

漏洞地址

漏洞等级

高危

漏洞描述

SQL注入是开发者对用户输入的参数过滤不严格，通过把SQL命令插入到Web表单提交、输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令，导致用户输入的数据能够影响预设查询功能的一种技术。它是一种通过在用户可控参数中注入SQL语句，破坏原有的SQL结构，达到编写程序时意料之外结果的攻击行为。

按照构造和提交SQL语句的方式进行划分，SQL注入又分为GET型注入、POST型注入和Cookies型注入。

GET 型 SQL 注入提交数据的方式为 GET , 注入点的位置在 GET 参数部分，通常发生在网页的 URL。

POST 型 SQL 注入使用 POST 方式提交数据，注入点位置在 POST 数据部分，通常发生在表单输入框中。

Cookie 型 SQL 注入HTTP 请求时通常有客户端的 Cookie, 注入点存在 Cookie 的某个字段中。

漏洞成因

Web应用程序对用户输入的数据校验处理不严或者根本没有校验，使用字符串拼接的方式构造SQL语句，同时未对用户可控参数进行足够过滤，致使用户可以拼接执行SQL命令造成SQL注入漏洞。

漏洞危害

1.在有写文件权限的情况下，直接用INTO OUTFILE或者DUMPFILE向Web目录写文件，或者写文件后结合文件包含漏洞达到代码执行的效果。

2.在有读文件权限的情况下，用load_file()函数读取网站源码和配置文件，获取敏感数据。

3.提升权限，获得更高的用户权限或者管理员权限，绕过登录，添加用户，调增用户权限等，从而拥有更多的网站功能。

4.通过注入控制数据库查询出来的数据，控制如模板、缓存等文件的内容来获取权限，或者删除、读取某些关键文件。

5.在可以执行多语句的情况下，控制整个数据库，包括控制任意数据、任意字段长度等。

6.在SQL Server这类数据库中可以直接执行系统命令。

7.数据库原有数据泄露、篡改甚至删除，甚至导致攻击者完全控制服务器。

修复方案

参考资料：

https://github.com/Tencent/secguide/blob/main/Java%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97.md

1. Web后台系统应默认使用预编译绑定变量的形式创建sql语句，保持查询语句和数据相分离。以从本质上避免SQL注入风险。

如使用Mybatis作为持久层框架，应通过#{}语法进行参数绑定，MyBatis 会创建 PreparedStatement 参数占位符，并通过占位符安全地设置参数。

示例：JDBC

String custname = request.getParameter("name");

String query = "SELECT * FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.prepareStatement( query );

pstmt.setString( 1, custname);

ResultSet results = pstmt.executeQuery( );

示例：Mybatis

          select rule_id from scan_rule_sqlmap_tab where application_id=#{applicationId}

2. 应避免外部输入未经过滤直接拼接到SQL语句中，或者通过Mybatis中的传入语句（即使使用，语句直接拼接外部输入也同样有风险。例如中部分参数通过{}传入SQL语句后实际执行时调用的是PreparedStatement.execute()，同样存在注入风险）。

3. 对于表名、列名等无法进行预编译的场景，比如外部数据拼接到order by, group by语句中，需通过白名单的形式对数据进行校验，例如判断传入列名是否存在、升降序仅允许输入“ASC”和“DESC”、表名列名仅允许输入字符、数字、下划线等。

参考示例：

public String someMethod(boolean sortOrder) {

 String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");`

 ...

4.Web应用程序接入数据库服务器使用的用户禁用系统管理员，用户角色应遵循最小权限原则。

5.定期审计数据库执行日志，查看是否存在应用程序正常逻辑之外的SQL语句执行痕迹。

【特别注意】：

Order By 注入修复方案

开发者在编写系统框架时无法使用预编译的办法处理这类参数，只要对输入的值进行白名单比对，基本上就能防御这种注入。

1. 通过正则表达式进行字符串过滤，只允许字段中出现字母、数字、下划线。

2. 通过白名单思路，使用间接对象引用。前端传递引用数字或者字符串等，用于与后端做数组映射，这样可以隐藏数据库数据字典效果，避免直接引用带来的危害。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意文件读取漏洞

漏洞地址

漏洞等级

高危

漏洞描述

攻击者通过Web Server自身的安全问题或不安全的服务器配置可以读取服务器上开发者不允许读取的文件，进而造成诸如非预期读取文件、错误地把代码类文件当作资源文件等情况的发生，读取操作涉及内容包括服务器的各种配置文件、文件形式存储的密钥、服务器信息（包括正在执行的进程信息）、历史命令、网络信息、应用源码及二进制程序等。

漏洞成因

由于一些网站的业务需要,往往需要提供文件读取或下载的一个模块,但如果没有对读取或下载做一个白名单或者限制，可能导致恶意攻击者读取下载一些敏感信息(etc/passwd 等),对服务器做下一步的进攻与威胁。

攻击者通过Web Server自身的安全问题或不安全的服务器配置可以读取服务器上开发者不允许读取的文件，进而造成诸如非预期读取文件、错误地把代码类文件当作资源文件等情况的发生，读取操作涉及内容包括服务器的各种配置文件、文件形式存储的密钥、服务器信息（包括正在执行的进程信息）、历史命令、网络信息、应用源码及二进制程序等。

漏洞危害

通过任意文件下载，可以下载服务器的任意文件，web业务的代码，服务器和系统的具体配置信息，也可以下载数据库的配置信息，以及对内网的信息探测等等。

攻击者通过Web Server自身的安全问题或不安全的服务器配置可以读取服务器上开发者不允许读取的文件，进而造成诸如非预期读取文件、错误地把代码类文件当作资源文件等情况的发生，读取操作涉及内容包括服务器的各种配置文件、文件形式存储的密钥、服务器信息（包括正在执行的进程信息）、历史命令、网络信息、应用源码及二进制程序等。

修复方案

1.php.ini 配置 open_basedir（针对PHP应用程序）。

2.用户输入配置白名单，对文件下载类型进行检查，判断是否为允许下载类型。

3.过滤路径回溯符../，或者直接将..替换成空。对参数进行过滤，依次过滤“.”、“..”、“/”、“”等字符。

4.对于下载文件的目录做好限制，只能下载指定目录下的文件，或者将要下载的资源文件路径存入数据库，附件下载时指定数据库中的id即可，id即对应的资源。

测试过程

复测过程

复测结果

未修复

漏洞名称

SSRF漏洞

漏洞地址

漏洞等级

高危

漏洞描述

SSRF（Server Side Request Forgery，服务端请求伪造）是一种攻击者通过构造数据进而伪造服务器端发起请求的漏洞。因为请求是由内部发起的，所以一般情况下，SSRF漏洞攻击的目标往往是从外网无法访问的内部系统。

SSRF漏洞形成的原因多是服务端提供了从外部服务获取数据的功能，但没有对目标地址、协议等重要参数进行过滤和限制，从而导致攻击者可以自由构造参数，而发起预期外的请求。

漏洞成因

SSRF漏洞形成的原因多是服务端提供了从外部服务获取数据的功能，但没有对目标地址、协议等重要参数进行过滤和限制，从而导致攻击者可以自由构造参数，而发起预期外的请求。

漏洞危害

1.SSRF漏洞可以直接探测网站所在服务器端口的开放情况甚至内网资产情况，如确定该处存在SSRF漏洞，则可以通过确定请求成功与失败的返回信息进行判断服务开放情况。

2.使用Gopher协议攻击Redis、MySQL。

3.PHP-FPM攻击。

4.攻击内网中的脆弱Web应用。

5.自动组装Gopher。

修复方案

1.设置URL白名单或者限制内网IP地址（使用gethostbyname()判断是否为内网IP）。

IPv4地址的内网地址分为三段：

10.0.0.0 ~ 10.255.255.255、172.16.0.0 ~ 172.31.255.255、192.168.0.0 ~ 192.168.255.255。

示例代码：

       private boolean validHost ( String hostname ) {

              try {

                     InetAddress ip = InetAddress.getByName(hostname);

                     if (ip.isSiteLocalAddress()) {

                            return false;

                     }

              } catch (UnknownHostException e) {

                     return false;

              }

              return !filters.contains( hostname );

       }

2.禁用不需要的协议，仅仅允许http和https请求。可以防止类似于file://, gopher://, ftp:// 等引起的问题。

3.限制请求的端口为http常用的端口，比如 80、443、8080、8090。

4.过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。

5.统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。

6.禁止跳转。

测试过程

复测过程

复测结果

未修复

漏洞名称

命令执行漏洞

漏洞地址

漏洞等级

高危

漏洞描述

用户通过浏览器注入一些特殊字符提交执行命令，由于服务端没有针对执行函数做过滤，导致攻击者在没有指定绝对路径的情况下就执行命令，可能会允许攻击者通过改变$PATH或程序执行环境的其他方面来执行恶意构造的代码，改变原本的执行意图，从而执行攻击者指定的命令。

漏洞成因

在各类编程语言中，为了方便程序处理，通常会存在各种执行外部程序的函数，当调用函数执行命令且服务端未对执行函数输入结果做过滤时，导致在没有指定绝对路径的情况下就执行命令，攻击者通过注入恶意命令，造成巨大的危害。

在Web应用中有时候程序员为了考虑灵活性、简洁性，会在代码调用eval函数(PHP函数)去处理，比如当应用在调用一些能将字符串转化成代码的函数时，没有考虑用户是否能控制这个字符串，将造成代码执行漏洞。

由于开发人员编写程序时没有针对代码中可执行的特殊函数入口做过滤，导致客户端可以提交恶意构造语句提交，并交由服务端执行。命令注入攻击中WEB服务器没有过滤类似system()，eval()，exec()，assert()，preg replace() + /e 模式等函数是该漏洞攻击成功的最主要原因。

漏洞危害

攻击者在没有指定绝对路径的情况下就执行命令，可能会允许攻击者通过改变$PATH或程序执行环境的其他方面来执行恶意构造的代码，改变原本的执行意图，从而执行攻击者指定的命令。

修复方案

通用方案

1. 使用低权限用户执行应用程序。

2. 升级组件到最新版本。

3. 配置或代码过滤危险函数，例如eval()、assert()、preg replace()+/e模式等。

PHP

1. 对于eval()和assert()函数一定要保证用户不能轻易接触eval()和assert()的参数或者用正则严格判断输入的数据格式。

2. 对于字符串一定要使用单引号包裹可控代码，并且插入前进行addslashes。

3. 对于preg replace()放弃使用/e修饰符。如果必须要用/e修饰符，请保证第二个参数中，对于正则匹配出的对象，用单引号包裹。

测试过程

复测过程

复测结果

未修复

漏洞名称

XSS漏洞

漏洞地址

漏洞等级

高危

漏洞描述

跨站脚本（Cross-Site Scripting，XSS）是一种网站应用程序的安全漏洞攻击，是代码注入的一种，允许恶意用户将代码注入网页，其他用户在观看网页时会受到影响。这类攻击通常包含HTML和用户端脚本语言。XSS攻击通常是指通过利用网页开发时留下的漏洞，巧妙注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上可以包括Java、VBScript、ActiveX、Flash或者普通的HTML。攻击成功后，攻击者可能得到更高的权限（如执行一些操作）、私密网页内容、会话和Cookie等内容。

跨站脚本攻击是一种迫使Web站点回显可执行代码的攻击技术，而这些可执行代码由攻击者提供、最终为用户浏览器加载。不同于大多数攻击（一般只涉及攻击者和受害者），XSS涉及到三方，即攻击者、客户端与网站。XSS的攻击目标是为了盗取客户端的Cookie或者其他网站用于识别客户端身份的敏感信息。获取到合法用户的信息后，攻击者甚至可以假冒最终用户与网站进行交互。

XSS 全称 (Cross Site Scripting) 跨站脚本攻击， 指攻击者在网页中嵌入客户端脚本(例如 JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的。比如获取用户的Cookie，导航到恶意网站,携带木马等。

XSS又分为存储型、反射型和DOM型。

存储型跨站脚本攻击漏洞是指攻击者注入的跨站脚本长期性地存储到服务器，当任何用户访问存在跨站脚本的页面时，都会遭到跨站脚本攻击。

反射型跨站脚本攻击漏洞是简单地把用户输入的数据“反射”给浏览器。攻击脚本未存储在服务端，客户端每次访问需要携带攻击脚本才能中招。

DOM型跨站脚本攻击漏洞是客户端脚本（一般是 javascript）处理用户输入时，没有做充分的过滤，并且将用户的输入赋给 DOM 树中 某些对象的属性，比如通过 document.write，window.location 等。这些操作支持执行 javascript,造成用户的输入被执行。

漏洞成因

由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤，允许用户在提交的数据中掺入HTML代码（最主要的是“>”、“<”），然后未加编码地输出到第三方用户的浏览器，这些攻击者恶意提交代码会被受害用户的浏览器解释执行。由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤，允许用户在提交的数据中掺入HTML代码（最主要的是“>”、“<”），然后未加编码地输出到第三方用户的浏览器，这些攻击者恶意提交代码会被受害用户的浏览器解释执行。

漏洞危害

获取用户的Cookie，导航到恶意网站,携带木马等。

修复方案

通用方案：

1. 将重要的Cookie标记为 http only，使javascript中的document.cookie语句不能获取到Cookie。

2. 输入检查：

在构造白名单的过程中需要保证在不影响用户体验的同时，尽可能杜绝一切不必要的输入内容，只允许用户输入我们期望的数据。例如：

年龄的textbox中，只允许用户输入数字，而数字之外的字符都过滤掉。

3. 输出检查：

对数据进行html encode处理，过滤移除特殊的html标签。

例如：

过滤javascript事件的标签。

例如：

onclick=，onfocus 等等

建议过滤关键字为：

[1] < 左尖括号

[2] > 右尖括号

[3] " 双引号

[4] ' 单引号

[5] `` 反引号

[6]%百分号

[7](左圆括号

[8])右圆括号

[9];分号

[10]/正斜杠

[11]` 反斜杠

[12] [ 左中括号

[13] ] 右中括号

[14] & 连接符号

[15] # 井号

比如把<编码为<。< span="">

4.其他参考：

富文本过滤库

ruby：             https://github.com/rgrove/sanitize

php：              https://github.com/ezyang/htmlpurifier

javascript：       https://github.com/leizongmin/js-xss

                https://github.com/cure53/DOMPurify

更多：            

https://github.com/search?o=desc&q=xss&ref=searchresults&s=stars&type=Repositories&utf8=%E2%9C%93

PHP

建议采用以下函数进行实体编码或者过滤特殊字符建议采用以下函数进行实体编码或者过滤特殊字符

strip_tags($str, [允许标签])     #从字符串中去除 HTML 和 PHP 标记

htmlentities($str)                  #转义html实体

html_entity_decode($str)            #反转义html实体

addcslashes($str, '字符')            #给某些字符加上反斜杠

stripcslashes($str)                 #去掉反斜杠

addslashes ($str )              #单引号、双引号、反斜线与 NULL加反斜杠

stripslashes($str)              #去掉反斜杠

htmlspecialchars()              #特殊字符转换为HTML实体

htmlspecialchars_decode()       #将特殊的 HTML 实体转换回普通字符

Java

1. 特殊字符替换

public static String html(String content) {

       if(content==null) return "";       

       String html = content;

       html = html.replace( "'", "&apos;");

       html = html.replaceAll( "&", "&");

       html = html.replace( """, """);  //"

       html = html.replace( "t", "  ");// 替换跳格

       html = html.replace( " ", " ");// 替换空格

       html = html.replace("<", "<");

       html = html.replaceAll( ">", ">");

       return html;

}

2. apache工具包common-lang中有一个很有用的处理字符串的工具类，其中之一就是StringEscapeUtils,这个工具类是在2.3版本以上加上的去的，利用它能很方便的进行html,xml,java等的转义与反转义

org.apache.commons.lang3包有个StringEscapeUtils

StringEscapeUtils.unescapeHtml4(str);

3. org.springframework.web.util.HtmlUtils 可以实现HTML标签及转义字符之间的转换。

/** HTML转义 **/ 

String s = HtmlUtils.htmlEscape("

hello world

"); 

System.out.println(s); 

String s2 = HtmlUtils.htmlUnescape(s); 

System.out.println(s2);。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意文件上传漏洞

漏洞地址

漏洞等级

高危

漏洞描述

上传文件的时候，如果服务器端脚本语言，未对上传的文件进行严格的验证和过滤，就有可能上传恶意的脚本文件，从而控制整个网站，甚至是服务器上传文件的时候，如果服务器端脚本语言，未对上传的文件进行严格的验证和过滤，就有可能上传恶意的脚本文件，从而控制整个网站，甚至是服务器。

漏洞成因

在网站运营过程中，不可避免地要对网站的某些页面或者内容进行更新，这个时候需要使用到网站的文件上传功能。如果不对被上传的文件进行限制或者限制被绕过，该功能便有可能会被利用上传可执行文件、脚本到服务器上，进而进一步导致服务器沦陷。

漏洞危害

文件上传在Web业务中很常见，如用户上传头像、编写文章上传图片等。在实现文件上传时，如果后端没有对用户上传的文件做好处理，会导致非常严重的安全问题，如服务器被上传恶意木马或者垃圾文件。如果不对被上传的文件进行限制或者限制被绕过，该功能便有可能会被利用上传可执行文件、脚本到服务器上，进而进一步导致服务器沦陷。

修复方案

1.在服务器后端控制上传文件类型，处理时强制使用随机数改写文件名和文件路径,不要使用用户自定义的文件名和文件路径。

2.在服务器后端建议使用白名单的方法对上传的文件进行过滤，上传的目录不进行解析，只提供下载权限。

3.开源编辑器上传漏洞：若新版编辑器已修复漏洞，请更新编辑器版本。

4.除了以上的方法之外，还可将被上传的文件限制在某一路径下，并在文件上传目录禁止脚本解析。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意文件解析漏洞

漏洞地址

漏洞等级

高危

漏洞描述

文件上传漏洞通常与Web容器的解析漏洞配合利用，常见Web容器有IIS、Nginx、Apache、Tomcat等。

漏洞成因

IIS5.x-6.x

IIS 6中存在两个解析漏洞：“*.asp”文件夹下的所有文件会被当做脚本文件进行解析，文件名为“yu.asp；a.jpg”的文件会被解析为ASP文件，上传“x.asp，a.jpg”文件获取到的后缀为jpg，能够通过白名单的校验。

使用iis5.x-6.x版本的服务器，大多为windows server 2003，网站比较古老，开发语言一般为asp；该解析漏洞也只能解析asp文件，而不能解析aspx文件。

1. 当建立*.asp、*.asa格式的文件夹时，其目录下任意文件都会被iis当作asp文件来解析。

2. 当文件为*.asp;1.jpg时，IIS6.0同样会以ASP脚本来执行。

目录解析(6.0)

形式：www.xxx.com/xx.asp/xx.jpg

原理: 服务器默认会把.asp，.cer，.asa，.cdx目录下的文件都解析成asp文件。

文件解析

形式：www.xxx.com/xx.asp;.jpg

原理：服务器默认不解析;号后面的内容，因此xx.asp;.jpg便被解析成asp文件了。

解析文件类型

IIS6.0 默认的可执行文件除了asp还包含这三种 :

    /test.asa

    /test.cer

    /test.cdx

Apache

Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。比如 test.php.owf.rar “.owf”和“.rar” 这两种后缀是apache不可识别解析,apache就会把xxxx.php.owf.rar解析成php。

在Apache 1.x和Apache 2.x中存在解析漏洞。

Apache在解析文件时有一个原则，当碰到不认识的扩展名时，将会从后向前解析，直到碰到认识的扩展名为止，如果都不认识，则会暴露其源代码。

如：1.php.rar.sa.xs就会被解析为php，可以据此来绕过文件名限制

可以在Apache安装目录下的文件“/conf/mime.types”中配置Apache可以识别的文件名。

Nginx

Nginx的解析漏洞为配置不当造成的问题，在Nginx未配置try_files且FPM未设置security.limit_extensions的场景下，可能出现解析漏洞。

先上传x.jpg文件，再访问x.jpg/1.php，location为.php结尾，会交给FPM处理，此时$fastcgi_script_name的值为x.jpg/1.php；在PHP开启cgi.fix_pathinfo配置时，x.jpg/1.php文件不存在，开始fallback去掉最右边的“/”及后续内容，继续判断x.jpg是否存在；这时若x.jpg存在，则会用PHP处理该文件，如果FPM没有配置security.limit_extensions限制执行文件后缀必须为php，则会产生解析漏洞。

Nginx默认是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。当访问www.xx.com/phpinfo.jpg/1.php这个URL时，$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”，然后构造成SCRIPT_FILENAME传递给PHP CGI，但是PHP为什么会接受这样的参数，并将phpinfo.jpg作为PHP文件解析呢?这就要说到fix_pathinfo这个选项了。如果开启了这个选项，那么就会触发在PHP中的如下逻辑：

PHP会认为SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就会将phpinfo.jpg作为PHP文件来解析了。

对低版本的Nginx可以在任意文件名后添加%00.php进行解析攻击

如：上传图片xx.jpg，然后通过改名为xx.jpg%00.php就会解析为php。

IIS7.5

IIS7.5的漏洞与nginx的类似，都是由于php配置文件中，开启了cgi.fix_pathinfo，而这并不是nginx或者iis7.5本身的漏洞。

当php的配置文件中的选项cgi.fix_pathinfo = 1开启时，当访问http://www.xxx.com/x.txt/x.php

时，若x.php不存在，则PHP会递归向前解析，将x.txt当作php脚本来解析。

IIS中：任意文件名/任意文件名.php就会被解析为php

Nginx中：任意文件名/任意文件名.php就会被解析为php。

漏洞危害

文件解析漏洞配合文件上传漏洞、文件包含漏洞利用，攻击者可以通过上传WebShell控制服务器。

修复方案

IIS 5.x-6.x

1. 目前尚无微软官方的补丁，可以通过自己编写正则，阻止上传xx.asp;.jpg类型的文件名

2. 做好权限设置，限制用户创建文件夹

Apache

1. apache配置文件，禁止.php.这样的文件执行，配置文件里面加入：

    <files </files~ ".(php.|php3.)">

           Order Allow,Deny

           Deny from all

2. 用伪静态能解决这个问题，重写类似.php.*这类文件，打开apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so

  把#号去掉，重启apache,在网站根目录下建立.htaccess文件,代码如下:

    <ifmodule </ifmodulemod_rewrite.c>

           RewriteEngine On

           RewriteRule .(php.|php3.) /index.php

           RewriteRule .(pHp.|pHp3.) /index.php

           RewriteRule .(phP.|phP3.) /index.php

           RewriteRule .(Php.|Php3.) /index.php

           RewriteRule .(PHp.|PHp3.) /index.php

           RewriteRule .(PhP.|PhP3.) /index.php

           RewriteRule .(pHP.|pHP3.) /index.php

           RewriteRule .(PHP.|PHP3.) /index.php

Nginx

1. 修改php.ini文件，将cgi.fix_pathinfo的值设置为0，然后重启php-cgi。此修改会影响到使用PATH_INFO伪静态的应用。

2. 在Nginx配置文件中添加以下代码：

    if ( $fastcgi_script_name ~..*/.*php ) {

    return 403;

    }

这行代码的意思是当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。

或

    location ~* .*.php($|/)

    {

           if ($request_filename ~* (.*).php) {

                  set $php_url $1;

           }

           if (!-e $php_url.php) {

                return 403;

           }

           fastcgi_pass  127.0.0.1:9000;

           fastcgi_index index.php;

           include fcgi.conf;

    }

3.对于存储图片的location{...}，或虚拟主机server{...}，只允许纯静态访问，不配置PHP访问。

IIS 7&7.5

1.配置cgi.pathinfo(php.ini中)为0并重启php-cgi程序。

2.在“Handler Mapping”勾选php-cgi.exe程序的“Invoke handler only if request is mapped to”。

3. 重新配置iis，使用ISAPI的方式(注意：PHP5.3.1已经不支持ISAPI方式)。

测试过程

复测过程

复测结果

未修复