# Access Control Vulnerabilities

### Lỗi bảo mật mà không cần hiểu code


### IDOR

# LAB

Thử thách về lỗi bảo mật Access Control

Đến với thử thách về lỗi bảo mật Access Control, bạn sẽ tấn công trang Fakebook của Zack Muckerberg với nhiệm vụ đọc private post của user khác bao gồm các mục tiêu:

Mục tiêu level 1: http://fakebok.cyberjutsu-lab.tech:27001/

Mục tiêu level 2: http://fakebok.cyberjutsu-lab.tech:27002/

Mục tiêu level 3: http://fakebok.cyberjutsu-lab.tech:27003/

Mục tiêu level 4: http://fakebok.cyberjutsu-lab.tech:27004/

Ngoài ra, bạn sẽ có nhiệm vụ phụ là tìm chức năng bị lỗi Access Control bao gồm các mục tiêu:

Mục tiêu level 4: http://fakebok.cyberjutsu-lab.tech:27004/

Mục tiêu level 5: http://fakebok.cyberjutsu-lab.tech:27005/

### Level 1 - Untrusted Data của IDOR là mã định danh

- Đây là ứng dụng cho phép đăng post dưới 2 trạng thái: `public và private`.
- Để sử dụng, người dùng cần phải tạo tài khoản và đăng nhập.


- Tại trang chủ /wall.php, người dùng có thể tạo post



– Goal: đọc được post private của user khác

a) Cách hoạt động của ứng dụng
- Kiểm tra Burp Suite để xem các gói tin đã được gửi đi.


- Gói tin 79, 80 là thực hiện việc login

- Gói 84 và 88 với method POST là các gói tin khi mình thử tạo post public và post private.

- Gói tin tạo post public


- Gói tin tạo post private

Có 2 tham số là `content và public`.

- Tham số content chứa nội dung của post.
- Tham số public có giá trị là 1 với post dạng public và có giá trị là 0 với post dạng private

- Một điểm đáng lưu ý, sau khi tạo post thành công, mỗi lần request về lại `/wall.php`, server sẽ thực hiện gửi request đến
`/post.php?action=list_posts` và `?action=read` để hiển thị các post đã tạo lên trang của người dùng.


- Tại file `post.php` có thể thấy `action read` thực hiện truy vấn đến database để lấy content của post dựa trên `post_id`. Mà` post_id `lại được lấy từ untrusted data là `$_GET[‘id’]` mà không có bất kì lớp validate nào.


b) Ý tưởng / Giả thuyết

- Hai post đã tạo có id là 9 và 10. Có vẻ server sẽ tạo id cho post bằng cách tăng tuyến tính, vậy nó có thể chỉ là những con số.

- Liệu có thể thay đổi id để đọc nội dung của những bài post khác không?

c) Khai thác

- Thử request để đọc post có id là 0 thì “Not Found”.

- Thử tăng id lên 1 thì thấy ta đã đọc được một post của user khác với `author_id` là 1. Nhưng đây là post public thôi vì giá trị public là 1.


- Tiếp tục tăng id lên và đọc được Flag


### Level 2 Tìm hiểu quy tắc của mã định danh (base64)

- Goal: đọc được post private của user khác

a) Cách hoạt động của ứng dụng
- Ở level này, có vẻ anh dev đã biết việc tạo id là số tự nhiên tăng tuyến tính rất nguy hiểm và dễ dàng bị đoán được. Do đó ảnh đã tạo id theo một quy tắc gì đó.

- Tuy nhiên, nếu đoán được quy tắc này, rất có thể ta vẫn tấn công được như level trước.



- Nếu chỉ quan sát một id, thì khó để tìm ra quy tắc. Khi quan sát nhiều id, không khó để nhận ra những id này ở dạng base64 encode.

- Kiểm chứng: thực hiện decode base64 id của 2 post đã tạo và nhận được giá trị là` 000004 và 000005`.


Vậy ở level này, thay vì để id ở dạng số, anh dev đã encode base64 để tăng độ khó đoán, nhưng không fix vào bản chất vấn đề.

`b) Ý tưởng / Giả thuyết `

- Có thể id ở level này vẫn được tạo tuyến tính và sau đó được base64 encode.

