oracle application...

Oracle Application Express のベスト・

プラクティス

Oracle ホワイト・ペーパー 2006 年 1 月

Oracle Application Express のベスト・プラクティス

概要 ...................................................................................................................... 3 アプリケーション開発の目的........................................................................... 3 開発 ...................................................................................................................... 4

データベース設計......................................................................................... 4 整合性制約の実施 ................................................................................... 4 主キーへの入力 ....................................................................................... 4

開発の生産性................................................................................................. 5 UI のデフォルト値 .................................................................................. 5 よく使用される文字列の間接参照 ....................................................... 5 ページ・コンポーネントの再利用 ....................................................... 5 ウィザードの有効利用 ........................................................................... 6 エラーと例外の対応 ............................................................................... 6

デプロイメント .................................................................................................. 7 作業領域の整理............................................................................................. 7 アプリケーションのデプロイ ..................................................................... 7

データベース・オブジェクトの管理 ................................................... 8 静的ファイルの管理 ............................................................................... 8 アプリケーションの移植 ....................................................................... 9

ユーザー・インタフェースの整合性と有用性............................................. 10 データとアプリケーション・ロジックからのスタイルとレイアウトの分離....................................................................................... 10 複数アプリケーション間のユーザー・インタフェースの整合性の維持............................................................................................... 11

セキュリティ .................................................................................................... 12 セキュリティはデータベースから ........................................................... 12 ユーザーの管理........................................................................................... 12 URL の改ざん.............................................................................................. 13 クロス・サイト・スクリプティング ....................................................... 14 SQL インジェクション攻撃からの保護 .................................................. 15 レポート列の保護....................................................................................... 16

パフォーマンス ................................................................................................ 17 バインド変数の使用................................................................................... 17 ページ区切りスタイルの適切な選択 ....................................................... 19 可能な場合の宣言ロジックの使用 ........................................................... 19 リダイレクトの使用................................................................................... 19

結論 .................................................................................................................... 20


2

Oracle Corporation 発行「Oracle Application Express Best Practices」の翻訳版です。


概要 Oracle Application Express は、Oracle データベースで迅速に Web アプリケーション

を開発するツールです。このホワイト・ペーパーでは、Oracle Application Expressによるアプリケーションの開発とデプロイメントに関する一連のベスト・プラク

ティスを説明します。

アプリケーション開発の目的 Web アプリケーションの成功をもたらす特性は、多数あります。以下の特性を備

えたアプリケーションは、成功の可能性が高くなります。

• 開発が容易

• デプロイが容易

• 保守が容易

• 使いやすい

• 高速

• 安全性が高い

このホワイト・ペーパーでは、これらの特性を持つアプリケーションの開発のガ

イドラインを提供します。このホワイト・ペーパーの内容を絶対的な基準として

使用しないでください。これらの基準は、本番環境の Oracle Application Expressアプリケーションの開発と実行の経験に基づいた推奨事項およびベスト・プラク

ティスとして使用してください。


3


開発 Oracle Application Express は、数時間で（時には数分で）Oracle データベース上に

完全に運用できるレポート・アプリケーションおよびデータ入力アプリケーショ

ンを構築してデプロイできる生産性の高いツールです。柔軟性が高いので、多く

の場合、同じ目的を達成する複数の方法があります。この項の推奨事項によって、

も効率的な方法で目的を達成できます。

データベース設計

整合性制約の実施

適切なデータベース設計を行っていないリレーショナル・データベースに基づい

たアプリケーションの構築は不可能ではありませんが困難です。適切なデータベース

設計には、データの整合性と論理の健全性を保証するための参照整合性制約と一

意性制約が含まれます。アプリケーションで実施されている検証または参照整合

性規則が十分だと思っている場合でも、他の方法によるデータベースへのアクセ

スがないことを保証できないことがよくあります。データベース設計の徹底的な

調査はこのホワイト・ペーパーの範囲外ですが、データの正確性と整合性を保つ

ためにデータベースの固有の機能を活用することを推奨します。必要に応じて、

主キー、外部キー、NOT NULL 制約、チェック制約を使用してください。

主キーの入力

Oracle Application Express には、データベース表のデータ入力フォームを作成する

ウィザードがあります。このウィザードは、挿入、更新、および削除機能を実現

するために必要なすべての UI コントロールとプロセスを作成します。このフォー

ム・ウィザードと生成される自動 DML プロセスを使用している場合、データベー

ス・トリガーとシーケンスを使用して主キー列に入力すると便利です。たとえば、

主キー列 ID とシーケンス MYSEQ を使用した表 T の場合、次のようにトリガー

MY_TRIGGER を作成できます。

create or replace trigger MY_TRIGGER before

insert on T for each row

begin

if ( :new.ID is NULL ) then

