意図的に間違ったHTTPレスポンスコードを返す?

私は簡単なREST APIを書いています、そして私は私のモバイルクライアントだけにアクセスを制限したいです。言い換えれば、悪意のあるユーザーが、不正なPOST要求を行うためにcurlを使用する。

もちろん、これは不可能です。ただし、ハッカーが成功するのを困難にする特定の対策があります。現在のところ、私はすべての要求をクライアント側に格納された秘密鍵で暗号化しています(明らかにこれは理想的ではありませんが、iOSアプリのリバースエンジニアリングの困難さが最も決定的なハッカー以外のすべてを阻止します)。

私が持っていた一つの簡単なアイデアは、不正なリクエストに対して間違ったHTTPレスポンスコードを返すことです。 「401 Unauthorized」を返すのではなく、なぜ返さないのか。 「305 Use Proxy」、つまり意図的に混乱している。誰もがこれをやることについて考えたことがありますか?

36
コメントは詳細な議論のためではありません。この会話はされていますチャットに移動しました。
追加された 著者 Rory Alsop,
@Pascal 403の代わりに404を使用することを考えています。 HTTP規格明示的にこれを許可することで、リソースへのアクセスが許可されていないユーザーにそのリソースの存在を明らかにしないようにします。認証を必要とする他の場所のパターンと一致するすべての場所でそれを必要とする場合、401が存在に関する情報を漏らさないようにすることができます。 (このコメントを再投稿しても大丈夫です。これは重要な情報だと思います。)
追加された 著者 jpmc26,
あなたが正しいHTTPステータスコードを返さないのなら、厳密に言えば、あなたはHTTPを話していないと言うかもしれません。それで、あなたがこれまで行ったならば、あなたは単にあなた自身の完全に異なるプロトコルを実行するかもしれません...
追加された 著者 Magnus Johansson,
@Pascalこれは、認証されていないか無許可のときにプライベートリポジトリにアクセスしようとするときにGitHubがとるアプローチです(少なくとも)。
追加された 著者 Alexandre Amato,
それは「あいまいさによるセキュリティ」と呼ばれています。遅くなることがありますが、それだけです。
追加された 著者 sluukkonen,
その価値のために、私はHTTPの公式文書のどこかを読みました(申し訳ありませんが、ソースを覚えていないでください)。
追加された 著者 Pascal,

11 答え

誰かがこれをやることを考えたことがありますか?

はい、実際にはdefcon 21(動画スライド)。

結論として、攻撃的なセキュリティとしてレスポンスコードを使用すると、自動スキャナー、正常に機能しないスキャナー、および大量の偽陽性または偽陰性が大幅に遅くなる可能性があります(手動スキャンではほとんど何もしません) 。

あいまいさによるセキュリティだけがあなたの唯一の防御であるべきではありませんが、それは徹底的な防御として有益であるかもしれません(別の例:それはすべての使用されたコンポーネントのバージョン番号を放送しないことを推奨します)

その一方で、REST APIはできるだけクリーンにする必要があり、意図的に間違ったHTTPコードで返信することは開発者や正当なクライアントにとっては混乱を招く可能性がありますコード)。このため、私はあなたのケースでそれをお勧めしませんが、それはまだ面白いアイデアです。

