意図的に間違ったHTTP応答コードを返しますか？
簡単なREST APIを書いていて、モバイルクライアントのみへのアクセスを制限したいのです。つまり、悪意のあるユーザーがcurlを使用して不正なPOSTリクエスト。
もちろん、これは不可能です。ただし、ハッカーが成功するのを困難にする特定の対策があります。現在、私はクライアント側に保存されている秘密鍵ですべてのリクエストを暗号化しています（明らかに、これは理想的ではありませんが、iOSアプリのリバースエンジニアリングの難しさが、最も決定的なハッカー以外のすべてを阻止することを願っています）。
私が持っていた簡単なアイデアの1つは、不正な要求に対して間違ったHTTP応答コードを返すことです。 「401 Unauthorized」を返すのではなく、たとえば、 「305 Use Proxy」、つまりわざと混乱している。誰かがこれを行うことを考えたことがありますか？
誰かがこれを行うことを考えたことがありますか？
はい、実際にdefcon 21でこれについての話がありました（ video 、 slides ）。
彼らの結論は、攻撃的なセキュリティとして応答コードを操作すると、自動スキャナー、機能しないスキャナーが大幅に遅くなり、大量の誤検知または誤検知が発生する可能性があるということです（手動スキャンでは明らかにほとんど何もしません）。 。
あいまいさによるセキュリティが唯一の防御であってはなりませんが、多層防御として有益な場合があります（別の例：使用されているすべてのコンポーネントのバージョン番号をブロードキャストしないことをお勧めします）。
一方、REST APIは可能な限りクリーンである必要があり、故意に間違ったHTTPコードで応答することは、開発者や正当なクライアントを混乱させる可能性があります（これはブラウザの問題の少し少ないです） 、ユーザーには実際にはコードが表示されません。）このため、私はあなたのケースではそれをお勧めしませんが、それでも興味深いアイデアです。
実際に攻撃者を感知できるほど遅くすることはありませんが、プラットフォームで作業する将来の開発者を本当に不快にさせるでしょう。また、HTTPリクエストライブラリの特定のNice機能が不適切な情報で動作しているため、それほど機能しない場合もあります。
これは obcursityによるセキュリティ の非常に弱い形式です。このようなシステムを設計するときは、攻撃者を数十分ではなく数百年遅くすることを考えるべきです。
「401 Unauthorized」を返すのではなく、たとえば、 「305 Use Proxy」、つまりわざと混乱している。
はい、攻撃者を混乱させます。しかし、訓練を受けた人にとっては、2秒を超えてフラットにならない可能性があります。また、ステータスコードは、主にブルートフォースファイル名を使用する場合に限り、それほど有用ではありません。
有効なキーを持っているとしましょう。私の認証で200の範囲のコードが返されるのを観察できます。キーを少し変更し、すべてのリクエストで305秒を返すと、すぐに「うーん。開発者がめちゃくちゃになっているようだ」とすぐに思います。ランダムなコードを返す場合、それが故意だったことがわかり、無視します。
iOSアプリのリバースエンジニアリングの困難さは、最も決定的なハッカー以外のすべてを阻止する
はい、できますが、公開するのに必要なのは1つだけなので、再び遅くなります。
これは、あいまいさによるセキュリティです。つまり、セキュリティはまったく提供されません。あなたが提案しているソリューションは、攻撃者を遅くするだけで、攻撃者が自分のクライアントを使用するのを妨げることはありません。実際、実装によっては、要求を暗号化する方法によっては、暗号化システムの他の部分に対する攻撃が開かれるため、アプリケーションのセキュリティが低下する場合があります。許可されていないクライアントがAPI関数にアクセスするのを防ぐよりも、API関数自体を保護する（つまり、ペンをテストしてSQLインジェクションなどの攻撃から保護する）ために努力するほうがよいでしょう。
しかし、ユーザーISは既にプロトコルを使用しています。
問題は、ユーザーが実行できることのサーバーのインターフェースが安全でないことです！
あなたはあなたのサーバーが誰に送るデータを決定します！
（こんにちは、親愛なるオンライン新聞。はい、私はあなたを見ています！）
ユーザーがクライアントであると想定して設計します。あなたのコードではありません。 彼はそうです。どのクライアントを使用するかは問題ではありません。
アプリは、ユーザーのハードウェア制御下にあるCPUで実行されます。あなたのコードは単にコマンド/データのリストであり、ユーザーと彼のCPUは好きなように処理できます。それを処理するを含めない。
彼は自分のCPUの動作を決定します。アプリのコードをそのまま受け入れるという彼の恵みを、ブラインド実行の権利と間違えないでください。ここで信頼されているのはあなたです。その信頼は非常に短いものです。
特にこのような卑劣な戦術で。
いずれにしても、暗号化キーとすべてをユーザーに渡して、コードのバスケットのどこかにそれを置いているので、ユーザーがそれを使用しないことを期待します。 …DRMと同じように、これはヘビ油であり、動作することはありません。
キーを置く場所を見つけるのに1人人しかかかりません。 （例えば、それは私です。）他の人はそれをググる必要があります。
しかし、中間者攻撃からユーザーを保護するのではなく、ユーザーをプロトコルに対して暗号化することだけを考えていることに驚いています。
これが通常行われる理由を仮定します（はい、私はあなたに「コンテンツ業界」と話しています。）：ユーザーが敵である場合は、公平性とユーザーを騙して反発に対処する代わりに、双方にメリットがある。
PS：「あいまいさによるセキュリティ」の答えはすべて無視してください。これは誤動作であり、正しい動作をもたらしますが、それでも無効な仮定に基づいています。議論としてそれを使用することは、せいぜい素人であり、本当に有能ではありません。
実際には、allセキュリティはあいまいさを介して行われます。いくつかはもっとあいまいです（=偽装されています）。これが悪い実際の理由は、私たちが本当のセキュリティと呼んでいるものはバジリオン倍もあいまいで、actual（統計的）信頼できる非常に高い隠蔽性。非常に単純な隠蔽性は、誰かが何も考え出せない可能性が非常に高いのとは対照的です。
他の人がすでに説明したように、あいまいさによるセキュリティは攻撃者を遅くします。
あなたの特定のケースでは、私はそれがそれほど大きな影響を与えることはないと思います。この時点で、攻撃者はすでにアプリをリバースエンジニアリングして秘密鍵を抽出する必要がありました。つまり、あなたの攻撃者はばかではなく、彼が何をしているかを知っています。少しあいまいな場合は、実装するよりも時間がかかりません。
他の人が既に述べたように、あなたはObscurityによるセキュリティの使用を提案しています。この手法には目的がありますが、このアプローチを選択する前に、以下を検討してください。
- APIのテクニカルサポートを提供します。不正なHTTP応答コードを使用すると、あなた以外の誰かがサポートを提供することが困難になります。特定の状況が実際に適切な応答コードを送信しているか、それともあいまいなコードを送信しているかを検討する必要があります。サポートリクエストの唯一の連絡先であることにした場合、これは問題になりません。
- 「悪意のあるユーザー」とは何ですか？リクエストを悪意のあるものとして分類する場合は注意が必要です。悪影響を及ぼす可能性があります。 IPが悪意のあるトラフィックを送信していると判断され、対策が使用されているとします。ここで、同じIPが実際に数百または数千のユーザーを背後に持つプロキシであると仮定します。これで、それらすべてに対策が適用されました。これと同じ原則を適用して、ヘッダーや本文の悪意のあるアクティビティを特定できます。
- アプリケーションコードが最も遅くなります。最終的に「セキュリティ」ロジックに到達するには、リクエストがスタック全体をトラバースする必要があります。このアーキテクチャは拡張性が低く、速度が遅いです。不正なリクエストはできるだけ早く停止する必要があります。これは、Webアプリケーションファイアウォール（WAF）を使用するための前提です。
- アクセスの拡張。 APIが最初に設計されたよりも多くのクライアントからアクセスできるようになった場合、それらの新しいクライアントは、不正なHTTP応答コードの使用の可能性を認識する必要があります。
- 永続的な悪意のあるユーザー。他の人が述べたように、この手法はスピードバンプにすぎません。
より良いアプローチ
すべての既知の適切な要求をホワイトリストに登録することに時間を集中してください。これは、すべての潜在的な不良リクエストを特定するよりもはるかに簡単です。 （例として）HTTP動詞でフィルタリングしている場合、ホワイトリストに表示されていないものはすべて、HTTP 400やHTTP 405などの適切な応答コードをすぐに取得する必要があります。できれば、これはリクエストがアプリケーションコードに到達する前に発生します。
許可されたリクエストのホワイトリストに加えて、アプリケーションが OWASPガイドライン に基づいて保護されていることを確認します。あなたはOWASPで時間を費やしてはるかに良い結果を得るでしょう、それからあなたは悪意のあるユーザーが何であるかを決定し、あいまいなHTTP応答コードを返します。
私はそれをしません。通常、独自の標準を作成していることを意味します。
実際の意味へのhttp応答のマップを作成した後、APIは予測的です。 HTTP応答の変更は、数回の試行の後にあきらめる "ハッカー"に対しては機能する可能性がありますが、決定的なものに対しては機能しません。 APIを以前のタイプのみ、つまり11歳から保護しますか？私はそうは思いません。
開発者、おそらくテスター、特にグローバル標準に従って操作するのに慣れている人にとっては、かなりの混乱があります。
他の方法を選んでください。確かにいくつかあります。私は最近数週間、同じヘッドスクラッチャーと格闘していて、望ましい制限を達成するために少なくとも2つ程度信頼できる方法を考え出しました[ただし、ここに投稿することはできません]。
あなたが欲しいものを手に入れるには、間違いなくもっと効果的な方法があります。 APIを別の角度から見てみてください...もしあなたがハッカーであり、あなたの人生がそのAPIをハッキングすることに依存しているなら、あなたは成功するために何をしますか？あなたがそれを壊そうとするあなたの試みにあなたが欲求不満になるために何が起こるべきですか？
基本的に、権限のないクライアントがリクエストを送信するのを防ぐことはできません。可能な最も近いことは、クライアントで何らかの暗号チェックを行うことですが、シャーロックホームズが言ったように、「発明できるもの、他のものは発見できるもの」です。 （私はこれを確実に知っています。私は多くの場合、人々のクライアント側のセキュリティをクラックしたためです。）
代わりに、カスタムクライアントを使用して、誰でもisを使用できるようにAPIを構築します。フレンドリーにする。それによって何を失うのですか？攻撃者はあなたが何をしても攻撃します。APIを使いやすくすると、誰かが思いもよらないことを思いつき、サーバーを想像以上に大きくします。 APIと他のAPIの両方と通信するクライアントは何ができますか？無数の可能性があり、それらを許可することは本当にあなたを傷つけますか？
これを行わない理由としては、特にモバイルアプリの場合は、アプリが複数のプロキシを介して、たとえば電話会社などで既にサーバーと通信している可能性が高いためです。ほとんどの大企業は、ネットワーク上でプロキシを使用して、悪意のあるコンテンツからシステムを保護しようとします。多くの電話会社は、転送中のビデオや画像の品質を低下させています。また、プラットフォームでHTTP用のさまざまなシステムライブラリを使用しても役に立たなくなります。一般的に使用されるアプローチの1つは、名前のアドレスやクレジットカードの詳細をハッシュするなど、ユーザーが共有したくない情報からいくつかのキーまたはトークンを取得することです。このようにして、アプリがハッキングされた場合でも、人々はダウンロードしたランダムなプログラムに必要な情報を提供することに警戒し、証明された攻撃の共有能力を制限します。