Parameter Logic Bugs
Module Methodology
Now, let's discuss the methodology we will utilize throughout this module to identify and study the different types of logic bugs we just defined, and the scenario we'll follow to explain it.
Methodology
The methodology we will follow in this module is quite similar to the Whitebox Pentesting Process as defined in the Intro to Whitebox Pentesting module, which is split into four main steps:
-
Code Review -
Local Testing -
Proof of Concept -
Patching & Remediation
We will start each logic bug type by explaining it in detail, and give a real example of how it may look like. Then, we will follow the above methodology/process, as follows:
| Order | Step | Description |
|---|---|---|
| 1 | Code Review |
We start by trying to navigate a large code base and understand the application design to identify potentially vulnerable functions. We will do so using both static and dynamic analysis, and we will combine app usage with code reviews to better understand the application logic. |
| 2 | Local Testing |
With a list of interesting functions, we will begin testing them for potential logic bugs, and will learn through each section how to identify each type. |
| 3 | Proof of Concept |
As this is a secure coding exercise and not a whitebox pentesting exercise, we will not be writing exploits. Instead, we will focus on exploiting the vulnerable functions based on our understanding from the previous two steps, as a way of 'proof of concept'. Then, we can confirm the vulnerability on the real target, but this must be done in a safe way that doesn't cause any downtime or data loss. |
| 4 | Patching & Remediation |
At the end of each logic bug type, we will discuss how to patch this type of logic bugs and the example we just exploited. We will also test the attacks again to ensure it has indeed been patched. |
Before we start discussing the different types of logic bugs, let's take a quick look at the scenario we will be following throughout this module.
Note: As a defensive secure coding module, our main target is to identify and patch the logic bugs. We will still show how we can take advantage (attack) some of the vulnerabilities, though this is not our primary objective, so we will not go into a lot of attacking details, other than what's necessary to understand why the logic bug exists.
Scenario
To fully understand real-world Logic Bugs and thoroughly comprehend the exercises and module material, we need a fully fletched real-world web application that we are familiar with and can easily navigate to identify its inconsistencies. There is one web application we can be certain that whoever takes this module is familiar with, Hack The Box Academy!
The above is an Academy replica that we re-built from scratch, both its front-end and back-end (using the MERN stack, for those interested). We put a lot of effort in creating a realistic demo with a sizable codebase, so that we can demonstrate all of the different types of Logic Bugs defined in the previous section with Academy as the vulnerable target.
We all know how the "real" Academy works, so this should give us a very clear contrast of how a logic bug would look, since we can compare the solid-logic-design (real academy) vs the weak-logic-design (replica academy).
Note: The development frameworks used in this Academy replica are not the same as the real Academy (e.g. Real Academy uses PHP while this uses JS). This, of course, will not have any effects whatsoever on the realism of the examples, as we are mainly interested in the application logic, which is irrelevant to its development framework, since these issues can occur regardless of what framework we use.
As a secure coding module, we will always provide the source code with each exercise, so that you can follow along the methodology we will describe next as you go through the various exercises. Even though we will use the same target web application for all examples of Logic Bugs, each would be configured slightly differently to showcase a different Logic Bug. So, be sure to download the source code of each new logic bug type.
IMPORTANT: Throughout the module, we will suggest various exercises and challenges, and we strongly recommend that you do each and every one of them. Even if you are not able to complete all of them, you will greatly improve your code-reviewing abilities by simply attempting to solve them, before following up with the section instructions, which usually cover the same so you can compare your work and see what you missed and where you can improve your work.
/ 1 spawns left
Questions
Answer the question(s) below to complete this Section and earn cubes!
Click here to spawn the target system!
Target:
Click here to spawn the target system!
+10 Streak pts
Table of Contents
Logic Bugs
Introduction to Logic Bugs Types of Logic Bugs Module Methodology Setting UpValidation Logic Disparity
Validation Logic Disparity Code Review - Validation Logic Disparity Local Testing - Validation Logic Disparity PoC and Patching - Validation Logic DisparityUnexpected Input
Unexpected Input Code Review - Unexpected Input Local Testing (Validation) - Unexpected Input Local Testing (Manipulation) - Unexpected Input PoC and Patching - Unexpected InputNull Safety
Null Safety Code Review (Null Variables) - Null Safety Code Review (Optional Parameters) - Null Safety Local Testing (Schemas) - Null Safety Local Testing (functions) - Null Safety PoC and Patching - Null SafetyAvoiding Parameter Logic Bugs
Avoiding Parameter Logic BugsSkill Assessment
Skill Assessment - Parameter Logic BugsMy Workstation
OFFLINE
/ 1 spawns left
