[书籍精读]《Web前端黑客技术揭秘》精读笔记分享

写在前面

• 书籍介绍：Web前端的黑客攻防技术是一门非常新颖且有趣的黑客技术，主要包含Web前端安全的跨站脚本（XSS）、跨站请求伪造（CSRF）、界面操作劫持这三个大类，涉及的知识点涵盖信任与信任关系、Cookie安全、Flash安全、DOM渲染、字符集、跨域、原生态攻击、高级钓鱼、蠕虫思想等，这些都是研究前端安全的人必备的知识点。本书作者深入剖析了许多经典的攻防技巧，并给出了许多独到的安全见解。
• 我的简评：这本书出版好几年了（13年出版的），上面写的很多HTML漏洞、CSS漏洞、JavaScript漏洞以及浏览器漏洞现在已经都被修复了。但Web前端安全这个主题对于我们开发人员来说，还是非常重要的一块知识点，特别是对于大型公司项目的开发人员。而且对于Web前端黑客技术的了解，体现出一个技术人员的技术层次及对于技术的热衷和钻研程度。所以还是很推荐朋友们阅读此书。
• ！！福利：文末有pdf书籍、笔记思维导图、随书代码打包下载地址哦

第一章 Web安全的关键点

1.1.数据与指令

• 用浏览器打开一个网站，呈现在我们面前的都是数据，有服务端存储的（如：数据库、内存、文件系统等）、客户端存储的（如：本地Cookies、Flash Cookies等）、传输中的（如：JSON数据、XML数据等），还有文本数据（如：HTML、JavaScript、CSS等）、多媒体数据（如：Flash、Mp3等）、图片数据等。
• 两个例子的攻击场景：1.SQL注入攻击的发生；2.XSS跨站脚本攻击的发生
• 跨站攻击发生在浏览器客户端，而SQL注入攻击由于针对的对象是数据库，一般情况下，数据库都在服务端，所以SQL注入是发生在服务端的攻击

1.2.浏览器的同源策略

• 计算机的本地与Web是不同的层面，Web世界（通常称为Internet域）运行在浏览器上，而被限制了直接进行本地数据（通常称为本地域）的读写
• 同源策略规定：不同域的客户端脚本在没明确授权的情况下，不能读写对方的资源。其中有几个关键词：不同域、客户端脚本、授权、读写、资源
• 1.不同域或同域：同域要求两个站点同协议、同域名、同端口
• 2.客户端脚本：主要指JavaScript（各个浏览器原生态支持的脚本语言）、ActionScript（Flash的脚本语言），以及JavaScript与ActionScript都遵循的ECMAScript脚本标准
• 3.授权：HTML5新标准中提到关于Ajax跨域访问的情况，默认情况下是不允许跨域访问的，只有目标站点明确返回HTTP响应头
• 4.读写权限：Web上的资源有很多，有的只有读权限，有的同时拥有读和写的权限。比如：HTTP请求头里的Referer（表示请求来源）只可读，而document.cookie则具备读写权限
• 5.同源策略里的资源是指Web客户端的资源。一般来说，资源包括：HTTP消息头、整个DOM树、浏览器存储（如：Cookies、Flash Cookies、localStorage等）

1.3.信任与信任关系

• 安全类似木桶原理，短的那块板决定了木桶实际能装多少水。一个Web服务器，如果其上的网站没做好权限分离，没控制好信任关系，则整体安全性就由安全性最差的那个网站决定
• 很多网站都嵌入了第三方的访问统计脚本，嵌入的方式是使用<script>标签引用，这时就等于建立了信任关系，如果第三方的统计脚本被黑客挂马，那么这些网站也都会被危及

1.4.社会工程学的作用

• 常用的社工辅助技巧有：Google Hack、SNS垂直搜索、各种收集的数据库集合查询等

1.5.攻防不单一

• CSRF会借用目标用户的权限做一些借刀杀人的事（注意是“借用”，而不是“盗取”目标权限），然后去做坏事，“盗取”通常是XSS（跨站脚本攻击）最喜欢做的事

第二章 前端基础

2.1.W3C的世界法则

• Web安全事件的角色如下：W3C、浏览器厂商、Web厂商、攻击者（或黑客）、被攻击者（或用户）

2.2.URL

• URL是互联网最伟大的创意之一，也就是我们经常提的链接，通过URL请求可以查找到唯一的资源
• URL有个重点就是编码方式，有三类：escape、encodeURI、encodeURIComponent，对应的解码函数是：unescape、decodeURI、decodeURIComponent

2.3.HTTP协议

• URL的请求协议几乎都是HTTP，它是一种无状态的请求响应，即每次的请求响应之后，连接会立即断开或延时断开（保持一定的连接有效期），断开后，下一次请求再重新建立
• User-Agent很重要，用于表明身份（我是谁）。从这里可以看到操作系统、浏览器、浏览器内核及对应的版本号等信息
• 通过Cookies进行会话跟踪，第一次响应时设置的Cookies在随后的每次请求中都会发送出去。Cookies还可以包括登录认证后的身份信息
• 针对不同的资源类型会有不同的解析方式，这个会影响浏览器对响应体里的资源解析 方式，可能因此带来安全问题。字符集也会影响浏览器的解码方式，同样可能带来安全问题

2.4.松散的HTML世界

• HTML里可以有脚本、样式等内容的嵌入，以及图片、多媒体等资源的引用
• HTML是由众多标签组成的，标签内还有对应的各种属性。这些标签可以不区分大小写，有的可以不需要闭合。属性的值可以用单引号、双引号、反单引号包围住，甚至不需要引号。多余的空格与Tab毫不影响HTML的解析。HTML里可以内嵌CSS、JavaScript等内容，而不强调分离，等等
• 很多前端安全问题就是因为松散导致的
• 1.DOM树：很多数据都存在于DOM树中，通过DOM树的操作可以非常容易地获取到我们的隐私数据；隐私数据可能存储在以下位置（HTML内容中、浏览器本地存储中，如Cookies、URL地址中）
• 2.iframe内嵌出一个开放的世界：iframe标签是HTML中一个非常重要的标签，也是Web安全中出镜频率最高的标签之一，很多网站都通过iframe嵌入第三方内容；iframe标签带来了很多便利，同时也带来了很多风险，比如，攻击者入侵一个网站后，可以通过iframe嵌入自己的网马页面，用户访问该网站后，被嵌入的网马页面就会执行；如果父页和子页之间是同域，那就很容易，父页可以通过调用子页的contentWindow来操作子页的DOM树，同理，子页可以调用父页的contentWindow来操作父页的DOM树。如果它们不同域，则必须遵守同源策略，但子页还是可以对父页的location进行写操作，这样可以让父页重定向到其他页面。不过对location的操作仅仅只是写权限，而没有读权限，这样就不能获取到父页location URL的内容，否则有可能会造成隐私数据泄露；
• 3.HTML内嵌脚本执行：JavaScript脚本除了出现在JS格式文件里，被嵌入而执行外，还可以出现在HTML的<script></script>标签内、HTML的标签on事件中，以及一些标签的href、src等属性的伪协议（javascript：等）中；

