Improper resource access authorization checkmarx java

Insufficient Login And Monitoring

OWASP Top 10 - 2017 The Ten Most Critical Web Application Security Risks

This work is licensed under a

Creative Commons Attribution-ShareAlike 4.0 International Licensehttps://owasp.org

https://creativecommons.org/licenses/by-sa/4.0/
http://creativecommons.org/licenses/by-sa/4.0/
1

Copyright and License

Copyright © 2003 – 2017 The OWASP Foundation

This document is released under the Creative Commons Attribution Share-Alike 4.0 license.

For any reuse or distribution, you must make it clear to others the license terms of this work.

Table of Contents About OWASP

The Open Web Application Security Project (OWASP) is an

open community dedicated to enabling organizations to

develop, purchase, and maintain applications and APIs that

can be trusted.

At OWASP, you'll find free and open:

• Application security tools and standards.

• Complete books on application security testing, secure code development, and secure code review.

• Presentations and videos. • Cheat sheets on many common topics. • Standard security controls and libraries. • Local chapters worldwide. • Cutting edge research. • Extensive conferences worldwide. • Mailing lists.

Learn more at: https://www.owasp.org.

All OWASP tools, documents, videos, presentations, and

chapters are free and open to anyone interested in improving

application security.

We advocate approaching application security as a people,

process, and technology problem, because the most

effective approaches to application security require

improvements in these areas.

OWASP is a new kind of organization. Our freedom from

commercial pressures allows us to provide unbiased,

practical, and cost-effective information about application

security.

OWASP is not affiliated with any technology company,

although we support the informed use of commercial security

technology. OWASP produces many types of materials in a

collaborative, transparent, and open way.

The OWASP Foundation is the non-profit entity that ensures

the project's long-term success. Almost everyone associated

with OWASP is a volunteer, including the OWASP board,

chapter leaders, project leaders, and project members.

We support innovative security research with grants and

infrastructure.

Come join us!

TOC Table of Contents

TOC - About OWASP ……………………………… 1

FW - Foreword …………..………………...……… 2

I - Introduction ………..……………….……..… 3

RN - Release Notes …………..………….…..….. 4

Risk - Application Security Risks…………….…… 5

T10 - OWASP Top 10 Application Security

Risks – 2017 …………..……….....….…… 6

A1:2017 - Injection …….………..……………………… 7

A2:2017 - Broken Authentication ……………………... 8

A3:2017 - Sensitive Data Exposure ………………….. 9

A4:2017 - XML External Entities (XXE) ……………... 10

A5:2017 - Broken Access Control ……………...…….. 11

A6:2017 - Security Misconfiguration ………………….. 12

A7:2017 - Cross-Site Scripting (XSS) ….…………….. 13

A8:2017 - Insecure Deserialization ……………………14

A9:2017 - Using Components with Known

Vulnerabilities .……………………………… 15

A10:2017 - Insufficient Logging & Monitoring….…..….. 16

+D - What’s Next for Developers ….………..….. 17

+T - What’s Next for Security Testers .……..….. 18

+O - What’s Next for Organizations ….....…….... 19

+A - What’s Next for Application Managers ...... 20

+R - Note About Risks ……..……………………. 21

+RF - Details About Risk Factors ……………..…. 22

+DAT - Methodology and Data …..………………… 23

+ACK - Acknowledgements ………………..………. 24

http://creativecommons.org/licenses/by-sa/3.0/
https://www.youtube.com/user/OWASPGLOBAL
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
https://www.owasp.org/index.php/OWASP_Chapter
https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference
https://lists.owasp.org/mailman/listinfo
https://www.owasp.org
2

Foreword

Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure. As our software

becomes increasingly complex, and connected, the difficulty of achieving application security increases exponentially. The

rapid pace of modern software development processes makes the most common risks essential to discover and resolve

quickly and accurately. We can no longer afford to tolerate relatively simple security problems like those presented in this

OWASP Top 10.

A great deal of feedback was received during the creation of the OWASP Top 10 - 2017, more than for any other equivalent

OWASP effort. This shows how much passion the community has for the OWASP Top 10, and thus how critical it is for

OWASP to get the Top 10 right for the majority of use cases.

Although the original goal of the OWASP Top 10 project was simply to raise awareness amongst developers and managers,

it has become the de facto application security standard.

In this release, issues and recommendations are written concisely and in a testable way to assist with the adoption of the

OWASP Top 10 in application security programs. We encourage large and high performing organizations to use the OWASP

Application Security Verification Standard (ASVS) if a true standard is required, but for most, the OWASP Top 10 is a great

start on the application security journey.

We have written up a range of suggested next steps for different users of the OWASP Top 10, including What’s Next for

Developers, What’s Next for Security Testers, What’s Next for Organizations, which is suitable for CIOs and CISOs, and

What’s Next for Application Managers, which is suitable for application managers or anyone responsible for the lifecycle of

