How to protect your file system from hackers.
Protecting your File System
You should try and ensure that access to your local file system is protected from unauthorized creation, modification, or deletion. The file system is quite vulnerable to attack.
Defacement
A common attack is defacement. Usually the attacker ends up defacing your site, much to your embarrassment. Most defacement occurs because of poor patching of vulnerable web servers. The second most common form of defacement is due to web application vulnerabilities.
To secure your file system, you should try to:
? Use ?chroot? jails on Unix platforms
? Use minimal file system permissions on all platforms
? Consider the use of read-only file systems (such as CD-ROM or locked USB key) if
practical.
You can check if you system is vulnerable by confirming the following:
? Is your system up to date? If not, then update it.
? Does the file system allow writing via the web user to the web content (including
directories?) To secure your system, ensure that the application files and resources are read-only.
? Does the application write files with user supplied file names? To secure your system, ensure that the application does not take user supplied file names when saving or working on local files
? Does the application use file system calls or executes system commands (such as exec()
or xp_cmdshell()? To secure your system, ensure that the application checks all user supplied input to prevent any commands from being run.
? Would any execution or file system calls allow the execution of additional, unauthorized commands? See how to prevent injection attacks.
Path traversal
Most web applications include local resources, such as images, themes, other scripts, etc. Each time a resource or file is included by the application, it is possible that an attacker may be able to include a file or remote resource you didn?t authorize.
Your file system is vulnerable if:
? files have unauthorized code containing file open, include, file create, file delete, and so on
? files contain unsanitized user input.
To protect your file system, do the following:
? Try not to have user input when using file system calls
? Use indexes rather than actual portions of file names when templating or using language
files (eg the value 1 for America rather than allowing the user to return ?America?)
? Don’t allow the user to supply the whole path ? surround it with your path code
? Validate the user?s input by only accepting known good ? do not sanitize the data
? Use chrooted jails and code access policies to restrict where the files can be obtained or
saved to
File permissions
Your file system is vulnerable to local and remote attack if users can read, modify or delete files used by the web application.
Protect yourself:
? By using the tightest possible permissions when developing and deploying web applications
? By trying to deployed your application on read-only media, such as CD-ROMs
? By considering using chroot jails and code access security policies to restrict and control the
location and type of file operations even if the system is misconfigured
? By removing all ?Everyone:Full Control? ACLs on Windows, and all mode 777 (world
writeable directories) or mode 666 files (world writeable files) on Unix systems
? By strongly considering removing ?Guest?, ?everyone? and world readable permissions
wherever possible
Insecure Indexing
Search tools such as Google are very useful but can also be used by attackers to find vulnerable information on your system. Your system is vulnerable if Google or other search tools can find things such as hidden files or meta tags.
Protect yourself by:
? Using robots.txt ? this will prevent most search engines looking any further than what you
have in mind
? Tightly controlling the activities of any search engine you run for your site, such as the IIS
Search Engine, Sharepoint, Google appliance, and so on.
? Disabling any search functionality on your website if you don?t need it
Unmapped files
Web applications only interpret their own files to the user. All other content is rendered as HTML or plain text. This may disclose secrets and configurations which an attacker may be able to use to successfully attack the application.
To check if your system is vulnerable, use your browser to request a file that is not normally visible. If the file?s contents are rendered or exposed, then the application is at risk.
To protect yourself:
? Remove or move all files that do not belong in the web root
? Rename include files to be normal extension (such as foo.inc to foo.jsp or foo.aspx)
? Map all files that need to remain, such as .xml or .cfg to an error handler or a renderer
that will not disclose the file contents. This may need to be done in both the web
application framework?s configuration area or the web server?s configuration.
Temporary files
Applications occasionally need to write data to a temporary file. These files, if exposed
to unauthorized users, may expose private and confidential information.
If your application uses temporary files, check the following:
? Are the files in the web root? If they are, can they be retrieved using just a browser? If so,
can it be done without being logged on?
? Are old files exposed? Is there a garbage collector or other mechanism deleting old files?
? Does retrieval of the files expose the application?s workings, or expose private data?
To protect yourself, consider the following controls:
? Generate the content on the fly rather than storing the data in a temporary file
? Users must be authenticated before they can retrieve any resource. Also, ensure that they only have access to their own files
? Use a ?garbage collector? to delete old temporary files
? If deployed under Unix like operating systems, use chroot jails to isolate the application
from the primary operating system. On Windows, use the inbuilt ACL support to prevent
the IIS users from retrieving or overwriting the files directly
? Move the files to outside the web root to prevent browser-only attacks
? Use random file names to decrease the likelihood of a brute force pharming attack
Old, unreferenced files
Old temporary files may contain sensitive source or configuration data which attackers may be able to access.
Check the file system for:
? Temporary files created by editors or crashed programs
? Folders called ?backup? ?old? or ?Copy of ??
? Files with additional extensions, such as foo.php.old
? Temporary folders with intermediate results or cache templates
To protect yourself:
? Prevent the need to keep old copies of files around
? Periodically ensure that all files in the web root are required
? Ensure that the application?s temporary files are not accessible from the web root
Second Order Injection
If the web application creates a file that is operated on by another process, typically a batch
or scheduled process, the second process may be vulnerable to attack.
To check if you are vulnerable:
? Does the application use background / batch / scheduled processes to work on user
supplied data?
? Does this program validate the user input prior to operating on it?
? Does this program communicate with other business significant processes or otherwise
approve transactions?
To protect yourself:
? Ensure that all behind the scenes programs check user input prior to operating on it
? Run the application with the least privileges ? in particular, the batch application should
not require write privileges to any front end files
? Restrict the resources and features which the background application may use
? Use host based intrusion detection systems and anti-virus systems to detect unauthorized file creation.
For more on how to secure your site, get our FREE E Book
