web安全

对《白帽子讲web安全的总结》，希望各位看官老爷能够仔细看完

        求瓶可乐（伸手要.jpg）

什么是安全，安全的本质就是信任（一切安全都建立在信任的基础上，我们必须要信任一些东西，必须有一些基本的假设，安全方案才能成立）

比如说我要把一份机密文件锁起来，首先我们必须要信任锁匠，其次信任造抽屉的木匠没有建后门，在这种信任的基础上文件是安全的，如果不信任他们那这就是不安全的

安全三要素：

机密性：要求保护的数据的内容不能被泄露

完整性：要求保护数据的内容是完整的，没有被篡改的

可用性：要求保护的资源是"随时可用的"

安全评估：

资产等级划分——》 威胁分析——》风险分析——》确认解决方案

在这几个阶段中，上一个阶段决定一下个阶段的目标，需要实现到什么程度

互联网公司除了一些服务器之外的死物最重要的就是用户的数据，所以互联网安全的核心问题，是数据安全的问题

威胁分析：

把可能造成危害的来源称为威胁，把可能会出现的损失叫风险。风险一定是和损失联系在一起的。不能弄混

那怎么做威胁分析呢，一般是做头脑风暴，也可以使用微软的STRIDE模型：

威胁	定义	对应的安全属性
Spoofing(伪装)	冒充他人身份	认证
Tampering(篡改)	修改数据或代码	完整性
Repudiation（抵赖）	否认做过的事情	不可抵赖性
InformationDisclosure（信息泄露）	机密信息泄露	机密性
Denial of service（拒绝服务）	拒绝服务	可用性
Elevation of Privilege（提升权限）	未经授权获得许可	授权

一个优秀的安全方案能够有效解决问题：

用户体验好

高性能

低耦合

易于扩展与升级

最小权限原则：这个不用多说

纵深防御原则：

在各个不同层面，不同方面实施安全方案，避免出现疏漏，不同安全方案之间相互配合，构成一个整体，要在正确的地方做正确的事，在解决根本问题的地方实施针对性的安全方案

并不是一个安全方案做多遍，而是要从不同的层面，不同的角度对系统做出整体的解决方案，比如UTM，全称为"统一威胁管理"，集成了所有主流的安全产品功能，他主要是解决中小型企业没有精力自己做安全方案，可以在一定程度上提高安全门槛，很多问题不应该在网关，网络层进行解决

所以在一个比较复杂的网络架构里纵深防御是必须的

数据与代码分离原则：

sql，xss还有缓冲区溢出，也可以认为违背了这一原则的后果-----程序在堆中将用户的数据当成代码执行，混淆了代码与数据的边界，从而导致了安全问题的产生

不可预测性原则：

可以巧妙地运用在一些敏感数据上，比如说csrf，通常会使用一个tocken来进行有效的防御。只所以能够成功防御csrf是因为攻击者在进行攻击时是无法预测tocken的

浏览器安全：

同源策略：

浏览器的同源策略，限制了来自不同源“document”或脚本，对当前“document”读取或设置某些属性

影响“源”的因素有：host（域名或IP地址，如果是IP地址则看做一个根域名），子域名，端口，协议

跨域：

跨域：

        指的是在浏览器环境中，一个网站的脚本试图访问另一个网站资源时，涉及到不同源的情况。由于同源策略的影响，跨域请求通常是被禁止的。

所以这两个是相关但不同的概念：

        同源不等于跨域。同源是指两个网站在协议，域名，端口号上完全相同，而跨域是指在浏览器环境下，脚本试图访问不同源的资源。跨域请求需要特殊处理

所以这两个是相关但不同的概念：

同源不等于跨域。同源是指两个网站在协议，域名，端口号上完全相同，而跨域是指在浏览器环境下，脚本试图访问不同源的资源。跨域请求需要特殊处理

xss:

通常是指黑客通过“HTML注入”篡改了页面，插入了恶意的脚本，从而在用户浏览页面时，控制用户浏览器的一种攻击

csrf 跨站请求伪造：

如果在测试CSRF的时候发现等标签在IE中居然能够发送Cookie，而又找不到原因，那么很可能就是因为P3P头

