2

私は、フロントエンドに純粋な JavaScript を使用し、RESTful AJAX 呼び出しを介してデータの Web サービスにアクセスする、サービス指向アーキテクチャを利用する新しいサイトに取り組んでいます。

特に重要ではありませんが、私のスタックは次のとおりです。

  • javascriptMVC
  • jQuery
  • ブートストラップ
  • ASP.NET Web API (.NET 4.0 上の C#)
  • MSSQL

この記事から、クライアント (JavaScript) とサーバー (Web API を介した REST サービス) の間で秘密鍵を共有すると、Web サービス呼び出しを保護するための良い方法がいくつかわかりました。ただし、暗号化に使用する秘密鍵を確立する方法に苦労しています。

悪い考え #1

ただし、最初は、HTTPS 経由で発生するログイン時に設定し、再利用のためにクライアントの Cookie に保存することでした。問題は、私たちのサイトがhttp://www.example.comにあるのに、私たちの SSL 証明書はhttps://secure.example.com用であるため、secure.example.com Cookie にアクセスできないことです。 www.example.com から。

悪い考え #2

次に考えたのは、次のように、HTTPS ログインから HTTP ポストログイン ページに URL パラメータを介して暗号化および署名して渡すことでした。

http://www.example.com/processLogin?key=[encryptedKey]&sig=[encryptedSig]&user=[userid]

encryptedKey と encryptedSig は両方とも、そのトランザクションのためだけに存在する別の秘密鍵で暗号化されます。ログイン時に作成され、データベース内のそのユーザーに割り当てられます。HTTP 側では、これらすべてがサーバーに渡され、サーバーはそれを復号化し、署名を検証し、その秘密鍵を削除し (リプレイ攻撃から保護するため - 基本的にnonce )、復号化された秘密鍵 ([encryptedKey]復号化されたもの) を返します。

それ以降、復号化された値は、[encryptedKey]将来のすべてのトランザクションに使用されます。問題は、復号化された秘密鍵を HTTP 経由で回線経由で送信する必要があることです。

悪い考え #3

また、この値を復号化するために使用される JavaScript にハードコードされたキーがあることも簡単に思いつきましたが、どのように難読化しようとしても、ハッカーに発見されて使用される可能性があります。

悪い考え #4

また、最初のハンドシェイクで公開鍵暗号を使用するある種のキー交換も検討しましたが、他の場所で述べたように、クライアント側では、最初のハンドシェイクが終了しない限り、改ざんがないと確信することはできません。 SSL - 振り出しに戻ります。

大きな疑問

では、 HTTPSを介さずにすべてを管理するにはどうすればよいでしょうか。この秘密鍵を Cookie に保存するには、HTTP と HTTPS で同じドメイン名を使用する必要がありますか?

サイトの非 SSL 部分では、クレジット カードやログイン情報などは共有されないことに注意してください。この吸盤を大きく開いたままにしたくないだけです。

4

3 に答える 3

2

SSL を実装しないと、javascript クライアントとサーバーの間で安全で暗号化された通信を行うことはできません。それは無理だ。本当に達成したいことがトラフィックを暗号化することではなく、話しているクライアントがリクエストを行う権限を与えられていること、およびクライアントがなりすましではないことを確認することだけである場合は、OAuth で十分な場合があります。標準の OAuth .net 実装については、 http://www.dotnetopenauth.net/を参照してください。

OAuth に関わりたくない場合で、既に構築したものに基づいて構築したいだけの場合は、トークンと公開鍵と秘密鍵を JavaScript クライアントに配布する必要があります。公開鍵とトークンはリクエストごとにやり取りされるものですが、秘密鍵はやり取りされることはなく、代わりに何らかのタイプの署名ハッシュを生成するために使用されます。リプレイを防ぐために、すべてのリクエストにこの署名と時間ベースのナンスが必要です。また、非常に頻繁にトークンを期限切れにし、クライアントに署名と公開鍵を使用して「更新」トークンを要求するように要求する必要があります。本質的に、私が説明したのは OAuth 1.0a であり、このルートを使用したい場合は、自分でロールバックしようとするのではなく、DotNet OpenAuth に戻ることをお勧めします。

ただし、繰り返しになりますが、SSL を使用しない場合でも、他の種類の攻撃に対して脆弱です。また、最初のトークン リクエストを SSL 暗号化しない限り、ハッカーは常にトークン/公開/秘密キーのペアの最初の配信を傍受する可能性があるため、最初からセキュリティを確保するためのすべての労力が不要になります。

上記に代わる方法は、クライアントと REST API の間にプロキシ サーバーを配置することです。API へのリクエストは、プロキシ サーバーのみを通過できます。クライアントはログインし、基本認証を使用してhttps://secure.example.comから Cookie を取得し ます。その後、クライアントは引き続き secure.example.com と secure.example.com にリクエストを送信し、API にリクエストを送信してデータをクライアントに返します。

とにかく、うまくいけば、考える材料を与えるのに十分な情報です.

于 2012-08-22T18:56:16.920 に答える
1

次の回答を確認することで、サブドメインとCookieの操作方法を確認できます。ドメインでJavaScript Cookieを作成し、サブドメイン間で読み取る

于 2012-08-22T17:58:03.900 に答える
0

悪い考え＃3について：

http://jsbeautifier.orgを使用して、 http : //dean.edwards.name/packer/ を使用して難読化されたものを解読できることをしばらく知っていました。 "チェックボックス。そのため、JavaScript は完全に安全ではなく、SSL 暗号化、ユーザー認証トークン、編集可能なアカウント統計をブラウザーに保存するために依存するべきではありません。そうしないと、誰かが自分のゲーム アカウントを編集して、+1,000 万のゲーム コインを自分に与えようとするだけです。

すべてが SSL を経由する場合、「中間者」攻撃からのみ保護されます。これは、まさに「サーバー ボット イン ザ ミドル」攻撃です。エンドユーザー自身がハッカーになることを防げません。

次の図では、SSL により、サーバー a から e は、クライアントからターミナル サーバーに渡されるデータを見ることができなくなりますが、SSL がなければサーバー C はデータを盗みます。これは、クライアントとすべてのサーバーがデータを読み取ることができる暗号化なしのサーバーホップの仕組みです。

client > a > b > server c's bot sniffs http traffic > d > e > terminus server

サーバー c のボットは、暗号化された銀行口座番号であるクレジット カード番号をログに記録します。(ほとんどの人は、クレジット カード番号が暗号化され変換された銀行口座番号であることを認識していません。クレジット カード番号が侵害された場合、銀行が銀行口座番号から新しい暗号化された CC# を再発行して送信するのは簡単です。元の銀行口座番号を変更する必要も、銀行口座番号が底に印刷されている新しい小切手を印刷する必要もありません。)

TLS/SSL/https 暗号化を使用したサーバー ホップは次のように機能し、クライアントとサーバーだけが何かを読み取ることができます。

client > all servers from a-e are blind & pass the data through > terminus server

サーバー c のボットは、SSL を使用して何かを読み取ることができる場合、1234-5678-9012-... ではなく as65a89as7df08 のようなジャンクを認識します。

iOS の優れている点は、HTML 5 と CSS を併用すると JS コードが読みにくくなることです。ユーザーは、デスクトップ ブラウザーでできるように、iPhone で右クリックして検査することはできません。バックエンド言語を使用して、ターミナル サーバーでパスワードを簡単に隠すことができます。

JavaScript がエンドユーザー (クライアント) によってハッキングされるのを防ぐことは現在のところ不可能です。すべてのエンドユーザーがハッカーになる可能性があります。何か他のことを見つけたら、将来の開発者が読めるようにここに投稿できます。

于 2016-03-17T23:17:19.800 に答える