Penetration Testing Step 3 – CSRF attack – Hồi thứ nhất

Như đã đề cập trong nội dung Penetration Testing Step 3 – Nhập môn Cross-site Request Forgery – CSRF attack, kỳ này tôi sẽ đi sâu vào minh họa các kịch bản tấn công điển hình với Cross-site Request Forgery – CSRF.

Trong phần lớn các tình huống, CSRF vulnerability xuất phát từ sai lầm trong việc xác minh CSRF token (như ví dụ kì trước là đỉnh cao của sai lầm vì chẳng có cái CSRF token nào cả, mọi sự an nguy đều trong cậy vào mỗi cái session handling cookie mong manh dễ vỡ).

Vì các kịch bản tấn công điển hình với Cross-site Request Forgery – CSRF cũng tương đối dài nên tôi phải tạm chia các nội dung ra một số kỳ. Trong kỳ này, tôi sẽ tập trung vào hai tình huống xử lý lỗi bao gồm:

  • Xác minh CSRF token dựa vào request method;
  • Xác minh CSRF token dựa vào sự có mặt của token;

Lưu ý:

#1. CSRF attack trong tình huống mục tiêu xác minh CSRF token dựa vào request method

Thông thường, các thao tác đẩy dữ liệu lên (ví dụ thay đổi email trong kỳ trước) sẽ được triển với POST request. Do vậy, một số đại ca xây dựng và quản lý ứng dụng có thể nảy ra “tối kiến” là chỉ triển việc xác minh CSRF token với POST request và kệ mịa cái GET request. Cái “tối kiến” đấy chỉ có thể phù hợp với “người thường”, với attacker, chuyện thay đổi request method để né tránh việc kiểm soát với CSRF token là “chuyện thường ngày”.

Tôi sẽ múc ngay phần demo để bạn thấy việc này nó diễn ra như thế nào.

Đầu tiên, tôi cũng đăng nhập với credentials được cung cấp như mọi khi (wiener:peter) rồi chạy các chức năng Update email.

Update email function
Update email function

Tiếp đến, tôi hốt cái request tương ứng cho việc cập nhật email quăng qua Burp Suite Repeater.

Update email request
Update email request

Tại đây, nếu thử đổi cái CSRF token (tôi thử thêm “-1“) tôi sẽ bị chửi “Invalid CSRF token” vì xài hàng đểu.

Modified update email request
Modified update email request

Để thử nghiệm, tôi bật Context menu (bằng chuột phải) rồi chọn Change request method.

Change request method
Change request method

Như quan sát ở bên dưới, lúc này request method đã chuyển từ POST sang GET (kèm theo các thay đổi tương ứng) và response đã trả về status code 302 nhẹ nhàng tình cảm dù tôi vẫn dí vào cái CSRF token đểu (tức là với GET request, tôi gửi cái CSRF token gì cũng không quan trọng vì ứng dụng nó cũng chả quan tâm).

Update email GET request
Update email GET request

Công việc kế tiếp tương tự như kỳ trước, từ Context menu, tôi có thể mở Engagement tools à Generate CSRF PoC (nếu dùng bản Burp Suite Professional).

Generate CSRF PoC
Generate CSRF PoC

Sau đó tùy chỉnh Options (chọn Include auto-submit script) rồi chọn Generate.

Generate CSRF PoC options
Generate CSRF PoC options

Kết quả tôi thu được sẽ kiểu như sau.

Generate CSRF PoC result
Generate CSRF PoC result

Và tất nhiên, bạn cũng có thể dùng cái template sau đây để xử lý thủ công nếu sử dụng Burp Suite Community Edition.

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

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

</form>

<script>

        document.forms[0].submit();

</script>

Hoặc tận dụng hàng sáng tác bởi cái Generate CSRF PoC rồi mông má lại cho phù hợp.

<html>

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

  <body>

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

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

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

      <input type="hidden" name="csrf" value="hEcNtpYgYQjZ6Dm6WNcAYiAOAU3DH3sJ&#45;1" />

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

    </form>

    <script>

      document.forms[0].submit();

    </script>

  </body>

</html>

Tôi cũng đẩy cái đống nói trên vô Body section bên Exploit Server rồi chọn Store.

Exploit Server
Exploit Server

Cũng lại như kỳ trước, tôi chọn View exploit rồi kiểm tra thông tin coi hàng chạy ngon hay không trước khi “giao” đến cho các nạn nhân.

Updated email
Updated email

#2. CSRF attack trong tình huống mục tiêu xác minh CSRF token dựa vào sự có mặt của token

Với kịch bản này, ứng dụng sẽ “ứng xử” kiểu “Ai muốn xác minh thì đưa CSRF token đây cho anh xác minh, còn không đưa thì …thôi khỏi xác minh!“. Dù nghe hơi hư cấu nhưng nếu may mắn, tôi vẫn có thể bắt gặp những ứng dụng chơi kiểu này.

Vẫn như cũ, tôi đăng nhập vào ứng dụng và chạy chức năng Update email rồi tém cái request cập nhật email quẳng qua Burp Suite Repeater.

Update email request
Update email request

Cũng như tình huống trước đó, nếu mông má lại cái CSRF token rồi gửi request thì tôi sẽ ăn chửi “Invalid CSRF token“.

Modified update email request
Modified update email request

Tuy nhiên, nếu tôi mạnh dạn cắt phéng cái của nợ (CSRF token) thì mọi chuyển bỗng trở nên êm đẹp một cách khó tin.

Update email request without CSRF
Update email request without CSRF

Câu chuyện tiếp theo cũng không khác gì kịch bản trước đó (trừ việc tôi sẽ triệt phần liên quan đến cái CSRF token trong request) nên tôi không diễn giải chi tiết nữa. Bạn có thể thao tác tương tự như bên dưới.

Generate CSRF PoC result
Generate CSRF PoC result

<html>

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

  <body>

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

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

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

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

    </form>

    <script>

      document.forms[0].submit();

    </script>

  </body>

</html>

Tôi cũng đẩy hàng vào phần Body trên Exploit server rồi StoreView Exploit.

Exploit Server
Exploit Server

Sau đó, tôi có thể rung đùi ngồi lại kiểm tra “thành quả lao động” của mình.

Updated email
Updated email

Đến đây, tôi cũng xin tạm dừng hồi thứ nhất của phần demo CSRF attack. Hẹn gặp lại bạn trong các kỳ tiếp theo.

2 thoughts on “Penetration Testing Step 3 – CSRF attack – Hồi thứ nhất”

Leave a Reply

Your email address will not be published.