2.5.跨站之魂-JavaScript

• 有了XSS漏洞，就意味着可以注入任意的JavaScript，有了JavaScript，就意味着被攻击者的任何操作都可以模拟，任何隐私信息都可以获取到
• DOM树操作：1.获取HTML内容中的隐私数据；2.获取浏览器的Cookies数据（Cookies中保存了用户的会话信息，通过document.cookie可以获取到，不过并不是所有的Cookies都可以获取）；3.获取URL地址中的数据
• AJAX风险：Ajax简直就是前端黑客攻击中必用的技术模式；利用Ajax的攻击显得很诡异，无声无息；不是任何请求头都可以通过JavaScript进行设置的，W3C给出了一份头部黑名单；如果目标域不设置Access-Control-Allow-Origin，虽然浏览器会报权限错误的问题，但实际上隐私数已经被目标域的代码接收到了；默认情况下，这样的跨域无法带上目标域的会话（Cookies等），需要设置xhr实例的withCredentials属性为true（IE还不支持）；如果设置了Access-Control-Allow-Credentials为true，那么Access-Control-Allow-Origin就不能设置为*通配符，这也是浏览器为了安全进行的考虑；
• 模拟用户发起浏览器请求：XMLHttpRequest对象就是一个非常方便的方式，可以模拟表单提交，它有异步与同步之分，差别在于XMLHttpRequest实例化的对象xhr的open方法的第三个参数，true表示异步，false表示同步，如果使用异步方式，就是Ajax；前端黑客攻击中，比如XSS经常需要发起各种请求（如盗取Cookies、蠕虫攻击等），上面的几种方式都是XSS攻击常用的，而最后一个表单自提交方式经常用于CSRF攻击中；
• Cookie安全：Cookie是一个神奇的机制，同域内浏览器中发出的任何一个请求都会带上Cookie，无论请求什么资源，请求时，Cookie出现在请求头的Cookie字段中。服务端响应头的Set-Cookie字段可以添加、修改和删除Cookie，大多数情况下，客户端通过JavaScript也可以添加、修改和删除Cookie；Cookie经常被用来存储用户的会话信息，用户登录认证后的Session，之后同域内发出的请求都会带上认证后的会话信息，非常方便。攻击者就特别喜欢盗取Cookie，这相当于盗取了在目标网站上的用户权限；
• 本地存储风险：本地存储的主要风险是被植入广告跟踪标志，有的想删都不一定能删除干净；广为人知的evercookie，还使用了以下存储（Silverlight的IsolatedStorage、PNG Cache、类似PNG Cache机制的还有HTTP Etags、Web Cache、Web History、window.name）；
• e4x带来的混乱世界：对于JavaScript来说，当前只有Firefox支持E4X，这种技术是将XML作为JavaScript的对象；通过使用E4X技术，可以混淆JavaScript代码，甚至绕开一些过滤规则；
• JavaScript函数劫持：JavaScript函数劫持很简单，一般情况下，只要在目标函数触发之前，重写这个函数即可；曾经的浏览器劫持document.write、document.writeln也同样是这样的方式；

2.6.一个伪装出来的世界-CSS

• CSS即层叠样式表，用于控制网页的呈现样式，如颜色、字体、大小、高宽、透明、偏移、布局等，通过灵活运用CSS技巧，攻击者可以伪装出期望的网页效果，从而进行钓鱼攻击
• CSS容错性
• 样式伪装：伪装出来的UI效果让人感觉就是真的
• CSS伪类：曾经出现比较久的CSS History攻击利用的就是:visited伪类技巧进行的，原理很简单，就是准备一批常用的链接，加上:visited{ background:url(xxxxx) }样式；如果其中的某链接之前访问过（也就是存在于记录中的），那么:visited就会触发，随后会发送一个唯一的请求到目标地址，这样就可以知道被攻击者的历史记录是否有这个链接，不过这个方式已经被浏览器修补了；但还有一些伪类是有效的。比如::selection伪类，当指定对象区域被选择时，就会触发::selection，这个在Chrome下有效；
• CSS3的属性选择符：CSS还可以内嵌脚本执行

2.7.另一个幽灵-ActionScript

• ActionScript（简称AS）和JavaScript一样遵循ECMAScript标准。ActionScript由Flash的脚本虚拟机执行，运行环境就在Flash Player中，而Flash Player的运行环境主要有两个：浏览器与操作系统本地，Flash有自己的安全沙箱来限制ActionScript的能力，否则通过ActionScript可以进行很多危险的操作
• flash安全沙箱：Flash安全沙箱是用来制定ActionScript的游戏规则的；安全沙箱包括远程沙箱与本地沙箱。其实这个沙箱模型类似于浏览器中的同源策略。在同一域内的资源会被放到一个安全组下，这个安全组被称为安全沙箱；
• html嵌入flash的安全相关配置
• 跨站flash：跨站Flash也称Cross Site Flash（XSF），即通过ActionScript来加载第三方Flash文件，攻击者如果对这个过程可控，那么他们就可以让目标Flash加载恶意的Flash文件，从而造成XSF攻击；
• 参数传递
• flash里的内嵌html：Flash内嵌HTML不能很随意，且支持的标签有限；
• 与JavaScript通信：1.getURL()与navigateToURL()；2.ExternalInterface；
• 网络通信：URLLoader与URLRequest组合进行文本数据的请求，这是AS3种绝佳的组合，GET/POST数据都很方便，如果仅是发送数据出去，而不需要得到响应，则直接用sendToURL函数+URLRequest组合；如果要使用socket请求，则可以使用Socket类或XMLSocket类；AMF（Action Message Format）是Flash和服务端通信的一种常见的二进制编码模式，其传输效率高，可以在HTTP层面上传输；分析了一些外挂，有专门模拟AMF消息进行各种恶意操作的；
• 其他安全问题：发现Flash的一些重要数据或逻辑运算直接在本地进行。这是错误的，通过一些流行的反编译工具（比如HP swfdump.exe等）就能得到ActionScript代码；牢记，重要的数据或运算不要在本地进行；

第三章 前端黑客之XSS

3.1.XSS概述

