File System - Revision history

Schattenbaum: fixed the google search query sample

2015-08-26T14:31:01Z

fixed the google search query sample

Jmanico: /* How to protect yourself */

2014-03-25T03:48:34Z

‎How to protect yourself

Adam.muntner: /* Insecure Indexing */

2010-03-09T14:02:28Z

‎Insecure Indexing

Adam.muntner: /* File System */

2010-03-09T13:54:10Z

‎File System

Adam.muntner: /* How to identify if you are vulnerable */

2010-03-09T07:02:32Z

‎How to identify if you are vulnerable

Adam.muntner: moving recommendations. all the other subject headings are technical issues this was one possible impact of many.

2010-03-09T06:56:40Z

moving recommendations. all the other subject headings are technical issues this was one possible impact of many.

Adam.muntner: /* How to identify if you are vulnerable */

2010-03-09T06:52:50Z

‎How to identify if you are vulnerable

Adam.muntner: /* How to identify if you are vulnerable */

2010-03-09T06:52:04Z

‎How to identify if you are vulnerable

Adam.muntner: /* How to identify if you are vulnerable */

2010-03-09T06:31:58Z

‎How to identify if you are vulnerable

Adam.muntner: /* Best Practices */

2010-03-09T05:36:31Z

‎Best Practices

@@ Line 92: / Line 92: @@
 ===How to determine if you are vulnerable ===
-* Use Google to search for indexed directories. Example: [http://www.google.com/search?hl=en&q="index+of+/"+site:owasp.org http://www.google.com/search?hl=en&q="index+of+/"+site:owasp.org]
+* Use Google to search for indexed directories. Example: [http://www.google.com/search?hl=en&q=&#34;index+of+/&#34;+site:owasp.org http://www.google.com/search?hl=en&q=&#34;index+of+/&#34;+site:owasp.org]
 * If a file is found, your application is at risk.

← Older revision		Revision as of 03:48, 25 March 2014
Line 58:		Line 58:

	* Use chrooted jails and code access policies to restrict where the files can be obtained or saved to		* Use chrooted jails and code access policies to restrict where the files can be obtained or saved to
		+
		+	* If forced to use user input for file operations, normalize the input before using in file io API's, such as [http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#normalize() http://docs.oracle.com/javase/7/docs/api/java/net/URI.html#normalize()].

	See the OWASP article on [[Path Traversal]] for a description of the attack.		See the OWASP article on [[Path Traversal]] for a description of the attack.

@@ Line 85: / Line 85: @@
 ==Insecure Indexing ==
-A very popular tool is the Google desktop search engine and Spotlight on the Macintosh. These wonderful tools allow users to easily find anything on their hard drives. This same wonderful technology allows remote attackers to determine exactly what you have hidden away deep in your application’s guts.
+Indexable directories allow an attacker to easily discover the existence of content on your web server that should remain private.
 ===How to determine if you are vulnerable ===
-* Use Google and a range of other search engines to find something on your web site, such as a meta tag or a hidden file
+* Use Google to search for indexed directories. Example: [http://www.google.com/search?hl=en&q="index+of+/"+site:owasp.org http://www.google.com/search?hl=en&q="index+of+/"+site:owasp.org]
 * If a file is found, your application is at risk.
@@ Line 95: / Line 96: @@
 ===How to protect yourself ===
-* Use robots.txt – this will prevent most search engines looking any further than what you have in mind
+* Use robots.txt – this will prevent most search engines looking any further than what you have in mind, but be aware that attackers can view the contents of this directory and fuzz it for content, as well.
 * Tightly control the activities of any search engine you run for your site, such as the IIS Search Engine, Sharepoint, Google appliance, and so on.

@@ Line 373: / Line 373: @@
 ==File System ==
-Even with an authentication system in place to protect your content, if file permissions are set incorrectly an attacker could browse directly to your application source code or protected documents.  The section below gives guidance in setting file system permissions and directories to reduce your risk of exposure.
+Even with an authentication system in place to protect your content, if file permissions are set incorrectly an attacker could browse directly to your application source code or protected documents.  The section below gives guidance in reducing your exposure to risk.
-'''Best Practice'''
+* Manually review web directory contents for unnecessary files which could be discovered by an attacker, such as documentation, template, example files, which could be used by an attacker to identify attackable surface area.
-'''File Permissions'''
+* Enable virus scan on the destination directory.
-Restrict access of the \CFIDE directory to specific IP address and user group/account.
+Cold Fusion specific:
-Remove the \cfdocs directory. Sample applications are installed by default in the cfdocs directory and are accessible to anyone. These applications should never be available on a production server.
+* Restrict access of the \CFIDE directory to specific IP address and user group/account.
-Ensure that directory browsing is disabled.
+* Remove the \cfdocs directory. Sample applications are installed by default in the cfdocs directory and are accessible to anyone. These applications should never be available on a production server.
 Ensure that proper access controls are set on web application content. The following settings assume a user account called “cfuser” has been created to run the ColdFusion service.  In addition, if you are using a directory or operating system authentication service these setting may need to be adjusted.
-File types: Scripts (.cfm, .cfml, .cfc, .jsp, and others)
+* File types: Static content (.txt, .gif, .jpg, .html, .xml)
-Do not allow user input to specify the destination directory or file name of uploaded documents.
+* '''ACLs: cfuser (Read); Administrators (Full)'''
 ==Reference==

@@ Line 41: / Line 41: @@
 ===How to identify if you are vulnerable ===
-* Utilize resources in the [[OWASP_Code_Review_Project]]
+* Be sure you understand how the underlying operating system will process filenames handed off to it.
-* Utilize resources in the [[OWASP_Testing_Guide_v3_Table_of_Contents]]
+* Don't store sensitive configuration files inside the web root
-* Determine if it contains unsanitized user input.
+* For Windows IIS servers, the web root should not be on the system disk, to prevent recursive traversal back to system directories.
 ===How to protect yourself ===

← Older revision		Revision as of 06:56, 9 March 2010
Line 34:		Line 34:

	* On a Windows web server system, make sure that the web root is not on the same disk as the %systemroot%, which is usually the boot disk, C:\. If the web application is on the physical path D:\, it won't be possible to traverse (ex: ../../windows/system32/cmd.exe?) to system disk paths.		* On a Windows web server system, make sure that the web root is not on the same disk as the %systemroot%, which is usually the boot disk, C:\. If the web application is on the physical path D:\, it won't be possible to traverse (ex: ../../windows/system32/cmd.exe?) to system disk paths.
−
−	~~==Defacement ==~~
−
−	Defacement is one of the most common attacks against web sites. An attacker uses a tool or technique to upload hostile content over the top of existing files or via configuration mistakes, new files. Defacement can be acutely embarrassing, resulting in reputation loss and loss of trust with users.
−
−	There are many defacement archives on the Internet, and most defacements occur due to poor patching of vulnerable web servers, but the next most common form of defacement occurs due to web application vulnerabilities.
−
−	~~===How to identify if you are vulnerable ===~~
−
−	* Is your system up to date?
−
−	* Does the file system allow writing via the web user to the web content (including directories?)
−
−	* Does the application write files with user supplied file names?
−
−	* Does the application use file system calls or executes system commands (such as exec() or xp_cmdshell()?
−
−	* Would any of execution or file system calls allow the execution of additional, unauthorized commands? See the OS Injection section for more details.
−
−	~~===How to protect yourself ===~~
−
−	* Ensure or recommend that the underlying operating system and web application environment are kept up to date
−
−	* Ensure the application files and resources are read-only
−
−	* Ensure the application does not take user supplied file names when saving or working on local files
−
−	* Ensure the application properly checks all user supplied input to prevent additional commands cannot be run

	==Path traversal ==		==Path traversal ==

@@ Line 75: / Line 75: @@
 * Determine if it contains unsanitized user input.
-* Review the entire list of ongoing OWASP projects to find security resources for the technologies you are using. [[OWASP_Project]]
+* Review the entire list of ongoing OWASP projects to find security resources for the technologies you are using.
 ===How to protect yourself ===

@@ Line 69: / Line 69: @@
 ===How to identify if you are vulnerable ===
-* Inspect code containing file open, include, file create, file delete, and so on
+* Utilize resources in the [[Category:OWASP_Code_Review_Project]]
 * Determine if it contains unsanitized user input.
-* If so, the application is likely to be at risk.
+* Review the entire list of ongoing OWASP projects to find security resources for the technologies you are using. [[Category:OWASP_Project]]
 ===How to protect yourself ===

@@ Line 23: / Line 23: @@
 ==Best Practices ==
-* Use “chroot” jails on Unix platforms
+* Use of virtual jail environments on Unix platforms.
-* Use minimal file system permissions on all platforms
+* Follow the principle of least privilege - every module must be able to access only the information and resources necessary to its legitimate purpose.
-* Consider the use of read-only file systems (such as CD-ROM or locked USB key) if practical
+* Follow the principle of least user access or least-privileged user account (LUA),  the concept that all users and modules at all times should run with as few privileges as possible.
 ==Defacement ==