Rate this post
Cross-Site Request Forgery (CSRF) là gì?
Cross-Site Request Forgery (CSRF) là một cuộc tấn công buộc người dùng cuối phải thực hiện thao tác mà họ không có chủ đích làm trên website đã được xác thực. Với cac thủ thuật khác, kẻ tấn công có thể khiến người bị hại thực hiện theo hành động chúng định trước. Việc khai thác CSRF thành công có thể làm tổn hại đến dữ liệu và hoạt động của người dùng cuối khi nó nhắm mục tiêu đến người dùng bình thường. Nếu người dùng cuối có quyền hạn là Admin, thì một cuộc tấn công CSRF có thể xâm phạm nặng đến website.
Các bài viết liên quan:
CSRF dựa vào:
- Hành vi của trình duyệt web về việc xử lý thông tin liên quan đến phiên như cookie và thông tin xác thực HTTP.
- Kẻ tấn công biết các URL, yêu cầu hoặc chức năng của ứng dụng web hợp lệ.
- Quản lý phiên ứng dụng chỉ dựa vào thông tin mà trình duyệt biết.
- Sự tồn tại của các thẻ HTML mà sự hiện diện của chúng gây ra quyền truy cập ngay lập tức vào tài nguyên HTTP [S]; ví dụ thẻ hình ảnh img.
Các điểm 1, 2 và 3 là cần thiết để hiện diện lỗ hổng bảo mật, trong khi điểm 4 tạo điều kiện thuận lợi cho việc khai thác thực tế, nhưng không bắt buộc phải nghiêm ngặt.
- Trình duyệt tự động gửi thông tin được sử dụng để xác định phiên người dùng. Giả sử trang web là một trang web lưu trữ một ứng dụng web và nạn nhân của người dùng vừa xác thực trang web đó. Đáp lại, trang web sẽ gửi cho nạn nhân một cookie xác định các yêu cầu do nạn nhân gửi thuộc về phiên đã xác thực của nạn nhân. Khi trình duyệt nhận được cookie do trang web đặt, nó sẽ tự động gửi cookie cùng với bất kỳ yêu cầu nào khác được chuyển hướng đến trang web.
- Nếu ứng dụng không sử dụng thông tin liên quan đến phiên trong URL, thì URL của ứng dụng, các tham số và giá trị hợp pháp của chúng có thể được xác định. Điều này có thể được thực hiện bằng cách phân tích mã hoặc bằng cách truy cập ứng dụng và ghi chú các biểu mẫu và URL được nhúng trong HTML hoặc JavaScript.
- “Được trình duyệt biết đến” đề cập đến thông tin như cookie hoặc thông tin xác thực dựa trên HTTP (chẳng hạn như Xác thực cơ bản chứ không phải xác thực dựa trên biểu mẫu), được trình duyệt lưu trữ và sau đó hiển thị theo từng yêu cầu hướng tới một khu vực ứng dụng yêu cầu xác thực. Các lỗ hổng được thảo luận tiếp theo áp dụng cho các ứng dụng hoàn toàn dựa vào loại thông tin này để xác định phiên người dùng.
- Vì lợi ích của đơn giản, hãy xem xét các URL có thể truy cập GET (mặc dù cuộc thảo luận cũng áp dụng cho các yêu cầu ĐĂNG). Nếu nạn nhân đã tự xác thực, việc gửi một yêu cầu khác sẽ tự động gửi cookie cùng với nó. Hình bên dưới minh họa người dùng truy cập một ứng dụng trên www.example.com.
Người dùng có thể gửi yêu cầu GET theo nhiều cách khác nhau:
- Sử dụng ứng dụng web
- Nhập URL trực tiếp vào trình duyệt
- Theo một liên kết bên ngoài trỏ đến URL
Ứng dụng không thể phân biệt được những lời gọi này. Đặc biệt, thứ ba có thể khá nguy hiểm. Có một số kỹ thuật và lỗ hổng có thể che giấu các thuộc tính thực của một liên kết. Liên kết có thể được nhúng trong thư email, xuất hiện trong trang web độc hại mà người dùng bị thu hút hoặc xuất hiện trong nội dung do bên thứ ba lưu trữ (chẳng hạn như trang web khác hoặc email HTML) và trỏ đến tài nguyên của ứng dụng . Nếu người dùng nhấp vào liên kết, vì họ đã được xác thực bởi ứng dụng web trên trang web, trình duyệt sẽ đưa ra yêu cầu GET cho ứng dụng web, kèm theo thông tin xác thực (cookie phiên ID). Điều này dẫn đến một hoạt động hợp lệ được thực hiện trên ứng dụng web mà người dùng không mong đợi; ví dụ: chuyển tiền trên ứng dụng ngân hàng trực tuyến.
Xem thêm Các bước hack hệ thống ? hacking? Ethical hacking
Bằng cách sử dụng một thẻ như img, như được chỉ định trong điểm 4 ở trên, người dùng thậm chí không cần thiết phải theo một liên kết cụ thể. Giả sử kẻ tấn công gửi cho người dùng một email khiến họ truy cập vào một URL đề cập đến một trang chứa HTML (đơn giản hóa quá mức) sau đây.
<html>
<body>
...
<img src="https://www.company.example/action" width="0" height="0">
...
</body>
</html>
Khi trình duyệt hiển thị trang này, nó cũng sẽ cố gắng hiển thị hình ảnh có kích thước không (do đó, ẩn) được chỉ định từ https: //www.company.example. Điều này dẫn đến một yêu cầu được tự động gửi đến ứng dụng web được lưu trữ trên trang web. Điều quan trọng là URL hình ảnh không tham chiếu đến một hình ảnh thích hợp, vì dù sao thì sự hiện diện của nó cũng sẽ kích hoạt hành động yêu cầu được chỉ định trong trường src. Điều này xảy ra với điều kiện là tải xuống hình ảnh không bị tắt trong trình duyệt. Hầu hết các trình duyệt không tắt tính năng tải xuống hình ảnh vì điều đó sẽ làm tê liệt hầu hết các ứng dụng web ngoài khả năng sử dụng.
Vấn đề ở đây là hệ quả của:
- Các thẻ HTML trên trang dẫn đến việc thực thi yêu cầu HTTP tự động (img là một trong những thẻ đó).
- Trình duyệt không có cách nào để biết rằng tài nguyên được tham chiếu bởi img không phải là một hình ảnh hợp pháp.
- Tải hình ảnh xảy ra bất kể vị trí của nguồn hình ảnh bị cáo buộc, tức là
- biểu mẫu và hình ảnh chính nó không cần phải được đặt trên cùng một máy chủ lưu trữ hoặc thậm chí cùng một miền.
Thực tế là nội dung HTML không liên quan đến ứng dụng web có thể tham chiếu đến các thành phần trong ứng dụng và việc trình duyệt tự động soạn một yêu cầu hợp lệ đối với ứng dụng cho phép loại tấn công này. Không có cách nào để cấm hành vi này trừ khi kẻ tấn công không thể tương tác với chức năng ứng dụng.
Xem thêm SEO – App Store: Hướng dẫn dành cho thiết bị Di động
Trong môi trường thư / trình duyệt tích hợp, chỉ cần hiển thị một thông báo email có chứa tham chiếu hình ảnh sẽ dẫn đến việc thực thi yêu cầu đối với ứng dụng web bằng cookie của trình duyệt được liên kết. Thư email có thể tham chiếu đến các URL hình ảnh có vẻ hợp lệ, chẳng hạn như:
<img src = "https: // [attacker] /picture.gif" width = "0" height = "0">
Trong ví dụ này, [attacker] là một trang web do kẻ tấn công kiểm soát. Bằng cách sử dụng cơ chế chuyển hướng, trang web độc hại có thể sử dụng http: // [attacker] /picture.gif để hướng nạn nhân đến hành động http: // [thirdparty] / và kích hoạt hành động.
Cookie không phải là ví dụ duy nhất liên quan đến loại lỗ hổng này. Các ứng dụng web có thông tin phiên hoàn toàn do trình duyệt cung cấp cũng dễ bị tấn công. Điều này bao gồm các ứng dụng chỉ dựa vào cơ chế xác thực HTTP, vì thông tin xác thực được trình duyệt biết và được gửi tự động theo mỗi yêu cầu. Điều này không bao gồm xác thực dựa trên biểu mẫu, chỉ xảy ra một lần và tạo ra một số dạng thông tin liên quan đến phiên, thường là cookie.
Giả sử rằng nạn nhân đã đăng nhập vào bảng điều khiển quản lý web tường lửa. Để đăng nhập, người dùng phải tự xác thực và thông tin phiên được lưu trữ trong cookie.
Giả sử bảng điều khiển quản lý web tường lửa có chức năng cho phép người dùng đã xác thực xóa quy tắc được chỉ định bởi ID số của nó hoặc tất cả các quy tắc trong cấu hình nếu người dùng chỉ định * (một tính năng nguy hiểm trong thực tế, nhưng một tính năng tạo ra ví dụ thú vị hơn). Trang xóa được hiển thị tiếp theo. Giả sử rằng biểu mẫu – vì mục đích đơn giản – đưa ra yêu cầu GET. Để xóa quy tắc số một:
https://[target]/fwmgt/delete?rule=1
Để xóa tất cả các quy tắc:
https: // [target] / fwmgt / delete? rule = *
Ví dụ này có chủ đích ngây thơ, nhưng cho thấy một cách đơn giản sự nguy hiểm của CSRF.
Sử dụng biểu mẫu trong hình trên, nhập giá trị * và nhấp vào nút Xóa sẽ gửi yêu cầu GET sau:
https: //www.company.example/fwmgt/delete? rule = *
Người dùng cũng có thể đạt được kết quả tương tự bằng cách gửi URL theo cách thủ công:
https: // [target] / fwmgt / delete? rule = *
Hoặc bằng cách nhấp vào một liên kết trỏ đến, trực tiếp hoặc thông qua chuyển hướng, đến URL ở trên. Hoặc, một lần nữa, bằng cách truy cập trang HTML có thẻ img được nhúng trỏ đến cùng một URL.
Trong tất cả các trường hợp này, nếu người dùng hiện đang đăng nhập vào ứng dụng quản lý tường lửa, yêu cầu sẽ thành công và sẽ sửa đổi cấu hình của tường lửa. Người ta có thể tưởng tượng các cuộc tấn công nhắm vào các ứng dụng nhạy cảm và thực hiện các cuộc đấu giá tự động, chuyển tiền, đặt hàng, thay đổi cấu hình của các thành phần phần mềm quan trọng, v.v.
Một điều thú vị là những lỗ hổng này có thể được thực hiện đằng sau một bức tường lửa; nghĩa là nạn nhân có thể truy cập được liên kết bị tấn công chứ không phải kẻ tấn công trực tiếp. Đặc biệt, nó có thể là bất kỳ máy chủ web mạng nội bộ nào; ví dụ, trong kịch bản quản lý tường lửa đã đề cập trước đó, mà không có khả năng được tiếp xúc với Internet.
Xem thêm Cách xây dựng các backlink chất lượng cao theo cách có thể mở rộng
Các ứng dụng tự dễ bị tấn công, tức là các ứng dụng được sử dụng làm vectơ tấn công và mục tiêu (chẳng hạn như ứng dụng thư web), làm cho mọi thứ trở nên tồi tệ hơn. Vì người dùng đã đăng nhập khi họ đọc email của họ, một ứng dụng dễ bị tấn công kiểu này có thể cho phép kẻ tấn công thực hiện các hành động như xóa tin nhắn hoặc gửi tin nhắn có vẻ như bắt nguồn từ nạn nhân.
Các biện pháp phòng ngừa KHÔNG hoạt động
Một số ý tưởng thiếu sót để bảo vệ chống lại các cuộc tấn công của CSRF đã được phát triển theo thời gian. Dưới đây là một số điều mà chúng tôi khuyên bạn nên tránh.
Tóm Tắt
Sử dụng một cookie bí mật
Hãy nhớ rằng tất cả cookie, ngay cả những cookie bí mật, sẽ được gửi theo mọi yêu cầu. Tất cả các mã thông báo xác thực sẽ được gửi bất kể người dùng cuối có bị lừa gửi yêu cầu hay không. Hơn nữa, mã định danh phiên chỉ được sử dụng bởi vùng chứa ứng dụng để liên kết yêu cầu với một đối tượng phiên cụ thể. Số nhận dạng phiên không xác minh rằng người dùng cuối có ý định gửi yêu cầu hay không.
Chỉ chấp nhận các yêu cầu POST
Các ứng dụng có thể được phát triển để chỉ chấp nhận các yêu cầu POST để thực hiện logic nghiệp vụ. Quan niệm sai lầm là vì kẻ tấn công không thể xây dựng một liên kết độc hại, một cuộc tấn công CSRF không thể được thực hiện. Thật không may, logic này không chính xác. Có nhiều phương pháp mà kẻ tấn công có thể lừa nạn nhân gửi yêu cầu POST giả mạo, chẳng hạn như một biểu mẫu đơn giản được lưu trữ trong Trang web của kẻ tấn công với các giá trị ẩn. Hình thức này có thể được kích hoạt tự động bởi Ja
vaScript hoặc có thể được kích hoạt bởi nạn nhân, người nghĩ rằng biểu mẫu sẽ thực hiện một cái gì đó khác.
Giao dịch nhiều bước
Giao dịch nhiều bước không phải là biện pháp ngăn chặn đầy đủ CSRF. Miễn là kẻ tấn công có thể dự đoán hoặc suy luận từng bước của giao dịch đã hoàn thành, thì CSRF là có thể.
Viết lại URL
Đây có thể được coi là một kỹ thuật ngăn chặn CSRF hữu ích vì kẻ tấn công không thể đoán ID phiên của nạn nhân. Tuy nhiên, ID phiên của người dùng được hiển thị trong URL. Chúng tôi khuyên bạn không nên sửa một lỗ hổng bảo mật bằng cách giới thiệu một lỗ hổng bảo mật khác.
HTTPS
Bản thân HTTPS không có tác dụng gì để bảo vệ chống lại CSRF.
Tuy nhiên, HTTPS nên được coi là điều kiện tiên quyết để mọi biện pháp phòng ngừa trở nên đáng tin cậy.
Mục tiêu kiểm tra
Xác định xem có thể thay mặt người dùng thực hiện các yêu cầu không do người dùng thực hiện hay không.
Làm thế nào để kiểm tra
Kiểm tra ứng dụng để xác định xem quản lý phiên của nó có dễ bị tấn công hay không. Nếu quản lý phiên chỉ dựa vào các giá trị phía máy khách (thông tin có sẵn cho trình duyệt) thì ứng dụng sẽ dễ bị tấn công. “Giá trị phía máy khách” đề cập đến cookie và thông tin xác thực HTTP (Xác thực cơ bản và các hình thức xác thực HTTP khác; không phải xác thực dựa trên biểu mẫu, là xác thực cấp ứng dụng).
Các tài nguyên có thể truy cập thông qua các yêu cầu HTTP GET rất dễ bị tấn công, mặc dù các yêu cầu POST có thể được tự động hóa thông qua JavaScript và cũng dễ bị tấn công; do đó, việc sử dụng POST một mình là không đủ để khắc phục sự xuất hiện của các lỗ hổng CSRF.
Trong trường hợp POST, mẫu sau có thể được sử dụng.
- Tạo một trang HTML
- tương tự như hiển thị bên dưới
- Lưu trữ HTML trên một trang web độc hại hoặc bên thứ ba
Gửi liên kết của trang cho (những) nạn nhân và khiến họ nhấp vào liên kết đó.
<html>
<body onload='document.CSRF.submit()'>
<form action='http://targetWebsite/Authenticate.jsp' method='POST' name='CSRF'>
<input type='hidden' name='name' value='Hacked'>
<input type='hidden' name='password' value='Hacked'>
</form>
</body>
</html>
Trong trường hợp các ứng dụng web trong đó các nhà phát triển đang sử dụng JSON để giao tiếp giữa trình duyệt với máy chủ, vấn đề có thể phát sinh với thực tế là không có tham số truy vấn nào với định dạng JSON, điều bắt buộc đối với biểu mẫu tự gửi. Để vượt qua trường hợp này, chúng tôi có thể sử dụng biểu mẫu tự gửi với tải trọng JSON bao gồm đầu vào ẩn để khai thác CSRF. Chúng tôi sẽ phải thay đổi loại mã hóa (enctype) thành văn bản / thuần túy để đảm bảo tải trọng được phân phối như hiện tại. Mã khai thác sẽ giống như sau:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action='http://victimsite.com' method='POST' enctype='text/plain'>
<input type='hidden' name='{"name":"hacked","password":"hacked","padding":"'value='something"}' />
<input type='submit' value='Submit request' />
</form>
</body>
</html>
Yêu cầu ĐĂNG sẽ như sau:
POST / HTTP/1.1
Host: victimsite.com
Content-Type: text/plain
{"name":"hacked","password":"hacked","padding":"=something"}
Khi dữ liệu này được gửi dưới dạng yêu cầu ĐĂNG, máy chủ sẽ vui vẻ chấp nhận các trường tên và mật khẩu và bỏ qua trường có phần đệm tên vì nó không cần đến nó.
Biện pháp khắc phục hậu quả
Hãy xem OWASP CSRF Phòng chống Gian lận để biết các biện pháp phòng ngừa.
Công cụ
