Tôi gửi một tài liệu XML có 'thực thể ngoài' trỏ vào /etc/passwd, và một parser cấu hình sai trả về nguyên danh sách người dùng hệ thống. Nhưng điều bất ngờ là bốn trong sáu cấu hình tôi thử đã mặc định an toàn. XXE ngày nay phần lớn là lỗi bật nhầm một cái cờ.
HTTP dựng cấu trúc trên một ký tự vô hình: cặp CRLF. Tôi dựng lại lỗ header injection — một \r\n trong giá trị người dùng tạo header giả và cả một thân phản hồi giả — rồi đo cách http.client và Werkzeug từ chối nó ngay. Lỗ chỉ còn sống khi bạn tự nối chuỗi response thô, và nó là cùng một con quái vật với SQL injection, XSS, command injection.
Thông báo lỗi sinh ra để giúp lập trình viên — và khi hiện cho người dùng, nó giúp luôn kẻ tấn công. Tôi đo lượng thông tin rò ở chế độ debug so với production: gấp ~700 lần, và một lỗi SQL nguyên văn phơi cả tên bảng lẫn câu truy vấn. Bài học: thông báo chung ra ngoài, log chi tiết vào trong.
Một timing side channel: cách bạn so sánh token với bí mật để lộ token đúng tới đâu — không qua nội dung, mà qua thời gian. Byte-by-byte dừng sớm rò tuyến tính ~9 ns/byte; compare_digest giữ 666 ns bất biến. Và một bất ngờ: == của Python lại KHÔNG lộ, vì một lý do đáng nhớ.
DoS thường được hình dung là cơn lũ lưu lượng. Nhưng loại nguy hiểm hơn chỉ cần một request nhỏ mà đắt: regex 30 ký tự làm máy chủ bận 20 giây, 49 KB nén giải ra 50 MB, chính cơ chế băm mật khẩu chậm trở thành vũ khí. Bốn kiểu bất đối xứng, đo thật.
Kẻ tấn công parse không chỉ điều khiển kích thước dữ liệu mà cả cấu trúc của nó, và mỗi chiều đánh vào một tài nguyên khác nhau: JSON lồng sâu 100.000 cấp (195 KB) làm tràn stack, một số 100.000 chữ số đốt CPU O(n²), một mảng 5 triệu phần tử ngốn RAM. Tôi đo cả ba, và cho thấy vì sao giới hạn kích thước body — biện pháp phổ biến nhất — chỉ chặn được đúng một trục.