Building-a-Secure-Web-Application

Building a Secure Web Application


Combining OWASP’s TOP 10 within a SECURE DEVELOPMENT FRAMEWORK gives you the strategy you need.

When it comes to building a secure web application, developers have relied on OWASP’s list of Top 10 vulnerabilities for the best part of two decades.

But increasingly we hear people asking: Is OWASP still relevant?

At Shearwater, we believe OWASP is important and the guidelines still have much to offer.

However, we also believe it is absolutely crucial developers understand the right way to make use of the OWASP Top 10 list.

Don’t treat OWASP as just a checklist.

Rather, you should consider it in the context of a secure development framework. This will enable you to conceptualise security requirements early in the lifecycle.

While OWASP provides the ideal starting point for web app developers, achieving a comprehensive security posture requires the standards be implemented from the very beginning of the development process.

This is where a secure development framework, like OWASP ASVS, BSIMM or Microsoft’s Security Development Lifecycle (SDL), become significant.

By considering the OWASP Top 10 vulnerabilities within a secure development methodology and timeline, you’ll achieve a comprehensive Shift-Left approach towards web app security.

Shift-Left  /ʃɪft/-/lɛft/

A Shift-Left approach can be used by developers to identify and pre-empt software defects, including security vulnerabilities, as early as possible in the development pipeline.

By using a Shift-Left testing strategy for potential vulnerabilities earlier in the lifecycle (i.e., moving your testing to the left on the project timeline), you’ll benefit by being able to:

· Enhance Product Quality
· Save Time
· Save Money

 

When did OWASP and Microsoft’s SDL begin?


Bill Gates is a name you’re familiar with. But are you also familiar with Mark Curphey?

Both played pivotal roles in raising web app security awareness in the early 2000s. Within the space of just four months, both Gates and Curphey introduced principles that continue to set the benchmark for web app security standards till today.

Back in September 2001, Curphey launched OWASP, or the Open Web Application Security Project.

Together with legions of volunteer contributors, Curphey set out to shed light on what it takes to achieve software security best practice. In doing so, he sought to ensure developers would be better informed about web application security risk. They would also be exposed to potential solutions to mitigate those risks.

Just four months later, in January 2002, Gates announced Microsoft’s commitment to “Trustworthy Computing”. The landmark commitment would place security at the heart of all Microsoft initiatives. This became the foundation of the Microsoft Security Development Lifecycle (SDL), which outlines a clear pathway, so security and privacy considerations are incorporated at every stage of the software development pipeline.

At Shearwater, we believe that developing a secure web app requires combining the OWASP security parameters, while implementing them at the appropriate stages of a development pipeline, such as the one outlined in Microsoft’s SDL.

While the SDL is only 100% relevant if you’re building software exactly the way Microsoft does, following a traditional ‘waterfall’ software development model, it nonethless has elements you can adapt for agile development, as preferred by many developers.

This combination of the OWASP Top 10 with the Microsoft SDL increases your chances of developing a robust and secure web application.

 

What is the OWASP TOP 10 and why is it important?


By 2003, OWASP refined its list to the 10 most significant web app vulnerabilities. Since the release of the initial OWASP Top 10 list, many developers have relied on it as the holy grail of vulnerability assessment.

With the OWASP Top 10 being updated approximately every three years, most recently in 2017, developers have an up-to-date list of the most common vulnerabilities. These are identified following extensive studies. The 2017 list was compiled after analysing in excess of 2.3 million potential vulnerabilities on approximately 50,000 web applications. OWASP today has more than 36,000 participants in local chapters world-wide.

Whatever the nature of the site, such as webmail, e-commerce, online auctions or any other type of web app, it’s imperative that vulnerabilities and security flaws are plugged before going live.

It needs to be noted that the OWASP Top 10 is NOT designed to identify every possible vulnerability. Rather, it is designed to assist developers avoid common threats that pose the greatest risk to their application. Any determined hacker will find ways to breach even the most secure web apps. But in line with risk management strategies, the OWASP Top 10 list focuses on the most common vulnerabilities.

That’s why OWASP is important.

 