82
追加された
私は「曖昧さによるセキュリティ」の侵入に対する正当性(つまり、スクリプトのキッズを追い出すこと)を正当性として認めていますが、あまりにも多すぎると実際のアプリケーションのセキュリティに深刻な悪影響を及ぼすと思います。暗号と情報セキュリティという2つの関連分野のうち、一方は「あいまいさ」に依存しますが、もう一方は依存しません。ちなみに、することは、たいていの場合容易になります。さらに、あいまいさはすべての当事者(あなたが支払ったペンテスターを含む)に適用され、さらに複雑なエルゴの攻撃方法をもたらします。
追加された 著者 Ryan Versaw,
@ypercubeᵀᴹコメントを読んだ今、私​​は言っているように聞こえますが、私は正反対を意味していました - 暗号学では、Kerckhoffsの原則は本質的に '曖昧さによるセキュリティ'の反対です。
追加された 著者 Ryan Versaw,
@ K.Steff機密扱いの暗号化アルゴリズムを使用するすべての政府は、暗号化に「不明瞭性によるセキュリティ」を使用しています。
追加された 著者 mostlyinformed,
@ K.Steff 「暗号化は曖昧さに頼っています」 「ステガノグラフィ」を書くつもりでしたか?
追加された 著者 cupe,
これは非常に実用的な答えだと思います。誰かがセキュリティをブログなどで悪いと判断したために、セキュリティが不明瞭になると怒ります。現実の世界では、それは間違いなく役に立つことがあります。それはあなたのバッグの唯一のトリックではあり得ない、それがすべてです。
追加された 著者 corsiKa,
開発者については+1。私がシステムに変更を加え、突然404になったところで突然に200を得たとき、私は別の応答を送信することが決定された場所を特定するほくろのゲームをしました。私がOPに言えることは、あなたがこれをすることに決めたならば、それを適切に文書化してくださいまたはあなたの名前が将来しばらくの間泥になることです
追加された 著者 booboo,

それは実際には攻撃者をかなりの量まで遅くすることはありませんが、あなたのプラットフォームで作業する将来の開発者を本当にあなたに悩ませてしまうでしょう。また、HTTPリクエストライブラリの特定の優れた機能は、誤った情報で動作しているため、それほど良くない場合があります。

これは不明瞭によるセキュリティの非常に弱い形式です。このようなシステムを設計するとき、あなたは攻撃者を数十分ではなく数百年遅くすることを考えるべきです - さもなければあなたはまだ失うことになるでしょう。

57
追加された
@Nacht「あいまいさによるセキュリティ」が唯一の可能性です。あなたがシステムを保護することができず、あなたがそれを安全にする必要があるならば、それを実装しないでください。広告のようなビジネスモデルについても同様です。
追加された 著者 Ryan Versaw,
「このようなシステムを設計する際には、攻撃者を数十分ではなく数百年も遅くすることを考えるべきです。そうしなければ、やはり負けることになります。」熱心で、決心した、巧みな攻撃者に対して?はい。しかし、自動化された攻撃プログラムや人間の攻撃者を打ち負かすためには、最も簡単で最も脆弱な標的を利用するだけでよいのです。いいえ。彼らはおそらく正しい方向に動くでしょう。また、BTWは、展開できる能力のある「本当の」セキュリティ対策を破ることに直面しているため、より意図的な脅威を見つけるための可視性をよりよく提供します。
追加された 著者 mostlyinformed,
この問題は、不明瞭によるセキュリティが唯一の可能性であるシナリオについてです。あなたの最初の段落は良いですが、あなたの2番目の段落は無関係です。
追加された 著者 Francisco Corrales Morales,
@Cruncher、いや、あいまいさによるセキュリティによって、誰かが何百年も遅くなることは決してありません。彼はあなたが「適切な」セキュリティを必要としていると言っています、それはOPの現在の設計では不可能です。
追加された 著者 Francisco Corrales Morales,
@mostltinformed OPは、(不正な)リクエストを行うためにcurlまたはその他の方法を使用している悪意のあるユーザーについて具体的に述べました。攻撃者は、とりわけiOSアプリをリバースエンジニアリングして、とりわけ攻撃を実行するために必要なキーを入手しました。戻りコードに関する軽微な不便さによって止められることはありません。
追加された 著者 Robert,
過酷な、しかしただ。私はそれが好きです :) 。それは弱さの本質を展望に入れる。
追加された 著者 J.A.K.,
これは本当に攻撃者に関する強い仮定にかかっていると思います。確かにそれはサイトを特に狙って熟練した攻撃者を遅くしないでしょう、しかしそれは自動化されたスキャンの試みまたは応答コードに混乱することになるかもしれない遅い攻撃者を妨害することができます。そのため、必ずしもセキュリティが強化されるわけではありませんが、改善することができます。問題は、それほど決定的ではない攻撃者を遅くする可能性があるものをすべて実装する価値があるかどうかです。
追加された 著者 Kat,
@Nacht 2番目のものは無関係ですか?非常に関連性があります。彼が言っているのは、あいまいさを利用してセキュリティを使用するのであれば、それはより良いあいまいさを排除するほうがよいということです。彼は、この特定の防御が洗練された誰かを非常に遅くさせることは全くないと言っています
追加された 著者 Cruncher,

