Trainning
  • WEEK 2
    • Tìm hiểu các thành phần hệ điều hành
    • TryHackMe| Abusing Windows Internals
  • WEEK 3
    • Một số phương thức Persistence
    • Các Phương thức tấn công Process nâng cao
    • Implement tấn công
  • week 4
    • Linux
      • Basic Concept Linux
      • Symlink
      • Linux Persistence
      • Notes
    • PROCESS LIST
    • Network
      • OSI MODEL(OPEN SYSTEMS INTERCONNECTION MODEL)
      • Các giao thức phổ biến trong môi trường enterprise
        • SMB - Server Message Block
        • LDAP - Lightweight Directory Access Protocol
          • LDAP Injection
        • SSH - Secure Shell
        • RDP - Remote Desktop Protocol
        • ICMP - Internet Control Message Protocol
        • DNS - Domain Name System
        • DHCP - Dynamic Host Configuration Protocol
        • HTTP/HTTPS
  • WEEK 5
    • Các dạng tấn công trong network phổ biến (SYNC Flood, MAC flood,...)
    • Reconnaissance
    • Active Directory
      • Group Policy
    • NTLM vs Kerberos
      • Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks
      • Path The Hash
      • ASREPRoast
        • Demo
      • Kerberoasting
        • Demo
      • Silver Ticket
        • Demo
      • Golden Ticket
        • Demo
      • Tóm tắt
    • Stealing Windows Credentials
      • Mimikatz
      • Custom SSP
    • LLMNR Poisoning, NTLM Replay
  • WEEK 6 + 7
    • DOM-based vulnerabilities
      • DOM-based open redirection
    • SQL Injection
      • Lab: Retrieving hidden data
      • Lab: Subvering application logic
      • SQL injection UNION attacks
        • Lab: SQL injection UNION attack, determining the number of columns returned by the query
        • Lab: SQL injection UNION attack, finding a column containing text
        • Lab: SQL injection UNION attack, retrieving data from other tables
        • Lab: SQL injection UNION attack, retrieving multiple values in a single column
      • Blind SQL Injection
        • Lab: Blind SQL injection with conditional responses
        • Lab: Blind SQL injection with conditional errors
        • Lab: Visible error-based SQL injection
        • Lab: Blind SQL injection with time delays
        • Lab: Blind SQL injection with time delays and information retrieval
        • Lab: Blind SQL injection with out-of-band interaction
        • Lab: Blind SQL injection with out-of-band data exfiltration
      • Examining the database
        • Lab: SQL injection attack, querying the database type and version on Oracle
        • Lab: SQL injection attack, querying the database type and version on MySQL and Microsoft
        • Lab: SQL injection attack, listing the database contents on non-Oracle databases
        • Lab: SQL injection attack, listing the database contents on Oracle
      • Che dấu cuộc tấn công bằng Encode
        • Lab: SQL injection with filter bypass via XML encoding
    • Authentication
      • Lỗ hổng trong đăng nhập bằng mật khẩu
        • Lab: Username enumeration via different responses
        • Lab: Username enumeration via subtly different responses
        • Lab: Username enumeration via response timing
        • Lab: Broken brute-force protection, IP block
        • Lab: Username enumeration via account lock
        • Lab: Broken brute-force protection, multiple credentials per request
      • Lỗ hổng trong xác thực đa nhân tố
        • Lab: 2FA simple bypass
        • Lab: 2FA broken logic
        • Lab: 2FA bypass using a brute-force attack
      • Các lỗ hổng trong cơ chế xác thực khác
        • Lab: Brute-forcing a stay-logged-in cookie
        • Lab: Offline password cracking
        • Lab: Password reset broken logic
        • Lab: Password brute-force via password change
        • Lab: Password brute-force via password change
      • Lỗ hổng xác thực OAuth 2.0
        • Lab: Authentication bypass via OAuth implicit flow
        • Lab: Authentication bypass via OAuth implicit flow
        • Lab: Forced OAuth profile linking
        • Lab: OAuth account hijacking via redirect_uri
        • Lab: Stealing OAuth access tokens via an open redirect
        • Lab: Stealing OAuth access tokens via a proxy page
        • Lab: SSRF via OpenID dynamic client registration
    • Access Control
      • Lab: Unprotected admin functionality
      • Lab: Unprotected admin functionality with unpredictable URL
      • Lab: User role controlled by request parameter
      • Lab: User role can be modified in user profile
      • Lab: URL-based access control can be circumvented
      • Lab: Method-based access control can be circumvented
      • Lab: User ID controlled by request parameter
      • Lab: User ID controlled by request parameter, with unpredictable user IDs
      • Lab: User ID controlled by request parameter with data leakage in redirect
      • Lab: Insecure direct object references
      • Lab: Multi-step process with no access control on one step
      • Lab: Referer-based access control
    • Path Traversal
      • Lab: File path traversal, simple case
      • Lab: File path traversal, traversal sequences blocked with absolute path bypass
      • Lab: File path traversal, traversal sequences stripped non-recursively
      • Lab: File path traversal, traversal sequences stripped with superfluous URL-decode
      • Lab: File path traversal, validation of start of path
      • Lab: File path traversal, validation of file extension with null byte bypass
    • Command Injection
      • Lab: OS command injection, simple case
      • Lab: Blind OS command injection with time delays
      • Lab: Blind OS command injection with output redirection
      • Lab: Blind OS command injection with out-of-band interaction
      • Lab: Blind OS command injection with out-of-band data exfiltration
    • File uploads
    • Server-side request forgery (SSRF)
    • Cross-site scripting
      • Reflected XSS
      • Stored XSS
      • DOM-based XSS
      • Cross-site scripting contexts
    • Cross-site request forgery (CSRF)
      • Bypassing CSRF token validation
      • Bypass SameSite cookie restrictions
      • Page 2
    • Insecure deserializaton
    • Burp Suite
    • Tóm tắt
  • Week 8
    • Rà soát mã độc
