|---Module:text|Size:Small---|
On Part 1 of this article we went through the first 5 steps to ensure security when developing software applications. Let’s look at the other 5.
6. Handle exceptions correctly, add logging and introduce intrusion detection.
Handling exceptions in your application is not always an easy task. Mistakes in this process can lead to sensitive data leaking or unexpected and uncontrolled behaviours. Specific and detailed error messages can help attackers to know more about the system.
Stack traces and detailed error messages can show technical information about your environment or architecture. For example, “invalid username” or “invalid password” instead of “invalid login data” help attackers as much as it helps users.
Logging is one of the most important parts of troubleshooting and debugging, but it also helps in terms of auditing, intrusion detection and forensics. Use an extensible logging framework that will help you to make the correlation in logs, so you can trackback any action. Don’t forget to verify regulation and policies applying to sensitive data. Sometimes you can’t log everything you want.
7. Deny by default on access control.
Before starting to code your application, you must decide how to control the access to your system: who can access it and what features or data can be accessed.
Retrofitting the access control after the application is built can be painful, so make sure to manage and control all the rules in a central server-side system/component instead of spread controls in the business logic. Use only server-side data and rules and deny access by default. Before accessing any resource, user authentication and authorisation must be verified. It’s better to deny than to wrongly allow.
8. Validate, validate and validate again.
One of the key principles in development is to validate inputs, outputs and processes. You should never trust the input. Validating data on the client-side is only useful to guide the user in terms of usability, but it doesn’t prevent someone “in the middle” – between client and server – from changing the data.
Validation between components, depending on the architecture and development methodology, can also be in place. If there are components or libraries reused by several teams and it’s not possible to control their development lifecycle, they should be treated as untrusted.
As access control should be implemented with a deny by default policy, validations should implement whitelisting techniques instead of blacklisting. Whitelisting will list all the allowed scenarios, excluding all other scenarios by default – so you don’t forget to exclude any.
9. Train yourself and your team.
Application security is not about common-sense knowledge. It’s discipline with specific terms, complex processes and many tools to help secure your development process.
If you don’t feel prepared to secure your deliverables, you should find tailored security training for your needs, create or join the application security community, find tailored security training for your needs and spread this knowledge within your team.
Training is not only about attending sessions, but also being an active community member, researching for vulnerabilities and solutions and sharing this knowledge with your peers.
10. Enforce market, customer and local policies.
Every customer, market or region can have specific regulations, laws or policies. Before starting to build an application, you must verify the applicable policies and make sure the team knows every constraint that must be in place.
You must keep in mind that a policy is a compilation of the best security practices and guidelines applicable to a context, helping to deliver more secure applications.
Non-compliance to relevant policies may lead an application to a situation in which it can’t be deployed to a productive environment, but worse than that, you will have to refactor features or even the architecture. In later stages of development, it can be painful. Not being compliant can damage your self-image of competence.
These 10 steps for more secure applications address the essential aspects to look for when addressing application security. Maybe some of these aspects have already been met, but there’s certainly room for improvement. The specific application you are delivering may need those steps to be adapted, so be aware of the context and the constraints and perform the changes needs. Remember: no one knows your application better than you do.
.jpg)
