安全基础理论入门知识参考上一篇《WEB应用安全测试指南蓝队安全测试1》

一、文件 I/O 类

1.1、任意文件上传

漏洞描述：

• 一般情况下文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。文件上传本身是 web 中最为常见的一种功能需求，关键是文件上传之后服务器端的处理、解释文件的过程是否安全。一般的情况有：
  1. 上传文件WEB脚本语言，服务器的WEB容器解释并执行了用户上传的脚
     本，导致代码执行。
  2. 上传文件FLASH策略文件crossdomain.xml，以此来控制Flash在该域下的行为。
  3. 上传文件是病毒、木马文件，攻击者用以诱骗用户或管理员下载执行。
  4. 上传文件是钓鱼图片或包含了脚本的图片，某些浏览器会作为脚本执
     行，可用于实施钓鱼或欺诈。

检查条件：

• 测试目标具有文件上传功能。

检测方法：

• 上传方式根据不同的 web 语言，检测方法也各式各样，以下列举基于 JS
  验证的上传的几种常见的文件上传绕过方法：

  1. 直接删除代码中onsubmit事件中关于文件上传时验证上传文件的相关代码即可。如图：
     

  2. 直接更改文件上传 JS 代码中允许上传的文件扩展名你想要上传的文件扩展名，如图所示：
     

  3. 使用本地提交表单即可，如图所示：
     

  4. 使用 burpsuite 或者是 fiddle 等代理工具提交，本地文件先更改为 jpg，上传时拦截，再把文件扩展名更改为 asp 即可，如图所示：
     

  5. 当然也有不是基于JS验证的上传，例如一些中间件IIS，Nginx,，PHP,FCK编辑器等等的解析漏洞，其上传绕过方式也是多种多样。通过对上传页面进行检查，常见的文件上传检查针对文件类型进行，可以使用手动修改POST包然后添加%00字节用于截断某些函数对文件名的判断。除了修改文件名来绕过类型检查外，还可以修改文件头来伪造文件头，欺骗文件上传检查，如图，修改文件头中的类型来进行绕过：
     

  以上为几种常见的上传，更多的还需自行研究，进行上传绕过。以下为总体的测试流程：

  1、登陆网站，并打开文件上传页面。

  2、点击“浏览”按钮，并选择本地的一个JSP文件（比如hacker.jsp），确认上传。

  3、如果客户端脚本限制了上传文件的类型（比如允许gif文件），则把hacker.jsp更名为hacker.gif；配置HTTP Proxy（burp）进行http请求拦截；重新点击“浏览”按钮，并选择hacker.gift，确认上传。

  4、在WebScarab拦截的HTTP请求数据中，将hacker.gif修改为hacker.jsp，再发送请求数据。

  登陆后台服务器，用命令find / -name hacker.jsp查看hacker.jsp文件存放的路径。如果可以直接以Web方式访问，则构造访问的URL，并通过浏览器访问hacker.jsp，如果可以正常访问，则已经取WebShell，测试结束。如果hacker.jsp无法通过web方式访问，例如hacker.jsp存放在/home/tmp/目录下，而/home/tomcat/webapps目录对应http://www.example.com/，则进行下一步

  5、重复1～3，在burp拦截的HTTP请求数据中，将hacker.gif修改为../tomcat/webapps/hacker.jsp，再发送请求数据。

  6、在浏览器地址栏输入http://www.example.com/hacker.jsp，访问该后门程序，取得WebShell，结束检测。

漏洞等级：

【*高危*】：成功上传恶意文件，并且解析 webshell。

修复方案：

1. 最有效的，将文件上传目录直接设置为不可执行，对于Linux而言，撤销其目录的'x'权限；实际中很多大型网站的上传应用都会放置在独立的存储上作为静态文件处理，一是方便使用缓存加速降低能耗，二是杜绝了脚本执行的可能性；
2. 文件类型检查：建议使用白名单方式，结合MIME Type、后缀检查等方式（即只允许允许的文件类型进行上传）；此外对于图片的处理可以使用压缩函数或resize函数，处理图片的同时破坏其包含的HTML代码；
3. 使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件；
4. 单独设置文件服务器的域名。

