Top 5 Security Considerations for a New Web App: 1. Secure Coding

Welcome to my comprehensive series on the Top 5 Security Considerations for a New Web App. For this first detailed topic in the series, we focus on Secure Coding Practices, as part of a broader effort to equip developers, IT professionals, and web administrators with essential security knowledge for proactively safeguarding their web applications. Throughout this series, we explore the critical security measures that are fundamental to the development and launch of a secure web application. For a complete overview and the context of this series, I invite you to read the Introduction post. This foundational understanding will enhance your grasp of why each consideration plays a vital role in the lifecycle of a web application in the initial buildout and the days immediately following the launch. Join me as we delve into the best practices, strategies, and real-world applications that underscore the importance of implementing robust security measures from the ground up.

1. Secure Coding Practices

As we venture further into the realm of web application security, it becomes evident that the foundation of a secure web application lies in its coding practices. Secure coding is a proactive measure to prevent vulnerabilities right from the developmental stages of an application. It involves writing code with security in mind, ensuring that it is robust enough to withstand attacks and manipulations.

Key aspects of secure coding include:

• Input Validation: This is crucial in preventing attacks such as SQL injections and Cross-Site Scripting (XSS). By validating all input data, applications can filter out harmful data that could be used to exploit vulnerabilities.
• Error Handling: Secure error handling practices prevent attackers from gaining insights into the application’s architecture. It’s important to ensure that error messages provide the necessary information to the users without revealing sensitive system details.
• Secure Database Practices: Using parameterized queries and stored procedures can significantly reduce the risk of SQL injection attacks. It’s also essential to limit database permissions and access.

Adhering to guidelines and standards, such as those set forth by the Open Web Application Security Project (OWASP), is essential in maintaining a high standard of secure coding. These practices are not just about preventing attacks; they are about instilling a culture of security awareness among developers, leading to the creation of inherently more secure applications.

A Case Study - PlayStation Network (2011)

The Sony PlayStation Network (PSN) breach of 2011 stands as one of the most significant cybersecurity incidents of the early 21st century, illustrating the devastating impact of neglecting secure coding practices. In April 2011, Sony's PlayStation Network, an online gaming and digital media delivery service, was attacked, leading to the personal data of approximately 77 million users being compromised. The attack, which Sony later attributed to an external intrusion, resulted in the theft of sensitive information, including names, addresses, email addresses, birthdates, and login credentials. The breach was significant not only because of its scale but also due to the extended downtime of the PSN service, lasting about 23 days. Hacktivist group LulzSec claimed responsibility for the breach, stating that they were able to exploit vulnerabilities in Sony's network through SQL injection attacks. SQL injection is a technique that exploits security vulnerabilities in an application's software by injecting malicious SQL statements into input fields for execution (e.g., to dump the database contents to the attacker). This type of attack can occur when an application does not properly sanitize input to adequately differentiate between data and command input.

While Sony did not publicly detail the specific vulnerabilities exploited, the company acknowledged the breach was due to a "very carefully planned, very professional, highly sophisticated criminal cyber attack." The incident led to widespread criticism of Sony's security measures, highlighting the company's failure to adhere to secure coding practices that could have prevented such an attack. The breach also prompted legal, regulatory, and consumer backlash, including a U.S. Congressional inquiry and fines by the UK's Information Commissioner's Office (ICO) for failing to protect user data.

Sony implemented enhanced security features in the aftermath of this breach, including updating its software, creating a Chief Information Security Officer position, and adding automated software monitoring and configuration management to help defend against new attacks. Additionally, the company offered identity theft protection to affected users and bolstered its network infrastructure.

The PSN breach serves as a cautionary tale for the importance of secure coding practices. It underscores the necessity for organizations to rigorously test and audit their networks and applications for vulnerabilities, especially those as well-known and preventable as SQL injection. This case highlights the critical need for ongoing security assessments and the implementation of robust security protocols to safeguard against sophisticated cyber threats.

Given the nature of the information available, some of the technical specifics of the attack and Sony's subsequent security measures are based on the company's public statements and industry best practices. The precise details of the vulnerabilities exploited and the technical mechanisms of the attack have not been fully disclosed by Sony or the attackers.

In Summary

Having tested a large number of applications, I have seen a variety of different circumstances, ranging from brand new pre-release applications to old legacy apps on their way out.  These have been developed and maintained by teams with a wide range of security acumen as well, some being extremely well-versed in application security, others with significant gaps in the fundamentals of secure coding.  Here are some key practices I recommend considering for an organization without a format secure development process.

• Foster a security-conscious culture.  This means growing security knowledge internally within the development team(s) by providing training opportunities and facilitating knowledge sharing with the security team.  This may start with a small subset of developers who express an interest in application security, allowing them to organically share what they learn with their teammates.
• Build security-related tasks into their day-to-day practices.  When identifying requirements for the application or for a major enhancement, this discussion should intentionally cover security requirements.  If the team is defining test cases, these should intentionally also cover abuse cases.  
• Discuss flaws internally. When a novel security flaw is identified, whether by an internal team member or an external party, it should be discussed internally so that as many team members as possible can learn from it.  This discussion should include the flaw itself, how the exploitation works, what the impact is, and what was or will be done to remediate it.
• Stop thinking about security as an extra thing. The goal, over time, is not for security to be the primary focus of the development teams, but to make it second nature for them to include security among their considerations.  For them to do this in a productive manner, they need to be well-versed in common flaws and requisite security controls.  For a team not used to the involvement of security in their processes, an incremental approach is better than trying to adopt a mature approach all at once.

Related Materials

Secure software development is a large knowledge domain on its own, so I will undoubtedly be omitting some great resources from this list, but here are some of my favorites:

• OWASP Proactive Controls (https://owasp.org/www-project-proactive-controls/):
  This takes the top ten style approach, but with the focus being on what the team should be implementing, instead of what they should be avoiding.  It is not updated as frequently as the Top 10 web app vulnerabilities, but the 2018 list still holds up well in 2024.
• Microsoft Security Development Lifecycle (SDL) (https://www.microsoft.com/en-us/securityengineering/sdl): 
  Provides a substantial collection of resources and recommended practices for secure development.  This is more at the overall security program level as opposed to a reference for individual developers.
• OWASP Software Assurance Maturity Model (SAMM) (https://owasp.org/www-project-samm/): 
  OWASP SAMM fills a similar role to the Microsoft SDL, but is a community-maintained flagship project from OWASP.  In my opinion, SAMM is more accessible to teams without a lot of existing security processes, as it presents each of the different tasks for the SDLC stages with incremental maturity levels.
• PCI Secure SLC (Software Life Cycle) Standard (https://www.pcisecuritystandards.org/document_library/?category=sware_sec&document=sec_slc_std):
  This document and their related PCI Software Security Framework are written more for compliance-related assessments.  These are certainly relevant to teams dealing with PCI compliance, but many of the controls and practices they outline are appropriate for any secure application. 
  
  

Coming Up Next: 2. Authentication & Authorization

Mic Whitehorn is the Senior Security Consultant and Development Lead for Secure Ideas. Check out some of his latest insights on application security:

Read More:

• Many Hands Approach To AppSec
• What’s new in the OWASP Proactive Controls for 2024