Web漏洞知识库

• 目录:

  SQL注入漏洞分析及解决方案
  跨站漏洞分析及解决方案
  远程命令执行漏洞分析及解决方案
  文件包含漏洞分析及解决方案
  HTTP协议头注射漏洞分析及解决方案
  任意文件上传漏洞分析及解决方案
  
  

  SQL注入漏洞

  SQL注入攻击（SQL Injection），简称注入攻击，SQL注入是web开发中最常见的一种安全漏洞。 SQL注入漏洞可以用来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统最高权限.

  SQL注入漏洞原理：

  由于程序没有过滤用户的输入，攻击者通过响服务器提交恶意的SQL查询语句，应用程序接收后错误的将攻击者的输入作为原始SQL查询语句的一部分执行，导致改变了程序原始的SQL查询逻辑，额外的执行了攻击者构造的SQL查询语句。

  SQL注入实例：

  类型1：数字型 $id = $_GET[id]; $sql = “SELECT * FROM “.$tablepre.”announcements WHERE id=$id”; $result = $db->fetchsingleassocbysql( $sql ); $content = $result[‘content’];

  提交 and 1=1， 语句变成select * from tablepre announcements where id = 71 and 1=1 这时语句前值后值都为真，and以后也为真，返回查询到的数据。执行了攻击者额外的SQL查询语句，导致SQL注入漏洞

  类型2：字符型 $search = $_GET[key]; $sql = “SELECT * FROM users WHERE username LIKE ‘%$search%’ ORDER BY username”; $result = $db->fetchsingleassocbysql( $sql ); $content = $result[‘content’];

  提交%’order by id /* 语句变成SELECT * FROM users WHERE username LIKE ‘% %’ order by id /*ORDER BY username通过闭合单引号并闭合后面的原始语句，执行了攻击者额外的SQL语句，导致SQL注入漏洞

  SQL注入的位置：

  无论是内网环境还是外网环境（互联网），B/S架构的Web应用（以下指网站）都直接或者间接地受到各种类型的Web攻击的影响。 
  对于后台数据库来说，以SQL注入攻击危害最为普遍，由于网站服务端语言自身的缺陷与程序员编写代码的安全意识不足，
  攻击者可以将恶意SQL语句注入到正常的数据库操作指令中去，从而使该恶意SQL语句在后台数据库中被解析执行。 
  在SQL注入攻击之前，首先要找到网站中各类与数据库形成交互的输入点。通常情况下，一个网站的输入点包括：
  1.表单提交，主要是POST请求，也包括GET请求。
  2.URL参数提交，主要为GET请求参数。
  3.Cookie参数提交。
  4.HTTP请求头部的一些可修改的值，比如Referer、User_Agent等。
  5.一些边缘的输入点，比如.mp3文件的一些文件信息等。
  服务端从客户端直接或间接获取数据的过程都是一次输入过程， 无论直接或间接，默认情况下输入的数据都应该认为是不安全的。 
  上面列举的几类输入点，只要任何一点存在过滤不严，过滤缺陷等问题， 都有可能发生SQL注入攻击。
  大多数情况下，SQL注入的过程都是由工具完成的， 其中包括大批量注入工具的使用。
  

  SQL注入的危害：

  这些危害包括但不局限于：
  1.数据库信息泄漏：数据库中存放的用户的隐私信息的泄露。
  2.网页篡改：通过操作数据库对特定网页进行篡改。
  3.网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。
  4.数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被窜改。
  5.服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。
  6.破坏硬盘数据，瘫痪全系统。
  一些类型的数据库系统能够让SQL指令操作文件系统，这使得SQL注入的危害被进一步放大。
  

  SQL注入漏洞的解决方案：

  解决SQL注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。 
  1.所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。
  当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
  2.对进入数据库的特殊字符（'"\尖括号&*;等）进行转义处理，或编码转换。
  3.严格限制变量类型，比如整型变量就采用intval()函数过滤，数据库中的存储字段必须对应为int型。
  4.数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
  5.网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
  6.严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
  7.避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
  8.在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。
  9.确认PHP配置文件中的magic_quotes_gpc选项保持开启
  

• 跨站脚本漏洞

  跨站脚本攻击（Cross-site scripting，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、偷取密码、传播恶意代码等攻击行为。 恶意的攻击者将对客户端有危害的代码放到服务器上作为一个网页内容， 使得其他网站用户在观看此网页时，这些代码注入到了用户的浏览器中执行，使用户受到攻击。一般而言，利用跨站脚本攻击，攻击者可窃会话COOKIE从而窃 取网站用户的隐私，包括密码。 XSS攻击使用到的技术主要为HTML和Javascript，也包括VBScript和ActionScript等。XSS攻击对WEB服务器虽无直接 危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。

  跨站脚本漏洞原理:

  攻击者通过网站的输入点嵌入非法的HTML标签与JavaScript脚本并执行以达到在客户端攻击的目的。 攻击者注入的标签与脚本最终都要在客户端执行，攻击的过程实际上都 在客户端的浏览器上发生的。 能在客户端进行跨站的不仅仅是HTML标签与JavaScript脚本，还包含一些其它的客户端应用，比如Flash里的ActionScript脚本也能辅助发起XSS攻击

  跨站脚本漏洞实例:

  类型1：CSS跨站 <IMG STYLE="">//style属性值用户可控或者用户可以直接编辑模板 恶意用户可以提交“xss:expr/*XSS*/ession(alert('XSS'))”作为STYLE标签的属性值，或者在编辑模板的地方， 恶意用户可以将JS代码写入CSS文件，导致跨站漏洞

  类型2：HTML标签跨站 <input type=text name=keyword value="<?echo $_GET[‘evil_content’];>"> 由于程序没有对标签进行转义，恶意用户可以提交 http://www.test.com/search.php? evil_content ="><script>alert(/XSS/)</script>< 执行任意JS代码，导致跨站漏洞

  类型3：Javascript跨站 <script> var UID = '0'; var isLogin = false; var KEY = '';//KEY变量用户可控 var FROMTAG = 1; </script> 用户可以提交： http://www.test.com/news/tag.jsp?key=%27;alert%281%29;// 变量key包含在JavaScript代码段中。原始代码被修改为： <script> var UID = '0'; var isLogin = false; var KEY = '';alert(1);//恶意用户修改了页面输出代码'; var FROMTAG = 1; </script> 导致恶意用户可以控制变量值，将任意JS代码写入到输出页面

  跨站脚本漏洞危害：

  1.钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，
    或者注入钓鱼JavaScript以监控目标网站的表单输入，甚至发起基于DHTML更高级的钓鱼攻击方式。
  2.网站挂马：跨站时利用IFrame嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上，或者弹出恶意网站窗口等方式都可以进行挂马攻击。
  3.身份盗用：Cookie是用户对于特定网站的身份验证标志，XSS可以盗取到用户的Cookie，从而利用该Cookie盗取用户对该网站的操作权限。
  如果一个网站管理员用户Cookie被窃取，将会对网站引发巨大的危害。
  4.盗取网站用户信息：当能够窃取到用户Cookie从而获取到用户身份使，攻击者可以获取到用户对网站的操作权限，从而查看用户隐私信息。
  5.垃圾信息发送：比如在SNS社区中，利用XSS漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群。
  6.劫持用户Web行为：一些高级的XSS攻击甚至可以劫持用户的Web行为，监视用户的浏览历史，发送与接收的数据等等。
  7.XSS蠕虫：XSS 蠕虫可以用来打广告、刷流量、挂马、恶作剧、破坏网上数据、实施DDoS攻击等。
  

  跨站脚本漏洞解决方案：

  1.检查变量是否正确初始化并明确变量类型
  2.不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
  3.不要仅仅在客户端对数据做HTML标签转义以及过滤单引号，双引号等危险字符，关键的过滤步骤也应该在服务端进行。
  4.对输出到页面的数据也要做安全检查，数据库里的值有可能会在一个大网站的多处都有输出，
    即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
  5.在发布应用程序之前测试所有已知的威胁。
  

