OWASP Guide to Building Secure Web Applications and Web Services, Chapter 20: Configuration

Refer to this section of the OWASP Guide to Building Secure Web Applications and Web Services for advice on how to produce applications that are secure out of the box.

This Content Component encountered an error

This article is provided by special arrangement with the Open Web Application Security Project (OWASP). This article is covered by the Creative Commons Share-Alike Attribution 2.5 license. You can find the latest version of this article and more free and open application security tools and documentation at http://www.owasp.org.


Configuration

Objective
To produce applications that are secure out of the box.

Platforms Affected
All.

Relevant COBIT Topics
DS6 – Manage Changes – All sections should be reviewed

Best Practices

  • Turn off all unnecessary features by default

  • Ensure that all switches and configuration for every feature is configured initially to be the safest possible choice

  • Inspect the design to see if the less safe choices could be designed in another way. For example, password reset systems are intrinsically unsound from a security point of view. If you do not ship this component, your application's users will be safer.

  • Do not rely on optionally installed features in the base code

  • Do not configure anything in preparation for an optionally deployable feature.

Default passwords
Applications often ship with well-known passwords. In a particularly excellent effort, NGS Software determined that Oracle's "Unbreakable" database server contained 168 default passwords out of the box. Obviously, changing this many credentials every time an application server is deployed it out of the question, nor should it be necessary.

How to identify if you are vulnerable

  • Inspect the application's manifest and ensure that no passwords are included in any form, whether within the source files, compiled into the code, or as part of the configuration.

  • Inspect the application for usernames and passwords. Ensure that diagrams also do not have any.

  • Do not ship the product with any configured accounts.

  • Do not hard code any backdoor accounts or special access mechanisms.

Secure connection strings
Connection strings to the database are rarely encrypted. However, they allow a remote attacker who has shell access to perform direct operations against the database or back end systems, thus providing a leap point for total compromise.

  • Check your framework's configuration file, registry settings, and any application based configuration file (usually config.php, etc) for clear text connection strings to the database.

  • Sometimes, no password is just as good as a clear text password

  • On the Win32 platform, use "TrustedConnection=yes", and create the DSN with a stored credential. The credential is stored as a LSA Secret, which is not perfect, but is better than clear text passwords.

  • Develop a method to obfuscate the password in some form, such as "encrypting" the name using the hostname or similar within code in a non-obvious way.

  • Ask the database developer to provide a library which allows remote connections using a password hash instead of a clear text credential.

Secure network transmission
By default, no unencrypted data should transit the network.

  • Use a packet capture tool, such as Ethereal and mirror a switch port near the database or application servers.

  • Sniff the traffic for a while and determine your exposure to an attacker performing this exact same task.

  • Use SSL, SSH and other forms of encryption (such as encrypted database connections) to prevent data from being intercepted or interfered with over the wire.

Encrypted data
Some information security policies and standards require the database on-disk data to be encrypted. However, this is essentially useless if the database connection allows clear text access to the data. What is more important is the obfuscation and one-way encryption of sensitive data.

  • Is there a requirement to encrypt certain data?

  • If so, is it "encrypted" in such a fashion that allows a database administrator to read it without knowing the key?

If so, the "encryption" is useless and another approach is required.

  • Passwords should only be stored in a non-reversible format, such as SHA-256 or similar

  • Sensitive data like credit cards should be carefully considered – do they have to be stored at all? The PCI guidelines are very strict on the storage of credit card data. We strongly recommend against it.

  • Encrypted data should not have the key on the database server.

The last requirement requires the attacker to take control of two machines to bulk decrypt data. The encryption key should be able to be changed on a regular basis, and the algorithm should be sufficient to protect the data in a temporal timeframe. For example, there is no point in using 40 bit DES today; data should be encrypted using AES-128 or better.

Database security
Data obtained from the user needs to be stored securely. In nearly every application, insufficient care is taken to ensure that data cannot be obtained from the database itself.

  • Does the application connect to the database using low privilege users?

  • Are there different database connection users for application administration and normal user activities? If not, why not?

  • Does the application make use of safer constructs, such as stored procedures which do not require direct table access?

  • Highly protected applications:
    1. Is the database is on another host? Is that host locked down?
    2. All patches deployed and latest database software in use?
    3. Does the application connect to the database using an encrypted link? If not, is the application server and database server in a restricted network with minimal other hosts, particularly untrusted hosts like desktop workstations?

How to protect yourself

  • The application should connect to the database using as low privilege user as is possible

  • The application should connect to the database with different credentials for every trust distinction (eg, user, read-only user, guest, administrators) and permissions applied to those tables and databases to prevent unauthorized access and modification

  • The application should prefer safer constructs, such as stored procedures which do not require direct table access. Once all access is through stored procedures, access to the tables should be revoked

  • Highly protected applications:
    1. The database should be on another host, which should be locked down with all current patches deployed and latest database software in use.
    2. The application should connect to the database using an encrypted link. If not, the application server and database server must reside in a restricted network with minimal other hosts.
    3. Do not deploy the database server in the main office network.

Further reading

How to protect yourself How to identify if you are vulnerable How to protect yourself How to identify if you are vulnerable How to protect yourself How to identify if you are vulnerable Highly protected applications: How to protect yourself Highly protected applications and any application that has a requirement to encrypt data: How to identify if you are vulnerable

Dig deeper on Software Security Test Best Practices

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close