courtesy – hack2secure
Why Do We Need To Secure Web Applications?
Companies use web applications for every factor of their business operations from the public websites to mission-serious business applications. With the increase in usability and vulnerabilities, web applications now become the target for the attackers to gain access. The followings are the reason why we need to secure web applications:
- Easy target, directly exposed Public Interface
- Larger Attack Surface
- Addition of Complex Design & Features, increase chances of Attacks
- Root Cause of above 80% of Security Attacks are directly or indirectly related to the Web
Why Web Security?
With a web application threats are becoming more frequent occurrence; several organizations are struggling to implement security on their web application programs; since they unaware what to do.
Understanding that “Security is a process, not a product” could be an ideal solution for their searches.
Web Security Testing: Current Limitations
The followings are the reasons that stands behind the failure of web security testing:
- Organizations focus on Testing Business Functionality & Capability on Deployed Applications
- Security Testing is the last thing to consider, usually after Functional Testing
- Current trend shows an exponential increase in vulnerability list related to Web Applications
Open Web Application Security Project (OWASP) is an International Non-Profit Charitable Open Source organization. Its participation is free and open to all. It is a technology agnostic and contributed selflessly to the security community. OWASP address Risk-based approach.
OWASP Top 10: Web Application Security Risk
This document includes the list of the 10 most web security risk in the web application. The errors listed occur most frequently in the web application and they’re dangerous since they’ll allow the hackers completely control the software and steal data. The primary aim of the list is to educate developers, designers, architects and organizations about consequences of most common web application security vulnerabilities.
OWASP Risk Rating Methodology
OWASP uses its Risk rating methodology, to analyse severity of these Risk, based on their impact, and prevalence.
Let us begin with, Standard risk model
OWASP has proposed the systematic, Risk Rating Methodology, assisting organizations to effectively analyse and manage the corresponding Web Security Risk.
Step#1: Identify A Risk
Identify Security Risk that needs to be rated. It gathers information about the following aspects:
- Involved Threat Agents
- Attack used
- Vulnerability involved
- Business Impact
Step#2: Factors For Estimating Likelihood
The main goal is to estimate the likelihood of a successful attack.
- Threat agent: Estimate the likelihood of a successful attack by the group of threat agents
- Vulnerability agent: Estimate the likelihood of the certain vulnerability involved being revealed & exploited.
Step#3: Factors For Estimating Impact
Focus on the impact of the successful attack. It concentrates on the technical impact and business impact.
Step#4: Determining The Severity Of Risk
Proceeding with the following steps:
- Find Likelihood & Impact based on Score
- Determine Severity
Step#5: Deciding What To Fix
Once the risks are classified, then prioritize list to determine what to fix.
Step#6: Customizing The Risk Rating Model
Three ways to customize the model are:
- Adding Factors
- Customizing Options
- Weighting Factors
OWASP Top 10: How Each Risk Is Analyzed
The table illustrates how each risk is analysed in the OWASP Top 10 document :
OWASP Top 10: 2013 & 2017 Web App Security Risk
The threat environment for the API and web application continually changes. To appear up-to-date, OWASP Top 10 periodically updates their list with the recent dangerous security vulnerabilities. Recently, it announced the release of OWASP Top 10 Critical Web Application Security Risks.
Here is the comparison of OWASP Top 10 – 2013 (Previous Version and OWASP Top 10 – 2017 (Current Version)
As shown in the above illustration:
- The vulnerabilities A4 – Insecure Direct Object Reference and A7- Missing Function Level Access Control in the 2013 list are merged and listed as A4-Broken Access Control in the 2017 list.
- Moreover, in the OWAPS 2017, three new risks called A4:2017-XML External Entities (XXE), A8:2017-Insecure Deserialization, and A10:2017-Insufficient Logging and Monitoring are added additionally
- The risks A8 – Cross-site Request Forgery and A10 – Unvalidated Redirects and Forwards was found in the only minimum percentage of applications, both are dropped from the list of critical web application security risks.
For More Details on OWASP Top 10 2017 Risk …