Penetration Testing Step 3 – Nhập môn Cross-site Request Forgery – CSRF attack

Tiếp theo nội dung Penetration Testing Step 3 – SSTI attack với phương châm còn thở còn gỡ, kỳ này tôi sẽ chuyển sang một nhân vật mà tôi đã đề cập một số lần (nhưng chưa một lần giới thiệu cho đàng hoàng) đó là Cross-site Request Forgery – CSRF. Nội dung kỳ này sẽ chỉ tập trung vô phần giới thiệu dạo đầu nhẹ nhàng tình cảm. Các trò demo đâm chém, chọc ngoáy phức tạp hơn tôi sẽ triển trong các kỳ tiếp theo.

Lưu ý:

#1. SSRF vs CSRF attack

Về cơ bản, CSRF là dạng lỗ hổng bảo mật của web cho phép attacker có thể dẫn dụ người dùng thực thi các hành động một cách “vô thức”. Nhờ vào chiêu trò bẩn bựa này, attacker sẽ có thể hoàn toàn (hoặc một phần) thoát được sự kiểm soát của same origin policy trong việc ngăn chặn các sự tương tác của các website khác nhau.

Nếu bạn còn nhớ (nếu quên thì cũng chả sao vì tôi sẽ nhắc lại ngay đây), cái trò dụ dỗ nạn nhân thực hiện hành động trong “vô thức” này rồi giở trò đồi bại này cũng diễn ra với Server-side request forgery – SSRF. Điểm khác biệt ở đây là:

  • SSRF diễn ra ở phía server side, tức nạn nhân bị dụ dỗ là server-side application;
  • CSRF diễn ra ở phía client side, tức nạn nhân bị dụ dỗ là người dùng.

Lưu ý: Nếu muốn xem chi tiết hơn cái SSRF, bạn vui lòng bơi vào nội dung Penetration Testing Step 3 – Nhập môn Server-side request forgery – SSRF.

CSRF attack
CSRF attack

Nguồn: portswigger.net

#2. CSRF attack có dễ ăn?

Một khi đã có một sự vụ CSRF attack thành công (tức là đã dụ dỗ được người dùng “vô thức” thực hiện hành động mà attacker mong muốn), attacker sẽ có thể triển các bước khai thác tiếp theo ví dụ như thay đổi thiết lập email, password hay chuyển tiền đến tài khoản của vợ/bồ của đối tượng.

Nhưng mà nói thì dễ hơn làm, để CSRF attack thành công trót lọt, các điều kiện then chốt sau đây phải được đáp ứng:

  • A relevant action: Tức là đâu đó trong ứng dụng phải tồn tại ít nhất một hành động mà attacker khao khát dụ dỗ cho người dùng thực hiện. Hành động này có thể là privileged action – tức là hành động của các người dùng có quyền hạn (ví dụ admin thay đổi quyền của các user thường) hoặc đơn thuần là thao tác thay đổi dữ liệu cụ thể (ví dụ password) của người dùng nào đó;
  • Cookie-based session handling: Việc thực thi relevant action nói trên có thể cần diễn ra với một hoặc một vài HTTP request. Và nếu ứng dụng chỉ dựa vào session cookie để xác định người dùng thực hiện request mà không triển khai thêm bất kỳ phương án nào khác để theo dõi các session (hoặc xác minh request) của người dùng) thì coi như ngon ăn;
  • No unpredictable request paramenter: Tiếp theo, đám request thực hiện relevant action phải không chứa bất kỳ parameter (tham số) nào có giá trị mà attacker không thể xác định (hoặc đoán mò). Ví dụ, nếu hành động thay đổi password yêu cầu parameter nào đó dựa trên các biến thể của password hiện hành thì attacker sẽ treo mõm nghỉ ăn.

#3. Test nhanh khả năng “ăn” với CSRF attack

