WAF中的一个特性就是要阻止各类的XSS攻击以及CSRF攻击,尤其是后者,一般的WAF解决方案是针对GET以及POST插入随机身份令牌的做法,这样做的目的就是辨别出来经过伪造的跨站请求提交。
对于GET而言,WAF需要在受保护的URL连接后面动态插入随机令牌,比如这两个对比站点:http://trade-spf.gdsdemo.com/ 以及 http://trade-no-spf.gdsdemo.com/ ,前者是受保护的测试站点,后者则没有收到任何保护。
对于POST而言,也是类似的做法,WAF通过合理的令牌构造,可以比较有效的保护表单数据以及ASP.NET VIEWSTATE数据。
设计一个完备的令牌机制,可以有效的做到保护如下几个方面:
<a href="javascript:__doPostBack('ctl00$MainContent$gvwThreads'
,'Sort$LastPostDate')">
进化为
<a href="javascript:__doPostBack('b/xEVUeEDOCnhiKu0jS5USUs6N
4Qu1VH5OqHOwF146wSPlA87g==:1829384:61D26FD0849FF93D67B8489C4Qu1VH5OqHOwF146wSPlA87g==:61D26FD0849FF93D67B8489CF
A76','b/xEVUeEDOBfdZR3UM0Ds212HDDwHY3KoYyc/+/JULiDcjQ=:1829384:
83BF9D18B5C34CE2FC0541F954C093B43F0C3EA5')">
有关这方面的东西,后面再慢慢讨论.
下面这篇blog是讨论如何通过ASP.NET MVC的AntiForgeryToken helpers来保护POST数据,可以参考下。
Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Update: Since the Release Candidate of ASP.NET MVC, these anti-forgery helpers have been promoted to be included in the core ASP.NET MVC package (and not in the Futures assembly).
Cross-site scripting (XSS) is widely regarded as the number one security issue on the web. But since XSS gets all the limelight, few developers pay much attention to another form of attack that’s equally destructive and potentially far easier to exploit. Your application can be vulnerable to cross-site request forgery (CSRF) attacks not because you the developer did something wrong (as in, failing to encode outputs leads to XSS), but simply because of how the whole Web is designed to work. Scary!
How CSRF works
So, what’s it all about? All web application platforms are potentially vulnerable to CSRF, but in this post I’ll focus on ASP.NET MVC. Imagine you have a controller class as follows:
public class UserProfileController : Controller { public ViewResult Edit() { return View(); } public ViewResult SubmitUpdate() { // Get the user's existing profile data (implementation omitted) ProfileData profile = GetLoggedInUserProfile(); // Update the user object profile.EmailAddress = Request.Form["email"]; profile.FavoriteHobby = Request.Form["hobby"]; SaveUserProfile(profile); ViewData["message"] = "Your profile was updated."; return View(); } }This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. Everything’s fine, right? We implement this sort of thing all the time…
Unfortunately, this innocent controller is an easy target for CSRF. Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:
<body onload="document.getElementById('fm1').submit()"> <form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post"> <input name="email" value="hacker@somewhere.evil" /> <input name="hobby" value="Defacing websites" /> </form> </body>Next, they somehow persuade a victim to visit this page (basic social engineering, look it up). When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server.
Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.
Of course, instead of changing an victim’s email address, they can perform any action that the victim can perform with a single POST request. For example, they might be able to grant administrative permissions to another account, or post something defamatory to a CMS.
Ways to stop CSRF
There are two main ways to block CSRF:
- Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain. However, some people disable their browser’s Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain versions of Adobe Flash installed. This is a weak solution.
- Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. If, for example, this token is the user’s password, then a third-party can’t forge a valid form post, because they don’t know each user’s password. However, don’t expose the user’s password this way: Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.
Using the AntiForgeryToken helpers
With Preview 5, Microsoft has added a set of helpers to the “futures” assembly, Microsoft.Web.Mvc.dll,The core ASP.NET MVC package includes a set of helpers that give you a means to detect and block CSRF using the “us