• 远程命令执行漏洞

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

  远程命令执行漏洞原理：

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

  远程命令执行漏洞实例：

  <?php $log_string = $_GET[‘log’]; system("echo \"".date("Y-m-d H:i:s ")." ".$log_string."\" >> /logs/".$pre."/".$pre.".".date("Y-m-d").".log");} ?> 恶意用户只需要构造xxx.php?log=`id`形式的URL，即可通过浏览器在远程服务器上执行任意系统命令

  远程命令执行漏洞解决方案：

  1.建议假定所有输入都是可疑的，尝试对所有输入提交可能执行命令的构造语句进行严格的检查或者控制外部输入，
    系统命令执行函数的参数不允许外部传递。
  2.不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
  3.不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
  4.对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
  5.在发布应用程序之前测试所有已知的威胁。
  

• 文件包含漏洞

  文件包含漏洞，如果允许客户端用户输入控制动态包含在服务器端的文件，会导致恶意代码的执行及敏感信息泄露，主要包括本地文件包含和远程文件包含两种形式。

  文件包含漏洞原理：

  由于开发人员编写源码，开放着将可重复使用的代码插入到单个的文件中，并在需要的时候将它们包含在特殊的功能代码文件中，然后包含文件中的代码会被解释执 行。由于并没有针对代码中存在文件包含的函数入口做过滤，导致客户端可以提交恶意构造语句提交，并交由服务器端解释执行。 文件包含攻击中WEB服务器源码里可能存在inlcude()此类文件包含操作函数，可以通过客户端构造提交文件路径，是该漏洞攻击成功的最主要原因。

  文件包含漏洞实例：

  例1： <?php include($server_root . '/myapp_header.php');?> 如果 register_globals 设置为 on，那么攻击者通过提供 $server_root 作为请求参数，能够重写 $server_root 的值，从而在一定程度上控制动态包含指令。 例2：以下代码采用了指定用户的模板名称，并将该名称包含在要呈现的 PHP 页面中。 <?php include($_GET['headername']); ?> 攻击者通过提供给 headername 一个恶意数值，导致程序包含来自外部站点的文件，从而可以完全控制动态包含指令。比如提交： http://test.com/test.php?headername=../../../etc/passwd 如果攻击者为动态包含指令指定一个有效文件，那么该文件的内容会被传递给 PHP 解析器,可直接在远程服务器上执行任意PHP文件。 如果攻击者能够指定一条路径来指向被自己控制的远程站点，那么动态 include 指令就会执行由攻击者提供的任意恶意代码，也就是所谓的“远程文件包含”。

  文件包含漏洞解决方案：

  1.严格检查变量是否已经初始化。
  2.建议假定所有输入都是可疑的，尝试对所有输入提交可能可能包含的文件地址，
    包括服务器本地文件及远程文件，进行严格的检查，参数中不允许出现../之类的目录跳转符。
  3.严格检查include类的文件包含函数中的参数是否外界可控。
  4.不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
  5.在发布应用程序之前测试所有已知的威胁。
  