1.2、任意文件下载

漏洞描述：

• 任意文件下载漏洞不同于网站目录浏览，此漏洞不仅仅可遍历系统下 web中的文件，而且可以浏览或者下载到系统中的文件，攻击人员通过任意文件下载漏洞可以获取系统文件及服务器的配置文件等等。一般来说，他们利用服务器 API、文件标准权限进行攻击。严格来说，任意文件下载漏洞并不是一种 web漏洞，而是网站设计人员的设计“漏洞”。

检测条件：

• 测试目标具有文件下载功能。

检测方法：

1. 通过web漏洞扫描工具对网站实施扫描可能发现目录遍历或者任意文件下载漏洞，发送一系列”../”字符来遍历高层目录，并且尝试找到系统的配置文件或者系统中存在的敏感文件。
2. 也可通过判断网站语言，并根据其url中部分提供的参数，进行构造相关的路径信息，如收集到网站中间件版本为apache，则想办法构造../../../WEB-INF/web.xml等，然后查看其是否可被下载出来。随后可构造下载系统文件。

漏洞等级：

【*高危*】:下载系统的任意文件，对系统进行进一步的入侵。

修复方案：

1. 净化数据：对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或者空字符的参数进行拒绝。
2. web应用程序可以使用chroot环境包含被访问的web目录，或者使用绝对路径+参数来访问文件目录，时使其即使越权也在访问目录之内。www目录就是一个chroot应用. 由chroot创造出的那个根目录，叫做“chroot监狱”（所谓"监狱"就是指通过chroot机制来更改某个进程所能看到的根目录，即将某进程限制在指定目录中，保证该进程只能对该目录及其子目录的文件有所动作，从而保证整个服务器的安全，详细具体chroot的用法，可参考：http://blog.csdn.net/frozen_fish/article/details/2244870
3. 任意文件下载漏洞也有可能是web所采用的中间件的版本低而导致问题的产生，例如ibm的websphere的任意文件下载漏洞，需更新其中间件的版本可修复。
4. 要下载的文件地址保存至数据库中。
5. 文件路径保存至数据库，让用户提交文件对应ID下载文件。
6. 用户下载文件之前需要进行权限判断。
7. 文件放在web无法直接访问的目录下。
8. 不允许提供目录遍历服务。
9. 公开文件可放置在web应用程序下载目录中通过链接进行下载。

1.3、文件包含

漏洞描述：

• 文件包含是指程序代码在处理包含文件的时候没有严格控制。导致用户可以构造参数包含远程代码在服务器上执行，并得到网站配置或者敏感文件，进而获取到服务器权限，造成网站被恶意删除，用户和交易数据被篡改等一系列恶性后果。主要包括本地文件包含和远程文件包含两种形式，由于开发人员编写源码，开放着将可重复使用的代码插入到单个的文件中，并在需要的时候将它们包含在特殊的功能代码文件中，然后包含文件中的代码会被解释执行。由于并没有针对代码中存在文件包含的函数入口做过滤，导致客户端可以提交恶意构造语句提交，并交由服务器端解释执行。文件包含攻击中 WEB 服务器源码里可能存在 inlcude()此类文件包含操作函数，可以通过客户端构造提交文件路径，是该漏洞攻击成功的最主要原因。

检测条件：

1. 测试目标采用 include 等文件包含函数通过动态变量的方式引入需要包含的文件。
2. 用户能够动态控制该变量。

检测方法：

1. 常见的文件包含漏洞，出现在以 PHP 语言开发的网站中，例如以下代码采用了指定用户的名称，并将该名称包含在要呈现的 PHP 页面中，如下：

<?php
include($_GET['name']);
?>

2. 通过提供给 name 一个恶意数值，导致程序包含来自外部站点的文件，从而可以完全控制动态包含指令。比如提交：http://test.com/test.php?name=../../../etc/passwd
3. 如果我们为动态包含指令指定一个有效文件，那么该文件的内容会被传递给 PHP 解析器,可直接在远程服务器上执行任意 PHP 文件。如果我们能够指定一条路径来指向被自己控制的远程站点，那么动态 include 指令就会执行提供的任意恶意代码，也就是所谓的“远程文件包含”。
4. 构造类型复杂，还需自行研究，进行文件包含的利用。

