☰ Mục lục series
Tài liệu Go tiếng Việt
  1. Bắt đầu (Getting started)
    1. Tổng quan
    2. Tải về và cài đặt
    3. Bắt đầu với Go
    4. Quản lý các bản cài đặt Go
    5. Plugin trình soạn thảo và IDE
  2. Dạo quanh Go (A Tour of Go)
    1. Chào mừng
    2. Package, biến và hàm
    3. Điều khiển luồng
    4. Struct, slice và map
    5. Method và interface
    6. Generics
    7. Xử lý đồng thời
  3. Hướng dẫn (Tutorials)
    1. Danh sách hướng dẫn
    2. Tạo một Go module
    3. Gọi mã của bạn từ một module khác
    4. Trả về và xử lý lỗi
    5. Trả về lời chào ngẫu nhiên
    6. Trả về lời chào cho nhiều người
    7. Thêm một test
    8. Biên dịch và cài đặt ứng dụng
    9. Kết luận
    10. Bắt đầu với workspace nhiều module
    11. Phát triển RESTful API với Go và Gin
    12. Truy cập cơ sở dữ liệu quan hệ
    13. Bắt đầu với generics
    14. Bắt đầu với fuzzing
    15. Làm việc với JSON
    16. Tìm và sửa các dependency có lỗ hổng với govulncheck
    17. Tìm và khắc phục phụ thuộc có lỗ hổng với VS Code Go
    18. Viết ứng dụng web
  4. Viết code Go
    1. Cách viết mã Go
    2. Effective Go
    3. Doc Comment trong Go
  5. Module
    1. Phát triển và publish module
    2. Quản lý phụ thuộc
    3. Tổ chức một module Go
    4. Quản lý mã nguồn của module
    5. Cách đánh số phiên bản module
    6. Quy trình phát hành và đánh phiên bản module
    7. Publish một module
    8. Phát triển một bản cập nhật major version
    9. Tham chiếu tệp go.mod
    10. Ngừng hỗ trợ 'go get' cho việc cài đặt tệp thực thi
  6. Cơ sở dữ liệu (Database)
    1. Truy cập cơ sở dữ liệu quan hệ
    2. Mở một handle cơ sở dữ liệu
    3. Thực thi câu lệnh SQL không trả về dữ liệu
    4. Truy vấn dữ liệu
    5. Dùng prepared statement
    6. Thực thi transaction
    7. Huỷ các thao tác đang chạy
    8. Quản lý kết nối
    9. Tránh rủi ro SQL injection
  7. Chẩn đoán và hiệu năng
    1. Chẩn đoán
    2. Hướng dẫn về Go Garbage Collector
    3. Tối ưu hoá dựa trên profile
    4. Data Race Detector
    5. Gỡ lỗi mã Go bằng GDB
    6. Hỗ trợ coverage profiling cho integration test
  8. Bảo mật (Security)
    1. Tổng quan bảo mật
    2. Thực hành tốt về bảo mật cho lập trình viên Go
    3. Quản lý lỗ hổng trong Go
    4. Cơ sở dữ liệu lỗ hổng của Go
    5. Quét lỗ hổng trong IDE
    6. Chính sách CNA của Go
    7. Go Fuzzing
    8. Chi tiết kỹ thuật của Go Fuzzing
    9. Chính sách bảo mật của Go
    10. Threat Model của Go
    11. Các quyết định về bảo mật của Go
    12. Tuân thủ FIPS 140-3
  9. Công cụ và toolchain
    1. Tài liệu về các lệnh
    2. Về lệnh go
    3. Go Toolchains
    4. Telemetry của Go
    5. Cài đặt Go từ mã nguồn
    6. Cài đặt và sử dụng gccgo
  10. Tham khảo
    1. Câu hỏi thường gặp (FAQ)
    2. Go 1 và tương lai của các chương trình Go
    3. Hướng dẫn chuyển đổi sang encoding/json/v2
    4. Hướng dẫn đóng góp
    5. Đóng góp cho frontend gccgo
  11. Phụ lục
    1. Bảng thuật ngữ
Bảo mật (Security)

