PEAK XOOPS - anti-XSS system (4) in englishin japanese

Archive | RSS |
PHP
PHP : anti-XSS system (4)
Poster : GIJOE on 2006-06-25 18:20:31 (11448 reads)

in englishin japanese
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
Printer friendly page Send this story to a friend

Comments list

GIJOE  Posted on 2006/7/14 15:03
Quote:
Quote:
やはり外部からの「HTML許可」はあり得ない設定ですね。
そうなんですよね。HTMLタグありのプレビュー機能がいかに難しいか・・・。今のところ、私は自分が納得できる範囲での解決方法が見つけられてないです。
「HTMLタグありのプレビュー」は、XSSの方ですね。
これだと、BigUmbrellaも効かないですし。

ただ、記事にも書きましたが、このHTMLプレビュー以外はすべてBigUmbrellaでXSSを封じ込める事ができるので、あとは、HTMLプレビューにチケットなりリファラーチェックなりを埋め込めばOKじゃないかと踏んでます。

Quote:
Quote:
承認制でも事実上意味のないケースが多く見られますし。
管理者にCSRF攻撃を仕掛けられるだけですからね。
私が書いたのは、承認制のチェックにおいて、ScriptInsertionが成立しているものが多い、という意味だったのですが、tohokuaikiさんのおっしゃる通り、承認行為そのものを、別途XSS+CSRFで強制する、なんて手はありますね。

ただ後者は、BigUmbrellaで防げるとは思いますが、ずっとベターな対策として、管理者承認にcapchaを導入するしか!
tohokuaiki  Posted on 2006/7/13 18:47
Quote:
やはり外部からの「HTML許可」はあり得ない設定ですね。
そうなんですよね。HTMLタグありのプレビュー機能がいかに難しいか・・・。今のところ、私は自分が納得できる範囲での解決方法が見つけられてないです。

Quote:
承認制でも事実上意味のないケースが多く見られますし。
管理者にCSRF攻撃を仕掛けられるだけですからね。
GIJOE  Posted on 2006/7/13 17:57 | Last modified
Quote:
安易にprototype.jsなんかをincludeしてしまうと、このフィルタリングが非常に難しい・・・。たとえば、Ajaxは new Ajax.Request で生成されてしまう・・・。
外部ライブラリ自体の脆弱性ではないけど、それが引き起こす脆弱性が増えそうですね。
あ〜、なるほど〜。そりゃ潰しようがないですね。
やっぱり、Script Insertionについては、本体側で真面目に作ってもらうしかないですね。

やはり外部からの「HTML許可」はあり得ない設定ですね。
承認制でも事実上意味のないケースが多く見られますし。

Quote:
便利さと完全にトレードオフです。困ったものです・・。
実際、CSRF対策は
・とりあえずチケット
・後は何とかどっかで引っかかってくれ
という状況で。
これ、Mozzilaとかのブラウザプロジェクトにみんなでお願いしましょうよ。

XMLHttpRequest の場合には、それがWebアプリケーション側で確実に判別できるHTTPリクエストを送る(しかもJavaScriptからはキャンセルできない)、という仕様を追加してもらうしかないですよ。
tohokuaiki  Posted on 2006/7/13 12:32
Quote:
とにかく、JavaScriptで最も怖いのは、"XMLHttpRequest"なので、この文字列と、動的にXMLHttpRequestという関数名を生成・実行する"eval"の2つを検出することは最低限必要でしょう。
うーん。外部JavaScriptライブラリをincludeしている場合、潰す箇所がべらぼうに増えますね・・・。

安易にprototype.jsなんかをincludeしてしまうと、このフィルタリングが非常に難しい・・・。たとえば、Ajaxは new Ajax.Request で生成されてしまう・・・。
外部ライブラリ自体の脆弱性ではないけど、それが引き起こす脆弱性が増えそうですね。

便利さと完全にトレードオフです。困ったものです・・。
実際、CSRF対策は
・とりあえずチケット
・後は何とかどっかで引っかかってくれ
という状況で。
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!