記事ディレクトリ

jaxクロスドメインの問題を解決する

jaxクロスドメインの問題を解決する

次のコードでは、ajaxを使用してhttpリクエストを開始します。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
<script>
    //基于jQuery 里面的ajax 来进行使用

    $.ajax({
     
        //$是jQuery中已经定义好了的一个对象（变量）

        // jQuery中的所有的api都是$对象的方法
        type:'GET',
        url:'https://www.baidu.com',
        success:function (data,status) {
     
     
            //data就是响应的body,status 就是响应的状态码
            console.log(status);
            console.log(data);
        }
    });
</script>
</body>
</html>

上記のコードのURLをBaiduのURLに変更して再度実行すると、次のような状況が発生します。
ここに画像の説明を挿入
これはクロスドメインの問題です。
つまり、セキュリティを確保するために、ajaxでは、ajaxリクエストを開始するページとajaxリクエストを受け入れるサーバーが同じドメイン名/アドレスである必要があります。
要求を開始するページに対応するドメイン名（ドメイン名Aと仮定）と要求を受け入れるサーバーのドメイン名（ドメイン名Bと仮定）が異なる場合、それは順次クロスドメイン要求と見なされます。
ajaxは、デフォルトではクロスドメインアクセスを許可していません。
上記のコードでは、ドメイン名Aはローカルドメイン名に対応し、ドメイン名BはBaiduのドメイン名であり、2つは異なります。クロスドメインと見なされ、エラーが報告されます。
前回のブログでは、ajaxを使用してクラウドサーバーをリクエストしました。ローカルページでのクラウドサーバーへのアクセスもクロスドメインアクセスですが、最後のクラウドサーバーは特別な処理が行われ、ajaxがクロスドメインできないという制限が解消されました。。
処理は次のとおりです
ここに画像の説明を挿入
。サーバーへのローカルアクセスを許可するように、サーバーコードでクロスドメインを構成します。

ソケットコンストラクトhttpリクエスト

HTTPプロトコルもTCPに基づいていますが、TCPに基づいて、HTTPで合意された形式に従って文字列が作成され、送信されます。文字列を「アセンブル」し、Javaのソケットを介してリクエストを送信できます。
コードは次のように表示されます。

import com.sun.xml.internal.ws.api.model.wsdl.WSDLOutput;


import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;

public class HttpClient {
    
    
    private Socket socket;
    private String ip;
    private int port;
    public  HttpClient(String ip,int port) throws IOException {
    
    
       this.ip=ip;
       this.port=port;
        socket=new Socket(ip,port);

    }

    public String get(String url) throws IOException {
    
    
        StringBuilder request=new StringBuilder();
        //构造首行
        request.append("GET"+url+"HTTP/1.1\n");
        //构造请求头header
        request.append("Host:"+ip+":"+port+"\n");
        //构造空行
        request.append("\n");

        //GET 请求不需要body

        OutputStream outputStream=socket.getOutputStream();
        //OutputStream 是一个字节流 ，以字节为单位进行写入
        // 因此需要把StringBuilder 转换成一个字节数组
        outputStream.write(request.toString().getBytes());

        //读取响应
        InputStream inputStream=socket.getInputStream();
        //创建一个1M大小的缓冲区，用来存放响应数据
        byte[] buffer=new byte[1024*1024];

        //n 表示实际读到的字符串
        int n=inputStream.read(buffer);

        return new String(buffer,0,n);

    }

    public String post(String url,String body) throws IOException {
    
    
        StringBuilder request=new StringBuilder();
        //构造首行
        request.append("POST"+url+"HTTP/1.1\n");

        //构造header
        request.append("Host:"+ip+":"+port+"\n");
        request.append("Context-type:text/plain\n");
        request.append("Content-Length:"+body.getBytes().length+"\n");


        //构造空行
        request.append("\n");
        //构造body
        request.append(body);

        //发送请求

        OutputStream outputStream=socket.getOutputStream();
        outputStream.write(request.toString().getBytes());
        //读取响应
        InputStream inputStream=socket.getInputStream();
        byte[] buffer=new byte[1024*1024];
        int n=inputStream.read(buffer);
        return new String(buffer,0,n,"utf-8");
    }

    public static void main(String[] args) throws IOException {
    
    
        HttpClient httpClient=new HttpClient("42.192.83.143",8089);
        String resp= httpClient.get("/AjaxMockServer/info");
        System.out.println(resp);
    }
}

HTTPSプロトコル

