From: Mark Curphey [mark@curphey.com] Sent: Tuesday, September 25, 2001 11:26 PM To: www-mobile-code@securityfocus.com Subject: OWASP - Categorization Categorization Jeremiah / all How about adding a description and example for each attack when the categories are finalized ? Could even offer some basic advice to prevent the type of attack. Example below. Forceful Browsing Forceful Browsing is a common technique that is used to look for files that may contain exploits or be useful in constructing an attack. Those include; Known Vulnerable Files Hidden Un-Referenced Files Back-Up Files / Temp Files Essentially forceful browsing is just using the server response codes to determine if the file exists. You will recall that a web server will return a 200 message if the file does exist and 404 message if the file does not exist. Known Vulnerable Files Obviously many known vulnerable files exist, and in fact looking for them is one of the most common techniques that commercial vulnerability scanners use. Many people will focus their search on cgi's for example or server specific issues such as IIS problems. Hidden / Un-Referenced Files Many web site administrators leave files on the web server such as sample files or default installation files. When the web content is published , these files remain accessible although are un-referenced by any HTML in the web. Many examples are notoriously insecure, demonstrating things like uploading files from a web interface for instance. If an attacker can guess the URL, then he is able to access the resource. Back-Up Files / Temp Files Many applications used to build HTML and things like ASP pages can actually leave temp files and back-up files in directories. These often get up-loaded either manually in directory copies or automagically by site management modules of HTML authoring tools like Frontpage or Go Live. There are various dangers with leaving residue like this on a web server, but generally the risk is greater with languages that embed things like passwords into server side pages. A good example to understand the dangers is to examine how Microsoft Frontpage builds Active Server Pages or ASP pages. Remember ASP pages code are not normally visable to a client, so by design developers usually embed things like database usernames and passwords in the ASP source. FrontPage writes ASP files to an ASA temp file during design (global.asp becomes global.asa) and in many instances the file will not be deleted before publishing. ASA files source is fully visible by a client and so a malicious user who browsed say checkout.asa may well strike gold and get the username and password to the Oracle database. Back-up files are also dangerous as many developers embed things into development HTML that they later remove for production. Emacs for instance writes a *.bak in many instances Fixes / Prevention Never build the HTML on the same box that will ultimately serve it up. ---------------------------------------------------------------------------- ---- Use a staging screening process to look for back-up files. A simple recursive file grep of all extensions that are not explicitly allowed is very effective. ---------------------------------------------------------------------------- ---- Some web server / application servers that build dynamic pages will not return a 404 message to the browser, but instead return a page such as the site map. This confuses basic scanners into thinking that all files exist. ---------------------------------------------------------------------------- ---- Many good lists of files exist. We have some links and guidance on a seperate page here. ---------------------------------------------------------------------------- ---- Remove all sample files from your web server. Ensure that any unwanted or unused files are removed. ---------------------------------------------------------------------------- ---- Don't rely on files not be refernced to protect your site from mis-use.