Chính sách bảo mật của Go

Bản dịch từ go.dev/doc/security/policy

Tổng quan

Tài liệu này giải thích quy trình mà nhóm Go Security dùng để xử lý các vấn đề được báo cáo, và những gì bạn có thể mong đợi nhận lại.

Báo cáo một lỗi bảo mật

Mọi lỗi bảo mật trong bản phân phối Go cần được báo cáo qua email tới [email protected]. Thư này được chuyển tới nhóm Go Security.

Vui lòng đặt tiêu đề email theo dạng “Vulnerability: {package name}: {one-line summary}”, và tránh gửi kèm tệp đính kèm trong email trừ khi thật sự cần thiết, để thư của bạn không bị đánh dấu là spam.

Nếu muốn, vui lòng ghi kèm cách ghi nhận đóng góp (attribution) mà bạn mong muốn trong báo cáo. Phần ghi nhận này sẽ được thêm vào CVE, nếu có CVE được công bố.

Vui lòng viết báo cáo ngắn gọn, bao gồm mô tả vấn đề bạn tìm được, cách mà bạn tin rằng nó có thể bị khai thác, và một test case hoặc chương trình tái hiện nhỏ minh hoạ vấn đề.

Chúng tôi có một danh sách các quyết định về những nhóm vấn đề thường được báo cáo.

Email của bạn sẽ được xác nhận trong vòng 7 ngày. Nếu tới lúc đó bạn vẫn chưa nhận được hồi đáp, vui lòng liên hệ lại với nhóm Go Security tại [email protected]. Hãy chắc chắn rằng từ vulnerability có trong email của bạn.

Nếu sau 3 ngày nữa mà bạn vẫn chưa nhận được xác nhận về báo cáo của mình, có thể email của bạn đã bị đánh dấu là spam. Trong trường hợp đó, vui lòng gửi issue tại đây. Chọn “I want to report a technical security or an abuse risk related bug in a Google product (SQLi, XSS, etc.)”, và ghi “Go” là sản phẩm bị ảnh hưởng.

Vấn đề của bạn sẽ được khắc phục hoặc được công bố trong vòng 90 ngày kể từ xác nhận ban đầu của chúng tôi.

Các email báo cáo vấn đề bảo mật sẽ được lưu giữ vô thời hạn để theo dõi tình trạng khắc phục và ghi nhận đúng công lao của người phát hiện.

Báo cáo do LLM tạo ra

Vui lòng không gửi các báo cáo do LLM tạo ra mà không được chọn lọc kỹ càng.

Các LLM hiện đại rất giỏi trong việc tìm ra những lỗi bảo mật thật sự và quan trọng. Tiếc là chúng cũng rất giỏi trong việc tìm ra những vấn đề tưởng tượng, hoặc những vấn đề có thật nhưng không phải lỗi bảo mật. Đầu ra của LLM thường dài dòng, chôn vùi thông tin quan trọng giữa những đoạn văn không liên quan, và chứa những tuyên bố khoa trương, không có cơ sở.

Với các báo cáo do LLM tạo ra, giá trị nằm ở khâu chọn lọc. Gửi cho chúng tôi hàng chục vấn đề bảo mật khả dĩ rồi trông cậy vào chúng tôi tìm ra kết quả đáng giá duy nhất ẩn trong đó, tức là đẩy việc chọn lọc sang cho chúng tôi, và rốt cuộc cản trở mục tiêu làm cho Go an toàn. Vì lý do đó, chúng tôi chỉ ghi nhận công phát hiện cho những người báo cáo có tỷ lệ phát hiện thật sự đáng kể.

Dù không có quy tắc cứng nhắc nào, nhìn chung có thể hiểu như sau: nếu phần lớn báo cáo của bạn không được xác định là vấn đề bảo mật, và chúng tôi không tin rằng bạn đang đóng góp giá trị chọn lọc hữu ích, thì chúng tôi sẽ không ghi nhận cho bạn bất kỳ phát hiện nào trong số còn lại. Chúng tôi cố ý không định nghĩa một ngưỡng cụ thể cho “phần lớn” hay cho việc “chọn lọc” bao hàm những gì. Tuy nhiên, chủ ý của chúng tôi là một người báo cáo thiện chí, mang lại giá trị thực chất sẽ luôn được ghi nhận, còn người chuyển tiếp một lượng lớn đầu ra của LLM một cách bừa bãi thì không.