Ở chỗ này, nếu sử dụng Burp Suite Professtional thì bạn có thể xem xét sử dụng CSRF PoC generator có sẵn (còn nếu xài Burp Suite Community Edition thì cũng không sao, tôi sẽ giới thiệu phương án tương ứng ngay ở nội dung tiếp theo). Khi đó, công việc khai thác CSRF sẽ gói gọn trong các bước như sau:

  • Hốt cái request mà bạn muốn kiểm tra CSRF exploit;
  • Sử dụng context menu (bằng chuột phải) rồi chọn Engagement tools / Generate CSRF PoC;
  • Burp Suite sẽ tự sản xuất ra cái HTML có thể kích hoạt các request đã được lựa chọn. Cần lưu ý là cái HTML này sẽ loại bỏ cookie của bạn, và sử dụng cookie thó được từ browser của nạn nhân;
  • Tùy thuộc khẩu vị và tình hình thực tế, bạn có thể chế biến dựa trên các tùy chọn của CSRF PoC generator để có đòn CSRF attack như mong muốn;
  • Và cuối cùng là bê hết cái HTML nói trên quẳng lên browser (mà nạn nhân đã login) để coi cái requets tương ứng với các hành động mà bạn mong đợi có được thực thi hay không.

#4. CSRF attack với hệ thống không triển khai giải pháp phòng bị

Rồi, giờ tôi sẽ mần thử một nhát CSRF attack cơ bản để minh họa cái đám lý thuyết lằng nhằng nói trên. Trong kịch bản này, relevant action tương ứng sẽ là thay đổi thiết lập email của nạn nhân trên ứng dụng bị lỗ hổng CSRF.

Đầu tiên (với Burp Suite đã được thiết lập để hốt traffic), tôi login vào ứng dụng với account chính chủ của tôi cái đã. Tại đây, tôi nhận thấy có cái chức năng Update email.

My account
My account

Tôi quất đại một cái email vớ vẩn vào đấy rồi chạy thử.

Update email
Update email

Kiểm tra Burp Suite Proxy HTTP history, tôi ghi nhận cái Request/Response tương ứng.

Update email request
Update email request

Như đề cập trước đó, tôi chọn cái request tương ứng để thay đổi email rồi mở context menu bằng chuột phải rồi chọn Engagement tools / Generate CSRF PoC.

Generate CSRF PoC
Generate CSRF PoC

Ở đây, tôi sẽ cần mở Options rồi chọn Include auto-submit script trước khi click Generate.

Include auto-submit script
Include auto-submit script

Ở đây, nếu sử dụng Burp Suite Community Edition, bạn có thể hốt cái HTML template bên dưới rồi điền vào thông tin method, URLbody parameter tương ứng cho request (bạn có thể chuột phải vô request rồi chọn Copy URL cho nhanh).

<form method="$method" action="$url">

    <input type="hidden" name="$param1name" value="$param1value">

</form>

<script>

        document.forms[0].submit();

</script>

Với trường hợp minh họa trên, các thông tin tương ứng tôi lắp vào sẽ kiểu như sau.

<html>

  <!-- CSRF PoC - generated by Burp Suite Professional -->

  <body>

  <script>history.pushState('', '', '/')</script>

    <form action="https://ac571f081ea38866c0260a8e00170000.web-security-academy.net/my-account/change-email" method="POST">

      <input type="hidden" name="email" value="fake&#45;wiener&#64;normal&#45;user&#46;net" />

      <input type="submit" value="Submit request" />

    </form>

    <script>

      document.forms[0].submit();

    </script>

  </body>

</html>

Sau đó tôi bay qua exploit server dán cái exploit HTML ở trên vô Body section rồi chọn Store.

exploit server
exploit server

Để check coi hàng họ hoạt động không tôi có thể click View exploit rồi kiểm tra Request/Response tương ứng hoặc check thông tin chỗ My Account.

Updated My Account
Updated My Account

Nếu mọi chuyện đúng như thiết kế thì tôi có thể chuyển qua bước “giao hàng” cho nạn nhân. Cơ chế triển cái CSRF exploit thực tế cũng sẽ tương tự như với Reflected XSS (như tôi giới thiệu trong nội dung Penetration Testing Step 3 – Tìm và diệt mục tiêu với Reflected Cross-Site Scripting). Một giải pháp thường thấy là tôi sẽ neo cái HTML độc hại đã sáng tác ở trên vô một trang web mà tôi có thể kiểm soát rồi lại giở trò dụ dỗ cho nạn nhân mò vô trang web đấy. Việc này có thể thực hiện thông qua các kênh “truyền thống” như gửi link cho nạn nhân qua email/message.

Đến đây tôi cũng xin kết thúc màn giới thiệu dạo đầu cho CSRF attack. Trong các kỳ tiếp theo, tôi sẽ minh họa cho các kịch bản tấn công phức tạp hơn.

3 thoughts on “Penetration Testing Step 3 – Nhập môn Cross-site Request Forgery – CSRF attack”

Leave a Reply

Your email address will not be published. Required fields are marked *