漏洞等级：
【*高危】：读取系统的敏感信息或者包含恶意文件控制服务器。

修复方案：

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

二、接口安全类

2.1、短信炸弹

漏洞描述：

• 短信轰炸攻击时常见的一种攻击，攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时，系统会一直发送短信，这样就造成了短信轰炸的漏洞。

检测条件：

• 测试目标具有短信发送的功能。

检测方法：

1. 手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。
2. 通过利用 burp suite 或者其它抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到 10 条以上短信，如果收到大量短信，则说明存在该漏洞。

风险等级：

【*中危】：对任意手机号码进行轰炸。
【低危】：仅对当前用户手机号码进行轰炸

修复方案：

1. 合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过 3-5次，并且可对发送的时间间隔做限制。
2. 页面前台代码编写时，加入禁止针对同一手机号进行的次数大于 N 次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制。

2.2、邮件炸弹

漏洞描述：

• 应用系统未限制邮件的发送次数和频率，造成短时间内大量邮件发送至接收者邮箱，造成大量垃圾邮件。

检测条件：

• 测试目标具有邮件发送的功能。

检测方法：

1. 手工找到有关网站注册页面，认证页面，是否具有邮件发送页面，如果有，则进行下一步。
2. 通过利用 burp suite 或者其它抓包截断工具，抓取发送邮件的数据包，并且进行重放攻击，查看邮箱是否在短时间内连续收到 10 条以上邮件，如果收到大量邮件，则说明存在该漏洞。

风险等级：

【*中危】：对任意邮箱进行轰炸。
【低危】：仅对当前用户邮箱进行轰炸。

修复方案：

1. 合理配置后台邮件服务器的功能，对于同一邮箱，发送次数不超过 3-5 次，并且可对发送的时间间隔做限制。
2. 页面前台代码编写时，加入禁止针对同一邮箱账号进行的次数大于 N 次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制。

2.3、短信内容可控

漏洞描述：

• 应用系统未限制短信的发送内容，造成短信内容客户端可控。

检测条件：

• 测试目标具有短信内容编辑的功能或短信内容由客户端发出。

检测方法：

• 在客户端编辑短信内容，看是否过滤特殊字符或内容。

风险等级：
【*高危*】：短信内容可控，可对任意手机号码发送。
【*中危】：短信内容可控，仅对当前用户手机号码发送。

修复方案：

1. 建议在不影响业务的前提下，禁止客户端编辑短信内容。

2.4、邮件内容可控

漏洞描述：

• 应用系统未限制邮件的发送内容，造成邮件内容客户端可控。
  检测条件：
• 测试目标具有邮件内容编辑的功能或邮件内容由客户端发出。

检测方法：

• 在客户端编辑邮件内容，看是否过滤特殊字符或内容。

风险等级：
【*高危*】：邮件内容可控，可对任意邮箱发送。
【*中危】：邮件内容可控，仅对当前用户邮箱发送。

修复方案：

1. 建议在不影响业务的前提下，禁止客户端编辑邮件内容。

三、逻辑流程类

3.1、越权

漏洞描述：

• 越权访问：这类漏洞是指应用在检查授权（Authorization）时存在纰漏，使得攻击者在获得低权限用户帐后后，可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的高权限功能。在实际的代码安全审查中，这类漏洞往往很难通过工具进行自动化检测，因此在实际应用中危害很大。其与未授权访问有一定差别。

检测条件：

1. 测试目标存在不同级别的权限（角色）
2. 可通过用户名登录网站内进行功能的操作。
3. 测试目标正常运行。

检测方法：

