PHPユニバーサルパスワードの実際の役割の分析_PHPチュートリアル

About

しかし、PHP サイトで GPC マジック変換がオンになっている場合、特殊記号がエスケープされ、PHP インジェクションが完全に排除されるという人もいます。実際、これを言った人は、それについてよく考えておらず、ましてやユニバーサル パスワードを使用して PHP のバックエンドにアクセスしようとしたことはありません。

実際、GPC マジック変換がオンになっているかどうかは、PHP ユニバーサル パスワードを使用してバックエンドに入る場合にはまったく影響しません。ユニバーサルパスワード「or」=「or」を使用すると、当然アクセスできません。理由は、GPC をオンにするとシングルクォーテーションが変換されるためです。 PHP を挿入するときに私がよく使用する PHP ユニバーサル パスワードは次のとおりです: 'or 1=1/*。

それでは、なぜこれがバックグラウンドに入るのかを分析してみましょう。 SQL ステートメントが次のように書かれている場合: "SELECT * FROM admin where name='".$_POST['name']."'andpassword='".$_POST['password']."'" と入力します。アカウント番号のユニバーサルパスワード「または 1=1/*」にパスワードを入力すると、SQL ステートメントは select * from admin where name=''or 1=1/*'、password='任意の文字' になります。 /* は mysql のコメント文字で、以降はすべてコメントアウトされるため、パスワードを気軽に入力できます。

GPC 変換がオンになっていないと仮定して、以下を参照してください: ここで、name='' または 1=1 (*/以下はコメントアウトされています)、name='' の論理値は false、および次の 1 =1 論理 値は true ですが、全体として false または true になります。最終的な論理値は true のままで、バックグラウンドに入ります。

その後、GPC変換がオンになっている場合はシングルクォーテーションが変換されます。ステートメントは where name=''or 1=1 になります。先ほどとの違いを見てみましょう。ただ、他にもあります。 name='' と name='' の論理値は同じで、どちらも false であれば、SQL ステートメント全体の論理値は true ではないでしょうか。バックステージに行けない理由はありますか？

したがって、一般に、PHP ユニバーサル パスワードは次のように書くことができます: 'または 1=1/* であり、GPC 変換がオンになっているかどうかは影響しません。したがって、考えを変えてください: 文字インジェクションを使用する PHP Web サイトでは、ユニバーサル パスワード ' または 1=1/*

を使用できます。

http://www.bkjia.com/PHPjc/446120.htmlwww.bkjia.com本当http://www.bkjia.com/PHPjc/446120.html技術記事しかし、PHP サイトで GPC マジック変換がオンになっている場合、特殊記号がエスケープされ、PHP インジェクションが完全に排除されるという人もいます。実際、これを言った人は、よく考えておらず、ましてや味わったこともありません...