「401 Unauthorized」を返すのではなく、なぜ返さないのか。 「305 Use Proxy」、つまり意図的に混乱している。

はい、それは攻撃者を混乱させるでしょう。しかし訓練された人にとっては、2秒以上平らではないかもしれません。ステータスコードはそれほど有用ではありません。主にファイル名を強引に使用する場合だけです。

私が有効な鍵を持っているとしたら、私の認証用に200個の範囲のコードを返すことがわかります。もし私が私の鍵を少し変更し、そしてあなたがどちらかの要求に対して305秒を返すならば、私はすぐに「うーん、開発者がめちゃくちゃになったかもしれないように思える」と思うでしょう。あなたがランダムなコードを返すなら、私はそれが意図的であったことを知っているでしょう、そして私はただそれらを無視します。

iOSアプリのリバースエンジニアリングの難しさが、最も決定的なハッカー以外のすべてを阻止することを願っています

はい、できますが、公開するには1つしか必要ないので、やはり遅くなります

8
追加された
昔、私はこの種のことを試みる人に攻撃を仕掛けるコードを書いた。結局、それは賢いアイデアではないということを学びました。はるかに健全な要求が悪いかもしれません - >ファイアウォールレベルで100時間のIP禁止
追加された 著者 Joshua,

これはあいまいさによるセキュリティです。つまり、あまりセキュリティを提供しないということです。あなたが提案している解決策は攻撃者を遅くするだけで、彼らが彼ら自身のクライアントを使用することを防ぎません。 実際、実装によっては、リクエストを暗号化する方法によって、暗号システムの他の部分への攻撃が発生し、アプリケーションのセキュリティが低下する可能性があります。許可されていないクライアントがそれらにアクセスするのを防ぐことを試みるよりも、API関数自体を保護する(つまり、それらをペンテストしてSqlインジェクションのような攻撃から保護する)ことを試みるほうがよいでしょう。

6
追加された
これは元の質問とはまったく異なる質問であり、それでもまだ困難です。ユーザーが実際にそして本当に広告を見たかどうかを判断するには、サーバーサイドのメカニズムが必要です。広告のリクエストが受信されたときのタイムスタンプと広告の長さを含むデジタル署名されたトークンを送信するかもしれません。その後、ユーザーが保護されたエンドポイントを要求したいときに、そのトークンを再送信して検証する必要があります。 DRMソリューションを研究したいと思います。暗号化の経験なしにこれを自分で転がすのは、安全に行うのが難しいでしょう。
追加された 著者 Denis,
私は混乱しています。誰もがOPが本当のセキュリティを必要としていると言っています、そして、NOBODYはまだそれをする方法を述べました。問題は、広告が視聴されていない限りエンドポイントが呼び出されないようにすることです。彼らはどのようにこれを達成しますか?
追加された 著者 Cruncher,

しかし、ユーザーはすでにあなたのプロトコルを使っています。

Your problem is that your server’s interface of what the user can do is not secure!
You decide what data your server sends out to whom!
(Hello, dear online newspapers. Yes, I’m looking at you!)