select MYSEQ.nextval

into :new.ID

from dual;

end if;

end;


4


開発の生産性

UI のデフォルト値

Oracle Application Express の UI（ユーザー・インタフェース）のデフォルト値によっ

て、特定のスキーマ内の表、列、またはビューにデフォルトのユーザー・インタフェー

ス・プロパティを割り当てることができます。これらの UI プロパティは、フィール

ド・ラベル、フォーマット・マスク、列ヘッダー、列の位置合せなどのスクリー

ン要素に使用されます。ウィザードを使用してフォームやレポートを作成する場

合、領域や項目のプロパティのデフォルト値はこの情報を使用して作成されます。

あらかじめ UI のデフォルト値をカスタマイズすると、UI プロパティの多くの細

かな調整が不要になるため、開発中の時間を節約できます。

よく使用される文字列の間接参照

アプリケーションの開発中または開発後に変更される可能性のある文字列をアプ

リケーションが頻繁に参照する場合は、置換文字列を使用してください。置換文

字列は、アプリケーション・レベルで定義される静的変数です。これらの変数の

値は、&STRING_NAME の構文でアプリケーションのどこからでも参照できます。

たとえば、変更される可能性のある製品名をアプリケーションが頻繁に参照する

場合、置換文字列 PRODUCT_NAME を定義して、次のように参照できます。

Welcome to the &PRODUCT_NAME. store!

置換文字列を正しく使用すれば、製品名が変更されるたびに 1 個所を変更するだ

けで済みます。

ページ・コンポーネントの再利用

静的 HTML の領域やリストなどのページ・コンポーネントがアプリケーション内

の複数のページに表示される必要がある場合、ページ 0 の使用を検討してくださ

い。ページ 0 は、エンド・ユーザーによって直接実行されないアプリケーション

のページです。ただし、このアプリケーションのコンポーネントは、エンジンに

よる各ページ・ビューへのレンダリングに使用されます。ページ 0 に配置される

コンポーネントは、条件を使用して他のページから選択的に除外できます。


5


ウィザードの有効利用

Oracle Application Express には、フル機能のアプリケーション・コンポーネントを

生成する複数のウィザードがあり、手動で構築する場合に比べて大幅に時間を節

約できます。Oracle Application Express が他と異なる点は、ウィザードを使用して

も制御や柔軟性を損なわない点です。コンポーネントおよびコントロールは自動

的に生成されますが、いつでも表示や動作を変更できます。挿入、更新、および

削除処理を実現するフル機能のフォームを提供する以外に、コミット時ロックを

通じて失われた更新を検出できるため、表にフォームを作成するウィザードが特

に役立ちます。

開発プロセスを短縮できる他のウィザードには、クイック・アプリケーション・

ウィザードとウィザード作成ウィザードがあります。クイック・アプリケーショ

ン・ウィザードは、単一のデータベース表に、データ入力レポートの作成と分析

を完備したアプリケーションを生成します。複数ページのデータ収集ユーザー・

インタフェースのウィザードを生成するため、"wizard wizard"はこのような名前が

付けられています。このウィザードは、「Next」ボタンや「Previous」ボタンでペー

ジ間を移動するため、フォーム・フィールド、コントロール、およびページ・フ

ローを備えた一連のページを生成します。

アプリケーション機能を初から構築する前に、Oracle Application Express で使用

可能なウィザードを試行することを強く推奨します。

エラーと例外の対応

一般的に、Oracle Application Express アプリケーションは、データベースのデータ

を挿入または更新する場合などに、無名ブロックまたはパッケージやストアド・

プロシージャで PL/SQL ロジックを実行します。呼び出される PL/SQL で例外が発生

する場合には、正常に対処する必要があります。アプリケーションのフローを損

なうことなくこのエラーをユーザーに通知するには、例外が発生したイベントの

Oracle Application Express 項目にエラー・メッセージを割り当てることを推奨しま

す。例外が発生したプロセスを呼び出しているページにこの項目を表示すること

ができます。また、条件分岐を使用して、エラーが発生したページに戻ることが

できます。これによって、変更を加えたりページを更新したりできます。

例：

ページ 5 には、MY_PROC というプロシージャによってデータベースに値が挿入

されるデータ入力フォームがあります。挿入に成功すると、ユーザーはページ 1に戻ります。エラーが発生すると、エラーを修正する機会がユーザーに与えられ

ます。ページ 5 にユーザー・フレンドリーなエラー・メッセージを表示するには、

P5_ERROR_MSG という項目を作成してください。送信後プロセスを次のように

定義します。


6


BEGIN

MY_PROC (:P5_ITEM1, :P5_ITEM2);

:P5_ERROR_MSG := null;

EXCEPTION when others then

:P5_ERROR_MSG := '挿入でエラーが発生しまし

