Skip to main content
OutSystems

インジェクションおよびXSS(クロスサイトスクリプト)

インジェクションの欠陥とXXS(クロスサイトスクリプト)は、今でも最もよくあるアプリケーションの脆弱性です。ここでは、これらの種類の脆弱性からアプリケーションを保護するための開発およびOutSystemsプラットフォームの構成に関するベストプラクティスを示します。

XSSでは、攻撃者がHTMLを挿入して、他のユーザーが閲覧しているWebページで表示させたり、クライアント側のスクリプトを実行させたりします。OutSystemsでは、これを回避するためにIDEでの警告やその他の機能提供しています。

インジェクションの欠陥

一般的に、インジェクションの欠陥が発生するのは、UI入力または外部ソースからの信頼できないコマンド(SQL、HTML、JavaScript)をインタープリタで実行する場合です。

通常、OutSystemsプラットフォームでは式およびAggregate内のコンテンツをエスケープします。ただし、開発者がカスタムJavaScript、HTML、SQLオブジェクトと一緒にインラインパラメータを使用する必要がある場合は、悪意のあるコンテンツをエスケープして削除するためにエンコード/サニタイズするビルトイン関数やアクションが用意されています。

さらに、OutSystems IDEは、設計時にアプリケーションがインジェクションの脅威にさらされるパターンが作成されると、開発者に対して警告を発します。

SQLインジェクション

OutSystemsプラットフォームでは、SQLオブジェクトと一緒にインラインパラメータや文字列リテラルを使用する高度なクエリでSQLインジェクションが発生することがあります。