Powered by GitBook
On this page
  • Khái niệm
  • Tác động
  • Cách thức hoạt động
  • Cách xây dựng một cuộc tấn công CSRF
  • Cách phân phối một CSRF exploit
  • XSS và CSRF
  • Các biện pháp phòng thủ phổ biến chống lại CSRF:
  • Ngăn chặn
  • Sử dụng CSRF token
  • Sử dụng các hạn chế Strict SameSite cookie:
  • Cẩn trọng với tấn công cùng site, khác nguồn:
  1. WEEK 6 + 7

Cross-site request forgery (CSRF)

PreviousCross-site scripting contextsNextBypassing CSRF token validation

Last updated 7 months ago

Khái niệm

CSRF là lỗ hổng bảo mật web cho phép kẻ tân công dụ dỗ người dùng thực hiện các hành động mà họ không chủ ý thực hiện. Nó cho phép kẻ tấn công phá vỡ phần nào chính sách same origin policy, được thiết kế để ngăn chặn các trang web khách nhau can thiệp lẫn nhau

Tác động

Trong một cuộc tấn công CSRF thành công, kẻ tấn công khiến người dùng nạn nhân thực hiện một hành động vô ý (có thể là thay đổi email, mật khẩu hoặc thực hiện chuyển tiền). Một số hành động ấy còn giúp cho kẻ tấn công có thể giành quyền kiểm soát hoàn toàn đối với tài khoản người dùng. Nếu người dùng bị xâm phạm có đặc quyền trong ứng dụng, thì kẻ tấn công có thể giành được quyền kiểm soát hoàng toàn đối với tất cả dữ liệu và chức năng của ứng dụng

Cách thức hoạt động

3 điều kiện chính phải có của một cuộc tấn công CSRF:

  • Một hành động có liên quan (Thay đổi đặc quyền người dùng/ Thay đổi mật khẩu email của người dùng ...)

  • Xử lý phiên dựa trên cookie (Ứng dụng chỉ dựa vào cookie phiến để xác định người dùng nào đã thực hiện các yêu cầu, không có cơ chế khác để theo dõi phiên và xác thực yêu cầu của người dùng)

  • Không có tham số yêu cầu không thể đoán được (Ví dụ như chức năng đổi mật khẩu không yêu cầu nhập mật khẩu hiện tại)

Ví dụ: Chưc năng thay đổi địa chỉ email có HTTP như sau:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com

Điều này đáp ứng các điều kiện cần thiết cho CSRF:

  • Thay đổi địa chỉ email là mối quan tâm của kẻ tấn công -> sau này có thể kích hoạt đặt lại mật khẩu và chiếm tài khoản

  • Ứng dụng chỉ sử dụng cookie phiên để xác định người dùng nao đã đưa ra yêu cầu. Không có token hoặc cơ chế nào khác để theo dõi phiên người dùng

  • Kẻ tấn công có thể dẽ dàng xác định giá trị của các tham số yêu cầu cần thiết để thực hiện hành động

Với những điều kiện này, kẻ tấn công có thể xây dựng một trang web có chứa mã HTML sau:

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