ユーザーをクライアントと想定して設計します。あなたのコードではありません。 彼がそうだからどんなクライアントが使われてもかまいません。
アプリは、ユーザーのハードウェア制御下にあるCPU上で実行されます。あなたのコードは単にコマンド/データのリストであり、ユーザーと彼のCPUはそれを処理することができます。処理しないを含む
彼は自分のCPUが何をするかを決めます。自分のアプリコードをそのまま受け入れるという彼の恩恵を、盲目的に実行する権利と間違えないでください。あなたはここで信頼されている人であり、その信頼は非常に軽快です。
特にこのような気まぐれな戦術では。

いずれにせよ:あなたは暗号化キーとすべてをユーザに渡し、それを自分のコードバスケットのどこかに置くので、彼が自分でそれを使わないことを期待します。 …DRMと同じように、これはヘビの油であり、絶対に機能しません。
あなたが鍵をどこに置いたかを見つけるのに1人の人しか必要としません。他のみんなはそれをグーグルしなければなりません。

ただし、中間者攻撃からユーザーを保護するのではなく、ユーザーに対して プロトコルを暗号化することだけを考えていることに驚きました。
これが通常行われる理由を想定すると(はい、私はまたあなたに「コンテンツ業界」と話しています)。ユーザーをリッピングしてバックラッシュに対処する必要はありません。

P.S .:「曖昧さによるセキュリティ」の答えをすべて無視する。これは正しい行動をもたらす誤謬ですが、それでも無効な仮定に基づいています。これを引数として使用することは、せいぜい、素人的であり、本当に有能ではありません。
実際、すべてのセキュリティは不明瞭なものです。もう少しあいまいな(=偽装された)ものもあります。これが悪い実際の理由は、私たちが本当のセキュリティと呼ぶものは、非常にあいまいなのではなく、非常にあいまいで、実際には(統計的に)信頼できるほど高い不明瞭さを与えるからです単純な不明瞭さは、誰かが何からも思い付くことができないほど単純な方法です。