一般的にこのような場合は、信頼できない変数をEncodeSql()ビルトイン関数でラップして特定の文字(一重引用符「'」など)を避け、各EncodeSql()を常に一重引用符で囲んで(例: 「‘」 + EncodeSql(変数) + 「‘」)、インラインパラメータの文字列リテラルのコンテンツをエスケープするという方法をとります。

 

以下のコード例をご覧ください。

図1は、このコードが、OU12345などの有効なクライアントIDが含まれるリクエストが到着すると仮定していることを示しています。この場合、SQLは 図2のようになり、すべて適切な結果になります。

しかし、攻撃者がURLパラメータを変更して文字列 DUMMYSTR OR 1 = 1を渡し、この仮定を悪用する可能性があります。この場合、コードは図3のようになり、攻撃者がすべてのクライアントデータベースにアクセスできるようになります。

このクエリパラメータをSQL文に直接渡すことで、コードは、データベース内のすべてのユーザーを返してユーザーの個人情報を公開してしまいます。この考え方は不適切です。そのため、OWASPは、文を実行する前にすべての入力をサニタイズするか、安全なAPIを使用してインタープリタの全体的な実行を避けることを開発者に提案しています。

OutSystemsではどのようになるでしょうか。 Expand Inline プロパティを[Yes] に設定すると、プラットフォームのデフォルトのエスケープコンテンツが無効になるため、注意が必要です。

非文字列リテラルを含むSQL句の場合や追加のセキュリティが必要な場合、Sanitization拡張機能のVerifySqlLiteral()関数またはEncodeSql()関数を使用して、有効なSQLリテラルのみが含まれるようにすることができます。その代わりに、SQL予約文字を含む変数は拒否されます。以下の不適切な例(図1)と適切な例(図2)をご覧ください。

 

JavaScriptおよびHTMLインジェクション

JavaScriptは、WebページやWebアプリケーションで最も一般的かつ幅広く使用されているテクノロジーのひとつです。しかし、セキュリティ上の問題を引き起こすことがあるため、開発者とテスターは注意する必要があります。JavaScriptは、適切な用途だけではなく、悪意のある攻撃にも使用できます。JavaScriptインジェクションもそのひとつです。デフォルトでは、OutSystemsはすべてのコンテンツをユーザーに表示する前にエスケープします。しかし、SQLインジェクションを回避するなど、カスタムHTMLまたはJavaScriptを挿入する必要がある場合、このメカニズムを明示的に無効にできます。これを行う際は注意が必要です。OutSystemsでは、すべてのJavaScriptの予約語がエスケープ処理された文字に置き換えられることを保証するEncodeJavascript()を用意しています。OutSystems IDEは特にこの点に配慮しており、アプリケーションがインジェクションの脅威にさらされる場合は開発者に対して警告を表示します。以下の図1では開発者がデフォルトのエスケープ保護を無効化しており、図2では開発者がEncodeHtml()関数を使用しないで変数コンテンツの安全性の保証を無視しています。

 

動的URL

アプリケーションが偶然に動的リダイレクトを実行し、フォームデータまたはURLパラメータからデータを取得する場合は、データに潜在的な改ざんが加えられていることに注意が必要です。アプリケーションロジックが指定されたURLにリダイレクトする場合、URLが変更されていないことを常に保証する必要があります。OutSystemsユーザーは、EncodeUrl()ビルトイン関数を使用できます。

 

CSP(コンテンツセキュリティポリシー)

CSPは主に、ブラウザが読み込みを認められている許可されたコンテンツ出元を宣言する標準的な方法を提供し、XSS(クロスサイトスクリプティング)攻撃に対する追加のセキュリティレイヤーを提供します。

XSS攻撃は通常、悪意のあるユーザーが生成したコンテンツがWebサイトのセキュリティ対策を回避し、ユーザーに実行可能コードが配信されたときに発生します。このコードがユーザーのブラウザで実行され、悪意のあるアクティビティを実行します。

OutSystemsでXSSイベントが発生する可能性を減らすため、[Service Center]/[Security]でCSP保護を有効にし、多くの構成を指定してセキュリティを強化できます。

デメリットには、許可したリソースのホワイトリストの管理が挙げられます。通常、ホワイトリストの作成時に、サードパーティサイトとの通信によりサイトの受け入れの信ぴょう性を判定します。

OutSystemsでは、以下のように[Service Center]/[Administration]/[Security]でこの機能を有効にします。

HTTPSセキュリティを適用する

OutSystemsでは、設計段階で開発者がアプリケーションで使用するHTTPセキュリティを決定できます。これは、HTTPやHTTPSで利用可能なページと連携を定義することで行います。

ITマネージャーや管理者は、インストールした実行中のアプリケーションのHTTPセキュリティを上書きして有効にすることができます。環境全体に適用して実行中のすべてのアプリケーションに反映させることも、アプリケーションごとに適用することも可能です。

アクセス制御の不備

アプリケーションが処理するデータの機密性の度合いによっては、アクセス制御の不備が組織に重大な影響や致命的な影響を及ぼす場合があります。データ漏洩が発生すると、風評被害や経済的不利益を被るほか、不正に対する顧客の脆弱性を高めたり、顧客からの信頼を失ったりすることにつながります。
一般論として、アクセス制御の不備を回避できる完全な解決策はありません。少なくとも以下の2つの点を含む対策を講じる必要があります。

  • 認証: ユーザーがアプリケーションへのアクセスを試みた場合に、ユーザーを適切に識別する。

  • 認可: ユーザーが実行できるまたは実行できないアクションやリソースを決定する。

プラットフォームがデフォルトで提供するプロトコルを使用した場合、OutSystemsで開発したアプリケーションでアクセス制御の不備による問題が発生するリスクは低くなります。OutSystemsでは個人情報を保持せず、パスワードは強固に暗号化されています。セキュリティ対策として、OutSystemsではユーザーロールという考えを採用しており、アプリケーションの特定の画面や操作に対するエンドユーザーのアクセスを制限または拒否します。OutSystemsによるアプリケーションの保護の詳細については、「アプリケーションを保護する」をご覧ください。

メリット

インジェクション攻撃やXSS攻撃を受けた場合、データの損失や破損、権限のない第三者への公開のほか、責任所在の不明瞭化やサービス妨害が発生するおそれがあります。

主なメリットは、アプリケーションの機密データを保護し、その結果としてユーザーの信頼を得ることです。

  • Was this article helpful?