the application.

In the long term, we encourage all software development teams and organizations to create an application security program

that is compatible with your culture and technology. These programs come in all shapes and sizes. Leverage your

organization's existing strengths to measure and improve your application security program using the Software Assurance

Maturity Model.

We hope that the OWASP Top 10 is useful to your application security efforts. Please don't hesitate to contact OWASP with

your questions, comments, and ideas at our GitHub project repository:

• https://github.com/OWASP/Top10/issues

You can find the OWASP Top 10 project and translations here:

• https://www.owasp.org/index.php/top10

Lastly, we wish to thank the founding leadership of the OWASP Top 10 project, Dave Wichers and Jeff Williams, for all their

efforts, and believing in us to get this finished with the community's help. Thank you!

• Andrew van der Stock

• Brian Glas

• Neil Smithline

• Torsten Gigler

Project Sponsorship

Thanks to Autodesk for sponsoring the OWASP Top 10 - 2017.

Organizations and individuals that have provided vulnerability prevalence data or other assistance are listed on the

Acknowledgements page.

FW Foreword

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
https://www.owasp.org/index.php/OWASP_SAMM_Project
https://github.com/OWASP/Top10/issues
https://www.owasp.org/index.php/top10
https://www.autodesk.com/
3

Welcome to the OWASP Top 10 - 2017!

This major update adds several new issues, including two issues selected by the community - A8:2017-Insecure

Deserialization and A10:2017-Insufficient Logging and Monitoring. Two key differentiators from previous OWASP Top 10

releases are the substantial community feedback and extensive data assembled from dozens of organizations, possibly the

largest amount of data ever assembled in the preparation of an application security standard. This provides us with

confidence that the new OWASP Top 10 addresses the most impactful application security risks currently facing

organizations.

The OWASP Top 10 - 2017 is based primarily on 40+ data submissions from firms that specialize in application security and

an industry survey that was completed by over 500 individuals. This data spans vulnerabilities gathered from hundreds of

organizations and over 100,000 real-world applications and APIs. The Top 10 items are selected and prioritized according to

this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact.

A primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the

consequences of the most common and most important web application security weaknesses. The Top 10 provides basic

techniques to protect against these high risk problem areas, and provides guidance on where to go from here.

Roadmap for future activities

Don't stop at 10. There are hundreds of issues that could

affect the overall security of a web application as discussed

in the OWASP Developer's Guide and the OWASP Cheat

Sheet Series. These are essential reading for anyone

developing web applications and APIs. Guidance on how to

effectively find vulnerabilities in web applications and APIs

is provided in the OWASP Testing Guide.

Constant change. The OWASP Top 10 will continue to

change. Even without changing a single line of your

application's code, you may become vulnerable as new

flaws are discovered and attack methods are refined.

Please review the advice at the end of the Top 10 in What's

Next For Developers, Security Testers, Organizations, and

Application Managers for more information.

Think positive. When you're ready to stop chasing

vulnerabilities and focus on establishing strong application

security controls, the OWASP Proactive Controls project

provides a starting point to help developers build security

into their application and the OWASP Application Security

Verification Standard (ASVS) is a guide for organizations

and application reviewers on what to verify.

Use tools wisely. Security vulnerabilities can be quite

complex and deeply buried in code. In many cases, the

most cost-effective approach for finding and eliminating

these weaknesses is human experts armed with advanced

tools. Relying on tools alone provides a false sense of

security and is not recommended.

Push left, right, and everywhere. Focus on making

security an integral part of your culture throughout your

development organization. Find out more in the OWASP

Software Assurance Maturity Model (SAMM).

Attribution

We'd like to thank the organizations that contributed their

vulnerability data to support the 2017 update. We received

more than 40 responses to the call for data. For the first

time, all the data contributed to a Top 10 release, and the full

list of contributors is publicly available. We believe this is one

of the larger, more diverse collections of vulnerability data

ever publicly collected.

As there are more contributors than space here, we have

created a dedicated page to recognize the contributions

made. We wish to give heartfelt thanks to these

organizations for being willing to be on the front lines by

publicly sharing vulnerability data from their efforts. We hope

this will continue to grow and encourage more organizations

to do the same and possibly be seen as one of the key

milestones of evidence-based security. The OWASP Top 10 would not be possible without these amazing contributions.

A big thank you to the more than 500 individuals who took

the time to complete the industry ranked survey. Your voice

helped determine two new additions to the Top 10. The

additional comments, notes of encouragement,

and criticisms were all appreciated. We know your time is

valuable and we wanted to say thanks.

We would like to thank those individuals who have

contributed significant constructive comments and time

reviewing this update to the Top 10. As much as possible,

we have listed them on the ‘Acknowledgements’ page.

And finally, we'd like to thank in advance all the translators

out there who will translate this release of the Top 10 into

numerous different languages, helping to make the OWASP

Top 10 more accessible to the entire planet.

