php - 人気のあるPHPCMSの歴史的なセキュリティ上の欠陥？

Question

私はPHPCMSを作成しています。これは、一般の人々に使用されることを望んでいます。セキュリティは大きな懸念事項であり、Wordpress、Joomla、Drupalなどの人気のあるPHPCMSのいくつかから学びたいと思います。アプリケーションで回避できる過去のセキュリティ上の欠陥や脆弱性は何ですか。そして、それらを回避するためにどのような戦略を使用できますか？彼らが最初から正しく処理したために脆弱性として直面しなかった可能性があることを私が懸念する必要がある他の問題は何ですか？詳細からシステムレベルのセキュリティアプローチまで、どのような追加のセキュリティ機能または対策を含めますか？できるだけ具体的にしてください。私は一般的に通常の攻撃ベクトルのほとんどを知っていますが、すべての基地がカバーされていることを確認したいので、明白なことも言うことを恐れないでください。PHP5.2以降を想定します。

編集：これをコミュニティウィキに変更します。Arkhの優れた答えは受け入れられますが、もしあれば、私はまださらなる例に興味があります。

score 59 · Accepted Answer

クロスサイトリクエストフォージェリ（CSRF）

説明：

基本的な考え方は、ユーザーをだまして、攻撃したCMSに対してブラウザがPOSTまたはGETリクエストを開始するページに誘導することです。

CMSを利用したサイト管理者のメールアドレスを知っていると想像してみてください。あなたがそれに欲しいものを何でも彼にいくつかの面白いウェブページに電子メールで送ってください。このページでは、CMSの管理パネルが新しい管理ユーザーを作成するために使用するデータを使用してフォームを作成します。これらのデータをWebサイトの管理パネルに送信すると、Webページのiframeが非表示になります。Voilà、あなたはあなた自身の管理者アカウントを作成しました。

それを防ぐ方法：

通常の方法は、すべてのフォームでランダムな短命（15分から1時間）のナンスを生成することです。CMSがフォームデータを受信すると、最初にナンスが正常かどうかをチェックします。そうでない場合、データは使用されません。

CMSの例：

詳しくは：

ウィキペディアのページとOWASPプロジェクト。

不正なパスワードの保存

説明：

データベースがハッキングされ、ウィキリークスのようなものに公開されたと想像してみてください。ユーザーの大部分が多くのWebサイトで同じログインとパスワードを使用していることを知っているので、それらを簡単に取得できるようにしますか？

いいえ。データベースデータが公開された場合の被害を軽減する必要があります。

それを防ぐ方法：

最初のアイデアはそれらをハッシュすることです。レインボーテーブルがあるため、これは悪い考えです（たとえば、ハッシュがmd5ではなくsha512であっても）。
2番目のアイデア：ハッカーが各パスワードをブルートフォースする必要があるように、ハッシュする前に一意のランダムソルトを追加します。問題は、ハッカーが大量のハッシュを高速に計算できることです。
したがって、現在のアイデアは、パスワードのハッシュを遅くすることです。頻繁に行うことはないので、気にしません。しかし、攻撃者は、1ミリ秒あたりに生成されるハッシュが1000から1になると、泣きます。

プロセスを簡単にするために、パスワードの第一人者によって開発されたライブラリphpassを使用できます。

CMSの例：

Joomla！：塩漬けmd5
ModX：md5
Typo3：クリアテキスト
Drupal：このディスカッションの後にphpassに切り替えました。

詳しくは：

phpassページ。

クロスサイトスクリプティング（XSS）

説明

これらの攻撃の目的は、正当なユーザーによって実行されるスクリプトをWebサイトに表示させることです。

これらには、永続的かどうかの2種類があります。最初のものは通常、ユーザーが保存できるものからのものであり、他のものは送信されたリクエストによって与えられたパラメーターに依存します。これは例ですが、永続的ではありません：

<?php
if(!is_numeric($_GET['id'])){
  die('The id ('.$_GET['id'].') is not valid');
}
?>

