PHP による APP インターフェイス作成のセキュリティ関連の問題に関するディスカッション (1)

PHP による APP インターフェイス作成のセキュリティ問題に関する議論 (1)

この問題について議論する前に、インターネット コード作成者として、フロントエンドであるかバックエンドであるかにかかわらず、次のことを確認してください。 http リクエストをある程度理解し、http の特性を理解し、http におけるリクエストとレスポンスが何であるかを明確に理解し、Web サイトに Cookie、セッション、確認コードが存在する理由とその必要性を理解しなければなりません。 APP インターフェイスのセキュリティについて説明することは、HTTP リクエストのセキュリティについて説明することになるためです。

私は通常、APP インターフェイスを通常のインターフェイス、フォーム インターフェイス、メンバー インターフェイスの 3 つのカテゴリに分類します。この記事では次のことに焦点を当てます。ディスカッション メンバーインターフェース

共通インターフェース

は、収集や暴力的なクエリを防ぐために、通常、ニュースリスト GET http://Example.com/index.php?module=news&action=list の取得などの GET リクエストです。次の処理:

1. このサイトが他のサイトから file_get_contents にされないようにするため、user_agent を識別する必要があります。ブラウザ経由でアクセスしない場合は、直接表示されません。
   
2. user_agent を偽造して他の人が訪問した場合、1 分以上前に別の IP があった場合、クローラーは単位時間あたりの IP 訪問数によって制御されます。その後、処理する訪問回数。 ただし、特定のコミュニティや企業が特定のIPの外部ネットワークを利用する事態が発生すると行き詰まってしまいますので、ブラウザのCookieと連携して対応する必要があります
   要約: リクエストヘッダーは偽造でき、IP アドレスは変更でき、Cookie はクリアできます。たとえば、この問題を PC 側で防ぐことは基本的に困難です。タオバオや点評 などの大手サイトからのデータ。

APP はこの問題をどのように処理しますか? Dianping APP の http 要求パッケージを取得して確認してみましょう:

<code>GET http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 HTTP/1.1Host: 114.80.165.113Accept: */*pragma-appid: 351091731pragma-newtoken: c2032338f6abf96c8e2984db1655f2bac73b88f799e49aab4a426d414f994b5fpragma-token: 73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ffpragma-dpid: 9214560561001942797pragma-device: 566fe5aeb75a827967fbad8356608134ba98a4a6Proxy-Connection: keep-alivepragma-os: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0)Accept-Language: zh-cnnetwork-type: wifiUser-Agent: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0) Paros/3.2.13 </code>

http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 に直接アクセスすると、サーバー側から直接ブロックし、450 エラーを返します。

PHP のサーバーは通常、クライアント開発者との合意に従って、構成項目でいくつかのカスタマイズされたリクエストを使用することもできます。上記の parama-* などのヘッダー情報は、サーバー設定項目でこれらのカスタマイズされたリクエスト ヘッダー情報を取得し、それが合意されたリクエスト情報であるかどうかに応じて 450 に書き換えることができます。パケットをキャプチャしてすべてのリクエスト ヘッダー情報を取得すると、リクエスト ヘッダー情報を完全にシミュレートしてデータを取得できます。

多くのアプリはこのステップで API インターフェイスを取得できます。これは処理が非常に簡単な json 形式であり、Dianping APP は圧縮されたように見える大量の文字化けしたデータを直接返します:

これは PC 側と多少似ています。 gzip、サーバー クライアントは gzip 圧縮データを返し、ブラウザは gzip を解凍して実際のデータを取得し、それを表示します。 レビュー内の文字化けしたデータもこの原則に基づいているのかどうかはわかりません。解凍アルゴリズムがアプリ自体で実行されるため、データのセキュリティが確保されるだけでなく、帯域幅が節約され、データ送信が高速化されるため、これは本当に「素晴らしい」と言わざるを得ません。これがどのように行われるかはまだ不明です。

フォーム インターフェイス

は、主にデータをサーバーに送信する HTML の from フォームに似ています。一般に、これはポスト http リクエストです。主な危険は、HTTP リクエストの強制とデータベースのバーストです。PC 側では、通常、検証コードによってこの問題を解決しますが、APP 側では、これが唯一考えられます。検証コードを渡す方法は、PC 側が検証コードをセッションに保存し、APP 側がキャッシュに保存するだけですが、検証コードが追加されると、ユーザー エクスペリエンスが大きく損なわれることは間違いありません。これを解決するためのより良い方法はまだ不明です。

メンバー インターフェイス

いわゆるメンバー インターフェイスは、

と同様のリクエストであり、サーバーに直接送信されます。 user_id に基づいて対応するメンバーシップ操作を実行しますが、これは現在のメンバーシップシステム全体を公開することに等しい非常に危険なインターフェイス処理です。相手が user_id を変更する限り、すべてのメンバーに対応するインターフェイスを操作できます。

通常、PC 側では暗号化された Cookie を使用してメンバーを識別し、セッションを維持します。ただし、Cookie はブラウザのローカル ストレージ機能に属します。 APP 側は使用できないため、トークン パラメーターを通じてメンバーを識別する必要があります。また、このトークンをどのように処理するか? http://Example.com/index.php?module=users&action=info&user_id=333
まず最初に、このインターフェイスを暗号化する前に行った 4 つの解決策について話しましょう:

オプション 1

APP 開発者 md5 と特定の合意に同意する ただし、APP プログラムが逆コンパイルされると、特に Android APP では、これらの合意されたアルゴリズムが公開されてしまいます。このアルゴリズムを使用すると、インターフェイスのリクエストをシミュレートして検証に合格することが完全に可能です。

オプション 2
データベース メンバーシップ テーブルのパスワードは、ランダム暗号化と二重暗号化を備えた md5 値であり、ユーザーがログインすると、メンバーの対応する uid とパスワード、パスワードが返されます。これは平文ですが、他の人がそれを知っていればログインできません。結局のところ、インターフェース user_id=333&token=aa37e10c7137ac849eab8a2d5020568f をリクエストするたびに、主キー uid を通じて現在の uid に対応するトークンをすぐに見つけることができます。
しかし、この考えはあまりにも単純すぎます。パケットをキャプチャした人は、一度トークンを知ってしまえば、パスワードを変更しない限り、メンバーにログインできません。常にトークンを使用してメンバーの関連情報を操作できます。インターフェイス;

オプション 3
は、uid 网站公钥 で時間に敏感な暗号化を実行する対称暗号化アルゴリズムを使用します。一定の制限時間内に。メンバーがログインに成功すると、サーバーは ID を暗号化してクライアントに返し、クライアントはインターフェイスを要求するたびにこのパラメーターを渡し、サーバーは復号化によって認証します。
ただし、これも安全ではありません。なぜなら、外部から身を守るためには、内部から身を守ることはできないからです。今回のCtripの停止は、退職した内部職員の悪質な操作によるものだと聞きました。内部の悪意のある担当者が対応するアルゴリズム ルールを知っている場合、データベース権限を持たない場合でも、メンバーがログインするときに

オプション 4
リクエストを介して関連するメンバーを操作できます。インターフェイスにログインすると、サーバーはトークンをクライアントに返します。トークンを生成するルールは 网站公钥 当前uid 当前时间戳 一段随机数 です。必要に応じて、トークンをキャッシュに入れて一定期間待機するかどうかを決定します。自動的に期限切れになるまでの時間をデータベースに保存するか (データベースに保存する場合は、ユーザーのログイン時間とログアウト時間を記録する別のテーブルを作成します)、ユーザーがログアウトするときに変更して、トークンが確実に有効になるようにします。ユーザーが手動でログアウトしてからログインするまでの間のみ使用できます。
セキュリティを確保するには、一定期間内にユーザーが自動的にログアウトできるようにする必要があります。このソリューションを Linux とデータベースの権限管理と組み合わせると、外部と内部の両方の保護を防ぐことができます。

開発上の注意事項他のインターフェイスの

1. JSON はクロスプラットフォームのパフォーマンスが優れているため、JSON 形式のデータを使用するのが最善です。 JSON を生成するときは、オブジェクト (ディクショナリ) と配列という 2 つの json 形式に注意する必要があります。モバイル開発言語の PHP には同様の foreach がありませんが、オブジェクトに対する操作のみが可能です。通常はキー名を使用してキー値を取得します。
   
2. 成功か失敗か。インターフェイスは明確なデータ ステータス情報を提供する必要があり、NULL を返すことはできません。NULL が返されると、IOS 側でクラッシュします。