た。値を修正して再度実行してください。';

END;

次のソースを使用して、ページ 5 の HTML 領域にエラー・メッセージを表示でき

ます。

&P5_ERROR_MSG

例外が発生しない場合、P5_ERROR_MSG は NULL なので、メッセージはページ

に表示されません。

後に、例外を引き起こしたエラーを修正する機会をユーザーに提供するため、

P5_ERROR_MSG の値が NULL 以外の場合はページ 5、NULL の場合はページ 1 に

分岐する条件分岐を作成してください。

デプロイメント

作業領域の整理

Oracle Application Express の作業領域を使用すると、1 つ以上のスキーマのデータ

ベース・オブジェクトに対して 1 人以上の開発者がアプリケーションを開発でき

ます。通常、相互に関連するアプリケーションを格納するために、作業領域を整

理する必要があります。相互に関連するアプリケーションとは、データとスキー

マの一般的なセットを使用する一般的な開発者のグループによって開発されるア

プリケーションです。

アプリケーションのデプロイ

Oracle Application Express では、アプリケーションは次のコンポーネントで構成されます。

• データベース・オブジェクト

• Oracle Application Express アプリケーションの定義

• イメージ（オプション）

• カスケーディング・スタイルシート（オプション）


7


開発に使用したデータベース以外のデータベースにアプリケーションをデプロイ

するには、アプリケーション定義とそれが依存するデータベース・オブジェクト

をデプロイする必要があります。オプションとして、イメージとカスケーディン

グ・スタイルシート（CSS）をデプロイできます。

アプリケーションの可用性の要件、ユーザー集団のサイズ、および他の要因に応

じて、開発環境と本番環境を区別するラインがどの程度厳密である必要があるか

を決定できます。特定のアプリケーションについては、アプリケーションが一時

的に使用できなくなったり停止したりすることをエンド・ユーザーが把握してい

る限り、開発サーバーと配置サーバーの結合が許容されています。

他のアプリケーションは、2 台のサーバー（開発用と本番用）または 3 台のサー

バー（開発用、テスト用、本番用）が必要になることがあります。Oracle Application Express では、アプリケーション定義のエクスポート機能およびインポート機能を

使用して、アプリケーションを環境間で移動することができます。

データベースとOracle Application Expressの実行に使用できるハードウェアが 1台だけの場合でも、個別のスキーマにアクセスする 2 つの作業領域を使用すること

によって、開発用と本番用のアプリケーションを区別できます。1 つの作業領域

を開発用に使用し、本番用にアプリケーションをデプロイするためにもう 1 つの

作業領域を使用します。

データベース・オブジェクトの管理

開発用とは別の作業領域またはスキーマにアプリケーションをデプロイする場合、

データベース・オブジェクトをアプリケーションと一緒に移動しなければならな

い場合があります。すべてのデータベース定義言語（DDL）の実行に Oracle Application Express を使用している場合、配置環境で変更を適用する 2 つのオプ

ションがあります。初のオプションは、SQL Workshop でスクリプトの DDL を

管理します。SQL Workshop を使用して、スクリプトの編集、作成、エクスポート、

およびインポートを行うことができます。SQL Workshop でスクリプトの DDL を

すべて取得すると、スクリプトをインポートして実行することによって、配置環

境にデータベース・オブジェクトをインストールできます。

2 番目のオプションは、SQL Workshop でも使用可能な DDL のエクスポート機能

を使用する方法です。この機能を使用すると、作成方法に関係なく、任意のスキー

マでのデータベース・オブジェクトのスクリプト形式で DDL をエクスポートでき

ます。これらのオブジェクトを本番用に再作成するには、生成されたスクリプト

をインポートするだけです。

静的ファイルの管理

Oracle Application Express アプリケーションは、カスケーディング・スタイルシー

ト（CSS）、イメージ、Javascript ライブラリなどの追加の外部ファイルを参照す

る場合があります。


8


これらのイメージは、Web サーバーを実行するサーバーのファイル・システムに

配置できます。また、Oracle Application Express の Application Builder でアップロー

ドされる場合、データベース内に保存できます。

Application Builderでデータベース内のイメージやCSSなどのファイルを管理する

利点は、ブラウザだけを使用して別の Oracle Application Express 環境や作業領域に

ファイルをエクスポートおよびインポートできることです。ただし、比較的イメー

ジが少ない場合や負荷の高いリクエストのスループットにアプリケーションが対

応できない場合のみ、データベースに関連ファイルを保存することを推奨します。

イメージ、CSS、Javascript ライブラリがデータベースに保存されると、ブラウザ

がこれらのいずれかのファイルをリクエストするたびにデータベース接続が確立

されます。ただし、高いスループットのアプリケーションでは、データベースに

過度の負荷がかかる場合があります。