これで、攻撃者は次のようなリンクを送信できます。http://www.example.com/vulnerable.php?id=<script>alert('XSS')</script>

それを防ぐ方法

クライアントに出力するすべてのものをフィルタリングする必要があります。ユーザーにhtmlを保存させたくない場合は、 htmlspecialcharsを使用するのが最も簡単な方法です。しかし、彼らにhtml（彼ら自身のhtmlまたはbbcodeのような他のものから生成されたもののいずれか）を出力させるとき、あなたは非常に注意しなければなりません。これは、imgタグの「onerror」イベントを使用した古い例です：vBulletin脆弱性。または、古いMyspaceのSamyがあります。

CMSの例：

詳しくは：

ウィキペディアとOWASPを確認できます。ha.ckersページにもたくさんのXSSベクターがあります。

メールヘッダーインジェクション

説明：

\r\nメールヘッダーはCRLF（）シーケンスで区切られます。一部のユーザーデータを使用してメールを送信すると（From：またはTo：に使用する場合など）、より多くのヘッダーを挿入できます。これにより、彼らはあなたのサーバーから匿名のメールを送ることができます。

それを防ぐ方法：

ヘッダー内のすべての、、、および文字を\nフィルタリングし\rます。%0a%0d

CMSの例：

Jetbox CMS

詳しくは：

ウィキペディアはいつものように良いスタートです。

SQLインジェクション

説明：

古い古典。これは、ユーザーからの直接入力を使用してSQLクエリを作成するときに発生します。この入力が必要に応じて作成されている場合、ユーザーは自分が望むことを正確に実行できます。

それを防ぐ方法：

単純。ユーザー入力を使用してSQLクエリを作成しないでください。パラメータ化されたクエリを使用します。たとえば、ファイルシステム、独自のデータベース、またはWebサービスからの入力など、ユーザー入力として自分でコーディングされていない入力を検討してください。

CMSの例：

詳しくは：

ウィキペディアとOWASPには、このテーマに関する非常に優れたページがあります。

Http応答の分割

説明：

電子メールヘッダーと同様に、httpヘッダーはCLRFシーケンスで区切られます。アプリケーションがユーザー入力を使用してヘッダーを出力する場合、これを使用して独自のヘッダーを作成できます。

それを防ぐ方法：

メールの場合と同様に、ヘッダーの一部として使用する前に、ユーザー入力から、、、および文字をフィルタリング\nします。ヘッダーをurlencodeすることもできます。\r%0a%0d

CMSの例：

詳しくは：

この種の攻撃に関する多くの情報がどこにあるかについて少し推測させてください。OWASPとウィキペディア。

セッションハイジャック

説明：

これでは、攻撃者は別の正当な（そしてできれば認証された）ユーザーのセッションを使用したいと考えています。このために、彼は自分のセッションCookieを被害者のものと一致するように変更するか、被害者に自分の（攻撃者の）自分のセッションIDを使用させることができます。

それを防ぐ方法：

ここで完璧なものはありません：-攻撃者が被害者のCookieを盗んだ場合、ユーザーセッションがユーザーIPと一致することを確認できます。ただし、正当なユーザーがIPを頻繁に変更するプロキシを使用している場合、これによりサイトが役に立たなくなる可能性があります。-攻撃者がユーザーに自分のセッションIDを使用させる場合は、 session_regenerate_idを使用して、ユーザーの権限が変更されたときにユーザーのセッションIDを変更します（ログイン、ログアウト、Webサイトの管理者部分へのアクセスなど）。

CMSの例：

Joomla！とDrupal
禅カート

詳しくは：

主題に関するウィキペディアのページ。

他の

