☰ 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)

Cơ sở dữ liệu lỗ hổng của Go

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

Quay lại Quản lý lỗ hổng trong Go

Tổng quan

Vulnerability database (cơ sở dữ liệu lỗ hổng) của Go (https://vuln.go.dev) cung cấp thông tin về lỗ hổng trong Go theo lược đồ Open Source Vulnerability (OSV).

Bạn cũng có thể duyệt các lỗ hổng trong cơ sở dữ liệu tại pkg.go.dev/vuln.

Đừng dựa vào nội dung của kho Git x/vulndb. Các tệp YAML trong kho đó được duy trì theo một định dạng nội bộ có thể thay đổi mà không báo trước.

Đóng góp

Chúng tôi rất mong mọi maintainer của package Go đóng góp thông tin về các lỗ hổng công khai trong chính dự án của họ, và cập nhật thông tin sẵn có về những lỗ hổng trong package Go của họ.

Chúng tôi hướng tới việc làm cho quy trình report trở nên ít rào cản nhất, nên bạn cứ thoải mái gửi cho chúng tôi các đề xuất của bạn.

Vui lòng đừng dùng các biểu mẫu ở trên để báo cáo lỗ hổng trong thư viện chuẩn của Go hoặc các kho con. Thay vào đó, hãy làm theo quy trình tại go.dev/security/policy cho các lỗ hổng liên quan tới dự án Go.

API

Cơ sở dữ liệu lỗ hổng chính thức của Go, https://vuln.go.dev, là một máy chủ HTTP có thể đáp ứng các request GET tới những endpoint được nêu dưới đây.

Các endpoint không có tham số truy vấn, và không yêu cầu header đặc biệt nào. Vì vậy, ngay cả một site phục vụ từ một hệ thống tệp cố định (kể cả URL dạng file://) cũng có thể hiện thực API này.

Mỗi endpoint trả về một response được mã hóa JSON, ở dạng không nén (nếu được yêu cầu dưới dạng .json) hoặc dạng nén gzip (nếu được yêu cầu dưới dạng .json.gz).

Các endpoint gồm:

  • /index/db.json[.gz]

    Trả về siêu dữ liệu về cơ sở dữ liệu:

    {
      // The latest time the database should be considered
      // to have been modified, as an RFC3339-formatted UTC
      // timestamp ending in "Z".
      "modified": string
    }

    Lưu ý rằng thời điểm modified không nên được so sánh với thời gian đồng hồ thực, ví dụ cho mục đích vô hiệu hóa cache, vì có thể có độ trễ trong việc đưa các thay đổi của cơ sở dữ liệu lên hệ thống.

    Xem /index/db.json để có ví dụ thực tế.

  • /index/modules.json[.gz]

    Trả về một danh sách chứa siêu dữ liệu về từng module trong cơ sở dữ liệu:

    [ {
      // The module path.
      "path": string,
      // The vulnerabilities that affect this module.
      "vulns":
        [ {
          // The vulnerability ID.
          "id": string,
          // The latest time the vulnerability should be considered
          // to have been modified, as an RFC3339-formatted UTC
          // timestamp ending in "Z".
          "modified": string,
          // (Optional) The module version (in SemVer 2.0.0 format)
          // that contains the latest fix for the vulnerability.
          // If unknown or unavailable, this should be omitted.
          "fixed": string,
        } ]
    } ]

    Xem /index/modules.json để có ví dụ thực tế.

  • /index/vulns.json[.gz]

    Trả về một danh sách chứa siêu dữ liệu về từng lỗ hổng trong cơ sở dữ liệu:

    [ {
        // The vulnerability ID.
        "id": string,
        // The latest time the vulnerability should be considered
        // to have been modified, as an RFC3339-formatted UTC
        // timestamp ending in "Z".
        "modified": string,
        // A list of IDs of the same vulnerability in other databases.
        "aliases": [ string ]
    } ]

    Xem /index/vulns.json để có ví dụ thực tế.

  • /ID/$id.json[.gz]

    Trả về report riêng lẻ cho lỗ hổng có ID là $id, theo định dạng OSV (mô tả bên dưới trong phần Schema).

    Xem /ID/GO-2022-0191.json để có ví dụ thực tế.

Tải hàng loạt

Để việc tải toàn bộ cơ sở dữ liệu lỗ hổng của Go dễ dàng hơn, một tệp zip chứa tất cả các tệp index và tệp OSV được cung cấp tại vuln.go.dev/vulndb.zip.

Sử dụng trong govulncheck

Mặc định, govulncheck dùng cơ sở dữ liệu lỗ hổng chính thức của Go tại vuln.go.dev.

Câu lệnh này có thể được cấu hình để liên hệ với một vulnerability database khác bằng cờ -db, cờ này nhận một URL của vulnerability database với giao thức http://, https://, hoặc file://.

Để hoạt động đúng với govulncheck, vulnerability database được chỉ định phải hiện thực API mô tả ở trên. Câu lệnh govulncheck dùng các endpoint “.json.gz” đã nén khi đọc từ nguồn http(s), và các endpoint “.json” khi đọc từ nguồn là tệp.

API cũ

Cơ sở dữ liệu chính thức chứa một số endpoint bổ sung thuộc về một API cũ. Chúng tôi dự định sớm gỡ bỏ hỗ trợ cho các endpoint này. Nếu bạn đang dựa vào API cũ và cần thêm thời gian để chuyển đổi, hãy cho chúng tôi biết.

Schema

Các report dùng lược đồ Open Source Vulnerability (OSV). Cơ sở dữ liệu lỗ hổng của Go gán những ý nghĩa sau cho các trường:

id

Trường id là định danh duy nhất cho một mục lỗ hổng. Nó là một chuỗi có định dạng GO-<YEAR>-<ENTRYID>.

affected

Trường affected là một mảng JSON chứa các object mô tả những phiên bản module có chứa lỗ hổng.

affected[].package

Trường affected[].package là một object JSON xác định module bị ảnh hưởng. Object này có hai trường bắt buộc:

  • ecosystem: trường này luôn là “Go”
  • name: đây là module path của Go
    • Các package có thể import được trong thư viện chuẩn sẽ có name là stdlib.
    • Lệnh go sẽ có name là toolchain.

affected[].ecosystem_specific

Trường affected[].ecosystem_specific là một object JSON chứa thông tin bổ sung về lỗ hổng, được các công cụ phát hiện lỗ hổng của Go sử dụng.

Hiện tại, ecosystem specific sẽ luôn là một object với một trường duy nhất, imports.

affected[].ecosystem_specific.imports

Trường affected[].ecosystem_specific.imports là một mảng JSON chứa các package và ký hiệu bị ảnh hưởng bởi lỗ hổng. Mỗi object trong mảng sẽ có hai trường sau:

  • path: một chuỗi chứa import path của package chứa lỗ hổng
  • symbols: một mảng chuỗi gồm tên các ký hiệu (hàm hoặc method) chứa lỗ hổng
  • goos: một mảng chuỗi gồm các hệ điều hành thực thi nơi các ký hiệu xuất hiện, nếu biết
  • goarch: một mảng chuỗi gồm các kiến trúc nơi các ký hiệu xuất hiện, nếu biết

database_specific

Trường database_specific chứa các trường tùy chỉnh riêng cho cơ sở dữ liệu lỗ hổng của Go.

database_specific.url

Trường database_specific.url là một chuỗi biểu diễn URL đầy đủ của report lỗ hổng trong Go, ví dụ “https://pkg.go.dev/vuln/GO-2023-1621”.

database_specific.review_status

Trường database_specific.review_status là một chuỗi biểu diễn trạng thái rà soát của report lỗ hổng. Nếu không có, report nên được coi là REVIEWED. Các giá trị có thể có là:

  • UNREVIEWED: Report được sinh tự động dựa trên một nguồn khác, chẳng hạn một CVE hoặc GHSA. Dữ liệu của nó có thể hạn chế và chưa được đội ngũ Go kiểm chứng.
  • REVIEWED: Report bắt nguồn từ đội ngũ Go, hoặc được sinh ra dựa trên một nguồn bên ngoài. Một thành viên của đội ngũ Go đã rà soát report, và khi cần thiết, đã bổ sung thêm dữ liệu.

Để biết thông tin về các trường khác trong schema, hãy tham khảo đặc tả OSV.

Ghi chú về phiên bản

Bộ công cụ của chúng tôi cố gắng tự động ánh xạ các module và phiên bản trong những khuyến cáo nguồn sang module và phiên bản Go chính thức, theo đúng quy ước số phiên bản module của Go. Những công cụ như govulncheck được thiết kế để dựa vào các phiên bản chuẩn này nhằm xác định một dự án Go có bị ảnh hưởng bởi lỗ hổng trong một phụ thuộc hay không.

Trong một số trường hợp, chẳng hạn khi một dự án Go dùng lược đồ đánh phiên bản riêng, việc ánh xạ sang phiên bản Go chuẩn có thể thất bại. Khi điều đó xảy ra, report trong cơ sở dữ liệu lỗ hổng của Go có thể liệt kê một cách thận trọng tất cả phiên bản Go là bị ảnh hưởng. Điều này đảm bảo những công cụ như govulncheck không bỏ sót việc report lỗ hổng do khoảng phiên bản không nhận diện được (âm tính giả). Tuy nhiên, việc thận trọng liệt kê mọi phiên bản là bị ảnh hưởng có thể khiến các công cụ báo nhầm rằng một phiên bản đã được khắc phục của module vẫn chứa lỗ hổng (dương tính giả).

Nếu bạn cho rằng govulncheck đang report sai (hoặc bỏ sót) một lỗ hổng, vui lòng đề xuất chỉnh sửa cho report lỗ hổng đó và chúng tôi sẽ xem xét.

Ví dụ

Mọi lỗ hổng trong cơ sở dữ liệu lỗ hổng của Go đều dùng lược đồ OSV đã mô tả ở trên.

Xem các liên kết dưới đây để có ví dụ về những loại lỗ hổng khác nhau trong Go:

  • Lỗ hổng trong thư viện chuẩn của Go (GO-2022-0191): JSON, HTML
  • Lỗ hổng trong toolchain của Go (GO-2022-0189): JSON, HTML
  • Lỗ hổng trong module Go (GO-2020-0015): JSON, HTML

Các report bị loại trừ

Các report trong cơ sở dữ liệu lỗ hổng của Go được thu thập từ nhiều nguồn khác nhau và được đội ngũ Bảo mật của Go tuyển chọn. Chúng tôi có thể gặp một khuyến cáo lỗ hổng (ví dụ một CVE hoặc GHSA) và chọn loại trừ nó vì nhiều lý do. Trong những trường hợp đó, một report tối giản sẽ được tạo trong kho x/vulndb, tại x/vulndb/data/excluded.

Report có thể bị loại trừ vì những lý do sau:

  • NOT_GO_CODE: Lỗ hổng không nằm trong package Go, nhưng nó được một nguồn khác đánh dấu là khuyến cáo bảo mật cho hệ sinh thái Go. Lỗ hổng này không thể ảnh hưởng tới bất kỳ package Go nào. (Ví dụ, một lỗ hổng trong thư viện C++.)
  • NOT_IMPORTABLE: Lỗ hổng xuất hiện trong package main, một package internal/ chỉ được package main import, hoặc một vị trí nào đó không bao giờ có thể được module khác import.
  • EFFECTIVELY_PRIVATE: Dù lỗ hổng xuất hiện trong một package Go có thể được module khác import, package đó không dành cho việc dùng từ bên ngoài và nhiều khả năng sẽ không bao giờ được import ngoài module nơi nó được định nghĩa.
  • DEPENDENT_VULNERABILITY: Lỗ hổng này là tập con của một lỗ hổng khác trong cơ sở dữ liệu. Ví dụ, nếu package A chứa một lỗ hổng, package B phụ thuộc vào package A, và có các mã CVE riêng cho package A và B, chúng tôi có thể đánh dấu report cho B là lỗ hổng phụ thuộc, hoàn toàn được thay thế bởi report cho A.
  • NOT_A_VULNERABILITY: Dù đã có một mã CVE hoặc GHSA được cấp, không có lỗ hổng nào được biết đến gắn với nó.
  • WITHDRAWN: Lỗ hổng đã bị nguồn của nó rút lại.

Hiện tại, các report bị loại trừ không được phục vụ qua API vuln.go.dev. Tuy nhiên, nếu bạn có một trường hợp sử dụng cụ thể và việc truy cập được thông tin này qua API là hữu ích, hãy cho chúng tôi biết.

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.