アプリケーションの移植

アプリケーションを Oracle Application Express 環境間で簡単に移動できるように

するには、環境間で変更される可能性のある値に対するハードコードされた参照

を避ける必要があります。たとえば、アプリケーション ID は、アプリケーション

全体に渡って複数の URL で参照されることが多くあります。Oracle Application Express エンジンは、アプリケーション ID を使用して、アプリケーション・レポ

ジトリから取得および実行されるアプリケーションを一意に識別します。実際の

アプリケーション ID は使用されず、以下の URL で実行されます。

f?p=100:1:&APP_SESSION.:

代わりに以下の間接参照を使用することを推奨します。

f?p=&APP_ID.:1:&APP_SESSION.:

この&APP_ID. は、ハードコードされた値100を置き換える組込みの置換文字列

です。この技法を使用すると、アプリケーションIDが変更される場合でも、デプ

ロイ前にアプリケーションに変更を加える必要がなくなります。

同様に、円滑なデプロイメントを行うには、テンプレート、HTML領域、または

SQL問合せのイメージへの参照で、ハードコードされたパスの代わりに置換文字

列を使用する必要があります。たとえば、開発環境の仮想パス/dev/images/のファイル・システムにイメージが保存されるアプリケーションを想定してください。

アプリケーションが異なるサーバーに配置される場合、イメージは仮想パス

/prod/images/に保存されます。アプリケーション・レベルで定義される置換文

字列を使用すると、デプロイ前にアプリケーション全体に変更を加える必要がなくな

ります。たとえば、アプリケーション・レベルの置換文字列IMAGE_PATHを定義し、

/dev/images/の値を割り当ててから、問合せで次のように参照します。


9


SELECT '<img src="&IMAGE_PATH.edit_icon.gif" />' icon,

ename,

job

FROM emp

テンプレートのイメージを参照する場合にも、この方法を使用してください。た

とえば、ページ・テンプレートの Header セクションは、次のようになります。

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01

Transitional//EN">

<html>

<head>

#HEAD#

<link rel="stylesheet" href="&IMAGE_PATH.custom.css"

type="text/css">

<title>#TITLE#</title>

</head>

<body bgcolor="#FFFFFF" #ONLOAD#>#FORM_OPEN#

この例のcustom.cssは、ファイル・システムに保存されているカスケーディン

グ・スタイルシートです。この技法を使用すると、配置中にアプリケーション・

レベルの置換文字列IMAGE_PATHの値を変更するだけで済みます。

ユーザー・インタフェースの整合性と有用性

データとアプリケーション・ロジックからのスタイルと

レイアウトの分離

Oracle Application Express には、アプリケーションを素早く構築するために選択で

きる次のような豊富なコンポーネントがあります。

• レポート

• フォーム

• リスト

• ナビゲーション・バー


10


• メニュー

これらの各コンポーネントはテンプレートを使用してレンダリングされるので、

スタイルとは別の構造を定義できます。

スタイル、ロジック、データ・アクセス間を明確に区別するには、絶対に避けら

れない場合を除き、これらのコンポーネント固有の実装をプログラミングしない

でください。HTML をレンダリングするカスタム・コードを記述する代わりに、

HTML をレンダリングする組込みコンポーネントをできるだけ使用してください。

この方法によって、ロジックに影響を与えないで、アプリケーションのルック・

アンド・フィールをより変更しやすくなります。たとえば、Oracle Application Express のレポートは、SQL 問合せのフォーマット済み結果になります。ページ上

に EMP 表の ename 列を太字で表示する場合、次の問合せでレポートを作成できま

す。

SELECT '<strong>' || ename || '</strong>', job

FROM emp

マークアップを組み込まない問合せを使用し、その後結果セットに適用されるテ

ンプレートまたは HTML 式を使用して同じ目的を達成するのが効果的です。

Oracle Application Express の宣言的なコンポーネントを使用すると、いくつかの利

点があります。まず、スタイルとレイアウトを心配しないでアプリケーションの

内容を開発できます。レポートのフォーマットは、適切なレポート・テンプレー

トを適用して、後で追加できます。レポート・テンプレートは後で追加できます。

また、他の開発者が並行して設計することもできます。

複数アプリケーション間のユーザー・インタフェースの整合性の維持

組織では、すべてのイントラネット・アプリケーションまたはインターネット・

アプリケーションで表示を統一することが一般的です。複数のアプリケーション

で一貫性のあるルック・アンド・フィールを維持する必要がある場合は、テンプ

レート・サブスクリプションを使用してください。テンプレート・サブスクリプ

ションとは、中央で定義されるマスター・テンプレートへの参照です。良い方法

は、テンプレートのマスター・コピーを含む参照アプリケーションを定義するこ

とです。他のアプリケーションは、このようなマスター・コピーにテンプレート

