Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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'.
Tôi dựng một cuộc tấn công từ điển thật vào mười bản băm và đo: mật khẩu yếu bị bẻ 6/10 dù dùng bcrypt, còn mật khẩu mạnh biến từ '4 ngày trên SHA256' thành '3.800 năm trên bcrypt'. Hai lớp phòng thủ — mật khẩu mạnh và thuật toán chậm — nhân nhau chứ không cộng, và thiếu một lớp là sụp về mức của lớp yếu hơn.
Phản xạ khi lỡ commit một khoá là xoá dòng, commit lại, thở phào. Tôi đo hai điều cái thở phào bỏ qua: xoá khỏi file không xoá khỏi lịch sử git (quét working-tree 0, quét lịch sử 2), và viết lại lịch sử không vô hiệu credential — token vẫn sống qua rebase/force-push, chỉ chết khi xoay vòng. Lỡ lộ thì xoay vòng trước, dọn git sau.
Máy chủ tự báo 0,673 ms, người dùng thật chờ 151,255 ms — nó mù 99,6% thời gian. Tôi đo khoảng cách đó khi thêm độ trễ mạng, và phát hiện kích thước phản hồi chỉ lộ ra khi có độ trễ (chênh 2,2% trên mạng nhanh thành 128% khi thêm 50 ms), còn keep-alive tiết kiệm đúng một vòng khứ hồi. Ba con số trong bảng là ba đại lượng khác nhau, không phải ba mức chính xác của một đại lượng.
Cho đúng một chặng giữa chuỗi quên chuyển tiếp header traceparent, cái cây trace tách làm hai — mà không dịch vụ nào báo lỗi, cả hai mảnh đều 'khoẻ mạnh'. Cộng lấy mẫu 10%, tỷ lệ yêu cầu có trace đầy đủ rơi từ 9,93% xuống 1,01%. Mỗi chỗ gãy không cộng chi phí, nó nhân.
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.