客户端脚本安全
浏览器安全
同源策略
限制了来自不同源的document或脚本，对当前“document”读取或设置某些属性。
浏览器沙箱
让不信任的代码的网页代码，javascript代码运行在受限制环境中，从而保护本地桌面系统安全。
Google Chrome 主要进程：浏览器进程，渲染进程，插件进程(flash，java，pdf等与浏览器严格隔离互不影响)，扩展进程。
恶意网址拦截
浏览器周期性从服务器端获取最新的恶意网址黑名单，用户上网访问的网址存在此黑名单浏览器将弹出一个警告页面
挂马网站：包含恶意脚本如js或Flash，利用浏览器漏洞（包括插件，控件漏洞）执行shellcode,在用户电脑中植入木马
钓鱼网站：模仿知名网站的相似页面来欺骗用户
高速发展的浏览器安全
浏览器插件安全
跨站脚本攻击（XSS）
XSS分类
反射型XSS：简单将用户输入的数据”反射“给浏览器。黑客需要诱使用户“点击”一个恶意链接，才能攻击成功。【非持久型XSS】
存储型XSS：将用户输入的数据”存储“服务器端。很强的稳定性【持久型XSS】
DOM Based XSS：(从效果上看属于反射型XSS)通过修改页面的DOM节点形成的XSS
XSS Payload
XSS攻击成功后攻击者能够对用户当前浏览器进行控制的恶意脚本。
【js脚本（还可以是Flash或其他富客户端脚本）】
XSS钓鱼
验证码：XSS Payload 可通过读取页面内容，将验证码的图片URL发送到远程服务器上实施——攻击者可在远程xss后台接收当前验证码，并将验证码的值返回当前XSS payload，从而绕过验证码
修改密码：攻击者可将XSS与“钓鱼相结合”利用js在当前页面构造一个伪造的登录框，当用户输入账号密码后，密码将会发送到黑客服务器中
识别用户浏览器
识别用户安装的软件
CSS History Hack
style的visited属性判断用户是否曾经访问过某个连接
XSS攻击平台
Attack API
总结了大量可直接使用的XSS Payload，归纳为API的方式。“获取客户端本地信息的API用户真实IP地址”出自这个项目
BeEF
曾是最好的XSS演示平台。不同于Attack API，BeEF演示的是一个完整的XSS攻击过程。BeEF有一个控制台，攻击者可在后台控制前端一切。每个被XSS攻击的用户都将出现在后台，后台控制者可以控制这些浏览器行为，并将通过XSS向用户发送命令
XSS-Proxy
轻量级XSS攻击平台，通过嵌套iframe的方式实时地远程被XSS攻击的浏览器
终极武器：XSS Worm
发起XSS Worm 攻击条件：用户之间发生交互行为的，如果存在存储型XSS，则比较容易发起XSS Wrom攻击。
XSS构造技巧
利用字符编码
var redirectUrl=“”;alert(/XSS/)"; 系统转义双引号导致变量无法闭合
利用事件（Event） 缩短所需要的字节数
输出为"onclick=alert(1)//"绕过限制长度
window对象不受同源策略的限制，攻击者可以利用这个对象实现跨域，跨页面传递数据。
在同一窗口打开XSS站点后，只需要XSS执行以下代码即可：eval(name);【eval将字符串转换为表达式】
- <script>window.name = "alert(document.cookie)"; location.href = "http://www.xssedsite.com/xssed.php";</script>
- 标签将指定其后的标签默认从base标签中获取URL。可以通过在远程服务器上伪造图片，链接或者脚本，劫持当前页面中使用“相对路径”标签“定义页面上的所有使用“相对路径”标签的hosting地址。
例如可以控制两个文本框第二个文本框支持写入更多字节。此时可以利用HTML的”注释符号“，把两个文本框之间的HTML代码全部注释掉，从而 打通两个<input>标签。重新写XSSPayload
将XSSPayload存放location.hash中（服务器日志中不会记录location.hash 的内容隐藏黑客真实意图）执行1 <input type="text" value="" onclick="eval(location.hash.substr(1))">
利用注释符绕过长度限制。
使用<base>标签
windows.name的妙用
”鸡肋“漏洞变废为宝
Apache Expect Header XSS
Anehta的回旋镖
Flash XSS
JavaScript 开发框架
Dojo
YUI
XSS防御
HttpOnly【四两拨千斤助于缓解XSS攻击】
HttpOnly解决的是XSS后 的Cookie劫持攻击
如果业务非常复杂，则需要在所有的set-Cookie的地方，给关键Cookie都加上HttpOnly。漏掉一个地方都可能使得这个方案失效。
浏览器将禁止页面的Javascript访问带有HttpOnly属性的Cookie
输入检查
格式检查：检查用户输入的数据中是否包含一些特殊字符，<、>、‘、”、等。如果发现存在特殊字符，则将这些字符过滤或者编码。
XSS Filter 匹配XSS特征：查找用户数据是否包含了<script>,javascript等敏感字符。
输出检查
针对HTML代码编码方式：HtmlEncode——将字符串转换为HTMLEntities（编码实体化）
针对JavaScript代码编码方式：JavascriptEncode
XMLEncode
JSONEncode
< -----><
.> ----->>
" ----->"
需要使用“”对特殊字符进行转义。
安全编码函数
要求输出的变量必须在引号内部避免造成安全问题。
正确地防御XSS
如果网站使用MVC架构，那么XSS就发生在View层——在应用拼接变量到HTML页面时产生。
防御DOM Based XSS
1.URL的path（路径）或者search（参数）中输出，使用URLEncode即可。
2.如果变量是整个URL，则应该先检查变量是否以”http“开头（如果 不是则自动添加），以保证不会出现伪协议类的XSS攻击
空格转换为%20
<转换为%3c
将字符串转换为%HH形式
尽可能禁止用户可控制在变量在“<style>标签” 、“HTML标签的style属性”以及"CSS文件"中输出。如果一定有这样需求推荐使用OWASP ESAPI 中的encodeForCSS()函数。
实现原理：类似于ESAPI.encoder（）.encodeForJavaScript()函数，除了字母 、数字外的所有字符都被编码成十六进制形式”uHH“。
1test
1.<script> var x ="";alert(/xss/);//";</script>
1.<div id="abc" name=""><script>alert(/XSS/)</script><""></div>
1.<div><script>alert(/XSS/)</script></div>
在HTML标签中输出
在HTML属性中输出
在<script>标签中输出
在事件中输出
在CSS中输出
在地址中输出
document.write()
document.writeln()
xxx.innerHTML=
xxx.outerHTML=
innerHTML.replace
document.attachEvent()
window.attchEvent()
document.location.replace()
document.location.assign()
......
在document.write输出到HTML页面时，如果是输出到事件或者脚本，则要再做一次javascriptEncode
在document.write输出到HTML页面时，如果是输出到事件或者脚本，则要再做一次HtmlEncode
将HTML代码写入DOM节点，最后导致了XSS的发生
在”$var“输出到<script>时，应该执行一次javascriptEncode；
服务器端直接输出变量到JavScript输出到HTML页面的必经之路【重点关注这几个地方的参数是否可以被用户控制】
页面中所有的inputs框
windows.location(href、hash等)
window.name
document.referrer
document.cookie
localstorage
XML HttpRequest返回的数据
“HTML注入”用户数据作为HTML代码执行，从而混淆了原本的语义，产生新的语义。
换个角度看XSS风险(业务风险角度)
攻击过程来说：
反射型XSS一般要求攻击者诱使用户点击一个包含XSS代码的URL链接
存储型XSS则只需要让用户查看一个正常的URL链接，XSSPayload会被执行。漏洞极其隐蔽，且埋伏在用户的正常业务中风险颇高
风险角度来看：
用户之间有互动的页面是可能发起XSS Worm攻击的地方。而根据不同页面PageView高低，也可以分析出哪些页面受XSS攻击影响会更大。如网站首页发生的XSS攻击肯定比网站合作伙伴页面的XSS攻击严重的多
从业务风险角度：来重新定位每个XSS漏洞更具有意义
跨站点请求伪造（CSRF）
CSRF简介
攻击者仅仅诱使用户访问一个页面，就以该用户身份在第三方站点里面执行一次操作。
CSRF本质
重要操作的所有参数都是可以被攻击者猜测的到
CSRF进阶
浏览器的Cookie策略
Session Cookie 又称”临时Cookie“ 没有指定Exprie时间，所以当浏览器关闭后Session Cookie 就会失效了。
Third—party Cookie是服务器在Set—Cookie时指定了Expire时间，之后到了Exprie时间后Cookie才会失效，所以这种cookie会保存在本地；当浏览器从一个域的页面种，要加载到另一个域的资源由于安全原因，某些浏览器会阻止Third-party Cookie的发送。
浏览器持有的Cookie分为两种
IE出于安全考虑默认禁止浏览器在<img>、<iframe>、<script>,<link>、标签中发送第三方Cookie
Firefox中默认策略是允许发送第三方Cookie的
如果攻击目标并不需要使用Cookie,则也不需要顾虑浏览器的Cookie策略
P3P头的副作用
P3P Header是W3C制定的一项关于隐私的标准，全称是The Platfrom for Privacy Preferences
如果网站返回给浏览器的HTTP头中包含有P3P头，在某种程度上来说将允许浏览器发送第三方Cookie。在IE下即使<script>、<ifame>等标签也将不再拦截第三方Cookie 的发送。
在网站中的业务中P3P头主要用于类似广告等需要跨域访问的页面，一次设置，每次请求都会遵守策略而不需要再重复设置。遗憾的是P3P头设置后对Cookie的影响将扩大到整个域中的所有页面。【cookie是以域和path为单位的】并不符合”最小权限原则。
GET？POST？都存在CSRF
Flash CSRF
CSRF Wrom
即使没有XSS漏洞，仅靠CSRF，也能够发起大规模蠕虫攻击
CSRF的防御
验证码
强制用户必须与应用交互，才能完成最终请求。
处于用户体验的角度验证码只能作为防御CSRF的防御手段，并不能作为最主要的解决方案
对抗CSRF攻击最简单而有效的防御方法
Referer Check
很多用户处于隐私保护考虑，限制了Referer的发送。
再某些情况下，浏览器也不会发送Referer，如从HTTPS跳转到HTTP出于安全考虑，浏览器也不会发送Referer
Flash的一些版本加强了安全限制，不再允许发送自定义Referer头。
出于种种原因，我们还是无法依赖于Referer Check 作为防御CSRF的主要手段，但通过Referer Check 来监控CSRF 攻击的发生，倒是可行的方法
常见应用防止图片盗链
用于检查请求是否来自合法的源
Referer Check的缺陷在于，服务器并非什么时候都能取到Referer。
Anti CSRF Token
不可预见性原则方案
保密性+随机性
允许一个用户的有效生命周期内在Token消耗掉前都使用同一个Token。但是如果用户已经提交了表单则这个Token已经消耗掉应该再次重新生成新的Token
如果Token保存在Cookie中，而不是服务器端Session中，则会带来一个新的问题。如果一个用户打开几个相同的页面同时操作，当某个页面被消耗掉Token后，其他的页面的表单内保存的还是被消耗掉的那个Token，因此其他页面的表单再次提交时，会出现Token错误。在这种情况下，可以考虑生成多个有效的Token，以解决多页面共存场景。
Token的保密性。Token如果出现在某页面的URL中则可能会通过Referer的方式泄露。尽可能将Token放在表单中。把敏感操作由GET改为POST。以from表单（或AJAX）形式提交，可以避免Token泄露。
XSS跨域漏洞或一些跨域漏洞都能让攻击者窃取Token。XSS带来的问题，应该使用XSS的防御防范予以解决，否则CSRF的Token防御将是空中楼阁
一致，合法请求
不一致，或者为空，则请求不合法可能产生CSRF
Token足够随机，保证使用足够安全的随机数生城算法，或者采用真随机数生成器（物理随机）。实际应用中Token可以放在用户的Session中，或者浏览器Cookie中。
Token需要同时放在表单和Session中。在提交请求中，服务器中需要表单中Token与用户Session（或Cookie）中的Token是否一致。
Token的使用原则
点击劫持（ClickJacking）
Flash点击劫持
攻击者通过Flash构造出点击劫持在完成一系列复杂动作后最终控制了用户电脑摄像头
图片覆盖攻击
通过调整图片的style使得图片能够覆盖在他所指定的任意位置形成点击劫持
拖拽劫持与数据窃取
触屏劫持
防御 ClickJacking
frame busting
写一段Javascript代码，以禁止iframe的嵌套。但控制能力不是很强，因此有许多方法可以绕过
X-Frame-Option三个可选值
允许frame加载页面地址
则frame页面的地址只能为同源域名下的页面
子主题 1
浏览器会拒绝当前页面加载的任何frame页面；
DENY
SAMEORIGIN
ALLOW-FROM origin
Firefox 的”Content Security Policy“
Firefox的”NoScript“扩展
简介
通过调整iframe页面位置跨域诱使用户恰好点击在iframe页面的一些功能性按钮上。
视觉上的欺骗手段。
攻击者使用一个透明的、不可见的iframe,覆盖在一个页面上，然后诱使用户在该页面上进行操作，
此时用户将在不知情的情况下点击透明的iframe页面。
但CSRF攻击过程中，如果出现用户交互的页面则攻击可能会无法栓里完成。点击劫持不存在这些顾虑，它利用的就是与用户产生交互页面
点击劫持与CSRF攻击有异曲同工之妙，都是在用户不知情的情况之下诱使用户完成的一些动作。
HTML5安全
iframe 的 sadbox
HTML5专门为iframe定义了一个新的属性，叫sandbox，使用这一属性后，<iframe>标签加载的内容将被视为一个独立的”源“（参考同源策略）其中的脚本将被禁止执行，表单被禁止提交，插件被禁止加载，指向其他浏览器对象的链接也会被禁止。
一个iframe的实例：<iframe sandbox=”allow-same-orgial allow-froms allow-scripts“ src=”http://maps.example.com/embedded.html“></iframe>
allow—same-origin：允许同源访问；
allow-top-navigation：允许访问顶层窗口
allow-froms：允许提交表单
allow-scripts：允许执行脚本
sandbox属性将极大地增强应用使用iframe的安全性
新标签的XSS
Link Types：noreferrer
HTML5中为<a>标签定义了一个新的Link Types：noreferrer出于保护敏感信息和隐私的考虑，通过Referer可能会泄露一些敏感信息。标签通过开发者手动添加到页面标签中，对于有需求的的标签可以选择使用noreferrer
Canvas的妙用
- <canvas>标签让JavaScript可以在页面中直接操作图片对象，也可以直接操作像素，构造出图片区域。Canvas的出现极大的挑战了传统客户端插件的低位。开发者甚至可以使用Canvas在浏览器中写小游戏
其他安全问题
Cross-Origin Resource Sharing
Origin Header 用于标记HTTP发起的”源“，服务器端通过识别浏览器端自动带上这个Origin Header， 来判断浏览器请求是否来自一个合法的源。Orgin Header 可以用于防范CSRF，它不像Referer那么容易被伪造成功或者清空
Access-Control-Allow-Origin：*【即相当于没有任何安全设置】
postMessage-跨窗口传递消息
window这个对象几乎是不受同源策略限制，很多脚本攻击都巧妙地利用了Window对象的这一特点
postMessage允许每个window（包括当前窗口，弹出窗口，iframes等）对象往其他的窗口发送文本消息，从而实现跨窗口的消息传递，这个功能是不受同源策略限制的
使用postMessage（）时注意的两个安全问题
1.必要时，可以在接收窗口验证Domain甚至验证URL，以防止来自非法页面的消息。这实际上是在代码中实现一次同源策略的验证过程。
2.接受的消息写入textContent。若消息写入innerHTML甚至写入script中则可能会导致DOM based XSS的产生。据”Secure By Default“原则，在接收窗口中不应该信任接收到的消息，而需要对消息进行安全检查。
Web Storage
离线浏览功能
Session Storage关闭浏览器就会失效
Local Storage关闭浏览器仍然存在
如同关系型数据库，由Key-Value对组成，可通过JavaScript对其进行操作
设置一个值：window.sessionStorage.setItem（key，value）
读取一个值：window.sessionStrorage.getItem(key)
Web Strange让Web开发更灵活多变，他的强大使得XSS Payload打开方便之门。攻击者可能将恶意代码保存在Web Strotage中，从而实现跨页面攻击
JavascriptEncode
HtmlEncode
cookie使用过程
Step1：浏览器向服务器发起请求此时没有Cookie。
Step2：服务器返回时发送Set-Cookie头，向客户端浏览器写入cookie【HttpOnly是在Set-Cookie时标记的】
Step3：在该Cookie到期前，浏览器访问该域下所有页面，都将发送Cookie。
子主题 4