Nếu người dùng nạn nhân truy cập vào trang web của kẻ tấn công:

  • Trang này sẽ kích hoạt HTTP request tới trang web dễ bị tấn công

  • Nếu người dùng đăng nhập vào trang web dẽ bị tấn công, trình duyệt sẽ tự động đưa cookie phiên của họ vào request (Giả sử cookie SameSite không được sử dụng)

  • Trang web dẽ bị tấn công sẽ thực thi request theo cách thông thường, coi yêu cầu đó như được thực hiện bởi người dùng nạn nhân và thay đổi địa chỉ email của họ.

Cách xây dựng một cuộc tấn công CSRF

  • Chọn Yêu Cầu: Trong Burp Suite, chọn yêu cầu HTTP bạn muốn kiểm tra.

  • Tạo PoC CSRF: Nhấp chuột phải vào yêu cầu và chọn Engagement tools / Generate CSRF PoC.

  • Xem và Tinh Chỉnh HTML: Burp Suite tạo HTML để kích hoạt yêu cầu. Tinh chỉnh nếu cần.

  • Kiểm Tra PoC: Sao chép HTML vào một trang web, mở trang trong trình duyệt đã đăng nhập, và kiểm tra kết quả.

Giải pháp:

Đăng nhập và sử dụng chức năng đổi email, quan sát thấy POST request dễ bị tấn công CSRF:

Tạo Payload như sau

<form action="https://0aff004a0497feed803967b9004100cb.web-security-academy.net/my-account/change-email" method="POST">
    <input type="hidden" name="email" value="loile@evil-user.net" />
</form>
<script>
    document.forms[0].submit();
</script>

Trên exploit server Store và Deliver to victim

Cách phân phối một CSRF exploit

Cơ chế phân phối về cơ bản giống như đối với reflected XSS. Thông thường, kẻ tấn công sẽ đặt HTML độc hại vào một website mà chúng điều khiển, và sau đó xúi giục nạn nhân truy cập trang web đó. Điều này có thể thực hiện bằng cách cung cấp cho người dùng một link tới website 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 (ví dụ: trong comment người dùng), chúng có thể chỉ đợi người dùng truy cập vào trang web đó.

Một số cuộc tấn công CSRF đơn giản sử dụng phương thức GET có thể được thực hiện hoàn toàn chỉ với một URL trên trang web dễ bị tấn công. Trong trường hợp này, kẻ tấn công không cần sử dụng trang web bên ngoài mà chỉ cần gửi cho nạn nhân một URL độc hại trực tiếp trên tên miền dễ bị tấn công. Ví dụ, nếu việc thay đổi địa chỉ email có thể thực hiện bằng phương thức GET, cuộc tấn công tự chứa có thể trông như sau:

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

Nạn nhân truy cập URL này sẽ thực hiện hành động thay đổi email mà không cần biết.

XSS và CSRF

Sự khác biệt giữa XSS và CSRF:

  • Cross-Site Scripting (XSS): Cho phép kẻ tấn công thực thi mã JavaScript bất kỳ trong trình duyệt của người dùng bị tấn công.

  • Cross-Site Request Forgery (CSRF): Cho phép kẻ tấn công dẫn dụ người dùng thực hiện các hành động mà họ không có ý định làm.

Hậu quả:

  • XSS nghiêm trọng hơn CSRF.

    • CSRF thường chỉ giới hạn ở một số hành động mà người dùng có thể thực hiện, trong khi XSS có thể khiến người dùng thực hiện bất kỳ hành động nào họ có quyền thực hiện.

    • CSRF là lỗ hổng "một chiều" - kẻ tấn công chỉ có thể gửi yêu cầu nhưng không nhận được phản hồi.

    • XSS là "hai chiều" - mã độc có thể gửi yêu cầu và đọc phản hồi, sau đó gửi dữ liệu ra ngoài.

CSRF tokens có thể ngăn chặn tấn công XSS không?

  • CSRF tokens có thể ngăn chặn một số tấn công XSS (đặc biệt là reflected XSS).

    • Ví dụ: nếu trang yêu cầu một CSRF token hợp lệ để xử lý yêu cầu, việc khai thác lỗ hổng XSS có thể bị chặn.

Lưu ý:

  • Nếu lỗ hổng XSS tồn tại ở bất kỳ nơi nào không có bảo vệ bằng CSRF token, thì lỗ hổng đó vẫn có thể bị khai thác.

  • CSRF tokens không bảo vệ trước XSS lưu trữ (stored XSS), vì mã độc sẽ được thực thi khi người dùng truy cập trang chứa nội dung đã bị chèn mã.

Các biện pháp phòng thủ phổ biến chống lại CSRF:

Hiện nay, việc tìm và khai thác lỗ hổng CSRF thường đòi hỏi phải vượt qua các biện pháp bảo vệ mà trang web hoặc trình duyệt của nạn nhân áp dụng. Các biện pháp phòng thủ phổ biến bao gồm:

  1. CSRF tokens:

    • Là một giá trị bí mật, duy nhất, và không thể đoán trước, được tạo bởi ứng dụng phía server và chia sẻ với client. Khi thực hiện các hành động nhạy cảm như gửi form, client phải gửi kèm CSRF token hợp lệ. Điều này khiến việc tạo ra một yêu cầu hợp lệ thay mặt nạn nhân trở nên rất khó khăn.

  2. SameSite cookies:

    • SameSite là một cơ chế bảo mật trình duyệt kiểm soát khi nào cookie của trang web được bao gồm trong các yêu cầu từ trang khác. Vì các hành động nhạy cảm thường yêu cầu cookie phiên xác thực, việc giới hạn SameSite có thể ngăn kẻ tấn công kích hoạt hành động từ các trang khác. Từ năm 2021, Chrome thực thi hạn chế SameSite Lax mặc định, và các trình duyệt lớn khác có thể sẽ làm tương tự trong tương lai.

  3. Xác thực dựa trên Referer:

    • Một số ứng dụng sử dụng HTTP Referer header để bảo vệ chống lại các cuộc tấn công CSRF, thường bằng cách kiểm tra xem yêu cầu có bắt nguồn từ chính miền của ứng dụng hay không. Tuy nhiên, phương pháp này kém hiệu quả hơn so với xác thực CSRF token.

Ngăn chặn

Sử dụng CSRF token

CSRF token là cách phòng thủ mạnh mẽ nhất để ngăn chặn. Để bảo vệ hiệu quả, CSRF token cần phải:

  • Không thể dự đoán với độ entropy cao

  • Liên kết với phiên của người dùng

  • Được xác thực nghiêm ngặt trước khi thực hiện hành động liên quan.

Các tạo CSRF token:

  • Nên sử dụng trình tạo số giả ngẫu nhiên an toàn về mặt mật mã (CSPRNG) và kết hợp với timestamp khi token được tạo ra cùng một bí mật tĩnh.

  • Để tăng cường bảo mật, có thể thêm entropy cụ thể của người dùng và sử dụng hàm băm mạnh để tạo token

Cách truyền CSRF token:

  • Token nên được truyền qua một trường ẩn (hidden field) trong form HTML dùng phương thức POST. Ví dụ:

<input type="hidden" name="csrf-token" value="CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz" />

  • Token không nên được truyền qua chuỗi truy vấn URL vì nó có thể bị ghi lại hoặc chia sẻ không an toàn.

  • Một số ứng dụng có thể truyền CSRF tokens qua custom headers, giúp bảo vệ thêm khỏi kẻ tấn công.

Cách xác thực CSRF token:

  • Token phải được lưu trữ phía server trong dữ liệu phiên của người dùng và được xác thực khi yêu cầu tiếp theo cần được thực hiện

  • Nếu yêu cầu không chứa token hoặc token không hợp lệ, yêu cầu đó phải bị từ chối

Sử dụng các hạn chế Strict SameSite cookie:

  • Ngoài việc triển khai xác thực token CSRF mạnh mẽ, cần thiết lập rõ ràng các hạn chế SameSite với mỗi cookie được phát hành. Điều này cho phép kiểm soát ngữ cảnh mà cookie được sử dụng, bất kể trình duyệt nào.

  • Mặc dù các trình duyệt có thể mặc định sử dụng chính sách "Lax-by-default", nhưng chính sách này không phù hợp cho mọi loại cookie và có thể dễ dàng bị vượt qua hơn so với Strict.

  • Strict nên được sử dụng mặc định và chỉ nên giảm xuống Lax nếu có lý do cụ thể. Không nên vô hiệu hóa SameSite với SameSite=None trừ khi hiểu rõ các tác động bảo mật.

Cẩn trọng với tấn công cùng site, khác nguồn:

SameSite bảo vệ tốt khỏi các tấn công giữa các trang web khác nhau nhưng không bảo vệ được các cuộc tấn công cùng site nhưng khác nguồn. Vì vậy, nên cách ly nội dung không an toàn (ví dụ như file tải lên của người dùng) trên một trang riêng biệt để bảo vệ dữ liệu nhạy cảm.

Sử dụng của

👍
CSRF PoC generator
Burp Suite Professional
Bypassing CSRF token validation
LogoLab: CSRF vulnerability with no defenses | Web Security AcademyWebSecAcademy