Applying Web Application Recognition to Offensive Hacking
Securing web applications is a team sport. To stand a chance against a growing wave of web application attacks, software engineers and security professionals need to know when to pass the ball. The integration of security expertise into software engineering is a key starting point.
Web application security, published by O’Reilly Media, is a comprehensive resource for software engineers seeking to learn and apply security concepts to modern web applications. Once a software engineer himself, author Andrew Hoffman understands their important role in preventing application vulnerabilities, with enough security knowledge.
Hoffman intentionally organized the book into three parts – Recon, Offense, and Defense – so that each section builds on the last. With a foundation in web application recognition in their toolbox, software engineers can better understand the techniques of attackers and create applications that are more secure and resistant to hackers.
In the following excerpt from Chapter 9, “Introduction to Web Application Hacking,” enter the mindset of a hacker by applying web application recognition techniques to find and exploit application vulnerabilities. .
The hacker’s state of mind
Becoming a successful hacker takes more than an objectively measurable set of skills and knowledge, it also takes a very specific mindset.
Software engineers measure productivity in terms of added value through features or enhancements to an existing code base. A software engineer might say, “I added the x and y functionality, so today was a good day.” Alternatively, they might say, “I improved the performance of features a and b by 10%”, alluding to the fact that the work of a software engineer, while difficult to measure against traditional professions, is still quantifiable. .
Hackers measure productivity in ways that are much more difficult to discern and measure. This is because the majority of hacking actually involves collecting and analyzing data. Often times, this process is riddled with false positives and can feel like wasted time to an uneducated viewer.
Most hackers don’t deconstruct or modify software, but rather analyze software in order to work with the existing code base, looking for entry points rather than creating them. Often the skills used to analyze an application while looking for entry points are similar, if not identical, to the skills presented in Part One of this book.
Any given codebase is full of bugs that could potentially be exploitable. A good hacker is constantly looking for clues that could lead to the discovery of a vulnerability.
Unfortunately, the nature of this job means that even a good hacker can spend a lot of time without much success. It’s entirely possible to spend weeks, if not months, analyzing a web application before a suitable entry point can be found and an exploit can be designed and delivered.
As a hacker, you have to constantly stress the importance of finding and delivering a payload. Beyond that, you should also carefully keep a record of your past attempts and the lessons you learned from them. Attention to detail when saving past work will be crucial as you move on from crawling small apps and starting hacking larger apps, especially with key features or data as a target.
As we have seen in the history of software security, hackers must also constantly improve their skills, otherwise they will be beaten by those who intend to keep them away from their software. This means that a hacker must also constantly learn, as old techniques can lose their value as the web adapts.
A hacker is above all a detective. A good hacker is a well-organized sleuth, and a good hacker is a good hacker who also has excellent technical knowledge and skills. A master hacker possesses all of the above and is constantly learning and adapting their skills as those who try to fend them off improve their own skills.
In Part 1, we learned how to research a web application, learning various information about its underlying technology and structure along the way. This part is about taking advantage of security holes in the same applications.
The lessons of Part I should not be forgotten, however. These lessons will be crucial for the future, and you will soon understand why.
In Part 1, you learned how to determine what type of API an application uses to deliver data to its clients (the browser in our examples). We’ve learned that most modern web applications use REST APIs to achieve this. The examples in the following chapters will mainly involve sending a payload through a REST API. As a result, being able to determine the API type of an app you’re trying to hack will be important here.
Additionally, we used a combination of public records and network scripts to discover undocumented API endpoints. In this chapter, the exploits we develop will be applicable to many different web applications. As we learned in Part I, sometimes it can be useful to try the same exploit against multiple apps with the same owner. It is very possible that due to code reuse, you could find an exploit against a single web application and replicate it to internal web applications discovered through the techniques described in previous chapters.
Topics surrounding endpoint discovery will also be beneficial, as you may come across multiple API endpoints that take similarly structured payload. Maybe an attack on / users / 1234 / friends does not return any sensitive non-public data, but / users / 1234 / settings could.
Understanding how to understand the authentication scheme in place for a web application is also crucial. Most web applications today provide a superset of guest functionality to authenticated users. This means that the number of APIs you can attack with an auth token is greater, and the privileges granted to processes running as a result of those requests will likely be greater.
In the first part, we also learned how to identify third-party dependencies (often OSS) in an application. In this part, we’ll learn how to find and customize publicly documented exploits against third-party dependencies. Sometimes we can even find a security hole resulting from integration between custom code and third party code.
Our discussions and analyzes regarding the architecture of the application will be valuable here, as we can see that if application A cannot be exploited, application B can. If we don’t have a way to deploy an exploit directly to Application B, instead we can look at the ways in which Application A communicates with Application B in order to try to find a way to deliver our payload. to application A, which would then later communicate it to application B.
To conclude and underline once again, the recognition skills of the previous chapters and the hacking skills of the upcoming chapters go hand in hand. Hacking and Reconnaissance are all complex and interesting skills on their own, but together they are much more valuable.