原理CSRF，CrossSiteRequestForgery，即跨站点请求伪造。这种攻击是指，在用户正常登录系统以后，攻击者诱使用户访问一些非法链接，以执行一些非法操作。比如：如果删除用户操作（如，yourdomain/deluser?id=123）没有经过防范CSRF的处理，那么，假设用户登录系统后，攻击者诱使用户同时访问了攻击者的站点的一个链接（该链接正好为yourdomain/deluser?id=123），那么，系统就会在用户不知情的情况下丢失一个用户。在这个例子中，跨站请求中的链接之所以被正常执行，首先是因为请求中浏览器正常发送了yourdomain的认证信息（一般保存在cookie中），服务器根本不知道该请求是用户为之，还是恶意为之。其次，就是请求中的参数是可以被猜测的。这两个条件，构成了CSRF攻击的全部条件。这里还需要强调一下，如果认证基于cookie，那么实际上还有第三个条件：如果cookie是本地cookie，qun.81nanchang浏览器还需要允许跨域发送本地cookie，即如果请求是第三方网站发起的，应带上请求的域的cookie。IE默认是不允许跨域发送本地cookie的（sessioncookie则无此限制），而firefoxe就默认允许的。原理如图：应对策略1：采用token的形式。采用token是指让请求所带的参数变的不可猜测。即，每次需要保护的请求都要带上一个额外的参数，该参数可以是sessionid（一定要是额外的参数，但是其值可以为sessionid），也可以是另外的无法被猜测的一个值。然后，服务器在得到这个请求后，再验证该值是否匹配。可能有人会进一步提出，不是sessionid也是可以非法得到的吗，或者说用户的sessionid是没有授权被操作的？答案是没错，但是，那又是另外的攻击方法（涉及到会话劫持和权限欺骗）了，wwqqmy8在这里，仅仅防御的是CSRF攻击。不过为了保险起见，我们可以用sessionid+salt，然后散列的方式来生成这个token。采用token的形式，我们还需要考虑该token，也就是客户端所带的这个参数的保存问题。从CSRF的本质考虑，token的保存首先不能保存在cookie中，因为cookie本身就是在发送请求的时候可以被带上。其次，token可以保存在服务器端吗，如，我们可以为当前请求设定一个唯一标识，然后保存在session中。答案当然也是不行的，我们可以假设完成一次请求包含两个部分：发起请求的URL（或程序），处理请求的URL（或程序），诚然，这种方式我们防住了单独请求”处理请求的URL”的CSRF攻击。但是，既然攻击者得到了处理请求的页面，那么，他在伪造CSRF的时候，只要带上了发送请求的页面，就依然可以完成一次攻击。所以，token的保存只能是保存在发送到客户端的页面中，然后客户端在接下来发送的请求的时候，带上这个参数就可以了。当然，如果页面本身已经被XSS攻破，那么攻击者仍旧可以伪造一次合法请求，但这已经不是防范CSRF的范畴了，而是防范XSS。2：每次需要被保护的请求发送时，都要求用户输入密码；3：每次需要被保护的请求发送时，都带上referrer。不过这并不是应对的最佳策略，因为referrer是可以被轻易伪造的。具体措施以下具体措施针对token的形式。n遍历前台所有发送请求的地方1：文件查找前台所有的”svc”,”ajax”,”.aspx”,””,”.htm”2：文件查找前台所有的”form”根据以上的查找，汇总到如下的表格：序号文件代码行GET/POST处理完成否n处理请求筛选出需要进行CSRF处理的请求。然后对请求做如下处理：如果是GET方式发送的请求，则为请求加入参数token=[value]，其中[value]为sessionid的值；如果是POST方式发送的请求，则为Form加入隐藏的input，其name为token，其值为sessionid。n遍历所有的请求处理处1：遍历所有的svc，为svc的方法增加token参数2：遍历所有的aspx页面的code-behind3：遍历所有其它的后台方法，如果存在的话，如控制器方法（在EL中并不存在）。根据以上的查找，汇总到如下的表格序号文件代码行处理完成否n处理请求处理处处理参数中的token，检测该token是否存在于当前的sessionid中，如果存在，则放行，否则异常；以上全部的逻辑用代码表示，大致如下：protectedvoidPage_Load(objectsender,EventArgse){stringtoken=CreateToken();PutTokenToClient(token);SaveTokenInS...