防御：

验证码

Referer Check，用以检查请求是否来自合法的源，但是服务器并不是什么时候都能取到Referer

CSRF的本质：

        就是所有的重要操作的参数都是可以被攻击者猜测到的，就违背了“不可预测性原则”如果攻击者猜想不到url参数中的数据，那么这就无法构成CSRF，但是这样做把所有参数都进行不可逆加密后会造成数据分析等操作的不便，所以我们要使用更加通用的方法来解决这个问题，tocken tocken需要足够的随机，tocken放在用户的Session中，或者浏览器的Cookie中。Tocken需要同时放在表单和Session中。在提交请求时，服务器只需要验证表单中的tocken与用户的Session（或者cookie中的Tocken是否一致）如果一致那么认为请求合法，否则认为请求不合法

但是如果该网站还存在xss漏洞时，在xss攻击下攻击者可以请求页面后，读取页面内容里的tocken，让后在构造出一个合法请求，这个过程可称之为XSRF

点击劫持：

点击劫持就是视觉上的一个欺骗手段，攻击者可以使用一个透明的，不可见的ifname，覆盖在一个网页上，然后诱使用户恰好点击在ifname页面的一些功能按钮

像什么：图片覆盖 或者 将原来的内容覆盖掉（手机，邮箱等等）。。。。

拖曳劫持与数据窃取：

拖曳是不受同源策略的限制，可以是一个链接，可以是文字，也可以从一个窗口拖曳到另外一个窗口

“拖曳劫持”的思路是诱使用户从隐藏不可见的中拖曳出攻击者希望得到的数据，然后放到攻击者能控制的另一个页面中去，从而窃取数据

触屏劫持：

智能手机的每次触屏操作简单来说就是：

touchstart：手指触摸屏幕时发生的

touchend：手指离开屏幕时发生的

touchmove：手指滑动时发生的

touchcancel：系统可取消touch事件

通过将一个不可见的覆盖到当前网页上，可以劫持用户的触屏操作

防御：

fram busting：通常写一段js代码，以禁止iframe的嵌套。但这种方式由于是js代码写的控制能力并不是很强，因此有很多方法可以绕过它（网上有很多绕过的帖子）

X-Frame-Options:使用HTTP头-------X-Farme-Options，他会有三个值：DENY，SAMEORIGIN，ALLOW-FROM orgin

当值为DENY时，浏览器会拒绝当前页面加载任何frame页面，若值为SAMEORIGIN，则frame页面的地址只能为同源域名下的页面，若值为ALLOW-FROM orgin，则可以定义允许frame加载页面的地址

浏览器实现的同源策略限制了脚本的跨域请求。但互联网的发展趋势越来越开发，因此跨域请求访问的需求也变的越来越迫切。

        跨源资源共享（Cross-Origin Resource Sharing，CORS）是一种Web浏览器的机制，用于控制在跨域请求时如何进行跨域资源共享。

        同源策略（Same-Origin Policy）是浏览器的一项安全措施，限制了从一个源加载的网页如何与来自不同源的资源进行交互。

         跨源资源共享通过在服务器端设置额外的HTTP头部来解除这种限制，从而允许在跨源场景下 进行跨域访问。 ​

        具体来说，CORS使用以下HTTP头部字段来进行配置和控制： ​

        Access-Control-Allow-Origin：指定允许访问该资源的源，可以是具体的源或通配符"*"。

        Access-Control-Allow-Methods：指定允许的HTTP请求方法。

        Access-Control-Allow-Headers：指定允许的自定义请求头部。

        Access-Control-Expose-Headers：指定响应中可以被前端访问的自定义响应头部。         Access-Control-Allow-Credentials：指示是否允许发送凭证（如cookies、HTTP认证等）。

        Access-Control-Max-Age：指定预检请求的有效期（在实际请求前发送的OPTIONS请求）。

        通过这些HTTP头部字段，服务器可以告知浏览器在跨域请求时如何处理，并授权特定的源进行跨域访问。浏览器在发起跨域请求时， 会首先发送一个预检请求（OPTIONS请求）到目标服务器，以获取服务器端是否允许该源进行实际请求。 ​

        CORS是一项重要的安全机制，它帮助保护用户数据和防止跨站点脚本攻击（XSS）。通过合理配置CORS，服务器可以提供可控的跨域资源共享， 同时确保安全性和隐私保护。