4
追加された
@ DavidRicherby:あたかもそれが反論としてのように私のまさしくその点を繰り返しています。すべてのセキュリティはクラック/修正するのにかかる作業の量(別名不明瞭)によってのみ異なるということが私のポイントです。セキュリティ」。
追加された 著者 NotoriousWebmaster,
@ DavidRicherby: の言ったことを話していますか。 ^^おい、私はあなたに同意します! (それともあなたは私と一緒に。)あなたはもっと何をしたいですか?リラックス!私が言わなかったことを「解釈」しないでください。 「セキュリティ」という用語が役に立たないとは言わなかった。はい、100%のセキュリティはありません。今までそれはあいまいさのレベルにすぎません。あなたは便利に「安全」の任意の定義を選ぶことができますが、それからあなたは幻想的な土地に出発します。
追加された 著者 NotoriousWebmaster,
P:これはなぜテキストが人間の会話にとって悪い媒体であるかの別の例です。すべての誤解
追加された 著者 NotoriousWebmaster,
@Cruncher:理解していないために何かを強く信じる人にとって良い兆候は、「非常に良い理由で」というような感情的な議論をしているときですが、それを支持しないでください。それが確信ではなかったら、彼らは単に磨耗した段階ではなくその理由を述べるでしょう。残念ながら人間の間では非常に一般的なこと。議論の反省、選択的な解釈、愚かな議論、個人的な、そして侮辱的なものとして扱うことなどと同じように。
追加された 著者 NotoriousWebmaster,
@DavidRicherby:そして、1.なぜそれに対して議論をしているのですか。 :) /私はいくつかのトローリングの匂いがします
追加された 著者 NotoriousWebmaster,
セキュリティから曖昧さという句の曖昧さは、鍵となる資料とは対照的に、システムの設計の曖昧さを特に意味します。それはケルホフの原理を参照する方法です。
追加された 著者 Filegedhiel,
@DavidRicherbyこのコメントを100回支持したいです。すべてのセキュリティを異なる度合いで同じビンにまとめるのはまったく役に立ちません。 という正当な理由のために、「不明確さによるセキュリティ」という用語を発明しました。
追加された 著者 Cruncher,
@ Evi1M4chine「感情的な」議論を嫌った人にとっては、きっととても感情的なのです。 「非常に良い」理由は、実際には何よりも権威への訴求力であった。それについて感情的なことは何もありません。私も直接あなたに返答することすらありませんでした。私はただDavidの主張を強めていました。ここでは議論していません。私の主張が不完全であったという事実は、それが無効または根拠のないことを意味するものではありません。
追加された 著者 Cruncher,
「すべての安全保障は曖昧なものである」という興味深い見方。何かが人間の一生の間に解くことが不可能であるならば、それは安全ではありませんか? :)
追加された 著者 niilzon,
「あいまいさによるセキュリティ」は有用な概念ではないというあなたの主張は、実際には有効ではありません。あなたのポイントは、例えば秘密鍵を持つことは、その鍵をあいまいにしておくことによるセキュリティだけであるということです。しかし、私があなたの秘密鍵を見つけたら、あなたはそれを新しい鍵と取り替えて、立ち上がって実行し、そしてあなたの新しい鍵にもっと注意を払うことを試みることができる。私があなたの秘密のアルゴリズムを見つけたならば、あなたはまったく新しいシステムを構築しなければなりません。また、あなたが自分の鍵を把握するのにどれくらいの時間がかかるのか、あなたのアルゴリズムを把握するのにどれくらいの時間がかかるのかについて、もっと良い限界を与えることができます。
追加された 著者 William Pietri,
@ Evi1M4chineいいえ私は違います。あなたは、すべてのセキュリティは、最終的には、何かをあいまいにしておくことによるセキュリティであると言っています。私たちは「あいまいさによるセキュリティ」という言葉を「あいまいにしないことによるセキュリティ」という意味で使用するのではないと言っています。十分に決定された十分に強力な対戦相手によって何でもハッキングされる可能性があるのでシステムが安全ではないと主張するのと同じです。したがって、「セキュリティ」という言葉は本当に安全ではないので無用です。それは「セキュリティ」という言葉が意味するために使用されているものではなく、あなたが話しているシンは「不明瞭さによるセキュリティ」を意味するためのものではありません。
追加された 著者 William Pietri,
@ Evi1M4chine「非常に良い(しかし述べられていない)理由のため」は感情的な議論ではない。しかしそれはあいまいさによる議論です。 ;-)
追加された 著者 William Pietri,
@ Evi1M4chineいいえ、同意しません。あいまいさによるセキュリティの概念は「誤謬」であるとあなたは言った。そうではないと私は言った。それは非常に便利な概念です。
追加された 著者 William Pietri,

他の人がすでに説明したように、あいまいさによるセキュリティはせいぜい攻撃者を遅くします。

あなたの特定のケースでは、私はそれが認められるほどの効果はないと言うでしょう。この点に到達するために、あなたの攻撃者はすでにあなたのアプリをリバースエンジニアリングし、秘密鍵を抽出しなければなりませんでした。つまり、あなたの攻撃者はばかではなく、彼がしていることを知っています。ほんの少しの不明瞭さは、あなたがそれを実行するのにかかるよりも少ない時間で彼にかかるでしょう。

3
追加された
技術的には、これはアプリから秘密鍵を取得する必要があるという事実を隠そうとすることです。つまり、これが最初に発生します。ただし、アプリからキーを取得できるユーザーは、これまでにまったく遅れることはありません。
追加された 著者 Cruncher,
ばかではない攻撃者は、最初に正規のトラフィックを監視し、すぐに要求が暗号化されていることを確認します。彼が気づくのは文字通り最初のことでしょう。
追加された 著者 Tom,

基本的に、あなたは不正なクライアントがリクエストを送信するのを防ぐことはできません。最も近い方法は、クライアントで何らかの暗号チェックを行うことですが、Sherlock Holmesが言ったように、「誰かが発明できるもの、別のものが発見できるもの」です。 (私は確かにこれを知っています、なぜなら私は何度も人々のクライアントサイドのセキュリティを破ったからです。)

代わりに、カスタムクライアントを使用してだれでも に使用できるようにAPIを構築してください。それを友好的にしなさい。あなたはそれによって何を失いますか?攻撃者は、あなたが何をしても攻撃します。もしあなたがあなたのAPIを使いやすくするならば、誰かがあなたが考えもしなかった何かを思いついて、あなたのサーバーを想像以上に大きくするでしょう。あなたのAPIと他のものの両方に話しかけるクライアントによって何ができるでしょうか?どんな無数の可能性があります、そしてそれは本当にそれらを許可するのを傷つけますか?

1
追加された

他の人がすでに述べたように、あなたは曖昧さによるセキュリティを使用することを提案しています。この方法には目的がありますが、この方法を選択する前に次の点を考慮してください。

  • あなたのAPIにテクニカルサポートを提供する。不正なHTTPレスポンスコードを使用すると、あなた以外の誰かがサポートを提供することが難しくなります。彼らは、特定の状況が実際に適切なレスポンスコードを送信しているのか、それとも不明瞭なレスポンスコードを送信しているのかを考慮する必要があります。サポートリクエストの連絡先を1つだけにしたい場合は、これは問題になりません。
  • 「悪意のあるユーザー」とは何ですか?リクエストを悪意のあるものとして分類するときは、悪影響を及ぼす可能性があるので注意してください。 IPが悪意のあるトラフィックを送信していると判断され、対策が使用されているとします。今、同じIPが実際にその背後に何百または何千ものユーザーを持つプロキシであるとします。あなたは今あなたの対抗策をそれらすべてに適用しました。これと同じ原則が、ヘッダーや本文の悪意のあるアクティビティの識別にも適用されます。
  • アプリケーションコードが最も遅いです。要求は、最終的に「セキュリティ」ロジックに到達するためにスタック全体を通過する必要があります。このアーキテクチャはうまく拡張できず、遅いです。不正な要求はできるだけ早く停止する必要があります。これは、Webアプリケーションファイアウォール(WAF)を使用するための前提条件です。
  • アクセスを拡張する。あなたのAPIが元々設計されていたよりも多くのクライアントにアクセス可能になった場合、それらの新しいクライアントは不正なHTTPレスポンスコードの使用の可能性を知っておく必要があります。
  • 永続的な悪意のあるユーザー。他の人が言っているように、このテクニックは単なるスピードバンプです。

より良いアプローチ

すべての既知の良い要求をホワイトリストに入れることにあなたの時間を集中してください。これは、すべての潜在的な悪い要求を識別しようとするよりもはるかに簡単です。ホワイトリストに表示されていないものは、HTTP動詞でフィルタリングしている場合(例として)、HTTP 400やHTTP 405などの適切なレスポンスコードをすぐに受け取るはずです。できれば、リクエストがアプリケーションコードにヒットする前にこれを実行します。

ホワイトリストで許可されたリクエストとともに、アプリケーションが OWASPガイドラインに基づいて保護されていることを確認します。あなたははるかに良い結果 OWASPにあなたの時間を費やすことになるでしょう、そしてあなたは悪意のあるユーザーが何であるかを決定しようとし、そしてあいまいなHTTPレスポンスコードを返すことを試みるでしょう。

1
追加された

私はしません。それは一般的にあなたがあなた自身の標準を作成していることを意味します。

  1. http応答を実際の意味にマップした後に予測するAPI。 HTTPレスポンスを変更することは、数回の試行の後にあきらめてしまうような「ハッカー」にはうまくいくかもしれませんが、他の人には影響がありません。あなたのAPIを以前のタイプ、つまり11歳からのみ保護したいですか?そうは思わない。

  2. 開発者、そしておそらくテスター、特に世界標準に従って動作するのに慣れている人にとっては、かなり混乱します。

  3. 他の方法を選んでください。確かにいくつかあります。私は最近数週間、同じヘッドキャッチャーと奮闘していましたが、望ましい制限を達成するために少なくとも2つの多少なりとも信頼性の高い方法を思いついたのです。

あなたが欲しいものを手に入れるためには、間違いなくもっと良い、そしてもっと効果的な方法があります。あなたのAPIを別の角度から見てみてください...あなたがハッカーであり、あなたの人生がそのAPIをハッキングすることに依存していた場合 - 成功するために何をしますか?あなたがそれを破ろうとする試みに苛立ちを感じるようになるために何が起こるべきですか?

1
追加された

一般的には良い考えではありません。

クライアントのWebサイトが盗まれたクレジットカード・ローンダリング・リングによって使用されていたときに、私はこれを非常に的を絞った使用方法で効果を上げました。詐欺的な取引によってのみ共有される識別機能がいくつかあったので、それらを丁寧に拒否するのではなく、私はサイトが数分だけ応答を遅らせるようにしました。サーバーエラーに対する標準の "すみません、それはあなたではありません、それは私です"メッセージ(法執行機関に引き渡すための詳細も記録されています)。私たちは、この可能性のある返答を得て、それから二度と彼らから話を聞かれなかった取引で3回の試みをしました。

それでも

  1. 私たちが知っていたことへの対応として、問題を抱えているユーザーにとっては不快ではなく、攻撃であることがわかっていました。
  2. プロトコル自体のセキュリティへの攻撃に対する防御ではなく、それより上の人間レベルでの防御
  3. 他の説明を通じて説明できます。つまり、それがもっともらしい状況で(本当に不気味なWebサイトがたくさんあります)、私たちが具体的な目標ではない状況で、本当に不気味なWebサイトを作っているようです他の人に)

問題を抱えているユーザーは、虐待されるのではなく、助けられるべきです。 「あなたが正しく承認されていないので、私はそれをすることができません」というのは有益な方法で何かをすることを拒んでいます。誰かがプロキシを使用する必要がない場合、「プロキシを使用する必要があるため、これは実行できません」というのは悪用されています。意図的に役に立たないことは、攻撃を受けていることが明らかで偽のメッセージのように見えるべきではないか、何も隠していないことが適切である場合にのみ適切です。すべてのクライアントエラーに対して)。

とはいえ、ステータスが情報を漏らさないようにするための対策を講じることは できます。例えば。 /admin/を404にすることもできます(規格ではそのように記述されています)。ただし、別の場合(許可ユーザー、許可されたクライアントIPアドレスなど)では200になります。/my-profile は承認されたユーザーの場合は200、それ以外の場合は403または401です。その場合、/members/fdsasafdasfwefaxc が承認されたユーザーの場合404となります。無許可のユーザーこれは、どのURIがリソースに関連しているかを考慮して保護されている情報のビットの1つであると考えるほど、あいまいさによるセキュリティではありません。

0
追加された

特にモバイルアプリでこれを行わないのは、電話会社などで、アプリが複数のプロキシを介してサーバーと通信している可能性が非常に高いためです。ほとんどの大企業は、悪意のあるコンテンツからシステムを保護するためにネットワーク上でプロキシを使用しています。また、多くの電話会社は、転送中のビデオまたは画像の品質を低下させています。それはまたあなたのプラットフォーム上でHTTPのための様々なシステムライブラリを使うことをあなたに無用にするでしょう。一般的に使用されている1つのアプローチは、名前アドレスやクレジットカードの詳細をハッシュするなど、ユーザーが共有したくない情報からキーまたはトークンを取得することです。あなたのアプリがハッキングされたとしても、こうすれば人々はダウンロードしたランダムなプログラムに必要な情報を与えることに慎重になり、証明された攻撃の共有能力を制限することになります。

0
追加された