http://www.80sec.com Know it then hack it! Tue, 20 Dec 2011 08:10:25 +0000 http://backend.userland.com/rss092 en http://www.80sec.com/sae-security.html http://www.80sec.com/privacy-risk.html http://www.80sec.com/80sec-attack-defend.html <!DOCTYPE copyright [ <!ELEMENT copyright (#PCDATA)> <!ENTITY hi80sec SYSTEM "http://www.wooyun.org/"> ]> <wooyun version="2.0"> <whitehats> &hi80sec; is a legend </whitehats> </wooyun> 这将使得xml解析器以当前上下文的环境引用外部的资源www.wooyun.org作为hi80sec实体的内容，从而在实际的应用上下文里将该部分数据引入逻辑流程进行处理。同样，我们可以使用 file:///etc/passwd file://localhost/etc/password 进行访问本地文件系统的操作。 不同的解析器可能默认对于外部实体会有不同的处理规则，以PHP语言为例，默认处理xml的方法就包括： xml_parse 和 simplexml_load 两种不同的方法，这两种不同的方法在底层完全采取不同的底层逻辑实现，xml_parse的实现方式为expat库，而simplexml_load使用的是libxml库，两个底层库在解析的时候细节并不一样，expat默认对外部实体并不解析，而simplexml_load默认情况下会解析外部实体等，所以simplexml_load和DOM等函数会受此问题影响，而xml_parse则默认不会受到影响。 我们不止在PHP，在包括Java，Python等处理xml的外部组件及函数中都证明可能存在此问题，而且已经在一些互联网公司的应用及一些使用广泛的开源软件中都发现存在问题。 漏洞证明：我们将在WooYun漏洞报告平台上提交我们发现的已经被证明的安全漏洞 解决方案：检查所使用的底层xml解析库，默认禁止外部实体的解析，同时增强对系统的监控，防止此问题被人利用；我们将在WooYun漏洞报告平台上发布可能受影响的，请及时关注；]]> http://www.80sec.com/xml-entity-injection.html $_v) ${$_k} = $_v; } ?> ＜a href=”＜? echo $_SERVER["PHP_SELF"]; ?>?i=＜? echo $id;?>”>分页＜/a> ——————————————————————— 这段PHP代码中模拟register_globals是Web程序中常见的，代码中输出了网页的分页链接这个也是常见的，因为忽略了对传入数据的效验，更产生了最常见的XSS漏洞。 下面是这个XSS漏洞的验证方法： http://127.0.0.1/demo.php?id=1″>＜script>alert(1)＜/script> GET方法在id参数中传入HTML内容，导致网页内容中的herf闭合，执行script标签里的脚本内容： ＜a href=”/demo.php?id=1″>＜script>alert(1)＜/script>”>分页＜/a> [...]]]> http://www.80sec.com/%e6%b7%b1%e6%8e%98xss%e6%bc%8f%e6%b4%9e%e5%9c%ba%e6%99%af%e4%b9%8bxss-rootkit-%e4%bf%ae%e8%ae%a2.html http://www.80sec.com/%e6%b5%85%e8%b0%88%e7%bb%95%e8%bf%87waf%e7%9a%84%e6%95%b0%e7%a7%8d%e6%96%b9%e6%b3%95.html http://www.80sec.com/cross_domain_attack.html route分发->controller接管处理用户输入及业务逻辑->view层代码执行->controller返回展现结果 从上面的流程发现了什么？ MVC模型就是一个将程序员分散在M、C、V中的代码寻找并整合在一起执行的过程。那这必然就要牵涉到一个代码调度执行的问题。这里route就是一个非常明显的例子。一个框架这么多代码文件，route每一次调用controller，都需要根据用户输入的url进行匹配并执行用户指定的函数。这里就是一个薄弱点，一个必然绕不过去的问题。 对应到现实的例子，一个非常明显的例子就是：struts2框架的动态方法调用（DMI） 当你访问www.test.com/a!test.action时，struts会根据你的url帮你映射到名为a的controller中名为test的Action方法。而通过修改test的值，我们可以访问a这个类中的所有方法。如果恰好这个方法中含有敏感的信息，攻击者就获得了一切。结合其他技巧，攻击者能够做到的更多。但这就是框架的功能，框架总是要依靠URL中的内容去匹配执行程序代码。 那么对于PHP的框架呢？仔细想一下，如果PHP需要做分散在不同文件中的代码调度执行，唯一能够实现的方式就是使用require/include函数包含文件。文件名来源于哪里？来源于用户输入的URL。实际上目前市面上的大部分PHP框架也都是这么实现的，Yii，FleaPHP等等。如果对用户的输入没有做好验证，就很容易导致一个本地文件包含漏洞。笔者曾经就在某不知名框架中发现过这样的漏洞，在不涉及应用程序逻辑的情况下，直接获取了系统权限。 2、统一化逻辑处理 框架的一大功能就是，通过统一的入口点，可以做一些统一的安全防护、逻辑控制。在软件工程学里的说法，这个叫“面向切面编程”（AOP）。 然而我们并不是说这样的统一控制模式不好，但对于这样的统一控制，如果框架设计或实现的不好，就能直接沦陷所有跑在之上的应用。 这里有一个典型的统一处理导致安全问题的极端的例子：struts2任意代码执行漏洞。 漏洞起因是struts2希望能让用户提交的值能够直接注入到程序中的数据对象，而无需手动类型转换并给内部变量赋值等操作。为此struts2专门设计了一个叫做ognl的表达式。通过它，用户提交的参数就能被自动解析为程序上下文中所存在的变量。 想想为什么能够自动解析？原因是用户提交的参数被当作自定义语言的代码被解析执行了！只是你并没有意识到这一点而已。于是有心人研究了一下，发现ognl表达式除了参数值注入，还能通过它直接调用Java自身的API。于是，一个巨大的通杀0day就这么诞生了。 回想一下，如果struts2没有这么“智能”的自动化、统一化用户输入处理机制，也就不会出现上述的大漏洞了。 前段时间爆出的Django的csrf token绕过漏洞也是在统一安全处理的设计上出的问题。深究一下，为什么会出现这样的绕过问题？原因就是，框架必须要对所有用户的提交在真正的应用执行前做统一的csrf防范，于是django框架产生的token是保存在cookie中的（老版本和sessionid有关，这个也是保存在cookie中）。对于用户提交的POST请求，表单中增加一项token，框架在获得token值后，与cookie中的正确token值比对，如果相等就通过。然而对于ajax的请求，框架设计者却想当然的认为只要判断X-Requested-With这个Ajax特有的HTTP头即可，根本无需运算比对token。所以，框架对于http头中包含有X-Requested-With域的请求放行。通常情况下，只有ajax的请求浏览器才会带上此自定义域，且浏览器一般无法自定义此字段。 结果被人发现可以利用flash+307跳转可以伪造自定义http头，结果就绕过了此防范，导致统一的csrf防护毫无作用。如果应用程序完全依靠框架的统一安全实现，就会受到安全漏洞的威胁。 其实Django也很无奈，在它的架构设计中，它通过这个自定义头判断ajax思路上也没有什么问题。可惜在目前连黄瓜都不可靠的年代，就没什么是可靠的了。 3、常见代码高度封装 [...]]]> http://www.80sec.com/security-about-framework.html http://www.80sec.com/security-issue-on-linux-fd-inheritance.html http://www.80sec.com/wooyun-%e4%b9%8c%e4%ba%91%e6%ad%a3%e5%bc%8f%e4%b8%8a%e7%ba%bf.html