安全なJoomla拡張機能を開発する方法は？
最初の拡張機能を作成する前に、できる限り脆弱でないように設計する方法を理解したいと思います。
安全なJoomla拡張機能を作成するための一連のルールはありますか？
私は SQLインジェクション のみが脅威であると想像できるので、フォーム入力を「そのまま」SQLコマンドに直接挿入することはできません。
カスタムモジュールまたはプラグインを作成するときに注意する必要のある他の攻撃ベクトルは何ですか？
あなたが指摘した主なものの1つはSQLインジェクションです。これは、私が見たいくつかの人が完全に見落とし、nonJoomlaコーディング標準を使用して開発を開始し、_mysql_*_コマンド。
1つ目のポイントで述べた2番目のことは、常にJoomlaコーディング標準に固執することです。 Joomlaが代替手段を提供しない場合は、あなたがすべきでない唯一の時です。
3番目に、拡張機能がフォルダーまたはファイルを作成する場合は、それらに正しい権限を与え、フォルダーchmod 777の作成を開始しないようにします。これが、最も人気のある拡張機能の1つであるK2が脆弱であると見なされた正確な理由ですそして一時的にJEDから削除されました。
常にフォームでトークンを使用します。これにより、他のサイトからの不正な攻撃が実行されないことが保証されます。これに関する詳細については、以下をご覧ください。
http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms
すでにいくつかのテストが実行されているかどうかわからない場合は、 Code Review Stackexchange に移動してみてください。コードをチェックしてくれる人がいるかもしれません。
あなたができることの1つは、安全でないために一時的に（修正されるまで）Joomla拡張機能ディレクトリから削除された拡張機能を確認するために Vulnerable Extensions List を確認することです。
これがあなたの最初の拡張機能に少しの洞察と幸運を与えることを願っています
公式ドキュメントに続いて、トピックのいくつかの手順を示します 安全なコーディングガイドライン ：
リクエストから取得したデータを検証します（POST、GET、COOKIESなど）。ユーザーを信頼せず、できるだけ厳格にしてください。
integerが必要な場合は、stringの受け入れを許可しないでください。ファイルのアップロード-公開ウェブページでファイルを受け入れることは可能な限り避けてください。ファイルのメタ情報を検証し、すべての可能なチェックを行う必要がある場合。
SQLクエリの構築-SQLインジェクションの仕組みだけでなく、データベースエラーの処理方法も理解します。表示するエラーが多いほど、データベース構造についての情報が多くなります。理想的には、エラーをログに記録しますが、表示はしません。
トークンを使用してフォームを保護する
ほとんどの拡張機能でほとんど安全ですが、ファイルの保存/編集が必要になる可能性がある場合は十分に注意してください。不適切なフィルタリングや検証により、エントリポイントが作成される可能性があります。
JDatabaseのAPIを正しく使用している限り、SQLインジェクションからも安全である必要があります。 Joomlaのインストールでcom_contentまたはplg_system_loadpositonを調べると、さまざまなJoomla APIの細かい点のいくつかを理解するのに役立ちます（ドキュメントを理解するのが少し難しいため）。
また、APIを使用して失敗し、何らかの脆弱性が使用された場合、修正はおそらくコアアップデートになるでしょう（そのJDatabaseの場合、発見がDであれば、1時間以内にJoomlaのリリースを想像できます）。アップデートではありません。あなたの拡張子に。
これはオープンソースの大きな欠点の1つであり、害を与えようとする人は誰でも、そうするために必要なすべての情報を持っているということです。クローズドエクステンション（公開されていない）である場合、問題が発生することはありません。
最後に、拡張機能がシンプルであるほど（コードが少ないほど）、それは「不死身」になる可能性が高くなります。エクステンションが大きくなると、エントリポイントを作成するときに少しの間違いが発生する可能性のある場所がさらに多くなります。