重要と認識されているが、PUBLICでアクセスできるパッケージ。OWA_*、DBMS_*およびUTL_*パッケージなど。URLに特殊文字を含むプロシージャ名。mod_plsqlを使用して直接実行されないように、特定のパッケージへのアクセスを明示的に拒否するこのデフォルト・モデルは、適切に設計されたPL/SQLアプリケーションの大部分に対しては十分です。このレベルのセキュリティがPL/SQLアプリケーションには不十分である場合は、次の方法を1つ以上使用して、PL/SQLアプリケーションを確実に保護することをお薦めします。mod_plsqlでのPlsqlRequestValidationFunctionディレクティブの定義mod_plsqlには、PlsqlRequestValidationFunctionというDADパラメータ・ディレクティブが用意されています。このディレクティブを使用すると、リクエストされたプロシージャのそれ以上の処理を許可または禁止できます。このディレクティブは、DADからの実行を禁止されたパッケージまたはプロシージャ・コールをブロックして、PL/SQLアプリケーションについて厳重なセキュリティを実装する場合に役立ちます。このパラメータによって定義されるファンクションには、次のプロトタイプが必要です。varchar2)起動時には、引数procedure_nameに、リクエストで実行しようとしているプロシージャの名前が含まれます。ブラウザからコールできるすべてのPL/SQLアプリケーション・プロシージャがパッケージmypkg内にある場合、このファンクションの実装は例2-1に示すような単純なものになります。ヒント:アプリケーションに属し、ブラウザからコールできるリクエストのみを許可するように、このファンクションを実装することをお薦めします。このファンクションは、すべてのリクエストについてコールされるため、必ずこのファンクションのパフォーマンスを高くしてください。次のような推奨事項があります。Webからアクセスできるすべてのプロシージャが既知のパッケージの小さなセットに属すように、また、これらのパッケージがWebブラウザから直接アクセスできないプロシージャを定義しないように、PL/SQLパッケージに名前を付けます。正しいネーミング規則を使用した検証ファンクションの実装は例2-1のようになります。実装で表検索を実行し、実行が許可されるパッケージまたはプロシージャを特定する場合、共有プールにカーソルを留めると、パフォーマンスがさらに改善されることがあります。mod_plsqlでのPlsqlExclusionListディレクティブへのルールの追加mod_plsqlには、PlsqlExclusionListというDAD設定パラメータが用意されています。このパラメータを使用すると、特定のパターンを持つプロシージャをブラウザURLから直接実行することを禁止できます。指定されるパターンには大/小文字の区別はなく、任意の文字の組合せが0回以上発生することを示すワイルドカード・パターンの「*」を使用できます。ダイレクトURLからアクセスできないデフォルトのパターンは、sys.*、dbms_*、utl_*、owa_util.*、owa_*、ctxsys.*、mdsys.*、htp.*およびhtf.*です。(10.1.2)からは、ユーザーがPlsqlExclusionListを使用して追加ルールを構成していても、デフォルトの組込み除外リストは引き続き有効です。以前のバージョンでは、PlsqlExclusionListディレクティブがDAD設定でオーバーライドされると、デフォルト設定は適用されませんでした。(')、バックスラッシュ(\)などの特殊文字を含むURLも却下されます。このディレクティブは、1つ以上の除外されたパッケージに作成された可能性があるデータベース・シノニムからの保護を提供しません。シノニムが存在し、脆弱である場合は、そのシノニムを除外されるパターンのリストに明示的に追加する必要があります。Server管理者ガイド』の「mod_plsql」を参照してください。注意:PlsqlExclusionListディレクティブを#NONE#に設定すると、すべての保護が無効になるため、アクティブなWebサイトには使用しないでください。dads.confというmod_plsqlの構成ファイルに、PlsqlExclusionListディレクティブを設定できます。この設定ファイルは、次のディレクトリにあります。Serverをインストールした場所です。PUBLICに付与されるユーザー定義のPL/SQLプロシージャに対して最適なセキュリティを確保するには、例2-2に示すように、PlsqlExclusionListディレクティブを使用してユーザー設定をdads.confファイルに指定します。Server管理者ガイド』を参照してください。カスタム認証でのAUTHORIZEプロシージャの使用カスタム認証を使用するアプリケーションでは、AUTHORIZEプロシージャの実装で制限付きパッケージまたはプロシージャへのアクセスを拒否できます。データベース表の保護アプリケーション・オブジェクト(表およびプロシージャ)を含むスキーマを、mod_plsqlの実行対象であるスキーマと区別することが役に立つ場合があります。このようにすると、mod_plsqlがユーザーとして接続するとき、そのユーザーに付与されたAPI以外を経由して、表およびその他のデータベース・オブジェクトに直接アクセスすることを禁止できます。シノニムを使用すると、スキーマ接頭辞を付けなくてもプロシージャは実行可能になります。SQLインジェクションからのデータベースの保護SQLインジェクション攻撃は、悪質なユーザーがバックエンド・データベースに対して実行されているSQLコマンドを変更できる場合に発生します。変更内容には、追加のデータを読み取ること、失敗するはずの妥当性チェックを成功させること、レコードを書き込むこと、またはその他の方法でアプリケーションの円滑な実行に影響を与えることなどがあります。多くのアプリケーションがデータベース上に構築されており、通常、ユーザー入力がデータベース問合せの一部として使用されています。アプリケーションのコーディングが慎重に行われていない場合、入力内容を注意深く構成することで、データベースに送信される問合せを変更できることがあります。このようなSQLインジェクション攻撃を回避するには、ユーザーの入力によって作成される動的SQLを可能なかぎり使用しないようにします。動的SQLにユーザー入力を使用する必要がある場合には、動的SQLで使用する前に、アプリケーション側で入力内容を適切にフィルタ処理する必要があります。ユーザーが入力パラメータとして表の名前を入力する場合、基礎となるアプリケーション・コードで、このパラメータに使用できる値が有効な表の名前のみとなるようにする必要があります。Serverから提供される認証レベルに加えて、様々な認証レベルを提供します。Webアプリケーションを実行するユーザーを保護します。表2-1に示すように、様々な認証モードを有効化できます。mod_plsqlで使用する認証モード認証モードアプローチBasicHTTPのBasic認証を使用して認証が実行されます。ほとんどのアプリケーションでは、Basic認証が使用されます。Toolkitパッケージを含むスキーマのowa_custom.authorizeプロシージャを使用して実行されます。カスタムOWA認証は、ユーザーのスキーマ(owa_customize.authorize)にあるパッケージとプロシージャを使用して実行されます。Toolkitパッケージを含むスキーマのパッケージとプロシージャが使用されます。認証は、ユーザーのスキーマ(packageName.authorize)にあるパッケージとプロシージャを使用して実行されます。Sign-Onを使用して実行されます。Serverで動作する場合のみです。Basic(データベース制御認証)モジュールmod_plsqlは、データベース・レベルでの認証をサポートしています。Basic認証が使用されますが、この方式を使用してデータベースへのログオンを試行することで資格証明が認証されます。認証は、次のどちらかのユーザー名とパスワードを使用して、ユーザーのデータベース・アカウントと比較検証されます。DADに格納されているユーザー名とパスワード。エンド・ユーザーがログインする必要はありません。この方法は、公開情報を提供するWebページに便利です。Basic認証ダイアログ・ボックスを使用して入力するユーザー名とパスワード。ユーザーは、このダイアログ・ボックスにユーザー名とパスワードを入力する必要があります。Serverでは、Basic認証モードの仕組みが異なります。ユーザー名およびパスワードはDADに格納する必要があります。Basic認証を使用します。認証は、そのファイルに指定されているユーザーと比較検証されます。Basic認証モードmod_plsqlは、Basic認証をサポートしています。Serverでは、ユーザーの資格証明をファイル・システム上のパスワード・ファイルと照合して認証します。この機能は、mod_authというモジュールによって提供されます。グローバルOWA、カスタムOWAおよびパッケージ別(カスタム認証)カスタム認証を使用すると、データベース・レベルではなくアプリケーション自体でユーザーを認証できます。認証は、ユーザー記述の認証ファンクションをコールすることで実行されます。カスタム認証は、OWA_CUSTOMを使用して行われ、動的ユーザー名/パスワード認証とは組み合せることができません。カスタム認証には、DAD設定ファイルに格納されている静的ユーザー名/パスワードが必要です。mod_plsqlは、このDADユーザー名/パスワードを使用してデータベースにログインします。mod_plsqlはログインすると、アプリケーション・レベルのPL/SQLフックをコールして、認証コントロールをアプリケーションに戻します。このコールバック・ファンクションは、アプリケーション開発者によって実装されます。コールバック・ファンクションの戻り値により、認証の成功または失敗が決まります。値TRUEは成功を意味し、FALSEは失敗を意味します。必要なカスタム認証の種類に応じて、認証ファンクションは様々な場所に配置できます。グローバルOWAの場合は、すべてのユーザーおよびプロシージャに対して同じ認証ファンクションをコールできます。カスタムOWAの場合は、各ユーザーおよびすべてのプロシージャに対して異なる認証ファンクションをコールできます。パッケージ別認証を使用すると、特定のパッケージのプロシージャまたは匿名プロシージャについてのみ、すべてのユーザーに対して認証ファンクションを実行できます。カスタムOWAを使用している場合、認証ファンクションは、ユーザーがパスワードwelcomeのユーザーguestとしてログインしているかどうかを確認できます。ユーザーのIPアドレスをチェックしてアクセス権を判別できます。表2-2にパラメータ値を示します。カスタム認証モードとコールバック・ファンクションモードアクセス制御の有効範囲コールバック・ファンクショングローバルOWAすべてのパッケージOWAパッケージ・スキーマ内のowa_custom.authorize。カスタムOWAすべてのパッケージユーザーのスキーマ内、または見つからない場合はOWAパッケージ・スキーマ内のowa_custom.authorize。指定したパッケージユーザーのスキーマ内のpackageName.authorize。anonymous.authorizeがコールされます。動的認証(DADにユーザー名とパスワードなし)を使用するDADの場合、mod_plsqlではPL/SQLプロシージャを介してユーザーをプログラム的にログオフ(HTTP認証情報を消去)させることができ、すべてのブラウザ・インスタンスを終了する必要はありません。Explorerでサポートされます。他のブラウザの場合、ユーザーが認証を解除するにはブラウザの終了操作が必要になることがあります。ログアウトをシミュレートしてユーザーをサインオフ・ページにリダイレクトする独自のログアウト・プロシージャを作成すると、認証解除をプログラム的に実行できます。MyLogOffProcプロシージャを次のように作成または置き換えます。htp.p('<BR>bye');END;もう1つの認証解除方法は、URLのDADの後に/logmeoffを追加することです。reserved.法律上の。