PEAK XOOPS - anti-XSS system (4) 
PHP
PHP : anti-XSS system (4)
This is the last chapter of BigUmbrella.
The code in (3) has two points should be argued.
- Is the check pattern OK?
preg_match( '/[<\'"].{15}/s' , $val , $regs )<img src="(REQUEST)" />
<a href="(REQUEST)">
If this pattern exists, it is not enough.
Because "java-script:" attack can exploit it.
Thus, you should add such "java-script:" checker into the code of (3).
- Is it enough to check POST and GET?
Checking COOKIE sounds non-sense, because contaminated COOKIE means he/she has already been exploited.
Rather than cookie, you should add checking $_SERVER into the checker.
Don't forget adding $_SERVER['PHP_SELF'] , $_SERVER['PATH_INFO'] , $_SERVER['PATH_TRANSLATED'] , at least.
And don't forget BigUmbrella just protect from XSS attacking.
BigUmbrella can do nothing about ScriptInsertion attack.
You should learn XSS and ScriptInsertion are different attacks each other.
Related articles
- Big Umbrella Anti-SQL-Injection(1) (2009-01-07 04:37:49)
- anti-XSS system (3) (2006-06-22 12:46:44)
- anti-XSS system (2) (2006-06-21 15:27:40)
- anti-XSS system (1) (2006-06-20 13:16:00)
Comments list
GIJOE
Posted on 2006/7/14 15:03
Quote:「HTMLタグありのプレビュー」は、XSSの方ですね。
これだと、BigUmbrellaも効かないですし。
ただ、記事にも書きましたが、このHTMLプレビュー以外はすべてBigUmbrellaでXSSを封じ込める事ができるので、あとは、HTMLプレビューにチケットなりリファラーチェックなりを埋め込めばOKじゃないかと踏んでます。
Quote:私が書いたのは、承認制のチェックにおいて、ScriptInsertionが成立しているものが多い、という意味だったのですが、tohokuaikiさんのおっしゃる通り、承認行為そのものを、別途XSS+CSRFで強制する、なんて手はありますね。
ただ後者は、BigUmbrellaで防げるとは思いますが、ずっとベターな対策として、管理者承認にcapchaを導入するしか！
Quote:そうなんですよね。HTMLタグありのプレビュー機能がいかに難しいか・・・。今のところ、私は自分が納得できる範囲での解決方法が見つけられてないです。やはり外部からの「HTML許可」はあり得ない設定ですね。
これだと、BigUmbrellaも効かないですし。
ただ、記事にも書きましたが、このHTMLプレビュー以外はすべてBigUmbrellaでXSSを封じ込める事ができるので、あとは、HTMLプレビューにチケットなりリファラーチェックなりを埋め込めばOKじゃないかと踏んでます。
Quote:
Quote:管理者にCSRF攻撃を仕掛けられるだけですからね。承認制でも事実上意味のないケースが多く見られますし。
ただ後者は、BigUmbrellaで防げるとは思いますが、ずっとベターな対策として、管理者承認にcapchaを導入するしか！
tohokuaiki
Posted on 2006/7/13 18:47
Quote:そうなんですよね。HTMLタグありのプレビュー機能がいかに難しいか・・・。今のところ、私は自分が納得できる範囲での解決方法が見つけられてないです。
Quote:管理者にCSRF攻撃を仕掛けられるだけですからね。
やはり外部からの「HTML許可」はあり得ない設定ですね。
Quote:
承認制でも事実上意味のないケースが多く見られますし。
GIJOE
Posted on 2006/7/13 17:57 | Last modified
Quote:あ〜、なるほど〜。そりゃ潰しようがないですね。
やっぱり、Script Insertionについては、本体側で真面目に作ってもらうしかないですね。
やはり外部からの「HTML許可」はあり得ない設定ですね。
承認制でも事実上意味のないケースが多く見られますし。
Quote:これ、Mozzilaとかのブラウザプロジェクトにみんなでお願いしましょうよ。
XMLHttpRequest の場合には、それがWebアプリケーション側で確実に判別できるHTTPリクエストを送る（しかもJavaScriptからはキャンセルできない）、という仕様を追加してもらうしかないですよ。
安易にprototype.jsなんかをincludeしてしまうと、このフィルタリングが非常に難しい・・・。たとえば、Ajaxは new Ajax.Request で生成されてしまう・・・。
外部ライブラリ自体の脆弱性ではないけど、それが引き起こす脆弱性が増えそうですね。
やっぱり、Script Insertionについては、本体側で真面目に作ってもらうしかないですね。
やはり外部からの「HTML許可」はあり得ない設定ですね。
承認制でも事実上意味のないケースが多く見られますし。
Quote:
便利さと完全にトレードオフです。困ったものです・・。
実際、CSRF対策は
・とりあえずチケット
・後は何とかどっかで引っかかってくれ
という状況で。
XMLHttpRequest の場合には、それがWebアプリケーション側で確実に判別できるHTTPリクエストを送る（しかもJavaScriptからはキャンセルできない）、という仕様を追加してもらうしかないですよ。
tohokuaiki
Posted on 2006/7/13 12:32
Quote:うーん。外部JavaScriptライブラリをincludeしている場合、潰す箇所がべらぼうに増えますね・・・。
安易にprototype.jsなんかをincludeしてしまうと、このフィルタリングが非常に難しい・・・。たとえば、Ajaxは new Ajax.Request で生成されてしまう・・・。
外部ライブラリ自体の脆弱性ではないけど、それが引き起こす脆弱性が増えそうですね。
便利さと完全にトレードオフです。困ったものです・・。
実際、CSRF対策は
・とりあえずチケット
・後は何とかどっかで引っかかってくれ
という状況で。
とにかく、JavaScriptで最も怖いのは、"XMLHttpRequest"なので、この文字列と、動的にXMLHttpRequestという関数名を生成・実行する"eval"の２つを検出することは最低限必要でしょう。
安易にprototype.jsなんかをincludeしてしまうと、このフィルタリングが非常に難しい・・・。たとえば、Ajaxは new Ajax.Request で生成されてしまう・・・。
外部ライブラリ自体の脆弱性ではないけど、それが引き起こす脆弱性が増えそうですね。
便利さと完全にトレードオフです。困ったものです・・。
実際、CSRF対策は
・とりあえずチケット
・後は何とかどっかで引っかかってくれ
という状況で。
Login