How to do OWASP Testing?


Many developers use the OWASP Top 10 as a checklist against which they can test their site before launch.

However, the checklist approach to security and privacy is not considered best practice.

Rather than developers considering from the outset how OWASP works and what the OWASP standards require, a tendency has emerged to consider the guidelines at the end of the development process.

We’ve witnessed many developers build web apps without explicitly incorporating security requirements as core priorities from the get-go. All too often, we encounter developers seeking to validate their work as OWASP compliant just prior to launch, almost as an afterthought.

Such a strategy is fraught with risk.

At such a late stage in the development pipeline, vulnerabilities that would have been easily rectified earlier, may become significantly more complex, timely and expensive to remediate.

This tendency to leave security considerations for late in the development pipeline stems from developers being educated to focus primarily on getting a web app built and working efficiently, often within tight deadlines. With this mindset, security is not the central concern because security-related issues are usually addressed by security specialists rather than developers.

One way in which this lack of focus on security manifests itself is in relation to the use of open source software. Increasingly, developers rely on open source components to quickly and easily add features to their products. This avoids the need to develop every component themselves from scratch.

However, frequently we see open source software being used that is prone to vulnerabilities. On many occasions, developers conduct cursory checks of the open source software in use, without delving deeply enough to identify potential flaws. Once any vulnerabilities in the open source software are identified, having already been integrated into the app, and usually at a late stage in the development, a significant risk exists that the project timeline will be set back, often at significant cost.   

This misunderstanding surrounding how and why OWASP should be used in the advancement of secure, high-quality coding is concerning. According to current OWASP chairman Martin Knobloch, the list should be a guide to writing good code. It was never designed to be a validating or box-ticking exercise after the code is written.

“ A guide on how to validate is not a guide on how to build in security.
You need to make security explicit. ”

OWASP chairman Martin Knobloch

 

Integrating Security and Privacy from the Outset


Knobloch’s message is one we strongly endorse.

We always urge web app developers to consider security and privacy from the outset of a project.

At an early stage of the development pipeline, you should explicitly specify minimum security and privacy requirements for the application. This should be done alongside your plans for how the app will ultimately be utilised within an operational environment.

Take time to establish a tracking system that includes ongoing testing for security vulnerabilities, as well as any remediation work that may be required to address them. Including this within your workflow should reduce the risk of major surprises at the end of the development pipeline and will help ensure your product release is not delayed due to unforeseen security vulnerabilities. 

Another strategy you can adopt is to integrate security specialists within the development team. Bringing together developers and security specialists allows everyone to bring their expertise to the table from the outset. The security specialists can ensure the vulnerabilities identified in the OWASP Top 10 are addressed at each stage of the project.

Remember – you have a big incentive to incorporate strategies that integrate security and privacy considerations from the very early planning stages: COST.

Analysis shows that a bug identified and fixed at the design stage of the development pipeline can be up to 60 x cheaper than attempting to remediate it with a patch after release. 

Integrating-Security-and-Privacy-from-the-Outset-

 

OWASP and the Secure Development Lifecycle


While embracing the OWASP guidelines is an important first step in developing a secure web app, of equal importance is the development lifecycle, so you can ensure you’re incorporating security at all the right stages.

This is best achieved by adopting the timeline recommendations advocated by Microsoft in the Security Development Lifecycle (SDL). This approach lays out all the security activities you should embrace in the development lifecycle, and the order in which you should implement them.

Following the SDL helps developers build more secure software and address security compliance requirements while reducing development costs by helping ensure security flaws are not discovered at the last minute. Comprising a collection of mandatory security activities, they are presented in the order in which they should occur and grouped by the phases of the traditional software development life cycle.

“The optimal time to influence a project’s design trustworthiness is “early in its life cycle. It is critically important to consider security and privacy concerns carefully during the design phase. Mitigation of security and privacy issues is much less expensive when performed during the opening stages of a project life cycle. Project teams should refrain from the practice of ‘bolting on’ security and privacy features and mitigations near the end of a project’s development.”

Microsoft SDL

