NỘI DUNG
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 ý:
- Như mọi khi, tôi cũng sẽ tận dụng các bài Lab dựng sẵn của ông PortSwigger để tiết kiệm thời gian dàn cảnh;
- Thông tin liên quan đến Burp Suite bạn có thể xem trong nội dung Penetration Testing Step 3 – 6 điều bạn nên biết trước khi xài tool khủng Burp Suite;
- Chi tiết việc sử dụng Burp Suite Repeater bạn có thể xem trong nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater;
#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.
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.
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.
Để thử nghiệm, tôi bật Context menu (bằng chuột phải) rồi chọn 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).
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).
Sau đó tùy chỉnh Options (chọn Include auto-submit script) rồi chọn Generate.
Kết quả tôi thu được sẽ kiểu như sau.
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-csrf-wiener@normal-user.net" />
<input type="hidden" name="csrf" value="hEcNtpYgYQjZ6Dm6WNcAYiAOAU3DH3sJ-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.
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.
#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.
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“.
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.
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.
<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-csrf-wiener@normal-user.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 Store và View Exploit.
Sau đó, tôi có thể rung đùi ngồi lại kiểm tra “thành quả lao động” của mình.
Đế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”