浏览器的同源策略限制了一些跨域行为, 但仍有些特例 (img,iframe,script 标签) 不受跨域限制, 这就给 XSS 攻击创造了机会(这完全不是同源策略的锅, 一定是程序员的锅).
在讲下面的内容前, 还是要提一下 Cookie,Cookie 是用来辨别用户身份的重要依据. 来做个形象的比喻, 有一天, 小 A 去了一家新开的理发店, 店里的托尼老师不认识小 A, 于是小 A 就办了一张 VIP 卡, 当小 A 第二次去这家理发店的时候, 店里的托尼老师刷了下小 A 的卡, 想起来了你是小 A 啊, 今天搞什么样的造型啊~ Cookie 就是那张 VIP 卡, 用于辨别用户身份.
Cookie 包含以下几个属性
采用 Name = Value 的键值对形式存储数据, Name 是唯一的
Domain: 域名, 限制哪些域名下可以使用(该 VIP 卡仅限本店使用)
Path: 路径, 只有这个路径前缀的才可用(该 VIP 卡仅限烫头)
Expires: 过期时间(该 VIP 卡有效期一年)
HTTP(HTTPOnly): 只有浏览器请求时, 才会在请求头中带着, JavaScript 无法读写
Secure: 非 HTTPS 请求时不带
SameSite: 用于定义 cookie 如何跨域发送
Cookie 就先简单说到这里, 回到 XSS 攻击, 后续讲到的 XSS 和 CSRF 攻击都会围绕着怎么获取 Cookie 来举例.
XSS(Cross-site-Script 跨站脚本攻击), 通常是带有页面可解析内容的数据未经处理直接插入到页面上解析造成的. XSS 根据攻击脚本的引入位置来区分为存储型 XSS, 反射型 XSS 以及 MXSS(也叫 DOM XSS)三种.
根据上面的描述来举个例子:
假设有一个论坛存在 XSS 漏洞, 用户小 A 在该论坛的一篇帖子中留言到
当小 A 写的留言被该论坛保存下来之后, 如果有其他的用户看到了这条评论(相当于打开了这个页面, 执行了 hark.JS,hark.JS 里面内容大致是获取 Cookie, 发送请求), 那么这些用户的 Cookie 都会发送到小 A 事先写好的信息收集网站中进行保存, 然后小 A 就可以用这些 Cookie 进行登录啦.
上述这种 XSS 攻击属于存储型, 提交的代码会被存储在服务器端, 下次请求目标网站时不用再提交 XSS 代码. 所以这种类型的主要原因是前端提交的数据未经处理直接存储到数据库, 然后从数据库中读取出来后直接插入到页面中导致的.
继续讲故事:
假设有一个网站 lalala 存在 XSS 漏洞, 网址是 http://www.lalala.com. 然后有一天小 A 在邮件里发现一封邮件, 内容是一张你懂得图片然后配下面的标签.
小 A 好奇啊, 然后就点了进去, 如果在此之前小 A 登录过 lalala 网站, 那么他的 Cookie 就被盗走了.
这种 XSS 攻击属于反射型, 发出请求时, XSS 代码出现在 URL 中, 作为输入提交到服务器, 服务器解析后响应, XSS 代码随着响应内容一起传回给浏览器, 最后浏览器解析执行 XSS 代码. 这个过程像一次反射, 故叫做反射型 XSS.
MXSS 则是在渲染 DOM 属性时将攻击脚本插入 DOM 属性中被解析而导致的.
至此, 三种类型的 XSS 攻击都描述完了, 你看确实都是程序员的锅吧.
服务端可以做以下动作:
1, 刚刚上面讲到 Cookie 中有个属性时 HTTP, 设置为 True, 不允许 JavaScript 读取 cookies, 但该属性只适配部分浏览器. 对于 HTTPS 可以设置 Secure
2, 处理富文本框输入内容, 进行 XSS 过滤, 过滤类似 script,iframe,form 等标签以及转义存储
客户端可以做以下动作:
1, 输入检查, 和服务端一样都要做.
2, 输出检查, 编码转义, 如果使用 jQuery, 就是那些 append,html,before,after 等, 插入 DOM 的方法需要注意. 现今大部分的 MV * 框架在模板 (view 层) 会自动处理 XSS 问题.
XSS 攻击的危害是很大的, 像上面的例子注入 script 可以执行任何的 JS 代码(意味着可以获取 cookie 等信息了), 注入 style 可以把页面全部弄崩. 尤其是具有评论功能的网站需要注意防范此类攻击, 不要相信客户端发送过来的任何数据! 还有就是不要乱点开奇奇怪怪的链接啦~
来源: https://www.cnblogs.com/anyhoo/p/10443517.html