【WEB应用安全测试指南–蓝队安全测试2】--超具体-可直接进行实战！！！亲
安全基础理论入门知识参考上一篇《WEB应用安全测试指南蓝队安全测试1》一、文件 I/O 类
1.1、任意文件上传
毛病形貌：
[*]一样平常情况下文件上传毛病是指用户上传了一个可执行的脚本文件，并通过此脚本文件得到了执行服务器端下令的能力。文件上传本身是 web 中最为常见的一种功能需求，关键是文件上传之后服务器端的处理、解释文件的过程是否安全。一样平常的情况有：
[*]上传文件WEB脚本语言，服务器的WEB容器解释并执行了用户上传的脚
本，导致代码执行。
[*]上传文件FLASH战略文件crossdomain.xml，以此来控制Flash在该域下的行为。
[*]上传文件是病毒、木马文件，攻击者用以诱骗用户或管理员下载执行。
[*]上传文件是垂纶图片或包罗了脚本的图片，某些浏览器会作为脚本执
行，可用于实行垂纶或敲诈。
检查条件：
[*]测试目的具有文件上传功能。
检测方法：
[*] 上传方式根据差别的 web 语言，检测方法也各式各样，以下列举基于 JS
验证的上传的几种常见的文件上传绕过方法：
[*] 直接删除代码中onsubmit变乱中关于文件上传时验证上传文件的相关代码即可。如图：
https://i-blog.csdnimg.cn/direct/2742b2db374e491083e32d469f4a4d11.png
[*] 直接更改文件上传 JS 代码中答应上传的文件扩展名你想要上传的文件扩展名，如图所示：
https://i-blog.csdnimg.cn/direct/87399ef6522d4b4490559af3356bdcb1.png
[*] 利用本地提交表单即可，如图所示：
https://i-blog.csdnimg.cn/direct/db9919aff1504814b4bffdc22d0bcfd8.png
[*] 利用 burpsuite 大概是 fiddle 等署理工具提交，本地文件先更改为 jpg，上传时拦截，再把文件扩展名更改为 asp 即可，如图所示：
https://i-blog.csdnimg.cn/direct/8ce83e74455242d891a8f9b47d6b8b2c.png
[*] 固然也有不是基于JS验证的上传，比方一些中间件IIS，Nginx,，PHP,FCK编辑器等等的剖析毛病，其上传绕过方式也是多种多样。通过对上传页面进行检查，常见的文件上传检查针对文件类型进行，可以利用手动修改POST包然后添加%00字节用于截断某些函数对文件名的判定。除了修改文件名来绕过类型检查外，还可以修改文件头来伪造文件头，欺骗文件上传检查，如图，修改文件头中的类型来进行绕过：
https://i-blog.csdnimg.cn/direct/de5564f6041c4c6294b7dadf4f5f57e0.png
以上为几种常见的上传，更多的还需自行研究，进行上传绕过。以下为总体的测试流程：
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。
修复方案：
[*]最有用的，将文件上传目次直接设置为不可执行，对于Linux而言，打消其目次的'x'权限；实际中很多大型网站的上传应用都会放置在独立的存储上作为静态文件处理，一是方便利用缓存加速降低能耗，二是杜绝了脚本执行的可能性；
[*]文件类型检查：建议利用白名单方式，结合MIME Type、后缀检查等方式（即只答应答应的文件类型进行上传）；别的对于图片的处理可以利用压缩函数或resize函数，处理图片的同时粉碎其包罗的HTML代码；
[*]利用随机数改写文件名和文件路径，使得用户不能容易访问本身上传的文件；
[*]单独设置文件服务器的域名。
1.2、任意文件下载
毛病形貌：
[*]任意文件下载毛病差别于网站目次浏览，此毛病不但仅可遍历系统下 web中的文件，而且可以浏览大概下载到系统中的文件，攻击职员通过任意文件下载毛病可以获取系统文件及服务器的设置文件等等。一样平常来说，他们利用服务器 API、文件标准权限进行攻击。严格来说，任意文件下载毛病并不是一种 web毛病，而是网站设计职员的设计“毛病”。
检测条件：
[*]测试目的具有文件下载功能。
检测方法：
[*]通过web毛病扫描工具对网站实行扫描可能发现目次遍历大概任意文件下载毛病，发送一系列”../”字符来遍历高层目次，并且实验找到系统的设置文件大概系统中存在的敏感文件。
[*]也可通过判定网站语言，并根据其url中部门提供的参数，进行构造相关的路径信息，如收集到网站中间件版本为apache，则想办法构造../../../WEB-INF/web.xml等，然后查看其是否可被下载出来。随后可构造下载系统文件。
毛病品级：
【*高危*】:下载系统的任意文件，对系统进行进一步的入侵。
修复方案：
[*]净化数据：对用户传过来的文件名参数进行硬编码或同一编码，对文件类型进行白名单控制，对包罗恶意字符大概空字符的参数进行拒绝。
[*]web应用程序可以利用chroot情况包罗被访问的web目次，大概利用绝对路径+参数来访问文件目次，时使其即使越权也在访问目次之内。www目次就是一个chroot应用. 由chroot创造出的谁人根目次，叫做“chroot监狱”（所谓"监狱"就是指通过chroot机制来更改某个进程所能看到的根目次，即将某进程限定在指定目次中，保证该进程只能对该目次及其子目次的文件有所动作，从而保证整个服务器的安全，具体具体chroot的用法，可参考：http://blog.csdn.net/frozen_fish/article/details/2244870
[*]任意文件下载毛病也有可能是web所采用的中间件的版本低而导致问题的产生，比方ibm的websphere的任意文件下载毛病，需更新其中间件的版本可修复。
[*]要下载的文件所在保存至数据库中。
[*]文件路径保存至数据库，让用户提交文件对应ID下载文件。
[*]用户下载文件之前需要进行权限判定。
[*]文件放在web无法直接访问的目次下。
[*]不答应提供目次遍历服务。
[*]公开文件可放置在web应用程序下载目次中通过链接进行下载。
1.3、文件包罗
毛病形貌：
[*]文件包罗是指程序代码在处理包罗文件的时间没有严格控制。导致用户可以构造参数包罗长途代码在服务器上执行，并得到网站设置大概敏感文件，进而获取到服务器权限，造成网站被恶意删除，用户和生意业务数据被篡改等一系列恶性结果。重要包罗本地文件包罗和长途文件包罗两种形式，由于开辟职员编写源码，开放着将可重复利用的代码插入到单个的文件中，并在需要的时间将它们包罗在特殊的功能代码文件中，然后包罗文件中的代码会被解释执行。由于并没有针对代码中存在文件包罗的函数入口做过滤，导致客户端可以提交恶意构造语句提交，并交由服务器端解释执行。文件包罗攻击中 WEB 服务器源码里可能存在 inlcude()此类文件包罗操作函数，可以通过客户端构造提交文件路径，是该毛病攻击成功的最重要原因。
检测条件：
[*]测试目的采用 include 等文件包罗函数通过动态变量的方式引入需要包罗的文件。
[*]用户可以或许动态控制该变量。
检测方法：
[*]常见的文件包罗毛病，出现在以 PHP 语言开辟的网站中，比方以下代码采用了指定用户的名称，并将该名称包罗在要呈现的 PHP 页面中，如下：
<?php
include($_GET['name']);
?>
[*]通过提供给 name 一个恶意数值，导致程序包罗来自外部站点的文件，从而可以完全控制动态包罗指令。好比提交：http://test.com/test.php?name=../../../etc/passwd
[*]如果我们为动态包罗指令指定一个有用文件，那么该文件的内容会被传递给 PHP 剖析器,可直接在长途服务器上执行任意 PHP 文件。如果我们可以或许指定一条路径来指向被本身控制的长途站点，那么动态 include 指令就会执行提供的任意恶意代码，也就是所谓的“长途文件包罗”。
[*]构造类型复杂，还需自行研究，进行文件包罗的利用。
毛病品级：
【*高危】：读取系统的敏感信息大概包罗恶意文件控制服务器。
修复方案：
[*]PHP：设置 php.ini 关闭长途文件包罗功能(allow_url_include = Off)
[*]严格检查变量是否已经初始化。
[*]建议假定所有输入都是可疑的，实验对所有输入提交可能可能包罗的文件所在，包罗服务器本地文件及长途文件，进行严格的检查，参数中不答应出现../之类的目次跳转符。
[*]严格检查 include 类的文件包罗函数中的参数是否外界可控。
[*]不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
[*]在发布应用程序之前测试所有已知的威胁。
二、接口安全类
2.1、短信炸弹
毛病形貌：
[*]短信轰炸攻击时常见的一种攻击，攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时，系统会一直发送短信，这样就造成了短信轰炸的毛病。
检测条件：
[*]测试目的具有短信发送的功能。
检测方法：
[*]手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。
[*]通过利用 burp suite 大概别的抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到 10 条以上短信，如果收到大量短信，则说明存在该毛病。
风险品级：
【*中危】：对任意手机号码进行轰炸。
【低危】：仅对当前用户手机号码进行轰炸
修复方案：
[*]合理设置后台短佩服务器的功能，对于同一手机号码，发送次数不超过 3-5次，并且可对发送的时间隔断做限定。
[*]页面前台代码编写时，参加禁止针对同一手机号进行的次数大于 N 次的发送，大概在页面中参加验证码功能，并且做时间隔断发送限定。
2.2、邮件炸弹
毛病形貌：
[*]应用系统未限定邮件的发送次数和频率，造成短时间内大量邮件发送至吸收者邮箱，造成大量垃圾邮件。
检测条件：
[*]测试目的具有邮件发送的功能。
检测方法：
[*]手工找到有关网站注册页面，认证页面，是否具有邮件发送页面，如果有，则进行下一步。
[*]通过利用 burp suite 大概别的抓包截断工具，抓取发送邮件的数据包，并且进行重放攻击，查看邮箱是否在短时间内连续收到 10 条以上邮件，如果收到大量邮件，则说明存在该毛病。
风险品级：
【*中危】：对任意邮箱进行轰炸。
【低危】：仅对当前用户邮箱进行轰炸。
修复方案：
[*]合理设置后台邮件服务器的功能，对于同一邮箱，发送次数不超过 3-5 次，并且可对发送的时间隔断做限定。
[*]页面前台代码编写时，参加禁止针对同一邮箱账号进行的次数大于 N 次的发送，大概在页面中参加验证码功能，并且做时间隔断发送限定。
2.3、短信内容可控
毛病形貌：
[*]应用系统未限定短信的发送内容，造成短信内容客户端可控。
检测条件：
[*]测试目的具有短信内容编辑的功能或短信内容由客户端发出。
检测方法：
[*]在客户端编辑短信内容，看是否过滤特殊字符或内容。
风险品级：
【*高危*】：短信内容可控，可对任意手机号码发送。
【*中危】：短信内容可控，仅对当前用户手机号码发送。
修复方案：
[*]建议在不影响业务的前提下，禁止客户端编辑短信内容。
2.4、邮件内容可控
毛病形貌：
[*]应用系统未限定邮件的发送内容，造成邮件内容客户端可控。
检测条件：
[*]测试目的具有邮件内容编辑的功能或邮件内容由客户端发出。
检测方法：
[*]在客户端编辑邮件内容，看是否过滤特殊字符或内容。
风险品级：
【*高危*】：邮件内容可控，可对任意邮箱发送。
【*中危】：邮件内容可控，仅对当前用户邮箱发送。
修复方案：
[*]建议在不影响业务的前提下，禁止客户端编辑邮件内容。
三、逻辑流程类
3.1、越权
毛病形貌：
[*]越权访问：这类毛病是指应用在检查授权（Authorization）时存在纰漏，使得攻击者在得到低权限用户帐后后，可以利用一些方式绕过权限检查，访问大概操作到本来无权访问的高权限功能。在实际的代码安全审查中，这类毛病往往很难通过工具进行自动化检测，因此在实际应用中危害很大。其与未授权访问有一定差别。
检测条件：
[*]测试目的存在差别级别的权限（角色）
[*]可通过用户名登录网站内进行功能的操作。
[*]测试目的正常运行。
检测方法：
[*]以超管 admin（高权限用户） 身份登录系统
[*]找 到 一 个 只 有 超 管 （ 高 权 限 ） 才 有 的 功 能 的 链 接 ， 好比:“http://localhost/mywebappname/userManage/userList.do” , 表现出所有的 user，并复制此链接。
[*]以普通用户登岸进系统,在所在栏输入: userManage/userList.do，如果可以查看到其所有的 user，则就造成了，普通用户的越权访问。
[*]检测说明：权限管理测试更多的是进行人工分析，自动化工具无法了解页面的具体应用场景以及逻辑判定过程。因此这里的测试需要起首测试职员理解测试业务系统的逻辑处理流程，并在此基础上进行如下测试。这里有几个测试的参考依据：
[*]页面是否进行权限判定；
[*]页面提交的资源标记是否与已登岸的用户身份进行匹配比对；
[*]用户登岸后，服务器端不应再以客户端提交的用户身份信息为依据，而应以会话中保存的已登岸的用户身份信息为准；
[*]必须在服务器端对每个哀求 URL 进行鉴权，而不能仅仅通过客户端的菜单屏蔽大概按钮 Disable 来限定。
风险品级：
【*高危*】：任意程度或垂直越权
修复方案：
[*]对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作，建议在服务端对哀求的数据和当前用户身份做校验检查。
3.2、未授权访问
毛病形貌：
[*]未授权访问毛病:是在攻击者没有获取到登录权限或未授权的情况下，大概不需要输入暗码，即可通过直接输入网站控制台主页面所在，大概不答应查看的链接便可进行访问，同时进行操作。
检测条件：
[*]测试目的具有登录页面，大概具有不答应访问的目次或功能。
[*]不消登录，可通过链接直接访问用户页面功能。
检测方法：
[*]通过对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器进行打开。
[*]也可以通过 web 扫描工具进行扫描，爬虫得到相关所在链接，进行直接访问，如果未进行跳转到登录页面，则可判定为存在未授权访问毛病。
风险品级：
【*高危*】：认证模式可绕过，不登录即可通过 URL 或其他方式访问登岸后页面。
修复方案：
[*]在系统中，参加用户身份认证机制大概 tonken 验证，防止可被直接通过连接就可访问到用户的功能进行操作，简而言之，一定对系统重要功能点增加权限控制，对用户操作进行合法性验证。
3.3、CSRF 毛病
毛病形貌：
[*]跨站哀求伪造攻击：Cross-Site Request Forgery（CSRF），攻击者在用户浏览网页时，利用页面元素（比方 img 的 src），逼迫受害者的浏览器向 Web 应用服务器发送一个改变用户信息的 HTTP 哀求。CSRF 攻击可以从站外和站内发起。从站内发起 CSRF 攻击，需要利用网站本身的业务，好比“自定义头像”功能，恶意用户指定本身的头像 URL 是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息哀求。从站外发送哀求，则需要恶意用户在本身的服务器上，放一个自动提交修改个人信息的 htm 页面，并把页面所在发给受害者用户，受害者用户打开时，会发起一个哀求。威胁形貌：攻击者利用 CSRF 攻击可以或许逼迫用户向服务器发送哀求，导致用户信息被迫修改，甚至可引发蠕虫攻击。如果恶意用户可以或许知道网站管理后台某项功能的 URL，就可以直接攻击管理员，逼迫管理员执行恶意用户定义的操作。
检测条件：
[*]测试目的正常运行。
[*]存在数据提交的所有功能点。
检测方法：
[*]检查网站是否有利用 token 或 referer 参数，若有上述参数，删除参数值查看返回是否有报错。
[*]修改 referer 值，保留原 host 关键词，实验绕过 referer 检测。
[*]伪造 referer。
以下来举例说明其中一种检测以及攻击方案：
1）利用 BurpSuite 对关键操作进行抓包，右键选择“Engagement tools >Generate CSRF PoC”进行 CSRF 攻击脚本的构造。
https://i-blog.csdnimg.cn/direct/02826e483f5b4bfd85b6461f1d8321fa.png
2）天生脚本后选择“Test in browser”进行 CSRF 验证。
https://i-blog.csdnimg.cn/direct/8a8d152cba014e758dbba45c92e614f0.png
风险品级：
【*高危*】：核心系统关键操作（账户操作，审批确认…）。
【*中危】：普通系统关键操作（账户操作，审批确认…）。
修复方案：
[*]通过 referer 判定页面来源进行 CSRF 防护，该方式无法防止站内 CSRF攻击及 referer 字段伪造。
[*]重要功能点利用动态验证码进行 CSRF 防护。
[*]通过 token 方式进行 CSRF 防护。
[*]为每个 session 创建唯一的随机字符串，并在受理哀求时验证。
四、数据验证类
4.1、SQL 注入
毛病形貌：
[*]SQL 注入：就是通过把 SQL 下令插入到 Web 表单提交或输入域名或页面哀求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 下令。具体来说，它是利用现有应用程序，将（恶意）SQL 下令注入到后台数据库引擎执行的能力，它可以通过在 Web 表单中输入（恶意）SQL 语句得到一个存在安全毛病的网站上的数据库，而不是按照设计者意图去执行 SQL 语句。 造成 SQL 注入毛病原因有两个：一个是没有对输入的数据进行过滤（过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。
检测条件：
[*]测试目的具有交互功能模块，涉及到参数查询、提交等。
检测方法：
[*] 通过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 '%'='）。
[*] 绕过验证（常见的为管理登岸）也称万能暗码
[*]用户名输入： ‘ or 1=1 or ‘ 暗码：任意
[*]Admin’ - -（或‘ or 1=1 or ‘ - -）(admin or 1=1 --) (MS SQL)(直接输入用户名，不进行暗码验证)
[*]用户名输入：admin 暗码输入：’ or ‘1’=’1 也可以
[*]用户名输入：admin' or 'a'='a 暗码输入：任意
[*]用户名输入：‘ or 1=1 - -
[*]用户名输入：admin‘ or 1=1 - - 暗码输入：任意
[*]用户名输入：1'or'1'='1'or'1'='1 暗码输入：任意
[*]差别的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 返回错误
[*] 如果应用程序已经过滤了’和+等特殊字符，我们仍然可以在输入时过把字符转换成URL编码（即字符ASCII码的16进制）来绕过检查。
风险品级：
【*高危*】：存在 SQL 注入，无论能否爆出数据。
修复方案：
[*]SQL改用预编译查询语句。
[*]过滤用户输入的参数中的特殊符号，如’”<>~！@#￥%&()_-=+等、过滤常见的sql函数，如select、from、where、substr、ascii、if、case、when等。
[*]Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不答应操作其他数据库。
[*]设置Web应用中用于连接数据库的用户对Web目次不答应有写权限。
4.2、XSS
毛病形貌：
[*]跨站脚本攻击的英文全称是 Cross Site Script，为了和样式表区分，缩写为 XSS。发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击,它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意用户的特殊目的。已知的跨站脚本攻击毛病有三种：1）存储式；2）反射式；3）基于 DOM。
[*]存储型跨站脚本攻击涉及的功能点：用户输入的文本信息保存到数据库中，并可以或许在页面展示的功能点，比方用户留言、发送站内消息、个人信息修改等功能点。
[*]反射型跨站脚本攻击涉及的功能点：URL 参数需要在页面表现的功能点都可能存在反射型跨站脚本攻击，比方站内搜索、查询功能点。
[*]基于 DOM 跨站脚本攻击涉及的功能点：涉及 DOM 对象的页面程序，包罗
（不限这些）：
document.URL
document.URLUnencoded
document.location
document.referrer
window.location
检测条件：
[*]测试目的存在参数输入，大概以 POST 方式提交参数，表现为表单方式，假设为 name=value。
[*]在某种情况下，用户输入被重新表现在网页上，包罗名字、帐号、检索结果等等（说明目的网站服务器并没有对用户提交数据检测）
检测方法：
[*] 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的值，好比：
https://i-blog.csdnimg.cn/direct/1b08df53b2e64953b47818a6597f053a.png
[*] Post 方式跨站脚本：
1） 在POST 表单中逐条输入以下语句，只要其中一条弹出表现 123456 的对话框，就说明存在跨站毛病，记录毛病，停止测试。
2）<script>alert(123456)</script>
3）javascript:alert(123456);
4）如果没有弹出表现 123456 的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件”
5）查 找 网 页 源 文 件 中 是 否 包 含 完 整 的 字 符 串<script>alert(123456)</script>，则不管有没有弹出表现 123456 的告警框，都表明存在跨站脚本毛病。
6）由于有些 HTML 元素（好比或”）会影响脚本的执行，所以不一定可以或许正确弹出 123456 告警框，需要根据返回网页源文件的内容，构造 value的值，好比
https://i-blog.csdnimg.cn/direct/4cdff8c4e31d4407b607d39860396629.png
风险品级：
【*高危*】：应用中存在存储型跨站。
【*中危】：应用中存在反射型跨站。
修复方案：
[*] 验证所有输入数据，有用检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。
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 跳转链接的地方。
检测方法：
[*]起首找到网站相关 url 中存在跳转链接的参数（如登岸页面）。
[*]在检测的同时，可以修改参数中的合法 URL 为非法 URL，然后查看是否能正常跳转大概通过抓包工具获取其 HTTP 响应头中 Host:的值是否包罗了构造的 URL。
[*]如果是 struts2 重定向毛病，则可通过 web 扫描工具扫描发现，大概手工 验 证 ， 直 接 在 URL 后 添 加 ?redirect:+ 指 定 钓 鱼 链 接 ， 例 如 ：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com 进行验证。
风险品级：
【*中危】：URL 跳转参数可控，且未对参数做白名单限定导致任意所在跳转可被利用垂纶。
修复方案：
[*]对传入的 URL 做有用性的认证，保证该 URL 来自于信托域。限定的方式可参考以下两种：
[*]限定 Referer（Referer 是 HTTP header 中的字段，当浏览器向 web 服务器发送哀求时，一样平常会带上 Referer，告诉服务器是从哪个页面链接过来的），通过限定 Referer 保证将要跳转 URL 的有用性，避免攻击者天生本身的恶意跳转链接；
[*]参加有用性验证 Token，保证所有天生的链接都来自于可信域，通过在天生的链接里参加用户不可控的 Token 对天生的链接进行校验。
下一期预告更新：《WEB应用安全测试指南–蓝队安全测试3》重要包罗：组件安全类+Jboss 组件毛病等。
（创作不易，支持打赏，感谢支持）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]