1. 以超管 admin（高权限用户） 身份登录系统
2. 找 到 一 个 只 有 超 管 （ 高 权 限 ） 才 有 的 功 能 的 链 接 ， 比如:“http://localhost/mywebappname/userManage/userList.do” , 显示出所有的 user，并复制此链接。
3. 以普通用户登陆进系统,在地址栏输入: userManage/userList.do，如果可以查看到其所有的 user，则就造成了，普通用户的越权访问。
   • 检测说明：权限管理测试更多的是进行人工分析，自动化工具无法了解页面的具体应用场景以及逻辑判断过程。因此这里的测试需要首先测试人员理解测试业务系统的逻辑处理流程，并在此基础上进行如下测试。这里有几个测试的参考依据：
     • 页面是否进行权限判断；
     • 页面提交的资源标志是否与已登陆的用户身份进行匹配比对；
     • 用户登陆后，服务器端不应再以客户端提交的用户身份信息为依据，而应以会话中保存的已登陆的用户身份信息为准；
     • 必须在服务器端对每个请求 URL 进行鉴权，而不能仅仅通过客户端的菜单屏蔽或者按钮 Disable 来限制。

风险等级：

【*高危*】：任意水平或垂直越权

修复方案：

• 对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作，建议在服务端对请求的数据和当前用户身份做校验检查。

3.2、未授权访问

漏洞描述：

• 未授权访问漏洞:是在攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，即可通过直接输入网站控制台主页面地址，或者不允许查看的链接便可进行访问，同时进行操作。

检测条件：

1. 测试目标具有登录页面，或者具有不允许访问的目录或功能。
2. 不用登录，可通过链接直接访问用户页面功能。

检测方法：

1. 通过对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器进行打开。
2. 也可以通过 web 扫描工具进行扫描，爬虫得到相关地址链接，进行直接访问，如果未进行跳转到登录页面，则可判断为存在未授权访问漏洞。

风险等级：

【*高危*】：认证模式可绕过，不登录即可通过 URL 或其他方式访问登陆后页面。

修复方案：

• 在系统中，加入用户身份认证机制或者 tonken 验证，防止可被直接通过连接就可访问到用户的功能进行操作，简而言之，一定对系统重要功能点增加权限控制，对用户操作进行合法性验证。

3.3、CSRF 漏洞

漏洞描述：

• 跨站请求伪造攻击：Cross-Site Request Forgery（CSRF），攻击者在用户浏览网页时，利用页面元素（例如 img 的 src），强迫受害者的浏览器向 Web 应用服务器发送一个改变用户信息的 HTTP 请求。CSRF 攻击可以从站外和站内发起。从站内发起 CSRF 攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像 URL 是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。从站外发送请求，则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的 htm 页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求。威胁描述：攻击者使用 CSRF 攻击能够强迫用户向服务器发送请求，导致用户信息被迫修改，甚至可引发蠕虫攻击。如果恶意用户能够知道网站管理后台某项功能的 URL，就可以直接攻击管理员，强迫管理员执行恶意用户定义的操作。

检测条件：

1. 测试目标正常运行。
2. 存在数据提交的所有功能点。

检测方法：

1. 检查网站是否有使用 token 或 referer 参数，若有上述参数，删除参数值查看返回是否有报错。
2. 修改 referer 值，保留原 host 关键词，尝试绕过 referer 检测。
3. 伪造 referer。
   以下来举例说明其中一种检测以及攻击方案：
   1）使用 BurpSuite 对关键操作进行抓包，右键选择“Engagement tools >Generate CSRF PoC”进行 CSRF 攻击脚本的构造。
   
   2）生成脚本后选择“Test in browser”进行 CSRF 验证。
   

风险等级：

【*高危*】：核心系统关键操作（账户操作，审批确认…）。
【*中危】：普通系统关键操作（账户操作，审批确认…）。

修复方案：

1. 通过 referer 判断页面来源进行 CSRF 防护，该方式无法防止站内 CSRF攻击及 referer 字段伪造。
2. 重要功能点使用动态验证码进行 CSRF 防护。
3. 通过 token 方式进行 CSRF 防护。
4. 为每个 session 创建唯一的随机字符串，并在受理请求时验证。

四、数据验证类

4.1、SQL 注入

漏洞描述：

• SQL 注入：就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令。具体来说，它是利用现有应用程序，将（恶意）SQL 命令注入到后台数据库引擎执行的能力，它可以通过在 Web 表单中输入（恶意）SQL 语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行 SQL 语句。 造成 SQL 注入漏洞原因有两个：一个是没有对输入的数据进行过滤（过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。

检测条件：

• 测试目标具有交互功能模块，涉及到参数查询、提交等。

