APIインターフェースのデータセキュリティを確保する方法は？

フロントエンドとバックエンドの開発方法は分離されており、インターフェースを標準として使用して、インターフェースを促進、定義し、独自の機能を開発し、最終的に共同調整を行います。ネイティブAPP、Webアプリ、またはPC側のソフトウェアを開発している場合でも、フロントエンドとバックエンドが分離されている限り、ビジネスインタラクションのためにバックエンドによって提供されるインターフェイスを呼び出すことは避けられません。

Webページやアプリの場合、パッケージを取得する限り、リクエストによって取得されたデータを明確に知ることができ、サーバーを取得または攻撃するためにリクエストを偽造することができます。これはクローラーにとっても恩恵であり、簡単です。データをキャプチャします。では、これらの問題をどのように解決するのでしょうか。

インターフェイス署名

まず、偽造されたインターフェイスデータとインターフェイスの繰り返し呼び出しの問題について考えてみましょう。この問題を解決するには、インターフェイス署名スキームを使用する必要があります。

署名プロセス

ここに画像の説明を挿入

署名ルール

1. appidとappsecretをオフラインで割り当て、異なる発信者に異なるappidとappsecretを割り当てます。2。
タイムスタンプ（timestamp）を追加すると、データは5分以内に有効になります。3 。
一時的なシリアル番号nonceを追加します（繰り返し送信されないようにするため）。少なくとも10ビット。クエリインターフェイスの場合、シリアル番号はログのランディングにのみ使用されます。これは、後のログ検証に便利です。繰り返しの要求を避けるために、処理インターフェースの有効期間内にシリアル番号の一意性を検証する必要があります。
4.すべてのデータの署名情報である署名フィールド署名を追加します。
上記のフィールドは、リクエストヘッダーに配置されます。

署名の生成

署名フィールド生成ルール
すべての動的パラメーター=リクエストヘッダー部分+リクエストURLアドレス+リクエストリクエストパラメーター+リクエスト本文

上面的动态参数以key-value的格式存储，并以key值正序排序，进行拼接

最後に接続された文字列は、appSecret
署名= DigestUtils.md5DigestAsHex（sortParamsMap + appSecret）の文字列に接続
され、md5の不可逆暗号化が実行されます。

リクエストヘッダー

リクエストヘッダー= "appId = xxxx＆nonce = xxxx×tamp = xxxx＆sign = xxx"
リクエストヘッダーの4つのパラメーターを渡す必要があります。そうしないと、例外が直接報告されます。

リクエストURLアドレス

これは、
https：//mso.xxxx.com.cn/api/userなどのリクエストインターフェイスのプロトコルを含むアドレスです。

リクエストリクエストパラメータ

つまり、リクエストがGetメソッドの場合、着信パラメータが取得されます

リクエスト本文

つまり、リクエストがPostの場合、リクエスト本文の本文

从request inputstream中获取保存为String形式

署名アルゴリズムの実装

基本的な原則は実際には比較的単純で、各リクエストを処理するようにフィルタをカスタマイズします。全体的なプロセスは次のとおりです
。1）必要なヘッダーパラメータを確認します
。2）ヘッダーパラメータ、リクエストパラメータ、URLリクエストパス、リクエスト本文を取得します。、そしてこれらを置く値はソートのためにSortMapに配置されます
3）SortMapの値はスプライスされます
4）スプライスされた値は暗号化され、サインが生成されます
5）生成されたサインは正面から渡されたサインと比較されます終了し、同じでない場合はエラーが返されます

コードを見てみましょう

@Component
public class SignAuthFilter extends OncePerRequestFilter{
    
    
static final String FAVICON = "/favicon.ico";
static final String PREFIX = "attack:signature:";
}

ここに画像の説明を挿入
上記はフィルタークラスです。appSecretsの1つは、自社で取得する必要があります。その機能は、主にさまざまなクライアントアプリを区別することです。また、取得したappSecretを使用して署名署名に参加し、クライアントの要求署名がバックグラウンドによって制御されるようにします。また、クライアントごとに異なるappSecretを発行できます。

検証ヘッダーパラメータを見てみましょう

ここに画像の説明を挿入

上の図は、実際には値が渡されているかどうかを確認するためのものですが、実際には、リクエストの時間を確認するという非常に重要なポイントがあります。10分を超えると、リンクがタイムアウトし、他の人がこのリンクにアクセスしてリクエストすることはできません。これは、ホットリンクを防ぐためです。

各パラメータを取得する方法を見てみましょう

ここに画像の説明を挿入

上記のさまざまなパラメータを取得しましたが、これは比較的簡単です。符号の生成と符号の検証を見てみましょう。
ここに画像の説明を挿入

上記のプロセスでは、追加のセキュリティプロセスがあります。

ホットリンクを防ぐために、リンクを期限切れにすることができます
nonceパラメーターを使用して、繰り返し送信されないようにします

在签名验证成功后，判断是否重复提交；
原理就是结合redis，判断是否已经提交过

ここに画像の説明を挿入

総括する

現在、署名を使用して外部に提供するインターフェースを保護していますが、この保護は、他のユーザーがリクエストを改ざんしたり、リクエストをシミュレートしたりするのを防ぐだけです。

ただし、データ自体のセキュリティ保護はまだ不十分です。つまり、要求されたパラメータと返されたデータが他のユーザーによって傍受される可能性があり、これらのデータは、傍受されている限り、対応するビジネスデータはプレーンテキストです。取得できる。