By considering security and privacy in the ‘Requirements’ and ‘Design’ stages, which are the first two stages of the SDL, you will have an effective framework for incorporating the OWASP Top 10 and it will help you achieve the Shift-Left approach you need.

OWASP and the Secure Development Lifecycle

With Microsoft’s SDL, the key is to start early. Explicitly consider security from the beginning of the process, at the same time as you’re refining and designing your project.

 

REQUIREMENTS STAGE
 

 

 

Establish Security Requirements

  • Analyse security and privacy requirements from the outset of the initial planning phase.
  • This allows your development team to clearly identify what security measures need to be implemented at each stage of the development pipeline.
  • This also ensures the integration of security and privacy measures in a way that does not disrupt development plans and schedules.
  • Consider the security and privacy measures that will be required once the app is developed and running in a typical operating environment.
  • Establish a tracking system to ensure security measures are regularly tested throughout the development process, allowing time for additional work to remediate any identified vulnerabilities.
 

Create Quality Gates & Bug Bars

  • Use Quality Gates and Bug Bars to establish minimum baselines of acceptable security and privacy levels.
  • A Bug Bar is a fixed maximum number of bugs you’re prepared to accept. Bug Bars can be set for different types of bugs, depending on the severity of the bug and the risk it poses to your app.
  • This will enhance your ability to understand the risk levels associated with various security issues.
  • It will also enhance your team’s capacity to identify and fix bugs throughout the pipeline, prioritising “critical” or “important” bugs that pose greater levels of risk.
 

 

Security & Privacy Risk Assessment

  • Conduct Security Risk Assessments (SRAs) and Privacy Risk Assessments (PRAs) to identify areas for deeper investigation.
  • These assessments will help you determine:
    · Any threat modelling requirements before release.
    · Any Penetration Testing requirements by external experts such as Shearwater.
    · What your Privacy Impact Rating (PIR) is:
    ⋅ High – transferring Personally Identifiable Information (PII).
    ⋅ Moderate – transferring anonymous data.
    ⋅ Low – no data transfers.

 

 

DESIGN STAGE
 

 

Establish Design Requirements

  • This phase focuses on more specific design requirements including:
    · Security and Privacy design specifications.
    · Minimal cryptographic design specifications.
  • The design specifications should describe features that will be directly exposed to users and how all functionality should be securely deployed.
  • Focus on building in ‘secure features’ where all aspects of the functionality are well engineered with respect to Security and Privacy, as opposed to bolting on ‘security features’ which describes specific functionality with security implications.
 

Analyse Attack Surface

  • Involves reducing risk by giving attackers less opportunity to exploit vulnerabilities.
  • This is achieved by restricting access levels and employing the principle of least privilege with layered defences.
 

Threat Modelling

  • A team exercise involving managers, developers and testers.
  • It is the primary security analysis task during the design stage of the pipeline.
  • It allows development teams to consider the security implications of their web app designs in the context of the planned operational environment.

Adopted individually, each of these measures provides a degree of enhanced security. However, the full benefit comes from implementing all of them as integral parts of the development process.

 

 

How Shearwater can help you


Vulnerable web applications are the most common point of attack on an organisation.

Attacks via web apps have resulted in the theft of millions of credit cards, and
compromised critical information for organisations and end users.

Reduce your vulnerability to attack with Shearwater’s team of expert Penetration Testers.

We understand how to protect your web app from the most common vulnerabilities identified by the OWASP Top 10 list. With a Web Application Penetration Test, we will perform an authorised ethical hacking attempt on your web application.

The aim of this test is to identify and exploit vulnerabilities relating to:

  • Authorisation;
  • Security configuration; and
  • Data protection mechanisms.

We offer in-depth executive level reporting which serves as a risk minimisation tool for management, and a technical document – listing vulnerabilities prioritised according to risk level – for the internal security team.

The report also provides access to mitigation strategies based on Shearwater’s key insights into the cyber-threat landscape.

By following the OWASP Top 10 guidelines in conjunction with the Secure Development Lifecycle timeline, and then having your web app expertly tested by Shearwater’s team of Penetration Testers, your organisation stands the best chance of reducing your web app’s risk profile.