• XSS即跨站脚本，发生在目标网站中目标用户的浏览器层面上，当用户浏览器渲染整个HTML文档的过程中出现了不被预期的脚本指令并执行时，XSS就会发生
• 跨站脚本的重点不在“跨站”上，而应该在“脚本”上
• 可以通俗地总结XSS为：想尽一切办法将你的脚本内容在目标网站中目标用户的浏览器上解析执行

3.2.XSS类型

• XSS有三类：反射型XSS（也叫非持久型XSS）、存储型XSS（也叫持久型XSS）和DOM XSS
• 反射型XSS：发出请求时，XSS代码出现在URL中，作为输入提交到服务端，服务端解析后响应，在响应内容中出现这段XSS代码，最后浏览器解析执行
• 存储型XSS和反射型XSS的差别仅在于：提交的XSS代码会存储在服务端（不管数据库、内存还是文件系统等），下次请求目标页面时不再提交XSS代码
• 最典型的例子是留言板XSS。存储型XSS的攻击是最隐蔽的
• DOM XSS和反射型XSS、存储型XSS的差别在于，DOM XSS的XSS代码并不需要服务器解析响应的直接参与，触发XSS靠的就是浏览器端的DOM解析，可以认为完全是客户端的事情
• DOM XSS的处理逻辑就在客户端

3.3.哪里可以出现XSS攻击

• XSS涉及的场景可以很广，现在越来越多的客户端软件支持HTML解析和JavaScript解析，比如：HTML文档、XML文档、Flash、PDF、QQ、一些音乐播放器、一些浏览器的功能界面等

3.4.有何危害

• 挂马
• 盗取用户Cookie
• Dos（拒绝服务）客户端浏览器
• 钓鱼攻击，高级钓鱼技巧
• 编写针对性的XSS病毒，删除目标文章、恶意篡改数据、嫁祸于人
• 劫持用户Web行为，甚至进一步渗透内网
• 爆发Web 2.0蠕虫
• 蠕虫式的DDoS攻击
• 蠕虫式挂马攻击、刷广告、刷流量、破坏网上数据

第四章 前端黑客之CSRF

写在前面

• CSRF的全称是Cross Site Request Forgery，即跨站请求伪造
• CSRF对于那些开源网站、多用户的网站、社交网站等来说非常值得关注，此时的CSRF可以直接攻击管理员后台或者其他用户

4.1.CSRF概述

• 对于CSRF来说，它的请求有两个关键点：跨站点的请求与请求是伪造的
• 可以认为：如果请求的发出不是用户的意愿，那么这个请求就是伪造的
• 删除文章的示例：这个攻击过程有三个关键点，跨域发出了一个GET请求、可以无JavaScript参与、请求是身份认证后的

4.2.CSRF类型

• 按照攻击方式来说，CSRF可分为：HTML CSRF攻击、JSON HiJacking攻击和Flash CSRF攻击等
• HTML中能够设置src/href等链接地址的标签都可以发起一个GET请求
• 还有通过JavaScript动态生成的标签对象或CSS对象发起的GET请求，而发出POST请求只能通过form提交方式
• Flash的世界同样遵循同源策略，发起的CSRF攻击是通过ActionScript脚本来完成的
• 说到Flash CSRF，通常会想到以下两点：跨域获取隐私数据；跨域提交数据操作，一些如添加、删除、编辑等操作的请求

4.3.有何危害

• 篡改目标网站上的用户数据
• 盗取用户隐私数据
• 作为其他攻击向量的辅助攻击手法
• 传播CSRF蠕虫

第五章 前端黑客之界面操作劫持

5.1.界面操作劫持概述

• 界面操作劫持攻击是一种基于视觉欺骗的Web会话劫持攻击。它通过在网页的可见输入控件上覆盖一个不可见的框（iframe），使得用户误以为在操作可见控件，而实际上用户的操作行为被其不可见的框所劫持，执行不可见框中的恶意劫持代码，从而完成在用户不知情的情况下窃取敏感信息、篡改数据等攻击
• 从其技术发展阶段上分析，可以分为以下三种：点击劫持、拖放劫持、触屏劫持
• 点击劫持：其首先劫持的是用户的鼠标点击操作，它主要的劫持目标是有重要会话交互的页面
• 拖放劫持：在浏览器中，拖放操作是不受“同源策略”限制的，用户可以把一个域的内容拖放到另一个不同的域
• 触屏劫持：智能移动设备已经成为黑客们攻击的新目标

5.2.界面操作劫持技术原理分析

• 透明层+iframe：这里的“覆盖”是指控件位置之间的层次关系，“不可见的”是指页面的透明度为零，而“框”则指的是iframe标签。所以。“覆盖一个不可见的框”可以理解成“透明层”+ “iframe”
• 通过页面透明度+iframe实现了对用户的视觉欺骗，即用户看到的操作对象与实际操作对象是不一致的，从而为界面操作劫持攻击提供了技术手段
• dataTransfer作为event对象的一个属性出现，用于从被拖动的对象传递字符串到放置对象
• setData操作完成向系统剪贴板中存储需要传递的数据，传递数据分为两种类型：文本数据和URL数据。在HTML5的扩展中，其允许指定任意的MIME类型
• 拖放劫持的操作函数稍微复杂一些，浏览器中可以拖放的对象一直在不断地增加，图片、链接和文本都是可以拖动的
• IPhone Safari浏览器有一个特殊的功能，即可以把网页添加到IOS操作系统的桌面当作一个程序图标来显示
• 在这些触屏移动设备中，同样可以使用透明度+iframe方法，然后配合触屏设备中自身的API函数来发起触屏劫持攻击

5.3.界面操作劫持实例

• 点击劫持：微博的关注按钮示例
• 拖放劫持：小游戏

5.4.有何危害

• 界面操作劫持实际上突破了CSRF的防御策略。它带来的危害可以很大，比如，删除与篡改数据、偷取隐私设置爆发蠕虫

第六章 漏洞挖掘

写在前面

• 一个漏洞的产生可能与很多因素有关，比如，浏览器差异（或说浏览器特性）、浏览器BUG、字符集问题、漏洞对象、所在场景等
• CSRF的漏洞挖掘只要确认以下内容即可：目标表单是否有有效的token随机串；目标表单是否有验证码；目标是否判断了Referer来源；网站根目录下crossdomain.xml的“allow-access-fromdomain”是否是通配符；目标JSON数据似乎可以自定义callback函数等；
• 界面操作劫持的漏洞挖掘只要确认以下内容即可：目标的HTTP响应头是否设置好了X-Frame-Options字段；目标是否有JavaScript的Frame Busting机制；更简单的就是用iframe嵌入目标网站试试，若成功，则说明漏洞存在；