をサブスクライブできます。マスター・テンプレートが更新されるたびに、マス

ター・コピーをサブスクライブしているテンプレートに変更を適用できます。


11


セキュリティ Web アプリケーションの保護は非常に困難な作業であり、それについてはこれま

で多くの文献が書かれてきました。以下の内容は、アプリケーションを保護する

方法のすべてではありませんが、よく取り上げられるセキュリティの問題に関す

るいくつかの推奨事項を示しています。

セキュリティはデータベースから

アプリケーションのみによるセキュリティとアクセス制御では不十分です。家の

玄関に優れた鍵を取り付けているからといっても、窓から侵入されて現金を盗ま

れる場合も考えられるので、安易にコーヒー・テーブルに大金は置きません。代

わりに、現金を金庫に保管します。

同様に、構築するアプリケーションは、データベースの基本となるデータにアク

セスする唯一の手段ではない場合があります。非定型のクエリー・ツールや直接

SQL*Plus アクセスなどの代替手段が考えられます。データベース・レベルで適切

なアクセス制御を構築すれば、データベース内のデータにアクセスする各アプリ

ケーションのセキュリティ・ポリシーを再実装する必要はなくなります。

データベースにセキュリティを実装するには、SQL および PL/SQL を解析するた

めに使用されるスキーマだけがアプリケーションに必須のデータにアクセスして

いることを確認してください。スキーマ A、B、C のすべてではなく一部のデータ

へのアクセスが必要な場合、スキーマ A、B、C の必要なオブジェクト上に定義さ

れたビューを持つ追加のスキーマ D の作成を検討してください。

問い合わせているユーザーに応じて表内の行へのアクセスを制限するには、Fine Grained Access Control（FGAC）を使用してください。仮想プライベート・データ

ベース（VPD）とも呼ばれる Fine Grained Access Control は、ポリシーに基づいて

表またはビュー内の行へのアクセスを制限するメカニズムです。これらのポリシー

は、アプリケーション・コンテキストに基づいて問合せの条件つまり WHERE 句

を変更します。アプリケーション・コンテキストを使用して、問合せを開始する

ユーザー、実行する時間、実行するアプリケーションの種類を決定できます。こ

れらのデータに基づき、使用できる適切なデータだけがユーザーに返されるよう

に WHERE 句を構築できます。

FGAC を使用する場合、セキュリティ・ポリシーは、1 つのデータベース・オブジェ

クトで一度定義するだけで済みます。基本となるデータベース・オブジェクトに

アクセスする各アプリケーションは、データベースからアクセス制御の制限を継承

します。アプリケーションで同じセキュリティを再実装する必要はありません。

ユーザーの管理

Oracle Application Express アプリケーションを構築およびデプロイする際に、エン

ド・ユーザーの資格証明を管理する場所と方法を選択できます。デフォルトでは、

エンド・ユーザーは、アプリケーションが含まれる作業領域のユーザーとして定

義されます。


12


大きなユーザー集団にデプロイする場合、Oracle Application Server で提供されるソ

リューションなどの LDAP サーバーやシングル・サインオン・インフラストラク

チャなどの外部 ID 管理ソリューションの使用を強く推奨します。ユーザー定義と

資格証明を常に組織で一元的に定義されるようにすると、エンド・ユーザーとア

プリケーション管理者のパスワード管理の負荷が軽減されます。アプリケーショ

ン管理者は、ユーザーのパスワードのリセットを頻繁に支援する必要がありませ

ん。エンド・ユーザーは、同じパスワードを複数のアプリケーションのログイン

に使用するため、記憶する必要のあるユーザー名とパスワードが少なくなります。

また、資格証明を一元的に管理すると、ユーザーが組織を離れる場合にすべての

アプリケーションのアクセスを取り消す処理が容易になります。

URL の改ざん

多くの場合、Oracle Application Express で開発されたアプリケーションを含む Webベースのアプリケーションは、URL でページ間の値を渡します。賢明なユーザー

は、この点に注意し、ブラウザのロケーション・フィールドに固有の値を入力し

て値を変更します。たとえば、従業員レコードを編集するフォームを表示するペー

ジの場合、特定の項目のセッション状態値によって、表示されるレコードが変わ

る場合があります。Oracle Application Express において、この項目のセッション状

態は、以下の文字列を含む URL に設定できます。

f?p=&APP_ID.:1:::::P1_EMPID:1234

アプリケーションIDは100、ページIDは1です。P1_EMPIDはセッション状態変数

で、1234は従業員表の主キーの値を表します。

ユーザーがこのリンクをクリックすると、ブラウザのロケーション・フィールド

に表示されます。この時点で、ユーザーは、次のような URL に変更して試行でき

ます。

f?p=&APP_ID.:1:::::P1_EMPID:5678