I Introduction

https://www.owasp.org/index.php/OWASP_Guide_Project
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
https://www.owasp.org/index.php/OWASP_Testing_Project
https://www.owasp.org/index.php/OWASP_Proactive_Controls
https://www.owasp.org/index.php/ASVS
https://www.owasp.org/index.php/OWASP_SAMM_Project
4

What changed from 2013 to 2017? Change has accelerated over the last four years, and the OWASP Top 10 needed to change. We've completely refactored the OWASP Top 10, revamped the methodology, utilized a new data call process, worked with the community, re-ordered our risks, re- written each risk from the ground up, and added references to frameworks and languages that are now commonly used.

Over the last few years, the fundamental technology and architecture of applications has changed significantly:

• Microservices written in node.js and Spring Boot are replacing traditional monolithic applications. Microservices come with their own security challenges including establishing trust between microservices, containers, secret management, etc. Old code never expected to be accessible from the Internet is now sitting behind an API or RESTful web service to be consumed by Single Page Applications (SPAs) and mobile applications. Architectural assumptions by the code, such as trusted callers, are no longer valid.

• Single page applications, written in JavaScript frameworks such as Angular and React, allow the creation of highly modular feature-rich front ends. Client-side functionality that has traditionally been delivered server-side brings its own security challenges.

• JavaScript is now the primary language of the web with node.js running server side and modern web frameworks such as Bootstrap, Electron, Angular, and React running on the client.

New issues, supported by data:

• A4:2017-XML External Entities (XXE) is a new category primarily supported by source code analysis security testing tools (SAST) data sets.

New issues, supported by the community:

We asked the community to provide insight into two forward looking weakness categories. After over 500 peer submissions, and removing issues that were already supported by data (such as Sensitive Data Exposure and XXE), the two new issues are:

• A8:2017-Insecure Deserialization, which permits remote code execution or sensitive object manipulation on affected platforms.

• A10:2017-Insufficient Logging and Monitoring, the lack of which can prevent or significantly delay malicious activity and breach detection, incident response, and digital forensics.

Merged or retired, but not forgotten:

• A4-Insecure Direct Object References and A7-Missing Function Level Access Control merged into A5:2017-Broken Access Control.

• A8-Cross-Site Request Forgery (CSRF), as many frameworks include CSRF defenses, it was found in only 5% of applications.

• A10-Unvalidated Redirects and Forwards, while found in approximately 8% of applications, it was edged out overall by XXE.

OWASP Top 10 - 2013  OWASP Top 10 - 2017

A1 – Injection  A1:2017-Injection

A2 – Broken Authentication and Session Management  A2:2017-Broken Authentication

A3 – Cross-Site Scripting (XSS)  A3:2017-Sensitive Data Exposure

A4 – Insecure Direct Object References [Merged+A7] ∪ A4:2017-XML External Entities (XXE) [NEW]

A5 – Security Misconfiguration  A5:2017-Broken Access Control [Merged]

A6 – Sensitive Data Exposure  A6:2017-Security Misconfiguration

A7 – Missing Function Level Access Contr [Merged+A4] ∪ A7:2017-Cross-Site Scripting (XSS)

A8 – Cross-Site Request Forgery (CSRF)  A8:2017-Insecure Deserialization [NEW, Community]

A9 – Using Components with Known Vulnerabilities  A9:2017-Using Components with Known Vulnerabilities

A10 – Unvalidated Redirects and Forwards  A10:2017-Insufficient Logging&Monitoring [NEW,Comm.]

RN Release Notes

https://www.owasp.org/index.php/Source_Code_Analysis_Tools
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
5

What Are Application Security Risks? Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention.

Sometimes these paths are trivial to find and exploit, and sometimes they are extremely difficult. Similarly, the harm that is caused may be of no consequence, or it may put you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine your overall risk.

Weakness

Attack

Threat Agents

ImpactWeakness

Attack

Attack Vectors

Security Weaknesses

Technical Impacts

Business Impacts

Attack

Impact

Impact

Asset

Function

Asset

Weakness

Control

Control

ControlWeakness

Security Controls

Risk Application Security Risks

What’s My Risk? The OWASP Top 10 focuses on identifying the most serious web application security risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using the following simple ratings scheme, which is based on the OWASP Risk Rating Methodology.

In this edition, we have updated the risk rating system to assist in calculating the likelihood and impact of any given risk. For more details, please see Note About Risks.

Each organization is unique, and so are the threat actors for that organization, their goals, and the impact of any breach. If a public interest organization uses a content management system (CMS) for public information and a health system uses that same exact CMS for sensitive health records, the threat actors and business impacts can be very different for the same software. It is critical to understand the risk to your organization based on applicable threat agents and business impacts.

Where possible, the names of the risks in the Top 10 are aligned with Common Weakness Enumeration (CWE) weaknesses to promote generally accepted naming conventions and to reduce confusion.