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

Hiện nay có rất nhiều kiểu tấn công mạng khác nhau và ngày càng phong phú, phổ biến, khó chống lại hơn. Trong đó có CSRF, một kiểu tấn công giả mạo chủ thể nguy hiểm. Để hiểu rõ hơn CSRF là gì và làm sao để chống được các cuộc tấn công này, hãy cùng Vietnix tìm hiểu trong bài viết sau đây.

CSRF là gì?

CSRF được biết đến dưới nhiều cái tên khác nhau – Cross site request forgery (CSRF – XSRF), Sea Surf hay là Session Riding. Đây là một vector tấn công, có khả năng đánh lừa trình duyệt web thực hiện các hoạt động không mong muốn trong ứng dụng người dùng đã đăng nhập.

Một cuộc tiến công trá hình chính chủ thể sẽ gây hậu quả nghiêm trọng cho những doanh nghiệp lẫn người dùng. Cụ thể là dẫn đến những hoạt động giải trí chuyển tiền trái phép, đổi khác mật khẩu, đánh cắp tài liệu – gồm cả những session cookies .
CSRF là gì?CSRF là gì?

Các cuộc tấn công mạng này thường lợi dụng các email hoặc liên kết giả mạo, nhằm đánh lừa nạn nhân gửi các request đến server. Nhiều trường hợp ứng dụng người dùng sử dụng đã được xác thực trước đó, nên rất khó phân biệt giữa các request hợp pháp và giả mạo.

Lịch sử của tấn cống CSRF

CSRF Open từ năm 1990 và xuất phát từ IP của người sử dụng. Vì vậy, log file của website không Open bất kỳ những tín hiệu của CSRF. Các cuộc tiến công theo kỹ thuật CSRF thường không được báo cáo giải trình rất đầy đủ. Cho đến năm 2007, mới có khá đầy đủ những tài liệu miêu tả cụ thể về CSRF .
Sau đó 1 năm, đã có khoảng chừng 18 triệu người dùng eBay tại Nước Hàn bị đánh cắp thông tin cá thể cực kỳ nghiêm trọng. Trong thời gian đó, có 1 số ít người mua ở Mexico đã bị mất cắp thông tin tài khoản cá thể của mình. Cả 2 trường hợp này, hacker đều sử dụng kỹ thuật tiến công CSRF để tạo ra lỗ hổng và đánh cắp thông tin cực kỳ nguy hại .

CSRF hoạt động như thế nào?

Có ba yếu tố then chốt để thực hiện một cuộc tấn công CSRF:

  • Hành động liên quan: Đây là các hành động được thực hiện trong ứng dụng mà các hacker có thể sử dụng làm phương tiện để tấn công. Chẳng hạn như các hành động đặc quyền (như sửa đổi quyền truy cập) hay các hành động trên dữ liệu của riêng người dùng (thay đổi mật khẩu).
  • Xử lý dựa trên session cookie: Cụ thể, các hacker sẽ đưa ra một hay nhiều HTTP request, và ứng dụng chỉ dựa vào session cookie để xác định người dùng đã thực hiện request. Tức là không có cơ chế nào khác để có thể theo dõi session hoặc xác thực user request.
  • Tham số request có thể đoán được: Các request thực hiện hành động chứa các tham số mà hacker có thể xác định hay đoán được.

Lấy ví dụ, giả sử có một ứng dụng chứa có năng được cho phép người dùng biến hóa địa chỉ email trên thông tin tài khoản. Khi người dùng triển khai hành vi này, họ sẽ đưa ra một HTTP request 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

Request này đáp ứng đủ ba yếu tố cần thiết cho CSRF:

  • Hành động thay đổi địa chỉ email của người dùng là một hành động lý tưởng với các hacker để tấn công. Sau đó, chúng thường trigger một password reset, từ đó nắm được toàn quyền kiểm soát tài khoản của người dùng.
  • Ứng dụng sử dụng session cookie để xác nhận người dùng đưa ra request.
  • Không có token hay cơ chế nào khác để theo dõi user session.
  • Kẻ tấn công có thể dễ dàng xác định giá trị của các tham số request cần thiết để thực hiện hành động.

Với những điều kiện kèm theo trên, những hacker hoàn toàn có thể tạo một website chứa HTML sau :



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=wiener@normal-user.com

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/change?email=pwned@evil-user.net 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=pwned@evil-user.net

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.

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=wiener@normal-user.com

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.

Ở 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=wiener@normal-user.com

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 )

Source: https://wikifin.net
Category: Blog

Leave a Comment

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *