[Tấn Công CSRF Là Gì] – Cách chống tấn công giả mạo | Vietnix

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

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

Việc tạo HTML cho CSRF là điều thiết yếu nhưng tương đối phức tạp, đặc biệt quan trọng là khi request mong ước chứa nhiều tham số. Cách đơn thuần nhất là sử dụng trình tạo CSRF PoC được tích hợp sẵn trong Burp Suite Professional :

• Chọn một request ở bất kỳ đâu trong Burp Site Professioanl để test hoặc exploit.
• Click chuột phải vào context menu, chọn Engagement tools / Generate CSRF PoC.
• Burp Suite sau đó sẽ tạo một số HTML để trigger các request đã chọn (ngoại trừ cookies – sẽ được trình duyệt của nạn nhân tự động thêm vào).
• Ta có thể điều chỉnh nhiều tùy chọn khác nhau trong CSRF PoC Generator nhằm chỉnh sửa một số khía cạnh khác của cuộc tấn công. Đặc biệt là với các request lạ.
• Copy HTML đã được tạo vào một trang web, xem nó trong trình duyệt được đăng nhập vào trang web dễ bị tấn công. Sau đó kiểm tra xem request dự kiến có được đưa ra thành công hay không, và xem hành động mong muốn có xảy ra không.

Cách phân phối khai thác CSRF

Các chính sách phân phối cho cuộc tiến công này về cơ bản giống như XSS. Thông thường, hacker sẽ đặt HTML vào một website mà chúng trấn áp. Sau đó lôi kéo nạn nhân truy vấn vào website đó. Chúng hoàn toàn có thể phân phối cho người dùng những link đến trang, qua email hoặc tin nhắn trên mạng xã hội. Đôi khi tiến công CSRF hoàn toàn có thể được đặt ở những trang thông dụng ( ví dụ điển hình như phần comment của người dùng ). Khi đó, những hacker chỉ cần “ há miệng chờ sung ” đợi người dùng truy vấn vào .
Lưu ý rằng, 1 số ít khai thác CSRF đơn thuần sử dụng chiêu thức GET, và hoàn toàn có thể trọn vẹn độc lập với một URL duy nhất trên website dễ bị tiến công. Khi đó, hacker không thiết yếu phải sử dụng website bên ngoài mà hoàn toàn có thể trực tiếp cung ứng những một URL ô nhiễm trên domain dễ bị tiến công .
Trong ví dụ trước, nếu request biến hóa địa chỉ email hoàn toàn có thể được thực thi bằng chiêu thức GET, thì một cuộc tiến công khép kín sẽ có dạng như sau :

Cách ngăn chặn tấn công CSRF

Cách mạnh mẽ nhất để có thể chống tấn công CSRF chính là có thêm các CSRF token bên trong những request liên quan. Token này nên:

• Khó đoán, có entropy cao, như đối với các session token nói chung.
• Bị ràng buộc với user session.
• Được xác thực 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.

Bên cạnh đó, ta cũng hoàn toàn có thể sử dụng SamSite cookies để chống bị tiến công. Đây là một chiêu thức khá hiệu suất cao và hoàn toàn có thể được sử dụng cùng với CSRF token .

Các lỗ hổng CSRF phổ biến hiện nay

Hầu hết mọi lỗ hổng đều phát sinh do sai sót trong quy trình xác nhận CSRF token .
Trong ví dụ trước, giả sử rằng ứng dụng gồm có cả CSRF token trong request để biến hóa password của người dùng :

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&[email protected]

Khi đó, ta hoàn toàn có thể chống được CSRF, vì nó vi phạm những điều kiện kèm theo thiết yếu để có thực thực thi tiến công : Ứng dụng giờ đây không chỉ dựa vào mỗi cookies để giải quyết và xử lý session nữa. Đồng thời, request cũng chứa một tham số mà kẻ tiến công không hề xác lập được .
Tuy nhiên, vẫn còn có nhiều cách khác để những hacker hoàn toàn có thể phá vỡ lớp bảo vệ. Tức là ứng dụng vẫn hoàn toàn có thể bị tiến công bởi CSRF .

Xác thực mã thông báo CSRF phụ thuộc vào phương thức yêu cầu

Nhiều ứng dụng hoàn toàn có thể xác nhận đúng token khi request sử dụng giải pháp POST. Nhưng lại bỏ lỡ nó với chiêu thức GET .
Khi đó, hacker hoàn toàn có thể chuyển sang chiêu thức GET để bypass xác nhận, rồi gửi một cuộc tiến công :

GET /email/[email protected] HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

Xác thực mã thông báo CSRF phụ thuộc vào mã thông báo hiện có

Một số ứng dụng xác nhận đúng token khi nó hiện hữu, nhưng lại bỏ lỡ xác nhận nếu không có token. Khi đó, hacker hoàn toàn có thể xóa hàng loạt tham số chứa token để bypass và triển khai tiến công :

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
[email protected]

Mã thông báo CSRF không bị ràng buộc với session người dùng

