È solo una parte del nome del file, proprio come lettere, numeri e altri caratteri speciali possono far parte del nome file.

È normale creare "backup" di file prima di modificarli aggiungendo una tilde, quindi in caso di problemi, è necessario ripristinare una versione precedente. In Bash questo può essere fatto facilmente con cp index.php{,~} che si espande in cp index.php index.php~ .

Potrebbe essere sul CTF perché le persone spesso dimenticano quei file e li lasciano non protetti. Soprattutto un file come index.php potrebbe contenere credenziali di database.

In bash, una tilde all'inizio di un argomento si espande anche in una cartella home: ~ diventa $HOME (ad esempio /home/yourusername ) o ~username si trasforma nella cartella home di quell'utente (ad esempio ~root in genere si espande in /root ). Non è questo il caso, però, perché non è all'inizio.

~ è un suffisso comune aggiunto ai nomi di file per copie di backup o temporanee di file. Questo può essere un backup manuale o uno creato da un editor o altro strumento.

Sebbene la maggior parte dei file system non abbia un concetto di "estensioni di file", molti software usano la parte di un nome di file dopo il primo o l'ultimo . per determinare il tipo di file e cosa fare con esso.

In questo caso, il server web sarà stato configurato per eseguire file che terminano in .php , ma per servire i contenuti di altri tipi di file. Poiché .php~ sembra essere una "estensione di file" diversa, non corrisponde alla regola da eseguire e viene fornito il codice sorgente. Questo a sua volta ti permette di vedere il probabile contenuto dello script PHP che avrebbe dovuto essere eseguito (cioè è probabile che index.php~ abbia contenuti simili a index.php ), che potrebbero rivelare credenziali o indizi ad altri exploit.

Ci sono due cose che l'ipotetico sysadmin avrebbe dovuto fare per evitare questo:

1. I file di backup non sono rimasti all'interno delle directory mappate agli URL web.
2. Configurato il server web per rispondere con un errore, piuttosto che il contenuto del file, per estensioni di file non riconosciute.

Hai scoperto un potenziale difetto di sicurezza per le app Web.

Lo scenario è questo:

• Un server web è configurato per interpretare una determinata estensione di file utilizzando un interprete di script (ad esempio, PHP per .php file).
• Alcuni editor di testo memorizzano copie di backup o "funzionanti" del file che si sta modificando come lo stesso nome di file, ma con una tilde ( ~ ) alla fine. Una tilde spesso significa "questo è generato dal sistema, non ti preoccupare".
• Talvolta questi file potrebbero rimanere dopo la modifica, perché l'editor non è configurato per rimuoverli o se l'editor viene ucciso senza chiudere correttamente.
• Aggiungendo una tilde alla fine di un URL potresti avere la fortuna di imbattersi in una di queste copie di backup che un webmaster ha lasciato (o caricato) accidentalmente sul suo sito di produzione dal vivo.
• Il server web non lo interpreterà utilizzando un interprete di script perché l'estensione è diversa (ad esempio, non è ".php"), quindi torna al suo comportamento predefinito per le estensioni di file sconosciute che servono come file download.
• Puoi leggere il codice sorgente del loro script.

Se questo è di grande utilità è variabile. A volte il codice sorgente può contenere elementi come i dettagli di autenticazione per database o servizi esterni.

I'm playing on www.example.com/index.php but when I added (~) at the end: www.example.com/index.php~, a file with name index.php started downloading.

Come altri hanno già detto, molti editor di testo (in particolare Emacs, direi) eseguono il backup delle versioni precedenti dei file su cui si lavora creando un altro file il cui nome è uguale all'originale ma con una tilde aggiunta.

Quali altre risposte non hanno sottolineato abbastanza, tuttavia, il fatto che sia possibile accedere a tale file è una conseguenza di alcuni mix di controllo versione errato o costruzione e implementazione non corrette .

Controllo versione errato (trascuratezza dei file "ignore")

I sistemi di controllo versione (VCS) dispongono di meccanismi per configurare un repository in modo che i nomi file VCS che corrispondono a modelli specificati vengano ignorati. Il sistema di controllo delle versioni più popolare oggi è Git, e il suo meccanismo è file speciali denominati .gitignore . La maggior parte del codice sorgente I repository Git dovrebbero avere un file .gitignore di livello superiore che contiene questa riga:

*~

Questo è uno schema che dice a Git di ignorare tutti i file il cui nome termina con una tilde. Un errore comune tra gli sviluppatori è quello di non mantenere questi file diligentemente, o semplicemente ignorarli completamente. Ad esempio, molti IDE visualizzeranno un avviso quando troveranno i file non tracciati nell'albero dei sorgenti e ti daranno la possibilità di dire all'IDE di ignorarli. Non dovresti quasi mai usare questa opzione; invece, scopri cosa inserire nel file "ignore" del repository in modo che tutti che lo controlla venga automaticamente impostato per non controllare mai questi file.

L'uso disciplinato di tali file "ignorati" è molto lungo per proteggerti da molti altri problemi di sicurezza. Ad esempio, possono aiutarti a proteggerti dal comune problema degli sviluppatori che verificano accidentalmente le credenziali segrete. Una pratica che ho trovato utile è quella di adottare un layout standard in cui i progetti hanno una directory designata per gli sviluppatori per inserire tali file. È quindi possibile configurare il repository VCS in modo che i file in quella directory vengano ignorati e progettare l'applicazione in modo che le build di sviluppo possano ottenere la configurazione da lì.

Processi di compilazione e distribuzione non corretti

L'altra cosa che potrebbe causare problemi di questo genere sono i processi di generazione e distribuzione che propagano erroneamente file come index.php~ in questione.

Alcune pratiche che dovrebbero essere adottate per evitare questo:

• Ottieni il tuo sistema di controllo della versione per ignorare i file, come menzionato sopra.
• Avere un sistema di build automatizzato che controlla periodicamente il tuo progetto dal controllo del codice sorgente, lo costruisce e lo impacchetta per la distribuzione.
• Non modificare mai i file nella directory di lavoro del sistema di generazione, in modo che la sua copia del repository di origine sia sempre pulita. Osserva sempre la disciplina secondo cui gli ambienti di sviluppo sono separati dagli ambienti di generazione automatici.
• Non creare mai versioni dagli ambienti degli sviluppatori.

Un altro suggerimento importante è utilizzare strumenti di build collaudati in battaglia per costruire i tuoi progetti, che impongono un layout di progetto razionale e hanno una buona storia su come identificare quali file devono essere confezionati e quali no. Gli strumenti di compilazione per molte lingue, ad esempio, anziché archiviare ciecamente tutto nel repository di origine, copierà selettivamente i file da esso in una directory temporanea di gestione temporanea e quindi archiverà tale file, in modo che solo i file che lo strumento ha selezionato esplicitamente per l'inclusione ottengano incluso.