Software Development Resources
Create account | Log in | Log in with OpenID | Help

Web application/Security

From DocForge

There are many facets to web application security. It's critical to any system that the development team is familiar with common exploits and the best practices to prevent them.


[edit] Best Practices

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. These best practices expand on the security best practices which should be applied to all applications.

[MARKED AS SPAM BY ANTISPAM BEE | CSS Hack]Enormement environnant les puaierr n'ose marche commencer durante Bourse. Ce monde plusieurs solutions binaires leur semblent compliqu avec peu sont au courant que ces odds environnant les remporter are generally mise avoisinent des 50%. C'se rrrvrrle rrtre la raison fill laquel les Dealers ainsi que Brokers du monde entier s'enrichissent regulierement avec new york Bourse durante ligne. Suppos que le Investing vous interesse : gagner-argent

[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. This content can cause the browser to perform an action, such as downloading a file or executing JavaScript. A text input, for example, may contain HTML which invalidates a page or injects JavaScript when it's rendered later, exposing a cross-site scripting (XSS) vulnerability. Use built-in escape or strip functions when available.

Escaping, filtering, and related functions:

[edit] File System

[edit] Structure

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.

For example, a web application's code may be securely organized with this directory structure:

/app               - Internal application code
/htdocs            - Document root, publicly accessible
/htdocs/index.php  - The only script accessible directly by clients

[edit] Requests

Web applications should also be careful when processing file requests from the 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.

For example, a request for /download?file=data.txt may be safe while /download?file=/etc/passwd should be ignored. This can be handled in a few ways. One simple solution is to store every downloadable file in one directory and not allow the path as part of the request. So in this example data.txt would be a valid request while anything containing a slash ("/" or "\") could respond with a forbidden message. Also be weary of relative paths (like ../../home/username) because they can expose directories other than those intended when evaluated to their absolute path.

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.

Another common scenario to consider is project checkouts from code repositories. Typical revision control systems store local files for synchronization with a repository. These can accidentally be exposed on a web server, allowing others to see internal file paths and execute them. To avoid this problem, export the code from the repository instead of checking it out. Or block requests for these repository files. With subversion this can be accomplished with the following mod_rewrite configuration:

RewriteRule (\.svn)/(.*?) - [F,L]

[edit] Privileges

A web server should execute with restricted file system rights, only giving it access to read, write, and execute files which are appropriate. Executable scripts should be read-only for the web server so they can't be overwritten by an attacker who leverages a vulnerability to alter the application. A web application should have no access at all to files which it would never require, such as other system configuration files.

[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. Never use the database's root or super-user account for a web application; these are only appropriate for system administrators.
    • 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 / POST data so SQL can not be injected directly by the client. It's best to use preparted sql statements. If those are not available, escape each value individually before using in any SQL statement.

I'm taking my eempoylrs to a Tribunal and the disciplinary system is only really used by the management to settle personal scores. If everything disciplinary for like for like offences was harsh, that would be consistent and in it's own way, then fair enough.But if the offender is a management favourite they can be amazingly lenient for serious offences. They have given me some contradictory ones and are withholding others. How do I go about finding out information that they don't want me to know?Any good ideas please?

[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.

Encryption / Decryption functions:

[edit] Web Application Security Exploits

[edit] Further Reading