主キー値 5678 の従業員レコードを取得することを仮定しています。このユーザー

は、従業員 5678 の詳細の確認を許可される場合とされない場合があります。許可

されない場合は、このデータの参照を防止するために、できればデータベース・

レベルで、適切な認可規則をページのロジックに適用する必要があります。URLに渡される値を、エンコードまたは暗号化の形式で隠すだけでは十分ではありま

せん。

保護を強化するため、Oracle HTML DB 2.0 は、Session State Protection（セッション

状態の保護）という新機能を導入しました。Session State Protection（セッション状

態の保護）は、ハッカーによるアプリケーション内の URL の改ざんを防止する組

込み機能です。


13


クロス・サイト・スクリプティング

XSS とも呼ばれるクロス・サイト・スクリプティングは、動的に生成される Webページを利用したセキュリティ侵害です。XSS 攻撃では、Web アプリケーション

は、何の疑いもないユーザーのブラウザで読み込まれる際にアクティブ化するス

クリプトを使用して送信されます。このスクリプトによってデータやセッション

資格証明が抽出され、ハッカーに送信される可能性があります。アプリケーショ

ン開発者がこのような攻撃を行うことはまれですが、攻撃からの保護は開発者の

責任です。動的なWebサイトはユーザー入力に依存するため、悪意のあるユーザー

は、正当なリクエスト内に不正なスクリプトを隠すことで、不正なスクリプトを

ページに入力します。アプリケーションによる通常のユーザー入力を装った不正

なスクリプトの送信を開発者が防止しないと、通常のユーザーがスクリプトの攻

撃を受ける可能性があります。

これらの攻撃から保護するには、予期しない文字と不正な入力を検出するため、

すべてのユーザー入力を初にフィルタリングします。次に、コンテンツを無意

識に HTML またはスクリプトとしてレンダリングしないように、ブラウザに対す

るすべての出力をフィルタリングします。Oracle Application Express には、アプリ

ケーション・コンポーネントを作成する多くのウィザードがあります。アプリケー

ション・コンポーネント自体は、これらのセキュリティ問題にアプリケーション

を公開しません。ただし、追加機能とカスタム・コードでアプリケーションを拡

張する場合、入力された時からブラウザのレンダリングで出力される時まで、各

データ要素のエンドツーエンド分析を実行するなどして、引き続き注意する必要

があります。後者の例には、P1_ITEM というアプリケーション項目が次の文で

PL/SQL 動的コンテンツ領域のページに出力される場合があります。

htp.p(:P1_ITEM);

おそらくよくあることですが、何らかの内部アプリケーション・ロジックによっ

て確立されたP1_ITEMの値が次のURLを使用してハッカーによってページに導入

された場合、

f?p=APP:PAGE:::::P1_ITEM:<some malicious

javascript>

出力ページは、損害を与えるために不正なスクリプトをブラウザに送信します。

開発者は、このような可能性を認識し、ページで使用される出力をフィルタリングす

る必要があります。mod_plsql Webツールキットに装備されているhtf.escape_scな

どの関数の使用を推奨します。この関数は、<や&などのタグおよび文字をエンティ

ティ参照の<や&に変換します。例を以下に示します。


14


htp.p(htf.escape_sc(:P1_ITEM));

SQL インジェクション攻撃からの保護

SQLインジェクション攻撃とは、コードの欠陥を利用して未承認のSQLコマンド

を実行するデータベース駆動型のWebサイトに対する攻撃です。この種類の攻撃

を防止するには、アプリケーションによって実行されるSQL問合せに任意のユー

ザー入力を含めないでください。レポートのソースとして使用される次の無名ブ

ロックを検討してください。この問合せは、ユーザー入力に基づいて動的に作成

され、P1_USER_INPUTというOracle Application Express項目に保存されます。以

下のPL/SQLロジックに従ってユーザーが項目の値を設定すると、その値が問合せ

に追加されます。

DECLARE

q varchar2(4000);

BEGIN

q := 'SELECT ename, job, sal

FROM emp

WHERE deptno = 20 ';

IF :P1_USER_INPUT is not NULL then

q := q || :P1_USER_INPUT;

END IF;

return q;

END;

P1_USER_INPUTの値を"AND SAL < 2000"と仮定すると、実行される問合せは、

次のようになります。

SELECT ename, job, sal

FROM emp

WHERE deptno = 20 AND SAL < 2000


15


この問合せの結果には、給与が 2000 より低い部門 20 のすべての従業員の名前、

仕事の内容、および給与が含まれます。ユーザーが P1_USER_INPUT 項目に"OR 1=1"を入力すると、問合せは、次のようになります。

SELECT ename, job, sal

FROM emp

WHERE deptno = 20 OR 1=1

