PHP による APP インターフェイス作成のセキュリティ問題についてのディスカッション

この問題について議論する前に、確認しておきたいのは、インターネット プログラマーとして、フロントエンドであろうとバックエンドであろうと、http リクエストをある程度理解し、http の特性を理解し、明確に理解する必要があるということです。 http の内部 リクエストとレスポンスとは何ですか? Web サイトに Cookie、セッション、確認コードが存在する理由と、それらの意味と必要性について説明します。 APP インターフェイスのセキュリティについて議論することは、HTTP リクエストのセキュリティについて議論することになるためです。

私は通常、APP インターフェイスを通常のインターフェイス、フォーム インターフェイス、メンバー インターフェイスの 3 つのカテゴリに分類します

通常のインターフェイス

全般に焦点を当てます。ニュース リスト GET http://Example.com/index.php?module=news&action=list の取得などの GET リクエストの場合、収集や暴力的なクエリを防ぐために、PC 側は通常、次の処理: GET http://Example.com/index.php?module=news&action=list，为了防止采集或者暴力查询，我们PC端一般做如下处理:

1. 防止本站被它站file_get_contents，所以要识别user_agent，如果不是通过浏览器来访问的话直接不给看。
   
2. 如果别人通过伪造user_agent来访问的话，就通过单位时间ip的访问量来控制抓取方，可以写一套算法，如果再一个ip在前后一分钟多于多少次访问量来处理。但是，会有一种情况，即某个小区或公司内都是使用某一个IP的外网的话，这样搞就会自寻死路，所以还要配合浏览器中的cookie来处理
   总结: 请求头可以伪造，IP地址可以变更，cookie可以清空，基本上PC端是很难防这个问题的，比如淘宝，点评等大站的数据我也是经常去采的。

那APP端如何处理这个问题呢?我们可以抓点评APP的http请求包来看一下:

<code>GET http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 HTTP/1.1
Host: 114.80.165.113
Accept: */*
pragma-appid: 351091731
pragma-newtoken: c2032338f6abf96c8e2984db1655f2bac73b88f799e49aab4a426d414f994b5f
pragma-token: 73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff
pragma-dpid: 9214560561001942797
pragma-device: 566fe5aeb75a827967fbad8356608134ba98a4a6
Proxy-Connection: keep-alive
pragma-os: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0)
Accept-Language: zh-cn
network-type: wifi
User-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的服务器一般为Apache或Nignx,我们也可以在配置项中根据与客户端开发人员约定的一些自定义的Request头信息,比如上面的parama-*,在服务器配置项中可以获取到这些自定义的Request头信息,然后根据是否为约定好的Request信息,如果不是就rewrite到450;

但是,我们通过抓包既可获得全部请求头信息,这时可以完全模拟请求头信息来获取数据;

很多APP最多到此步既可获得该API接口的数据,而且是非常便于处理的json格式,而点评APP到此处直接返回的是一堆看上去是经过压缩的乱码数据:

这有点类似于PC端gzip，服务器端返回的是gzip的压缩数据，而浏览器来解压这个gzip来获取真正的数据，然后再显示出来;
我不知道点评的这个乱码数据是否也是这个原理，如果是的话，不得不说真的是"棒棒哒"，因为解压的算法是发生在自己的APP端，这不仅保证了数据的安全性，而且还节省带宽流量，加快的数据传输速度。具体是怎么样做的，暂时还不得而知；

表单接口

即类似html中的from表单，主要是往服务器提交数据的。一般是post方式的http请求，主要的危险是来自于强刷HTTP请求，撑爆数据库;在PC端我们一般通过验证码来解决这个问题,而在APP端,我能想到的也只有通过验证码的方式,只不过PC端的是把验证码存进session,而APP端是存进cache里面；但如果加上验证码的话，在用户体验上肯定会大打折扣，关于这一点肯定有更好的方式解决，具体怎么解决，暂时还不得而知；

会员接口

所谓会员接口，就是类似http://Example.com/index.php?module=users&action=info&user_id=333

1. このサイトが他のサイトによって file_get_contents にされるのを防ぐため、user_agent を識別する必要があります。ブラウザ経由でアクセスしない場合は、直接表示されません。
   
2. 他の IP が user_agent を偽造して訪問した場合、クローラーは単位時間あたりの IP 訪問数によって制御されます。別の IP が 1 分以上前に訪問した場合に、一連のアルゴリズムを作成できます。どれくらいのアクセス数を処理するのでしょうか？ただし、特定のコミュニティや企業が外部ネットワークに特定の IP を使用すると、行き止まりになるため、ブラウザの Cookie を使用して処理する必要があります概要: リクエストヘッダーの偽造、IP アドレスの変更、Cookie のクリアは可能です。たとえば、淘宝網や点評などの大手サイトからデータを収集する場合、基本的にこの問題を PC 側で防ぐのは困難です。

APP はこの問題をどのように処理しますか? Dianping APP の http リクエスト パケットを取得して見てみましょう:

rrreee

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

PHP のサーバーは通常、Apache または Nignx です。また、上記の parama-* など、クライアント開発者との合意に基づいて、設定項目でカスタマイズされた Request ヘッダー情報を使用することもできます。 、これらのカスタマイズされたリクエスト ヘッダー情報はサーバー設定項目で取得でき、それが合意されたリクエスト情報であるかどうかに基づいて、そうでない場合は 450 に書き換えられます

🎜 ただし、次の方法ですべてのリクエスト ヘッダー情報を取得できます。この時点で、リクエスト ヘッダー情報を完全にシミュレートしてデータを取得できます。🎜🎜 🎜多くのアプリはこのステップまでしか進められません。この API インターフェースからデータが取得され、処理が非常に簡単な json 形式ですが、Dianping APP は、まるで文字化けしたような大量のデータを直接返します。圧縮されています: 🎜🎜これは、PC 側の gzip に似ており、サーバー側は gzip 圧縮データを返します。 、そしてブラウザは gzip を解凍して実際のデータを取得し、それを表示します;🎜 レビュー内の文字化けしたデータもこの原則に基づいているのかどうかはわかりません。解凍アルゴリズムがアプリ側で実行されるため、データのセキュリティが確保されるだけでなく、帯域幅トラフィックが節約され、データ転送速度が向上します。それがどのように行われるかはまだ不明です。🎜🎜フォーム インターフェイス🎜🎜は、主にデータをサーバーに送信する HTML の from フォームに似ています。一般に、これはポスト http リクエストであり、主な危険は HTTP リクエストの強制とデータベースのバーストです。PC 側では通常、この問題は検証コードによって解決されますが、APP 側では次のことが考えられます。認証コードを渡す方法は、PC 側が認証コードをセッションに保存し、APP 側がそれをキャッシュに保存するだけですが、認証コードが追加されると、ユーザー エクスペリエンスが大きく損なわれることは間違いありません。これに対するより良い方法は解決されましたが、具体的な解決策はまだ不明です。 🎜

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

🎜 いわゆるメンバー インターフェイスは、http://Example.com/index.php? に似ています。 module=users&action=info&user_id= 333 リクエストを送信すると、サーバーは user_id に基づいて対応するメンバーシップ操作を直接実行します。これは、現在のメンバーシップ システム全体を相手に公開することに等しい、非常に危険なインターフェイス処理です。 user_id を変更すると、メンバーに対応するすべての操作を実行できます。 🎜通常、PC 側では暗号化された Cookie を使用してメンバーを識別し、セッションを維持します。ただし、Cookie はブラウザのローカル ストレージ機能に属します。 APP 側は使用できないため、トークン パラメーターを通じてメンバーを識別する必要があります。また、このトークンをどのように処理するか? 🎜🎜まず最初に、このインターフェースを暗号化する前に私が経験した 4 つの解決策について話させてください: 🎜🎜オプション 1🎜 特定の md5 組み合わせアルゴリズムについてアプリ開発者と合意し、それらが同じかどうかを比較します。 、同じでない場合は許可、拒否します 🎜 ただし、APP プログラムが逆コンパイルされると、これらの合意されたアルゴリズムが公開されます。このアルゴリズムを使用すると、インターフェイス リクエストをシミュレートすることができます。そして検証に合格します 🎜

オプション 2
データベース メンバーシップ テーブルのパスワードは、ランダム暗号化と二重暗号化を備えた md5 値です。ユーザーがログインすると、メンバーの対応する uid とパスワードが返されますが、パスワードは平文ですが、他のユーザーはログインできません。結局のところ、それは暗号化されており、インターフェイス user_id=333&token=aa37e10c7137ac849eab8a2d5020568f をリクエストするたびに、主キー uid を通じて現在の uid に対応するトークンをすぐに見つけることができます。 、そしてそれを比較してください user_id=333&token=aa37e10c7137ac849eab8a2d5020568f,通过主键uid可以很快的找到当前uid对应的token,然后再来比对;
但是这样想法是too yang too simple的,抓包的人虽然不能通过密文密码来登录该会员,然而一旦知道了这个token,除非用户更改密码,否则也可以一直通过这个token来操作该会员的相关接口;

方案三
通过对称加密算法，该加密算法对uid+网站公钥进行时效加密，在一定时效内可用。在会员登录成功时，服务器端对该ID加密后返回给客户端，客户端每次请求接口的时候带上该参数，服务器端通过解密认证；
但是这样做，也是不安全的。因为，防外不防内，听说这次的携程宕机就是因为内部离职人员的恶意操作。内部不怀好意的人员如果知道相应的算法规则后，就算没有数据库权限，也可以通过接口来操作相关会员；

方案四
会员登录的时候请求登录接口，然后服务器端返回给客户端一个token，该token生成的规则是 网站公钥 + 当前uid + 当前时间戳 + 一段随机数 しかし、この考え方はあまりにも単純すぎます パケットをキャプチャした人は、一度トークンを知ってしまうと、パスワードを変更しない限り、メンバーにログインできなくなります。常にトークンを使用してメンバーの関連インターフェイスを操作できます。
オプション 3

対称暗号化アルゴリズムを使用して、この暗号化アルゴリズムは uid+Web サイト公開キー に対して時間制限のある暗号化を実行し、特定の範囲内で使用できます。制限時間。メンバーがログインに成功すると、サーバーは ID を暗号化してクライアントに返し、クライアントはインターフェースを要求するたびにこのパラメーターを渡し、サーバーは復号化によって認証します

しかし、これも安全ではありません。なぜなら、外部から身を守るためには、内部から身を守ることはできないからです。今回のCtripの停止は、退職した内部職員の悪質な操作によるものだと聞きました。内部の悪意のある担当者が対応するアルゴリズム ルールを知っている場合、データベース権限を持っていない場合でも、インターフェイスを通じて関連するメンバーを操作できます。

オプション 4
1. メンバーがログインすると、ログイン インターフェイスを要求し、サーバーがトークンを返します。クライアントにとって、トークン生成ルールは Web サイト公開キー + 現在の UID + 現在のタイムスタンプ + 乱数 の二重暗号化です。必要に応じて、トークンをキャッシュに入れて待機するかどうかを決定します。自動的に期限切れになるまでの期間を設定するか、データベースに保存します (データベースに保存する場合は、ユーザーのログイン時間とログアウト時間を記録する別のテーブルを作成して、トークンが確実に有効になるようにします)。ユーザーが手動でログアウトする場合にのみ使用されます。
   セキュリティを確保するために、ユーザーは一定期間内に自動的にログアウトできるようにする必要があります。このソリューションは、外部および内部の保護を防ぐために Linux およびデータベースの権限管理と連携します。 JSON はクロスプラットフォーム機能に優れているため、データ形式には JSON 形式を使用するのが最適です。 JSON を生成するときは、オブジェクト (ディクショナリ) と配列という 2 つの json 形式に注意する必要があります。モバイル開発言語の PHP には同様の foreach がありませんが、オブジェクトに対する操作のみが可能です。通常はキー名を使用してキー値を取得します。
2. それが成功でも失敗でも。インターフェイスは明確なデータ ステータス情報を提供する必要があり、NULL を返すことはできません。NULL が返されると、IOS 側でクラッシュします。

上記では、内容の側面も含めて、PHP で APP インターフェイスを作成する際のセキュリティ問題についての最初の議論を紹介しました。PHP チュートリアルに興味のある友人に役立つことを願っています。

🎜