ファイル拡張子の終わりのチルダ（〜）はどういう意味ですか？
私がプレイしている間は Capture the Flag （CTF）ですが、このチルダ〜が原因でチャレンジを解決できませんでした。 www.example.com/index.phpが最後に（〜）を追加した場合：www.example.com/index.php~、index.phpという名前のファイルのダウンロードが開始されました。
このチルダ（〜）の役割は何ですか？
文字、数字、その他の特殊文字をファイル名の一部にすることができるように、ファイル名の一部です。
チルダを追加して編集する前にファイルの「バックアップ」を作成するのが慣例です。そのため、何かがおかしくなった場合に備えて、以前のバージョンを復元する必要があります。 Bashでは、これはcp index.php{,~}に展開されるcp index.php index.php~で簡単に実行できます。
人々はしばしばそれらのファイルを忘れて保護されないままにするので、それはCTFにあるかもしれません。特に、index.phpのようなファイルには、データベース資格情報が含まれる場合があります。
Bashでは、引数の先頭のチルドもホームフォルダーに展開されます。~は$HOMEに変わります（例：/home/yourusername）、または~usernameはそのユーザーのホームフォルダーに変わります（例：~rootは通常/rootに展開されます）。ただし、これは最初の段階ではないため、ここでは当てはまりません。
~は、ファイルのバックアップまたは一時的なコピーのためにファイル名に追加される一般的なサフィックスです。これは、手動バックアップ、またはエディターや他のツールによって作成されたバックアップの場合があります。
ほとんどのファイルシステムには「ファイル拡張子」の概念がありませんが、多くのソフトウェアでは、最初または最後の.の後にあるファイル名の部分を使用して、ファイルタイプとそれをどうするかを決定します。
この場合、Webサーバーは実行.phpで終わるファイルに設定されていますが、他のファイルタイプのコンテンツを提供に設定されています。 .php~は別の「ファイル拡張子」のように見えるため、実行されるルールと一致せず、ソースコードが提供されます。これにより、PHPスクリプトの実行される可能性のある内容（つまり、index.php~がindex.phpと類似した内容である可能性が高い）を確認できます）、資格情報や他のエクスプロイトの手がかりを明らかにする可能性があります。
これを回避するために、架空のシステム管理者が2つのことを行う必要があります。
- Web URLにマップされたディレクトリ内にあるバックアップファイルは残されません。
- 認識されないファイル拡張子に対して、ファイルの内容ではなくエラーで応答するようにWebサーバーを構成しました。
Webアプリの潜在的なセキュリティ欠陥を発見しました。
シナリオはこれです：
- Webサーバーは、スクリプトインタープリターを使用して特定のファイル拡張子を解釈するように構成されています（例：PHP for
.phpファイル）。 - 一部のテキストエディターは、編集中のファイルのバックアップまたは「作業中」コピーを同じファイル名としてチルダ（
~） 終わりに。チルダは、「これはシステムによって生成されたものであり、心配する必要はありません」を意味します。 - これらのファイルは、エディターがファイルを削除するように構成されていないため、またはエディターを正しく閉じずに強制終了した場合など、編集が終了した後も残ることがあります。
- チルダをURLの最後に追加することにより、Webマスターがライブの本番サイトに誤って残した（またはアップロードした）これらのバックアップコピーの1つに出くわすことができます。
- 拡張子が異なるため（たとえば、「。php」ではない）、Webサーバーはスクリプトインタープリターを使用してそれを解釈しないため、ファイルのダウンロードとして機能する不明なファイル拡張子のデフォルトの動作に戻ります。
- あなたは彼らのスクリプトのソースコードを読むことができます。
これが大いに役立つかどうかはさまざまです。ソースコードには、データベースや外部サービスの認証の詳細などが含まれている場合があります。
私は
www.example.com/index.phpでプレイしていますが、最後に（〜）を追加したとき：www.example.com/index.php~、index.phpという名前のファイルのダウンロードが始まりました。
他の人が述べたように、多くのテキストエディター（特にEmacsだと思います）は、元のファイルと同じ名前でチルダが追加された別のファイルを作成することで、以前のバージョンのファイルをバックアップします。
しかし、他の回答が十分に強調していないのは、そのようなファイルにアクセスできるという事実は、不適切なバージョン管理の組み合わせの結果であるということですまたはビルドとデプロイメントが正しくありません。
不適切なバージョン管理（「無視」ファイルを無視）
バージョン管理システム（VCS）には、指定されたパターンに一致するVCSファイル名が無視されるようにリポジトリを構成するメカニズムがあります。今日最も人気のあるバージョン管理システムはGitであり、そのメカニズムは .gitignoreという名前の特別なファイル です。ほとんどのソースコードのGitリポジトリには、次の行を含む最上位の.gitignoreファイルが必要です。
*~
これは、名前がチルダで終わるすべてのファイルを無視するようにGitに指示するパターンです。開発者の間でよくある間違いは、これらのファイルを入念に保守しないか、完全に無視することです。たとえば、多くのIDEは、ソースツリーで追跡されていないファイルを見つけると警告を表示し、IDEにそれらを無視するように指示するオプションを提供します。このオプションはほとんど使用しないでください。代わりに、リポジトリの「無視」ファイルに何を配置するかを理解し、それをチェックアウトするeverybodyがこれらのファイルをチェックインしないように自動的に設定されるようにします。
このような「無視」ファイルを適切に使用することは、他の多くのセキュリティ問題からユーザーを保護するのに非常に長い道のりとなります。たとえば、秘密の資格情報を誤ってチェックインする開発者の一般的な問題からユーザーを保護するのに役立ちます。開発者がそのようなファイルを配置するための指定されたディレクトリをプロジェクトに持つ標準的なレイアウトを採用することは、私が有用だと思ったプラクティスの1つです。次に、そのディレクトリ内のファイルが無視されるようにVCSリポジトリを設定し、開発ビルドがそこから構成を取得するようにアプリケーションを設計できます。
正しくないビルドおよびデプロイメントプロセス
そのような問題を引き起こす可能性が高いもう1つのことは、問題のindex.php~のようなファイルを誤って伝達するビルドおよびデプロイメントプロセスです。
これを回避するために採用すべきいくつかの慣行：
- 上記のように、最初にファイルを無視するようにバージョン管理システムを取得します。
- ソース管理からプロジェクトを定期的にチェックアウトし、展開用にビルドしてパッケージ化する自動ビルドシステムを用意します。
- ソースリポジトリのコピーが常にクリーンになるように、ビルドシステムの作業ディレクトリにあるファイルを編集しないでください。開発者環境は自動ビルド環境から分離されているという規律を常に守ってください。
- 開発者自身の環境からリリースをビルドしないでください。
もう1つの重要なヒントは、合理的なプロジェクトレイアウトを適用し、どのファイルをパッケージ化し、どのファイルをパッケージ化しないかを特定する方法について、いくつかの優れたストーリーを備えたプロジェクトをビルドするために、テスト済みのビルドツールを使用することです。たとえば、ソースリポジトリのすべてを盲目的にアーカイブするのではなく、多くの言語用のビルドツールは、そこから一時的なステージングディレクトリにファイルを選択的にコピーし、それをアーカイブします。含まれています。