結果として、EMP 表のすべての内容が出力されます。基本となる表に一時的なフ

ルアクセスを許可する場合を除き、任意のユーザー入力をアプリケーションによっ

て実行される問合せに追加しないでください。代わりに、問合せの構造を詳細に

制御し、慎重にユーザー入力を組み込んでください。

レポート列の保護

Oracle Application Expressのレポートを定義して、ユーザー権限に基づき、ユーザー

ごとに異なる列を表示できます。認証スキームとは、アプリケーション全体の要

素に適用できる一元的に定義されるアクセス制御ルールです。アクセス制御ルー

ルは、SQL、PL/SQL、または組込み宣言ロジックで定義できます。たとえば、

PRIVILEGED_ USERS という認可されたユーザーに表を作成したと仮定すると、次のような EXISTS問合せに基づいて認証スキームを実装できます。

SELECT 1

FROM privileged_users

WHERE username = :APP_USER

この例では、セッション状態変数 APP_USER に自動的に保存される現在ログイン

しているユーザーの名前は、PRIVILEGED_USERS 表のすべてのエントリと比較さ

れます。認証スキームの定義方法は、一致する場合のみ、適用されるすべての要

素にアクセスを許可する方法です。

レポート列に適用される認証スキームを使用して、すべてのユーザーに対してレ

ポートを一度定義し、アクセス制御ルールを同時に施行できます。


16


パフォーマンス Oracle Application Express のアーキテクチャでは、ほとんどの処理がデータベース

内で発生します。Oracle Application Express エンジン自体は、プロセッサの速度に

もよりますがページ・リクエストごとのCPUの使用が0.04秒だけなので、オーバー

ヘッドをほとんど要しません。当然ながら、Oracle Application Express エンジンが

処理を行うレポートと指示の問合せがページに追加されるにしたがって、CPU タ

イムの要求が増えます。アプリケーションを開発する際にデータベースの負荷を

小限に抑える推奨事項を以下に示します。

バインド変数の使用

Oracle データベースでは SQL 問合せまたは PL/SQL コードの実行の前に、解析、

名前解決、セキュリティ・チェック、適化を含む一連の手順が実行されます。

同じ SQL または PL/SQL を頻繁に実行する場合にこれらの手順の不要な繰り返し

を避けるため、データベースは、コンパイル済みの SQL と PL/SQL を保存する共

有プールつまりライブラリ・キャッシュを使用します。問合せの実行中、データ

ベースは初にこのキャッシュを参照し、すでに実行されているかどうかと、再

利用できるバージョンがあるかどうかを確認します。問合せをできるだけ再利用

したい場合は、バインド変数を使用してください。バインド変数は、実行中に値

を割り当てる SQL または PL/SQL のプレースホルダーです。以下の SQL の例を検

討してください。

SELECT empno, sal

FROM emp

WHERE empno = 1234

この問合せを実行した後、領域が必要な場合にメモリーのこの部分をクリーンアップ

するエージング・ルーチンに従って、共有プールで再利用できます。当然ながら、

この特別な問合せは、完全に同じ問合せがアプリケーションで実行される場合の

み再利用できます。つまり、従業員番号（EMPNO）が 1234 の従業員の従業員番

号と給与を取得する問合せです。

ここで、バインド変数を使用した次の同じ SQL を検討してください。

SELECT empno, sal

FROM emp

WHERE empno = :empno


17


この問合せは、問合せの実行時に実際の値が割り当てられるので、任意の従業員

番号に対して再利用できます。

共有プールから問合せを確実に再利用できることは、データベース・アプリケー

ションのスケーラビリティにとって重要です。共有プールからコンパイル済みの

（そのまま実行できる）問合せを実行すると、一度も実行したことのない問合せを

実行するよりも、実行時間が短縮されます。結果として、同時実行性の実現に必

要なデータベースの貴重なリソースの使用が軽減されます。

Oracle Application Expressアプリケーションでどのように問合せの再利用を実現す

るかは SQL および PL/SQL のセッション状態から値を格納する場合、バインド変

数を使用します。原則的に、SQL と PL/SQL の置換文字列の使用は避けてくださ

い。以下の SQL 問合せを検討してください。

SELECT '<a href="f?p=100:1:&APP_SESSION.">edit</a>'

link,

empno, sal

FROM emp

適切で問題のないように初は見えますが、再利用のために適化された問合せ

ではありません。実際には、1 人のユーザーによって再利用されるだけです。こ

の問合せを実行する前に、Oracle Application Express は、&APP_SESSION の代わ

りに現在のユーザーのセッション識別子を使用します。データベースは、次のよ

うに問合せを確認します。

SELECT '<a href="f?p=&APP_ID.:1:9878768768759">edit</a>'

link,

empno, sal

FROM emp