Các track

Tuỳ vào bản chất vấn đề của bạn, nhóm Go Security sẽ phân loại nó thành vấn đề thuộc track PUBLIC, PRIVATE hoặc URGENT. Mọi vấn đề bảo mật đều sẽ được cấp số CVE.

Nhóm Go Security không gán các nhãn mức độ nghiêm trọng chi tiết theo kiểu truyền thống (ví dụ CRITICAL, HIGH, MEDIUM, LOW) cho các vấn đề bảo mật, bởi mức độ nghiêm trọng phụ thuộc rất nhiều vào cách người dùng sử dụng API hoặc chức năng bị ảnh hưởng. Ngoài ra, khi cấp CVE cho các vấn đề bảo mật của Go, chúng tôi không gán điểm CVSS, vì chúng tôi về cơ bản không đồng tình với việc áp dụng hệ thống chấm điểm đó cho Go, cũng vì những lý do trên. Các bên thứ ba, chẳng hạn MITRE hay NIST, thông qua NVD, có thể gán điểm CVSS cho các lỗ hổng của chúng tôi, nhưng chúng tôi không xác nhận các điểm số này phản ánh chính xác tác động của chúng.

Ví dụ, tác động của một vấn đề cạn kiệt tài nguyên trong bộ phân tích cú pháp encoding/json phụ thuộc vào thứ đang được phân tích. Nếu người dùng phân tích các tệp JSON tin cậy từ hệ thống tệp cục bộ của họ, tác động nhiều khả năng là thấp. Nếu người dùng phân tích JSON tuỳ ý, không tin cậy, từ phần thân của một HTTP request, tác động có thể cao hơn nhiều.

Dù vậy, các track vấn đề sau đây có thể hiện mức độ nghiêm trọng và/hoặc phạm vi ảnh hưởng mà nhóm Security tin rằng một vấn đề có. Ví dụ, một vấn đề có tác động từ trung bình đến đáng kể với nhiều người dùng là vấn đề track PRIVATE theo chính sách này, còn một vấn đề có tác động từ không đáng kể đến nhỏ, hoặc chỉ ảnh hưởng tới một nhóm nhỏ người dùng, là vấn đề track PUBLIC.

PUBLIC

Các vấn đề thuộc track PUBLIC ảnh hưởng tới những cấu hình ngách, có tác động rất hạn chế, hoặc vốn đã được biết đến rộng rãi.

Các vấn đề track PUBLIC được gắn nhãn Proposal-Security, được thảo luận qua quy trình review proposal của Go, được sửa công khai, và được backport (đưa ngược bản vá về các nhánh cũ) vào các bản phát hành nhỏ kế tiếp theo lịch (diễn ra khoảng hàng tháng). Thông báo phát hành có kèm chi tiết về các vấn đề này, nhưng không có thông báo trước.

Một số ví dụ về các vấn đề PUBLIC trong quá khứ:

  • #44916: archive/zip: có thể panic khi gọi Reader.Open
  • #44913: encoding/xml: vòng lặp vô hạn khi dùng xml.NewTokenDecoder với một TokenReader tuỳ chỉnh
  • #43786: crypto/elliptic: các phép toán sai trên đường cong P-224
  • #40928: net/http/cgi,net/http/fcgi: Cross-Site Scripting (XSS) khi Content-Type không được chỉ định
  • #40618: encoding/binary: ReadUvarint và ReadVarint có thể đọc số byte không giới hạn từ đầu vào không hợp lệ
  • #36834: crypto/x509: bỏ qua kiểm tra hợp lệ chứng chỉ trên Windows 10

PRIVATE

Các vấn đề thuộc track PRIVATE là vi phạm những thuộc tính bảo mật đã cam kết.