Một số ứng dụng không xác nhận token thuộc cùng một phiên với user đang đưa ra request. Thay vào đó, ứng dụng sẽ duy trì một nhóm global, chứa những token đã được phát hành. Và sẽ đồng ý bất kể token nào ở trong nhóm này .

Khi đó, các hacker 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ệ, rồi cung cấp token đó cho nạn nhân trong tấn công.

Mã thông báo CSRF được liên kết với một cookie không phải session

Trong 1 số ít biến thể của lỗ hổng bảo mật thông tin ở trên, vài ứng dụng link token CSRF với một cookie. Nhưng nó không được link với cookie dùng để theo dõi session. Đặc biệt là khi một ứng dụng sử dụng hai framework khác nhau – một dùng để giải quyết và xử lý session, và một để bảo vệ. Hai framework này không được tích hợp cùng với nhau :

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&[email protected]

Mặc dù trường hợp này khó khai thác hơn, nhưng không phải là trọn vẹn miễn nhiễm với CSRF. Nếu website có chứa bất kể hành vi nào được cho phép hacker đặt cookie trong trình duyệt của nạn nhân, thì vẫn hoàn toàn có thể bị tiến công. Các hacker hoàn toàn có thể đăng nhập vào ứng dụng bằng thông tin tài khoản của họ, lấy token hợp lệ cùng với cookie được link. Sau đó tận dụng hành vi thiết lập cookie để đặt cookie vào trình duyệt của nạn nhân. Rồi từ đó cung ứng token cho nạn nhân trong tiến công CSRF .

Lưu ý: Hành vi thiết lập cookie không cần phải tồn tại trong cùng một ứng dụng web. Mọi ứng dụng khác ở trong cùng một domain DNS có thể được dùng để đặt cookie trong ứng dụng mục tiêu. Chỉ cần cookie được kiểm soát có phạm vi phù hợp.

Lấy ví dụ, một chức năng thiết lập cookie trên staging.demo.normal-website.com có thể được dùng để đặt cookie được gửi đến secure.normal-website.com.

Mã thông báo CSRF chỉ đơn giản được sao chép trong một cookie

Ở những phần trên, một số ít ứng dụng không duy trì bất kể bản ghi phía server nào về những token đã được phát hành. Mà thay vào đó là sao chép từng token bên trong một cookie và tham số request. Khi request tiếp theo được xác nhận, ứng dụng chỉ cần xác định rằng token được gửi trong tham số request khớp với giá trị trong cookie. Đây được gọi là giải pháp “ double summit ” để chống tiến công CSRF. Nó cũng là một giải pháp tương đối dễ triển khai, không cần trạng thái ở phía server :

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&[email protected]

Tương tự, ở trường hợp này, hacker hoàn toàn có thể triển khai tiến công CSRF laravel nếu website có bất kể tính năng setup cookie nào. Các hacker không cần lấy token hợp lệ nữa, mà chỉ cần tạo ra một token ( hoàn toàn có thể ở định dạng nhất định nếu cần được check ), tận dụng hành vi thiết lập cookie để đặt cookie vào trong trình duyệt của nạn nhân. Từ đó cung ứng token cho họ trong CSRF .

Ví dụ về cách tấn công CSRF

Trước khi triển khai CSRF attack, những hacker thường nghiên cứu và điều tra một ứng dụng để tạo những request trá hình. Nhưng tất yếu là phải trông hợp lệ nhất hoàn toàn có thể .
Chẳng hạn, dưới đây là một GET request để giao dịch chuyển tiền 100 USD :

GET http://netbank.com/transfer.do?acct=PersonalB&amount=$100 HTTP/1.1

Hoặc script trên hoàn toàn có thể được chỉnh sửa một chút ít. Chẳng hạn nếu hacker muốn chuyển 100 USD vào thông tin tài khoản của chúng, thì request sẽ có dạng như sau :

GET http://netbank.com/transfer.do?acct=AttackerA&amount=$100 HTTP/1.1

tin tặc cũng hoàn toàn có thể nhúng request vào một hyperlink khác :

Read more!

Tiếp đến, chúng hoàn toàn có thể phân phối hyperlink này qua email đến một lượng lớn người mua của ngân hàng nhà nước. Những người click vào link trong khi đăng nhập vào thông tin tài khoản ngân hàng nhà nước sẽ vô tình chuyển 100 USD cho hacker .

Cần lưu ý rằng, nếu trang web của ngân hàng chỉ sử dụng các POST request, thì việc tạo các frame độc hại bằng tag href là không thể. Tuy nhiên, các cuộc tấn công vẫn có thể được phân phối trong tag

với việc tự động thực thi JavaScript được nhúng.

Khi đó, script sẽ có dạng như sau :

Lời kết

Hy vọng bài viết trên sẽ giúp bạn đọc hiểu được CSRF là gì? Cách chống tấn công CSRF một cách tốt nhất. Nếu có thắc mắc hay đóng góp ý kiến, mời bạn bình luận phía dưới bài viết. Vietnix xin chân thành cảm ơn.

5/5 – ( 1 bầu chọn )