この問題について議論する前に、確認しておきたいのは、インターネット プログラマーとして、フロントエンドであろうとバックエンドであろうと、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端一般做如下处理:
那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
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 に書き換えられます
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 を暗号化してクライアントに返し、クライアントはインターフェースを要求するたびにこのパラメーターを渡し、サーバーは復号化によって認証します Web サイト公開キー + 現在の UID + 現在のタイムスタンプ + 乱数
の二重暗号化です。必要に応じて、トークンをキャッシュに入れて待機するかどうかを決定します。自動的に期限切れになるまでの期間を設定するか、データベースに保存します (データベースに保存する場合は、ユーザーのログイン時間とログアウト時間を記録する別のテーブルを作成して、トークンが確実に有効になるようにします)。ユーザーが手動でログアウトする場合にのみ使用されます。 上記では、内容の側面も含めて、PHP で APP インターフェイスを作成する際のセキュリティ問題についての最初の議論を紹介しました。PHP チュートリアルに興味のある友人に役立つことを願っています。
🎜