重点掌握: XSS理解与防御,CSRF理解与防御,中间人攻击理解与防御
# XSS
Cross-Site Scripting(跨站脚本攻击)简称 XSS,是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本,使之在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息如 Cookie、SessionID 等,进而危害数据安全。
本质:恶意代码未经过滤,与网站正常的代码混在一起;浏览器无法分辨哪些脚本是可信的,导致恶意脚本被执行。
# XSS漏洞来源
- 来自用户的 UGC(User Generated Content) 用户原创内容
- 来自第三方的链接
- 来自URL
- 参数 POST
- 参数 Referer (可能来自不可信的来源)
- Cookie (可能来自其他子域注入)
# XSS具体形式
在 HTML 中内嵌的文本中,恶意内容以 script 标签形成注入。
在内联的 JavaScript 中,拼接的数据突破了原本的限制(字符串,变量,方法名等)。
在标签属性中,恶意内容包含引号,从而突破属性值的限制,注入其他属性或者标签。
在标签的 href、src 等属性中,包含
javascript:
等可执行代码。在 onload、onerror、onclick 等事件中,注入不受控制代码。
在 style 属性和标签中,包含类似
background-image:url("javascript:...");
的代码(新版本浏览器已经可以防范)。在 style 属性和标签中,包含类似
expression(...)
的 CSS 表达式代码(新版本浏览器已经可以防范)。
# XSS的危害
- 盗取用户资料,比如:登录帐号、网银帐号等
- 利用用户身份,读取、篡改、添加、删除数据等
- 盗窃重要的具有商业价值的资料
- 非法转账
- 强制发送电子邮件
- 网站挂马
- 控制受害者机器向其它网站发起攻击
# XSS分类
根据攻击的来源,XSS 攻击可分为存储型、反射型和 DOM 型三种
类型/区别点 | 存储区* | 插入点* |
---|---|---|
存储型 XSS | 后端数据库 | HTML |
反射型 XSS | URL | HTML |
DOM 型 XSS | 后端数据库/前端存储/URL | 前端 JavaScript |
- 存储区:恶意代码存放的位置
- 插入点:由谁取得恶意代码,并插入到网页上。
# 存储型 XSS
攻击步骤:
- 攻击者将恶意代码提交到目标网站的数据库中。
- 用户打开目标网站时,网站服务端将恶意代码从数据库取出,拼接在 HTML 中返回给浏览器。
- 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。
攻击场景:
- 论坛发帖
- 商品评论
- 用户私信
- 涉及用户保存数据相关的网站功能
# 反射型 XSS
攻击步骤:
- 攻击者构造出特殊的 URL,其中包含恶意代码。
- 用户打开带有恶意代码的 URL 时,网站服务端将恶意代码从 URL 中取出,拼接在 HTML 中返回给浏览器。
- 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。
攻击场景:
- 网站搜索
- 跳转
- 通过URL传递参数并诱导点击的功能
- 通过构造表单发出POST请求并诱导点击的功能(少见)
# DOM型 XSS
攻击步骤:
- 攻击者构造出特殊的 URL,其中包含恶意代码。
- 用户打开带有恶意代码的 URL。
- 用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行。
- 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。
攻击场景:
- 论坛发帖
- 商品评论
- 用户私信
- 涉及用户保存数据等网站功能
DOM 型 XSS 跟前两种 XSS 的区别:
DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞
# 预防
XSS攻击要素:
- 攻击者提交恶意代码
- 浏览器执行恶意代码
# 输入过滤
通过前端进行输入过滤,把结果提交给后端。在某些情况下解决特定的 XSS 问题,但会引入很大的不确定性和乱码问题。
存在问题:
- 转义后的字符,不能直接用于 Vue 等模板的展示,也不能直接用于内容长度计算。不能用于标题、alert 等
- 用户的输入内容可能同时提供给前端和客户端,而一旦经过了 escapeHTML(),客户端显示的内容就变成了乱码
使用场景:
- 数字、URL、电话号码、邮件地址等内容
- 有明确的输入类型限制
# 纯前端渲染
前端渲染真正意义上的实现了前后端分离,前端只专注于UI的开发,后端只专注于逻辑的开发,前后端交互只通过约定好的API来交互,后端提供json数据,前端循环json生成DOM插入到页面中去。
后端渲染:后端返回给浏览器的是经过服务器计算之后的呈现给用户的最终的HTML字符串,在这种情况下,浏览器只进行了HTML的解析。
前端渲染更快,网络传输数据量小,不占用服务端运算资源,可维护性跟高。
渲染过程:
- 浏览器先加载一个静态 HTML,此 HTML 中不包含任何跟业务相关的数据。
- 然后浏览器执行 HTML 中的 JavaScript。
- JavaScript 通过 Ajax 加载业务数据,调用 DOM API 更新到页面上。
缺点:
- SEO友好度差
后端渲染html 叫吐或者喷,爬虫可以看到完整的呈现源码 前端模板渲染html叫填,爬虫看不到完整的呈现源码
首屏性能差:DOM直接读写速度慢,还涉及回流重绘,虽然目前Vue和React等框架在数据变更后,他会帮你diff,没有改变可以复用的部分是不会重新渲染一遍的,但性能要求高的页面需要在首屏优化下功夫.
同构开发框架例如Next.js
- 巧妙地用标准化的解决了请求的问题。同构和页面开发类似,异步是个大难题,异步中难点又在接口请求。Next.js 给组件新增了 getInitialProps 方法来专门处理初始化请求,再也不用手动往页面上塞 DATA 和调用 ReactDOMServer.renderToString
- 使用 styled-jsx 解决了 css-in-js 的问题。这种方案虽然不像 styled-component 那样强大,但足够简单,可以说是最小的成本解决了问题
- Fast by default。页面默认拆分文件方式打包,支持Prefetch页面预加载
# 转义HTML
转义HTML主要是针对& < > " ' /这些字符。不同的上下文,如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等,所需要的转义规则不一致。 业务 RD 需要选取合适的转义库,并针对不同的上下文调用不同的转义规则。
利用模板引擎进行转义,后端处理为佳。
适用场景:
- HTML表情文字内容
- HTML属性值
不适用场景:
- css内联样式
- 内联js
- 内联json
- 跳转链接
# 代码规范化(针对DOM型XSS)
预防 DOM 型 XSS 攻击,主要是前端 JavaScript 代码本身不够严谨,把不可信的数据当作代码执行,结合前端渲染防范XSS攻击时需要注意以下几个方面。
不使用
v-html/dangerouslySetInnerHTML
功能在前端 render 阶段避免
innerHTML
、outerHTML
避免内联事件
如
location
、onclick
、onerror
、onload
、onmouseover
等,<a>
标签的 href 属性,JavaScript 的eval()
、setTimeout()
、setInterval()
等,都能把字符串作为代码运行, 尽量不要使用onLoad="onload('')"、onClick="go('')"
这种拼接内联事件的写法。如果不可信的数据拼接到字符串中传递给这些 API,很容易产生安全隐患,请务必避免 在 JavaScript 中通过 .addEventlistener() 事件绑定会更安全.验证码
防止脚本冒充用户提交危险操作
HTTP-only Cookie
禁止 JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注入后也无法窃取此 Cookie。
增加攻击难度
通过 CSP、输入长度配置、接口安全措施等方法,增加攻击的难度,降低攻击的后果
避免拼接 HTML
前端采用拼接 HTML 的方法比较危险,如果框架允许,使用
createElement
、setAttribute
之类的方法实现。或者采用比较成熟的渲染框架,如 Vue/React 等。最后希望我们时刻保持警惕:在插入位置为 DOM 属性、链接等位置时,要打起精神,严加防范。
# Content-Security-Policy
内容安全策略(CSP)本质上就是建立白名单,开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则,如何拦截是由浏览器自己实现的。我们可以通过这种方式来尽量减少 XSS 攻击.通常可以通过两种方式来开启 CSP。
设置 HTTP Header 中的 Content-Security-Policy:
- 只允许加载本站资源:
Content-Security-Policy: default-src 'self'
- 只允许加载 HTTPS 协议图片
Content-Security-Policy: /img-src https://*
- 允许加载任何来源框架
Content-Security-Policy: child-src 'none'
- 只允许加载本站资源:
设置 meta 标签的方式
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://www.baidu.com">
- default-src:不限制类型
- script-src: 外部脚本
- style-src:script-src 版的样式表
- /img-src: 用于定义可从中加载图像的来源。
- font-src: 用于指定可提供网页字体的来源
- media-src: 用于限制允许传输视频和音频的来源。
- object-src: 可对 Flash 和其他插件进行控制。
- plugin-types: 用于限制页面可以调用的插件种类。
- child-src: 用于列出适用于工作线程和嵌入的帧内容的网址(框架)
作用:
- 禁止加载外域代码,防止复杂的攻击逻辑。
- 禁止外域提交,网站被攻击后,用户的数据不会泄露到外域。
- 禁止内联脚本执行(规则较严格,目前发现 GitHub 使用)。
- 禁止未授权的脚本执行(新特性,Google Map 移动版在使用)。
- 合理使用上报可以及时发现 XSS,利于尽快修复问题。
# CSRF
CSRF(Cross-site request forgery)跨站请求伪造:攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的。
本质:攻击者盗用了你的身份,以你的名义发送恶意请求。
# 特点
CSRF通常是跨域的,因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能,比如可以发图和链接的论坛和评论区,攻击可以直接在本域下进行,而且这种攻击更加危险。
攻击一般发起在第三方网站,而不是被攻击的网站。被攻击的网站无法防止攻击发生。
攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;而不是直接窃取数据。
整个过程攻击者并不能获取到受害者的登录凭证,仅仅是“冒用”。
跨站请求可以用各种方式:图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中,难以进行追踪。
# 过程
用户打开浏览器,访问受信任银行网站,输入用户名和密码请求登录网站。
在用户信息通过验证后,银行网站产生Cookie信息并返回给浏览器,此时用户登录网站成功,可以正常发送请求到网站。
用户未退出银行网站之前,在同一浏览器中,打开一个TAB页访问其他网站B 。
这时候网站B 已被黑客注入诱导信息,加入是一张图片,图片地址指向 src=”http://bank.example/withdraw?account=bob&amount=1000000&for=黑客 点击之后转账给黑客这个账户
浏览器在接收到这些攻击性代码请求后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,根据用户的Cookie信息以C的权限处理该请求,导致来自黑客请求恶意代码被执行。
# 攻击类型
# 请求类型区分
GET类型的CSRF
该类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF最常见,危害最大,但也简单,这种类型又可以分为手动型和自动型。
- 手动型就是需要我们自己去点击才会发生攻击,比如各种URL链接,各种a标签包裹的DOM元素。
- 自动型的是不需要我们点击,只要当我们访问具有某些标签的网站的时候就会自动发生攻击
</img src=http://xx.com/index.html?xx=11 />
因为这些标签需要访问指定的URL才能发挥作用,所以会发送http请求,又因为这些标签是网页加载的时候就会自动发送http请求,所以当网页加载的时候CSRF就会自动发生。
要实现这种CSRF就必须实现跨域访问,比如利用上面这两个可以发送跨域请求的标签,AJAX是不能实现这种CSRF的,因为AJAX有同源策略,当使用AJAX的时候,接受数据的URL地址的域名、端口、协议、必须和当前地址的域名、端口、协议都一致才能成功发送数据,不然数据是发送不成功的。
POST类型的CSRF
post请求和get请求是不同的,post请求是要把参数放在http的请求body里发送给服务器,所以post类型的CSRF需要用post的方式发送请求。我们常用的post请求方式一般就两个,AJAX和表单,AJAX是有同源策略的,所以不能用AJAX的方式发送post请求,所以就剩下表单的方式了,没错,表单是支持跨域发送请求的。通常的方法就是创建一个自动提交的表单。
<form action="http://xxx.com/xxx.php" method="post" id="form">
<input type="text" name="name" value="qietuniu" />
<input type="text" name="pwd" value="1000" />
</form>
<script> document.getElementById("form").submit()</script>
2
3
4
5
6
GET接口太容易被拿来做CSRF攻击,只要构造一个/img标签,而/img标签又是不能过滤的数据。接口最好限制为POST使用,GET则无效,降低攻击风险。当然POST攻击者只要构造一个form就可以,但需要在第三方页面做,这样就增加暴露的可能性。
# 攻击类型区分
CSRF可分为:
- HTML CSRF攻击
- JSON 劫持
- FLash CSRF攻击
<link href="">
</img src="">
</img lowsrc="">
</img dynsrc="">
<meta http-equiv="refresh" content="0,url=">
<iframe src="">
<frame src="" />>
<script src="">
<bgsound src="">
<a href="">
// css
@import ""
background:url("")
2
3
4
5
6
7
8
9
10
11
12
13
14
# 预防
# 同源检测
Origin和Referer验证,在 HTTP 头中有一个字段叫 Referer,它记录了该 HTTP 请求的来源地址,服务器会验证客户端的请求来源,如果本网站请求的则响应,否则不响应。
缺点:
- 对于某些浏览器,比如 IE6 或 FF2,目前已经有一些方法可以篡改 Referer 值
- 用户自己可以设置浏览器使其在发送请求时不再提供 Referer
# token验证
Token是一个比较有效的CSRF防护方法,只要页面没有XSS漏洞泄露Token,那么接口的CSRF攻击就无法成功。 注意Token的保密性和随机性。
步骤:
- 用户访问某个表单页面。
- 服务端生成一个Token,放在用户的Session中,或者浏览器的Cookie中。
- 在页面表单附带上Token参数。
- 用户提交请求后, 服务端验证表单中的Token是否与用户Session(或Cookies)中的Token一致,一致为合法请求,不是则非法请求。
# 在 HTTP 头中自定义属性并验证
这种方法也是使用 token 并进行验证,和上一种方法不同的是,这里并不是把 token 以参数的形式置于 HTTP 请求之中,而是把它放到 HTTP 头中自定义的属性里。
通过 XMLHttpRequest 这个类,可一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性,并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便,同时,通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏,也不用担心 token 会透过 Referer 泄露到其他网站中去。
缺点:
- XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新,并非所有的请求都适合用这个类来发起
- 通过该类请求得到的页面不能被浏览器所记录下,从而进行前进,后退,刷新,收藏等操作,给用户带来不便
# 双重Cookie验证
利用CSRF攻击不能获取到用户Cookie的特点,我们可以要求Ajax和表单请求携带一个Cookie中的值。
过程:
- 在用户访问网站页面时,向请求域名注入一个Cookie,内容为随机字符串(例如“
csrfcookie=v8g9e4ksfhw“
)。 - 在前端向后端发起请求时,取出Cookie,并添加到URL的参数中(接上例“
POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw“
)。 - 后端接口验证Cookie中的字段与URL参数中的字段是否一致,不一致则拒绝。
优点:
- 无需使用Session,适用面更广,易于实施。
- Token储存于客户端中,不会给服务器带来压力。
- 相对于Token,实施成本更低,可以在前后端统一拦截校验,而不需要一个个接口和页面添加。
缺点:
- Cookie中增加了额外的字段。
- 如果有其他漏洞(例如XSS),攻击者可以注入Cookie,那么该防御方式失效。
- 难以做到子域名的隔离。
- 为了确保Cookie传输安全,采用这种防御方式的最好确保用整站HTTPS的方式,如果还没切HTTPS的使用这种方式也会有风险。
# Samesite Cookie
strict: 严格模式,表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie,绝无例外。
lax: 宽松模式,比 Strict 放宽了点限制:假如这个请求是这种请求(改变了当前页面或者打开了新页面)且同时是个GET请求,则这个Cookie可以作为第三方Cookie。
缺点: 新版Chrome和Firefox支持以外,Safari以及iOS Safari都还不支持。
# 服务端进行CSRF防御
在客户端页面增加伪随机数
方法: Cookie Hashing(所有表单都包含同一个伪随机值):表单里增加Hash值,以认证这确实是用户发送的请求,然后在服务器端进行Hash值验证。
# 验证码
每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,注意随机性
# 防止网站被利用
严格管理所有的上传接口,防止任何预期之外的上传内容(例如HTML)
添加Header “
X-Content-Type-Options: nosniff“
防止黑客上传HTML内容的资源(例如图片)被解析为网页。对于用户上传的图片,进行转存或者校验。不要直接使用用户填写的图片链接。
当前用户打开其他用户填写的链接时,需告知风险(这也是很多论坛不允许直接在内容中发布外域链接的原因之一,不仅仅是为了用户留存,也有安全考虑)。
# 中间人攻击
中间人攻击是指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制。
简单来说,攻击者在请求和响应传输途中,拦截并篡改内容。对于 HTTP 来说,由于设计的简单,不需要太多步骤就可以进行监听和修改报文;在这里主要是针对 HTTPS,HTTPS 使用了 SSL 加密协议,是一种非常安全的机制,目前并没有方法直接对这个协议进行攻击,一般都是在建立 SSL 连接时,利用中间人获取到 CA证书、非对称加密的公钥、对称加密的密钥;有了这些条件,就可以对请求和响应进行拦截和篡改。
# 攻击方式
# DNS欺骗
攻击者往往可以通过入侵DNS服务器,或是篡改用户本地hosts文件,从而截获到用户发出的请求。
截获请求以后,根据不同目的,攻击者既可以让用户“误入歧途”,引导用户访问一个假网站,也可以把用户请求依旧转发给目标服务器,仅仅实现监听的目的。
扩展:DNS的递归查询、root DNS、A记录解析、CName解析等概念
# APR欺骗
如果说DNS欺骗是在广域网中的拦截用户请求,那么APR欺骗就是在局域网中的拦截用户请求。ARP(Address Resolution Protocol)地址解析协议,是一种将IP地址转化成物理地址的协议。
过程:
- 在局域网中,主机A想要跟主机B(假设IP是123)通信,不仅需要知道对方的IP,也要需要知道对方的MAC地址。如果主机A的本地ARP缓存表没有主机B的地址缓存,主机A就会在向局域网内的所有主机发起广播,请求IP为123的主机。
- 主机B收到广播,检查自己的IP地址与主机A请求中的IP地址一致,就会把自己的MAC地址返回给主机A。主机A接收到反馈以后,会把主机B的MAC地址存入本地ARP缓存表,以便下次直接使用。
- 攻击者利用了APR协议的漏洞,通过局域网内部的一台主机(IP并不是123),冒充主机B,向主机A发送自己的MAC地址。主机A接到消息以后,无法识别消息是真的来自主机B,还是来自一个冒名顶替者,只能照样把接受到的新MAC地址存入ARP缓存表,取代原先的记录。
- 下一次,当主机A想要向主机B发送请求的时候,会先查询自己的ARP缓存表,查出主机B的MAC地址是def(本来应该是abc),结果把请求发给了主机D。从而让攻击者拦截到了请求信息。
# 代理服务器
代理服务器,就是用户主机在访问网站时所使用的各种代理,比如wifi,比如VPN,比如翻墙工具。这些代理未必都是可靠的,有些可能会遭到黑客攻击,有些可能自身就有问题。当用户通过这些代理发送请求的时候,请求信息自然而然就会被劫持。
# 预防
- 确保在URL前你所访问的网站有HTTPS
HTTPS协议在HTTP协议的基础上增加了SSL层,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密。这样一来,即使攻击者截获了用户发出的请求信息,也无法解密信息,更无法篡改信息。
- 点击电子邮件前,检查电子邮件的发件人
- 如果你是一个网站管理员,你应当执行HSTS协议
- 不要在公共Wi-Fi网络上购买或发送敏感数据
- 确保你的网站没有任何混合内容
- 如果你的网站使用了SSL,确保你禁用了不安全的SSL/TLS协议。你应当只启用了TLS 1.1和TLS 1.2
- 不要点击恶意链接或电子邮件
- 不要下载盗版内容
- 使用防火墙和杀毒软件
将安全工具正确地安装在系统上,在局域网内,发起ARP欺骗的主机往往是中了病毒的机器,从而被黑客控制,因此需要定期查杀病毒。而防火墙可以有效地阻挡疑似APR欺骗的消息。
- 使用DNSSEC机制
Domain Name System Security Extensions (DNSSEC)DNS安全扩展,是一系列DNS安全认证的机制,可以验证用户访问的站点地址是否有效,解决DNS欺骗的问题。
# 数字证书
数字证书是一个经证书授权中心CA数字签名的包含公开秘钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。数字证书还有一个重要的特征就是只在特定的时间段内有效。
证书至少需要包括如下内容:
- 颁证机构
- 证书持有者的名字
- 证书持有者的公钥
- 证书有效期
- 证书颁发机构的签名
# 分类
数字证书在广义上可分为:个人数字证书 、单位数字证书、单位员工数字证书、服务器证书、VPN证书、WAP证书、代码签名证书和表单签名证书。
服务器证书(SSL证书)
服务器证书被安装于服务器设备上,用来证明服务器的身份和进行通信加密。服务器证书可以用来防止欺诈钓鱼网站。
在服务器上安装服务器证书后,客户端浏览器可以与服务器证书建立SSL连接,在SSL连接上传输的任何数据都会被加密。同时,浏览器会自动验证服务器证书是否有效,验证所访问的站点是否是假冒站点,服务器证书保护的站点多被用来进行密码登录、订单处理、网上交易等。全球知名的服务器证书品牌有GlobalSign,Verisign,Thawte,Geotrust等。
SSL证书主要用于服务器(应用)的数据传输链路加密和身份认证,绑定网站域名,不同的产品对于不同价值的数据和要求不同的身份认证。
SSL证书还有企业型SSL证书(OVSSL) 及域名型证书(DVSSL)。
查看 : 浏览器工具->Internet选项->内容->证书
电子邮件证书
电子邮件证书可以用来证明电子邮件发件人的真实性。它并不证明数字证书上面CN一项所标识的证书所有者姓名的真实性,它只证明邮件地址的真实性。 收到具有有效电子签名的电子邮件,我们除了能相信邮件确实由指定邮箱发出外,还可以确信该邮件从被发出后没有被篡改过。
另外,使用接收的邮件证书,我们还可以向接收方发送加密邮件。该加密邮件可以在非安全网络传输,只有接收方的持有者才可能打开该邮件。
个人证书
客户端证书主要被用来进行身份验证和电子签名。
安全的客户端证书被存储于专用的 usbkey 中。存储于key中的证书不能被导出或复制,且key使用时需要输入key的保护密码。使用该证书需要物理上获得其存储介质usbkey,且需要知道key的保护密码,这也被称为双因子认证。这种认证手段是目前在internet最安全的身份认证手段之一。key的种类有多种,指纹识别、第三键确认,语音报读,以及带显示屏的专用usbkey和普通usbkey等。
# 作用
以数字证书为核心的加密技术(加密传输、数字签名、数字信封等安全技术)可以对网络上传输的信息进行加密和解密、数字签名和签名验证,确保网上传递信息的机密性、完整性及交易的不可抵赖性。
使用了数字证书,即使您发送的信息在网上被他人截获,甚至您丢失了个人的账户、密码等信息,仍可以保证您的账户、资金安全。
# 数字证书颁发过程
- 用户首先产生自己的秘钥对,并将公共密钥及部分个人身份信息传送给认证中心CA。
- 认证中心在核实身份后,将执行一些必要的步骤,以确信请求确实由用户发送而来。
- 认证中心将发给用户一个数字证书,该证书内包含用户的个人信息和他的公钥信息,同时还附有认证中心的签名信息。
用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布。数字证书各不相同,每种证书可提供不同级别的可信度。可以从证书发行机构获得您自己的数字证书。
# 原理(如何保证安全性的)
数字证书采用公钥体制,即利用一对互相匹配的秘钥进行加密、解密。每个用户自己设定一把特定的仅为本人所知的私有密钥(私钥),用它进行解密和签名;同时设定一把公共密钥(公钥)并由本人公开,为一组用户所共享,用于加密和验证签名。
当发送一份保密文件时,发送方使用接收方的公钥对数据加密,而接收方则使用自己的私钥解密,这样信息就可以安全无误地到达目的地了。通过数字的手段保证加密过程是一个不可逆过程,即只有用私有密钥才能解密。在公开密钥密码体制中,常用的一种是RSA体制。
数字证书里存有很多数字和英文,当使用数字证书进行身份认证时,它将随机生成128位的身份码,每份数字证书都能生成相应但都不可能相同的身份码,从而保证数据传输的保密性,即相当于生成一个复杂的密码。
# 点击劫持
点击劫持(Clickjacking)也称为UI-覆盖攻击,攻击者在页面上覆盖一层透明的 iframe ,然后诱使用户在该网页上进行操作,引导至恶意页面。
# 过程
- 黑客创建一个网页利用iframe包含目标网站:
- 隐藏目标网站,使用户无法察觉到目标网站存在;
- 构造网页,诱骗用户点击特定按钮 (图1中的PLAY!按钮);
- 用户在不知情的情况下点击按钮,触发执行恶意网页的命令。
# 结合 CSRF 漏洞
通过点击劫持来破解CSRF的token识别方法:
将载入目标网页 iframe 中 token 自动添加到 src 属性后面。使用HTTP “GET”方法的表单会自动完成上述步骤,实现攻击WEB应用程序。
Twitter 蠕虫攻击就是利用点击劫持漏洞来实现CSRF攻击。
# 结合 XSS 漏洞
反射型XSS难于利用,通过点击劫持,将反射性转换为存储型XSS,只要用户点击触发此漏洞,就可以在用户浏览器上执行任意的JavaScript 代码,因此具有极大的危害性。
# 涉及技术
# 目标网页隐藏技术
目标网页隐藏技术原理是攻击者在恶意网站上通过 iframe 载入目标网页,然并隐藏目标网页,欺骗用户点击隐藏的恶意链接。目前主要的网页隐藏技术有两种:
CSS隐藏技术
CSS 隐藏技术的原理是利用 CSS 技术控制网页内容显示的效果。其中opacity参数表示元素的透明度,取值范围为0~1,默认值为1表示不透明, 取值为0时元素在网页中完全透明显示。当设置目标 iframe 的opacity 属性小于或等于0.1,用户就无法看到含恶意代码的目标网页。
双iframe隐藏技术。
双iframe隐藏技术使用内联框架和外联框架。内联框架的主要功能是载入目标网页,并将目标网页定位到特定按钮或者链接。外联框架的主要功能是筛选,只显示内联框架中特定的按钮。
# 点击操作劫持
在成功隐藏目标网页后,攻击者下一个目标是欺骗用户点击特定的按钮,最简单实用的方法是使用社会工程学。例如,将攻击按钮外观设计成类似QQ消息的提示按钮,诱使用户点击从而触发攻击行为。
另外一种思路是使用脚本代码以及其他技术增加用户点击特定按钮的概率。主要方法如:
- JavaScript实现鼠标跟随技术
- 按键劫持 (Stroke jacking) 技术等。
# 拖拽(Drag and Drop)技术
主流的浏览器都有drag-and-drop API 接口,供网站开发人员创建交互式网页。但是,这些 API 接口在设计时没有考虑很多的安全性问题,导致通过拖拽就可以实现跨域操作。利用拖拽技术,攻击者可以突破很多已有的安全防御措施,
利用拖拽技术,攻击者可以轻易将文本注入到目标网页。在实际实施过程中,攻击者欺骗用户选择输入框的内容,完成拖拽操作。另外一种方式是,通过浏览器的 API 接口将 iframe 中的内容拖拽到目标网页的 text area 中,攻击者就可以获得用户网页中存在的敏感信息。
# 点击劫持防御
# 服务器端防御
服务器端防御点击劫持漏洞的思想是结合浏览器的安全机制进行防御,主要的防御方法介绍如下:
X-FRAME-OPTIONS 机制
在微软发布新一代的浏览器Internet Explorer 8.0中首次提出全新的安全机制:X-FRAME-OPTIONS。该机制有两个选项:
- DENY:DENY表示任何网页都不能使用 iframe 载入该网页
- SAMEORIGIN:SAMEORIGIN表示符合同源策略的网页可以使用 iframe载入该网页。 如果浏览器使用了这个安全机制,在网站发现可疑行为时,会提示用户正在浏览 网页存在安全隐患,并建议用户在新窗口中打开。这样攻击者就无法通过 iframe 隐藏目标的网页。
使用 FrameBusting 代码
点击劫持攻击需要首先将目标网站载入到恶意网站中,使用 iframe 载入网页是最有效的方法。Web安全研究人员针对 iframe 特性提出 Frame Busting 代码,使用 JavaScript 脚本阻止恶意网站载入网页。如果检测到网页被非法网页载入,就执行自动跳转功能。 Frame Busting代码是一种有效防御网站被攻击者恶意载入的方法,网站开发人员使用Frame Busting代码阻止页面被非法载入。需要指出的情况是,如果用户浏览器禁用JavaScript脚本,那么FrameBusting代码也无法正常运行。所以,该类代码只能提供部分保障功能。
使用认证码认证用户
点击劫持漏洞通过伪造网站界面进行攻击,网站开发人员可以通过认证码识别用户,确定是用户发出的点击命令才执行相应操作。识别用户的方法中最有效的方法是认证码认证。例如,在网站上广泛存在的发帖认证码,要求用户输入图形中的字符,输入某些图形的特征等。
# 客户端端防御
升级浏览器
最新版本的浏览器提供很多防御点击劫持漏洞的安全机制,对于普通的互联网用户,经常更新修复浏览器的安全漏洞,能够最有效的防止恶意攻击。
NoScript 扩展
对于Firefox的用户,使用 NoScript 扩展能够在一定程度上检测和阻止点击劫持攻击。利用 NoScript 中 ClearClick 组件能够检测和警告潜在的点击劫持攻击,自动检测页面中可能不安全的页面。
# 网络劫持
网络劫持分为DNS劫持和HTTP劫持。实际场景中,输入A网站跳转到B网站属于DNS劫持,页面中出现广告的情况属于HTTP劫持。
# DNS劫持
DNS劫持就是通过劫持了DNS服务器,通过某些手段取得某域名的解析记录控制权,进而修改此域名的解析结果,导致对该域名的访问由原IP地址转入到修改后的指定IP,其结果就是对特定的网址不能访问或访问的是假网址,从而实现窃取资料或者破坏原有正常服务的目的。
- DNS强制解析: 通过修改运营商的本地DNS记录,来引导用户流量到缓存服务器。
- 302跳转的方式: 通过监控网络出口的流量,分析判断哪些内容是可以进行劫持处理的,再对劫持的内存发起302跳转的回复,引导用户获取内容。
# 防御
一般而言,用户上网的DNS服务器都是运营商分配的,由于涉嫌违法,已经被监管起来,现在很少会有DNS劫持,但仍要明白如何防御。
- 为域名注册商和注册用邮箱设置复杂密码且经常更换.
- 将域名更新设置为锁定状态,不允许通过DNS服务商网站修改记录,使用此方法后,需要做域名解析都要通过服务商来完成,时效性较差。
- 定期检查域名帐户信息、域名whois信息,査看事件管理器,清理Web网点中存在的可疑文件.
- 加强网站的防SQL注入功能,SQL注入是利用SQL语句的特点向数据库写内容,从而获取到权限的方法.
- 设置Web站点文件夹及文件操作权限.
- 利用事务签名对区域传送和区域更新进行数字签名.
- 删除运行在DNS服务器上的不必要服务.
- 在网络外围和DNS服务器上使用防火墙服务.
- 被劫持之后:
- 修改域名服务商和邮箱密码,定期更换复杂度高的密码.
- 删除无用的DNS解析,恢复DNS设置,关闭域名的泛解析.
- 排查网站代码,清除垃圾页面.
- 收集非法添加的页面并设置404,使用百度站长工具提交死链.
- 若使用的是第三方DNS服务,则立即修改第三方DNS服务端账户密码,锁定账户信息,开启邮件或短信提醒.
- 更换服务商.
# HTTP劫持
在运营商的路由器节点上,设置协议检测,一旦发现是HTTP请求,而且是html类型请求,则拦截处理,一般出现下面来着场景:
- 网址被无辜跳转,多了推广尾巴,类似DNS劫持;
- 页面出现额外的广告(iframe模式或者直接同页面插入了dom节点)。
# 过程
- 在用户的浏览器连上被访问的网站服务器,发送了HTTP请求后,运营商的路由器会首先收到此次HTTP请求
- 运营商路由器的旁路设备标记此TCP连接为HTTP协议,可以抢在网站服务器返回数据之前发送HTTP协议的302代码进行下载软件的劫持
- 浏览器收到302代码后就会跳转到错误的软件下载地址下载软件了,随后网站服务器的真正数据到达后反而会被丢弃。
- 或者,旁路设备在标记此TCP连接为HTTP协议后,直接返回修改后的HTML代码,导致浏览器中被插入了运营商的广告,随后网站服务器的真正数据到达后最终也是被丢弃。
# 防御
最有效的办法就是全站HTTPS,将HTTP加密,这使得运营商无法获取明文,就无法劫持你的响应内容.
- 全站HTTPS
- 对外网做检测,上报被劫持的情况,通过投诉使得互联网服务提供商将该用户放入"黑名单"过滤掉,来达到短时间内免于被劫持的目的。
- 页面广告可能通过iframe方式,也可以通过dom节点方式,需要在首页检查这两种情况进行过滤。
window.addEventListener('DOMNodeInserted', checkDivHijack); function checkDivHijack(e) { var html = e ? (e.srcElement.outerHTML || e.srcElement.wholeText) : $('html').html(); var reg = /http:\/\/([^\/]+)\//g; var urlList = html.match(reg); if (!urlList || urlList.length == 0) { return; } reg = /^http:\/\/(.*\.qq\.com|.*\.gt/img\.cn|.*\.qlogo\.cn|.*\.qpic\.cn|.*\.wanggou\.com)\/$/; var hijack = false; for (var i = 0; i < urlList.length; i++) { if (!reg.test(urlList[i])) { hijack = true; break; } } }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 参考
# 案例:
https://www.ghacks.net/2008/01/17/dos-vulnerability-in-utorrent-and-bittorrent/
https://www.davidairey.com/google-Gmail-security-hijack/