6.1.普通XSS漏洞自动化挖掘思路

• 自动化的XSS漏洞挖掘其实是很复杂的，难度也会很高。这和我们要实现的XSS漏洞挖掘工具的需求有关，是要效率（有了广度，却忽略了深度），还是要检出率（既有广度又有深度，漏洞个数多且准确度高）
• 工具自动化的思路，是一种针对反射型XSS、存储型XSS、头部XSS、CookieXSS等比较普通的XSS漏洞挖掘思路
• URL上的玄机：URL的一种常见组成模式：<scheme>://<netloc>/<path>?<query>#<fragment>；
• HTML上的玄机：两类特殊的标签<script>和<style>，它们是不能嵌套标签的，而且payload构造情况会更灵活；同样有意思的场景，比如这三类：1.输出在src/href/action等属性内；2.输出在on*事件内；3.输出在style属性内；对IE来说，在标签的style属性中只要能注入expression关键词，并进行适当的闭合，我们就可以认为目标存在XSS；
• 请求中的玄机：“探子请求”，在真正的payload攻击请求之前，总会发起一次无危害（不包含任何特殊符号）的请求，这个请求就像“探子”一样，来无影去无踪。不会被网站的过滤机制发现，就像一次正常的请求；“探子”的目的有以下两个（1.目标参数值是否会出现在响应上，如果不出现，就完全没必要进行后续的payload请求与分析；目标参数值出现在HTML的哪一个部分，从上面的分析我们已经知道，不同的HTML部分对待XSS的机制是不一样的，请求的payload当然也不一样）
• 关于存储型xss挖掘：这里一般是表单的提交，然后进入服务端存储中，最终会在某个页面上输出

6.2.神奇的DOM渲染

• HTML与JavaScript自解码机制：在JavaScript执行之前，HTML形式的编码会自动解码；
• 具备htmlencode功能的标签：HTML在<textarea>中是不解析的。这样的标签还有title、iframe、noscript、noframes；textarea在HTML中的权重很高，允许html标签出现在<textarea><textarea>之间；
• url编码差异
• dom修正式渲染：view-source这样看到的“HTML编码”实际上是静态的；按F12键打开对应的调试工具，这些调试工具查看的源码是动态结果；浏览器在DOM渲染上进行各种修正，不同的浏览器进行的这种修正可能存在一些差异。这种修正式的渲染可以用于绕过浏览器的XSS Filter；
• 一种dom fuzzing的技巧：模糊测试(fuzzing)；

6.3.DOM XSS挖掘

• 静态方法：一旦发现页面存在可疑特征，就进行人工分析，这是静态方法的代价，对人工参与要求很高
• 动态方法：动态方法很难完美的实现检测引擎，这实际上是一次JavaScript源码动态审计的过程

6.4.Flash XSS挖掘

• XFS挖掘思路：XSF即Cross Site Flash；很多网站的Flash播放器都会有XSF风险，因为这些播放器需要能够灵活加载第三方Flash资源进行播放；
• Google Flash XSS挖掘：Google对它们的域分离的非常好，把那些无关紧要的内容都放到了其他域名上，这样，这个XSS就是鸡肋了；

6.5.字符集缺陷导致的XSS

• ASCII字符集表达不了拉丁系的字符，更表达不了东亚字符，所以各种演变出现了诸多字符集，如ISO8859、GB2312、GBK、GB18030、BIG5、Shift_JIS，直到Unicode字符集出现，才看到了世界和平的曙光，但是各国的这些字符集还在沿用，不可能清零从头开始，所以这个字符的世界还是很混乱
• Unicode字符集的编码方式有UTF-8、UTF-16、UTF-32、UTF-7，常见的是UTF-8与UTF-7
• 编码的目的是最终将这些字符正确地转换为计算机可理解的二进制，对应的解码就是将二进制最终解码为人类可读的字符
• 宽字符编码带来的安全问题：主要是吃ASCII字符（一字节）的现象；从前端到后端的流程中，字符集编码处理不一致可能导致SQL注入、命令执行等一系列安全问题；
• UTF-7问题：UTF-7时Unicode字符集的一种编码方式，不过并非是标准推荐的，现在仅IE浏览器还支持UTF-7的解析；IE浏览器历史上出现以下好几类UTF-7 XSS（1.自动选择UTF-7编码；2.通过iframe方式调用外部UTF-7编码的HTML文件；不过现在IE限制了<iframe>只能嵌入同域内的UTF-7编码文件；3.通过link方式调用外部UTF-7编码的CSS文件；4.通过指定BOM文件头；BOM的全称为Byte Order Mark。即标记字节顺序码，只出现在Unicode字符集中，BOM出现在文件的最开始位置，软件通过识别文件的BOM来判断它的Unicode字符集编码方式）；在实际的攻击场景中，能控制目标网页开头部分的功能如下（用户自定义的CSS样式文件；JSON Callback类型的链接；）
• 浏览器处理字符集编码BUG带来的安全问题：标准总是过于美好，比如字符集标准，但是每个浏览器在实施这些标准时不一定就能很好地实施，所以不要轻信它们不会出现BUG

6.6.绕过浏览器XSS Filter

• 目前，主要是IE和Chrome两大浏览器拥有XSS Filter机制，不可能有完美的过滤器
• XSS Filter主要针对反射型XSS，大体上采用的都是一种启发式的检测，根据用户提交的参数判断是否是潜在的XSS特性，并重新渲染响应内容保证潜在的XSS特性不会触发
• 响应头crlf注入绕过
• 针对同域的白名单：严格来说，针对同域的白名单机制不是绕过，而是浏览器的性质，这种性质给反射型XSS的利用提供了便利，IE和Chrome在这个机制上不太一样；IE会判断Referer来源是否是本域，如果是，则XSS Filter不生效；Chrome的同域白名单机制和IE完全不一样。如果是<script>嵌入同域内的js文件，XSS Filter就不会防御，这个受CSP策略的影响；
• 场景依赖性高的绕过

6.7.混淆的代码