HTTPSHTTPS（、Hypertext Security Transfer Protocol）のフルネームは何ですかHypertext Transfer Protocol over Secure Socket Layer。HTTPSはネットワークを介した安全な通信のための伝送プロトコルです。このプロトコルはHTTPプロトコルに基づいており、暗号化レイヤーを導入し、SSL/TLSを使用してデータパケットを暗号化します。。
HTTPSの主な機能は、データ送信のプライバシーと整合性を保護するためにWebサイトサーバーに認証を提供することです。

データ暗号化関連の概念

平文：送信される実際のデータ暗号文：暗号化
後のメッセージ
暗号化：平文を暗号
文に変換復号化：暗号文を平文に変換
キー（yao、4トーン）：暗号化と復号化の過程で、このプロセスを支援する中間データ、そのようなデータはキーと呼ばれます

HTTPSのしくみ

セキュリティを確保するため数据に暗号化する必要があるため、ネットワーク送信では平文は直接送信されなくなり、暗号化された暗号文が送信されます。

暗号化する方法はたくさんありますが、全体を2つのカテゴリに分類できます对称加密。非对称加密

対称暗号化：
対称暗号化は実際にはキーが1つしかないため、平文と暗号文を相互に変換できます。

例：

XOR演算を使用して、単純な対称暗号化を実装できます。平文を8888に、キーを1234に設定し、2つをXORして暗号文9834を取得します。暗号文とキーのXORを復号化して、平文8888を取得できます。

対称暗号化により、データを保護することができます。ハッカーがルーターに侵入した場合でも、リクエストの暗号文コンテンツのみを取得できます。
ここに画像の説明を挿入
上記の方法は良いのですが、鍵の合意方法に欠点がありますか？クライアントに最初にキーを生成させ、次にクライアントがサーバーに接続するときに、キーをサーバーに渡してサーバーに保存させることしかできません。
しかし、サーバーとクライアントが接続するときにハッカーがキーを傍受した場合、データを安全に保つにはどうすればよいでしょうか。キーを暗号化して送信すること
はできますが、鶏が先か卵が先かという問題が発生し、暗号化を継続できないため、非対称暗号化を採用しています。

非対称暗号化：

非対称暗号化はキーのペアを介して、平文と暗号文が相互に変換されます。
これらの2つのキーは、1つはと呼ばれ公钥、もう1つはと呼ばれ私钥ます。

平文は公開鍵で暗号化され、暗号文になります。
暗号文を秘密鍵で復号化して平文に変換します。
逆に使用して
、平文を秘密鍵で暗号化して暗号文に変換することもできます。
暗号文は公開鍵によって復号化され、平文になります。

ここでの公開鍵と秘密鍵は、実際のメールボックスと比較できます〜公開鍵はメールボックスのロックのようなものであり、秘密鍵はロックを作成するキーのようなものです

非対称暗号化のデメリット：
対称暗号化よりも非常に遅く、はるかに遅い

非対称暗号化プロセス

サーバーは公開鍵（公開鍵）をクライアントに直接送信します。クライアントは公開鍵を取得した後、公開鍵で暗号化してサーバーに送信し、サーバーは秘密鍵を復号化して鍵を取得します。その後、鍵を受信したメッセージは鍵で暗号化されてクライアントに送信され、クライアントは鍵を受信した後、その鍵を使用して対称暗号化によりデータをクライアントに送信します。
ここに画像の説明を挿入
まとめ：

サーバーとクライアントは接続し、公開鍵をクライアントに送信します。
クライアントはローカルでキーを生成し、公開キーで暗号化してサーバーに送信します。
中間ネットワークデバイス（ルーターなど）には秘密鍵がないため、データが傍受されても内部データを復元できず、対称鍵を取得する方法がありません。
サーバーは独自の秘密鍵を使用して復号化し、クライアントから送信された鍵を復元してから、この鍵を使用して応答データを暗号化し、クライアントに返します。
後続のクライアントとサーバーの通信は、対称暗号化を使用してのみ暗号化できます。

非対称暗号化が導入されたのに、なぜ対称暗号化を使い続けるのですか？？リソースの消費と実行速度がはるかに遅い
ため、実際の状況では、クライアントとサーバーが対話するデータは非常に大きくなります。すべてが非対称暗号化を使用する場合、全体的な伝送速度は非常に遅くなります。したがって、サーバーに非対称暗号化を介して鍵を取得させ、次に対称暗号化を使用して伝送効率を向上させるだけで済みます。对称加密非对称加密

残っている問題

クライアントはどのようにそれを取得し公钥ますか？クライアントが取得するものが、ハッカーによって偽造されたものではなく、本物で信頼できる
ものであることを確認するにはどうすればよいですか？公钥？

