默认相当于： <%=UttpUtil.HtmlEncode(Model.UserName) %>
至于连模板都没有用，直接拼接字符串输出html的做法，就彻底无语了。 ====== XSRF / XSS ====== 这样的攻击方式才相对“新颖”一些。 ===== HTTP Get ===== 假设网站存在可能导致用户数据改变的接口，如： * http://dummydomain.com/update_nick.aspx?nick=Stupid 那么，第三方网站可以直接将上述URL作为一个img标签的src，使得用户在访问的时候自动去获取此页面，造成昵称被改。 这里的问题根源是接口定义违反了HTTP的推荐设计。 一切HTTP Get操作，都不应该涉及用户数据的修改；必须强制使用为POST，以避免数据被无意/恶意修改。 ===== HTTP Post ===== 假设修改昵称的接口变成： * http://dummydomain.com/update_nick.aspx 用户必须通过form提交才可能可以修改数据，比方说：
这样的设计实际上也还是会有问题的，比方说，攻击者可以在 http://attackerdomain.com/clickme.html 里面写：
用户在访问 attackerdomain.com 的时候，便有可能被误导去点击，然后造成自己在 dummydomain.com 的数据被修改。 在这样的场景下，无论接口是Get还是Post，都无济于事；这类攻击是被称为 XSRF： Cross-site request forgery。 ===== XSRF =====
相比起页面注入，Web开发者对于XSRF的认识还不够；但它也是可以防范的。 首先，要确保所有的涉及数据更新的操作都是经过HTTP Post。 然后，服务器端强制要求所有 HTTP Post都必须包含一个 _XSRF 的参数；其值必须跟Cookie中的同名Cookie相同，比方说：
当攻击者企图从 http://attackerdomain.com/clickme.html 页面提交资料去 http://dummydomain.com/update_nick.aspx 时，浏览器发送的是 dummydomain的 cookie；而这个cookie的值，是attacherdomain.com所无法获得的，也就是说，它无法伪造：
有安全意识，或者说，先进的web框架（ Django / Tornado / RoR 等等 ），默认都强制要求POST提交必须有 XSRF 检查。 微软的技术，基本都是跟在别人后面的，目前似乎还是的开发者手动去处理，asp.net MVC 可以参考： * http://weblogs.asp.net/srkirkland/archive/2010/04/14/guarding-against-csrf-attacks-in-asp-net-mvc2.aspx 如果asp.net开发者没有安全意识，专门去给所有页面添加XSRF的检查，那么做出来的网站，都可能受到 XSRF 攻击。 大家有兴趣的话可以去挑各种asp.net开发的网站去试；或者说，想想自己做过的网站是否会受到此种攻击。 :) ====== Web 安全的根基 ======
Cookie / Same origin policy（简单的说，就是防止AJAX跨域）是 Web安全的根源。 而这两点，是由客户端浏览器所保证的，如果客户端实现得不好，域名A可以访问域名B的cookie值，或者说发起AJAX调用，那么所有服务器端的安全措施都是白搭。 Cookie在HTTP中是明文传输的，是可能会被中间人窃取然后伪造的；而cookie又是Web用户认证信息的根源，一旦Cookie泄露，攻击方就可以为所欲为。 所以，很多网站（比方说， twitter / gmail）默认都在强制把所有的页面传输转移去 HTTPS；以杜绝中间人的问题。 千里之堤，溃于蚁穴；根基不牢靠，上层所做的任何安全措施，都可能被攻破。 这里的关键，是要有一个可靠的根基，跟Web技术没有直接关系，Native程序也会有同样性质的问题。
最新评论