full-disclosure - Temporary Files and Web Sites (swp, ~, etc)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <s11b2b1b.095@mail.smuht.nwest.nhs.uk>
From: Marek.Isalski at smuht.nwest.nhs.uk (Marek Isalski)
Subject: Temporary Files and Web Sites (swp, ~,
	etc)

>>> <bugtraq@...ondsecurity.com> 12/08/2004 07:45:20 >>>
> In case where the 
> HTML file is an PHP, or an .index.php.swp is found, values like DB 
> usernames/passwords, security mechanism or worse might be revealed to the 
> user requesting the file.

> What can you do?
> There isn't much you can do beside:
> 1) Avoid leaving these files behind
> 2) Make rules in Apache/whatever to block access to .swp, ~, etc files.

A "fix", really a bit of coding discipline, from my previous employers':

Every .php file that Apache could see just included the .inc file of the same name.  Includes were in a directory not accessible by Apache.  Very easy to automate with a script too -- a bit of find | sed | xargs can make sure all the .inc files had a respective .php in the "www root" directory that Apache could read.

Has the additional advantage that if your .PHP interpreter breaks and Apache starts serving the files as-is, again you don't lose your source code to your customers/the internet/etc.

Marek