Ask the experts: What’s the worst web application security issue?

by Synopsys Editorial Team on July 8, 2019

Spoiler: There isn’t a “worst web application security issue,” because every app is unique. But these issues are a good place to start your security review.

We know. It’s an impossible question to answer. There’s no such thing as a “worst web application security issue,” because every app and every organization has its own unique set of issues. But if you’re a development organization with limited resources, how do you know where to start? Which issues appear over and over in data breaches, exploits, and top N lists such as the OWASP Top 10? We asked some experts—and Twitter—to give us their opinions.

Help us answer this important #security question: What is the worst web #AppSec issue?
— Software Integrity (@SW_Integrity) June 26, 2019

The results: Broken authentication is a particularly dangerous web app security issue. Without proper authentication, you’ll never know who’s really using your system. And to no one’s surprise, using open source and third-party components with known vulnerabilities is another really bad move. If you don’t know what’s in your code, and you don’t update and patch regularly, you’re in trouble—just ask these guys. But web app security doesn’t stop there. Read on to see what the experts say about the worst web application security issues and how to fix them.

Sponsorships Available

Broken authentication

It is difficult to assign a “No. 1 most serious web app security issue” because, obviously, “most serious” is contextual. For any company with a web app, the “most serious” security issue is the one that could be used to compromise their app.

From my 10,000 foot view as a journalist covering the space—reflecting on the compromise stories I write about and the many more I read about—I would say that authentication related issues (or “broken authentication,” as OWASP terms it) is a huge issue. Simply put: web application development organizations are not paying enough attention to technically simple problems like password reuse or brute force/credential stuffing attacks. The flaws are particularly troublesome because they leave web applications open to compromise by even unsophisticated actors. Authentication issues are relatively easy to identify and fix. They’re even easier for development teams to anticipate and prevent. Web application development teams need to consider problems like credential stuffing and password reuse, username enumeration and other trivial hacks and take steps to prevent their web applications from being compromised using these well-worn techniques.

—Paul Roberts, publisher and editor-in-chief of The Security Ledger

Injection and improper validation

Lack of validation for form entries. It’s the oldest flaw in the book, well-publicised with known consequences, yet is still prevalent. There is no excuse.
— Tony Dalton (@Tony_Dalton4) June 28, 2019

Using components with known vulnerabilities

Most organizations that author web software end up deploying third party code into production. By some estimates 80–90% of the code that makes up the average web application comes from third party libraries or components. The security of these third party components is questionable at best. An entire branch of scanning tools and services has cropped up to manage the problem of security issues within third party libraries and components. The security issues around “Using Third Party Components” has also been a OWASP Top Ten item since 2013.

—Jim Manico, global board member of OWASP Foundation

Using components with unknown vulnerabilities

Closed source software with unknown vulnerabilities.
— Barely Functional::🏴󠁧󠁢󠁳󠁣󠁴󠁿🇪🇺::ᛊᛁᛗᛟᚾ (@simon_brooke) June 29, 2019

Another vote for third-party components

Whilst only ranking No. 9 on the OWASP Top 10, “Using Components with Known Vulnerabilities” is an extremely important issue that organisations should work on ensuring they are monitoring and understanding their attack surface for the dependencies they rely on. A good example of this is Ruby On Rails CVE-2019-5418, which allowed attackers to retrieve host content from the web server. An issue on npm was event-stream, where the project was “given away” to a malicious actor who inserted code into the project which attempted to steal bitcoin from hosts which installed the dependency.

A few things to consider when dealing with the third-party components:

Build an asset registry of third-party components.
Monitor your third-party components using tools such as Black Duck, Dependency Check, npm audit, and Synk.
Pin dependency versions where possible to prevent issues such as event-stream affecting your organization.
Develop a process to update and regression test external components
Use a strong Content Security Policy (CSP) to define how and what resources should be loaded on your website.
Use Subresource Integrity (SRI) on third-party components.

—Lewis Ardern, senior security consultant, Synopsys (watch his webinar on JavaScript security reviews)

Inadequate monitoring

No attack vector is of significance if it does not stretch from the point of entry, through the system, to a key component.
That’s why you have security kernels, why they’re useful at all.
The worst failure is to make such a long fracture possible. Everything else happens.
— John Steed (@imipak) June 26, 2019

Don’t forget about business logic

I think focusing on one issue is the wrong approach. Even though one may raise the security bar for attackers by focusing on one (or ten) issues, there still remain many things that an attacker can exploit outside of those. For high-risk applications, one should definitely look broader than those canned lists.

If one decides to focus on one issue, pick the one that is a quick win (big risk, easy to fix, most of your applications are riddled with it) using data from past security assessments against the applications within your company.

Develop an approach to fix that one issue thoroughly, including educating developers, and potentially writing automated tests to detect such issues across your whole application portfolio.

The main takeaway: Your common and high-risk issues are not necessarily the same as mine. Pick your own one issue based on data.

If you want one, I think logic issues are undervalued.

—Koen Buyens, associate principal consultant, Synopsys (read his white paper on blockchain security)