Web Storage：

        web Storage分为 Session Storage和Local Storage ， Session Storage关闭浏览器就会失效，而Local Stroge则会一直存在。Web Stroge就像一个非关系型数据库，有key-value对组成，可以通过javascript对其进行操作。web Stroage也受到同源策略的约束，每个域所拥有的信息只会保存在自己的域下面

服务器端安全：

注入攻击：

        注入攻击的本质就是把用户输入的数据当做代码来执行。这里有两个关键条件，第一是用户能够控制输入，第二个是原本程序要执行的代码，拼接了用户输入的数据

SQL注入：

盲注：在很多时候，Web服务器关闭了错误回显。

所谓盲注，就是在服务器没有错误回显时完成的注入攻击。服务器没有错误回显，对于攻击者来说缺少了非常重要的“调试信息”，所以攻击者必须找到一个方法来验证注入的sql语句是否执行

        比如：select benchmark（100000000，encode（‘hello’，‘goodbye’））执行了100000000次，因此，利用benchmark()函数，可以让同一个函数执行若干次，使得返回的时间比平时的要长；通过时间长短的变化，可以判断出注入语句是否成功

命令执行：

        可以利用“用户自定义函数”的技巧，即UDF（User-Defined Functions）来执行命令，但在mysql 5及其之后的版本受到了限制，因为其创建的自定义函数并不符合新版规范，且返回值永远为0

后来找到了另一种方法：lib_mydsqludf_sys提供的几个函数执行命令

在攻击过程中，将lib_mvdsqludf上传到数据库能访问到的路径下。在创建UDF之后，就可以使用sys_eval()等函数执行系统命令了

sys_eval():执行任意命令，并将输出返回

sys_exec：执行任意命令，并将退出码返回

sys_get：获取一个环境变量

sys_set：创建或修改一个环境变量

其他数据库也是大同小异

攻击存储过程：

        存储过程为数据库提供了强大的功能，它与UDF很像，但存储过程必须使用CALL或者EXECUTE来执行。在ms sql server和Oeacle数据库中，都有大量内置的存储过程。在注入的过程中，存储可以提供很大的便利

        在My sqlServer中，xp_cmdshell使用最为广泛，但在SQL Server 2005及以后版本中则默认被禁止了。但是如果当前数据库用户拥有sysadmin权限，则可以使用sp_configure重新开启他，等等这类存储的函数是很多的

SQL Column Truncation:

        sql列截断指的是当尝试向数据库表插入或更新数据时，如果数据长度超过列定义的最大长度，会发生截断的情况。列截断可能导致数据丢失或损坏，因为超出定义长度的部分会被截断掉而不会引发错误

        比如说如果我在admin后加好多个空格，然后并没有报错显示成功添加那么这就是会有两个同名数据，这样就会有越权的风险了

防御sql：

1.简单点就是限制用户的输入，对输出进行检查

2.使用预编译，绑定变量

3.在数据库中使用存储过程中，应该尽量避免使用动态的SQL语句，如果无法避免，则应该4.使用严格的输入过滤或者编码函数来处理用户的输入数据

5.检查输入的类型，比如在代码层面我就只允许传入数字，不能传入字符，直接把代码写死，这样也可以避免注入攻击

XML注入：

        xml是一种常用的标记语言，通过标签对数据进行结构化表示。XML与HTML都是标准通用标记语言

        xml注入，也需要满足注入攻击的两大条件；用户能控制数据的输入；程序拼凑了数据。

在防御方案上也是一样的：对用户输入数据中包含“语言本身的保留字符”进行转义

代码注入:

代码注入与命令注入往往都是由一些不安全的函数或者方法引起的，其中典型的就是eval()，systen()等等

防御：

对抗代码注入，命令注入时，需要禁用这些危险函数，如果一定要使用这些函数，则需要对用户的输入和输出数据进行过滤。

