Skip to content

Latest commit

 

History

History
33 lines (17 loc) · 3.53 KB

安全性的探索.md

File metadata and controls

33 lines (17 loc) · 3.53 KB

暂且关注前端。

前几天做的XSS分享,一些旧知识的整理。

XSS分享

XSS简介

XSS全称cross-site script跨站脚本攻击,在现在2021年的时间点,XSS基本已经只能是“本站”脚本攻击了,在浏览器跨域的限制下想要跨站已经非常困难,需要天时地利人和。

所以当前阶段的XSS主要关注脚本攻击,说到脚本攻击,它的成因也就呼之欲出,前端的代码交互基本由JS在页面中存在于script标签。

如果某用户可以将一段自己写的JS代码让目标站点有意无意的发放给其他用户,那就形成了一个XSS攻击。

XSS

上面说到只要执行了JS代码就可以算作一个XSS攻击,如果你愿意,打开控制台写的JS也可以称为XSS,只不过这种XSS只对你自己有效,无法对其他用户生效,而且生效条件比较苛刻,只能物理操控你的电脑实现。

这种一般只会对自己生效的XSS会被归类为反射型XSS,只对自己生效的XSS一般不需要去修复,需要配合其他的漏洞打一套组合拳才会有效,对他人基本不构成威胁。

还有一种存储型的XSS,想象一个输入评论的场景,本应该输入大佬666的句子被替换成了<script>alert('大佬666')</script>,而且前后端在保存以及输出时都对该条输入毫无过滤,

那么最终渲染在浏览器里的话就会插入<script>alert('大佬666')</script>,script标签会被浏览器解析为JS脚本,从而发起一个alert。同时你的这条评论由于被服务器存储,所有用户在刷到你这条评论的时候都会弹出一条alert,这样就影响到了所有的用户。

此时将alert替换成真正有危险的JS语句,例如fetchXMLHttpRequest,这一类可以发起任何形式的请求语句,基于浏览器会自动携带cookies的特性,如果目标站点那个用户已经登录,那么就会顺利的请求成功。当然得益于验证码等等诸多限制条件,构造这样一个请求其实很费精力同时难以完成。在其之后一般会选择通过JS读取cookies然后经cookies发送给自己的网站来收集cookies,让自己登陆之后完成剩余操作,简称盗号。不过现代的话用于用户标识的cookies一般会打上http-only的标记来让JS无法读取,从而无法盗号,或者干脆选用JWT等验证方式(选择一个安全的存放位置)来一下干掉上述两种方案。

那么在现在浏览器的防御下即使得到了一个XSS也几乎无法干坏事,只能捣蛋,跨域的限制让跨站成为历史,但如果你本站内存在漏洞,XSS仍然可以配合这个漏洞来完成攻击,比如有测试用的一键修改密码的API被发现,或者重置密码的地方本身就存在一个密码,从而达成了已登录这个条件然后在修改成想要的密码等等。当然捣蛋肯定也不是希望发生的,发现了XSS还是要制止的。

钓鱼

上面说到XSS的主要攻击手段在于cookies也就是登录和伪造请求,有没有不直接发起请求和偷取登录凭证也可以达成这两种攻击手段呢,答案是有的。

如果你想伪造的站点允许被嵌入,那么可以利用iframe标签来嵌入目标站点,同时将其设置为透明。在之后抛弃传统的JS手段转而写HTML和CSS,引导用户点击或者输入内容,由于透明的作用,用户感知不到你真实的意图,从而达成钓鱼的目的,这种攻击通常被称为CSRF,当然CSRF伪造并非这一种,还有form表单欺骗等等。