• HTTP协议头注射漏洞

  HTTP 响应头文件中包含未经验证的数据会引发 cache-poisoning、cross-site scripting、cross-user defacement、page hijacking、cookie manipulation 或 open redirect。

  HTTP协议头注射漏洞原理：

  以下情况中会出现 HTTP协议头注射漏洞：
  1.数据通过一个不可信赖的数据源进入 Web 应用程序，最常见的是 HTTP 请求。
  2.数据包含在一个 HTTP 响应头文件里，未经验证就发送给了 Web 用户。
  其中最常见的一种 Header Manipulation 攻击是 HTTP Response Splitting。 
  为了成功地实施 Http Response Splitting 盗取，应用程序必须允许将那些包含 CR（回车，由 %0d 或 \r 指定）
  和 LF（换行，由 %0a 或 \n 指定）的字符输入到头文件中。
  攻击者利用这些字符不仅可以控制应用程序要发送的响应剩余头文件和正文，还可以创建完全受其控制的其他响应。
  

  HTTP协议头注射漏洞实例：

  <?php $location = $_GET['some_location']; header("location: $location"); ?> 假设在请求中提交了一个由标准的字母和数字字符组成的字符串，如 "index.html"，那么包含此 cookie 的 HTTP 响应可能表现为以下形式： HTTP/1.1 200 OK ... location: index.html ... 然而，因为该位置的值由未经验证的用户输入组成，所以仅当提交给 some_location 的值不包含任何 CR 和 LF 字符时，响应才会保留这种形式。

  如果攻击者提交的是一个恶意字符串，比如 : "index.html\r\nHTTP/1.1 200 OK\r\n..."， 那么此 HTTP 响应就会被分割成以下形式的两个响应： HTTP/1.1 200 OK location: index.html HTTP/1.1 200 OK ... 显 然，第二个响应已完全由攻击者控制，攻击者可以用所需的头文件和正文内容构建该响应。 攻击者可以构建任意 HTTP 响应，从而发起多种形式的攻击

  HTTP协议头注射漏洞解决方案：

  如今的许多现代应用程序服务器可以防止 HTTP 头文件感染恶意字符。 
  例如，当新行传递到 header() 函数时，最新版本的 PHP 将生成一个警告并停止创建头文件。 
  如果您的 PHP 版本能够阻止设置带有换行符的头文件，则其具备对 HTTP Response Splitting 的防御能力。
  代码层面常见的解决方案：
  1.严格检查变量是否已经初始化。
  2.禁止header()函数中的参数外界可控。
  

• 任意文件上传漏洞

  允许用户上传任意文件可能会让攻击者注入危险内容或恶意代码，并在服务器上运行。

  任意文件上传漏洞原理：

  由于文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，导致允许攻击者向某个可通过 Web 访问的目录上传任意PHP文件，并能够将这些文件传递给 PHP 解释器，就可以在远程服务器上执行任意PHP脚本。

  任意文件上传漏洞实例：

  以下代码会处理上传的文件，并将它们移到 Web 根目录下的一个目录中。 攻击者可以将任意的PHP源文件上传到该程序中，并随后从服务器中请求这些文件，会在远程服务器上执行恶意文件。 <? if(isset($_POST["form"])) { $uploadfile = "upfiles/".$_FILES['upfile']['name']; move_uploaded_file($_FILES['upfile']['tmp_name'], $uploadfile);//没有检查文件类型就直接上传 print_r($_FILES); die(); } ?>

  即使程序将上传的文件存储在一个无法通过 Web 访问的目录中，攻击者仍然有可能通过向服务器环境引入恶意内容来发动其他攻击。 如果程序容易出现文件包含漏洞，那么攻击者就可能上传带恶意内容的文件，并利用另一种漏洞促使程序读取或执行该文件，形成“二次攻击”。

  任意文件上传漏洞解决方案：

  1.检查是否判断了上传文件类型及后缀
  2.定义上传文件类型白名单，即只允许上传的文件类型
  3.文件上传目录禁止脚本解析