在PHP和JSP中应该避免使用include远程文件，代码注入往往是由于不安全的开发习惯造成的，危险函数应该尽量避免在开发环境中使用

CRLF注入：

CRLF其实是连个字符，\r\n，其16进制为0x0d 0x0a

        在HTTP协议中，HTTP头通过“\r\n”进行分割，如果服务器没有进行过滤，而又把用户输入的数据放在HTTP头中，则有可能导致安全隐患。不止http头可以进行注入，只要是使用“\r\n”进行分割的地方都有可能出现CRLF注入攻击

文件上传：

首先文件上传的利用要瞒住以下几个条件：

上传文件能够被wb容器解释执行。所以文件上传后的所在的目录要是web容器所覆盖到的路径。

用户能够从web上访问这个文件，如果文件上传了，但用户无法通过web访问，或者无法使得web容器解释这个脚本，那么这也不能称之为漏洞了

如果用户上传的文件若是被安全检查，格式化，图片压缩等改变了原来的内容，则也可能导致攻击不成功

有些网站在上传功能会进行限制，比如说进行黑名单，黑名单是不可信的

白名单绕过：

xxx.php[\0].jpg，其中[\0]为16进制0x00字符，在c,php等语言中0x00被认为是终止符，.jpg绕过了应用的上传文件类型判断，但对于服务器来说，此文件因为0x00字符截断的关系，最终却会变成xxx.php 这就是00截断

还有就是伪造一个合法文件头，而将真实的php等脚本代码附在合法的文件头之后。但此时任需要php来解释此图片才行，如果后缀是JPEG那么这还是无法执行的，会被当成静态资源进行解析

Apache文件解析漏洞：

在Apache1.x 2.x中，对文件名的解析就存在以下特性：

Apache对于文件名解析是从后往前解析的，直到遇见一个Apache认识的文件类型为止

shell.php.rar.rar.rar.rar

        因为Apache不认识rar这个文件类型，所以为一直向前进行遍历，直到php这个所认识的文件类型，而这个文件认识类型的定义在minme.type文件中

IIS文件解析漏洞：

IIS6在进行文件解析时和00截断差不多，不过截断的符号不是00而变成'；'比如xxx.asp;xxx.jpg这样只会执行xxx.asp而不会执行后面的