- Nếu vậy chỉ cần thử những số khác cùng định dạng và encode nó thì sẽ có thể đọc được nội dung post khác đúng không?

`c) Khai thác `

- Thử các id khác như 000003 dưới dạng base46 là `MDAwMDAz` và đọc được post private của crush <3



Mã nguồn


### Level 3 - Mã định danh bất quy tắc, phải đi tìm chỗ leak

Admin user_id=1 bạn không có quyền xem


Crush user_id = 2 bạn không có quyền xem

– Goal: đọc được post private của user khác

`a) Cách hoạt động của ứng dụng `

- Ở level này, chúng ta có thể truy cập đến trang cá nhân của user đang online là `admin và crush`. Tuy nhiên ta chỉ có thể xem những post public của các user đó

- Admin với user_id=1


- Crush với user_id=2

- Tuy nhiên ở level này, id của post là một dãy random hoàn toàn.



`b) Ý tưởng / Giả thuyết `

- Với dãy ký tự random, việc đoán hay bruteforce rất khó hay thậm chí dường như là không thể.

- Nhưng ta vẫn cần giá trị id để đọc được nội dung của post.

- Liệu có gói tin nào gửi giá trị `post_id `đến server để server có thể truy xuất content của post từ database không ta?

`c) Kiểm chứng giả thiết và khai thác `

- Server vẫn xử lý việc hiển thị `content post` lên trang cá nhân như ở level trước.


- Request` /post.php?action=list_posts` sẽ lấy ra giá trị post_id và public.


- Quan sát gói tin, có thể thấy nó lấy tất cả các `post_id` của user đó, kể cả những `post private`.



Ta thấy mã nguồn còn không lọc $GET['id'] không có cơ chế xác thực nên ta hoàn toàn có thể lấy lấy 1 post_id điền vào .

Vậy là mình có thể biết được post_id của crush rồi. Đọc post bí mật thôi!


<?php
include('libs/auth.php');
include('libs/db.php');

header('Content-Type: application/json');

$user_id = $_SESSION['user_id'];
if (isset($_GET['user_id']))
    $user_id = $_GET['user_id'];

if (!isset($_GET['action']))
    die(json_encode("Error"));

switch ($_GET['action']) {
    case 'list_posts':
        $res = select_all(
            'SELECT post_id, public FROM posts WHERE author_id = ?',
            $user_id
        );
        echo json_encode($res);
        break;
    case 'read':
        $post = select_one(
            'SELECT content, public, author_id FROM posts
            WHERE post_id = ? AND (public = 1 OR author_id = ?)',
            $_GET['id'],
            $user_id
        );
        if ($post)
            echo json_encode($post);
        else
            echo json_encode("Not Found");
        break;
    case 'create':
        $res = exec_query(
            'INSERT INTO posts (post_id, content, public, author_id) VALUES (?, ?, ?, ?);',
            generate_id(),
            $_POST['content'],
            $_POST['public'],
            $user_id
        );
        header('Refresh:2; url=wall.php'); // Redirect về wall.php sau 2s
        echo json_encode('Post created');
        break;
}
#mã nguồn trang post.php

### Level 4.1

a) Cách hoạt động của ứng dụng

- Ở level này, chúng ta vẫn có thể thấy được post_id thông qua `?action=list+posts`.


- Tuy nhiên, khi request đến post private bằng post_id thì không thể đọc được nội dung. Dù post này có tồn tại trong database.

- Có thể anh dev đã rút kinh nghiệm và sửa ở đâu đó. Đọc mã nguồn để xem anh dev đã sửa như thế nào.


- Câu truy vấn để đọc content bài post lúc này ngoài xét giá trị post_id được lấy từ `$_GET[‘id’]`, cần thỏa thêm một trong 2 điều kiện:

o Đây là post public (public = 1)
o Hoặc người gửi request đọc post phải là chủ bài post (user_id = author_id).

- Do đó ta không thể đọc private post của user admin (user_id = 1) được nữa.

`b) Ý tưởng/ Giả thiết`

- Ở những level trước, chúng ta đã control được giá trị id.

- Nhưng ở level này, cần kiểm soát được 1 trong 2 điều kiện nói trên nữa mới có thể exploit được.

- Trong đó, giá trị public được khởi tạo lúc user chọn loại của bài post, ta không thể tác động được.

