Ngăn chặn tấn công XSS bằng Content Security Policy (CSP)

Ngăn chặn tấn công XSS bằng Content Security Policy (CSP)

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Hẳn là nhiều người ở đây đã nghe đến kiểu tấn công bảo mật Clickjacking rồi nhỉ. Kẻ tấn công thường nhúng một website (thường là mục tiêu) vào trong một iframe trên website của chúng, sau đó làm mờ hoặc ẩn nó đi rồi đặt vào vị trí các nút bấm trên web, ví dụ "Bấm vào để nhận quà". Đâu ai ngờ rằng phía trên nút bấm đó là một nút bấm khác trong iframe. Khá nguy hiểm!

    Nhưng trình duyệt đã có cách ngăn chặn kiểu tấn công này bằng các quy tắc như tiêu đề X-Frame-Options, frame-ancestors của CSP và SameSite: Lax/Strict của Cookies...

    Mới đây, đã xuất hiện thêm kiểu tấn công mới - "DoubleClickjacking" 😨. Đại ý là "hắn" lợi dụng hành động double click để lừa người dùng bấm vào một nút mà hắn muốn. Chi tiết hơn trong bài viết này: DoubleClickjacking: A New Era of UI Redressing.

    » Xem thêm
  • Mọi người đã nghe nói đến Jujutsu - jj - một dạng quản lý phiên bản cho mã nguồn (version control system) chưa? Có vẻ như nó đang nhận được nhiều sự quan tâm.

    Chờ xíu! Chẳng phải git đã quá tốt rồi sao? Thế thì chế ra thằng jj để làm gì nữa? Cũng hơi khó trả lời nhỉ? Mỗi công cụ sinh ra chắc chắn phải cải thiện hoặc khắc phục được nhược điểm của cái trước. Cho nên jj ắt hẳn phải làm được điều gì đó mà git chưa làm được nên mới nổi lên như vậy.

    Thật ra mình đã nghe nói đến jj từ vài tháng trước rồi, nhưng vào đọc thì toàn kiến thức cao siêu. Hoặc là đang mang nặng cái lối suy nghĩ của git vào trong đầu rồi nên chưa lĩnh hội ra được điều gì cả.

    Mình hay có kiểu cái gì đọc lần 1 mà không hiểu thì đọc tiếp lần 2, lần 2 không hiểu thì đọc tiếp lần 3... đến lần thứ n mà vẫn không hiểu thì bỏ. Cơ mà không phải là từ bỏ mà một thời gian sau đó quay lại đọc tiếp. Đến một lúc nào đó khả năng mình sẽ hiểu ra một ít vấn đề, thế mới tài 😆.

    Thì cái jj này có vẻ như nó đang mở ra được tính linh hoạt trong việc "cam kết" mã. Tưởng tượng bạn đang làm việc trên một dự án, đang ở nhánh này, muốn sang nhánh khác để sửa, nhưng mà lại đang viết dở ở nhánh này, thế là phải stash, rồi checkout, rồi commit, rồi merge hoặc rebase lại vào nhánh cũ... nhìn chung quá trình làm việc với git nghiêm ngặt đến mức cứng nhắc, cần nhiều thao tác để giải quyết một vấn đề, chưa kể cái cây commit (commit-tree) nữa thì ôi thôi, khỏi xem cho đỡ nhức mắt. Thế nên ông jj này đang làm cách nào đó để bạn khỏi cần phải quan tâm đến các nhánh luôn, sửa trực tiếp vào commit. Nghe ảo nhỉ 😂.

    Đấy mới lĩnh hội được đến đấy, hy vọng sau n lần đọc lại nữa mình sẽ viết được một bài chi tiết hơn về công cụ này.

    » Xem thêm
  • Gòi gòi tới công chiện gòi 🤤🤤🤤

    » Xem thêm

CSP là gì