IIS6中还出现过一个/*,asp/目录下所有文件都会被当成ASP文件解析；https://www.xxx.com/path/xxx.asp/asp.jpg 这个xxx.jpg会被当成asp解析而不是jpg；这两个漏洞都需要在服务器的硬盘上确实存在这样的文件或者文件夹，若只是通过URL是无法触发漏洞的

在iis中还有经典的PUT文件上传：

        PUT就是允许用户上传文件到指定路径下，而IIS中如果目录支持写权限，同时开启了webDav（webDav就是一种基于HTTP协议的扩展，他允许用户通过网络编辑和管理远程服务器上的文件）则会支持PUT方法，在结合MOVE方法，就能将原本只允许上传的文本文件修改为脚本进行执行，MOVE能否执行成功，取决于IIS服务器是否勾选了“脚本资源访问复选框”

PHP CGI路径解析问题：

        在nginx配置fastcgi（是一中用于连接web服务器和应用程序的协议。它在提高web应用程序的性能和扩展性，通过保持应用程序进程的持久性来避免为每个请求创建新的进程，传统的CGI通过每个请求创建一个新的进程来处理web应用程序，在高负载下，这种方法可能导致性能问题）使用php时，会造成文件类型解析问题。

详细来说就是：

        将Nginx作为WEB Server时，一般使用fastcgi的方式调用脚本解析器，这种方式最为常见，但是这就会造成安全隐患：

http://www.xxx.com/path/test.jpeg/bbb.php

时test.jpeg当成php解析，bbb.php是不存在文件，如果在任何配置为fastcgi的php应用里上传一张图片（头像，也可能是论坛里上传的图片），其图片内容是php文件，则导致代码执行

解决方案：

        在php的配置文件中有一个关键的选项：cgi.fix_pathinfo,这个选项默认是开启的：          cgi.fix_pathinfo=1，当这个选项为1时，在映射URI时，将递归查询路径确认文件的合法性。bbb.php是不存在的，所以将往前递归查询路径。而path_INFO此时还是bbb.php。在最终执行时，test.jpg会被当做PHP解析，PHP官方给出的建议是将cgi.fix_pathinfo=0

文件上传防御：

1.文件上传的目录设置为不可执行

        只要Web容器无法解析该目录下的文件，即使攻击者上传了脚本文件，服务器本身也不会受到影响，很多大型网站都会把文件上传的文件放在独立的存储上，做静态文件处理，一方面使用缓存加速，降低性能损耗；另一方面也杜绝了脚本执行的可能。但对于一些边边角角的上传功能则需要注意

2.判断文件类型

        在判断文件类型时，可以结合MIME Type（是一种标准化的标识，用于表示互联网上不同类型的数据格式。它通过在HTTP协议中使用“Content-Type”头来指定），后缀名检查等方式。

3.使用随机数改写文件名和文件路径

        文件上传如果要执行代码，则需要用户能够访问带这个文件。在某些环境下，用户能够上传，但不能访问，像sell.php.rar,rar,rar这种文件，或者crossdomain.xml这种文件，都将因为文件名被改写而无法成功实施攻击。

4、单独设置文件服务器的域名

        于浏览器同源策略的关系，一系列客户端攻击都将失效，像什么上传包含javaScript的Xss利用 等问题

认证与会话管理：

很多时候会把认证和授权搞混，这其实是两种完全不同的概念

认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么

        认证实际上就是一个验证凭据的过程。只有一个凭证，则称为“单因素验证”；如果有两个或多个凭证被用于认证，则称为“双因素认证”或“多因素验证”，一般多因素认证要强于单因数认证。但是在用户体验上，多因素认证会带来不方便

Session认证：

        密码与证书认证手段，一般仅用于登录的过程。当登录完成后，用户发访问网站的页面，不可能每次浏览器请求页面时都认证一次。因此，当认证成功后，就需要替换一个对用户透明的凭证，这个凭证就是SeeionID

        当用户登录完成后，在服务器端就会创建一个新的回话（Session），会话中会保存用户的状态和相关信息。服务器端维护所有在线用户的Session，此时的认证，只需要知道是哪个用户在浏览当前页面即可。为了告诉服务器应该使用哪个Session，浏览器需要把当前用户持有的SessionID告知服务器

Session Fixation攻击：

        什么是Session Fixation攻击呢，简单来说就是在 用户登录网站的过程中，如果登录前后用户的SessionID没有发生变化，则会存在Session Fixation攻击。

        具体的攻击过程的就是，用户A（攻击者）先获取到一个未经认证的SessioniD，然后将这个SessioniD交给用户Y去认证，Y认证后，服务器未更新此SessionID的值（注意是未更改SessionID,而不是未改变Session），所以X可以可以凭借次SessionID登录进Y的账户。

        如果这个SessionID是保存在Cookie中，比较难做到这一点，但若SessionID保存在URL中，则X只需要诱使Y打开这个URL即可

防御：

在登录完成后，重写SessionID

将SessionID写在Cooki中

Session持久化：

        一般来说，Session是有生命周期的，当用户长时间未活动后，或者用户单点退出后，服务器将销毁Session，前面提到了Session Fixation攻击，如果Session一直保持不销毁，那就等于说拥有了一个持久性的后门

        但是cookie有失效时间，Session也会过期。但是通过不停的发起访问请求，让Session一直“活下去”，而Cookie是可以完全由客户端控制的，通过发送带有自定义Cookie头的HTTP包，也能实现同样的效果（工具也是有的）

防御：

        在一定时间后强制销毁Session。这个时间可以是从用户登录时间算起，设置一个阀值，比如3天后就强制Session过期，但强制销毁可能会影响到一些正常的用户。还可以选择的是当用户客户端发生变化时，要求用户重新登录。比如用户的IP。Useragent等信息发生变化时，就可以强制销毁用户当前的Session，并要求用户重新登录

        还需要考虑的是同一个用户可以同时拥有几个有效的Session。若每个用户只允许拥有一个Session，则攻击者想要一直保存一个Session也不太可能。当用户再次登录时，攻击者所保持的Session将被“踢出”

单点登录（SSO）：

        它指希望用户只需要登录一次，就可以访问所有的系统。从用户体验角度看，SSO无疑让用户的使用更加方便；从安全的角度来讲，SSO把风险集中在单点上，这样做是有利有弊的：

             SSO的优点在于风险集中化，就只需要保护好这一个点。缺点也很明显因为风险集中了，如果单点一旦被攻破了的话，后果是非常严重的，降低这种风险的方法就是在一些敏感的系统或其他的，在单独实现一些额外的认证机制，如网上支付，付款需要在输入一遍密码，或者手机验证码等等

访问控制：

        权限控制，或者说访问控制，广泛应用于各个系统中。抽象的说，都是某个主体（subject）对某个客体（ object）需要实施某种操作（operation），而系统对这种操作的限制就是权限控制

垂直权限管理：

        访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法就是 “基于角色的访问控制（Role-Based Access Control）”简称 RBAC

        RBAC事务会在系统中定义出不同的角色，不同的角色拥有不同的权限，一个角色实际上就是一个权限的集合。而系统的所有用户都会分配到不同的角色中，一个用户可能拥有多个角色，角色之间有高低之分（权限高低）。在系统验证权限时，只需要验证用户所属的角色，然后就可以根据角色所拥有的的权限进行授权了

        这种基于RBAC模型的权限管理，我们称之为“垂直权限管理”，而本就低权限的用户通过一些方法能够获得高权限角色的能力，这就叫垂直越权

水平权限管理：

        比如说我们通过修改URL中的ID，就能够改变访问的资源。而网站却没有检查这些资源是否属于当前用户，但是在RBAC这种“基于角色访问控制”模型下，系统只会验证用户A是否属于角色，而不会判断用户A是否能够访问只属于B的的数据。这种问题就叫“水平权限越权”

        防御：可以考虑使用用户组（Group）的概念。比如一个用户组的数据只属于该组内的成员，只有同一个用户组的成员才能实现对这些数据的操作。还可以考虑实现一个规则引擎，将访问控制的规则写在配置文件中，通过规则引擎对数据的访问进行控制

OAUTH：

        OAUTH是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。

        OAuth与OpenID都致力于让互联网变得更加开放。OpenID解决的问题是认证问题，OAuth则更注重授权

事实上对于中小型企业，自己实现一个OAuth协议并没有太多的必要，可以使用一些第三方的OAUTH库

WEB框架安全：

        在框架层面解决问题，要远远好于发现问题后，由程序员在去进行修改来的方便与快捷的多，在真实的开发环境压力下，是没有时间来一个一个修补漏洞的

MVC框架：

        在现代的Web开发中，使用MVC架构是一种流行的做法。MVC是Model-View-Controller的缩写，它将WEB应用分为三层：

                View层：负责用户视图，页面展示等工作

                Controller：负责应用的逻辑实现，接收View层传入的用户请求，并转发给对应的Model层做处理

                Model：负责实现模型，完成数据的处理

模板引擎与XSS防御：

        在View层，可以解决XSS的问题。XSS攻击是在用户的浏览器上执行的，其形成的过程则是在服务器端页面渲染时，注入了恶意的HTML代码导致的。从MVC架构来说，是发生在View层的，因此使用“输出编码”的防御方法更加合理

        针对不同的情况，使用不同的编码函数。那么现在流行的MVC框架中，View层使用的模板引擎对页面进行渲染，在跨站脚本攻击中所提到的Django，就使用Django，就使用了Django Templates作为模板引擎。模板引擎本身，可能会提供一些编码方法。在Django Templantes中，使用filters中的escape作为HtmlEncode的方法。

        但是还有其他的模板引擎Velocity，它也提供了类似的机制，但是有所不同的是，Velocity默认是没有开启HtmlEncode。但是Velocity提供的处理机制，与Django的auto-escape所提供的机制类似，都只进行了HTMLEncode，为未细分编码使用的具体场景。不过幸运的是，在模板引擎中，可以实现自定义的编码函数，应用于不同场景

WEB框架与CSRF防御：

        CSRF攻击的目标，一般都会产生“写数据”操作的URL，比如 “增”“删”“改”；而读数据操作并不是CSRF攻击的目标，因为在CSRF的攻击过程中攻击者无法获取到服务端返回的数据，攻击者只是借用户之手触发服务器

在web框架中，可以对HTTP头进行全局化管理，因此一些基于HTTP头的安全方案可以很好的实施，比如HTTP返回头的CRLF注入，因为HTTP头实际上可以看成是key-value对，因此对抗CRLF的方案，只需要在“value”中编码所有的\r\n即可，这里没有提到在key中编码\r\n这是因为能让用户控制key这本身就是及其危险的事情，在任何情况下都不应该发生

还有302的跳转，浏览器将会跳转到Location指定的URL中，往往利用此漏洞进行钓鱼或者诈骗。所以对于框架来说，管理好跳转目的地址是很有必要的。一般来说可以在两个地方做：

1、如果web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中

2、另一种解决办法是控制HTTP的Location字段，限制Location的值只能是那些地址,本质也还是白名单

在web框架中，可以对HTTP头进行全局化管理，因此一些基于HTTP头的安全方案可以很好的实施，比如HTTP返回头的CRLF注入，因为HTTP头实际上可以看成是key-value对，因此对抗CRLF的方案，只需要在“value”中编码所有的\r\n即可，这里没有提到在key中编码\r\n这是因为能让用户控制key这本身就是及其危险的事情，在任何情况下都不应该发生

还有302的跳转，浏览器将会跳转到Location指定的URL中，往往利用此漏洞进行钓鱼或者诈骗。所以对于框架来说，管理好跳转目的地址是很有必要的。一般来说可以在两个地方做：

1、如果web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中

2、另一种解决办法是控制HTTP的Location字段，限制Location的值只能是那些地址,本质也还是白名单

动作，所以读数据对于CSRF来说并无直接的意义（但是如果同时存在XSS漏洞或其他跨域漏洞，则可能会引起别的问题）

        因此，在WEB应用中，有必要对“读操作”和“写操作”予以区分，比如要求所有的写操作都需要使用HTTP POST

        在很多讲述CSRF的文档中，都要求使用HTTP POST进行防御，但实际上POST本身并不足以对抗CSRF，因为POST也可以自动提交。但是POST的使用，对于保护tocken有着积极的意义，而security tocken（不可预测性原则），是防御CSRF攻击的基础

完整的CSRF防御方案，对于WEB框架来说有以下几处环境需要改变：

        1.在Session中绑定tocken，如果不能保存到服务器端Session中，则可以替代为保存在Cookie里

        2.在form表单中自动填入token字段，比如

        3.在Ajax请求中自动添加tocken，这可能需要已有的Ajax封装实现的支持

        4.在服务端对比POST提交参数的tocken与Session中绑定的tocken是否一致，以验证CSRF攻击

                在Rails中，要做到这一点很简单，只需要在Application Controller（应用程序控制器，用于管理应用程序的逻辑和行为。它负责接收用户输入。处理业务逻辑，协调不同的组件和服务，并决定响应何种事件和操作）中增加一行即可：

        它根据Secret和服务器端的随机因子自动生成tocken，并自动添加到所有from和有rails生成的Ajax请求中

        在Django中也有类似的功能，但配置相对来说要复杂一点（自行百度）

HTTP Headers 管理：

        在web框架中，可以对HTTP头进行全局化管理，因此一些基于HTTP头的安全方案可以很好的实施，比如HTTP返回头的CRLF注入，因为HTTP头实际上可以看成是key-value对，因此对抗CRLF的方案，只需要在“value”中编码所有的\r\n即可，这里没有提到在key中编码\r\n这是因为能让用户控制key这本身就是及其危险的事情，在任何情况下都不应该发生

        还有302的跳转，浏览器将会跳转到Location指定的URL中，往往利用此漏洞进行钓鱼或者诈骗。所以对于框架来说，管理好跳转目的地址是很有必要的。一般来说可以在两个地方做：

                1、如果web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中

                2、另一种解决办法是控制HTTP的Location字段，限制Location的值只能是那些地址,本质也还是白名单