🔏Cross-site request forgery (CSRF)
Client Side Vul
Last updated
Client Side Vul
Last updated
CSRF hay còn gọi là kỹ thuật tấn công “Cross-site Request Forgery“, nghĩa là kỹ thuật tấn công giả mạo chính chủ thể của nó. CSRF nói đến việc tấn công vào chứng thực request trên web thông qua việc sử dụng Cookies. Đây là nơi mà các hacker có khả năng sử dụng thủ thuật để tạo request mà bạn không hề biết. Vì vậy, một CSRF là hacker lạm dụng sự tin tưởng của một ứng dụng web trên trình duyệt của nạn nhân.
Trong một cuộc tấn công CSRF thành công, kẻ tấn công gây cho nạn nhân tiến hành các hoạt động khoog có ý định từ trước.
Ví dụ: điều này có thể là thay đổi địa chỉ email trên tài khoản của họ, thay đổi mật khẩu của họ hoặc thực hiện chuyển tiền. Tùy thuộc vào bản chất của hành động, kẻ tấn công có thể có toàn quyền kiểm soát tài khoản của người dùng. Nếu người dùng bị xâm phạm có vai trò đặc biệt trong ứng dụng, thì kẻ tấn công có thể có toàn quyền kiểm soát tất cả dữ liệu và chức năng của ứng dụng.
Một hành động có liên quan. Có một hành động trong ứng dụng mà kẻ tấn công có lý do để gây ra. Đây có thể là một hành động đặc quyền (chẳng hạn như sửa đổi quyền cho những người dùng khác) hoặc bất kỳ hành động nào đối với dữ liệu dành riêng cho người dùng (chẳng hạn như thay đổi mật khẩu của chính người dùng).
Xử lý phiên dựa trên cookie. Thực hiện hành động bao gồm việc đưa ra một hoặc nhiều yêu cầu HTTP và ứng dụng chỉ dựa vào cookie phiên để xác định người dùng đã thực hiện yêu cầu. Không có cơ chế nào khác để theo dõi phiên hoặc xác thực yêu cầu của người dùng.
Không có thông số yêu cầu không thể đoán trước. Các yêu cầu thực hiện hành động không chứa bất kỳ tham số nào có giá trị mà kẻ tấn công không thể xác định hoặc đoán được. Ví dụ, khi khiến người dùng thay đổi mật khẩu của họ, chức năng này không dễ bị tấn công nếu kẻ tấn công cần biết giá trị của mật khẩu hiện có.
Cho ví dụ: Giả sử một úng dụng chưa một hàm mà người dùng thay đổi email của tài khoản của họ. Khi đó người dùng thực hiện hành động, sẽ có một HTTP request như sau:
Hành động thay đổi địa chỉ Email trong tài khoản của người dùng được kẻ tấn công quan tâm. Sau hành động này kẻ tấn công sẽ có thực hiện reset lại mật khẩu và kiểm soát hoàn toàn tài khoản của người dùng.
Úng dụng sử dụng một session cookie để nhận dạng người dùng nào đã đưa ra yêu cầu. Không có tokens khác hoặc cơ chế nào khác theo dõi session của người dùng
Kẻ tấn công có thể dễ dàng quyết định giá trị của các giá trị của tham số yêu cầu mà cần được thực hiện thành đông
Với những điều kiện chính thì kẻ tấn công có thể xây dựng một trang web chứa HTML như sau:
Nếu nạn nhân vào trang web của kẻ tấn công thì sẽ xảy ra như sau:
Trang của kẻ tấn công sẽ kích hoạt một HTTP request tới trang web bị lỗi
Nếu người dùng được login vào trang web lỗi, thì trình duyệt của họ sẽ tự động chứa các session cookie của họ trng request
Trang web lỗi sẽ xử lý request theo một cách bình thường và coi nó như một hành động bởi nạn nhân và thay đổi địa chỉ Email của nạn nhân
Note: Mặc dù CSRF thường được mô tả liên quan đến xử lý phiên dựa trên cookie, nhưng nó cũng phát sinh trong các ngữ cảnh khác khi ứng dụng tự động thêm một số thông tin đăng nhập của người dùng vào các yêu cầu, chẳng hạn như xác thực HTTP cơ bản và xác thực dựa trên chứng chỉ.
Tạo thủ công HTML cần thiết cho CSRF để khai thác có thể rất phức tạp, cụ thể nơi mà mong muốn request chưa một lượng lớn số và biến, hoặc những thứ kỳ quặc trong yêu cầu. Các dễ nhất để tạo CSRF exploit là sự dụng CSRF PoC generator trng Burp Suite Pro( bạn có thể crack nó)
Thực tế khi chúng ta tạo CSEF form từ Burp Suite thì nó sẽ có button để nạn nhân ấn nhưng thường các nạn nhân sẽ khó đoán, vậy dùng script để auto submit khi nạn nhân nhấn vào link luôn//////
Các cơ chế truyền cho CSRF về cơ bản giống như đối với Reflected XSS. Thông thường, kẻ tấn công sẽ đặt mã HTML độc hại vào một trang web mà chúng kiểm soát, sau đó lôi kéo nạn nhân truy cập vào trang web đó. Điều này có thể được thực hiện bằng cách cung cấp cho người dùng một liên kết đến trang web, qua email hoặc tin nhắn trên mạng xã hội. Hoặc nếu cuộc tấn công được đặt vào một trang web phổ biến
Lưu ý rằng một số khai thác CSRF đơn giản sử dụng phương pháp GET và có thể hoàn toàn độc lập với một URL duy nhất trên trang web dễ bị tấn công. Trong tình huống này, kẻ tấn công có thể không cần sử dụng trang web bên ngoài và có thể cung cấp trực tiếp cho nạn nhân một URL độc hại trên miền dễ bị tấn công. Trong ví dụ trước, nếu yêu cầu thay đổi địa chỉ email có thể được thực hiện bằng phương thức GET, thì một cuộc tấn công khép kín sẽ giống như sau:
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">
Cách mạnh nhất để chặn lại cuộc tấn công CSRF là bao gồm một CSRF token với các request liên quan. Token phải là:
Không thể đoán trước với entropy cao, như đối với token phiên nói chung.
Bị ràng buộc với session của người dùng.
Được xác nhận nghiêm ngặt trong mọi trường hợp trước khi hành động liên quan được thực hiện.
CSRF token là một giá trị duy nhất, bí mật, không thể đoán trước được tạo bởi ứng dụng phía máy chủ và được truyền đến máy khách theo cách mà nó được đưa vào một yêu cầu HTTP tiếp theo do máy khách thực hiện. Khi yêu cầu sau đó được thực hiện, ứng dụng phía máy chủ xác thực rằng yêu cầu có bao gồm token mong đợi và từ chối yêu cầu nếu token bị thiếu hoặc không hợp lệ.
CSRF token là một giá trị duy nhất, bí mật, không thể đoán trước được tạo bởi ứng dụng phía máy chủ và được truyền đến máy khách theo cách mà nó được đưa vào một yêu cầu HTTP tiếp theo do máy khách thực hiện. Khi yêu cầu sau đó được thực hiện, ứng dụng phía máy chủ xác thực rằng yêu cầu có bao gồm token mong đợi và từ chối yêu cầu nếu token bị thiếu hoặc không hợp lệ.
CSRF token phải chứa entropy đáng kể và rất khó đoán, có các thuộc tính giống như session tokens nói chung
CSRF token phải được coi là bí mật và được xử lý một cách an toàn trong suốt vòng đời của chúng. Một cách tiếp cận thường hiệu quả là truyền token đến máy khách trong trường ẩn của biểu mẫu HTML được gửi bằng phương thức POST. Sau đó, token sẽ được bao gồm dưới dạng tham số yêu cầu khi biểu mẫu được gửi:
<input type="hidden" name="csrf-token" value="CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz" />
Để đảm bảo an toàn hơn, trường chứa CSRF token phải được đặt càng sớm càng tốt trong tài liệu HTML, lý tưởng là trước bất kỳ trường đầu vào không ẩn nào và trước bất kỳ vị trí nào mà dữ liệu do người dùng kiểm soát được nhúng trong HTML. Điều này giảm thiểu các kỹ thuật khác nhau trong đó kẻ tấn công có thể sử dụng dữ liệu được tạo thủ công để thao tác tài liệu HTML và nắm bắt các phần nội dung của nó.
Một cách tiếp cận thay thế, đặt token vào chuỗi truy vấn URL, hơi kém an toàn hơn vì chuỗi truy vấn:
Được đăng nhập ở nhiều vị trí khác nhau ở phía máy khách và máy chủ;
Có trách nhiệm truyền cho các bên thứ ba trong HTTP Referer header;
Có thể được hiển thị trên màn hình trong trình duyệt của người dùng.
Hầu hết các lỗ hổng CSRF phát sinh do sai lầm trong quá trình xác thực CSRF token.
Trong ví dụ trước, giả sử rằng ứng dụng hiện bao gồm CSRF token trong yêu cầu thay đổi e-mail của người dùng:
Điều này phải ngăn chặn các cuộc tấn công CSRF vì nó vi phạm các điều kiện cần thiết cho lỗ hổng CSRF: ứng dụng không còn chỉ dựa vào cookie để xử lý phiên và yêu cầu chứa một tham số mà giá trị của kẻ tấn công không thể xác định. Tuy nhiên, có nhiều cách khác nhau mà lớp bảo vệ có thể bị phá vỡ, có nghĩa là ứng dụng vẫn dễ bị tấn công bởi CSRF.
Một số ứng dụng xác thực đúng token khi yêu cầu sử dụng phương thức POST nhưng bỏ qua xác thực khi phương thức GET được sử dụng.
Trong tình huống này, kẻ tấn công có thể chuyển sang phương thức GET để bỏ qua xác thực và thực hiện một cuộc tấn công CSRF:
Một số ứng dụng xác thực chính xác token khi nó hiện diện nhưng bỏ qua xác thực nếu token bị bỏ qua.
Trong tình huống này, kẻ tấn công có thể xóa toàn bộ tham số chứa token (không chỉ giá trị của nó) để bỏ qua xác thực và thực hiện một cuộc tấn công CSRF:
Một số ứng dụng không xác thực rằng token thuộc cùng một session với người dùng đang thực hiện yêu cầu. Thay vào đó, ứng dụng duy trì một nhóm token toàn cầu mà nó đã phát hành và chấp nhận bất kỳ token nào xuất hiện trong nhóm này.
Trong tình huống này, kẻ tấn công có thể đăng nhập vào ứng dụng bằng tài khoản của chính họ, lấy token hợp lệ và sau đó cung cấp token đó cho người dùng nạn nhân trong cuộc tấn công CSRF của chúng.
Vì nó không liên quan tới Session người dùng nên mỗi lần thay đổi email thì CSRF Token lại thành một mã mới. Nên chúng ta cần dùng token trung với email mà chúng ta thay đổi để gửi cho nạn nhân
Trong một biến thể của lỗ hổng bảo mật trước đó, một số ứng dụng gắn CSRF Token với một cookie, nhưng không gắn với cùng một cookie được sử dụng để theo session. Điều này có thể dễ dàng xảy ra khi một ứng dụng sử dụng hai khuôn khổ khác nhau, một để xử sesion và một để bảo vệ CSRF, không được tích hợp với nhau:
Tình trạng này khó khai thác hơn nhưng vẫn dễ có lỗ hổng . Nếu trang web chứa bất kỳ hành vi nào cho phép kẻ tấn công đặt cookie trong trình duyệt của nạn nhân, thì một cuộc tấn công có thể xảy ra. Kẻ tấn công có thể đăng nhập vào ứng dụng bằng tài khoản của chính họ, lấy mã thông báo hợp lệ và cookie được liên kết, tận dụng hành vi thiết lập cookie để đặt cookie của chúng vào trình duyệt của nạn nhân và cung cấp mã thông báo của chúng cho nạn nhân trong cuộc tấn công CSRF của chúng.
NOTE
Quan sát rằng nếu bạn hoán đổi csrfKeycookie và csrftham số từ tài khoản đầu tiên sang tài khoản thứ hai, yêu cầu được chấp nhận.
Quay lại trình duyệt ban đầu, thực hiện tìm kiếm, gửi yêu cầu kết quả đến Burp Repeater và quan sát rằng cụm từ tìm kiếm được phản ánh trong tiêu đề Set-Cookie. Vì chức năng tìm kiếm không có bảo vệ CSRF, bạn có thể sử dụng chức năng này để đưa cookie vào trình duyệt của người dùng nạn nhân. (Dùng Set-Cookie)
Trong một biến thể khác trong lỗ hổng trước đó, một số ứng dụng không duy trì bất kỳ bản ghi phía máy chủ nào về token đã được phát hành, mà thay vào đó sao chép từng mã thông báo trong cookie và tham số yêu cầu. Khi yêu cầu tiếp theo được xác thực, ứng dụng chỉ cần xác minh rằng mã thông báo được gửi trong tham số yêu cầu khớp với giá trị được gửi trong cookie. Điều này đôi khi được gọi là biện pháp bảo vệ "double submit" chống lại CSRF và được ủng hộ vì nó dễ thực hiện và tránh sự cần thiết của bất kỳ trạng thái phía máy chủ nào:
Trong trường hợp này, kẻ tấn công có thể thực hiện lại một tấn công CSRF nếu trang web chưa bất kỳ chức năng cài đặt cookie nào. Ở đây, kẻ tấn công không cần lấy token hợp lệ của riêng họ. Họ chỉ cần tạo một token , tận dụng hành vi cài đặt cookie để đặt cookie của họ vào trình duyệt của nạn nhân và cung cấp token của họ cho nạn nhân trong cuộc tấn công CSRF của họ.
NOTE:
Kiểm tra csrf của cookie và csrf có bằng nhau hay không
Thay đổi cả hai csrf của cookie và csrf giống như nhau gửi lại khi đó email được đổi thành công => dính CRSF | /?search=test%0d%0aSet-Cookie:%20csrf=fake
Ngoài các biện pháp bảo vệ CSRF Token, một vài ứng dụng sử dụng HTTP Referer Header để có gắng ngăn chặn lại tấn công CSRF, bình thường kiếm trả lại rằng request bắt đầu từ domain riêng của ứng dụng.
Một số ứng dụng xác thực Referer header khi nó xuất hiện trong các yêu cầu nhưng bỏ qua xác thực nếu tiêu đề bị bỏ qua.
Trong tình huống này, kẻ tấn công có thể khai thác CSRF của họ theo cách khiến trình duyệt của người dùng nạn nhân thả Refererheader trong yêu cầu kết quả. Có nhiều cách khác nhau để đạt được điều này, nhưng cách dễ nhất là sử dụng thẻ META trong trang HTML lưu trữ cuộc tấn công CSRF:
Một số ứng dụng xác nhận Referertiêu đề theo cách ngây thơ có thể bị bỏ qua. Ví dụ: nếu ứng dụng xác thực rằng miền trong phần Refererbắt đầu bằng giá trị mong đợi, thì kẻ tấn công có thể đặt nó làm miền phụ của miền riêng của chúng:
Tương tự như vậy, nếu ứng dụng chỉ đơn giản xác nhận rằng Referercó chứa tên miền riêng của nó, thì kẻ tấn công có thể đặt giá trị bắt buộc ở nơi khác trong URL:
Note:
Mặc dù bạn có thể xác định hành vi này bằng cách sử dụng Burp, bạn sẽ thường thấy rằng phương pháp này không còn hoạt động khi bạn kiểm tra bằng chứng khái niệm của mình trong trình duyệt. Trong một nỗ lực để giảm nguy cơ dữ liệu nhạy cảm bị rò rỉ theo cách này, nhiều trình duyệt hiện đã loại bỏ chuỗi truy vấn khỏi Referertiêu đề theo mặc định.
Bạn có thể ghi đè hành vi này bằng cách đảm bảo rằng phản hồi chứa phần khai thác của bạn có bộ Referrer-Policy: unsafe-url tiêu đề (lưu ý Referrer trong trường hợp này viết đúng chính tả, chỉ để đảm bảo rằng bạn đang chú ý!). Điều này đảm bảo rằng URL đầy đủ sẽ được gửi, bao gồm cả chuỗi truy vấn.
Các bạn có thể tìm hiểu history.pushState làm gì ở đây.
Cảm ơn các bạn đã đọc bài.....