• 为了提高漏洞挖掘的成功率，我们经常需要对各种代码进行混淆，以绕过过滤机制
• 浏览器的进制常识：在浏览器中常用的进制混淆有八进制、十进制和十六进制；在JavaScript中可以直接通过eval执行的字符串有八进制和十六进制两种编码方式；需要注意的是，这两种表示方式不能够直接给多字节字符编码（如汉字、韩文等），如果代码中应用了汉字并且进行进制编码，那么只能进行十六进制Unicode编码；JavaScript自身就带有两个函数可以处理这个事情：char.toString(jinzhi)（char为需要编码的单字，jinzhi为需要编码的进制，可以填写2、8、10、16或其他之类数字）、String.fromCharCode(code, jinzhi)；
• 浏览器的编码常识：在JavaScript中，有三套编/解码的函数：escape/unescape、encodeURI/decodeURI、encodeURIComponent/decodeURIComponent；除了JavaScript提供的这三种加/解密方法外，我们还需要了解HTMLEncode、URLEncode、JSEncode、UTF-7编码、Base64编码的相关知识；
• html中的代码注入技巧：完整的HTML代码分为：标签名、属性名、属性值、文本、注释。其中可以是JavaScript事件、资源链接或data对象；1.标签：（由于HTML语言的松散性和各标签的不同优先级，使得我们可以创造出很多代码混淆或绕过方式；另外还有一种特殊的注释：IE HTML条件控制语句）；2.属性：（HTML标签中的属性同样也是大小写不敏感的，并且属性值可以用双引号引起来，也可以用单引号，甚至不用引号在HTML语法上也是正确的；此外，标签和属性之间、属性名和等号之间、等号和属性值之间可以用空格、换行符（chr(13)）、回车符（chr(10)）或者tab（chr(9)）等，并且个数不受限制；还有一个常识对我们来说非常重要，HTML中通过属性定义的事件在执行时会做HTMLDecode编码）；3.HTML事件（另一种特殊的HTML属性是事件属性，一般以on开头。它继承了普通的HTML属性的所有特点：大小写不敏感、引号不敏感等）
• css中的代码注入技巧：与HTML一样，我们可以将CSS分为选择符、属性名、属性值、规则和声明几部分；与HTML类似，CSS的语法同样对大小写不敏感，属性值对单引号不敏感，对资源类属性来说，URL部分的单双引号以及没有引号也都不敏感，并且凡是可以使用空格的地方使用tab制表符、回车和换行也都是可以被浏览器解析；1.CSS资源类属性：（与HTML的资源类属性类似，CSS的一些资源类属性的XSS利用也是通过伪协议来完成的，这种利用方式目前只能在IE下被执行，并且IE9已经可以防御住；CSS还有一类资源类属性可以嵌入XML、CSS或者JavaScript，比如，Firefox2独有的-moz-binding、IE独有的behavior以及规则@import）；2.expression：（expression是IE所独有的CSS属性，其目的就是为了插入一段JavaScript代码）；3.利用UTF-7编码进行CSS代码混淆（介绍monyer在线加解密工具时，提过两个加/解密：UTF7Encode和UTF7Decode。将页面进行UTF7编码，这为混淆我们的代码、绕过u对方的过滤器提供了很大便利）
• JavaScript中的代码注入技巧
• 突破url过滤：可以参考如下一些技巧来绕过过滤：URL编码、十进制、十六进制、八进制、混合编码、不带http:协议、最后加个点；
• 更多经典的混淆checklist：通过大量的模糊测试可以发现很多奇怪的XSS利用点，浏览器之间存在大量细微的差异，很难总结出完美的规律；可以参考html5sec.org网站上整理的Checklist，还有一个由Gareth Heyes主导构建起来的在线fuzzing平台（shazzer.co.uk）；

6.8.其他案例分享-GmailCookieXSS

• FireCookie是Firefox浏览器扩展Firebug的一个插件，专门用于Cookie的各种操作，非常方便

第七章 漏洞利用

• 漏洞利用要完美，就得保证利用过程的原生态，本意就是让被攻击者区分不出，甚至被攻击后很长一段时间或者永远都不知道发生过这样的事情

7.1.渗透前的准备

• 1.目标环境：对于开源CMS的渗透，可以通过白盒、黑盒 方式了解透，大大方便后续的渗透。而对于闭源的CMS，我们只能利用黑盒进行，会更麻烦，需多走几个步骤
• 2.目标用户：目标用户的角色可以很多种，如：CMS管理员、客服、普通用户、黑客/安全人员等
• 3.预期效果：最后明确本次渗透过程中每一阶段的效果，如：获取Cookie、添加一篇文章、传播网马、盗取密码、破坏数据等

7.2.偷取隐私数据

• XSS探针：xssprobe：通过它可以获取目标页面的通用数据；利用这些通用数据，有时能让我们直接获取目标用户的权限（通过Cookies利用）；
• referer惹得祸：Referer指请求来源，很多网站通过这个来判断用户是从哪个页面/网站过来的，Referer是公开的，故不可在Referer中存在与身份认证或者其他隐私相关的信息，但很多网站设计之初没考虑到Referer的风险性，从而导致出现了安全问题；
• 浏览器记住的明文密码：2010年时，各浏览器开始逐渐加入“记住密码”的功能（这些浏览器包括Firefox、Chrome、IE、Opera、Safari等），记住密码不同于老方式“记住登录状态”。“记住登录状态”主要是设置了持久型的Cookie，这和浏览器没关系，而是Web服务自己设置的；与记住表单内容相比，记住密码更危险，因为通过DOM就能获取其中的密码，而且是明文；可以在XSS利用中使用该POC获取用户的明文密码，由于不同的Web环境下的密码表单项不太一样，此时只需要修改相关的表单项值就行；
• 键盘记录器：键盘记录器实际上用处并不大，还不如劫持表单项的各种事件方便；

7.3.内网渗透技术

• 内网渗透是一门独立的学问，通过Web层面（主要是JavaScript）进行的内网渗透实际上是一种很浅的渗透，不过带来的威力有可能很大
• 获取内网ip：目前，内网IP的获取还有一个比较好的方式，即通过Java Applet，但需要JRE支持
• 获取内网ip端口：Image对象请求时，得到资源后就触发onerror事件（因为这个资源不是正常的图片），得不到就进入timeout机制，通过这个原理来判断目标IP与端口是否存在，不过这个功能不太稳定；还可以尝试通过跨域AJAX技巧或Web Socket方法实现IP端口的获取；
• 获取内网主机存活状态：主机存活状态的获取技巧很不错，本质是通过跨域AJAX请求进行的判断，比较稳定；
• 开启路由器的远程访问能力：默认的“远程管理IP地址”是0.0.0.0，如果设置为255.255.255.255，则允许互联网上任意IP进行远程Web方式的管理，即通过浏览器登录这台FAST的外网IP，输入用户名与密码即可进行管理操作；
• 内网脆弱的web应用控制：通过Referer有可能泄露内网Web应用的地址，即通过对Referer的判断可能猜测出这个Web应用的类型，还可以通过fuzzing方式，猜测内网可能存在的Web应用；常见的内网Web应用类型有：BBS、Blog、Trac、Wiki、OA、WebMail、项目管理、客服后台、存在漏洞的Web应用环境等；

7.4.基于CSRF的攻击技术

