XSS简介

跨站脚本攻击（Cross Site Script）,为了和众所周知的样式表CSS进行区分，它在安全领域简称XSS。xss攻击是由于Web应用程序对用户的输入过滤不足而产生的。攻击者利用网站漏洞把恶意的脚本代码注入到网页之中，当其他用户浏览这些网页时，就会执行其中的恶意代码，对受害用户可能采取 Cookie资料窃取、会话劫持、钓鱼欺骗等各种攻击。在一开始，这种攻击的案例通常是跨域的，所以叫做跨站脚本攻击。但是发展到今天，由于JavaScript的强大功能以及网站前端应用的复杂化，是否跨域已经不再重要，但是由于历史原因，XSS这个名字一直保留下来。
具体攻击方法和防护方案本文后面会有介绍。目前所有知名不知名的网站，凡是我们能看到的，基本都做了xss漏洞防御，下面这个图是我在一个小网站的搜索框输入<script>alert(1)</script> 之后得到的提示信息。
在这里插入图片描述
在CSDN的搜索框随意输入了<script>alert(1)</script> 也没出现问题，然而等我写完这个文章看私信消息的时候不幸的事情发生了，CSDN的搜索记录保留了这段字符串，每次跳转到包含这个搜索框的页面都会弹出这个攻击提示，清空了搜索记录也还这样弹弹出来，心里好怕。
郑重的提示各位，如果想自己测试具体攻击过程，可以搭建一个dvwa靶场或者其他任何正式的允许测试的场景，学习web安全的课程不是要从入门到入狱，非专业同学可以仅了解一下漏洞原理做好日常防范就行了。
在这里插入图片描述

XSS分类介绍

xss根据效果的不同可以分为以下几类：

反射型XSS
反射性XSS只是简单的把用户输入的数据“反射”给浏览器，也就是说，攻击者需要诱导用户点击一个恶意链接，才能攻击成功。反射性XSS也叫做“非持久型XSS”.
存储型XSS
存储型XSS会把用户输入的数据“存储”在服务器端，所以这种攻击也叫做“持久型XSS”。比较常见的一个场景是，黑客写下一篇含有恶意JavaScript代码的博客文章，文章发表后，所有访问该文章的用户都会在他们的浏览器中执行这段恶意代码。
Dom Based XSS
通过修改页面的DOM节点形成的XSS攻击，成为Dom Based XSS，从效果上来说它也是反射型XSS,单独划分出来是因为这种攻击的形成原因比较特别，发现它的安全专家提出了这个概念，由于历史原因这个分类也保留了下来。
举个例子，这里有个简单的html页面：

<div id="divid"></div>
<input type="text" id="text" value="" />
<input type="button" id="s" value="save" onclick="test()"/>

<script>
function test(){
    
    
	var str = document.getElementById("text").value;
	document.getElementById("divid").innerHTML="a href='"+str+"' >testLink</a>";
}
</script>

点击"save"按钮后会在当前页面插入一个超链接，跳转地址为当前用户输入的内容。在这里，通过innerHTML把一段用户输入数据当作HTML写入到页面中，这就造成了Dom Based XSS。
假设构造这样的数据' onclick=alert(1) // 输入后页面代码就变成了：

<a href='' onclick=alert(1) //'>testLink</a>

首先用一个单引号闭合掉href的第一个单引号，然后插入一个onclick事件，最后再注释掉第二个单引号，点击这个新生成的链接，alert脚本将被执行。。。

XSS 的威力和危害

XSS 攻击成功后，攻击者能够对用户当前浏览器的页面植入恶意脚本控制用户的浏览器，这些用以完成具体功能的恶意脚本，被称为XSS Payload. XSS Payload实际上就是Javascript脚本（也可以是Flash等），所以任何JavaScript脚本能实现的功能，XSS Payload都能做到,比如读取浏览器的Cookie对象发起“Cookie劫持”攻击，后端开发应该经常见这样的场景，我们登录系统后通过F12查看当前访问网页的Cookie，然后在POSTMAN或者其他接口测试工具中输入当前的Cookie参数，就可以在不登陆系统的情况下测试系统接口的返回数据，本地测试自己开发的系统肯定没问题，但是如果让攻击者劫持到Cookie信息后果还是很可怕的。
XSS可能造成的危害还包括：

盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
盗窃企业重要的具有商业价值的资料
非法转账
强制发送电子邮件
网站挂马
控制受害者机器向其它网站发起攻击

XSS防御措施

HttpOnly

严格来说，HttpOnly并非是为了对抗XSS-HttpOnly解决的是XSS后的Cookie劫持攻击。前面说了XSS可能会窃取用户的Cookie，然后就直接登录了该用户的账户，但是如果Cookie设置了HttpOnly,则这种攻击会失败，因为JavaScript读取不到Cookie的值。
一个Cokie的使用过程如下：

浏览器向服务器发起请求，这时候没有Cookie.
服务端返回时发送Set-Cookie头，向客户端浏览器写入Cookie.
在该Cookie到期前，浏览器访问该域下的所有页面时都会发送该Cookie.

HttpOnly就是在Set-Cookie时标记的：

Set-Cookie:<name>=<value>
[;<Max-Age>=<age>]
[;expires=<date>]
[;domain=<domain-name>]
[;path=<path-name>]
[;secure]
[;HttpOnly]
// 不同语言在Cookie中添加HttpOnly的写法可能不同

输入检查

常见的web漏洞如XSS/SQL Injection等，都要求攻击者构造一些特殊字符，这些特殊字符可能是正常用户不会用到的，所以在设计网站的时候对用户提交的内容进行严格的过滤非常有必要。
输入检查,在很多时候也被用于格式检查。例如用户在网站注册时填写的用户名，会被要求只能为字母、数字的组合等，电话号码应该是不长于16位的数字。检查校验的逻辑必须放在服务器端的代码中实现，如果只是存在于客户端用js进行输入检查，很容易被攻击者绕过。

输出检查

使用安全的编码函数 在变量输出到HTML页面时，可以使用编码或转义的方式防御XSS攻击，如escapeJavascript()函数
处理富文本 用户提交的富文本呢数据，其语义时完整的HTML代码，在标签的选择、css样式等方面都要特殊处理，一般前端的框架已经集成了公共的处理方法。

小结

XSS漏洞理论上看着好像比较复杂，但却是可以彻底解决的。从风险的角度看，用户之间有互动的页面受攻击的可能性会更大，安全人员需要吮乳理解XSS攻击的原理，根据不同页面的危险高低，在设计方案的时候针对不同场景使用不同的方法。

Web系统常见安全漏洞介绍及解决方案-XSS攻击

漏洞档案