最も安全な方法でアプリケーションをデプロイするために、サーバーレベルの設定で実装する推奨事項を示します。「GeneXus システムとデプロイメントの GAM によるセキュリティ強化」もお読みください。
クライアントとサーバー間の通信に安全なチャネルを使用するには、インフラ管理者がいくつかの事項を考慮する必要があります。これらの事項は使用するテクノロジーによって異なります。以下に示す推奨事項は一般的なものです。また、実装方法を理解するのに役立つ、いくつかの外部参照も付けています。GAM を補完することによって、不適切に設定された Cookie や資格情報の盗用などの問題を防止できます。
暗号化されていない HTTP の使用は避けます。GeneXus から、 [ Protocol specification ] プロパティを生成環境レベルで設定できます。値に Do not specify が割り当てられている場合は、アプリケーションをホストするサーバーの設定に応じて HTTP または HTTPS が使用されます。これにより、テスト環境での操作が容易になります。この方法で問題になるのは、本番サーバーが適切に設定されていると見なすことです。値が Secure (HTTPS:) の場合は、HTTPS の使用が強制され、アプリケーションをホストするすべての環境が正しく設定されている必要があります。
HTTP を使用しないという制限ポリシーを、HTTP Strict Transport Security (HSTS) を有効化するなどの補完的手段あわせて、各 Web サーバーで設定できます。HSTS は HTTPS の使用に関する考慮事項に対応するのにも役立ちます。
詳細については、次のサイトを参照してください:
- https://support.microsoft.com/en-us/help/324069/how-to-set-up-an-https-service-in-iis
- https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/hsts
- https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts
- https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
- https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html
HTTP や安全でないプロトコルに戻らないようにする必要があります。
特定の URL では、意図的に、または誤ってサーバー設定が HTTPS から HTTP に切り替わることがあります。サーバー上の URL Rewrite 機能で HTTP ではなく HTTPS の使用を強制しながら、アクセスを試みている同一リソースへのリダイレクトを作成できます。
暗号化プロトコルでは、通常、TLS (Transport Layer Security) またはその前身である SSL (Secure Sockets Layer) が異なるバージョンで設定されています。現在は、アプリケーションで TLS 1.2 と 1.3 のみをサポートすることをお勧めしています。Windows で実行されるサーバー (Internet Information Services) は、手動で、または IIS Crypto などのツールを使用してオペレーティング システム レベルで設定できます。Apache などのサーバーでは、設定ファイルを編集することでサービスレベルで変更します。たとえば、次の行を対応するファイルに追加します:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
詳細については、次のサイトを参照してください:
- https://howtohelpdesk.com/how-to-redirect-http-to-https-in-iis/
- https://www.tecmint.com/redirect-http-to-https-on-apache/
- https://www.journaldev.com/160/steps-to-configure-ssl-on-tomcat-and-setup-auto-redirect-from-http-to-https#tomcat-redirect-http-to-https
- https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
- https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html#ciphersuites
- https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client
- https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html
- https://www.nartac.com/Products/IISCrypto/Download
- https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html
正しいプロトコルを選択することに加えて、暗号化スイートを慎重に選択することも必要です。プロトコルでサポートされる、認証、暗号化、整合性コントロールのアルゴリズムの組み合わせです。さまざまな構成があり、広く認められている業界およびセキュリティ関連エンティティ (OWASP など) が推奨する構成、またはアプリケーションサーバーのベンダーが (Apache ドキュメントなどで) 推奨する構成に従うことができます。
Windows (Internet Information Services) では、手動で、または IIS Crypto などのツールを使用してオペレーティング システム レベルで設定されます。Apache などのサーバーでは、設定ファイルを編集することでサービスレベルで変更します。たとえば、次の行を対応するファイルに追加します:
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
詳細については、次のサイトを参照してください:
- https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
- https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html#recommendations-for-a-cipher-string
- https://www.nartac.com/Products/IISCrypto/Download
- https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel
- https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html#ciphersuites
- https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html
- https://www.acunetix.com/blog/articles/tls-ssl-cipher-hardening/
開発者と管理者は、一般的なエラーページ (404、403、500 など) を生成し、それぞれをサーバーに設定して、アクセスコントロールの失敗、GAM や GeneXus の内部エラーなどの情報を明らかにしないようにする必要があります。これは、アクセス許可がない、またはリソースが存在しないためにリソースにアクセスできないことを示すものではないため、しばしば推奨される方法です。また、内部エラーが発生した場合、エラーのトレースもテクノロジーも記録されません。このようなエレメントは攻撃者に情報を提供することになります。
GeneXus 16 Upgrade 11 以上を使用している場合は、さまざまな静的 HTML ページを特定のエラーコードと関連付けるように [ Http Error Handlers ] プロパティを設定できます。
それ以前のバージョンを使用している場合でも、この設定は可能です。すべての Web サーバー実装には、エラーページを返すための固有の設定があります。IIS (Internet Information Services) では管理用の GUI から設定を適用できますが、通常は web.config ファイルを直接編集したほうが汎用性が高く、情報を容易に見つけることができます。その他の実装 (Apache など) では設定ファイルで編集できます。また、特定のページを返すには次のような行で十分なので、実用的なサンプルを探すほうが簡単な場合もあります。
ErrorDocument 404 /errors/not_found.html
バージョンによって設定ファイルが大きく違っていることがあるため、設定するサーバーのバージョンを考慮する必要があります。たとえば、Apache Tomcat では、次の tomcat/conf/web.xml で示すように、404 エラーの同じ処理を設定できます:
<error-page>
<error-code>404</error-code>
<location>/errors/not_found.html</location>
</error-page>
ただし、Tomcat 9 の場合、この設定では間違った形式の URL など特定のケースに対応できません。そのため、HTTP リクエストの処理に介入するルールである Valve が導入されています。特に、エラーレポート Valve をここで適用して、エラーの処理をカスタマイズできるようにすることが必要です:
<Valve className="org.apache.catalina.valves.ErrorReportValve"
errorCode.400="webapps/ROOT/errors/not_found.html"
errorCode.0="webapps/ROOT/errors/errorOthers.html"
showReport="false"
showServerInfo="false" />
詳細については、次のサイトを参照してください:
- https://www.bruceclay.com/blog/microsoft-iis-custom-404-error-page-configuration/
- https://www.troyhunt.com/solving-tyranny-of-http-403-responses/
- https://www.digitalocean.com/community/tutorials/how-to-configure-apache-to-use-custom-error-pages-on-ubuntu-14-04
- https://httpd.apache.org/docs/2.4/custom-error.html
- https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Error_Report_Valve
GAM レジストリは、非本番環境でテストを行うときに使用します。これを GAM Web Backoffice のインターフェースまたは API からアクティベートすると、後で編集できないログファイルができます。この情報は本番環境のログには含めないようにする必要があります。GAM のユーザーやトークンからの情報がログに記録される可能性があるためです。そのため、 [ Enable tracing repository ] プロパティを 0 - Off に設定する必要があります。
詳細については次の記事を参照してください:
- https://wiki.genexus.com/commwiki/servlet/wiki?25395,HowTo%3A+Generate+GAM+trace
開発者は、ユーザビリティとセキュリティのバランスをとるため、HTTP ヘッダーを使用して機能を実装します。これにより、アプリケーションの汎用性やセキュリティが高まります。これを行うには、ヘッダーの実装方法と、それらが対応するベストプラクティスに従っているかを考慮する必要があります。
アプリケーションによって適切な値が異なるため、GeneXus では、推奨されるヘッダーの多くに既定の設定を提供していません。次に、最も重要なヘッダーの概要、意味のあるヘッダーとその使用に対する認識を高めることを目的とする、OWASP Secure Headers Project への参照情報を示します。
HTTP Strict Transport Security (HSTS) は、プロトコルの劣化と Cookie ハイジャック攻撃から Web サイトを保護するのに役立つ Web セキュリティポリシーです。これにより、Web サーバーが HTTPS を介してのみブラウザーと情報をやり取りすることを宣言できます。サーバーは、HTTPS 接続を使用し、Strict-Transport-Security ヘッダーを介して HSTS ポリシーを実装します (HTTP を使用した HSTS ヘッダーは無視されます)。完全な例は次のとおりです:
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
max-age はポリシーの持続期間を秒数で示し、includeSubDomains 項目属性 (オプション) はルールがすべてのサブドメインに適用されるように指定します。
詳細については、次のサイトを参照してください:
- https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
- https://owasp.org/www-project-secure-headers/
X-Frame-Options ヘッダーは、クリックジャック攻撃からの Web アプリケーションの保護を強化します。これは、コンテンツをフレーム内に表示できるかどうかをブラウザーに示すのに使用されます。CSP ポリシーの frame-ancestors ディレクティブ (Content-Security-Policy ヘッダーを参照) があると、X-Frame-Options ヘッダーの定義が不明瞭になります。
GeneXus では、プロンプトなどのエレメントでフレームを使用するため、通常、このヘッダーで値に Deny を使用することは推奨されません。最善の方法は、値として sameorigin (生成元がそのフレームを含むページと同じでない場合、フレームはロードされない) または allow-from: DOMAIN を使用することです。この DOMAIN はフレームを含むページの、許可されるドメイン名です。完全な例は次のとおりです:
X-Frame-Options: sameorigin
詳細については、次のサイトを参照してください:
- https://owasp.org/www-community/attacks/Clickjacking
- https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
- https://owasp.org/www-project-secure-headers/
このヘッダーを含めると、ブラウザーがサーバー応答の内容を調査せず、Content-Type ヘッダーの値のみを考慮するようになります。たとえば、text/plain を text/css として扱うことがなくなります。値は、次に示すように、nosniff にする必要があります。
X-Content-Type-Options: nosniff
詳細については、次のサイトを参照してください:
- https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/gg622941(v=vs.85)?redirectedfrom=MSDN
- https://docs.microsoft.com/en-us/archive/blogs/ie/ie8-security-part-vi-beta-2-update
- https://owasp.org/www-project-secure-headers/
コンテンツ セキュリティ ポリシー
コンテンツ セキュリティ ポリシー (CSP) は、慎重に調整し、正確に定義する必要があります。CSP を有効にすると、ブラウザーがアプリケーションをレンダリングする方法に大きな影響が生じます。たとえば、インラインの JavaScript は既定で無効になり、ポリシーで明示的に許可する必要があります。CSP はクロスサイトスクリプティングやその他のインジェクション攻撃など、さまざまな攻撃を阻止します。セキュアなポリシーの例を次に示します:
Content-Security-Policy: script-src 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'none'; require-trusted-types-for 'script';
値と、各ルールで定義される内容については、紹介しているドキュメントを参照してください。このヘッダーは、ブラウザーでロードされるリソースが過度に制限されてアプリケーションが機能不全にならないように、さらにテストする必要があります。ポリシーを検証するか、または (アプリケーションがインターネット上で公開されている場合に) 実装されるポリシーを確認するための Web サイトがあります。
詳細については、次のサイトを参照してください:
- https://owasp.org/www-community/attacks/Content_Security_Policy
- https://csp-evaluator.withgoogle.com/
- https://csper.io/evaluator
- https://owasp.org/www-project-secure-headers/
Referrer-Policy
Referrer-Policy ヘッダーはヘッダーに含まれる情報を決定するため、適切な値はアプリケーションでの Referer ヘッダーの用途によって異なります。Referer を含まない no-referrer など、非常に厳密な値もありますが、same-origin などの寛容な値もあります。same-origin は同じアプリケーションからのリクエストに対して情報を送りますが、ほかのサイトからのリクエストでは Referer 情報が送られません。ヘッダーの例は次のようになります:
Referrer-Policy: no-referrer
設定可能な値と、それらがさまざまなシナリオで Referer ヘッダーに与える影響を理解するため、以下のドキュメントを読むことをお勧めします。
詳細については、次のサイトを参照してください:
- https://web.dev/referrer-best-practices/
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
- https://owasp.org/www-project-secure-headers/
Web サーバーの実装ごとに、異なる方法で HTTP ヘッダーが追加されます。IIS の場合は、アプリケーション内 (または、すべてのホストされるアプリケーションレベル) に HTTP Response Headers というエレメントがあり、ここでヘッダーとそれらの固定値を手動で設定できます。
Apache の場合は、mod_headers モジュールを次のような行とともに使用することで、ヘッダーを容易に追加できます (ヘッダーを定義するより複雑な方法については、ドキュメントを参照してください):
Header set X-Content-Type-Options "nosniff"
Apache Tomcat の場合は、適用されている設定に応じて自動的にヘッダーを含めるフィルタがあります。たとえば、blockContentTypeSniffingEnabled というフィルタは、X-Content-Type-Options ヘッダーを値 nosniff で追加します。含まれていないヘッダーは、フィルタの設定ファイルで手動で追加できます。
<init-param>
<param-name>Custom-Header</param-name>
<param-value>custom value</param-value>
</init-param>
詳細については、次のサイトを参照してください:
- https://docs.microsoft.com/en-us/troubleshoot/iis/add-http-response-header-web-site
- https://httpd.apache.org/docs/current/mod/mod_headers.html
- https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html
|