WebアプリケーションにおけるSSLの使用の実現方式
6987 ワード
WebアプリケーションにおけるSSLの使用の実現方式
本文はただ個人の1つの学習ノートで、しばらく1つの記録をしましょう
発展の背景
インターネットの急速な発展、情報の急速な通達は企業にビジネスチャンスの無限の広大な発展空間を持って、インターネットは1つの完全に開放的なネットワークなため、その上で伝送する各種のデータはいろいろな盗聴と紛失の危険に直面します.現在、インターネット上の多くのWebアプリケーション、特にネットバンク、ネットスーパー、株式と債券のオンライン取引、ソフトウェアの有料ダウンロードなど、電子商取引アプリケーションは、Webサーバとクライアントブラウザの間で機密機密機密機密機密機密データを伝送する必要があります.これらのデータには、クレジットカード番号、パスワード、銀行口座番号などの高度な秘密データが含まれています.これらのデータが他の人にキャプチャされたり、改ざんされたりすると、お客様やWebサイトに計り知れない損失をもたらします.
これらの機密データの*転送中のセキュリティ*を保護するために、世界の多くの有名な企業はSSL(Secure Socket Layer)の暗号化メカニズムを採用しています.SSLは、インターネットExplorer、Netscape NavigatorなどのブラウザとWWWサーバ(NetscapeのNetscape Enterprise Server、ColdFusion Serverなど)の間に構築されたセキュリティチャネルでデータ伝送を行い、SSLはTCP/IP層の上、アプリケーション層の下で実行され、アプリケーションに暗号化されたデータチャネルを提供し、RC 4、MD 5、RSAなどの暗号化演算アルゴリズムを採用し、40ビットの鍵を使用して、ビジネス情報の暗号化に適しています.また、Netscape社はHTTPSプロトコルを開発し、ブラウザに内蔵しており、HTTPSは実際にはSSL over HTTPであり、HTTPのようにTCP/IPと通信するのではなく、デフォルトポート443を使用している.HTTPSプロトコルは、SSLを使用して送信側で元のデータを暗号化し、受信側で復号化する.暗号化と復号化は、送信側と受信側が共通の鍵を交換することによって実現される必要があるため、送信されたデータがネットワークハッカーによってキャプチャされ、復号化されにくい.
しかしながら、暗号化および復号化プロセスは、システムのオーバーヘッドを大量に消費し、機械の性能を著しく低下させる必要があり、テストデータは、HTTPSプロトコルを使用してデータを伝送する作業効率がHTTPプロトコルを使用して伝送する10分の1にすぎないことを示している.セキュリティ保護のために、1つのウェブサイトのすべてのWebアプリケーションをSSL技術で暗号化し、HTTPSプロトコルを使用して転送すると、そのウェブサイトの性能と効率が大幅に低下し、一般的にすべてのデータがそんなに高いセキュリティ保護レベルを要求しているわけではないので、この必要はありません.敏感な機密データに関するインタラクティブな処理にHTTPSプロトコルを使用するだけで、魚と熊の手を兼ねることができます.以下では,3つの具体的な実装方法を簡単から複雑に段階的に紹介する.
方法一、静的ハイパーリンク
これは現在のサイトで多く使われている方法であり、比較的簡単です.SSLを使用して転送する必要があるWEBアプリケーションまたはWebページへのリンクには、HTTPSプロトコルを使用することを直接明記しています.以下は、SSLを使用する必要があるWebページへのハイパーリンクです.
説明する必要があるのは、ページ内のハイパーチェーンが相対パスを使用する場合、そのデフォルトの有効化プロトコルは、ハイパーチェーンを参照するページまたはリソースの転送プロトコルと同じであり、例えば、ハイパーチェーンhttps://192.168.100.100/ok/login.jpsのWebページには、次の2つのハイパーリンクが含まれています.
では、最初のリンクはhttps://192.168.100.100/ok/login.jps同じ転送プロトコルhttpsで、2番目のリンクは、自身が識別したプロトコルhttpを使用します.静的ハイパーチェーンを用いた方法は,追加の開発作業を必要とせずに容易に実現できるという利点がある. しかし、容易な実装は、容易なメンテナンス管理に等しくない.httpプロトコルを完全に使用してアクセスするWebアプリケーションでは、各リソースがアプリケーションの特定のルートディレクトリの下の各サブディレクトリに格納され、リソースのリンクパスは相対パスを使用するため、アプリケーションの移行を容易にし、管理を容易にするためです.しかし、httpsプロトコルを使用するリソースがある場合、参照されるチェーン境界は完全なパスを使用する必要があります.したがって、アプリケーションの移行やURLに関連する任意の部分、例えばドメイン名、ディレクトリ、ファイル名などを変更する必要がある場合、メンテナンス者はすべてのハイパーチェーンの変更を必要とします.作業量の大きさは考えられます. さらに、静的チェーンを使用するには大きな問題があります.お客様がブラウザのURLにhttpプロトコルを使用してアクセスするためにhttpプロトコルを使用するリソースを手動で入力すると、すべての機密データが転送中に保護されず、ハッカーによってキャプチャされ、改ざんされやすくなります.
方法二、資源アクセス制限
WEBアプリケーションの機密データを保護し、資源の不正アクセスを防止し、伝送の安全性を保証するために、JAVAサーブレット2.2規範は定義した: security-constraint(セキュリティ制約)エレメント.1つ以上のWEBリソースセットのセキュリティ制約を指定します. user-data-constraint(ユーザデータ制約)エレメントはsecurity-constraintエレメントのサブクラスであり、クライアントとコンテナの間で伝送されるデータがどのように保護されるかを指定するために使用されます.user-data-constraint素子にはtransport-guarantee(転送保証)素子も含まれており、クライアントとサーバ間の通信は、NONE、INTEGRAL、CONFIDENTIALの3つのモードの1つでなければならないことを規定しています.そのうち: NONEは、指定されたWebリソースに伝送保証が不要であることを示す.
INTEGRALは、クライアントサーバ間で転送されたデータが転送中に改ざんされないことを示す.
CONFIDENTIALは、転送中にデータが改ざんされず、取得されないことを示す.
ほとんどの場合、INTEGRALまたはCONFIDENTIALは、SSL(Security Socket Layer)暗号化ソケットプロトコル層を使用して実装される.
例
ここではBEAのWebLogic Server 6.1を例にその実現方法を紹介し、WEBLOGICは性能の優れたJ 2 EEサーバーであり、管理するWEBリソースに対してEJB、JSP(JavaServer Page)、SERVLETアプリケーションを含めてアクセス制御条項を設定することができ、ここではWEBユーザーに対してアクセス制御を実現する方法だけを紹介する.もし私たちの手元にあるアプリケーションがweblogic serverに構築された/mywebAPPディレクトリがあるとしたら、その中の一部のservlets、JSPsはSSLを使用して転送することを要求しているので、私たちはそれらを/mywebAPP/sslsource/ディレクトリに置きます.次に、/secureAPP/WEB-INF/web.xmlファイルを編集し、web.xmlの設定によりWEBユーザーへのアクセス制御を実現します.Web.xmlファイルの例を次に示します.
例えば、あるWEBユーザがhttpプロトコルを使用してhttpプロトコルを使用することを要求するリソースBeSlslServiceletにアクセスし、URLを打ち込む.http://192.168.100.100/BeSslServletでは、BeSslServiceletを実行するときに、まずProcessSslServicelet.processslsl()を使用して、次のようにリダイレクトします.https://192.168.100.100/BeSslServlet,その後、BeSslServiceletとクライアントブラウザとの間でhttpプロトコルによるデータ転送が行われます.
以上紹介したのは最も簡単な例にすぎず,このようなリダイレクトの方法について初歩的な認識と概念を持つためである.本当にWEBアプリケーションで実現するには、以下のいくつかの問題を考慮しなければなりません.
●WEBアプリケーションではGETやPostメソッドが使用されることが多く、アクセス要求のURLにはgetRequesUrl()を使用して取得できないクエリー文字列が付いています.また、リダイレクト後に失われるので、リダイレクトする前に新しいURLに追加する必要があります.Request.getQueryString()を使用してGETのクエリー文字列を取得できます.PostのRequestパラメータについては、クエリー文字列に変換して処理できます.
・一部のWEBアプリケーションの要求では、オブジェクトがその属性として使用されます.リダイレクトする前に、リダイレクト後に使用するために、これらの属性をセッションに保存する必要があります.
●ほとんどのブラウザでは、同じホストに対して異なるポートアクセスを使用することを異なるホストへのアクセスと同様に、異なるセッションに分けて使用します.リダイレクト後に元のセッションを使用するように、アプリケーションサーバのクッキードメイン名に適切な設定を行う必要があります.
以上の問題はプログラム設計で解決できるが,ここでは詳しくは述べない.プログラム自身がプロトコルのリダイレクトを実現することによって、私達は厳格に保護することを要求するその部分の資源とその他の普通のデータを論理的に分けて処理することができて、SSLの資源を使用することとSSLの資源を使用する必要がないことを要求することをそれぞれ必要として、ウェブサイトのシステムの資源を浪費することを避けて、ウェブサイトの仕事の効率を高めて、また敏感なデータに対する伝送の保護を強化しました.転載先:http://lean1252.blog.163.com/blog/static/3181375520079911313829/
本文はただ個人の1つの学習ノートで、しばらく1つの記録をしましょう
発展の背景
インターネットの急速な発展、情報の急速な通達は企業にビジネスチャンスの無限の広大な発展空間を持って、インターネットは1つの完全に開放的なネットワークなため、その上で伝送する各種のデータはいろいろな盗聴と紛失の危険に直面します.現在、インターネット上の多くのWebアプリケーション、特にネットバンク、ネットスーパー、株式と債券のオンライン取引、ソフトウェアの有料ダウンロードなど、電子商取引アプリケーションは、Webサーバとクライアントブラウザの間で機密機密機密機密機密機密データを伝送する必要があります.これらのデータには、クレジットカード番号、パスワード、銀行口座番号などの高度な秘密データが含まれています.これらのデータが他の人にキャプチャされたり、改ざんされたりすると、お客様やWebサイトに計り知れない損失をもたらします.
これらの機密データの*転送中のセキュリティ*を保護するために、世界の多くの有名な企業はSSL(Secure Socket Layer)の暗号化メカニズムを採用しています.SSLは、インターネットExplorer、Netscape NavigatorなどのブラウザとWWWサーバ(NetscapeのNetscape Enterprise Server、ColdFusion Serverなど)の間に構築されたセキュリティチャネルでデータ伝送を行い、SSLはTCP/IP層の上、アプリケーション層の下で実行され、アプリケーションに暗号化されたデータチャネルを提供し、RC 4、MD 5、RSAなどの暗号化演算アルゴリズムを採用し、40ビットの鍵を使用して、ビジネス情報の暗号化に適しています.また、Netscape社はHTTPSプロトコルを開発し、ブラウザに内蔵しており、HTTPSは実際にはSSL over HTTPであり、HTTPのようにTCP/IPと通信するのではなく、デフォルトポート443を使用している.HTTPSプロトコルは、SSLを使用して送信側で元のデータを暗号化し、受信側で復号化する.暗号化と復号化は、送信側と受信側が共通の鍵を交換することによって実現される必要があるため、送信されたデータがネットワークハッカーによってキャプチャされ、復号化されにくい.
しかしながら、暗号化および復号化プロセスは、システムのオーバーヘッドを大量に消費し、機械の性能を著しく低下させる必要があり、テストデータは、HTTPSプロトコルを使用してデータを伝送する作業効率がHTTPプロトコルを使用して伝送する10分の1にすぎないことを示している.セキュリティ保護のために、1つのウェブサイトのすべてのWebアプリケーションをSSL技術で暗号化し、HTTPSプロトコルを使用して転送すると、そのウェブサイトの性能と効率が大幅に低下し、一般的にすべてのデータがそんなに高いセキュリティ保護レベルを要求しているわけではないので、この必要はありません.敏感な機密データに関するインタラクティブな処理にHTTPSプロトコルを使用するだけで、魚と熊の手を兼ねることができます.以下では,3つの具体的な実装方法を簡単から複雑に段階的に紹介する.
方法一、静的ハイパーリンク
これは現在のサイトで多く使われている方法であり、比較的簡単です.SSLを使用して転送する必要があるWEBアプリケーションまたはWebページへのリンクには、HTTPSプロトコルを使用することを直接明記しています.以下は、SSLを使用する必要があるWebページへのハイパーリンクです.
<a href=”https://192.168.100.100/ok/securePage.jsp”>SSL a>説明する必要があるのは、ページ内のハイパーチェーンが相対パスを使用する場合、そのデフォルトの有効化プロトコルは、ハイパーチェーンを参照するページまたはリソースの転送プロトコルと同じであり、例えば、ハイパーチェーンhttps://192.168.100.100/ok/login.jpsのWebページには、次の2つのハイパーリンクが含まれています.
<a href=”./bessl/exam.jsp”>SSL a>
<a href=”http://192.168.100.100/notssl/index.jsp”> SSL a>では、最初のリンクはhttps://192.168.100.100/ok/login.jps同じ転送プロトコルhttpsで、2番目のリンクは、自身が識別したプロトコルhttpを使用します.
方法二、資源アクセス制限
WEBアプリケーションの機密データを保護し、資源の不正アクセスを防止し、伝送の安全性を保証するために、JAVAサーブレット2.2規範は定義した:
INTEGRALは、クライアントサーバ間で転送されたデータが転送中に改ざんされないことを示す.
CONFIDENTIALは、転送中にデータが改ざんされず、取得されないことを示す.
ほとんどの場合、INTEGRALまたはCONFIDENTIALは、SSL(Security Socket Layer)暗号化ソケットプロトコル層を使用して実装される.
例
ここではBEAのWebLogic Server 6.1を例にその実現方法を紹介し、WEBLOGICは性能の優れたJ 2 EEサーバーであり、管理するWEBリソースに対してEJB、JSP(JavaServer Page)、SERVLETアプリケーションを含めてアクセス制御条項を設定することができ、ここではWEBユーザーに対してアクセス制御を実現する方法だけを紹介する.もし私たちの手元にあるアプリケーションがweblogic serverに構築された/mywebAPPディレクトリがあるとしたら、その中の一部のservlets、JSPsはSSLを使用して転送することを要求しているので、私たちはそれらを/mywebAPP/sslsource/ディレクトリに置きます.次に、/secureAPP/WEB-INF/web.xmlファイルを編集し、web.xmlの設定によりWEBユーザーへのアクセス制御を実現します.Web.xmlファイルの例を次に示します.
<web-app>
<security-constraint>
<web-resource-collection>
<web-resource-name>SecureAPPweb-resource-name>
<description>App using httpsdescription>
<url-pattern>/ sslsource
String desiredScheme = HTTPS;
String usingScheme = userRequest.getScheme();
String redirectString = null;
if ( !desiredScheme.equals(usingScheme)) {
StringBuffer url = HttpUtils.getRequestURL(userRequest);
url.replace(0, usingScheme.length(), desiredScheme );
redirectString = url.toString();
}
if( redirectString != null ){
try{
ourResponse.sendRedirect(
ourResponse.encodeRedirectURL(redirectString));
return;
}catch(Exception ioe){
}
}
return;
}
}
例えば、あるWEBユーザがhttpプロトコルを使用してhttpプロトコルを使用することを要求するリソースBeSlslServiceletにアクセスし、URLを打ち込む.http://192.168.100.100/BeSslServletでは、BeSslServiceletを実行するときに、まずProcessSslServicelet.processslsl()を使用して、次のようにリダイレクトします.https://192.168.100.100/BeSslServlet,その後、BeSslServiceletとクライアントブラウザとの間でhttpプロトコルによるデータ転送が行われます.
以上紹介したのは最も簡単な例にすぎず,このようなリダイレクトの方法について初歩的な認識と概念を持つためである.本当にWEBアプリケーションで実現するには、以下のいくつかの問題を考慮しなければなりません.
●WEBアプリケーションではGETやPostメソッドが使用されることが多く、アクセス要求のURLにはgetRequesUrl()を使用して取得できないクエリー文字列が付いています.また、リダイレクト後に失われるので、リダイレクトする前に新しいURLに追加する必要があります.Request.getQueryString()を使用してGETのクエリー文字列を取得できます.PostのRequestパラメータについては、クエリー文字列に変換して処理できます.
・一部のWEBアプリケーションの要求では、オブジェクトがその属性として使用されます.リダイレクトする前に、リダイレクト後に使用するために、これらの属性をセッションに保存する必要があります.
●ほとんどのブラウザでは、同じホストに対して異なるポートアクセスを使用することを異なるホストへのアクセスと同様に、異なるセッションに分けて使用します.リダイレクト後に元のセッションを使用するように、アプリケーションサーバのクッキードメイン名に適切な設定を行う必要があります.
以上の問題はプログラム設計で解決できるが,ここでは詳しくは述べない.プログラム自身がプロトコルのリダイレクトを実現することによって、私達は厳格に保護することを要求するその部分の資源とその他の普通のデータを論理的に分けて処理することができて、SSLの資源を使用することとSSLの資源を使用する必要がないことを要求することをそれぞれ必要として、ウェブサイトのシステムの資源を浪費することを避けて、ウェブサイトの仕事の効率を高めて、また敏感なデータに対する伝送の保護を強化しました.転載先:http://lean1252.blog.163.com/blog/static/3181375520079911313829/