[OWASP-TESTING] OWASP WAPT submission

Javier Fernandez-Sanguino jfernandez at germinus.com
Thu Aug 11 06:59:30 EDT 2005


Mauro Bregolin wrote:

> Daniel and all,
> 
> please find attached my submission.
> Feel free to review it and send comments, particularly if you have 
> relevant information regarding bibliographic references not mentioned in 
> the text

With respect to the "Old, backup and unrefereced (sic) files"  I want 
to point out (again) that Dafydd Stuttard wrote an excellent text on 
this matter that could be reused, please check the CVS or the file 
attached.

As for the text here's some personal recommendations for improvement:

Unreferenced application files are not only dangerous because they 
provide you with internal source code but because they might be 
vulnerable! Imagine the case of a web administrator taking a file that 
has an SQL injection, making a backup copy of it, editing it to remove 
the SQL injection present and leaving. If he forgets to remove the 
backup file _And_ the backup file's extension will be executed by the 
webserver (think: original: login.jsp, backup: login.old.jsp) then you 
might think you are safe when you are actually just as vulnerable as 
before (just that people don't know that the file exists).

You also fail to mention files that do not belong in the web server 
but are typically generated by upload tools (think WS_FTP.log files). 
These files are "unreferenced" in the sense that they should not be 
there, and contain sensitive information (like the user that ftp's in 
the web server) that might be valuable to the user.

Finally, many people are unaware or dimiss the problems with these 
files because they think that the default index.html pages prevents 
all of them from being seen (security through obscurity), they say 
"why care? only an internal user with knowledge can know about them?" 
and then the next web server security bugs comes around and makes all 
the directories browsable because a module fails to load the default 
index .{asp,html} page when fed malicious input, or the web server is 
not properly configured and serves directory listings (the "I expected 
everyone to go through the redirection that sends you to 
"/login/login.asp", I thought nobody could access "/login/" directly 
and get a listing of the directory there!)


Some White box strategies for detecting files (which I believe are 
easier to implement and will produces less FP than the scripted 
methods you suggest)

- Look for files who have not been accessed in a long time, they might 
be backup or unreferenced file. Rationale: If this is a web server, 
most of the files will have their "last access" timestamp modified 
everytime the web server reads them in to provide them to an end-user 
or run them through an application engine. If a file has not been 
accessed in, say, a year. It should be analysed. Of course, you need 
to be using a filesystem that stores access times (most modern 
filesystem will do)

- Correlate logs of the web server with actual files. Rationale: you 
can go through the web server access logs and retrieve the list of 
files requested by clients and then compare that with the actual files 
in the server. Those files that are _not_ on web server logs (if logs 
go back sufficient time) are potential unreferenced files

In Black Box testing you are missing some useful inputs sources:

- Archive.org, better than google since it will _not_ timeout the 
pages after time so you can actually see the old files that were in 
the web server 3 years ago.

- robots.txt files. Some people believe they can "hide" files from 
there using that file, they don't think that the robots.txt file is 
only honored by, yes, robots.

- HTML comments. Either of active content (think server side includes 
which have been disabled) or forms that have changed their action and 
maintain (in a comment) the previous action CGI used.

I would suggest you add these, as well as review the attached text 
(the one I mentioned before) and merge many of its suggestions and 
comments in your text.

Regards

Javier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-testing/attachments/20050811/3d237fab/attachment.html 


More information about the Owasp-testing mailing list