9878768768759は固有のセッション識別子なので、上記の問合せは、セッショ

ンの所有者によって何度も実行される場合を除いて、一意の問合せです。この問

合せを作成する推奨方法は、以下のとおりです。

SELECT '<a href="f?p=&APP_ID.:1:'|| :APP_SESSION ||

'">edit</a>'

link,

empno, sal


18


FROM emp

このセッション識別子は、以前に実行された同じ問合せを共有プールからデータ

ベースが取得した後に割り当てられるバインド変数として参照されます。同じデー

タベースで実行される同じアプリケーションの複数のコピー（異なるアプリケー

ション ID を使用）が存在する場合を除いて常に同じ値なので、置換変数&APP_IDを使用しても問題ありません。

ページ区切りスタイルの適切な選択

Oracle Application Express で作成されるレポートを自動的に構成して、結果セット

を通じてページ区切りスタイルを使用できます。約 5,000 行の結果セットは、25行ごとのページに分割できます。さまざまなページ区切りスタイルがあります。

Next と Previous のリンクと現在表示されている行範囲を示す番号のみを使用する

スタイルや、特定の行範囲に移動できる選択リストを使用するスタイルがありま

す。

結果セットの正確な行数をユーザーが把握する必要のない場合は、あらかじめ結

果セットのサイズを計算しないページ区切りスタイルを使用してください。たと

えば、"Row Ranges X to Y"などのページ区切りスタイルを使用すると、貴重なデー

タベース・リソースを節約できます。

可能な場合の宣言ロジックの使用

Oracle Application Express は、多くの場所で開発者に対してカスタム・ロジックを

構築する機会を提供します。たとえば、レンダリングまたは処理に適用される条

件やフォーム入力の検証などです。開発者の生産性を高めてパフォーマンスを

適化するため、多くの事前に定義された条件タイプと検証が存在します。

これらの事前に定義されたロジック単位は、Oracle Application Express エンジンに

基本的に"焼付け"されるので、アプリケーションのパフォーマンスをできるだけ

向上させるには、これらのロジックの使用を強く推奨します。たとえば、ユーザー

入力が数値かどうかを検証する場合、固有の PL/SQL ロジックを記述して、検証

を実装します。事前に作成した"Item is numeric"検証タイプを使用すると、時間が

短縮され、結果としてパフォーマンスが向上します。

リダイレクトの使用

Oracle Application Express アプリケーションのほとんどのページには、実行される際

に 2 つの異なる段階があります。初の段階は、Oracle Application Express アプリ

ケーション・レポジトリに保存される定義に基づいて、ページを他のコンポーネ

ントとページが参照するテンプレートに統合するレンダリング段階です。


19


次に、ユーザーがボタンをクリックしてデータベースにデータを挿入するなどし

てイベントが発生した場合、Oracle Application Express エンジンは、ページを処理

段階へ送ります。この段階では、検証が行われ、セッション状態またはデータベー

スのデータを変更する処理が実行されます。後に、ユーザーを別のページ（ま

たは同じページ）に案内するため、分岐が行われます。

ユーザーによるイベントの一部は、処理が必要ありません。たとえば、「Cancel」ボタンをクリックして、データ入力フォームから別のページに移動する場合、

セッション状態に対する変更はほとんど必要ありません。このシナリオにおいて、

Oracle Application Express は、処理が発生しない種類のボタンを使用しています。

実際には、URL リダイレクトで現在のページから移動するショートカットを提供

します。

結論 Oracle Application Express は、開発者がアプリケーションの動作、スタイル、レイ

アウトを正確に制御できる柔軟性を維持できる生産性の高い宣言型ツールです。

つまり、Oracle Application Express の開発者は、開発プロセスを選択できます。

このホワイト・ペーパーでは、セキュアで、正常な予想通に動作し、一貫性のあ

る保守しやすいユーザー・インタフェースを使用する Oracle Application Expressによる Web アプリケーションの簡単な開発と配置のガイドラインとベスト・プラ

クティスを取り上げました。


20


Oracle Application Express のベスト・プラクティス 2006 年 1 月著者: Sergio Leunissen Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファクシミリ: +1.650.506.7200 www.oracle.com Copyright © 2003, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される

内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述

による明示または法律による黙示を問わず、特定の目的に対する商品性

もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条

件も提供するものではありません。オラクル社は本文書に関するいかな

る法的責任も明確に否認し、本文書によって直接的または間接的に確立

される契約義務はないものとします。本文書はオラクル社の書面による

許可を前もって得ることなく、いかなる目的のためにも、電子または印

刷を含むいかなる形式や手段によっても再作成または送信することはで

きません。 Oracle は米国 Oracle Corporation およびその子会社、関連会社の登録商

標です。その他の名称はそれぞれの会社の商標です。

oracle application...

Documents