- Vậy chỉ còn cách khiến server nghĩ rằng mình là owner của bài post. Truy ngược lại mã nguồn, giá trị biến $user_id được gán ở dòng 7-9.


- Ngay dòng số 9, biến `$user_id` được gán từ tham số `user_id` trên URL, đây cũng chính là untrusted data.

- Quan sát lại các gói tin được gửi đi, ta thấy tham số user_id được truyền vào ở `?action=list_posts`.


- Vậy sẽ ra sao nếu mình cũng truyền tham số này vào `?action=read? `

`c) Khai thác `

Thử thêm tham số `user_id = 1` và đã đọc post private của admin.


Server đã xử lý bằng giá trị `user_id` cho mình truyền vào. Vậy đây là một `param ẩn`.

- Tiếp tục thay giá trị `id và user_id` để đọc content post private của crush.


Phải điền đúng post_id=id nó chính là id bài đăng của crush và user_id=2 nó chính của crush như đề bài đã tiết lộ

### Level 4.2 Truy tìm các chức năng bị lỗi Access Control

`a) Ý tưởng / Giả thuyết: `

- Ở chức năng tạo post của trang web cũng lấy giá trị `$user_id`


- Mà ở level 4.1 ta đã khám phá ra server có thể nhận giá trị cho `$user_id` từ param ẩn mà mình truyền vào thông qua `$_GET[’user_id’]`.

- Vậy nếu ta tạo một post public với user_id của user khác thì có thể tạo được post dưới danh nghĩa của người đó không?

`b) Kiểm chứng ý tưởng / giả thuyết: `

Tại `/post.php?action=create` thêm tham số `user_id` để thử tạo bài post public trên trang của crush.


- Tại trang của crush (user_id = 2) đã hiển thị post do mình tạo.


### Level 5 Truy tìm các chức năng bị lỗi Access Control

`a) Cách hoạt động của ứng dụng:`

- Level này xuất hiện 1 phần mới là` System notifications`. Có thể đây là nơi hiển thị thông báo từ hệ thống.


- Kiểm tra các gói tin đã được gửi đi khi truy cập trang web, ta thấy có sự khác biệt so với những level trước.


- Các ứng dụng thường được thiết kế theo một khuôn mẫu (design pattern), giúp cho việc lập trình & phát triển ứng dụng trở nên dễ dàng hơn. Có rất nhiều design pattern, như: Model-View-Controller, Single Page Application, Factory, …

Trong phần này, ta sẽ tìm hiểu Single Page Application design pattern:

- Design pattern này phát triển là nhờ vào sự phát triển của các ngôn ngữ client-side: HTML, JavaScript, …

- Khác với các design cũ. Đầu tiên, server sẽ gửi hết các file JS và HTML về, đủ để phía client xử lý giao diện.

- Từ đó ở những request sau, ở mỗi response server không cần gửi lại cả phần front end mà chỉ cần tập trung xử lý back end.

- Các file JS này thường bao gồm thông tin các API, endpoints để server trả giá trị về.

`b) Ý tưởng/ Giả thiết`

- Các file javascript, nếu không được quản lý tốt, rất có thể để lộ những API hay endpoint nguy hiểm.

- Liệu ta có còn những endpoint nào khác mà ta không biết?

`c) Kiểm chứng và khai thác `

- Thử kiểm tra các file js thì thấy tại file `/static/js/app.js `đang chứa các API của các tính năng trong trang web.


- Trong đó có `function push_noti()` tại `/system_cotification.php` Thử truy cập endpoint này thì thấy đây là chức năng đăng thông báo của admin.


- Vậy là mình đã access được vào chức năng thuộc quyền của admin mà không cần bất kỳ xác thực nào. Đây chính là lỗi `Broken Access Control`.

- Có thể anh developer nghĩ người dùng bình thường không thể biết được endpoint này.

- Thử đăng thông báo “Go to sleep!”


- Khi quay trở lại trang chủ, thông báo do mình gửi đã hiển thị tại phần `System notifications`.


- Trang cá nhân của hacker

Và thông báo này cũng được gửi đến những user khác.


Trang cá nhân của admin

Do đó, lỗi này cho phép hacker access vào tính năng của admin và gửi bất kì nội dung gì đến tất cả user một cách dễ dàng.