PowerBuilder アプリケーションはデータベースへの依存度が高く、業務上重要なデータを大量に処理することから、攻撃者にとって価値の高い標的となっています。PowerBuilder コードのセキュリティ脆弱性は、メンテナンス サイクル、サードパーティ連携、あるいは引き継がれた開発慣行を通じて静かに蓄積し、長年にわたって検出されないケースが少なくありません。
Visual Expert は、静的アプリケーション セキュリティ テスト（SAST）によって PowerBuilder コードのセキュリティを多角的に強化します。
- PowerBuilder コードのセキュリティ脆弱性（ハードコードされた認証情報、インジェクションの欠陥、安全でない暗号化など）を検出します。
- デッドコード、重複コード、廃止済みコードを特定することで、不要な攻撃経路を削減し、攻撃対象領域を縮小します。
- パフォーマンスを低下させる、またはサービス拒否（DoS）攻撃につながる可能性のある不適切なコーディング パターンを指摘します。
- 検出された各問題に対して、具体的な修正案を提示します。
- PowerBuilder クライアントと、接続された Oracle または SQL Server データベースのコードを単一の解析で同時にカバーします。
体系的な修正計画を検討しているチームは、コード、デプロイ、アクセス制御、監査対応を網羅した包括的なアプローチを PowerBuilder アプリケーション セキュリティ ガイド でご覧いただけます。
PowerBuilder セキュリティ脆弱性のカテゴリ
Visual Expert の 300 以上のコード インスペクション ルールは、PowerBuilder のセキュリティ脆弱性を 5 つのカテゴリに分類してカバーしています。
以下のセクションでは、各カテゴリの主要なルールについて詳しく説明します。
ハードコードされた認証情報と機密データ
ハードコードされた機密情報は、PowerBuilder のセキュリティ脆弱性の中でも最も一般的かつ危険なものの一つです。コンパイル済みの実行ファイルに静かに残り続け、デコンパイル ツールによって露出する可能性があります。物理的またはリモートを問わず、バイナリへのアクセスが発生した時点で、認証情報の漏洩につながります。
- ユーザー ID およびパスワードをハードコードしてはならない
ユーザー名、パスワード、IP アドレス、暗号化キーなどの機密情報をハードコードすると、攻撃者に露出するリスクがあります。実行ファイルにアクセスできる者は、デコンパイルによって機密情報を入手できる可能性があります。GDPR、SOX、HIPAA などの規制によって保護されるデータが漏洩した場合、深刻な法的責任を招く恐れがあります。
Visual Expert は、ハードコードされたユーザー ID およびパスワードを検索し、これらのセキュリティ上の脆弱性を除去できるよう支援します。 - 暗号化キーをハードコードしてはならない
このルールは、PowerBuilder コードで使用する暗号化キーを、コード内にプレーンテキストとして保存しないことを定めています。暗号化キーはコードの外部にある安全な場所に保存し、そこから参照するようにしてください。これにより、コードにアクセスできる可能性のある攻撃者への鍵の露出を防ぎ、鍵の変更や更新が必要になった場合の管理も容易になります。 - IP アドレスをハードコードしてはならない
IP アドレス、暗号化キー、パスコードなどの機密情報をハードコードすると、攻撃者にさらされるリスクがあります。実行時ファイルにアクセスされた場合、デコンパイルによってこれらの情報が露出する可能性があります。GDPR、SOX、HIPAA などの規制によって保護される情報が漏洩した場合、重大な法的責任を招く恐れがあります。
Visual Expert はハードコードされた IP アドレスを検索し、このセキュリティ上の脆弱性を除去できるよう支援します。 - 本番環境でコンソール ロギングを使用してはならない
コンソール ロギングは、コードの動作を調べたり問題発生を検知したりするためのデバッグ手法です。本番環境では無効化する必要があります。有効なままにしておくと、機密データが露出したり、アプリケーションの内部動作に関する情報が漏洩したりする恐れがあります。Visual Expert は PowerBuilder コード内のこうした問題を検出し、本番稼働前に無効化できるよう支援します。
暗号化および暗号技術の脆弱性
脆弱な暗号化や不適切に設定された暗号化は、PowerBuilder のセキュリティ脆弱性の中でも技術的に最も捉えにくいカテゴリの一つです。アルゴリズム、モード、または鍵長が不適切な場合、アプリケーションが暗号化を使用しているように見えても、実質的に保護されていない状態になる可能性があります。
- AES 暗号化アルゴリズムは必ずセキュアなモードで使用すること
AES にはいくつかのモード（ECB、CBC、CFB など）があり、速度やセキュリティの特性がそれぞれ異なります。
PowerBuilder コードで AES を使用する場合は、安全性の高いモードを選択してください。
Visual Expert はアプリケーションをスキャンし、安全性が低い呼び出しを検出してコード上でハイライト表示します。 - 暗号化アルゴリズムは適切なセキュア モードおよびパディング スキームとともに使用しなければならない
暗号化アルゴリズムでコードを保護する際は、動作モードとパディング スキームを正しく設定することが重要です。Visual Expert は使用されている暗号化アルゴリズムに応じて適切なパディングとモードの値を判定し、PowerBuilder コードでそれらが正しく使用されているかどうかを検証します。 - 暗号化キーは十分な長さでなければならない
暗号化キーをブルートフォース攻撃に対して十分に堅牢にするためには、適切な鍵長が必要です。Visual Expert は、PowerBuilder コードで堅牢性が不十分な鍵が使用されている場合に警告します。 - DES（データ暗号化標準）または 3DES を使用してはならない
DES（データ暗号化標準）は、デジタル データを暗号化するための共通鍵アルゴリズムです。
鍵長が 56 ビットと短く、現在では安全とは見なされていません。使用すべきではありません。
Visual Expert は PowerBuilder コード内のすべての DES 呼び出しを検出し、削除できるよう支援します。 - 暗号ハッシュ関数に SHA-1 またはメッセージ ダイジェスト アルゴリズムを使用してはならない
SHA-1 およびメッセージ ダイジェスト アルゴリズム（MD2、MD4、MD5、MD6）は、現在では安全と見なされていません。Visual Expert は、これらのアルゴリズムが PowerBuilder コードで使用されているかどうかを確認し、対応する呼び出し箇所を特定して、より安全なアルゴリズムへの更新を支援します。
インジェクションおよび入力検証の欠陥
PowerBuilder アプリケーションはその性質上、データベースへの依存度が高いため、SQL インジェクションは PowerBuilder のセキュリティ脆弱性の中でも特に影響が大きいカテゴリの一つです。検証されていないユーザー入力がデータベース クエリやシステム コマンドに到達すると、攻撃者がデータの読み取り、改ざん、破壊、あるいはシステム上での不正操作を行えるようになる可能性があります。
- データベース クエリはインジェクション攻撃に対して脆弱であってはならない
コード インジェクションとは、アプリケーションによって解釈・実行される悪意のあるコードを挿入する攻撃です。特に SQL インジェクションは、データベースに対する不正操作（機密データへのアクセス、サーバーの乗っ取りやシャットダウンなど）を可能にします。
PowerBuilder アプリケーションはその性質上、データベースへの依存度が高く、ミッション クリティカルな用途で利用されることも少なくありません。
大量の重要データを扱うため、攻撃者にとって格好の標的となります。
Visual Expert は、SQL の構築に使用されている文字列連結のうち、適切に検証またはエスケープされていないものを検索します。これらは SQL インジェクションの重大な脆弱性となる可能性があります。このようなクエリを特定してリファクタリングすることで、データベース保護を強化できます。 詳細：PowerBuilder アプリケーションをコード インジェクション攻撃から保護する方法 - ユーザー入力はパス インジェクションまたはパス トラバーサル攻撃を許容してはならない
URL パラメータや Cookie などのユーザー データは、潜在的に危険なものとして扱う必要があります。コードがこのデータからファイル システム パスを動的に生成している場合、攻撃者が「../」などの特定の値を注入して意図したパスを変更できる可能性があります。
この種の攻撃は「パス トラバーサル」または「ディレクトリ トラバーサル」と呼ばれます。攻撃者はこれにより、禁止されたディレクトリにアクセスし、機密データの読み取り・改ざん・削除、またはオペレーティング システム コマンドの実行が可能になります。
Visual Expert はこうした脆弱性を引き起こすコードを特定し、適切な修正を促します。有効な対策の一つとして、許可されたパスまたは文字のホワイトリストを定義する方法があります。 - OS コマンドはインジェクション攻撃を許容してはならない
ユーザー入力に基づいてオペレーティング システム コマンドを実行するコードでは、各コマンドの名前を必ず検証しなければなりません。検証がなければ、攻撃者が独自のコマンドを注入して不正操作を実行し、システムを危険にさらす可能性があります。
Visual Expert は PowerBuilder コード内のこうした欠陥を検出し、修正を支援します。対策例として、安全なコマンドのホワイトリストを定義し、シェル メタ文字をサニタイズする方法があります。 - 正規表現はサービス拒否攻撃を許容してはならない
ユーザー データから正規表現を動的に生成することは、正規表現型サービス拒否攻撃（ReDoS）につながる可能性があるため、強く推奨されません。この攻撃は、特定の文字を悪意を持って使用することで正規表現の評価を著しく遅延させる特性を悪用します。攻撃者はプログラムが正規表現を使用する状況を意図的に作り出し、長時間ブロックさせること（これがサービス拒否の原因）ができます。
Visual Expert は PowerBuilder コード内のそのような呼び出しを特定し、削除するか、正規表現のメタ文字をサニタイズすることで入力を無害化できるよう支援します。 - 汎用例外を無視してはならない
例外処理においては、catch ブロックには必ず適切な捕捉メカニズムを実装する必要があります。Visual Expert は空の catch ブロックを検出し、意味のある例外処理を実装することでコードの安全性を高めます。
非推奨コンポーネントおよびレガシー コンポーネント
多くの PowerBuilder アプリケーションには、以前のバージョンでは標準的な手法であったものの、現在は非推奨となったり、重大なセキュリティ リスクが指摘されたりするコンポーネントが今も残っています。これらはレガシー コード ベースにおける PowerBuilder セキュリティ脆弱性の一般的な発生源であり、自動スキャンなしでは特定が困難なため、見過ごされがちです。
- SOAP および INET オブジェクトを使用してはならない
PowerBuilder の SOAP および INET オブジェクトは TLS 1.2 をサポートしていないため、攻撃に対して脆弱になります。 - OLE Web ブラウザはセキュアでないため使用してはならない
OLE Web ブラウザはサポートが終了した古い技術であり、更新が提供されないため、セキュリティ上の脆弱性が存在します。このルールは、OLE Web ブラウザの使用を禁止するものです。HTML や JavaScript など、より安全な代替手段の使用を推奨します。 - EAServer はサポートが終了しているため使用してはならない
EAServer は PowerBuilder 2017 以降サポートが終了しています。SSLServiceProvider オブジェクトは古いバージョンの PowerBuilder で SSL/TLS サービスを提供しますが、現代のセキュリティ プロトコルをサポートしていない可能性があり、現在の安全な通信には適していません。CORBACurrent オブジェクトは分散オブジェクトの CORBA 標準の一部ですが、CORBA は陳腐化しており、現代のアプリケーション アーキテクチャではほとんど使用されていません。CORBAObject は CORBA システム内のリモート オブジェクトを表しますが、パフォーマンスの問題と時代遅れであることから使用は推奨されません。TransactionServer オブジェクトは分散アプリケーションのトランザクション管理を担いますが、現代のフレームワークがより堅牢でスケーラブルなソリューションを提供しています。 - CoSetProxyBlanket または CoInitializeSecurity を使用してはならない
サブルーチン CoSetProxyBlanket、CoInitializeSecurity、および CoInitializeSecurityAlias の呼び出しは、セキュリティ上の脆弱性を生じさせる可能性があります。Visual Expert は PowerBuilder コード内のこれらの呼び出しを検出し、削除を支援します。
アクセス制御とコードの露出
これらのルールは、クラスの外部からの意図しないデータ変更を可能にする、過度に許可的なフィールドのアクセシビリティによって、コード構造自体がセキュリティ上のリスクを生じさせる問題を対象としています。
- フィールドにパブリック アクセスを設定してはならない
このルールは、PowerBuilder コードのフィールドをパブリック アクセス可能な状態にしないことを定めています。つまり、パブリック変数として宣言するのではなく、プライベートまたはプロテクト変数として宣言する必要があります。フィールドをパブリック アクセス可能にすると、外部コードから制限なくフィールドにアクセスして変更できるようになり、潜在的なセキュリティ リスクが生じます。フィールドへのアクセスを同一クラス内のコードのみに限定することで、コードの安全性を確保し、意図した方法でのみ変更されるようにすることが重要です。