Collaboration is the key to a secure web application architecture
The number of web applications used by organizations large and small has increased dramatically in the age of digital transformation. As a result, the attack surface also increased – and attackers wasted no time targeting the personal, payment, and owner data contained in these apps. In fact, 43% of breaches were related to web application attacks, according to the Verizon 2020 Data Breach Investigations report, a double increase from the previous year.
Web application vulnerabilities are a common threat vector for malicious actors. In response, organizations should deploy preventative application security measures. But the responsibility for securing business applications shouldn’t be the responsibility of security teams alone, said Andrew Hoffman, author of Web application security, published by O’Reilly Media. For best results, software engineers should also be security actors.
Before becoming a security engineer, Hoffman was himself a software engineer. He wrote Web application security for software engineers as a practical guide to offensive and defensive security concepts.
Here, Hoffman discusses the importance of a secure web application architecture, and how software engineers can play a bigger role in preventing 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 take away from it?
Andrew Hoffman: I had a career transition where I was writing code for a security product and counseling people on how to write secure code and find security issues in existing code. I have found that there are no books for software engineers who want to learn security.
In the past, few people understood that future apps and websites would be so complex – or that many web security issues would be. [stem from] how a website is written. Older literature reflects this: Much has been written to prevent security vulnerabilities at the network level. But, in today’s modern web and mobile apps, there are a lot of security issues that arise at the code level, whether it’s in a mobile app, web browser, server, or some other intermediate connection point.
The book is organized into three parts: Recon, Offense, and Defense. What do these three aspects of web application security mean?
Hoffman: This organization is intentional. It begins with Chapter 1, “The History of Software Security,” which reviews major developments in cryptography and application security from World War II to the present day. This high level background helps in setting up “Part I. Recon”. This section explains how to watch and analyze an application, how to determine the technology it is based on, and the common processes used to create software.
This leads to “Part II. Offense,” which explains how to investigate vulnerabilities in web applications. It contains information on what to look for, what motivates them, and methods to get into the app. Now that you know how to map and attack web applications, the next logical step is to learn how to prevent others from breaking and entering, which is covered in “Part III. Defense”.
In Web application security, you wrote that most vulnerabilities come from incorrectly designed web application architecture rather than poorly written methods. Why is this distinction important?
Hoffman: Many software engineers believe 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 is true when it comes to security. Consider one of the most common ways that hackers break into web applications: cross-site scripting. [XSS]. As the codebase expands you will find more and more bugs until you end up playing whack-a-mole. You can save a tremendous amount of time by focusing on a secure web application architecture initially. For example, use a standardized library to manipulate the browser document object model [DOM], implement each mitigation in the standardized library, and make sure everyone in the organization goes through the same standardized workflow to build client applications. Many companies still don’t. They waste money and potentially put their customers at risk.
How can security and development teams secure the architecture of web applications and prevent common application security threats?
Hoffman: For an application to be secure in the long term, you need a tight coupling between security and software engineering. At the end of the day, they can’t be silos. Engineers need to understand security red flags not only when writing code, but also when designing features during the architecture phase of application development. Engineers need to be security aware enough that if a vulnerability is discovered after an application is released, they are able to write a test and fix it. The reason for writing tests is that they can be automatically alerted if a security vulnerability has been reopened in the application.
Many organizations still have security teams in conflict with engineering teams, as security is often seen as a bottleneck, especially in older software companies. Every security benefit has tradeoffs elsewhere. For example, writing secure code takes much longer. But implementing mitigation can slow app performance or adversely affect user experience.
In an excerpt from Chapter 9 available on SearchSecurity, you wrote that it’s hard to quantify a hacker’s productivity. Can you explain why?
Hoffman: Productivity becomes much harder to measure in the world of software security, 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 may need to learn accounting rules to determine if they have been entered correctly into the system. By the time they have learned the rules of accounting, a pen tester might be halfway to becoming an accountant.
Is security undervalued because it is difficult for organizations to measure?
Hoffmann: Sure. There is a common joke in the security world that I first heard at DEF CON. Someone said to me, “The easiest way to increase your team’s budget is to have a serious security incident.” It’s true. After an incident, all of a sudden, security personnel increases, tooling increases, and people are sent to conferences and training because management finally understands the value.
Why should people pursue careers in security engineering or application security?
Hoffman: There is a huge labor shortage. Anyone in this industry will tell you that hiring is difficult, especially in application security. Currently, no school can prepare you for this career. The education system and the US government are struggling to retain security talent because private industry pays much better. The typical path is to get a technical job and learn more about security before moving into an Application Security role.
How would you describe your career transition in security?
Hoffman: The transition from engineering to safety has been very rewarding. When you are an engineer, you are faced with many deliverables. Often times the most exciting thing is getting something done early or impressing a coworker with how you implemented something. In the security world, there are incidents to respond to, there are downtime, there are uptime. It’s much less routine, which might appeal to people who find a consistent schedule boring.