Các vấn đề track PRIVATE được sửa trong các bản phát hành nhỏ kế tiếp theo lịch, và được giữ kín cho tới lúc đó.

Ba tới bảy ngày trước khi phát hành, một thông báo trước được gửi tới golang-announce, báo về sự hiện diện của một hoặc nhiều bản vá bảo mật trong các bản phát hành sắp tới, và về việc các vấn đề đó ảnh hưởng tới thư viện chuẩn, toolchain, hay cả hai, cùng với các mã CVE đã được đăng ký cho từng bản vá.

Với những vấn đề tồn tại trong một bản ứng viên phát hành (release candidate) của phiên bản chính, chúng tôi theo cùng quy trình, đưa các bản vá vào bản ứng viên phát hành kế tiếp theo lịch.

Một số ví dụ về các vấn đề PRIVATE trong quá khứ:

  • #53416: path/filepath: cạn kiệt stack trong Glob
  • #53616: go/parser: cạn kiệt stack trong mọi hàm Parse*
  • #54658: net/http: xử lý lỗi phía server sau khi gửi GOAWAY
  • #56284: syscall, os/exec: NUL không được làm sạch trong biến môi trường

URGENT

Các vấn đề track URGENT là mối đe doạ đối với tính toàn vẹn của hệ sinh thái Go, hoặc đang bị khai thác tích cực trong thực tế gây thiệt hại nghiêm trọng. Không có ví dụ gần đây, nhưng chúng sẽ bao gồm những trường hợp như thực thi mã từ xa trong net/http, hoặc khôi phục khoá một cách khả thi trong crypto/tls.

Các vấn đề track URGENT được sửa kín, và kích hoạt ngay một bản phát hành bảo mật riêng, có thể không có thông báo trước.

Đánh dấu các issue đã có là liên quan tới bảo mật

Nếu bạn tin rằng một issue đã có là liên quan tới bảo mật, chúng tôi mong bạn gửi email tới [email protected]. Email nên bao gồm ID của issue và mô tả ngắn gọn vì sao nó cần được xử lý theo chính sách bảo mật này.

Quy trình công bố

Dự án Go dùng quy trình công bố (disclosure) sau:

  1. Khi báo cáo bảo mật được tiếp nhận, nó được giao cho một người xử lý chính. Người này điều phối quy trình vá và phát hành.

  2. Vấn đề được xác nhận và danh sách phần mềm bị ảnh hưởng được xác định.

  3. Mã nguồn được rà soát để tìm mọi vấn đề tương tự có thể có.

  4. Nếu xác định, sau khi trao đổi với người gửi báo cáo, rằng cần một số CVE, người xử lý chính sẽ xin cấp một số CVE.

  5. Các bản vá được chuẩn bị cho hai phiên bản chính gần nhất và bản head/master. Các bản vá được chuẩn bị cho hai phiên bản chính gần nhất và được merge vào head/master.

  6. Vào ngày các bản vá được áp dụng, thông báo được gửi tới golang-announce, golang-dev, và golang-nuts.

Quy trình này có thể mất một thời gian, nhất là khi cần phối hợp với maintainer của các dự án khác. Chúng tôi sẽ nỗ lực hết sức để xử lý lỗi nhanh nhất có thể, tuy nhiên điều quan trọng là chúng tôi phải theo đúng quy trình mô tả ở trên để bảo đảm việc công bố được xử lý nhất quán.

Với các vấn đề bảo mật có kèm việc cấp số CVE, vấn đề được liệt kê công khai tại sản phẩm “Golang” trên website CVEDetails cũng như tại trang National Vulnerability Disclosure.

Nhận các bản cập nhật bảo mật

Cách tốt nhất để nhận thông báo bảo mật là đăng ký danh sách thư golang-announce. Mọi thư liên quan tới một vấn đề bảo mật sẽ có tiền tố [security].

Góp ý về chính sách này

Nếu bạn có bất kỳ đề xuất nào để cải thiện chính sách này, vui lòng gửi issue để thảo luận.

Nội dung gốc: Go Documentation © The Go Authors, giấy phép CC BY 3.0. Bản dịch và ghi chú: Lê Văn Dũng.