# Bài tập 1:

## Tiêu đề: A06:2021 – Vulnerable and Outdated Components

## Mô tả lỗ hổng:
Lỗ hổng Vulnerable and Outdated Components

### Tóm tắt:
Server sử dụng phần mềm hoặc thư viện đã lỗi thời -> dính bug

## Các bước để thực hiện lại và bằng chứng:
B1: Ta thấy lab cho ta một webpage CSE bookstore sử dụng PHP.

B2: Sử dụng [exploit-db](https://www.exploit-db.com/) để tìm kiếm thông tin về exploit của book store

B3: Ta sử dụng exploit đã có sẵn và RCE thành công trang web

-> Đáp án

## Mức độ ảnh hưởng của lỗ hổng
Khi các thành phần của ứng dụng (thư viện, framework, module, hay plugin) lỗi thời hoặc có lỗ hổng bảo mật, kẻ tấn công có thể khai thác các lỗ hổng đã được công bố để thực hiện nhiều cuộc tấn công khác nhau như thực thi mã từ xa, DoS, đánh cắp thông tin nhạy cảm, leo thang đặc quyền, hoặc xâm nhập hệ thống.

## Đề xuất khắc phục
Cập nhật và vá lỗi các thành phần của ứng dụng thường xuyên, đảm bảo rằng hệ thống sử dụng các phiên bản mới nhất của các thành phần (thư viện, framework, plugin) đã được kiểm tra bảo mật.

Sử dụng các công cụ tự động để quản lý các thành phần bên ngoài và theo dõi các lỗ hổng bảo mật liên quan (Snyk, Dependabot).

Loại bỏ các thành phần không cần thiết hoặc không còn được hỗ trợ.

Kiểm thử bảo mật để phát hiện sớm các vấn đề bảo mật, đảm bảo quá trình tích hợp có bao gồm kiểm tra lỗ hổng.

# Bài tập 2:

## Tiêu đề: A07:2021 – Identification and Authentication Failures

## Mô tả lỗ hổng:
Lỗ hổng Identification and Authentication Failures

### Tóm tắt:
Server kiểm tra tính xác thực của dữ liệu yếu / không kiểm tra -> attacker có thể bypass việc xác thực đó

## Các bước để thực hiện lại và bằng chứng:
B1: Khi thực hiện việc reset password với userXYZ ta quan sát thấy server phản hồi cho ta một url có vẻ dùng như dùng để reset password kèm với một chuỗi hex khả nghi.

B2: Ta đoán rằng chuỗi hex đó có thể là hash của 1 thông tin nào đó của người dùng nên ta xài tool để reverse cũng như đoán mã hash đó.
-> Như vậy, ta đã biết rằng chuỗi hex chính là SHA1 của username đang cần reset

B3: Dựa trên việc được cung cấp url để reset password cũng như là username của người dùng cần reset. Ta có thể tự tính SHA1 của userABC và reset password của user đó. Sau đó ta login vào userABC

## Mức độ ảnh hưởng của lỗ hổng
Cho phép kẻ tấn công khai thác các điểm yếu trong quá trình xác thực và định danh, có thể dẫn đến việc kẻ tấn công giả mạo danh tính hợp pháp. Gây ra các cuộc tấn công leo thang đặc quyền, truy cập vào các thông tin nhạy cảm hoặc tài nguyên bị hạn chế, làm mất tính bảo mật, tính toàn vẹn và tính khả dụng của hệ thống.

Các hậu quả tiềm ẩn bao gồm chiếm đoạt tài khoản người dùng, truy cập dữ liệu trái phép, thay đổi cấu hình hệ thống hoặc tấn công các dịch vụ dựa trên web.

## Đề xuất khắc phục:
- Khi yêu cầu reset password của một người dùng, ta yêu cầu người dùng phải nhập password cũ. Hoặc nếu người dùng không nhớ password cũ, ta cần kiểm soát tính xác thực của dữ liệu trả ra cũng như xác thực người dùng đó có hợp lệ hay không. Ví dụ, khi trả về mã hash liên quan đến tên người dùng, ta nên kẹp thêm hệ số gây nhiễu noise vào để attacker khó có thể reverse được chuỗi hash đã cho a.k.a trả giá trị sha1(random + username).

# Bài tập 3:

## Tiêu đề: A08:2021 – Software and Data Integrity Failures

## Mô tả lỗ hổng:
Tấn công Cross-Site Scripting (XSS) trên một trang web và thay đổi nội dung của liên kết tải xuống tệp.

### Tóm tắt:
Điều này thường xảy ra khi sử dụng phần mềm từ các nguồn hoặc kho lưu trữ không đáng tin cậy, hoặc khi phần mềm bị can thiệp tại các giai đoạn như nguồn gốc, quá trình truyền tải, thậm chí là trong bộ đệm của thiết bị đầu cuối.

Về kịch bản, đây là 1 trang web có chức năng hiển thị trang tải xuống tài liệu cho người dùng. Kẻ tấn công có thể lợi dụng việc không bảo vệ tính toàn vẹn của phần mềm, dẫn đến việc thay đổi nội dung của tệp tải xuống hoặc thay thế bằng tệp độc hại. Hắn sẽ dùng kỹ thuật XSS để thay đổi nội dung của đường dẫn tải tệp và từ đó có thể sử dụng các chiến thuật lừa đảo để dụ người dùng tải về tệp độc hại.

Để ngăn người dùng vô tình sử dụng tệp độc hại, nên so sánh giá trị hash của tệp sau khi tải xuống trước khi sử
dụng.

## Các bước để thực hiện lại và bằng chứng:
- **Bước 1: Thiết kế và kiểm tra file download.php**

<?php
if(isset($_GET['username']) && !empty($_GET['username'])){
  $username = $_GET['username'];
} else {
  header('Location: index.html');
  exit;
}
?>
...
    </style>
    <div class="container">
      <h1>Welcome <?php echo $username;?></h1>
      <p>Thank you for choosing to download our file. To download it, please click the button below.</p>
      <a href="real.exe" class="button">Download File</a>
    </div>
  </body>
</html>

Ta có thể thấy, như bình thường thì khi nhấn vào nút, ta sẽ tải về 1 file tên là `real.exe`

Bắt đầu phân tích, biến ``$_GET['username']`` được sử dụng trực tiếp trong mã HTML mà không có bất kỳ biện pháp sanitize hay escape nào. Điều này có nghĩa là nếu kẻ tấn công có thể chèn mã JavaScript vào giá trị username, mã đó sẽ được thực thi khi người dùng tải trang Ví dụ, khi giá trị username là ``Stranger<script>...</script>``, đoạn mã JavaScript được nhúng vào trang HTML mà không có bất kỳ kiểm tra nào, dẫn đến khả năng thực thi mã độc.

- **Bước 2: Phân tích & tạo payload**
Khi load bài lab từ docker, ta có thể thấy payload (đã decode URL) của attacker như sau:

https://localhost/bugs/15fileIntegrity_Integrity/download.php?username=Stranger<script>window.addEventListener('load', function(){document.getElementsByTagName('a')[0].setAttribute('href','./real.exe');});</script>

Ở giá trị `username`: `username=Stranger<script>...</script>` Kẻ tấn công đã tiêm trực tiếp mã JavaScript vào giá trị của tham số `username`. Vì giá trị này được in ra trực tiếp trong trang web mà không được xử lý đúng cách, mã JavaScript sẽ được nhúng và thực thi trên trang web.

Mã độc trong script: `window.addEventListener('load', function(){document.getElementsByTagName('a')[0].setAttribute('href','./fake.exe');});`

Đoạn mã này sử dụng sự kiện load của trang để đợi trang tải xong và sau đó tìm thẻ <a> đầu tiên trên trang (chính là nút tải tệp), rồi thay đổi thuộc tính href của liên kết từ `real.exe` thành `fake.exe`.

- **Bước 3: Khái quát qua flow hoạt động**
Khi người dùng truy cập vào URL mà kẻ tấn công gửi, quá trình sẽ diễn ra như sau:

Trang download.php được tải: Khi người dùng mở trang download.php, trang sẽ hiển thị nội dung chào mừng với tên người dùng và nút tải xuống file real.exe.

Mã JavaScript của kẻ tấn công được thực thi: Vì giá trị của tham số username chứa mã JavaScript độc, đoạn mã này sẽ được thực thi khi trang được tải.

Thay đổi liên kết tải xuống: Khi mã JavaScript thực thi, nó sẽ tìm thẻ <a> đầu tiên (liên kết tải tệp) và thay đổi giá trị của thuộc tính href thành fake.exe. Do đó, khi người dùng nhấn vào nút "Download File", thay vì tải real.exe, họ sẽ tải về tệp fake.exe mà kẻ tấn công đã chuẩn bị.


## Tài liệu hỗ trợ và tham khảo
- ChatGPT
- https://github.com/Hrishikesh7665/OWASP21-PG/

## Mức độ ảnh hưởng của lỗ hổng
Phần mềm không bảo đảm được tính toàn vẹn của dữ liệu hoặc mã nguồn, có thể dẫn đến việc kẻ tấn công thay đổi, sửa đổi phần mềm hoặc dữ liệu một cách trái phép. Điều này có thể gây ra các cuộc tấn công như chèn mã độc, phá vỡ tính toàn vẹn của dữ liệu, hoặc làm thay đổi hành vi của phần mềm, gây ra các tác động bảo mật nghiêm trọng như đánh cắp thông tin, thực hiện mã độc từ xa, hoặc thay đổi chức năng hệ thống.

Các tác động cụ thể bao gồm phá vỡ chuỗi cung ứng phần mềm, dẫn đến cài đặt mã độc qua các bản cập nhật phần mềm không an toàn, và tấn công vào các hệ thống tự động triển khai, dẫn đến hậu quả nghiêm trọng cho toàn bộ cơ sở hạ tầng.

## Đề xuất khắc phục
Sử dụng các cơ chế xác thực mạnh và kiểm tra tính toàn vẹn của các thành phần phần mềm, bao gồm chữ ký số và mã hóa để đảm bảo các bản cập nhật, thư viện bên ngoài, hoặc các tệp cấu hình không bị sửa đổi.

Đảm bảo tính toàn vẹn của các hệ thống CI/CD, bao gồm việc kiểm tra mã nguồn và thực hiện các quá trình xác thực bảo mật trước khi triển khai phần mềm.

Hạn chế sử dụng các thư viện bên ngoài từ nguồn không đáng tin cậy và áp dụng kiểm thử để phát hiện sớm mã độc hoặc các thành phần không an toàn trong phần mềm.

Thiết lập cơ chế giám sát để phát hiện và phản ứng nhanh với các thay đổi bất thường trong hệ thống hoặc dữ liệu.

# Bài tập 4:

## Tiêu đề: A09:2021 – Security Logging and Monitoring Failures

## Mô tả lỗ hổng:
Kẻ tấn công đánh vào việc ghi nhật ký không đúng cách dẫn đến việc rò rỉ thông tin nhạy cảm.

### Tóm tắt và Các bước thực hiện
Điều này thường xảy ra khi việc không ghi nhật ký, giám sát hoặc báo cáo đầy đủ các sự kiện bảo mật (chẳng hạn như những lần thử đăng nhập không thành công hoặc đáng ngờ) hay ghi nhật ký một cách không đúng có thể dẫn đến việc khó phát hiện hành vi tấn công. Điều này làm tăng đáng kể khả năng kẻ tấn công có thể khai thác thành công các lỗ hổng của ứng dụng mà không bị phát hiện.

Kịch bản tấn công lần này sẽ là ta có một form để đăng nhập và mục tiêu của chúng ta là đăng nhập thành công. Ngoài ra chúng ta cũng có được gợi ý là hãy truy cập phần logging của web.

- **Bước 1: Kiểm tra phần logging**

Ta có thể truy cập được phần log của trang web qua đường dẫn `./debugging/logs/requests.log` và lướt xuống 1 chút ta sẽ có được credential đúng để đăng nhập:

Credential đó là `email=[e-mail]`và
`pass=MySuperSecretPassword#2021` nhưng trong phần hình ảnh thì @ và # đã bị encode URL nên thành các kí tự có % đứng đầu. Ta biết được đây là credential đúng vì ở cuối có chuỗi `Login Successful`. Sử dụng chuỗi này để đăng nhập thì ta thành công như dưới:


## Tài liệu hỗ trợ và tham khảo:
- ChatGPT
- https://github.com/Hrishikesh7665/OWASP21-PG

## Mức độ ảnh hưởng của lỗ hổng
Hệ thống không ghi nhận đủ các hoạt động quan trọng hoặc không giám sát hiệu quả, khiến việc phát hiện các cuộc tấn công hoặc hoạt động bất thường trở nên khó khăn hoặc không thể thực hiện kịp thời. Kẻ tấn công có thể khai thác lỗ hổng này để tiến hành các hành vi xâm nhập, khai thác lỗ hổng, và gây thiệt hại trong một khoảng thời gian dài trước khi bị phát hiện.

Không có cơ chế logging và monitoring tốt sẽ dẫn đến việc không thể phát hiện sớm các cuộc tấn công, chẳng hạn như tấn công brute force, xâm nhập trái phép, hoặc thay đổi không mong muốn đối với dữ liệu hoặc hệ thống. Điều này có thể dẫn đến việc thất thoát dữ liệu, leo thang đặc quyền, hoặc gây mất tính khả dụng của hệ thống mà không thể phát hiện và phản ứng nhanh chóng.

## Đề xuất khắc phục
Thiết lập cơ chế ghi log toàn diện cho các sự kiện bảo mật quan trọng như đăng nhập thất bại, thay đổi quyền hạn, truy cập dữ liệu nhạy cảm và các sự kiện không hợp lệ hoặc bất thường trong hệ thống.

Đảm bảo rằng các log bảo mật được lưu trữ một cách an toàn, có thể truy xuất và không bị xóa hoặc chỉnh sửa dễ dàng. Sử dụng các công cụ quản lý và lưu trữ log tập trung để theo dõi và phân tích.

Cấu hình giám sát liên tục các sự kiện và kích hoạt cảnh báo khi phát hiện các hoạt động nghi ngờ hoặc nguy hiểm. Các hệ thống như SIEM có thể giúp tự động phát hiện và cảnh báo các sự cố bảo mật.

Thực hiện các cuộc kiểm tra log định kỳ để đảm bảo tính chính xác, đầy đủ và khả năng phát hiện sớm các sự kiện bất thường.

Phát triển và thực hiện các quy trình phản ứng nhanh với các sự cố bảo mật, nhằm kịp thời ứng phó và giảm thiểu thiệt hại trong trường hợp bị tấn công.

# Bài tập 5:

## Tiêu đề: A10:2021 – SSRF Level 1

## Mô tả lỗ hổng:
Hệ thống xác thực quyền hạn không đủ tốt dẫn đến hacker có thể vào chỉnh sửa url trong page source để tải internal file mong muốn như urls.py, .env,...

### Tóm tắt và Các bước thực hiện
Lỗ hổng SSRF (Server-Side Request Forgery) xảy ra khi một ứng dụng web cho phép người dùng cung cấp một URL từ xa mà không thực hiện xác thực hoặc kiểm tra đầy đủ. Lỗ hổng này cho phép kẻ tấn công ép buộc ứng dụng gửi yêu cầu đến một đích khác mà không được mong muốn, từ đó có thể khai thác các tài nguyên bên trong hoặc bên ngoài hệ thống.

Trong kịch bản này, ta được cung cấp một trang web đơn giản cho phép người dùng xem các bài blog, nhưng chức năng tải dữ liệu của nó có lỗ hổng SSRF.

- **Bước 1: Khái quát qua giao diện**
Giao diện web bình thường, khi muốn tải cái gì thì ta sẽ ấn vào:


Ta thử ấn vào 1 ảnh thì sẽ tải được file như dưới:


Mọi thứ dường như rất bình thường, giờ ta sẽ đến với bước tiếp theo là khám phá sâu hơn gói request của nó

- **Bước 2: Phân tích gói tin và chỉnh sửa để tấn công**
Sử dụng tính năng `Intercept`, ta bắt được gói tin như sau:

Ta thấy rằng trong gói tin POST gửi lên server để tải về, ta có thể can thiệp trực tiếp vào biến `file` ở hàng 22 -> SSRF. Thử sửa đường dẫn thành `FileDownloader.php` và xem file:


Ta có thể thấy file có vẻ bị hư và không xem được, thử cat file thì:


Vậy là đã rõ, khi đổi đường dẫn thì dẫn tới rằng file của chúng ta tải về đã bị thay đổi, dẫn đến khác với nội dung mong muốn ban đầu.

## Tài liệu hỗ trợ và tham khảo:
- ChatGPT
- https://github.com/Hrishikesh7665/OWASP21-PG

## Mức độ ảnh hưởng của lỗ hổng
Kẻ tấn công có thể thực hiện các yêu cầu tới các dịch vụ nội bộ của máy chủ, chẳng hạn như API nội bộ, cơ sở dữ liệu hoặc các hệ thống khác mà từ bên ngoài không thể truy cập trực tiếp. Điều này có thể dẫn đến việc đánh cắp thông tin, thực thi mã từ xa, xâm nhập vào các dịch vụ nội bộ hoặc phá hoại cơ sở hạ tầng.

SSRF có thể dẫn đến:
Truy cập trái phép đến các tài nguyên nội bộ không được công khai.
Đọc hoặc ghi dữ liệu nhạy cảm từ các dịch vụ nội bộ.
Tấn công leo thang đặc quyền và chiếm quyền kiểm soát các thành phần khác của hệ thống.
Thực hiện các cuộc tấn công từ chối dịch vụ (DoS) nhắm đến các dịch vụ nội bộ.

## Đề xuất khắc phục
Hạn chế quyền truy cập: Giới hạn khả năng thực hiện yêu cầu HTTP từ máy chủ tới các địa chỉ IP và mạng không đáng tin cậy, chẳng hạn như các dịch vụ nội bộ. Chỉ cho phép các địa chỉ IP cụ thể được phép thực hiện các yêu cầu đến tài nguyên nội bộ.

Đảm bảo rằng tất cả các đầu vào do người dùng cung cấp liên quan đến URL hoặc địa chỉ không được sử dụng trực tiếp để tạo ra các yêu cầu mạng mà không qua kiểm tra và xác thực.

Sử dụng blacklist và whitelist: Áp dụng danh sách trắng để chỉ cho phép các địa chỉ IP, miền, và giao thức tin cậy được phép yêu cầu. Đồng thời, sử dụng danh sách chặn để ngăn chặn các yêu cầu tới các dịch vụ nội bộ hoặc mạng cục bộ.

Vô hiệu hóa hoặc hạn chế giao thức nguy hiểm: Nếu không cần thiết, vô hiệu hóa các giao thức nguy hiểm như file://, ftp://, hoặc gopher:// có thể dẫn đến khai thác SSRF.

Sử dụng proxy để kiểm tra và kiểm soát tất cả các yêu cầu gửi từ máy chủ tới các dịch vụ khác, nhằm ngăn chặn các yêu cầu độc hại hoặc bất thường.

Ghi log đầy đủ cho các yêu cầu gửi từ máy chủ, và triển khai cơ chế giám sát để phát hiện các yêu cầu bất thường hoặc có khả năng độc hại.

# 11phpRCE_vulnerableComponent

## Tiêu đề: Vulnerable & Outdated Component

## Mô tả
Lỗ hổng này xảy ra là do tồn tại thành phần phần mềm là một phần của hệ thống, các hàm nguy hiểm, không ổn định hoặc ứng dụng giúp mở rộng chức năng, chẳng hạn như mô-đun, gói phần mềm hoặc API.

Các lỗ hổng dựa trên thành phần xảy ra khi một thành phần không được hỗ trợ, đã lỗi thời hoặc có lỗ hổng bảo mật mà kẻ tấn công đã biết và có thể khai thác. Khi sử dụng các thành phần như vậy, hệ thống hoặc ứng dụng có nguy cơ bị tấn công thông qua những lỗ hổng này.

Để phòng tránh, cần đảm bảo rằng tất cả các thành phần được cập nhật thường xuyên, ngừng sử dụng các thành phần không còn được hỗ trợ, và kiểm tra kỹ lưỡng trước khi tích hợp chúng vào hệ thống.

### Tóm tắt và Các bước thực hiện
Kịch bản ở đây cho chúng ta một trang web CMS nơi ta có thể chỉnh sửa và lưu tệp vào máy chủ. Máy chủ sử dụng hàm PHP eval() dễ bị tấn công để lưu tệp vào máy chủ. Từ đó dựa vào tên bài thực hành, ta có thể up những đoạn code php để tiến hành RCE vào máy chủ, gây rò rỉ những thông tin quan trọng

- **Bước 1: Kiểm tra giao diện và nộp thử vài trường hợp**
Ta thử ghi vài kí tự rồi submit lên, web cho thấy file đã được lưu thành công lên server:

Không có gì lạ xảy ra, ta cùng tiến tới bước 2.
- **Bước 2: Xem xét gói tin và tiến hành phân tích rồi tấn công**
Gói tin khi ta POST lên trang web tuy dài nhưng ta sẽ tập trung vô một phần như sau:

{
"filename":"a.php",
"htmlcontent":"aa"
}    

Cụ thể, `filename` cho biết tệp này có tên là "a.php". Việc tệp có phần mở rộng .php có nghĩa là đây có thể là một tệp mã nguồn PHP, và nếu được thực thi, nó có thể chứa mã lệnh PHP có thể ảnh hưởng đến hệ thống.

`htmlcontent: "aa"` lànội dung HTML mà người dùng gửi cùng với yêu cầu POST. Trong trường hợp này, nội dung chỉ là "aa", nhưng trường này thường chứa các đoạn mã HTML hoặc nội dung khác mà người dùng muốn đưa vào tệp a.php.

Từ đây ta có thể thấy, ta có thể RCE được vì trang web không hề thực hiện bất kì phương pháp nào để sanitize trường này, do đó ta thử đổi thành `"htmlcontent":"<?php system($_GET['cmd']);?>"` và thêm biến cmd như sau:


## Tài liệu hỗ trợ và tham khảo:
- ChatGPT
- https://github.com/Hrishikesh7665/OWASP21-PG

## Mức độ ảnh hưởng của lỗ hổng
Kẻ tấn công thực thi mã tùy ý từ xa trên máy chủ mà không cần có quyền truy cập trực tiếp. Trong trường hợp này, lỗ hổng có thể xuất phát từ một thành phần PHP dễ bị tấn công. Kẻ tấn công có thể lợi dụng lỗ hổng này để:
Chiếm quyền kiểm soát hoàn toàn máy chủ hoặc hệ thống bị ảnh hưởng.
Thực hiện các hành vi độc hại như đánh cắp dữ liệu, phá hoại hoặc thay đổi nội dung, hoặc mở cửa hậu (backdoor) để tấn công lâu dài.
Tấn công các hệ thống khác trong cùng một mạng hoặc triển khai phần mềm độc hại để xâm nhập thêm vào cơ sở hạ tầng.

Hậu quả của việc khai thác thành công RCE rất nghiêm trọng, vì nó có thể dẫn đến mất mát hoàn toàn dữ liệu, chiếm đoạt máy chủ và gây thiệt hại về tài chính, uy tín hoặc cả hai cho tổ chức.

## Đề xuất khắc phục
Cập nhật các thành phần PHP, framework, hoặc plugin dễ bị tấn công lên phiên bản mới nhất ngay khi có bản vá bảo mật. Đảm bảo rằng tất cả các thành phần bên thứ ba được kiểm tra và vá lỗ hổng bảo mật kịp thời.

Kiểm tra đầu vào nghiêm ngặt để đảm bảo rằng không có mã độc hại hoặc yêu cầu không mong muốn nào có thể thực thi trên máy chủ.

Sử dụng tường lửa ứng dụng web (WAF) để phát hiện và ngăn chặn các yêu cầu có khả năng khai thác lỗ hổng RCE.

Ứng dụng và máy chủ chỉ hoạt động với quyền hạn tối thiểu cần thiết. Điều này giúp giảm thiểu khả năng kẻ tấn công khai thác RCE để leo thang đặc quyền hoặc phá hoại hệ thống.

Nếu không cần thiết, vô hiệu hóa các tính năng PHP có thể dẫn đến RCE, chẳng hạn như eval(), exec(), shell_exec(), và các hàm tương tự có thể bị lạm dụng để thực thi mã độc.

# 14JWT_auth
## Tiêu đề: A07:2021- Indentification and Authentication Failures

## Mô tả
Lỗi nhận dạng và xác thực có thể xảy ra khi các chức năng liên quan đến danh tính, xác thực hoặc quản lý phiên của người dùng không được triển khai đúng cách hoặc không được bảo vệ đầy đủ. Kẻ tấn công có thể khai thác các lỗ hổng này bằng cách xâm phạm mật khẩu, khóa, mã thông báo phiên, hoặc khai thác các lỗi trong quá trình triển khai để giả mạo danh tính của người dùng khác, dù là tạm thời hay vĩnh viễn.

Điều này có nghĩa là nếu quy trình xác thực không an toàn, kẻ xấu có thể truy cập vào tài khoản của người khác và thực hiện hành vi trái phép như đánh cắp dữ liệu hoặc thao túng hệ thống. Để ngăn chặn, cần triển khai các biện pháp bảo mật như xác thực đa yếu tố, mã hóa thông tin nhạy cảm, và kiểm tra lỗi kỹ càng trong các chức năng quản lý phiên và xác thực người dùng.

### Tóm tắt và Các bước thực hiện
Trang web cho phép chúng ta đăng nhập vào với tài khoản đã được để ở phần gợi ý rồi sau đó xác thực bằng 1 mã otp được gửi về, mục tiêu sẽ là đăng nhập vào 1 tài khoản khác nhưng cùng 1 mã otp đã cho. Điều này có thể đạt được vì người lập trình đã sơ sẩy khi kiểm tra otp mà không kiểm tra rằng otp đó đúng với người dùng nào.

- **Bước 1: Kiểm tra giao diện**


Trang web chỉ gồm 2 ô đơn giản như này, để ta tiến hành đăng nhập và nhận OTP được gửi đến ở phần `Console`:

Sau khi nhập OTP, ta được xác thực:

- **Bước 2: Tiến hành tấn công**
Vậy bây giờ, để vào được với user khác thì ta dùng Burpsuite và bật `Intercept` để xem thông tin gói tin request:


Khi này ta thấy được, server cấp cho chúng ta một JWT, ta hãy cùng decode để xem nội dung:


Ta thấy ngoài các thông tin như tài khoản, thuật toán mã hóa,... thì ở phần `Verify Signature`, nó còn yêu cầu 1 phần secret. Nếu ta không điền vào cái phần này thì khi thay thế JWT giả mạo, hệ thống sẽ phát hiện ra.


Do đó, ta tiến hành đọc source code ở `otp.php` thì nhận ra secret là `testJWT`, điền vào ở phần secret, rồi sử dụng JWT mới này để đăng nhập thì ta thành công:


## Tài liệu hỗ trợ và tham khảo:
- ChatGPT
- https://github.com/Hrishikesh7665/OWASP21-PG

## Mức độ ảnh hưởng của lỗ hổng
Khi quá trình xác thực JWT có lỗ hổng, kẻ tấn công có thể khai thác các điểm yếu để đánh cắp hoặc giả mạo token, từ đó chiếm quyền truy cập vào tài nguyên hoặc dịch vụ mà không cần thông tin xác thực hợp lệ.

Các hậu quả bảo mật bao gồm: đánh cắp danh tính, chiếm quyền kiểm soát tài khoản, truy cập trái phép vào dữ liệu hoặc dịch vụ, hoặc leo thang đặc quyền.

## Đề xuất khắc phục
Đảm bảo mọi JWT đều được xác thực chữ ký chính xác trước khi được tin tưởng và sử dụng. Sử dụng các thuật toán an toàn như HS256, RS256 thay vì none.

Đảm bảo JWT được ký và mã hóa bằng các thuật toán mã hóa mạnh và không dễ bị tấn công. Với các thông tin nhạy cảm sử dụng JWE để mã hóa thông tin trong token.

Sử dụng trường exp (expiration) trong JWT để giới hạn thời gian sử dụng token, ngăn việc sử dụng lại token sau khi hết hạn.

Triển khai các cơ chế quản lý phiên token, như khả năng thu hồi token, để đảm bảo rằng chỉ các token hợp lệ mới có thể truy cập hệ thống.

Tránh lưu trữ JWT trong các nơi dễ bị tấn công như local storage hoặc session storage, đặc biệt khi sử dụng trên các ứng dụng web. Sử dụng cookie với cờ HttpOnly và Secure để tránh tấn công XSS.

Kiểm tra bảo mật định kỳ để phát hiện và xử lý kịp thời các lỗ hổng tiềm ẩn trong quá trình sử dụng JWT trong ứng dụng.

# 17SpecialCombo_Lab
## Tiêu đề: Software and Data Authority Failures + Security Logging and Monitoring Failures

## Mô tả
Lỗ hổng kết hợp giữa "Software and Data Authority Failures" và "Security Logging and Monitoring Failures" trong bài lab này liên quan đến việc quản lý quyền truy cập kém và thiếu kiểm tra các hành vi đáng ngờ. Kẻ tấn công có thể tạo ra các phiên cookie giả mạo để leo thang đặc quyền, đồng thời không có biện pháp ghi lại đầy đủ các sự kiện quan trọng để phát hiện tấn công.

Trong kịch bản này, ta có một trang web nơi mã thông báo phiên được sử dụng để xác thực người dùng. Lỗ hổng xảy ra khi mã thông báo này có thể bị thay đổi hoặc tạo lại một cách dễ dàng, mà không có sự xác thực hoặc kiểm tra tính toàn vẹn thích hợp, dẫn đến việc chiếm quyền truy cập với đặc quyền cao hơn.

### Tóm tắt và Các bước thực hiện

Kịch bản cho chúng ta 1 trang web và yêu cầu ta phải đọc được log:

Để ý rằng, đề cũng cho ta 1 token, ta thử decode token này:


Tuy nhiên, nếu thử thay và thêm vào thì chúng ta sẽ bị phát hiện:


Do đó, ta sẽ tìm phần code tạo token này để tự tạo. Tìm được github của tác giả, tôi chỉnh sửa và có đoạn code như sau:

<?php
function createCookie(){
    $userData = array(
        'username' => 'visitor',
        'role' => array(
            'name' => 'visitor',
            'admin' => true
        )
    );
    $serialized = serialize($userData);
    $digest = hash('sha256', $serialized);
    $combined = $serialized . $digest;
    $encoded = base64_encode($combined);
    return (urlencode($encoded));
}

// Create the cookie
$cookie = createCookie();

// Print the cookie
echo "Generated Cookie: " . $cookie;
?>
// Generated Cookie: YToyOntzOjg6InVzZXJuYW1lIjtzOjc6InZpc2l0b3IiO3M6NDoicm9sZSI7YToyOntzOjQ6Im5hbWUiO3M6NzoidmlzaXRvciI7czo1OiJhZG1pbiI7YjoxO319YjQ2MmI2OTAxMGIyZThjZmVmZmI4M2EzYWE3MWU0ZjhjNWI1NDQwZjI3ZTc0MTIxMWE4MzIxZjkyMDU4M2VlZA%3D%3D

Sửa phần cookie này lại trong gói request rồi gủi lại server, ta có như sau:


## Tài liệu hỗ trợ và tham khảo:
- ChatGPT
- https://github.com/Hrishikesh7665/OWASP21-PG

## Mức độ ảnh hưởng của lỗ hổng
Cho phép kẻ tấn công khai thác hệ thống theo nhiều cách khác nhau, gây ra các tác động nghiêm trọng như:
Xâm nhập vào hệ thống và chiếm quyền điều khiển.
Đánh cắp dữ liệu nhạy cảm từ cơ sở dữ liệu hoặc dịch vụ nội bộ.
Thực hiện các cuộc tấn công leo thang đặc quyền, DoS.

## Đề xuất khắc phục
Sử dụng các công cụ kiểm tra bảo mật để phát hiện và vá các lỗ hổng phổ biến như SQL Injection, XSS, SSRF, lỗ hổng xác thực và quản lý phiên.

Đảm bảo rằng cấu hình hệ thống được thực hiện đúng cách, chẳng hạn như tắt các tính năng hoặc dịch vụ không cần thiết, thiết lập quyền hạn tối thiểu cho các tài khoản và dịch vụ.

# 19imageDownloader_ssrf

## Tiêu đề: A10:2021 – Server-Side Request Forgery - Level 2

## Mô tả
Là một ứng dụng web Image Downloader cho phép người dùng nhập vào một URL và tải xuống hình ảnh tương ứng. Ứng dụng này có khả năng bị khai thác qua lỗ hổng SSRF (Server-Side Request Forgery), nơi mà người dùng có thể thao túng tham số URL để truy cập các tệp tin hạn chế trên máy chủ.

### Tóm tắt và Các bước thực hiện
Lỗ hổng SSRF (Server-Side Request Forgery) xảy ra khi một ứng dụng web cho phép người dùng cung cấp một URL từ xa mà không thực hiện xác thực hoặc kiểm tra đầy đủ. Lỗ hổng này cho phép kẻ tấn công ép buộc ứng dụng gửi yêu cầu đến một đích khác mà không được mong muốn, từ đó có thể khai thác các tài nguyên bên trong hoặc bên ngoài hệ thống.

- **Bước 1: Kiểm tra giao diện và tấn công**
Ở đây, ban đầu mình có submit thử `/etc/passwd` nhưng nó hiện ra lỗi 'NO protocal present : request error' -> ta phải tìm hiểu các protocol này.
Qua quá trình tìm hiểu, mình có thấy được để tiếp cận vào file hệ thống, ta cần sử dụng `file://`, do đó mình sửa payload lại thành `file:///etc/passwd` và được kết quả như này:


Lí do ảnh ra màu đen là vì nó được render như một ảnh, còn ở đây dữ liệu từ response của web không phải là ảnh mà là text nên nó sẽ bị vỡ. Tiếp theo, để tiếp cận được file gợi ý để thắng game, ta cần tìm hiểu nó nên lưu như nào.

Cơ bản, cái web này sẽ có root directory là `/var/www/html` và trang game của ta sẽ nằm ở `./bugs/19imageDownloader_ssrf`, do đó để access được cái kia thì ta có thể thêm đuôi `secret/superSecret.php` vào sau; từ đó có payload đầy đủ là `file:///var/www/html/bugs/19imageDownloader_ssrf/secret/superSecret.php`:


## Tài liệu hỗ trợ và tham khảo:
- ChatGPT
- https://github.com/Hrishikesh7665/OWASP21-PG

## Mức độ ảnh hưởng của lỗ hổng
Kẻ tấn công thực hiện các yêu cầu tùy ý từ máy chủ mục tiêu đến các dịch vụ khác. Trong trường hợp này, lỗ hổng thường xảy ra trong các chức năng tải xuống hình ảnh từ URL, nơi người dùng có thể cung cấp một liên kết để hệ thống tự động tải về hình ảnh. Kẻ tấn công có thể khai thác lỗ hổng này để:
Thực hiện các yêu cầu tới các dịch vụ nội bộ mà kẻ tấn công không thể truy cập trực tiếp, từ đó có thể dò tìm cấu trúc mạng hoặc xâm nhập vào các hệ thống khác.
Đọc hoặc ghi dữ liệu từ các dịch vụ khác, chẳng hạn như cơ sở dữ liệu hoặc các API nội bộ.
RCE thông qua khai thác lỗ hổng trong các dịch vụ nội bộ.
DoS bằng cách thực hiện các yêu cầu không mong muốn đến các tài nguyên nội bộ, dẫn đến quá tải hệ thống.

## Đề xuất khắc phục
Giới hạn khả năng tải xuống hình ảnh hoặc thực hiện các yêu cầu HTTP từ máy chủ chỉ tới các nguồn tin cậy và không cho phép truy cập các địa chỉ nội bộ hoặc các dịch vụ nội bộ khác.

Tất cả URL người dùng cung cấp đều kiểm tra và xác thực chặt chẽ, loại bỏ các yêu cầu đến các địa chỉ không hợp lệ hoặc không an toàn như localhost, 127.0.0.1, hoặc các địa chỉ trong mạng nội bộ.

Thiết lập whitelist cho các tên miền hoặc IP đáng tin cậy mà chức năng tải xuống hình ảnh có thể truy cập. Bất kỳ yêu cầu nào ngoài danh sách này nên bị từ chối.

Chỉ cho phép giao thức HTTP và HTTPS vô hiệu hóa các giao thức nguy hiểm như ftp://, file://, hoặc các giao thức không an toàn khác có thể bị khai thác.

Định tuyến tất cả các yêu cầu từ chức năng tải xuống qua một proxy an toàn để kiểm tra, theo dõi, và ngăn chặn các yêu cầu độc hại hoặc không mong muốn.

Ghi log cho các yêu cầu và giám sát hoạt động tải xuống hình ảnh để phát hiện các yêu cầu bất thường hoặc khả nghi, từ đó có thể phản ứng kịp thời nếu bị tấn công.

# Lab: Password brute-force via password change
## Mô tả
Chức năng thay đổi mật khẩu của phòng thí nghiệm này khiến nó dễ bị tấn công bằng phương pháp brute force.

## Tóm tắt và Các bước thực hiện
Bài lab này bị một lỗ hổng đó là chức năng thay đổi mật khẩu khiến nó dễ bị tấn công bằng cách dùng brute-force. Để giải quyết ta được cung cấp 1 danh sách mật khẩu để dùng brute-force tài khoản của Carlos và truy cập trang "My account" để hoàn thành.

- **Bước 1: Quan sát hành vi của web**

Ta để ý nếu nhập hai mật khẩu mới khác nhau, một thông báo lỗi là `Current password is incorrect`. Nếu bạn nhập mật khẩu hiện tại đúng nhưng hai mật khẩu mới khác nhau, thông báo sẽ nói "New passwords do not match". Chúng ta có thể sử dụng thông báo này để xác định mật khẩu đúng


Ngoài ra, một request sẽ trông như thế này:

- **Bước 2: Tấn công trang web sử dụng Intruder**

Trong Burp Intruder, thay đổi tham số `username` thành `carlos` và thêm vị trí payload vào tham số `current-password`. Đảm bảo rằng các tham số mật khẩu mới được đặt thành hai giá trị khác nhau như sau:


Ngoài ra, sử dụng các mật khẩu được cung cấp để làm payload, ta tiến hành `Start attack` và được như sau:

Ta có thể thấy được password của carlos là `123456`, ghi chú lại mật khẩu này và đăng xuất khỏi tài khoản của bản thân rồi đăng nhập lại với tài khoản carlos và mật khẩu mà ta vừa ghi chú. Cuối cùng, nhấp vào "My account" để hoàn thành bài lab.


## Mức độ ảnh hưởng của lỗ hổng
Kẻ tấn công thực hiện tấn công brute force để đoán mật khẩu của người dùng. Kẻ tấn công có thể khai thác tính năng thay đổi mật khẩu của trang web để thử nhiều mật khẩu khác nhau mà không gặp giới hạn về số lần thử. Dựa vào phản hồi của hệ thống (ví dụ: thông báo lỗi "New passwords do not match"), kẻ tấn công có thể biết được khi nào mật khẩu hiện tại đúng.

Nếu thành công, có thể chiếm quyền truy cập vào tài khoản của nạn nhân, có thể truy cập thông tin cá nhân, thực hiện các hành động độc hại như thay đổi thông tin tài khoản, xem dữ liệu nhạy cảm, hoặc thậm chí thực hiện các giao dịch thay mặt nạn nhân. Điều này có thể dẫn đến mất quyền kiểm soát tài khoản và gây ra thiệt hại về bảo mật và tài chính.

## Đề xuất khắc phục
Triển khai giới hạn số lần nhập mật khẩu không hợp lệ trong một khoảng thời gian nhất định. Điều này giúp ngăn chặn các cuộc tấn công brute force, bằng cách giới hạn số lần thử đăng nhập hoặc thay đổi mật khẩu.

Thêm CAPTCHA vào quá trình thay đổi mật khẩu để ngăn các công cụ tự động như Burp Intruder thực hiện tấn công brute force. Ngoài ra, việc triển khai xác thực đa yếu tố (MFA) sẽ tăng cường bảo mật.

Thay đổi thông báo lỗi để không tiết lộ quá nhiều thông tin cho kẻ tấn công. Ví dụ: thông báo chung "Mật khẩu không hợp lệ" thay vì thông báo riêng cho mỗi trường hợp như "Current password is incorrect" và "New passwords do not match."

Đảm bảo rằng mật khẩu được lưu trữ dưới dạng hash an toàn (ví dụ: bcrypt, argon2) và yêu cầu người dùng đặt mật khẩu mạnh hơn (phức tạp và dài hơn).

Giám sát và ghi log các hành vi bất thường liên quan đến thay đổi mật khẩu, như một số lượng lớn yêu cầu thay đổi mật khẩu từ cùng một địa chỉ IP hoặc tài khoản trong một khoảng thời gian ngắn.

# Lab: Username enumeration via response timing
## Mô tả
Bruteforce tên tài khoản người dùng thông qua thời gian phản hồi

### Tóm tắt và Các bước thực hiện
Để giải quyết bài này, dựa theo mô tả, ta sẽ thực hiện bruteforce username và từ tgian phản hồi của server ta sẽ xác định xem đâu là credential đúng rồi từ đó đăng nhập vào trang tài khoản.

- **Bước 1: Quan sát hành vi và đưa ra giả thuyết**


Trang web cho phép chúng ta đăng nhập vào bình thường, và từ tên đề bài, ta sẽ thử đăng nhập sai thông tin thử xem có liên quan gì đến thời gian không:


Và, có! Trang web sẽ block không cho chúng ta đăng nhập trong vòng 30p tiếp theo -> Ngay lập tức có ý tưởng rằng trang web này có thể đã sử dụng một cơ chế gọi là hỗ trợ header `X-forwarded-for` để tránh ta bruteforce.

- **Bước 2: Gửi Yêu cầu Đăng nhập qua Burp Repeater với header mới**

Sau một số lần thử, hệ thống sẽ chặn IP của bạn (thông qua thông báo lỗi hoặc không cho phép gửi yêu cầu tiếp).
Thêm header X-Forwarded-For vào yêu cầu trong Repeater:


Vậy là đã được gửi lại dù cùng 1 thông tin đó nhưng ta đã thêm header!

- **Bước 3: Thử nghiệm các trường hợp đối với độ dài của mật khẩu/username và tạo payload dò username**

Ta tiến hành thử nhiều username và mật khẩu khác nhau và có thể nhận rằng với những username không hợp lệ thì thời gian phản hồi gần như giống nhau và còn cái hợp lệ thì thời gian phản hồi tăng lên tùy thuộc vào độ dài của mật khẩu. Điều này cho thấy hệ thống đang kiểm tra mật khẩu của username hợp lệ.

Đã đủ manh mối, giờ ta sẽ thực hiện bruteforce để tìm ra username hợp lệ với password rất dài (1000 kí tự)

Sử dụng Burp Intruder để tự động thử nhiều username và chọn kiểu tấn công `Pitchfork`
Thiết lập Payloads cho X-Forwarded-For và Username, với:

- Payload 1: Thêm X-Forwarded-For header với giá trị IP được sinh tự động như sau `Payload type: Numbers (1-100, step 1)`.

- Payload 2: Thêm danh sách username được cho

Cuối cùng thực hiện quan sát thời gian phản hồi trong các cột bằng cách ở cuối tấn công, nhấp vào `Columns` -> `Response received và Response completed` để xem thời gian phản hồi của từng yêu cầu và ta sẽ ghi lại username có thời gian phản hồi lâu nhất (vì đó là username hợp lệ).

Ta để ý có username sau là có response rất to, ta sẽ thử chúng với list password được cấp


- **Bước 4: Tạo payload dò mật khẩu**
Sử dụng list pasword và thử với username: `alabama`


- Như vậy, ta đã login thành công với credential `alabama:1qaz2wsx`


## Mức độ ảnh hưởng của lỗ hổng
Lỗ hổng này có nguy cơ cao vì cho phép tấn công brute-force tài khoản và bypass bảo vệ dựa trên IP thông qua X-Forwarded-For. Kẻ tấn công có thể giả mạo IP để tránh bị chặn và sử dụng timing attack để xác định username hợp lệ dựa trên thời gian phản hồi. Khi kết hợp các kỹ thuật này, chúng có thể thử nhiều lần đăng nhập mà không bị giới hạn, gây ra nguy cơ chiếm đoạt tài khoản, đặc biệt là nếu tấn công vào tài khoản quản trị. Điều này có thể dẫn đến mất quyền kiểm soát hệ thống, mất dữ liệu nhạy cảm, hoặc tổn hại uy tín của tổ chức.

## Đề xuất khắc phục
Để khắc phục, hệ thống cần chỉ chấp nhận IP từ các proxy tin cậy và đặt giới hạn đăng nhập dựa trên username thay vì IP. Thời gian phản hồi phải đồng bộ cho mọi trường hợp để ngăn timing attack. Tích hợp CAPTCHA và triển khai xác thực hai yếu tố (2FA) sẽ làm giảm nguy cơ brute-force. Việc ghi log chi tiết và tạo cảnh báo tự động khi phát hiện hành vi bất thường sẽ giúp theo dõi và ngăn chặn các cuộc tấn công kịp thời.

# Lab: Username enumeration via different responses
## Mô tả
Tận dụng sự khác nhau giữa các lần hồi đáp của server mà tiến hành tấn công bruteforce tài khoản của người dùng.

### Tóm tắt và Các bước thực hiện
Bài lab này dễ bị tấn công liệt kê tên người dùng và brute-force mật khẩu. Trong hệ thống có một tài khoản với tên người dùng và mật khẩu có thể dự đoán được, được liệt kê trong các danh sách sau:

Danh sách tên người dùng khả thi
Danh sách mật khẩu khả thi

Để hoàn thành bài lab, bạn cần liệt kê được tên người dùng hợp lệ, sau đó brute-force mật khẩu của tài khoản này và truy cập vào trang tài khoản của họ.

- **Bước 1: Gửi yêu cầu đăng nhập sang Intruder và chỉnh payload để brute username**

Ta gửi 1 yêu cầu đăng nhập bình thường trên web và tìm yêu cầu `POST /login` ở trong phần `Http History` rồi gửi nó qua Intruder. Sau đó, ở `Payload Position`, ta thêm các dấu $ ở username để đánh dấu chỗ để bruteforce như sau(còn password giữ nguyên):

Tiếp theo, trong phần `Payloads` , ta paste danh sách username vào và bấm `Start attack`:

Khi tấn công hoàn tất, ta xem cột `Length` trong bảng kết quả và để ý rằng một trong các dòng sẽ có độ dài lớn hơn so với các dòng khác.


Biết rằng đây là username đúng (vì đúng nó mới check tới password) nên ta sẽ ghi chú lại và chuyển sang tấn công mật khẩu.

- **Bước 2: Bruteforce password và tiến hành đăng nhập hoàn thành bài**

Tương tự với khi ta bruteforce tên người dùng, lần này ta sử dụng list password được cấp sẵn và thiết lập lại các cài đặt về `Payloads` và `Payload positions` với lần này để tên username là `acceso` và bao giá trị password lại với cặp $:

Khi tấn công hoàn tất, ta kiểm tra cột `Status` để kiểm tra xem đã đăng nhập được chưa (302 nếu đăng nhập được vì đây là một mã cho thấy web điều hướng đến cái khác, còn 200 thì không):


Lần này ta thấy được password là `qwerty`.

Cuối cùng ta dùng username và password vừa tìm thấy để đăng nhập vào trang là xong bài.

## Mức độ ảnh hưởng của lỗ hổng
Kẻ tấn công khai thác các phản hồi khác nhau từ máy chủ khi cố gắng đăng nhập với các tài khoản không hợp lệ. Kẻ tấn công có thể phân biệt tài khoản tồn tại hay không dựa vào sự khác biệt trong phản hồi của hệ thống.

Sau khi xác định được tên người dùng hợp lệ, kẻ tấn công có thể thực hiện tiếp brute force để đoán mật khẩu của tài khoản đó.

Hậu quả tiềm ẩn là mất quyền kiểm soát tài khoản, rò rỉ thông tin cá nhân và thậm chí là mất mát tài chính, đặc biệt nếu tài khoản liên quan đến dịch vụ ngân hàng hoặc giao dịch trực tuyến.

## Đề xuất khắc phục
Hệ thống nên cung cấp thông báo lỗi chung cho cả tên người dùng và mật khẩu khi đăng nhập thất bại, ví dụ: "Tên người dùng hoặc mật khẩu không đúng."

Hạn chế số lần thử đăng nhập không hợp lệ trong một khoảng thời gian nhất định. Nếu vượt quá giới hạn, tài khoản hoặc địa chỉ IP sẽ bị khóa tạm thời.

Triển khai CAPTCHA cho các form đăng nhập sau một số lần đăng nhập không thành công để ngăn chặn tấn công tự động. Sử dụng xác thực đa yếu tố (MFA) sẽ tăng cường bảo mật bằng cách yêu cầu kẻ tấn công có thêm một yếu tố xác thực khác ngoài mật khẩu.

Theo dõi và ghi log mọi hoạt động đăng nhập bất thường, chẳng hạn như nhiều lần đăng nhập không thành công từ cùng một địa chỉ IP hoặc tài khoản.

Đảm bảo rằng mật khẩu của người dùng được lưu trữ dưới dạng hash an toàn và yêu cầu người dùng đặt mật khẩu mạnh hơn (kết hợp chữ cái, số, ký tự đặc biệt).

# Lab: 2FA simple bypass
## Mô tả
Xác thực 2 bước bị vượt qua và từ đó truy cập trái phép vào tài khoản của người dùng khác.
### Tóm tắt và Các bước thực hiện

Có được tài khoản và mật khẩu của nạn nhân nhưng mà ta không có quyền xem được mã xác thực 2 bước của họ, bây giờ ta phải tìm cách để vô được account của họ

- **Bước 1: Đăng nhập vô user của bản thân trước**
Trang web cho ta các mục như `Email Client`, `My account`:

Ta vào `Mail Client` để kiểm tra trong đó là gì:


Ở trong đây hiện giờ chưa có gì, ta quay lại và đăng nhập vào user `wiener|peter` và buộc phải có một mã xác thực:

Tiếp theo, và vào mail server để nhận được mã xác thực:

Nhập mã xác thực xong thì vô được trang `My account`:

- **Bước 2: Đăng nhập vô user nạn nhân**
Ta dùng username và password được cấp để đăng nhập và buộc phải có mã:


Khi nhập mã vào ô, ta khoan hẳn enter mà sửa đường dẫn thành `/my-account`:

Lúc này vậy là ta đã vào được! Lí do ở đây có thể là vì endpoint `/my-account` không được bảo vệ để kiểm tra xem người dùng đã hoàn thành xác thực 2FA hay chưa. Điều này cho phép người dùng truy cập trực tiếp vào tài khoản mà không cần cung cấp mã xác minh

## Mức độ ảnh hưởng của lỗ hổng
Lỗ hổng cho phép kẻ tấn công bỏ qua cơ chế xác thực hai yếu tố (2FA) để truy cập trái phép vào tài khoản của người dùng khác mà không cần mã xác thực thứ hai. Kẻ tấn công chỉ cần có được tên đăng nhập và mật khẩu của nạn nhân, sau đó có thể khai thác lỗ hổng này để truy cập thẳng vào tài khoản mà không cần mã 2FA.

Điều này làm vô hiệu hóa hoàn toàn biện pháp bảo mật bổ sung mà 2FA mang lại. Kẻ tấn công có thể tiếp cận các thông tin cá nhân, nhạy cảm hoặc thậm chí thực hiện các hành vi xâm phạm, chẳng hạn như thay đổi mật khẩu, chiếm đoạt tài khoản, và tiến hành các hoạt động độc hại khác.

Hậu quả có thể rất nghiêm trọng, đặc biệt nếu tài khoản của nạn nhân liên quan đến thông tin nhạy cảm hoặc các dịch vụ tài chính. Đây là một lỗ hổng nghiêm trọng trong hệ thống xác thực đa yếu tố, làm suy yếu sự bảo mật tổng thể của hệ thống.

## Đề xuất khắc phục
Hệ thống phải đảm bảo rằng tất cả các endpoint nhạy cảm (như /my-account) đều được bảo vệ để yêu cầu người dùng cung cấp mã xác thực 2FA trước khi được phép truy cập. Đặc biệt, cần kiểm tra trạng thái xác thực của người dùng để đảm bảo họ đã hoàn thành quá trình xác thực 2FA.

Đảm bảo rằng người dùng không thể bỏ qua quá trình xác thực bằng cách chỉnh sửa URL hoặc truy cập trực tiếp vào các trang nhạy cảm sau khi nhập thông tin đăng nhập. Quá trình xác thực nên được theo dõi chặt chẽ, và không cho phép chuyển hướng đến các trang quan trọng nếu người dùng chưa hoàn tất quá trình 2FA.

Sau khi người dùng cung cấp mã xác thực 2FA thành công, hệ thống nên tạo ra một mã thông báo (token) để xác minh trạng thái xác thực. Mã thông báo này sẽ được kiểm tra trong suốt các phiên đăng nhập để đảm bảo rằng người dùng đã hoàn thành bước 2FA.

Thực hiện kiểm tra và rà soát bảo mật định kỳ để đảm bảo rằng không có lỗ hổng nào tồn tại trong cơ chế 2FA. Việc giám sát và log các hành vi bất thường liên quan đến xác thực cũng là một phương pháp tốt để phát hiện sớm các cuộc tấn công.

Gửi thông báo qua email hoặc SMS cho người dùng mỗi khi có một lần đăng nhập hoặc yêu cầu mã xác thực 2FA mới. Điều này giúp người dùng phát hiện ra sớm bất kỳ hành vi truy cập trái phép nào và có thể thay đổi thông tin bảo mật của họ kịp thời.

# Lab: Exploiting clickjacking vulnerability to trigger DOM-based XSS
## Mô tả
Khai thác Clickjacking để kích hoạt DOM-based XSS

### Tóm tắt và Các bước thực hiện
Đề yêu cầu chúng ta sử dụng clickjacking để khiến người dùng nhấp vào nút "Click me" và nhấp chuột này sẽ kích hoạt lệnh `print()` (lệnh JavaScript để in trang).

Để hiểu rõ yêu cầu, ta sẽ làm rõ clickjacking và DOM-based XSS là gì.

*Clickjacking* là một kiểu tấn công giao diện (UI redress attack), trong đó:

- Trang web hợp lệ (mục tiêu) được nhúng vào dưới dạng iframe trong một trang web mồi do kẻ tấn công tạo ra. Người dùng tưởng rằng họ đang tương tác với nội dung trên trang mồi, nhưng thực chất đang tương tác với nội dung trên iframe của trang mục tiêu (ẩn bên dưới hoặc làm trong suốt).
- Clickjacking dùng CSS để điều chỉnh bố cục sao cho các hành động trên trang mồi được đồng bộ với iframe của trang mục tiêu, đánh lừa người dùng thực hiện các thao tác không mong muốn (như bấm nút, gửi biểu mẫu, thay đổi cài đặt).

*DOM-based XSS* là một dạng tấn công Cross-Site Scripting (XSS), trong đó:

- Dữ liệu do kẻ tấn công kiểm soát (ví dụ: từ URL) được JavaScript trong trình duyệt xử lý.
JavaScript này truyền dữ liệu đến một sink hỗ trợ thực thi mã động (như eval() hoặc innerHTML).
- Kẻ tấn công có thể chèn mã độc JavaScript và chiếm quyền điều khiển tài khoản của người dùng, lấy dữ liệu nhạy cảm hoặc thực thi lệnh tùy ý trên phiên của nạn nhân.

Do đó, để tóm tắt lại, ta chỉ cần viết 1 đoạn mã để lừa đảo khi người dùng nhấn vào thì họ sẽ nhấn vào nút có hàm `print()`
- **Bước 1: Khám phá trang web**

Trang web cho ta 1 giao diện như sau, tuy nhiên ta chỉ cần để ý ở `Go to exploit server`:

Ở trang này, ta có giao diện như sau:

- **Bước: Tạo mã CSS để thực hiện**
Như đã nói ở trên, clickjacking sẽ được triển khai thông qua CSS để tạo và thao tác các lớp (layers), trong đó iframe của trang mục tiêu được đặt chồng lên trang web mồi (decoy website) và do đó, dưới đây là phần mã css chúng ta dùng để làm việc này:

<style>
	iframe {
		position:relative;
		width:1000px;
		height: 900px;
		opacity: 0.01;
		z-index: 2;
	}
	div {
		position:absolute;
		top:810px;
		left:80px;
		z-index: 1;
	}
</style>
<div>Click me</div>
<iframe
src="https://0a09001b030f276e803003b20032004c.web-security-academy.net/feedback?name=<img src=1 onerror=print()>&email=[e-mail]&subject=test&message=test#feedbackResult"></iframe>

Giải thích như sau:
- Iframe: Nhúng trang web mục tiêu vào trong iframe.
- Positioning: Sử dụng position để định vị iframe sao cho nó khớp với giao diện của trang mồi.
- Z-index: Điều chỉnh thứ tự lớp hiển thị giữa iframe và trang mồi.
- Opacity: Điều chỉnh độ trong suốt (thường gần bằng 0.0) để iframe không thể nhìn thấy.

- **Bước 2: Gửi cho người dùng và kết thúc bài**
Cuối cùng, ta chỉ cần bấm `Store-> View exploit` rồi ấn vào nút `Click me` là xong!


## Mức độ ảnh hưởng của lỗ hổng
Clickjacking kết hợp với DOM-based XSS tạo ra một lỗ hổng nghiêm trọng, khi kẻ tấn công có thể lừa người dùng nhấp vào các phần tử trên trang mà không nhận thức được, dẫn đến việc thực thi mã JavaScript độc hại. Bằng cách khai thác lỗ hổng này, kẻ tấn công có thể gây ra những hậu quả như:
In trang web mà không có sự đồng ý của người dùng.
Thực thi các mã JavaScript độc hại khác, ví dụ: chèn mã độc để đánh cắp thông tin phiên đăng nhập, dữ liệu nhạy cảm, hoặc thực hiện các hành động thay đổi dữ liệu trên tài khoản của nạn nhân.
Chiếm quyền điều khiển phiên duyệt web của nạn nhân và có thể khai thác sâu hơn vào hệ thống.

Trong tình huống này, nếu kẻ tấn công có thể khiến người dùng nhấp vào một nút vô hại như "Click me", và đằng sau đó là mã JavaScript độc hại, thì việc khai thác sẽ xảy ra mà nạn nhân không hề hay biết.

## Đề xuất khắc phục
Cài đặt tiêu đề HTTP X-Frame-Options thành DENY hoặc SAMEORIGIN để ngăn chặn việc nhúng trang web của bạn vào iframe trong các trang khác. Điều này giúp bảo vệ trang khỏi các cuộc tấn công clickjacking.

Cấu hình CSP để chặn việc nhúng trang vào iframe trừ khi xuất phát từ các nguồn được tin cậy.

Kiểm soát các dữ liệu đầu vào được xử lý bởi JavaScript trên trình duyệt. Bất kỳ dữ liệu nào được chèn vào DOM cần được xử lý hoặc mã hóa đúng cách để ngăn chặn mã độc được thực thi thông qua các sự kiện DOM như onerror hoặc eval().

Tránh sử dụng các hàm như innerHTML hoặc eval() mà không có biện pháp phòng ngừa thích hợp, vì chúng có thể dễ dàng bị lợi dụng cho các cuộc tấn công DOM-based XSS.

Kiểm tra và giám sát các hành vi không bình thường liên quan đến các yêu cầu đáng ngờ hoặc hoạt động bất thường trên trang web.

Triển khai các biện pháp phòng thủ khác như cảnh báo cho người dùng khi phát hiện các hành vi không mong muốn liên quan đến clickjacking hoặc XSS.

Các công cụ kiểm tra bảo mật tự động có thể được sử dụng để phát hiện lỗ hổng XSS và clickjacking trong giai đoạn phát triển ứng dụng web.

# Lab: Basic server-side template injection
## Mô tả
Lỗi SSTI vì xây dựng template ERB không an toàn.

### Tóm tắt và Các bước thực hiện

Bài lab này khai thác Server-Side Template Injection (SSTI), một lỗ hổng cho phép chèn và thực thi mã độc hại trên máy chủ thông qua template ERB. Lỗ hổng này xảy ra do việc xây dựng template không an toàn, cho phép kẻ tấn công thực thi mã Ruby tùy ý từ input của người dùng.

- **Bước 1: Khám phá chức năng của trang web**
Đây là 1 trang web cho phép chúng ta mua hàng, chúng ta có thể chọn đồ để mua:

Ở đây, ta nhấp vào 1 món hàng đầu tiên thử, và nhận được thế này:

Có thể thấy rằng sản phẩm này hiện không còn hàng, và được pop up lên trang web(ở đây đã bắt đầu nghi ngờ được vì nó ghi thẳng lên web), ngoài ra ở trên thanh URL cũng có 1 tham số `message` để báo rằng hết hàng như này:
`?message=Unfortunately%20this%20product%20is%20out%20of%20stock`
Nhận ra rằng nó y chang những gì được ghi trên web, và dấu cách là kí tự đặc biệt đã được encode. Okay, vậy đã đủ manh mối để ta ngờ ngợ, giờ sang bước tiếp theo.
- **Bước 2: Kiểm tra xem có tồn tại lỗi hay không**
Ta thử thay đổi URL thành như sau:
Bingo, vậy là web này có 1 lỗ hổng rằng ta có thể thao tác trang web qua tham số `message`. Dựa vào hint trên đề bài, ta đọc tài liệu về cách thực thi code để tiến hành RCE.

Sau quá trình đọc, ta nhận ra ta có thể nhét phần code Ruby(ERB là embedded ruby) vào giữa tag `<% %>`, ta thử `<% system("cat /etc/passwd")%>' và encode URL nó:
và:
Bây giờ ta cùng xóa file đề yêu cầu là xong
- **Bước 3: Xóa file**
Ta dùng lệnh `rm morale.txt`, encode nó lại rồi gửi lại server:
Vậy là đã xong!

## Mức độ ảnh hưởng của lỗ hổng
Kẻ tấn công có thể chèn và thực thi mã tùy ý trên máy chủ thông qua việc thao tác các template.

Khai thác SSTI trong ERB (Embedded Ruby) cho phép kẻ tấn công:
Thực thi các lệnh hệ thống trên máy chủ, ví dụ như đọc file nhạy cảm (/etc/passwd) hoặc xóa file như trong ví dụ.
Chiếm quyền điều khiển máy chủ, từ đó có thể thực hiện tấn công leo thang đặc quyền và gây ra những thiệt hại nghiêm trọng, như chiếm quyền quản lý toàn bộ hệ thống.
RCE: Kẻ tấn công có thể thực thi mã tùy ý từ xa trên server, có khả năng chiếm quyền điều khiển máy chủ và khai thác thêm các lỗ hổng khác.

## Đề xuất khắc phục
Không chèn trực tiếp dữ liệu người dùng vào template. Thay vào đó, sử dụng các phương pháp xử lý dữ liệu an toàn và tránh xử lý trực tiếp các tham số input từ người dùng.

Thực hiện escaping và sanitization cho các tham số được nhúng vào template để đảm bảo không chứa mã độc hại.

Áp dụng WAF để phát hiện và chặn các mẫu tấn công SSTI trước khi chúng tiếp cận máy chủ.

Một số framework template như Jinja2 hay ERB có thể nguy hiểm nếu không được cấu hình đúng cách. Cần sử dụng các template engine an toàn hơn hoặc đảm bảo rằng không có lỗ hổng khi xử lý input.

Đảm bảo rằng input từ người dùng được xác thực và áp dụng CSP để ngăn ngừa các hành vi khai thác XSS hoặc SSTI.

# Lab: Modifying serialized objects

## Mô tả
Lợi dụng lỗi trong việc quản lý phiên bằng cơ chế serialization để đăng nhập bằng tài khoản admin.
### Tóm tắt và Các bước thực hiện

Bài lab này sử dụng cơ chế phiên dựa trên tuần tự hóa (serialization) và có lỗ hổng cho phép leo thang đặc quyền. Ta cần chỉnh sửa đối tượng đã được tuần tự hóa trong cookie phiên để khai thác lỗ hổng và giành quyền quản trị. Sau đó, xóa người dùng carlos.

- **Bước 1: Đăng nhập**

Đầu tiên, ta tiến hành đăng nhập với cred là wiener:peter. Sau đó, khi đăng nhập thành công, server sẽ cấp cho ta một cookie để xác thực phiên như sau:


- **Bước 2: Phân tích cookie**
Thử decode cookie này, ta có thông tin như sau:


Ở đây, ta có thể thấy việc phiên của mình có phải là admin hay không chỉ được xem xét qua giá trị boolean 0-1 ở phần cuối của cookie, ta thử đổi từ 0 sang 1 và gửi lại server:


Lúc này, ta đã mở khóa được “Admin panel”, cùng vào bên trong xem nó có gì:


Lúc này chỉ cần xóa user Carlos nữa là xong!


## Mức độ ảnh hưởng của lỗ hổng
Kẻ tấn công sửa đổi đối tượng đã được tuần tự hóa (serialized object) để nâng cấp quyền hạn hoặc thực hiện các hành vi không mong muốn. Trong bài này, kẻ tấn công có thể thay đổi giá trị trong cookie phiên để chuyển đổi từ người dùng thông thường thành admin, cho phép truy cập vào bảng điều khiển quản trị và thực hiện hành động xóa người dùng.

Lỗ hổng này có thể dẫn đến leo thang đặc quyền (privilege escalation), cho phép kẻ tấn công chiếm quyền điều khiển tài khoản quản trị hoặc thực hiện các thay đổi quan trọng trên hệ thống.

Nếu đối tượng được tuần tự hóa bao gồm dữ liệu nhạy cảm (như thông tin xác thực), kẻ tấn công có thể khai thác lỗ hổng này để đánh cắp thông tin hoặc RCE.

## Đề xuất khắc phục
Tránh sử dụng các hệ thống tuần tự hóa dễ bị tấn công. Thay vào đó, nên sử dụng các cơ chế bảo mật như JWT với mã hóa và ký số để bảo vệ dữ liệu phiên.

Ký số các đối tượng được tuần tự hóa, máy chủ có thể kiểm tra tính toàn vẹn của dữ liệu, đảm bảo rằng nó không bị thay đổi khi nhận lại từ phía người dùng.

Dữ liệu tuần tự hóa nên được mã hóa trước khi gửi đến người dùng để đảm bảo rằng dữ liệu không thể bị xem hoặc chỉnh sửa bởi bên thứ ba.

Hệ thống nên thực hiện kiểm tra quyền hạn (authorization checks) ở phía máy chủ để đảm bảo rằng các yêu cầu chỉ được thực hiện bởi người dùng có quyền hợp lệ, thay vì dựa trên các tham số không an toàn như cookie phiên.

Tránh lưu trữ thông tin nhạy cảm hoặc quan trọng (như quyền quản trị) trong cookie hoặc dữ liệu phiên mà người dùng có thể truy cập và sửa đổi.

# Lab: Source code disclosure via backup files
## Mô tả
Source code của trang web bị rò rĩ từ đó kẻ tấn công có thể đọc được những thông tin quan trọng nhạy cảm.

## Tóm tắt và Các bước thực hiện
Bài lab này có bug là rò rỉ mã nguồn thông qua các tệp backup được lưu ở trong một thư mục ẩn và mục tiêu của chúng ta là xác định và gửi mật khẩu CSDL được mã hóa cứng trong mã nguồn bị rò rỉ.
- **Bước 1: Thử các directory cơ bản**
Với dạng tấn công như thế này, thường ta sẽ dùng các tool như `ffuf`, `dirsearch`,... Tuy nhiên thì trước hết ta vẫn nên thử tay các endpoint cơ bản, ỏ đây ta thử endpoint `robots.txt` - nơi mà nói với search engine crawlers rằng những URL nào được phép tiếp cận trên trang web, và có kết quả như sau:

Từ đây, ta thấy có 1 endpoint là `/backup`, ta truy cập vào endpoint này:

Trong đoạn mã này, mật khẩu của cơ sở dữ liệu PostgreSQL là chuỗi "tze4oh2tmzsq3zh1jwizvhd0pjg59yim", được truyền vào tham số cuối cùng của phương thức `ConnectionBuilder.from()`. Đây là chuỗi mật khẩu để kết nối đến cơ sở dữ liệu PostgreSQL nên vậy là xong bài!


## Mức độ ảnh hưởng của lỗ hổng
Lỗ hổng rò rỉ thông tin qua file backup cho phép kẻ tấn công đọc được mã nguồn của trang web, bao gồm cả thông tin nhạy cảm như mật khẩu cơ sở dữ liệu. Điều này có thể dẫn đến việc tấn công hệ thống CSDL hoặc chiếm quyền truy cập trái phép vào hệ thống quản trị.

## Đề xuất khắc phục
Đảm bảo rằng các tệp backup không thể truy cập công khai qua web. Đặt chúng ở những vị trí không thể truy cập từ URL hoặc sử dụng xác thực để bảo vệ.

Không nên lưu trữ các thông tin nhạy cảm như mật khẩu trực tiếp trong mã nguồn. Thay vào đó, sử dụng biến môi trường để lưu trữ và quản lý những thông tin này.

Thực hiện kiểm tra định kỳ các endpoint nhạy cảm và các file hệ thống để đảm bảo rằng không có lỗ hổng bảo mật.