Web application/Security
From DocForge
When building a web application there are common practices which should be followed to enhance security. In addition to the basic security of the server operating system and runtimes, web developers should follow accepted guidelines to write secure applications. [1]
Contents |
[edit] Validate Input
Whether a web application is open to the internet or only on a private network, always validate all user input. Any layer of an application may be a security risk, and any input may be an attack vector. There are a wide variety of reasons for validating input:
- Input validation helps ensure data integrity. A user may input something unexpected. A bug on the client interface may post something incorrectly and corrupt data.
- Form posts may not be coming from the expected client or from the same web application. A post may come from any client. A form on one web site may post to a web application on another site.
- Malicious code may connect to a web application server from any other computer, with or without the owner's knowledge. The input posted to a web application may not be coming from the actual end user. Bots and scripts from other sources may unexpectedly connect to the web server and attempt to post data or download files.
- Some vulnerabilities in runtimes such as PHP have historically been exposed through requests and posts to web applications. By validating and escaping user input this attack vector becomes limited.
- Unexpected input can cause unexpected output. Cross-site scripting (XSS) vulnerabilities, for example, occur when HTML and JavaScript are injected into a web page, typically from a form post. One way to avoid XSS is to block or filter posts containing certain HTML.
A web application should always know what data or data characteristics to expect. Generally:
- Use whitelisted values
- Revalidate limited selections
- Escape data, using built-in escape functions when available
- Validate data types
- Validate data sources. If data is expected from a form post, be sure the data is actually coming from a post. PHP, for example, has a $_REQUEST variable which combines the data from post, get, and cookies. A cross-site request forgery (CSRF) can come from img tags passing parameters with the URL that may otherwise be expected to come from a form post. Using PHP's $_POST array prevents img elements posted to third-party sites from mimicking form actions.
[edit] Escape and Filter Output
Any input coming from a user and displayed again on a web site can become a source of vulnerabilities. Anything can be inserted into page's generated output if it's not properly escaped or filtered. A text input, for example, may contain HTML which invalidates a page or injects JavaScript, exposing a cross-site scripting (XSS) vulnerability. Use built-in escape or strip functions when available.
Escaping, filtering, and related functions:
[edit] File System
Web servers generally expose files which are within certain file system paths (the "document root"). Images and CSS files, for example, are often served directly from the generic web server and not by the custom web application. Files which should remain secure should be carefully placed outside the realm of publicly exposed directories.
Web applications should also be careful when processing file requests from query string or post data. A request containing a path may expose any file which the web application has read access to. Code files, configuration files, and even password files may become exposed. Before immediately responding with a file's contents, strip the directory part of the path or determine that it's safe for output.
One common scenario involves documents which should only be available to logged in users. To provide them for download, they can be placed within a publicly available web directory. But this can expose them to any requests from any client. One method to secure files is to place them outside any directories publicly exposed by the web server and handle the requests manually within the web application. For example, a predefined URL such as /uploads might not resolve to an actual file directory on disk, but is instead handled by PHP code which checks user security and transmits the file itself.
[edit] Database
There are a few different ways in which databases for web applications should be secured.
- Secure the database itself by limiting connection sources, user accounts, and permissions. Generally, create the most restrictive database environment possible while still allowing the application to function.
- Set the database server to only accept connections from the web application server. Even if the server has a firewall, the database software itself should only be listening to connections from the web application.
- Do not create database user accounts for each web application user (when it's not absolutely necessary). Create one user account to always be used by the application. Handle user authentication at the application level.
- This single application database user should only have the minimum amount of permissions it requires. For example, do not allow the web application database user to create tables, drop tables, or alter grants if it's not required.
- Consider running all queries through stored procedures and not granting the database user any permissions other than execution of those stored procedures. This will greatly restrict the abilities of the database user.
- Do not generate SQL based directly on form input. If a client can post any field names or otherwise generate their own SQL, it often exposes data in unexpected ways.
- Escape form input so SQL can not be injected directly by the client.
[edit] Sessions
In some default server configurations all session information is stored in one location. A security hole in one web application might expose session data among all web applications on the server. Therefore it's often beneficial to store sessions individually for each application.
Sessions should not contain especially secure information in unencrypted form, such as passwords.
[edit] Encryption
Especially secure information, such as passwords and credit card numbers, should never be stored in an unencrypted format. One-way encryption functions should be used when decryption is never necessary, such as with a password. To confirm a password, for example, encrypt the user input and compare that value against the encrypted password stored within the system.
One-way encryption functions:
Encryption / Decryption functions:
[edit] Notes
Additional references:
