OWASP Secure Coding Checklist – Part 2

OWASP Secure Coding Checklist – Part 2

Previous article on ‘OWASP Secure Coding Checklist’, took you through five points in the checklist that explained the risks developers should be aware of, while developing web application software. This article continues with next five points in the checklist, which explain some effective methods of securing your web application software.

6. Protect Privacy and Data

Encode data in Transit

While transmitting sensitive data, at any level of your network or application architecture, encoding-in-transit of some kind should be contemplated. SSL/TLS is known as the most common and extensively supported model used for encoding in transit by web applications.

Encoding data at Rest

It is difficult to securely build cryptographic storage. It is important to categorize data in your system and decide whether the data needs to be encoded, such as the need to encode credit cards as per the PCI compliance standard. Also, every time you start making your own low-level cryptographic functions, make sure that you have the help of an applied expert. Instead of building it from scratch, it is advised that peer reviewed open libraries, such as Bouncy Castle, Google KeyCzar project and other functions including SDKs. Also, be ready to handle the more difficult features of applied crypto such as overall cryptographic architecture, key management, tiering and trust issues in complicated software.

7. Incorporate Intrusion and Logging Detection

Application logging should not be a reconsideration or should not be limited to troubleshooting or debugging. Logging is also used in activities such as:

• Monitoring of applications
• Business insight and analytics
• Compliance monitoring and activity auditing
• Detection of system intrusion
• Forensics

To make analysis and correlation easier, follow a usual logging approach across the system as much as possible. Use an extensible logging framework such as Apache Log4j2, SLF4J with Logback, to make sure that all log entries are persistent.

8. Promote Security Features of Security Libraries and Frameworks

When it comes to creating security controls from scratch for web applications, mobile applications and web services, it leads to a lot of wasted time and big security holes. Secure coding libraries assist software developers by guarding them against implementation flaws and security-related designs.

Whenever possible, emphasis should be placed on using existing framework features, instead of importing third party libraries. It is better to have developers take advantage of what they are using presently, instead of imposing yet another library on them.

9. Include Needs Specific to Security

Following categories of security requirements can be defined early-on in a development project:

• Security functions and features: The apparent application security control of a system, include authentication, auditing functions and access control. These requirements can mostly be defined by using cases and user stories that include behavior, input and output. They can be tested and reviewed for functional correctness by QA staff.

• Business logic abuse cases: Business logic features have multi-branch multi-step workflows, which are difficult to examine properly and include money and valuable items, private information and user credentials.

• Privacy requirements in data classification: Developers should always be aware of any confidential pr personal information in the system and ensure that the data is safeguarded.

10. Architect and Design Security In

There are different areas where you have to take care of the design of a system or security in the architecture. They include:

• Know your tools: Your choice of platform (web server, O/S, NOSQL data manager or database, messaging), and languages, result in security risks that are technology-specific.

• Manage the attack surface: know the system’s attack surface, the ways through which attackers can get in, or get out out. Identify when the attack surface is being increased and use it to drive risk assessments (in case of threat modeling or planning for additional testing).



Let us know what you think