• 基于CSRF的攻击技术也是一种比较通用的思想：基于CSRF的攻击技术也是一种比较通用的思想
• 包括如下内容：基于CSRF的SQL注入；基于CSRF的命令执行；基于CSRF的XSS攻击；

7.5.浏览器劫持技术

• 浏览器劫持技术是指通过劫持用户点击链接操作，在打开新窗口的时候注入攻击者的JavaScript脚本，以达到将XSS威胁延续到同域内的其他页面

7.6.一些跨域操作技术

• ie res:协议跨域
• css string injection跨域：一个非常有趣的跨域技巧，@import方式导入外域CSS文件本身是一个正常的行为，然后IE通过document.body.currentStyle.fontFamily方式访问目标样式的font-family属性，它的值是font-family之后的所有内容，这是CSS高容错性导致的
• 浏览器特权区域风险
• 浏览器扩展风险：浏览器为了丰富自身的功能，允许第三方提供各类插件或扩展，但这些扩展的权限如果没控制好，就会带来严重的后果
• 跨子域：document.domain技术技巧：跨子域：document domain技巧非常好用，属于浏览器的性质；有一个合法的性质是：这个页面可以设置document.domain为当前子域或比当前子域更高级的域，一般顶级就到了根域；
• 更多经典的跨域索引：1.利用UNC“跨域”：通过Internet域（http协议）的代码，比如<iframe>标签利用file协议调用本地的XSS漏洞页面，并通过这个本地XSS执行任意的JavaScript代码，由于是file协议，权限会更大，比如，利用AJAX读取本地文件；2.mhtml:协议跨域；

7.7.XSS Proxy技术

• XSS Proxy技术用到了基于浏览器的远程控制上，这是一种非常好的思想，现在很多XSS利用框架，如XSS Shell、BeEF、Anehta等远程控制都是基于XSS Proxy的
• 要实现远程控制，必须具备以下两个条件：远控指令要在目标浏览器上“实时”执行；执行结果要能够让控制端看到
• XSS Proxy技术的4种思路，各有千秋
• 浏览器[script]请求：<script>标签请求内容可跨域，这是合法的功能，请求到的数据必须是合法的JavaScript语法格式；包括请求回来的是JSON+CallBack函数这样的数据内容（这种跨域数据通信被称为JSONP）；
• 浏览器跨域ajax请求：跨域AJAX请求也需要浏览器setInterval去主动发起服务端指令接口请求。唯一的好处是，这种请求时异步发起的，会显得更加安静；
• 服务端websocket推送指令：严格地说，WebSocket技术不属于HTML5，这个技术是对HTTP无状态连接的一种革新，本质就是一种持久性socket连接，在浏览器客户端通过JavaScript进行初始化连接后，就可以监听相关的事件和调用socket方法来对服务端的消息进行读写操作；
• postMessage方式推送指令：HTML5的postMessage机制非常完美，是客户端最直接的跨文档传输方法，一般用在iframe中父页与子页之间的客户端跨域通信；这个技巧如果用于XSS Proxy上可能有些绕，攻击者需要动态生成，然后在客户端进行跨域传输指令。这是一种思路，不过不好；

第八章 HTML5安全

• HTML5现在由WHATWG、W3C、IETF三个组织来共同开发制定

8.1.新标签和新属性绕过黑名单策略

• 白名单和黑名单过滤器策略是防御XSS攻击的重要方法
• 跨站中的黑名单策略
• 新元素突破黑名单策略：要绕过这种黑名单策略，一种方法就是跨站师使用变形后的代码绕过正则表达式的语义范围。另一种情况是下面将要提到的HTML5新标签和新属性；1.HTML5中可以利用到的新标签有音频标签<audio>和视频标签<video>；2.HTML5中可以利用到的新属性有formation、onformchange、onforminput、autofocus等；

8.2.HistoryAPI中的新方法

• pushstate()和replacestate()：HTML5的History API中新增加了两个新方法pushState()和replaceState()。可以在不刷新页面的情况下添加和修改历史条目
• 短地址+history新方法=完美隐藏url恶意代码：短地址服务是指把一个冗长的网址转换成一个简洁的网址；当用户点击短地址的时候，并不知道它指向哪里，此时攻击者就可以利用短地址这个特性，把注入恶意代码的网站转换为短地址，用户单击这个短地址后，就会遭到攻击；现在可以利用History的新方法pushState()和replaceState()，在无刷新页面的情况下改变地址栏中的URL，用户就无法看到恶意代码；
• 伪造历史记录：使用history.pushState可以对浏览器的历史记录进行伪造，而且也可以对历史记录发起Dos攻击

8.3.HTML5下的僵尸网络

• 僵尸网络（英文名为Botnet）是指，通过各种手段在大量的计算机中植入特定的恶意程序，使控制着能够通过相对集中的若干计算机直接向大量计算机发送指令的攻击网络
• web worker的使用：HTML5中的Web Worker可以让Web应用程序具备后台处理能力，比如，让Worker进行并行计算、后台I/O操作等，而且对多线程支持非常好；Web Worker不会导致浏览器UI停止响应，短暂的Worker操作不会让用户察觉，但如果是长时间大量的Worker运算操作，则会消耗CPU周期，使系统变慢，用户可能看到CPU始终保持在高位；
• cors向任意网站发送跨域请求：CORS的安全策略仅仅在于是否允许客户端获取服务器的返回数据，但并不会阻止客户端发送的请求
• 一个html5僵尸网络实例：如何控制更多的僵尸节点？蠕虫可以将被感染的用户浏览器变成僵尸节点

8.4.地理定位暴露你的位置

• 使用HTML5 Geolocation API（地理定位API），就可以请求用户共享自己的地理位置，如果用户同意，程序就可以定位到用户的地理位置
• 隐私保护机制：这套隐私机制完全由浏览器控制；用户对于记住共享设置的功能需要注意，尤其是用户选择了允许共享地理位置，这有可能使用户一直暴露自己的地理位置；
• 通过XSS盗取地理位置：获取这类真实地理信息比较容易。同时，结合原生的社工技巧，攻击成功的概率会更高

第九章 Web蠕虫

• 蠕虫的一个特性就是传播性，对于Web蠕虫来说，传播的媒介就是Web2.0网站的浏览器客户端，而传播的基石则是广大用户

9.1.Web蠕虫思想

• Web蠕虫主要包括：XSS蠕虫、CSRF蠕虫、Clickjacking蠕虫，这三类蠕虫都与具体的漏洞风险有关系，从名字上很好区分
• Web蠕虫的思想很简单，就是用户参与，而Web2.0网站正好具备这个条件
• 从XSS蠕虫到CSRF蠕虫，再从Clickjacking蠕虫到文本蠕虫，越往后，社工的成分越大

9.2.XSS蠕虫

• 原理+一个故事：蠕虫具有的最主要的两个性质如下：传播性、病毒行为；XSS蠕虫的发生需要具备以下条件（目标网站具备Web2.0的关键特性：内容由用户驱动；均存在XSS漏洞；被感染的用户是登录状态，这样XSS的权限就是登录后的权限，能执行更多恶意的操作；XSS蠕虫传播利用的关键功能本身具备内容传播性）
• 危害性：XSS蠕虫的权限大（一般情况下，Web用户有多大权限，它就有多大权限）；1.对用户数据进行任意操作（XSS蠕虫传播开后，可以批量对用户数据进行恶意操作）；2.拒绝服务攻击（XSS蠕虫可以对目标网站服务进行大面积的拒绝服务攻击，导致用户无法正常使用网站功能）；3.分布式拒绝服务攻击（分布式拒绝服务攻击的目标是其他网站，XSS蠕虫的每个被感染用户在地理位置上可能分布在全国各个位置，甚至世界各个位置）；4.散播广告；5.传播网页木马（一般情况下，网马是利用浏览器与浏览器插件漏洞（最臭名远昭的就是IE的ActiveX控件）进行本地攻击，将网马内的二进制数据或脚本病毒植入操作系统本地执行，本来在Web层面上的威胁，通过这些漏洞蔓延到了操作系统层面。在操作系统层面上，病毒的权限至少就是操作系统用户账号的权限）；6.传播舆情
• 蠕虫需要追求原生态：框架封装了太多优秀的函数，对XSS来说，直接调用就好，可以省去许多自定义代码的麻烦，而且可以大大减少XSS蠕虫的大小，这样的XSS蠕虫就是原生态的；1.代码的原生态：简单的几行代码就可以发起GET或POST请求，而且使用原生态的框架还有一个好处，它帮我们处理了各种浏览器兼容的问题；2.攻击效果的原生态：那些DIV框、UI组件都是可以直接调用一些高度封装的JavaScript函数来生成；

9.3.CSRF蠕虫

• 关于原理和危害性：CSRF蠕虫的原理和XSS蠕虫基本类似，只是这里用到的是CSRF，攻击代码存在于攻击者页面中，目标网站传播的内容都包含攻击者页面URL，这样才能诱惑目标网站上的被攻击者打开攻击者页面，然后触发CSRF，CSRF会继续跨域发布含攻击者页面URL的内容进行传播；和XSS蠕虫不一样的是：XSS蠕虫的攻击代码本质上是存放在目标网站上的，即使是<script>从攻击者域上引用进来，对JavaScript上下文来说，也属于目标网站；CSRF蠕虫的危害性大多与XSS蠕虫一样，如：获取用户隐私、对用户数据进行恶意操作、散播广告、传播网页木马、传播舆情等；
• 译言CSRF蠕虫：攻击代码可以做得非常隐蔽，顺便加上了Referer判断。而蠕虫代码就是靠得到的这个Referer值进行后续操作的。由于Ajax无法跨域获取操作第三方服务器上的资源，于是使用了服务端代理来完全跨域获取数据的操作（Microsoft.XMLHTTP控件的使用）；有一点要强调下，蠕虫传播的前提是目标用户登录了目标网站，然后才能看到消息并中招，之后的传播必定会带上目标用户的内存Cookie，所以这个过程不受限于IE下的本地CookieP3P策略的声明；
• 饭否CSRF蠕虫-邪恶的Flash游戏：饭否CSRF蠕虫是利用Flash进行传播的，本质上是该Flash文件里的ActionScript脚本向饭否发起CSRF请求；CSRF请求有两种：一种是Get请求获取攻击者相关的隐私数据。第二种是POST请求提交数据，使得被攻击者自动发送一条微博消息并向自己的好友都发一条私信；这些Web蠕虫都是基于用户群的，需要大量的用户参与，借用户交互之势而传播，而用户之间却存在一种信任关系，一般情况下，如果是自己的好友给自己发消息，都会去看，因为彼此很信任，饭否的这个蠕虫传播正是利用了这个特性；
• CSRF蠕虫存在的可能性分析：顾名思义，CSRF蠕虫就是利用CSRF技术进行传播的Web蠕虫，前者的译言CSRF蠕虫以及相关分析文章说明了CSRF蠕虫存在的事实，译言网站的这个CSRF是由用户驱动的，蠕虫的代码都存放于另外一个网站上；要解决的最关键的问题就是CSRF蠕虫的传播性，即基于用户驱动的传播性（主动或者被动）；跨域获取数据的几种方式：CSRF蠕虫传播必须面对的问题是如何获取各种必要的唯一值。这里有三种方式：服务端代理技术、FlashAS跨域请求技术、JSONHijacking技术；通过对CSRF蠕虫传播原理的分析，许多广泛存在CSRF漏洞的Web2.0网站都面临着CSRF蠕虫的威胁。Web2.0蠕虫由用户驱动（被动的或主动的），加上一些社工技巧，这将很难防御；

9.4.ClickJacking蠕虫

• ClickJacking蠕虫的由来：2009年初Twitter上发生的“Don't Click”蠕虫事件；
• ClickJacking蠕虫技术原理分析：技术分析：首先，攻击者使用ClickJacking技术制作蠕虫页面，该页面的URL地址使用TINYURL短地址转http://tinyurl.com/amgzs6；设计要点：对iframe和button标签进行CSS样式设定，放置iframe标签所在层为透明层，使iframe标签所在层位于button标签所在层的正上方；要发动ClickJacking蠕虫攻击，满足以下两点必要条件即可（在SNS社区网络中，找到一个可以直接使用HTTP的GET方式提交数据的页面；这个页面可以被<iframe>标签包含；）
• Facebook的LikeJacking蠕虫：Facebook遭遇的LikeJacking蠕虫攻击；Facebook中有一项插件服务，叫“Like Button”。用户可以在自己的博客或自己的网站中加入“Like Button”，访客浏览时，可以单击这个按钮表示自己喜欢这篇文章。当单击结束后，访客点击的状态信息会在访客的Facebook页面上以状态更新的方式显示出来；攻击者可以使用ClickJacking技术欺骗访客单击这个“Like Button”；
• GoogleReader的ShareJacking蠕虫：非常流行的“一键分享”功能插件；这种插件可以让用户把在网络中看到的好文章或好资源直接以广播消息的形式发布到自己的社区和好友们进行分享；除了发现Google Reader存在ShareJacking蠕虫攻击外，还发现国内SNS环境中腾讯微博、腾讯空间、腾讯朋友、搜狐微博、人人网、淘江湖均存在这种攻击；
• ClickJacking蠕虫爆发的可能性：分享已经是当前SNS网络中一个很重要的社交内容。只要是带有共享性质的网络社区，都有可能会遭受到ClickJacking蠕虫的攻击；Twitter的一键分享页面http://twitter.com/intent/tweet已经在HTTP头关键字中加入X-FRAME-OPTIONS来抵御ClickJacking攻击，Facebook的一键分享页面http://www.facebook.com/sharer/sharer.php中也使用了Frame Busting脚本来进行抵御；

第十章 关于防御

10.1.浏览器厂商的防御

• HTTP响应的X-头部：HTTP响应的扩展头部字段都以X-打头，用于区分标准的头部字段；与前端安全有关的头部字段有如下几个：X-Frame-Options、X-XSS-Protection、X-Content-Security-Policy；1.X-Frame-Options的值有以下两个：DENY（禁止被加载进任何frame）、SAMEORIGIN（仅允许被加载进同域内的frame）；2.X-XSS-Protection的值有以下三个：0（表示禁用）、1（默认，对危险脚本做一些标志或修改，以阻止在浏览器上渲染执行，Chrome和IE这方面的行为是有差异的）、1:mode=block（强制不渲染，在Chrome下直接跳转到空白页，在IE下返回一个#符号）；
• 迟到的CSP策略：前面提到Web前端混乱局面，比如IE下的CSS的expression可以写JavaScript，再如，HTML的标签<script>、标签on事件、标签style属性、标签src/href/action等属性都可以内嵌JavaScript执行；HTML仅做HTML的事，JavaScript/CSS都通过加载独立文件的方式被执行。JavaScript/CSS独立文件所在的域可以配置为白名单，这样就能有效地防止加载攻击者域上的相关资源文件。这大大提高了XSS攻击的难度，这就是CSP策略的最大设计初衷；CSP策略使得Web前端更有序，从而更安全，这是一个好趋势，W3C已经在大力推进这样的策略；目前，Chrome支持CSP策略的头部是X-WebKit-CSP，而不是标准的X-Content-Security-Policy；下面举几个应用CSP的场景（1、不允许任何外部的资源加载，且允许内嵌脚本执行；2、仅允许白名单的外部资源加载，不允许内嵌脚本执行；）

10.2.Web厂商的防御

• 域分离：域分离做得好的可以参考Google，Google将一些业务关联性小的内容转移到了不相干的域中
• 安全传输：Google很多重要的业务都完美地支持HTTPS安全传输（包括搜索）。安全传输可以有效地防止局域内的明文抓包
• 安全的Cookie：可以学学Google，某些身份认证相关的Cookie肯定严格设置为HTTPS传输，肯定是HttpOnly标志，这样XSS即使盗取了Cookie，也无法正确使用
• 优秀的验证码：验证码的出现肯定降低了用户体验，但是这个降低阈值是可以控制好的；Google的验证码公认是比较安全的（字母连着、扭曲变形、线条平滑、无噪等），暴力破解很困难，这也带来了用户体验上的尴尬，经常会输错验证码，说明Google非常重视安全，宁可牺牲一点用户体验；
• 慎防第三方内容：第三方内容的安全性是经常被大家提起的，常见的有以下几种形式：<script>引用第三方js文件；<iframe>引用第三方HTML文件；<object>等引用第三方Flash等资源
• XSS防御方案：一些防御策略（输入校验：长度限制、值类型是否正确、是否包含特殊字符等；输出编码：根据输出的位置进行相应的编码，如HTML编码、JavaScript编码、URL编码；）
• CSRF防御方案：针对CSRF攻击的防御，目前常用的有以下几种策略（1.检查HTTP Referer字段是否同域；2.限制Session Cookie的生命周期；3.使用验证码；4.使用一次性token；）；一般防御CSRF有三种方法：判断Referer、验证码、token；验证码的弊端很明显：会对用户造成影响；token存在的问题是：时效性无法保证；token防CSRF的原理是：无法通过AJAX等方式获得外域页面中的token值，XMLHttpRequest需要遵守浏览器同源策略；而临时Cookie的原理是：Cookie只能在父域和子域之间设置，也遵守同源策略；
• 界面操作劫持防御：基于界面操作劫持的攻击模式是用巧妙的视觉欺骗的方式，对Web会话进行劫持；基于界面操作劫持的攻击模式是用巧妙的视觉欺骗的方式，对Web会话进行劫持；目前针对界面操作劫持的防御有以下几种（1.X-Frame-Options防御：由微软提出来的防御界面操作劫持的一种方法，Web开发人员可以在HTTP响应头中加入一个X-Frame-Options头，浏览器会根据X-Frame-Options字段中的参数来判断页面是否可以被iframe嵌入；2.Frame Busting脚本防御：使用JavaScript脚本来对页面进行控制，达到页面无法被iframe嵌入的目的，这样的防护脚本被称为Frame Busting脚本；3.使用token进行防御：在业界主流的防御界面操作劫持攻击的方法中，似乎并没有提及防御CSRF中的token也可以对其进行防御；）；X-Frame和Frame Busting方法都可以做到对界面操作劫持的防御。相对而言，X-Frame-Options的方式还是比Frame Busting更安全。X-Frame-Options是在浏览器中嵌入的，而Frame Busting是脚本控制。这意味着JavaScript代码始终有被突破的可能性；

10.3.用户的防御

• 使用安全浏览器组合：Firefox浏览器+NoScript插件：NoScript插件是由Web前端安全牛人Giorgio Maone主力研发，众多该领域牛人的贡献可谓是安全插件的精品，能防御DOM与反射型XSS、ClickJacking，能强制进行HTTPS请求等，还能默认拦截所有网站的JavaScript、Flash、Java等
• 遵守信任最小原则

10.4.邪恶的SNS社区

• SNS里的攻击围绕着信任关系进行的，其特点是：人们往往信任自己熟悉的人，信任程度的高低一般取决于熟悉的程度与目标本身的信誉

写在后面

• pdf书籍、笔记思维导图、随书代码打包下载地址：https://pan.baidu.com/s/1CItemx1hsDgxnE25kbX0fg（提取码：uloo）
• 纸质书京东购买地址：https://u.jd.com/R5ve7p（推荐使用纸质书来学习）
• 为了方便在手机上查看，后面我会把这些笔记陆续发布到公众号“派三派四”，可以扫码关注一下，欢迎关注。
  

标签：Web,精读,浏览器,CSRF,XSS,JavaScript,黑客技术,蠕虫
来源： https://www.cnblogs.com/yzsunlei/p/12782503.html