web安全常见的8大板块:
XSS跨站脚本攻击
1.绕过XSS-Filter,利用<>标签注入Html/JavaScript代码;
2.利用HTML标签的属性值进行xss攻击。例如:;(当然并不是所有的Web浏览器都支持Javascript伪协议,所以此类XSS攻击具有一定的局限性)
3. 空格、回车和Tab。如果XSS Filter仅仅将敏感的输入字符列入黑名单,比如javascript,用户可以利用空格、回车和Tab键来绕过过滤,例如:;
4. 利用事件来执行跨站脚本。例如:,当src错误的视乎就会执行onerror事件;
5. 利用CSS跨站。例如:Body {backgrund-image: url(“javascript:alert(‘xss’)”)};
6. 扰乱过滤规则。例如:;
7.利用字符编码,透过这种技巧,不仅能让XSS代码绕过服务端的过滤,还能更好地隐藏Shellcode;(JS支持unicode、eacapes、十六进制、十进制等编码形式)
8.拆分跨站法,将xss攻击的代码拆分开来,适用于应用程序没有过滤 XSS关键字符(如<、>)却对输入字符长度有限制的情况下;
9.DOM型的XSS主要是由客户端的脚本通过DOM动态地输出数据到页面上,它不依赖于提交数据到服务器,而是从客户端获得DOM中的数据在本地执行。容易导致DOM型的XSS的输入源包括:Document.URL、Location(.pathname|.href|.search|.hash)、
Document.referrer、Window.name、Document.cookie、localStorage/globalStorage;
如何防御:
原则:不相信客户输入的数据
注意: 攻击代码不一定在中
1、输入过滤
2、HttpOnly Cookie
将重要的cookie标记为http only, 这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段,但是在脚本中却不能访问这个cookie,这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie:
过滤: JavascriptEncode ,CSSEncode ,HTMLEncode ,URLEncode
function HTMLEncode(html)
{
var temp = document.createElement ("div");
(temp.textContent != null) ? (temp.textContent = html) : (temp.innerText = html);
var output = temp.innerHTML;
temp = null;
return output;
}
function HTMLDecode(text)
{
var temp = document.createElement("div");
temp.innerHTML = text;
var output = temp.innerText || temp.textContent;
temp = null;
return output;
}
iframe带来的风险
既不安全也非常耗性能。
容易被其他第三方恶意网站以精确的iframe盗取我们的用户信息。
防御检测:
1.方式一
if (self.frameElement && self.frameElement.tagName == "IFRAME") {
alert('在iframe中');
}
2.方式二
if (window.frames.length != parent.frames.length) {
alert('在iframe中');
}
3.方式三
if (self != top) {
alert('在iframe中');
}
还好在HTML5中,iframe有了一个叫做sandbox的安全属性,通过它可以对iframe的行为进行各种限制,充分实现“最小权限“原则。使用sandbox的最简单的方式就是只在iframe元素中添加上这个关键词就好,就像下面这样:
sandbox还忠实的实现了“Secure By Default”原则,也就是说,如果你只是添加上这个属性而保持属性值为空,那么浏览器将会对iframe实施史上最严厉的调控限制,基本上来讲就是除了允许显示静态资源以外,其他什么都做不了。比如不准提交表单、不准弹窗、不准执行脚本等等,连Origin都会被强制重新分配一个唯一的值,换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求。
另外,sandbox也提供了丰富的配置参数,我们可以进行较为细粒度的控制。一些典型的参数如下:
allow-forms:允许iframe中提交form表单
allow-popups:允许iframe中弹出新的窗口或者标签页(例如,window.open(),showModalDialog(),target=”_blank”等等)
allow-scripts:允许iframe中执行JavaScript
allow-same-origin:允许iframe中的网页开启同源策略
更多详细的资料,可以参考iframe中关于sandbox的介绍。
别被点击劫持了
最常见的是恶意网站使用
防御方法:
1、不允许被iframe嵌套,
if (top.location.hostname !== self.location.hostname) {
alert("您正在访问不安全的页面,即将跳转到安全页面!");
top.location.href = self.location.href;
}
2、使用 HTTP 头防范
通过配置 nginx 发送 X-Frame-Options
响应头,这样浏览器就会阻止嵌入网页的渲染。更详细的可以查阅MDN上关于X-Frame-Options 响应头的内容。
add_header X-Frame-Options SAMEORIGIN;
错误的内容推断
比如在上传文件时在文件数据里面动了手脚,嵌入脚本文件或语句。
防火防盗防猪队友:不安全的第三方依赖包
前面圣诞老人的雪花不陌生吧,嘻嘻嘻~~~
用了HTTPS也可能掉坑里
解决这个安全问题的办法是使用HSTS(HTTP Strict Transport Security),它通过下面这个HTTP Header以及一个预加载的清单,来告知浏览器在和网站进行通信的时候强制性的使用HTTPS,而不是通过明文的HTTP进行通信:
Strict-Transport-Security: max-age=; includeSubDomains; preload
本地存储数据泄露
在前端存储敏感、机密信息始终都是一件危险的事情,推荐的做法是尽可能不在前端存这些数据。
缺失静态资源完整性校验
出于性能考虑,前端应用通常会把一些静态资源存放到CDN(Content Delivery Networks)上面,例如Javascript脚本和Stylesheet文件。这么做可以显著提高前端应用的访问速度,但与此同时却也隐含了一个新的安全风险。
如果攻击者劫持了CDN,或者对CDN中的资源进行了污染,那么我们的前端应用拿到的就是有问题的JS脚本或者Stylesheet文件,使得攻击者可以肆意篡改我们的前端页面,对用户实施攻击。
防御这种攻击的办法是使用浏览器提供的SRI(Subresource Integrity)功能。顾名思义,这里的Subresource指的就是HTML页面中通过浏览器在处理这个script元素的时候,就会检查对应的JS脚本文件的完整性,看其是否和script或link元素中integrity属性指定的SRI值一致,如果不匹配,浏览器则会中止对这个JS脚本的处理。
这个 integrity 属性的值来 指定浏览器提取的资源(文件)的base64编码的加密哈希值。如果资源匹配其中一个哈希值,它将被加载。
的integrity值 至少一个字符串,每个串包括指示特定散列算法(目前允许的前缀的前缀
sha256
,sha384
和sha512
),然后用短划线,并与实际base64编码散列结束。例如:
sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC