シークレットを使用してサーバーからファイルをダウンロードする：テキストまたはバイナリで？
ユーザーがWebサイトのボタンをクリックして、秘密のファイルをダウンロードするとします。 ajax経由。サーバーがそのファイルを生成して次のように送信すると、より安全ですか？
1）zip、tarなどbinaryファイル。コンテンツタイプ：application/octet-streamまたはapplication/Zipまたは類似のもの。
2）またはプレーンテキストファイルとして？コンテンツタイプ：text/plain。
1）の場合、パスワードで保護されていないものはすべてZip/tarであることに注意してください。
どちらの場合もHTTPSが使用されます。
実際には違いはありません。
適切なTLS暗号化を使用すると、どちらも途中で読み取ることができなくなり、サーバーが要求を適切に認証すると、許可されていない人はファイルをダウンロードできなくなります。
適切なTLSを使用していない場合、またはユーザーを適切に認証していない場合、攻撃者はどちらの場合でもファイルを読み取る可能性があります。
セキュリティ対策として、パスワードで保護されていない圧縮を使用しないでください。
いいえ、
ファイルのタイプが指定されている場合、セキュリティはまったく追加されません。たとえば、ファイルの解凍は非常に簡単なので、セキュリティは追加されません。
タイプが不明なファイルを介してシークレットを共有する方が安全かどうかを尋ねる場合、これは obcursityによるセキュリティ です。あいまいさによる確かなセキュリティは一部の人々を落胆させますが、それでも安全ではありません。
ファイル形式は、データ転送のセキュリティとは無関係です。暗号化されたTLSトンネルを介して、プレーンテキストおよび任意のバイナリ形式を安全に送信できます。トランスポートセキュリティがなければ、データはどちらの方法でもキャプチャでき、フォーマット自体の暗号化によってのみ保護されます。
アプリケーション層のセキュリティに関して、機密データの圧縮は歴史的にコンテンツスニッフィングに関連するWebアプリケーション攻撃のクラスに対する一般的な対策でした。たとえば、秘密データの形式とダウンロードパスの予測可能性に応じて、 クロスサイトスクリプトを含める （XSSではなくXSSI）適切なセキュリティ対策なしでプレーンテキストダウンロードを提供することによる脆弱性。これは、攻撃を説明する架空のシナリオです。
プラットフォーム上の認証済みユーザーが、ユーザー固有の機密構成ファイルを次のURLからダウンロードできると仮定します。
https://yourservice.example/download/myconfig
構成ファイルの形式は次のとおりです。
user_id = 314159
secret_token = "719fe66f5159f86e798eabf930b8c9c2"
攻撃者は、次のコンテンツを含む準備されたWebサイトへのリンクを送信することができます。
<script src = "https：//magicservice.example/download/myconfig"> </ script> <script> alert（secret_token）; </ script>
ここで何が起きるかは、ブラウザがダウンロードリンクからの応答を外部JSコードとして解釈し、user_idとsecret_tokenの値を、攻撃者が制御する埋め込みページにグローバルJS変数としてリークすることです。何らかの方法でデータを圧縮または再フォーマットすれば、Zipファイルは有効なJSコードを生成できないため、この攻撃を防ぐことができます。この特定のケースはフェッチされているように見えるかもしれませんが、過去にはスニッフィング関連の脆弱性が他にも数多くあります。
このXSSIシナリオを軽減する正しい最新の方法は、ファイルを圧縮するのではなく、ブラウザに正しいMIMEタイプのJSのみを受け入れるように強制するX-Content-Type-Options: nosniffヘッダーを送信し、指示するContent-Disposition: attachmentヘッダーを送信することに注意してください。ブラウザーでダウンロードをインラインで表示しない。
HTTPS経由かどうかは関係ありません。テキストファイルと同じくらい簡単にバイナリファイルを読み取ることができます。
はい。ただし、ほとんどのセキュリティを意識した設定以外では、心配するだけの価値はありません。
テキストは大きくてかさばっており、一般的に知られている制限された文字セットで構成されていますが、Zipのような圧縮バイナリ形式はコンパクトであり、可能な限り小さい数のバイトを必要とするようにバイトの可能な値の全範囲を使用しようとします。コンテンツを表します。また、通常、少なくとも最も重要な循環パターンが削除されます。
これにより、ダウンロードを保護するために使用するトランスポート層の暗号化を解読することがより困難になります。 （したがって、デフォルトでGPGのようなプログラムがメッセージを暗号化する前にメッセージを圧縮するのはなぜですか。）しかし、TLSが正しく設定されている場合、その解読はすでに非常に困難であるため、主要な政府以外の誰かを心配する必要はありません。 、それでも彼らはそれがあなたの家に現れてあなたが彼らにファイルを与えるまであなたを打ち負かす可能性が高いので、彼らがそれをするのに十分な時間を過ごすでしょう。
TLSを使用していない場合は、バイナリ形式を選択できなければ、意味がありません。そのため、敵がそれを識別できないほど難解です...その場合、ユーザーはおそらくどちらもできません...したがって、ダウンロードするために/ dev/urandomからlen（$ FILE）バイトを与えるだけで、実際のファイルをディスクに書き込んで投稿に送信することもできます。
これは実際には少し異なります。誰もがそのようにエンコードを指摘したように、明らかに、攻撃者の余分な課題を防ぐことはできませんが、他に考慮すべきことがいくつかあります。
暗号化されたデータを転送するときに、通常は保護することができないものがいくつかあります。送信元と宛先は1つで、長さは別です。長さは驚くほど強力なサイドチャネルであることがわかります。Googleマップのトラフィック分析の例については、 https://www.youtube.com/watch?v=skQNwd9Jij4 を確認してください。
私が指摘しようとしている点は、まれに、エンコーディングがシステム全体のセキュリティに影響を与える場合があるということです。これは、受け入れ可能な送信状態が少数の場合に特に当てはまります。あなたが「いいえ私は仕事のオファーを望んでいない」のどちらかを選択できるようになった場合。そして、「はい、契約書を一緒に送ってください。（契約書が追加されています）」。情報が同じに見えるようにするには、無回答のパディングが必要になります。
これは、識別子のハッシュなどで時々見られるデータの低エントロピーの特定のバージョンです。許容できる入力が数百万しかない場合、それらのハッシュは簡単に反転できます。