Content Security Policy (CSP) là một lớp bảo mật bổ sung giúp phát hiện và giảm thiểu một số loại tấn công nhất định, bao gồm cả tấn công Cross-Site Scripting (XSS) và dữ liệu. Các cuộc tấn công này được sử dụng cho mọi thứ, từ đánh cắp dữ liệu, làm mất mặt trang web, đến phân phối phần mềm độc hại.

Cách hoạt động của CSP

Khi máy chủ phản hồi trong header với thẻ Content-Security-Policy hoặc một thẻ <meta> trong HTML Document như:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

thì ngay lập tức trình duyệt hỗ trợ sẽ kích hoạt các biện pháp bảo vệ người dùng bằng cách hạn chế việc tải và thực thi các tài nguyên như Javascript, CSS, iframe, Web Worker, fonts...

Ví dụ thẻ <meta> trên tương đương với việc đặt thuộc tính Content-Security-Policy sau vào trong header của phản hồi:

Content-Security-Policy: default-src 'self'

thì trình duyệt sẽ chỉ tải những tài nguyên nếu chúng xuất phát từ nguồn của tên miền hiện tại (không bao gồm subdomain).

Tuy nhiên cách tốt nhất vẫn là phản hồi thuộc tính Content-Security-Policy trong header để kích hoạt CSP bởi vì việc đặt vào <meta> sẽ bị bỏ qua nếu như kẻ tấn công đính kèm mã vào phía trước. Hơn nữa một số thẻ policy sẽ không hoạt động đối với <meta>.

Cách đặt policy

Bằng cách đặt các thẻ policy lại với nhau để tạo ra một policy hoàn chỉnh mà bạn mong muốn thiết lập cho trang web. Có rất nhiều thẻ policy cho bạn lựa chọn, default-src hoặc script-src để ngăn thực thi mã inline hoặc lệnh eval(), default-src hoặc style-src để hạn chế áp dụng style từ thẻ <style> hoặc một thuộc tính inline style.

Để xem danh sách các thẻ policy đầy đủ bạn có thể xem tại Content-Security-Policy header.

Ví dụ:

Chỉ tải các nội dung từ chính tên miền và các tên miền phụ:

Content-Security-Policy: default-src 'self' example.com *.example.com

Tải ảnh từ bất kì nguồn nào đó, hạn chế tải video hoặc âm thanh và các tệp javascript:

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

Cấu hình báo cáo

Cấu hình báo cáo (report) giúp chúng ta phát hiện ra có kẻ đang cố gắng tấn công vào trang web. Bằng cách đặt thẻ report-uri vào thuộc tính Content-Security-Policy kèm theo URI nhận báo cáo trình duyệt sẽ tự động gửi một POST request đến địa chỉ đó kèm theo body là thông tin chi tiết của cuộc tấn công.

Ví dụ thuộc tính Content-Security-Policy đang xác định:

Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri http://reportcollector.example.com/collector.cgi

Sau đó hãy tạo một file html:

<!DOCTYPE html>
<html>
  <head>
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css">
  </head>
  <body>
    ... Content ...
  </body>
</html>

Rõ ràng href="css/style.css" đã vi phạm policy style-src cdn.example.com thế nên nếu cố tình chạy file html trên trình duyệt sẽ gửi một POST request đến report-uri nội dung như:

{
  "csp-report": {
    "document-uri": "http://example.com/signup.html",
    "referrer": "",
    "blocked-uri": "http://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri http://reportcollector.example.com/collector.cgi"
  }
}

Tổng kết

Content Security Policy là một giải pháp nhằm ngăn chặn tấn công XSS và một số loại tấn công khác như clickjacking, code injection... nhắm vào khai thác việc thực thi nội dung độc hại trong ngữ cảnh của trang web. Nó hoạt động bằng cách chỉ tải và thực thi tài nguyên từ những nguồn được xác định rõ ràng từ trước thông qua phản hồi Content-Security-Policy có trong header hoặc thông qua thẻ <meta> trong mã HTML.

Tài liệu tham khảo:

Cao cấp
Hello

5 bài học sâu sắc

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (2)

