dB挿入をサニタイズし、htmlentities($text, ENT_COMPAT, 'UTF-8')
で記述したHTMLをエスケープしている場合、xss_cleanで入力をフィルタリングするポイントもありますか?他にどのような利点がありますか?
xss_clean() は広範であり、また馬鹿げています。この関数の90%は、xssを防ぐために何もしません。 Word alert
を探しますが、_document.cookie
_は探しません。ハッカーはalert
をエクスプロイトに使用しません。xssでCookieをハイジャックするか、CSRFトークンを読み取ってXHRを作成します。
ただし、htmlentities()
またはhtmlspecialchars()
を実行することは冗長です。 xss_clean()
が問題を修正し、htmlentities($text, ENT_COMPAT, 'UTF-8')
が失敗する場合は次のとおりです。
_<?php
print "<img src='$var'>";
?>
_
簡単なPOCは次のとおりです。
http://localhost/xss.php?var = http://domain/some_image.gif '%20onload = alert(/ xss /)
これにより、_onload=
_イベントハンドラーがイメージタグに追加されます。この形式のxssを停止する方法はhtmlspecialchars($var,ENT_QUOTES);
です。この場合、xss_clean()
もこれを防ぎます。
ただし、xss_clean()ドキュメントから引用:
もちろん、100%絶対確実なものはありませんが、フィルターを通過するものを取得することができませんでした。
つまり、XSSは_output problem
_not_input problem
_です。たとえば、この関数は、変数が_<script>
_タグまたはイベントハンドラー内に既にあることを考慮することはできません。また、DOMベースのXSSも停止しません。最適な機能を使用するには、データの使用方法を考慮する必要があります。入力のすべてのデータをフィルタリングすることは、悪い習慣です。安全でないだけでなく、データが破損し、比較が困難になる可能性があります。
あなたの場合、 「より厳密な方法は問題ありませんが、より軽量です」 。 CodeIgniter開発者は、xss_clean()を「「安全な」HTMLタグを許可するコメントシステムまたはフォーラム」という別のユースケースに使用することを意図しています。これは、ユーザー名フィールドに適用されたxss_cleanが表示されるドキュメントから明らかではありません。
Xss_clean()を使用しないもう1つの理由があります。これは、これまでstackoverflowで強調されていませんでした。 xss_clean()は 2011 および 2012 の間に壊れたため、完全に修正することは不可能です。少なくとも完全な再設計がなければ、それは起こりませんでした。 現時点では、まだ次のような文字列に対して脆弱です:
<a href="j&#x41;vascript:alert%252831337%2529">Hello</a>
Xss_clean()の現在の実装は、文字列全体にurldecode()およびhtml_entity_decode()を効果的に適用することから始まります。これは、「javascript:」などの単純なチェックを使用できるようにするために必要です。最後に、デコードされた文字列を返します。
攻撃者はエクスプロイトを2回エンコードするだけです。 xss_clean()によって一度デコードされ、cleanとして渡されます。その後、ブラウザで実行する準備ができた、単独でエンコードされたエクスプロイトがあります。
これらのチェックは主に正規表現に依存しているため、これらのチェックを「単純」で修正不可能と呼びます。 HTMLは通常の言語ではありません。 ブラウザのパーサーと一致させるには、より強力なパーサーが必要です ; xss_clean()にはそのようなものはありません。たぶん、正規表現できれいに字句解析するHTMLのサブセットをホワイトリストに登録することが可能かもしれません。ただし、現在のxss_clean()は非常にブラックリストです。
XSS精製を行うには http://htmlpurifier.org/ を使用することをお勧めします。 CodeIgniter Inputクラスを拡張して活用を開始しています。
はい、あなたはまだそれを使用する必要があります、私は一般的に、少なくとも公共向け入力で使用することをルールにします提出する。
関数の真の目的は クロスサイトスクリプティング攻撃 を防ぐことであるため、一般的にDBクエリの入力を無害化することは副作用のように思われます。
私はxss_cleanが実行するすべてのステップの詳細を詳しく説明するつもりはありませんが、あなたが言及したいくつかのステップ以上のことを行うことをお伝えします xss_clean関数のソースを貼り付けました あなたが自分自身を見ることができるように、それは完全にコメントされています。
POSTまたはCOOKIEデータに遭遇するたびにフィルターを自動的に実行したい場合は、application/config/config.phpファイルを開いてこれを設定することで有効にできます:$ config ['global_xss_filtering' ] = TRUE;
Application/config/config.phpファイルを開き、これを設定することにより、csrf保護を有効にできます。$ config ['csrf_protection'] = TRUE;
詳細については、次のリンクをご覧ください。
https://ellislab.com/codeigniter/user-guide/libraries/security.html