web-dev-qa-db-ja.com

URLを介した$ _GETインジェクション？

私はウェブサイトを構築していますが、次のような簡単なケースで_$_GET_コマンドを無害化しないとどうなるのだろうと思っていました。

_<?php
if (isset($_GET['example'])) {
    $object_name = $_GET['example'];
}else{
    header( 'Location: ./index.php');
    exit();
}
echo $object_name;
?>
_

URL _www.example.com/file.php?example=30_の入力をどこで取るか__30_をWebサイトのバックエンドにコードを直接書き込むためのアクセス権を与えるような何か他に悪いことはありますか？

また、私がそこに印刷を持っていなかったが、代わりにその変数をより複雑なものに渡した場合、それを消毒しないままにしておくリスクはありますか？最良の衛生方法は何ですか？ htmlentities()はすべてを停止しますか？

phpxssinjection
1
user139270

あなたの例が基本的に行うことは、あなたがそれを与えるものは何でもエコーバックすることです。つまり、攻撃者はURLにコンテンツを含むリンクを作成することができ、リンクをクリックした人には誰でも、攻撃者が選択したコンテンツが提供されます。

それで、あなたを穏やかに困らせる以外に、それをどのように使うことができますか？それはコンテンツタイプによって異なります。他に何も指定されていないので、text/html。攻撃者がHTMLを提供できる場合、攻撃者は、Originからのものであるかのようにブラウザで実行されるスクリプトを提供することもできます。これは、スクリプトが、たとえば被害者に代わって、認証Cookie、キーログパスワードを盗んだり、アクションを実行したりします。ここにあるのは reflected XSS の主な例であり、それは非常に悪いことです。

しかし、攻撃者はバックエンド、つまりサーバーでコードを実行することができますか？いいえ、直接ではありません。結局、応答はクライアントに送信されます。しかし、これは特権エスカレーションの出発点として使用でき、それを使用しているWebアプリケーションになんらかの弱点がある場合、コードの実行を簡単に削除できる可能性があります。管理者がPHPコードを変更できるようにします。

では、どのようにして消毒しますか？これは、ここで完全に回答するための広義の質問ですが、少なくとも私にこう言わせてください：htmlentities()は、場合によってはあなたを保護しますしかしすべてではありません。いつ、どのように役立つのかを理解するには、 そのドキュメント および OWASP XSS防止のチートシート を参照してください。

Tom's answer で指摘されているように、サニタイズされていないデータで他のことを行うと、他の問題が発生します。 SQLクエリで使用する場合はSQLインジェクション。

3
Anders

問題となるのは、コードの後半でその変数がどうなるかです。

SQLクエリに使用されている場合、SQLインジェクションに対して脆弱である可能性があります。

変数をエコーすると、スクリプトがそのときに実行されているURLに追加される可能性があります。

PHP sanitation and mysqli_real_escape_string/prepareステートメントfor prepare for sanitation for DB querys

2
Tom

ユーザー入力を信頼しないでください。コードによると、$ _ GETの値を意味付けしていません。そのため、脆弱性が高く、LFI、RFI、RCEなどの多くのタイプの脆弱性を引き起こす可能性があります。

0
codeur