Tôi đã kiểm tra bảo mật cho các dự án cá nhân của mình — Đây là những gì tôi tìm thấy
Gần đây tôi đã tiến hành kiểm tra bảo mật (audit) cho tất cả các dự án cá nhân của mình. Tôi đã kiểm tra các backend FastAPI, bot Telegram và các ứng dụng web. Tôi cứ ngỡ mình đã rất cẩn thận.
Tôi đã lầm.
Tôi đã tìm thấy những lỗi thực sự mà tôi đã lỡ đưa lên môi trường production. Đây không phải là những vấn đề lý thuyết. Đó là những sai lầm tôi mắc phải trong quá trình cố gắng phát triển nhanh.
Dưới đây là những vấn đề chính mà tôi tìm thấy và cách khắc phục chúng:
- Xác thực có điều kiện (Conditional Authentication) Tôi đã viết mã chỉ kiểm tra API key nếu có tồn tại một mã bí mật (secret). Nếu tôi quên thiết lập secret trong môi trường (environment), bước kiểm tra này sẽ bị bỏ qua hoàn toàn. Điều này khiến API của tôi bị hở cho tất cả mọi người.
- Cách khắc phục: Đừng bao giờ để việc xác thực phụ thuộc vào điều kiện. Nếu thiếu secret, ứng dụng phải báo lỗi và dừng lại.
- Rò rỉ Key trong lịch sử Git
Tôi đã tìm thấy các API key cũ trong lịch sử Git của mình. Sau đó tôi đã chuyển chúng sang các tệp
.env, nhưng Git sẽ lưu giữ mọi phiên bản cũ của mã nguồn mãi mãi.
- Cách khắc phục: Hãy coi bất kỳ key nào từng được commit lên Git là đã bị lộ. Hãy thu hồi (revoke) nó ngay lập tức. Sử dụng các công cụ như
git-filter-repođể làm sạch lịch sử của bạn.
- Các endpoint debug còn sót lại Tôi đã để lại các endpoint trong môi trường production vốn hiển thị cấu hình cơ sở dữ liệu và các thiết lập hệ thống. Chúng rất hữu ích trong quá trình phát triển nhưng lại cực kỳ nguy hiểm khi triển khai thực tế.
- Cách khắc phục: Hãy thêm bước xóa các endpoint debug vào danh sách kiểm tra (checklist) khi triển khai (deployment).
- Thông báo lỗi quá chi tiết Tôi đã trả về các lỗi hệ thống thô cho người dùng. Những lỗi này tiết lộ đường dẫn tệp, loại cơ sở dữ liệu và phiên bản thư viện của bạn. Kẻ tấn công có thể sử dụng dữ liệu này để nhắm mục tiêu vào hệ thống của bạn.
- Cách khắc phục: Hãy ghi log (log) đầy đủ lỗi nội bộ để bạn tự kiểm tra. Chỉ trả về thông báo "Internal Server Error" chung chung cho phía client.
- XSS thông qua
innerHTMLTôi đã sử dụnginnerHTMLđể hiển thị dữ liệu người dùng ở frontend. Điều này cho phép kẻ tấn công chèn các đoạn mã script vào trang web của bạn.
- Cách khắc phục: Luôn luôn làm sạch dữ liệu (sanitize) hoặc sử dụng
textContentthay vìinnerHTML.
- Thiếu giới hạn tốc độ (Rate Limiting) Tôi có các endpoint gọi các mô hình AI đắt đỏ mà không có giới hạn. Một người dùng có thể làm phát sinh hóa đơn khổng lồ chỉ trong vài phút.
- Cách khắc phục: Xác thực (Authentication) giúp ngăn chặn người dùng không được phép. Giới hạn tốc độ (Rate limiting) giúp ngăn chặn người dùng đã được xác thực lạm dụng hệ thống của bạn. Bạn cần cả hai.
- Cấu hình CORS quá lỏng lẻo
Tôi đã sử dụng
allow_origins=["*"]trong middleware của mình. Điều này cho phép bất kỳ trang web nào cũng có thể gửi yêu cầu đến API của bạn.
- Cách khắc phục: Chỉ cho phép các domain cụ thể của bạn trong môi trường production.
- Rò rỉ file Tôi đã viết mã tạo ra các tệp tạm thời nhưng lại không xóa chúng nếu quá trình bị crash. Những tệp này sẽ tồn tại vĩnh viễn trên máy chủ của bạn.
- Cách khắc phục: Sử dụng khối try-finally để đảm bảo các tệp được xóa ngay cả khi có lỗi xảy ra.
Các vấn đề bảo mật hiếm khi là do cố ý. Chúng là kết quả của việc nói rằng "Tôi sẽ sửa lỗi này sau." Nhưng cái "sau đó" ấy chẳng bao giờ đến.
Hãy đưa bảo mật vào quy trình làm việc của bạn ngay từ ngày đầu tiên. Kiểm tra mã của bạn trước khi commit và trước khi deploy.
Nguồn: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb