常见WEB安全漏洞与整改建议.docVIP

常见WEB安全漏洞及整改建议 1. HTML表单没有CSRF保护 1.1 问题描述： ? ? CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。 ? ? CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。 1.2 整改建议： ? ? CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。有以下三种方法： ? ? (1).Cookie Hashing(所有表单都包含同一个伪随机值)： ? ? (2).验证码 ? ? (3).One-Time Tokens(不同的表单包含一个不同的伪随机值) 1.3 案例： ? ??1.服务端进行CSRF防御 ? ? 服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。 1.3.1 Cookie Hashing(所有表单都包含同一个伪随机值)： ? ? 这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败. ? ? ? ? //构造加密的Cookie信息 ? ? $value = “DefenseSCRF”; ? ? setcookie(”cookie”, $value, time()+3600); ? ? ? ? ? 在表单里增加Hash值，以认证这确实是用户发送的请求。 ? ? ? ? $hash = md5($_COOKIE[cookie]); ? ? ? ? ? ? ?? ? ?? ? ??” ? ?? ? ? ? ? 然后在服务器端进行Hash值验证 ? ? ? ? if(isset($_POST[check])) { ? ? $hash = md5($_COOKIE[cookie]); ? ? if($_POST[check] == $hash) { ? ? doJob(); ? ? } else { ? ? //… ? ? } ? ? } else { ? ? //… ? ? } ? ? ? ? ? 这个方法已经可以杜绝99%的CSRF攻击了，那还有1%….由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。 1.3.2 验证码 ? ? 这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，这个方案可以完全解决CSRF，但在易用性方面似乎不是太好，还有是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。 1.3.3 One-Time Tokens(不同的表单包含一个不同的伪随机值) ? ? 在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。 ? ? 以下实现: ? ? 1).先是令牌生成函数(gen_token())： ? ? ? ? function gen_token() { ? ? //这是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。 ? ? //这个可以参考写的Findbugs笔记中的《Randomobject created and used only once》 ? ? $token = md5(uniqid(rand(), true)); ? ? return $token; ? ? } ? ? 2).然后是Session令牌生成函数(gen_stoken())： ? ? ? ? function gen_stoken() { ? ? $pToken = “”; ? ? if($_SESSION[STOKEN_NAME] == $pToken){ ? ? //没有值，赋新值 ? ? $_SESSION[STOKEN_NAME] = gen_token(); ? ? } ? ? else{ ? ? //继续使用