Natural Order Development

Best Practice #1 Do Input Validation

Input validation verifies or cleans up inputs to the application. Essentially trust no data from any source until it has been proven to be safe based on some established format verification process. Input validation is a critical part of a web service's reliability and security (or any software application for that matter). By failing to validate input data an application may do very unexpected things given a garbled (accidentally or intentionally) input leading to a security violation or a vulnerable state.

Input Validation:

• Ensures input is in expected format before processing;
• Prevents the application from entering an unexpected state while processing
• Prevents unexpected crashes or security violations

To validate input:

• Establish what the valid format is for the specified input. In order to do this, all aspects of input need to be considered, these aspects include length, data type and value.
• Use a Positive List or Negative List to enforce the established format when applicable
  • Positive Filtering is a scheme for validating strings where valid sequences of characters are specified. Input is then validated against that list of valid sequences of characters.
  • Negative Filtering is a validation technique that consists in specifying the list of illegal characters and comparing input against that list.
• When possible, opt for positive filtering as it is the most conservative of the two techniques.

Best Practice #2 Output Validation/Encoding

Output validation ensures that all output data has been normalized and is in expected format before being given to other components of the system.

Most Script-Injection/Cross-site scripting issues could be mitigated with output validation techniques.

There are times when it makes sense that input validation is held to a minimum and a system to depend entirely on output validation. For example when data may be sent to more then one possible destination where different rules on valid display apply. In that case the input validation logic could not be aware of how the data will be processed by other components and cannot validate data accordingly.

For security purposes, data sometimes needs to be output differently than it is stored. This is due to the fact that data can have different meanings depending on the application processing it, e.g.: text vs. executable instructions.

Depending on the component that will process the output, all output should be validated in a way that is relevant to the target i.e. SQL-specific characters should be filtered before data is included in a database query, etc.

Output validation provides an extra layer of security should input validation fail or not be possible to implement. It should be coupled with input validation to provide defense in depth

Best Practice #3 Fail Securely

Exceptions are abnormal activity in a system. But any application needs to be constructed to prevent errors or unexpected conditions from disclosing too much information. Revealing information, especially due to improper error handling can give an attacker major insight into the system.

Error messages are best left in non-technical terms. But still useful. For example if authentication fails instead of saying user name is incorrect or password is incorrect put out a message that says that the login id or password were incorrect. That would be specific enough to trouble shoot but general enough to provide no useful information to an attacker.

Need to have global exception handlers to clean up the output. Catch ALL exceptions and output a reasonably clean error message.

Use the finally clause to make sure output is cleaned up and that the system is not in an insecure state. If some part of a method uses heightened permissions then make sure that any extra privileges are dropped.

Best Practice #4 Defence in Depth

Layer all security so that there are reasonable boundaries and each one has its own layer of security. Don't go overboard but the redundancy helps to ensure the safety of the systems and data. The concept is to have a number of high strong walls between an attacker and any critical data.

Redundancy is not meant to be simple copy paste (one exploit in the main defenses should not be usable at all other services). By having different code written at different times and explicitly for the given application you increase the chances that an attacker will not be able to penetrate all services and defenses with the same attack.

Really the idea here is to make your application more expensive and harder to break so that it is just too risky or expensive for the potential return.

Examine a bank's security for the principles:

• Armed guards at the entrances
• Bullet-proof time released doors to teller areas
• Security cameras
• Silent alarms
• Man traps at the exits
• Time controlled vaults
• Trained personnel on what to do during a robbery

The bank's defenses are not perfect they still get robbed. But it takes considerable more effort then to rob convenience stores where the defenses are:

• One or two low paid tellers
• No guards
• One or two low quality security cameras
• Quick in-out access

Best Practice #5 Handle Sensitive Data with Care

Use Secure String resources, proper encryption and try to isolate the exposure surface for sensitive data.

Best Practice #6 Compartmentalize Users, Processes & Data

Object oriented programming deals with trying to let each part do its own work. Try to keep things in their own space.

Separation of Resources:

• Data
• Users
• Processes

Best Practice #7 Account Management Policies are needed

If there is account management policies use them, enforce them.

Best Practice #8 Audit and Log

Log files are not for the users. Keep them safe and try to limit access especially for deleting or changing.

From time to time audit the logs. If they are not checked for exceptions, security errors and suspicious activity then they are useless.

Best Practice #9 Use the Principle of Least Prvilege

Get familiar with:

• Java Policy Files
• Java Permissions

And use them.

Best Practice #10 Keep It Simple (Open and Simple Design)

Complex code injects chances for errors and exploits.

Best Practice #11 Limit the Number of Entry Points to Your App

Keep the attack exposure as small as possible. Only allow inputs and outputs through specific points and then examine the API or services closely.

Best Practice #12 Do Not Reinvent the Wheel

If there is a solid known good solution use it. Software engineers love to reinvent components over and over again.

In many cases reinventing the wheel makes sense when:

• Existing solutions do not meet the needs and are not extensible
• License agreement with 3rd party component might not be applicable to needed solution
• Usage of the existing wheel is to heavy (no need to include a 50MB library to get at 3 functions)

Best Practice #13 Do Not Reveal Too Much Information

This falls back on the issues of giving away the keys to the kingdom. Given enough time attackers can discover enough about the layout of your application in order exploit a vulnerability.