Nội dung bình luận...
Avatar
Ẩn danh1 năm trước
cho minh hoi ngu xíu. *** Khi dùng script từ bên ngoài thì phài set vào CSP *** khi trang web của mình bị hack thì thôi..... còn khi trang web bên ngoài bị hack thì nó sẽ bi add mã độc vào. web mình vần down về và chạy mã đó. vậy CSP có còn hữu ích ko?
Trả lời
Avatar
Xuân Hoài Tống1 năm trước
Mình nghĩ việc cài đặt extension đã là chấp nhận một phần rủi ro rồi. Nó có thể can thiệp sâu vào trang web để từ đó đánh cắp hoặc tự ý thực thi mã không được phép. Mình không dám khẳng định CSP là không hiệu quả. Ngoài kia có rất nhiều trường hợp cần phải có CSP mà không lường hết được. Một công cụ được tạo ra chắc chắn phải được sử dụng để giải quyết vấn đề nào đó. Điều đó phụ thuộc nhiều vào bài toán cần giải quyết. Bạn thấy đấy, trang web của mình hiện tại không áp dụng CSP đơn giản là do thấy chưa cần thiết.
Avatar
Ẩn danh1 năm trước
ok. cam on ban. Theo minh thay thi ban ko dam nhan CSP la that su ko can thiet. theo minh thi no ko can thiet that. tai vi neu khong dung script ben thu 3. thi van phai dung 'self' mà 'self' thi hacker vẫn lừa bạn cài extention duoc. rồi extension vẫn chạy script ok.
Avatar
Xuân Hoài Tống1 năm trước
Àh, mình cũng có giải thích ở câu trả lời bên dưới rồi: "Nếu bên thứ 3 bị hack, rõ ràng là lúc này CSP cũng không chống lại được gì vì bạn đã "trust" cho tất cả tài nguyên của bên đó rồi."
Avatar
Ẩn danh1 năm trước
ý mình là CSP nó có thật sự cần thiết ko?
Avatar
Xuân Hoài Tống1 năm trước
Thắc mắc của bạn cũng là vấn đề chung của rất nhiều người lâu nay. Có một nguyên tắc là đừng bao giờ tin hoàn toàn vào bên thứ 3, chưa nói đến việc kẻ tấn công có thể hack vào hệ thống đó hay không mà đôi khi chính nhà phát triển thư viện cũng có khả năng là kẻ tấn công. Bạn có thể tìm thấy nhiều vụ tấn công liên quan đến việc sử dụng thư viện của bên thứ 3 trên mạng Internet. Rất nhiều cảnh báo được đưa ra. Nhiều dự án chỉ sử dụng tài nguyên trên chính hệ thống của mình bằng việc tự lưu trữ lại toàn bộ script... Nhưng thế là chưa đủ, nhiều vấn đề phát sinh như tốc độ, khả năng cập nhật... rồi chưa kể thư viện thứ 3 cần phải mở thêm kết nối bên ngoài khác nữa... Nói tóm lại, sử dụng thư viện thứ 3 đồng nghĩa với việc bạn chấp nhận rủi ro một phần, vì thế hãy lựa chọn thư viện "chính chủ", uy tín... Nếu bên thứ 3 bị hack, rõ ràng là lúc này CSP cũng không chống lại được gì vì bạn đã "trust" cho tất cả tài nguyên của bên đó rồi.
Avatar
Nguyễn Quang Tú2 năm trước
Giống với cors rồi
Trả lời
Avatar
Xuân Hoài Tống2 năm trước
Không giống đâu bạn, bạn có thể tìm đọc các bài viết nói về sự khác nhau giữ CORS và CSP nhưng đại loại là CORS cho phép một trang web thực hiện một request đến trang khác mà được phép sử dụng cả session, cookie... của trang đó. Còn CSP cho phép một trang web ngăn chính nó tải nội dung (có khả năng độc hại) như là các tập js, css... từ các nguồn không mong muốn (như một biện pháp bảo vệ chống lại XSS)
Bấm hoặc cuộn mạnh để sang bài mới