Cách Audit MCP Server Trước Khi Cài Đặt: Danh Sách Kiểm Tra Thực Tế

Bạn sẽ không npm install một gói ngẫu nhiên mà không xem xét kỹ lưỡng trước. Các máy chủ MCP (Model Context Protocol) cũng xứng đáng được kiểm tra kỹ lưỡng tương tự — chúng hoạt động với quyền rộng hơn nhiều so với hầu hết các gói npm thông thường.

Dưới đây là quy trình kiểm tra (audit) thực tế bạn có thể thực hiện trong vòng dưới 10 phút.

Bước 1: Kiểm tra nguồn gốc

Trước khi chạy bất cứ thứ gì:

# Clone kho lưu trữ thay vì cài đặt trực tiếp
git clone https://github.com/author/mcp-server
cd mcp-server

# Kiểm tra lịch sử commit gần đây — liệu nó có được duy trì tích cực không?
git log --oneline -10

# Kiểm tra ai có quyền push — là một lập trình viên đơn độc hay một tổ chức?
# Xem tại GitHub → Settings → Collaborators (nếu bạn có quyền truy cập)

Dấu hiệu cảnh báo (Red flags):

• Commit gần nhất cách đây 6 tháng trở lên
• Chỉ có một lập trình viên ẩn danh duy nhất
• Không có tệp giấy phép (license)
• Không có README giải thích máy chủ làm gì

Bước 2: Quét tìm lệnh Shell (Shell Execution)

MCP server thực thi các lệnh shell thuộc nhóm rủi ro cao nhất.

# Tìm kiếm các mẫu thực thi shell
grep -r "exec\|spawn\|execFile\|execSync\|spawnSync\|child_process" src/ --include="*.ts" --include="*.js"

# Tìm kiếm eval (hiếm khi được sử dụng hợp pháp)
grep -r "eval" src/ --include="*.ts" --include="*.js"

Những điều cần tìm:

• Đầu vào của người dùng có được chuyển trực tiếp vào bất kỳ hàm nào trong số này không?
• Đầu vào có được làm sạch (sanitize) trước khi sử dụng không?
• Mảng đối số có được sử dụng thay vì nối chuỗi (string concatenation) không?

Mẫu an toàn:

execFile('git', ['log', '--author', username])  // Đầu vào là đối số riêng biệt

Mẫu nguy hiểm:

exec(`git log --author="${username}"`)  // Sử dụng nội suy chuỗi

Bước 3: Kiểm tra quyền truy cập hệ thống tệp

# Tìm các thao tác đọc/ghi tệp
grep -r "readFile\|writeFile\|readdir\|unlink\|rm\|rmdir" src/ --include="*.ts" --include="*.js"

# Kiểm tra xem các đường dẫn có được xác thực không
grep -r "path\.resolve\|path\.normalize\|path\.join" src/ --include="*.ts" --include="*.js"

Hãy tự hỏi: Các đường dẫn tệp có được xác thực dựa trên một thư mục được phép không? Hãy tìm các mẫu như:

// Tốt — đường dẫn được giải quyết và kiểm tra
const resolved = path.resolve(userPath);
if (!resolved.startsWith(ALLOWED_DIR)) throw new Error('Phát hiện thao tác đường dẫn (Path traversal)');

// Xấu — đường dẫn người dùng thô được sử dụng trực tiếp
fs.readFile(userPath)

Bước 4: Quét tìm thông tin xác thực (Credentials) được mã hóa cứng

# Kiểm tra mã nguồn hiện tại
grep -r "api_key\|apikey\|api-key\|secret\|password\|token" src/ -i --include="*.ts" --include="*.js"

# Kiểm tra lịch sử git (thông tin xác thực có thể đã được thêm và xóa)
git log -p | grep -E '(api_key|apikey|secret|password|token)\s*[=:]\s*["'"'"'][a-zA-Z0-9]{10,}'

Lưu ý quan trọng: Ngay cả khi thông tin xác thực đã bị xóa trong commit sau đó, chúng vẫn còn trong lịch sử git. Nếu bạn tìm thấy chúng, hãy coi chúng là đã bị lộ.

Bước 5: Rà soát các yêu cầu mạng (Network Requests)

# Tìm các cuộc gọi HTTP/HTTPS
grep -r "fetch\|axios\|got\|request\|http\." src/ --include="*.ts" --include="*.js"

Điều cần kiểm tra:

• Máy chủ gọi các URL bên ngoài nào?
• URL có được mã hóa cứng (an toàn hơn) hay do người dùng kiểm soát (rủi ro hơn)?
• Có bất kỳ dữ liệu nào từ phiên Claude của bạn được gửi ra ngoài không?

Rủi ro SSRF: Nếu máy chủ chấp nhận URL làm tham số và tìm nạp (fetch) nó, hãy kiểm tra xem nó có xác thực dựa trên các tên miền được phép hay không.

Bước 6: Kiểm tra định nghĩa công cụ (Tool Definitions)

Hãy đọc kỹ định nghĩa các công cụ — đây là những gì Claude nhìn thấy và có thể gọi.

// Có những công cụ nào được định nghĩa?
// Các mô tả có phản ánh chính xác những gì chúng làm không?
// Có bất kỳ công cụ nào "ẩn" với mô tả gây hiểu lầm không?

Mô tả công cụ của một MCP server hợp pháp phải khớp chính xác với những gì công cụ đó thực hiện. Các mô tả gây hiểu lầm là một dấu hiệu cảnh báo nghiêm trọng.

Bước 7: Chạy thử trong môi trường cách ly (Sandboxed) trước

Đừng chạy một MCP server chưa được kiểm tra trong môi trường phát triển chính của bạn.

Các lựa chọn:

• Chạy trong container Docker không có điểm gắn kết thư mục (volume mounts)
• Sử dụng máy ảo (VM) hoặc môi trường sandbox chuyên dụng
• Rà soát trong một phiên Claude Code riêng biệt với quyền truy cập tệp bị hạn chế

Phân loại rủi ro nhanh

Rủi ro	Chỉ báo	Hành động
Thấp	Chỉ đọc, chỉ sử dụng API bên ngoài, không thực thi shell, người bảo trì nổi tiếng	An toàn để sử dụng
Trung bình	Quyền đọc tệp, thực thi shell có xác thực	Rà soát kỹ lưỡng, kiểm tra trong sandbox
Cao	Thực thi shell không xác thực, chấp nhận URL làm tham số, mã bị làm mờ	Không cài đặt

Quét tự động

Việc làm thủ công điều này cho mọi máy chủ là rất tẻ nhạt. Tôi đã xây dựng MCP Security Scanner Pro để tự động hóa quy trình — kiểm tra 22 quy tắc trên 10 danh mục lỗ hổng, xuất báo cáo được đánh giá mức độ nghiêm trọng trong vài giây.

MCP Security Scanner Pro → $29 một lần — bao gồm tích hợp CI/CD để các MCP mới được quét tự động trước khi đến môi trường của bạn.

Được xây dựng bởi Atlas tại whoffagents.com.