Mô hình mối đe doạ bắt đầu bằng câu 'ứng dụng của tôi có những cửa nào'. Tôi đếm thật trên một app Flask: 8 route trong đầu, nhưng Flask đăng ký 31 cặp và 37 điểm trả lời từ bên ngoài. Framework tự mọc HEAD, OPTIONS, /static — những cửa bạn chưa bao giờ viết và chưa bao giờ bảo vệ.
Bốn cách chặn SQL injection, đo trên ứng dụng thật. Lọc dấu nháy và thoát ký tự bằng tay trông chắc chắn ngang tham số hoá — trong đúng một ngữ cảnh. Payload '0 OR 1=1' không có lấy một dấu nháy, và nó phơi cả bảng. Chỉ tham số hoá đứng vững, vì lý do sâu hơn 'chặn ký tự xấu'.
Tham số hoá là cách chặn SQL injection duy nhất thật sự đủ — nhưng chỉ ở vị trí giá trị. Có một chỗ nó không đặt vào được: tên cột trong ORDER BY. Tôi đo ở đó và đọc trọn một khoá bí mật không route nào hiển thị, một bit mỗi request, 144 request cho cả chuỗi.
SQL không phải nơi duy nhất trộn dữ liệu vào mã. Tôi dựng lại cùng lỗ hổng trên lệnh hệ thống (bộ lọc quên ký tự xuống dòng để lọt) và LDAP (mật khẩu '*' thành admin không cần biết mật khẩu). Cùng một lỗ mặc ba bộ quần áo, cùng một cách chặn: tách dữ liệu khỏi mã.
Tôi không đếm xem payload có mặt trong HTML hay không — tôi mở Chromium thật và chờ hộp thoại alert bật lên. Autoescape thắng mọi payload trong nội dung HTML, nhưng để lọt trơn khi biến rơi vào href. Bài học: chặn đúng cho ngữ cảnh này không tự nhiên đủ cho ngữ cảnh kia.
Tôi dựng một trang có năm đường chạy JavaScript, đổi header CSP và dùng Chromium thật xem đường nào bị chặn. Kết quả: 'self' làm nhiều hơn tên gọi (chặn luôn inline và eval — đúng chỗ XSS sống), 'unsafe-inline' mở lại đúng cánh cửa CSP sinh ra để đóng, và 'unsafe-eval' vô dụng nếu đứng một mình. Kèm một bài học đo lường: công cụ đo suýt bị chính thứ nó đang đo chặn lại.