检测方法：

1. 通过web漏洞扫描工具进行对网站爬虫后得到的所有链接进行检测，或者手工判断是否存在注入点，一旦确认存在漏洞，可利用自动化工具sqlmap去尝试注入。
   几种常见的判断方法：

   • 数字型
     http://host/test.php?id=100 and 1=1 返回成功
     http://host/test.php?id=100 and 1=2 返回失败

   • 字符型
     http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功
     http://host/test.php?name=rainman ’ and ‘1’=‘2 返回失败

   • 搜索型
     搜索型注入：简单的判断搜索型注入漏洞是否存在的办法是：
     1）先搜索（’），如果出错，说明90%存在这个漏洞。
     2）然后搜索（%），如果正常返回，说明95%有洞了。
     3）然后再搜索一个关键字，比如（2006）吧，正常返回所有2006相关的信息。
     4）再搜索（2006%'and 1=1 and '%'='）和（2006%'and 1=2 and '%'='）。

   • 绕过验证（常见的为管理登陆）也称万能密码

     1. 用户名输入： ‘ or 1=1 or ‘ 密码：任意
     2. Admin’ - -（或‘ or 1=1 or ‘ - -）(admin or 1=1 --) (MS SQL)(直接输入用户名，不进行密码验证)
     3. 用户名输入：admin 密码输入：’ or ‘1’=’1 也可以
     4. 用户名输入：admin' or 'a'='a 密码输入：任意
     5. 用户名输入：‘ or 1=1 - -
     6. 用户名输入：admin‘ or 1=1 - - 密码输入：任意
     7. 用户名输入：1'or'1'='1'or'1'='1 密码输入：任意
     8. 不同的SQL服务器连结字符串的语法不同，比如MS SQL Server使用符号+来连结字符串，而Oracle使用符号||来连结：
        http://host/test.jsp?ProdName=Book’ 返回错误
        http://host/test.jsp?ProdName=B’+’ook 返回正常
        http://host/test.jsp?ProdName=B’||’ook 返回正常说明有 SQL 注入

   • 排序型：orderby参数或者被排序的参数
     orderby=desc,1/1 返回正常
     orderby=desc,1/0 返回错误

2. 如果应用程序已经过滤了’和+等特殊字符，我们仍然可以在输入时过把字符转换成URL编码（即字符ASCII码的16进制）来绕过检查。

风险等级：

【*高危*】：存在 SQL 注入，无论能否爆出数据。

修复方案：

1. SQL改用预编译查询语句。
2. 过滤用户输入的参数中的特殊符号，如’”<>~！@#￥%&()_-=+等、过滤常见的sql函数，如select、from、where、substr、ascii、if、case、when等。
3. Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不允许操作其他数据库。
4. 设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。

4.2、XSS

漏洞描述：

• 跨站脚本攻击的英文全称是 Cross Site Script，为了和样式表区分，缩写为 XSS。发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击,它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意用户的特殊目的。已知的跨站脚本攻击漏洞有三种：1）存储式；2）反射式；3）基于 DOM。
  1. 存储型跨站脚本攻击涉及的功能点：用户输入的文本信息保存到数据库中，并能够在页面展示的功能点，例如用户留言、发送站内消息、个人信息修改等功能点。
  2. 反射型跨站脚本攻击涉及的功能点：URL 参数需要在页面显示的功能点都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能点。
  3. 基于 DOM 跨站脚本攻击涉及的功能点：涉及 DOM 对象的页面程序，包括
     （不限这些）：
     document.URL
     document.URLUnencoded
     document.location
     document.referrer
     window.location

检测条件：

• 测试目标存在参数输入，或者以 POST 方式提交参数，显示为表单方式，假设为 name=value。
• 在某种情况下，用户输入被重新显示在网页上，包括名字、帐号、检索结果等等（说明目标网站服务器并没有对用户提交数据检测）

检测方法：