ユーザーの実行：試行されたIPではなく、試行されたユーザー名を無効にすることでログイン試行のブルートフォーシングを防止すると、誰でも2分以内にすべてのユーザーをブロックできます。新しいパスワードを生成するときも同じです。ユーザーが新しいパスワードを確認するまで（たとえば、パスワードを使用してログインすることにより）、古いパスワードを無効にしないでください。
ユーザー入力を使用してファイルシステムで何かを実行します。それがエイズと混合された癌であるかのようにこれをろ過してください。これは、ファイルでのincludeとrequireの使用に関係し、パスはユーザー入力から部分的に作成されます。
eval、system、exec、またはこの種のあらゆるものをユーザー入力で使用します。
WebにアクセスしたくないファイルをWebアクセス可能なディレクトリに入れないでください。

OWASPページで読むことができるものはたくさんあります。

score 12 · Accepted Answer

phpBBのかなり面白いものを覚えています。自動ログインCookieには、userIdと暗号化されたパスワード（ソルトなし）を含むシリアル化された配列が含まれていました。パスワードを値trueのブール値に変更すると、希望するユーザーとしてログインできます。弱く型付けされた言語が好きではありませんか？

phpBBが抱えていたもう1つの問題は、コールバック（を使用）を持つ検索キーワードを強調表示するための正規表現にありましたe modifier。これにより、独自のPHPコードを実行できます。たとえば、安全でないシステムでのシステムコールや、構成ファイルを次のように出力するだけです。 MySQLのログイン/パスワードを取得します。

したがって、この話を要約すると、

PHPがweaktypedであることに注意してください（md5( "secretpass" ) == true）。
コールバック（さらに悪いことに、eval）で使用される可能性のあるすべてのコードに注意してください。

そしてもちろん、私の前にすでに述べた他の問題があります。

score 3 · Accepted Answer

CMSが対処しているのを見たもう1つのアプリケーションレベルのセキュリティ問題は、ページまたは機能レベルのアクセスを十分に許可していないことです。つまり、セキュリティは、リンクの表示が許可されている場合にのみリンクを表示することによって設定されますが、ユーザーアカウントがページの表示またはページに表示された後の機能の使用が許可されていることを完全にはチェックしません。

つまり、管理者アカウントには、ユーザー管理ページに移動するためのリンクが表示されます。ただし、ユーザー管理ページは、ユーザーがログインしていることだけを確認し、ユーザーがログインして管理していることは確認しません。次に、通常のユーザーがログインし、管理ページURIを手動で入力すると、ユーザー管理ページへの完全な管理アクセス権が付与され、自分のアカウントが管理者アカウントになります。

ユーザーのCCデータが表示されるショッピングカートアプリケーションでも、このようなことを何度も目にしたことに驚かれることでしょう。

score 3 · Accepted Answer

とてもたくさん..

ここでの回答の多くは、彼らが覚えている特定の脆弱性または一般的な「Webアプリを作成するときに心配すること」をリストしていますが、過去に見つかった報告された脆弱性の大部分の合理的に信頼できるリストが必要な場合は、NationalVulnerabilityDatabaseを検索するには

JoomlaまたはJoomlaアドオンで報告されている脆弱性は582件あり、Wordpressでは199件、Drupalでは345件です。

一般的なWebアプリケーションの脆弱性を一般的に理解するために、OWASPトップテンプロジェクトが最近更新されており、Web開発者にとって必読です。

A1：注射
A2：クロスサイトスクリプティング（XSS）
A3：壊れた認証とセッション管理
A4：安全でない直接オブジェクト参照
A5：クロスサイトリクエストフォージェリ（CSRF）
A6：セキュリティの設定ミス
A7：安全でない暗号化ストレージ
A8：URLアクセスの制限に失敗しました
A9：不十分なトランスポート層保護
A10：未検証のリダイレクトと転送

score 3 · Accepted Answer

多くの人が忘れているか気付いていないように見える最大の問題は、Cookieやセッションなど、誰でもスクリプトにデータを投稿できることです。ユーザーがログインしているからといって、それが彼らを意味するわけではないことを忘れないでください。任意のアクションを実行できます。

たとえば、コメントの追加/編集を処理するスクリプトがある場合、次のようになります。

