安全なJoomla拡張機能を開発する方法は？

最初の拡張機能を作成する前に、できる限り脆弱でないように設計する方法を理解したいと思います。

安全なJoomla拡張機能を作成するための一連のルールはありますか？

私はSQLインジェクションだけが脅威の可能性があると想像できるので、フォームの入力をそのままSQLコマンドに直接挿入することはできません。

カスタムモジュールまたはプラグインを作成するときに注意する必要のある他の攻撃ベクトルは何ですか？

あなたが指摘した主なものの1つはSQLインジェクションです。これは、私が見たいくつかの人々が完全に見落とし、非 Joomlaコーディング標準を使用して開発を開始し、mysql_*コマンドを使用してSQLクエリを書き始めることの1つです。

1つ目のポイントで述べた2番目のことは、常にJoomlaコーディング標準に固執することです。Joomlaが代替手段を提供しない場合は、あなたがすべきでない唯一の時です。

3番目に、拡張機能がフォルダーまたはファイルを作成する場合は、それらに正しいアクセス許可を与え、フォルダーchmod 777の作成を開始しないようにします。これが、最も人気のある拡張機能の1つであるK2が脆弱であると見なされた正確な理由です一時的にJEDから削除されました。

常にフォームでトークンを使用します。これにより、他のサイトからの不正な攻撃が実行されないことが保証されます。これに関する詳細については、以下をご覧ください。

http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms

すでにいくつかのテストが実行されているかどうかわからない場合は、コードレビューStackexchangeを試してみてください。誰かがコードをチェックしてくれる可能性があるためです。

できることの1つは、脆弱な拡張機能リストを見て、安全でないために一時的に（修正されるまで）Joomla拡張機能ディレクトリから削除された拡張機能を確認することです。

これがあなたの最初の拡張機能に少しの洞察と幸運を与えることを願っています

公式ドキュメントに続いて、安全なコーディングのガイドラインに関するいくつかの手順を示します。

• リクエストから取得したデータを検証します（POST、GET、COOKIESなど）。ユーザーを信頼せず、できるだけ厳格にしてください。が必要な場合は、の受け入れをinteger許可しないでくださいstring。

• ファイルのアップロード -可能であれば、公開Webページでファイルを受け入れることは避けてください。ファイルのメタ情報を検証し、考えられるすべてのチェックを行う必要がある場合。

• SQLクエリの構築-SQLインジェクションの仕組みだけでなく、データベースエラーの処理方法も理解します。表示するエラーが多いほど、データベース構造についての情報が多くなります。理想的にはエラーをログに記録しますが、表示はしません。

• トークンを使用してフォームを保護する

ほとんどの拡張機能でほとんど安全ですが、ファイルの保存/編集が必要になる可能性がある場合は十分に注意してください。不適切なフィルタリングや検証により、エントリポイントが作成される可能性があります。

JDatabaseのAPIを正しく使用している限り、SQLインジェクションからも安全である必要があります。Joomlaのインストールを調べcom_contentたりplg_system_loadpositon、Joomlaのインストールを調べたりすると、さまざまなJoomla APIの細かい点のいくつかを理解するのに役立ちます（ドキュメントを理解するのが少し難しいため）。

また、APIを使用して失敗し、何らかの脆弱性が使用された場合、修正はおそらくコアアップデートになるでしょう（そのJDatabaseの場合、Joomlaのリリースが発見されれば、1時間以内にリリースを想像できます）。アップデートではありません。あなたの拡張子に。

これはオープンソースの大きな欠点の1つであり、害を及ぼすつもりのある人はだれでも、そうするために必要なすべての情報を持っています。クローズドエクステンション（公開されていない）である場合、問題が発生することはありません。

最後に、拡張機能がシンプルであるほど（コードが少ないほど）、それは「不死身」になる可能性が高くなります。エクステンションが大きくなると、エントリポイントを作成するためにわずかなミスが発生する可能性のある場所がさらに多くなります。