Second-Order IDOR (Whitebox)

Now that we have covered background information about second-order vulnerabilities, we will explore methods for identifying, exploiting, and mitigating them within a web application using a whitebox approach.

---

Code Review - Identifying the Vulnerability

Application Overview

File storage application. After logging in with htb-stdnt, users can see stored files.

Clicking a file results in request to /get_data.php?id=2, displaying the file.

Testing for First-Order IDOR

Accessing /get_data.php?id=1 (another user's file):

• User is logged out

• Error message displayed: "Something went wrong. You have been logged out for security reasons."

Result: Not vulnerable to classical first-order IDOR. Let's analyze source code.

---

Source Code Analysis

get_data.php

<?php
  session_start();
  require_once ('db.php');
  if(!$_SESSION['user']){
    header("Location: index.php");
    exit;
  }
  $_SESSION['id'] = $_GET['id'];  // ← ID set BEFORE access check!
  if(check_access($_SESSION['id'], $_SESSION['user'])){
    header("Location: display_data.php");
    exit;
  } else {
    header("Location: error.php");
    exit;
  }
?>

display_data.php

<?php
  session_start();
  require_once ('db.php');
  if(!$_SESSION['user']){
    header("Location: index.php");
    exit;
  }
  $user_data = fetch_user_data($_SESSION['user']);
  $data = fetch_data($_SESSION['id']);  // ← Uses session ID
?>
// HTML content displaying the file

error.php

<?php
  session_start();
  session_unset();  // ← Session cleared only HERE
  $_SESSION['msg'] = 'Something went wrong. You have been logged out for security reasons.';
  header("Location: index.php");
  exit;
?>

The Vulnerability

┌─────────────────────────────────────────────────────────────────────────┐
│                        Second-Order IDOR Flow                           │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  1. GET /get_data.php?id=1 (admin's file)                              │
│     └── $_SESSION['id'] = 1  ← ID is SET before access check           │
│     └── check_access() fails → Redirect to error.php                   │
│                                                                         │
│  2. DON'T follow redirect to error.php                                 │
│     └── session_unset() is NEVER called                                │
│     └── $_SESSION['id'] remains set to 1                               │
│                                                                         │
│  3. Navigate directly to /display_data.php                             │
│     └── fetch_data($_SESSION['id']) → fetches file ID 1                │
│     └── Admin's file displayed!                                        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Key insight: Session variable id is set before access check. It's only cleared in error.php. If we don't follow the redirect, the ID remains set!

---

Running the Application Locally

Database Setup (db.sql)

CREATE TABLE `data` (
  `id` int(11) NOT NULL,
  `owner` varchar(256) NOT NULL,
  `data` varchar(10000) NOT NULL,
  `name` varchar(256) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `users` (
  `id` int(11) NOT NULL,
  `username` varchar(256) NOT NULL,
  `description` varchar(256) NOT NULL,
  `password` longtext NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

# htb-stdnt:Academy_student!
INSERT INTO `users` (`id`, `username`, `description`, `password`) VALUES
(2, 'htb-stdnt', 'This is the user for HackTheBox Academy students.', '$2a$12$f4QYLeB2WH/H1GA/v3M0I.MkOqaDAkCj8vK4oHCvI3xxu7jNhjlJ.');

INSERT INTO `data` (`id`, `owner`, `data`, `name`) VALUES
(1, 'admin', "<SNIP>", 'Secret Apple Pie Recipe');

INSERT INTO `data` (`id`, `owner`, `data`, `name`) VALUES
(2, 'htb-stdnt', '<SNIP>', 'Lorem Ipsum');

Start MySQL Container

docker run -p 3306:3306 -e MYSQL_USER='db' -e MYSQL_PASSWORD='db-password' -e MYSQL_DATABASE='db' -e MYSQL_ROOT_PASSWORD='db' --mount type=bind,source="$(pwd)/db.sql",target=/docker-entrypoint-initdb.d/db.sql mysql

Start PHP Server

php -S 127.0.0.1:8000

---

Exploitation

Step 1: Set Session Variable

Request arbitrary file ID (don't follow redirect):

GET /get_data.php?id=1 HTTP/1.1
Host: idor.htb
Cookie: PHPSESSID=your_session_cookie

Response:

HTTP/1.1 302 Found
Location: error.php

Do NOT follow the redirect!

Step 2: Access display_data.php Directly

Navigate to /display_data.php in browser → Admin's file displayed!

This PoC can be scripted to exfiltrate all files on the web application.

---

Patching

Problem: Session variable id is set before access check.

Fix: Only set session variable after access check passes.

Fixed get_data.php

<?php
  session_start();
  require_once ('db.php');
  if(!$_SESSION['user']){
    header("Location: index.php");
    exit;
  }
  if(check_access($_GET['id'], $_SESSION['user'])){
    $_SESSION['id'] = $_GET['id'];  // ← Now set AFTER access check
    header("Location: display_data.php");
    exit;
  } else {
    header("Location: error.php");
    exit;
  }
?>

---

Question Walkthrough

Task: Exploit the second-order IDOR vulnerability to obtain the flag.

Step 1: Download and Analyze Source

wget https://academy.hackthebox.com/storage/modules/231/src_IDOR.zip
unzip src_IDOR.zip

Step 2: Understand the Flow

1. Login with htb-stdnt:Academy_student!

2. View files via /get_data.php?id=X

3. Notice: unauthorized access redirects to error.php

Step 3: Identify Vulnerability

In get_data.php line 10:

• $_SESSION['id'] is set before check_access()

• Session only cleared in error.php

Step 4: Exploit

1. Intercept request to /get_data.php?id=5

2. Don't follow redirect to error.php

3. Navigate directly to /display_data.php

4. Flag displayed!