誰でも公開鍵と秘密鍵のペアを生成できます。サーバーが生成できるだけでなく、ハッカーが自分で生成できます。

次のシナリオで、ハッカーが中間ネットワークデバイスにハッキングし、自分で公開pub2鍵と秘密鍵のペアを生成したとしpri2ます。サーバーが公開pub1鍵と秘密鍵を生成しましたpri1。サーバーは中間デバイスを介してサーバーに公開鍵を要求し、サーバーは公開鍵pub1を返します。これはハッカーによって傍受され、ハッカーは偽造された公開鍵pub2をクライアントに送信します。
ここに画像の説明を挿入
次に、クライアントpub2は暗号文を暗号化し、暗号文を中間デバイスに送信します。ハッカーはpri2暗号文を復号化して実際のキーを取得し、暗号文の暗号化を続行しpub1てサーバーに送信しますpri1。キーを取得します。このとき、サーバーはキーを取得しましたが、ハッカーも知らないうちにキーを取得しました。したがって、その後の暗号化されたデータ送信は役に立たず、ハッカーはすべてのプレーンテキストデータを直接取得できます。
これはとも呼ばれ中间人攻击ます。
ここに画像の説明を挿入
では、この問題を解決するにはどうすればよいでしょうか。？
この問題を解決するには、证书机制。

証明書メカニズム

クライアントとサーバーが初めて接続するとき、サーバーはクライアントに証明書を返します。
この証明書には、公開鍵だけでなく、WebサイトのID情報も含まれています。

ワークフロー：

サーバーは最初に公開鍵と秘密鍵のペアを生成し、次にサードパーティ機関からの証明書を申請します。次に、サーバーは公開鍵を証明書に入れて、証明書をクライアントに送信します。ハッカーが中間デバイスに侵入して証明書を取得したとしても、証明書の検証が非常に厳しいため、ハッカーが証明書を偽造することは非常に困難です。証明書が偽造された場合でも、クライアントはサードパーティにアクセスできます。検証のための組織。したがって、クライアントは実際の公開鍵を正常に取得し、鍵を暗号化してサーバーに送信できます。ハッカーは秘密鍵を持っていないため、傍受されたデータを解読することはできません。したがって、サーバーは暗号化されたキーを正常に取得できます。

これにより、非対称暗号化のセキュリティが確保されます。
ここに画像の説明を挿入

このプロセスは、SSL/TLSのハンドシェイクプロセスでもあります

証明書の内容：
証明書は、次の情報を含む構造化された文字列と見なすことができます。

証明書発行機関
証明書の有効期間
公開鍵
証明書の所有者
サイン
…

証明書の検証：

証明書の有効期間が終了したかどうかを確認します
証明書発行機関が信頼できるかどうかを判断します
証明書が改ざんされているかどうかを判断します（この判断プロセスはより複雑であり、ここでは紹介しません）
…

ブラウザで証明書を表示する：
Chromeブラウザで、右上隅の設定を開き、証明書を検索します。[証明書の管理]ページで、[信頼されたルート証明機関]をクリックすると、現在のブラウザで証明書情報を確認できます。
ここに画像の説明を挿入

要約する

HTTPSの作業プロセス全体に関係する3つのキーセットがあります
第一组（非对称加密）。証明書が改ざんされているかどうかを確認するために使用されます。サーバーは秘密キーを保持し（秘密キーは証明書の登録時に取得されます）、クライアントは
公開鍵（オペレーティングシステムには信頼できるCA証明機関が含まれており、対応する公開鍵も保持しています）。サーバーはこの秘密鍵を使用し
て証明書の署名を暗号化します。クライアントは公開鍵を復号化しての署名を取得します。証明書の内容が改ざんされているかどうかを確認するために、証明書。
第二组（非对称加密）：対称暗号化キーを生成するためのネゴシエーションに使用されます。サーバーはこの秘密キーと公開キーのペアのセットを生成し、公開キー
をに渡します。次に、クライアントはこの公開鍵を使用して、生成された対称暗号化鍵を暗号化します。これはサーバーに送信され、サーバー
は秘密鍵を復号化して対称暗号化鍵を取得します。
第三组（对称加密）：クライアントによって送信された後続のデータとサーバーは、この対称鍵によって暗号化および復号化されます。

参考記事：
https ：//leheavengame.com/article/622e001dcbba634f3982e4cb

JavaWeb〜ajaxクロスドメイン問題/ソケット構築リクエスト/Httpsプロトコル/非対称暗号化プロセス/証明書メカニズム