if ( userIsLoggedIn() ) {
    saveComment( $_POST['commentid'], $_POST['commenttext'] )
}

何が悪いのかわかりますか？ユーザーがログインしていることを確認しましたが、ユーザーがコメントを所有しているかどうか、またはコメントを編集できるかどうかは確認していません。つまり、ログインしているユーザーなら誰でもコメントIDとコンテンツを投稿したり、他のユーザーのコメントを編集したりできます。

他の人にソフトウェアを提供するときに覚えておくべきもう1つのことは、サーバーのセットアップが大きく異なることです。データが投稿されたときに、これを実行することができます。次に例を示します。

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];

score 2 · Accepted Answer

私の心の中で4つの大きなもの：

信頼できないデータ/コード（または一般的に）でexecを使用する
ローカル実行のためにリモートURLからファイルを含める
レジスタグローバルを有効にして、get変数とpost変数が自動的に割り当てられた変数値を取得できるようにします。
データベースに入力されたデータをエスケープしない/SQLインジェクション攻撃を許可する（通常、DB APIレイヤーを使用していない場合に発生します）

score 1 · Accepted Answer

他のドメイン/IPからのPOSTを禁止するため、ボットはフォームにログイン/送信できません。

score 0 · Accepted Answer

最大のセキュリティ違反である人々は、人間の 愚かさです。信頼、レビューコード。アプリケーションに追加コードとして追加されたものをすべて確認する特別なチームが必要です。cmsの問題は、アウトソーシング、着信、WordPress、Drupal、Joomla、およびデフォルトのインストールのような他の人気のあるcmsです。安全な良い点。問題は、適切なレビューなしに（または、侵入テストなしで）アプリケーションにコードを追加するように人々に任せるときに発生します。これは、WordPressとJoomlaに弱点があり、プラグインとテーマの開発者が非常に多く、承認が非常に多く、古いプラグインとテーマが何百もあるという点です。、優れたセキュリティ計画、貢献者をトレーニングし、安全なコーディング方法を学び、私の前に他のすべてのコメントを付けて、次のように言うことができます：ei hi that's my cms、

score -2 · Accepted Answer

特にフォーラム管理者にとっての潜在的な落とし穴がありますが、ドロップダウンセレクターを使用してフォームをコード化するが、投稿された応答が実際に利用可能なオプションの1つであるかどうかを検証しない人もいます。

大学では、phpBBのユーザーの「国」セレクターにはそのような検証がないことに気づきました。

私たちの学校のフォーラムでは、「米国」や「アフガニスタン」の代わりに、私の国は、どんなに愚かで不潔であっても、何でもあり得ます。必要なのはhtmlPOSTフォームだけでした。クラスメートが私がどのようにそれをしたかを理解するのに数日かかりましたが、すぐに、すべての「クールな子供たち」は、ユーザー名の下に表示された国ではなく、面白いフレーズを持っていました。

オタク大学に行くのは最高でした。：D

php - 人気のあるPHPCMSの歴史的なセキュリティ上の欠陥？

9 に答える 9

クロスサイトリクエストフォージェリ（CSRF）

説明 ：

それを防ぐ方法：

CMSの例：

詳しくは ：

不正なパスワードの保存

説明 ：

それを防ぐ方法：

CMSの例：

詳しくは ：

クロスサイトスクリプティング（XSS）

説明

それを防ぐ方法

CMSの例：

詳しくは ：

メールヘッダーインジェクション

説明 ：

それを防ぐ方法：

CMSの例：

詳しくは ：

SQLインジェクション

説明 ：

それを防ぐ方法：

CMSの例：

詳しくは ：

Http応答の分割

説明 ：

それを防ぐ方法：

CMSの例：

詳しくは ：

セッションハイジャック

説明 ：

それを防ぐ方法：

CMSの例：

詳しくは ：

他の

Related

Reference

説明：

詳しくは：

説明：

詳しくは：

詳しくは：

説明：

詳しくは：

説明：

詳しくは：

説明：

詳しくは：

説明：

詳しくは：