The number of web-based applications used by organizations large and small has significantly expanded in the digital transformation age. As a result, the attack surface area has also grown — and attackers have wasted no time targeting the personal, payment and proprietary data contained in these applications. In fact, 43% of breaches were linked to web application attacks, according to the Verizon 2020 Data Breach Investigations Report — a twofold increase from the prior year.
Web application vulnerabilities are a common threat vector for malicious actors. In response, organizations must deploy preventative application security measures. But the responsibility for securing enterprise applications shouldn’t fall to security teams alone, said Andrew Hoffman, author of Web Application Security,published by O’Reilly Media. For best results, software engineers should be security stakeholders, too.
Before becoming a security engineer, Hoffman was a software engineer himself. He wrote Web Application Security for software engineers as a practical guide to both offensive and defensive security concepts.
Here, Hoffman discusses the importance of a secure web application architecture and explains how software engineers can play a larger role in preventing both security and performance issues.
Editor’s note: This transcript has been edited for length and clarity.
Why did you write this book, and what do you hope people will take away from it?
Andrew Hoffman: I had a career transition where I was writing code for a security product and advising people on how to write secure code and find security issues in existing code. I found there weren’t any books aimed at software engineers who want to learn security.
In the olden days, few people understood that future applications and websites would be so complex — or that many web security issues would [stem from] how a website is written. Older literature reflects this: Many were written for preventing security vulnerabilities at the network level. But, in today’s modern web and mobile applications, many security concerns happen at the code level, either in a mobile app, web browser, server or any point of connection in between.
The book is organized into three parts: Recon, Offense and Defense. What is the meaning of those three aspects of web application security?
Hoffman: This organization is intentional. It starts with Chapter 1, “The History of Software Security,” which walks through major cryptography and application security developments from World War II to now. This high-level background helps set up for “Part I. Recon.” This section explains how to look at and analyze an application, how to determine what technology it’s built on and common processes used to build software.
That leads into “Part II. Offense,” which breaks down how to investigate web application vulnerabilities. It has information on what to look for, what makes it tick and methods for breaking into the application. Now that you know how to map and attack web applications, the logical next step is learning to prevent others from breaking in, which is covered in “Part III. Defense.”
As the code base expands, you’ll find more and more bugs until eventually you end up playing whack-a-mole. You can save an enormous amount of time by focusing on secure web application architecture initially. Andrew Hoffman
In Web Application Security, you wrote that most vulnerabilities stem from improper web application architecture design rather than from poorly written methods. Why is that distinction important?
Hoffman: Many software engineers think that improving the speed of smaller, slower functions in an application will also improve the speed of the application. But performance bottlenecks often result from incorrect application architecture.
The same thing is true in security. Consider one of the most common ways hackers break into web applications: cross-site scripting [XSS]. As the code base expands, you’ll find more and more bugs until eventually you end up playing whack-a-mole. You can save an enormous amount of time by focusing on secure web application architecture initially. For example, use a standardized library to manipulate the browser Document Object Model [DOM], implement every mitigation in the standardized library and make sure everyone in the organization goes through the same standardized workflow for creating client applications. Many companies still don’t do this. They’re wasting money and potentially putting their customers at risk as a result.
How can security and development teams secure web application architecture and prevent common application security threats?
Hoffman: For an application to be secure in the long run, you need a tight coupling between security and software engineering. Ultimately, they can’t be in silos. Engineers have to understand security red flags — not only when writing code, but also when designing features at the architecture phase of application development. Engineers should be security-aware enough that, if a vulnerability is found after an application is published, they’re capable of writing a test and fixing it. The reason for writing tests is so they can be automatically alerted if a security hole has been reopened in the application.
Many organizations still have security teams in conflict with engineering teams because security is often seen as a bottleneck — especially at older software companies. Every security benefit has tradeoffs elsewhere. For example, it takes much more time to write secure code. But implementing a mitigation may slow down the application performance or adversely affect user experience.
In an excerpt of Chapter 9 available on SearchSecurity, you wrote that quantifying a hacker’s productivity is difficult. Can you explain why?
Hoffman: Productivity gets significantly harder to measure in the software security world, especially for offensive software security practitioners — including red teams and bug bounty hunters. Surface-level vulnerabilities, such as XSS, are often easier to find. But other hacking methods are more specific to the business logic of the application. For example, an accounting application has business rules that may require extensive knowledge in order to understand how it works. The pen tester might need to learn accounting rules to determine whether they were entered in the system correctly. By the time they’ve learned the accounting rules, a pen tester could be halfway to becoming an accountant.
Does security get undervalued because it’s hard for organizations to measure?
Hoffman: Definitely. There’s a running joke in the security world that I first heard at DEF CON. Someone told me, ‘The easiest way to get your team’s budget increased is to have a serious security incident.’ It is true. After an incident, suddenly, the security staff head count goes up, the tooling increases, and people are sent to conferences and trainings because leadership finally understands the value.
Why should people pursue a career in security engineering or app security?
Hoffman: There is a huge workforce shortage. Anyone in this industry will tell you it’s hard to hire, especially in application security. Currently, there are not any schools that can prep you for this career. The education system and U.S. government struggle to retain security talent because the private industry pays so much better. The typical path is to get a tech job and learn about security there before transitioning to an application security role.
How would you describe your career transition into security?
Hoffman: The switch from engineering to security was so rewarding. When you’re an engineer, you’re dealing with many deliverables. Often, the most exciting thing is getting something done early or impressing a co-worker with how you implemented something. In the security world, there are incidents to respond to, there’s downtime, there’s uptime. It’s a lot less routine, which might appeal to the people who find a consistent schedule boring.
