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 tấn công giả mạo chính chủ thể sẽ gây hậu quả nghiêm trọng cho các doanh nghiệp lẫn người dùng. Cụ thể là dẫn đến các hoạt động chuyển tiền trái phép, thay đổi mật khẩu, đánh cắp dữ liệu – gồm cả các session cookies.
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.
>> Xem thêm: Cookies là gì? Dữ liệu Cookie được truyền như thế nào?
Lịch sử của tấn cống CSRF
CSRF xuất hiện 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 xuất hiện bất cứ các dấu hiệu của CSRF. Các cuộc tấn công theo kỹ thuật CSRF thường không được báo cáo đầy đủ. Cho đến năm 2007, mới có đầy đủ các tài liệu miêu tả chi tiết về CSRF.
Sau đó 1 năm, đã có khoảng 18 triệu người dùng eBay tại Hàn Quốc bị đánh cắp thông tin cá nhân cực kỳ nghiêm trọng. Trong thời điểm đó, có một số khách hàng ở Mexico đã bị mất cắp tài khoản cá nhân của mình. Cả 2 trường hợp này, hacker đều sử dụng kỹ thuật tấn công CSRF để tạo ra lỗ hổng và đánh cắp thông tin cực kỳ nguy hiểm.
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 cho phép người dùng thay đổi địa chỉ email trên tài khoản. Khi người dùng thực hiện hành động 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.comRequest 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 trên, các hacker có thể tạo một trang web chứa HTML sau:
<html> <body> <form action="https://vulnerable-website.com/email/change" method="POST"> <input type="hidden" name="email" value="pwne@evil-user.net /> </form> <script> document.forms[0].submit(); </script> </body> </html>Nếu nạn nhân truy cập trang web của hacker:
- Trang web của hacker sẽ trigger một HTTP request đến trang web dễ bị tấn công.
- Nếu người dùng đăng nhập vào trang web đó, trình duyệt sẽ tự động đưa session cookie vào request.
- Trang web sau đó sẽ xử lý request như bình thường, và thay đổi địa chỉ email theo yêu cầu.
Lưu ý: Mặc dù CSRF thường liên quan nhiều đến xử phiên session dựa trên cookie, nhưng nó cũng có thể phát sinh trong nhiều trường hợp khác. Chẳng hạn như 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 request, ví dụ như xác thực HTTP Basic và xác thực certificate-based.
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 cần thiết nhưng tương đối phức tạp, đặc biệt là khi request mong muốn chứa nhiều tham số. Cách đơn giả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 cơ chế phân phối cho cuộc tấ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 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 đó. Chúng có thể cung cấp cho người dùng các liên kết đến trang, qua email hoặc tin nhắn trên mạng xã hội. Đôi khi tấn công CSRF có thể được đặt ở các trang phổ biến (chẳng hạn như phần comment của người dùng). Khi đó, các hacker chỉ cần “há miệng chờ sung” đợi người dùng truy cập vào.
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. Khi đó, hacker không cần thiết phải sử dụng trang web bên ngoài mà có thể trực tiếp cung cấp các một URL độc hại trên domain dễ bị tấn công.
Trong ví dụ trước, nếu request thay đổi địa chỉ email có thể được thực hiện bằng phương pháp GET, thì một cuộc tấn công khép kín sẽ có dạng như sau:
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">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 có thể sử dụng SamSite cookies để chống bị tấn công. Đây là một phương pháp khá hiệu quả và 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 quá trình xác thực CSRF token.
Trong ví dụ trước, giả sử rằng ứng dụng bao gồm cả CSRF token trong request để thay đổi 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.comKhi đó, ta có thể chống được CSRF, vì nó vi phạm các điều kiện cần thiết để có thực thực hiện tấn công: Ứng dụng bây giờ không chỉ dựa vào mỗi cookies để xử lý session nữa. Đồng thời, request cũng chứa một tham số mà kẻ tấn công không thể xác định được.
Tuy nhiên, vẫn còn có nhiều cách khác để các hacker có thể phá vỡ lớp bảo vệ. Tức là ứng dụng vẫn có thể bị tấ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 có thể xác thực đúng token khi request sử dụng phương pháp POST. Nhưng lại bỏ qua nó với phương pháp GET.
Khi đó, hacker có thể chuyển sang phương pháp GET để bypass xác thực, rồi gửi một cuộc tấn công:
GET /email/change?email=pwned@evil-user.net HTTP/1.1 Host: vulnerable-website.com Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLmXá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 thực đúng token khi nó hiện diện, nhưng lại bỏ qua xác thực nếu không có token. Khi đó, hacker có thể xóa toàn bộ tham số chứa token để bypass và thực hiện tấ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.netMã 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 thực 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 các token đã được phát hành. Và sẽ chấp nhận 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 một số biến thể của lỗ hổng bảo mật ở trên, vài ứng dụng liên kết token CSRF với một cookie. Nhưng nó không được liên kết 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 để 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.comMặc dù tình huống này khó khai thác hơn, nhưng không phải là hoàn toàn miễn nhiễm với CSRF. Nếu trang web có chứa bất kỳ hành vi nào cho phép hacker đặt cookie trong trình duyệt của nạn nhân, thì vẫn có thể bị tấn công. Các hacker có thể đăng nhập vào ứng dụng bằng tài khoản của họ, lấy token hợp lệ cùng với cookie được liên kết. 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 cấp token cho nạn nhân trong tấ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
Ở các phần trên, một số ứng dụng không duy trì bất kỳ bản ghi phía server nào về các 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 thực, ứng dụng chỉ cần xác minh rằng token được gửi trong tham số request khớp với giá trị trong cookie. Đây được gọi là biện pháp “double summit” để chống tấn công CSRF. Nó cũng là một phương pháp tương đối dễ thực hiện, 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.comTương tự, ở tình huống này, hacker có thể thực hiện tấn công CSRF laravel nếu trang web có bất kỳ chức năng cài đặt 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 (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 cấp token cho họ trong CSRF.
Ví dụ về cách tấn công CSRF
Trước khi thực hiện CSRF attack, các hacker thường nghiên cứu một ứng dụng để tạo các request giả mạo. Nhưng tất nhiên là phải trông hợp lệ nhất có thể.
Chẳng hạn, dưới đây là một GET request để chuyển khoản 100 USD:
GET http://netbank.com/transfer.do?acct=PersonalB&amount=$100 HTTP/1.1Hoặc script trên có thể được chỉnh sửa một chút. Chẳng hạn nếu hacker muốn chuyển 100 USD vào 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.1Hacker cũng có thể nhúng request vào một hyperlink khác:
<a hreg="http://netbank.com/transfer.do?acct=AttackerA&amount=$100">Read more!</a>Tiếp đến, chúng có thể phân phối hyperlink này qua email đến một lượng lớn khách hàng của ngân hàng. Những người click vào link trong khi đăng nhập vào tài khoản ngân hàng 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 <a> 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 <form> với việc tự động thực thi JavaScript được nhúng.
Khi đó, script sẽ có dạng như sau:
<body onload="document.forms[0].submit()"> <form action="http://netbank.com/transfer.do" method="POST"> <input type="hidden" name="acct" value="AttackerA"/> <input type="hidden" name="amount" value="$100"/> <input type="submit" value="View my pictures!"/> </form> </body>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.
