XSS攻击通常指的是通过利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript,但实际上也可以包括Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML。攻击成功后,攻击者可能得到包括但不限于更高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容
反射型
攻击者构造带有xss攻击参数URL,恶意URL被服务器处理后返回并在用户的浏览器中执行。通过后端代码接收数据,然后将接收到的数据经处理后会把数据打印在浏览器上,浏览器根据自身的配置会对于接收到的数据进行处理,如果是脚本语言没有加以防护的话就会被浏览器当做脚本进行执行,触发跨站脚本。利用流程就是就是攻击者自己在网站发现有xss注入攻击的时候,攻击者自己构造网址具有xss的URL链接,诱导用户进行访问,从而构成反射性xss
DOM型
攻击者利用网页的 DOM(文档对象模型)结构漏洞,修改了网页的内容,使得恶意代码被执行。DOM型xss其实触发条件和反射型类似,不同的是反射型会将xss脚本通过后端代码进行传值处理,但是DOM型xss的执行均在前端执行
储存型
当攻击者发现有存储型xss漏洞时,攻击者将恶意的跨站注入脚本写入网站的数据库中,当有人再次访问这个网页的时候就会触存储型xss,进而进行xss攻击
原理案例分析
接收数据并进行展示我们可以发现输入1,后在页面进行正常显示
由于页面没有做任何限制,我们可以输入JavaScript语句进行测试
我们将参数改成了我们可以发现,浏览器进行了弹窗
我们可以看到脚本语言在header中,而普通文本在body中,可以看出,浏览器对于我们输入的数据进行了处理
案例分析--反射型xss
我们在一个在线测试的工具网站发现有一个检测我们浏览器信息的功能,我们发现这个功能点没有做过滤,我们可以使用xss跨站语句使其执行跨站脚本,结果如下
查看网页代码发现写入的跨站语句已经被当做脚本代码执行
案例分析--存储型xss
我们来到一个订单系统,我们在填写信息的时候,在具体要求的地方写入了跨站脚本工具语句,提交订单
编写完成后我们提交订单信息
作为一个订单程序cms,后台管理员会去后台查看订单信息,为此我们模拟管理员登录后去查看后台订单信息
发现浏览器产生弹窗
查看网页代码发现写入的跨站语句已经被当做脚本代码执行
证明我们的存储跨站脚本执行成功
BEEF xss平台的使用
存储型xss的利用,往往是盗用对方用户的cookie等敏感信息
我们借助beef平台进行实现
在实战中为了发挥其时实质价值,我们需要将其部署到公网IP上,这里做实验,直接使用kali中自带的beef
beeef的启动
我们登陆后进入其后台页面
我们在订单地址中写入
其实就是beef自带的一个xss攻击上线地址然后写入订单中
当管理员访问后台订单查询的时候就会触发上线
就会获取到浏览器的相关信息如:cookie 浏览器版本等等
当然如果将这个语句方放到正常的网页中,如果用户进行访问,也会被上线监测
案例分析--DOM型xss
DOM型xss最大的特点就是网站的语法是前端脚本语言写成我们可以通过查看源代码去查看其源码信息
案例分析
DOM XSS
我们将其代码闭合后可以进行跨站代码的写入,并触发跨站代码
查看源码
发现写入语句已经被当成了JavaScript标本进行解析执行
案例分析
用empireCMS访问/e/ViewImg/index.html?url=javascript:alert(1)地址就会触发JavaScript代码
源码分析
根据源码的写法我们可以将url使用JavaScript的语法传入xss的跨站语句
XSS代码执行成功
输入验证和过滤:对用户的输入进行严格的验证和过滤,以防止恶意代码的注入。可以采用基于黑名单的过滤或基于白名单的过滤方式,后者通常具有更好的防御效果。
输出编码:在将用户的输入呈现到网页时,使用合适的输出编码方式,以防止恶意代码的执行。
设置HTTPOnly标志:在cookie中加入httponly属性可以在一定程度上保护用户的cookie,减少出现XSS时损失。
避免直接使用用户输入作为URL参数:避免将用户输入直接用作URL参数,可以防止反射型XSS攻击。
如有错误,请及时指出,感谢