1. GET 方式跨站脚本：
   1）在 输 入 的 参 数 后 逐 条 添 加 以 下 语 句 ， 以 第 一 条 为 例 ， 输 入
   http://www.exmaple.com/page.xxx?name=<script>alert(123456)</script> 只要其中一条弹出显示 123456 的告警框，就说明存在跨站漏洞，记录漏洞，停止测试。

   2）如果没有弹出显示 123456 的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件”。

   3）查 找 网 页 源 文 件 中 是 否 包 含 完 整 的 字 符 串<script>alert(123456)</script>，则不管有没有弹出显示 123456 的告警框，都表明存在跨站脚本漏洞。

   4）由于有些 HTML 元素（比如<textarea>或”）会影响脚本的执行，所以不一定能够正确弹出 123456 告警框，需要根据返回网页源文件的内容，构造 value的值，比如：
   

2. Post 方式跨站脚本：
   1） 在POST 表单中逐条输入以下语句，只要其中一条弹出显示 123456 的对话框，就说明存在跨站漏洞，记录漏洞，停止测试。
   2）<script>alert(123456)</script>
   3）[img]javascript:alert(123456);[/img]
   4）如果没有弹出显示 123456 的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件”
   5）查 找 网 页 源 文 件 中 是 否 包 含 完 整 的 字 符 串<script>alert(123456)</script>，则不管有没有弹出显示 123456 的告警框，都表明存在跨站脚本漏洞。
   6）由于有些 HTML 元素（比如或”）会影响脚本的执行，所以不一定能够正确弹出 123456 告警框，需要根据返回网页源文件的内容，构造 value的值，比如
   

风险等级：

【*高危*】：应用中存在存储型跨站。
【*中危】：应用中存在反射型跨站。

修复方案：

• 验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。

  1.输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。

  2.输出编码：数据输出前，确保用户提交的数据已被正确进行 entity 编码，建议对所有字符进行编码而不仅局限于某个子集。

明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如 ISO8859-1 或 UTF 8)。

4.3、URL 重定向

漏洞描述：

• 服务端未对传入的跳转 url 变量进行检查和控制，可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。由于是从可信的站点跳转出去的，用户会比较信任，所以跳转漏洞一般用于钓鱼攻击，通过转到恶意网站欺骗用户输入用户名和密码盗取用户信息，或欺骗用户进行金钱交易；也可能引发的 XSS 漏洞（主要是跳转常常使用 302 跳转，即设置 HTTP 响应头，Locatioin: url，如果 url 包含了 CRLF，则可能隔断了 http 响应头，使得后面部分落到了 http body，从而导致 xss 漏洞）。另外在 struts2 中存在重定向的漏洞，是因为 struts2 由于缩写的导航和重定向前缀“action:”、 “redirect:”、 “redirectAction:”等参数前缀的内容没有被正确过滤导致的开放式重定向漏洞。

检测条件：

• 测试目标具有 URL 跳转链接的地方。

检测方法：

1. 首先找到网站相关 url 中存在跳转链接的参数（如登陆页面）。
2. 在检测的同时，可以修改参数中的合法 URL 为非法 URL，然后查看是否能正常跳转或者通过抓包工具获取其 HTTP 响应头中 Host:的值是否包含了构造的 URL。
3. 如果是 struts2 重定向漏洞，则可通过 web 扫描工具扫描发现，或者手工 验 证 ， 直 接 在 URL 后 添 加 ?redirect:+ 指 定 钓 鱼 链 接 ， 例 如 ：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com 进行验证。

风险等级：

【*中危】：URL 跳转参数可控，且未对参数做白名单限制导致任意地址跳转可被利用钓鱼。

修复方案：

• 对传入的 URL 做有效性的认证，保证该 URL 来自于信任域。限制的方式可参考以下两种：
  1. 限制 Referer（Referer 是 HTTP header 中的字段，当浏览器向 web 服务器发送请求时，一般会带上 Referer，告诉服务器是从哪个页面链接过来的），通过限制 Referer 保证将要跳转 URL 的有效性，避免攻击者生成自己的恶意跳转链接；
  2. 加入有效性验证 Token，保证所有生成的链接都来自于可信域，通过在生成的链接里加入用户不可控的 Token 对生成的链接进行校验。

下一期预告更新：《WEB应用安全测试指南–蓝队安全测试3》主要包含：组件安全类+Jboss 组件漏洞等。

（创作不易，支持打赏，感谢支持）