Web Security Basics Every Developer Must Know — txt1.ai

Bởi Marcus Chen, Kỹ Sư An Ninh Cao Cấp tại một công ty fintech Fortune 500 với 12 năm kinh nghiệm cải thiện bảo mật cho các ứng dụng web xử lý hơn 2 tỷ đô la trong giao dịch hàng ngày

Ba năm trước, tôi đã thấy một lập trình viên mới đưa mã lên sản xuất vào lúc 4:47 chiều thứ Sáu. Đến 6:15 chiều, trung tâm điều hành bảo mật của chúng tôi đã sáng như cây thông Giáng sinh. Một lỗ hổng SQL injection trong một tính năng tìm kiếm có vẻ vô hại đã làm lộ 340,000 hồ sơ khách hàng. Sự cố đã tiêu tốn của chúng tôi 4.2 triệu đô la cho việc khắc phục, phạt hành chính và mất doanh thu. Lập trình viên? Một kỹ sư xuất sắc nhưng đơn giản là không biết những gì họ không biết về bảo mật web.

Sự cố đó đã thay đổi cách tôi tiếp cận giáo dục an ninh. Tôi nhận ra rằng hầu hết các lập trình viên không liều lĩnh — họ chỉ đang hoạt động trong một môi trường thiếu kiến thức. Các chương trình khoa học máy tính dành có thể hai tuần cho bảo mật, nếu bạn may mắn. Các trại huấn luyện thường bỏ qua hoàn toàn. Tuy nhiên, chúng tôi được kỳ vọng xây dựng những pháo đài trong khi chỉ hiểu cách xếp gạch.

Tôi đã trải qua một thập kỷ ở trong lĩnh vực bảo mật web, từ thử nghiệm thâm nhập đến xây dựng các khung bảo mật được sử dụng bởi các nhóm có hơn 200 lập trình viên. Tôi đã thấy các cuộc tấn công phát triển từ những nỗ lực thô sơ của kẻ tội phạm cho đến những hoạt động tinh vi của quốc gia. Và tôi đã học rằng các nguyên tắc cơ bản — những điều mà mọi lập trình viên phải lưu nội tâm — không thay đổi nhiều như bạn nghĩ. Làm chủ những nguyên tắc cốt lõi này, bạn sẽ ngăn chặn 90% các lỗ hổng tôi thấy trong mã sản xuất mỗi ngày.

Hiểu Về Bề Mặt Tấn Công: Những Gì Bạn Thực Sự Đang Bảo Vệ

Khi tôi hỏi các lập trình viên về những gì họ đang bảo vệ, tôi thường nghe "dữ liệu người dùng" hoặc "cơ sở dữ liệu." Điều đó không sai, nhưng chưa đủ. Bề mặt tấn công của bạn là từng điểm mà ứng dụng của bạn chấp nhận đầu vào, xử lý dữ liệu hoặc tương tác với các hệ thống bên ngoài. Nó chính là mẫu đăng nhập, nhưng cũng là điểm cuối API mà bạn đã viết chỉ để sử dụng nội bộ, tính năng tải lên tệp trong bảng điều khiển quản trị, và thậm chí là thông báo lỗi mà bạn hiển thị cho người dùng.

Cho phép tôi cho bạn một ví dụ cụ thể từ kinh nghiệm của tôi. Chúng tôi có một điểm cuối API nội bộ chấp nhận tải trọng JSON cho các bản cập nhật người dùng hàng loạt. Nó là "chỉ nội bộ" — không yêu cầu xác thực vì nó chỉ có thể truy cập từ VPN của chúng tôi. Nhưng một ai đó đã cấu hình nhầm một proxy ngược, và đột nhiên điểm cuối đó bị lộ ra internet trong khoảng 18 giờ trước khi chúng tôi phát hiện ra. Trong 18 giờ đó, các công cụ quét tự động đã tìm thấy nó và cố gắng 2,847 cách tấn công khác nhau.

Bề mặt tấn công bao gồm mọi phụ thuộc trong package.json hoặc requirements.txt của bạn. Khi lỗ hổng Log4Shell xuất hiện vào tháng 12 năm 2021, tôi đã dành 72 giờ liên tiếp giúp các đội xác định và sửa lỗi hệ thống bị ảnh hưởng. Lỗ hổng không nằm trong mã mà chúng tôi đã viết - nó ở một thư viện ghi log mà là một phụ thuộc của một phụ thuộc của một phụ thuộc. Bề mặt tấn công của bạn kéo dài qua toàn bộ cây phụ thuộc của bạn, mà đối với một ứng dụng Node.js điển hình có thể bao gồm hơn 800 gói.

Hãy nghĩ về các ranh giới niềm tin của ứng dụng của bạn. Dữ liệu không đáng tin cậy ở đâu trong hệ thống của bạn? Mỗi trường biểu mẫu, mỗi tham số URL, mỗi tiêu đề HTTP, mỗi cookie, mỗi thân yêu cầu API. Nếu nó đến từ bên ngoài bộ nhớ của máy chủ bạn, nó là không đáng tin cậy. Tôi đã thấy các lập trình viên cẩn thận xác thực đầu vào của biểu mẫu nhưng hoàn toàn bỏ qua các tham số URL, hoặc khử trùng dữ liệu POST trong khi để các tham số GET mở rộng. Kẻ tấn công không quan tâm đến mô hình tâm lý của bạn về cái gì "nên" được xác thực - họ sẽ kiểm tra mọi thứ.

Bề mặt tấn công của bạn cũng bao gồm các lỗ hổng theo thời gian. Token đặt lại mật khẩu mà bạn tạo ra? Nếu nó dự đoán được hoặc không hết hạn, nó là một vectơ tấn công. Các định danh phiên, khóa API, tên tập tin tạm thời - bất kỳ thứ gì mà kẻ tấn công có thể đoán hoặc brute-force nếu có đủ thời gian. Tôi từng tìm thấy một hệ thống mà token đặt lại mật khẩu chỉ là các số nguyên tuần tự. Một kẻ tấn công có thể yêu cầu đặt lại cho tài khoản của họ, xem token 45231, sau đó thử các token 45230, 45229, 45228 để đặt lại mật khẩu của người dùng khác.

Xác Thực Dữ Liệu: Lớp Phòng Thủ Đầu Tiên Của Bạn

Nếu tôi có thể xăm một nguyên tắc lên trán của mọi lập trình viên, đó sẽ là: không bao giờ tin tưởng dữ liệu đầu vào từ người dùng. Không phải dữ liệu đầu vào từ ứng dụng di động của bạn. Không phải dữ liệu đầu vào từ API của "đối tác đáng tin cậy". Thậm chí không phải dữ liệu đầu vào từ JavaScript frontend của riêng bạn. Mọi thứ vượt qua ranh giới niềm tin phải được xác thực, khử trùng và được coi là có thể gây hại cho đến khi được chứng minh ngược lại.

Các lỗ hổng nguy hiểm nhất không phải là những cái mà hacker phát hiện - chúng là những cái mà lập trình viên không biết tồn tại trong mã của họ cho đến khi đã quá muộn.

Tôi thấy các lập trình viên mắc phải cùng một sai lầm lặp đi lặp lại: họ xác thực dữ liệu đầu vào ở phía frontend và cho rằng điều đó là đủ. Đây là thực tế — tôi có thể vượt qua xác thực frontend của bạn trong khoảng 15 giây bằng công cụ phát triển trình duyệt hoặc một lệnh curl đơn giản. Xác thực frontend là cho trải nghiệm người dùng, không phải bảo mật. Xác thực thực sự diễn ra trên máy chủ, mọi lúc, không có ngoại lệ.

Xác thực dữ liệu đầu vào hiệu quả có ba thành phần: kiểm tra kiểu, xác thực định dạng, và xác thực logic kinh doanh. Kiểm tra kiểu đảm bảo rằng một trường mong đợi một số thật sự nhận được một số, không phải một chuỗi chứa các nỗ lực SQL injection. Xác thực định dạng sử dụng danh sách cho phép (không phải danh sách không cho phép) để đảm bảo dữ liệu khớp với các mẫu mong đợi. Nếu bạn mong đợi một địa chỉ email, hãy xác thực theo regex email hợp lệ. Nếu bạn mong đợi một số điện thoại của Mỹ, hãy xác thực định dạng một cách rõ ràng.

Xác thực logic kinh doanh là nơi hầu hết các lập trình viên dừng lại. Chỉ vì điều gì đó về mặt kỹ thuật là hợp lệ không có nghĩa là nó có ý nghĩa trong bối cảnh ứng dụng của bạn. Tôi từng xem xét mã mà một giỏ hàng cho phép số lượng âm. Lập trình viên đã xác thực rằng đầu vào là một số nguyên, nhưng không bao giờ kiểm tra xem nó có phải là dương hay không. Một kẻ tấn công có thể "mua" -100 mặt hàng và nhận được tín dụng thay vì phải trả tiền. Việc sửa lỗi rất đơn giản, nhưng sự sơ suất đã khiến công ty mất 23.000 đô la trước khi bị phát hiện.

Dưới đây là cách tiếp cận thực tế của tôi: định nghĩa các sơ đồ nghiêm ngặt cho mọi đầu vào mà ứng dụng của bạn chấp nhận. Sử dụng các thư viện xác thực như Joi cho Node.js, Pydantic cho Python, hoặc xác thực tích hợp trong các khung như Laravel hoặc Django. Những thư viện này cho phép bạn tuyên bố chính xác những gì đầu vào hợp lệ trông như thế nào, và họ từ chối mọi thứ khác theo mặc định. Khi xác thực thất bại, hãy ghi lại. Những lần xác thực thất bại liên tiếp từ cùng một địa chỉ IP hoặc tài khoản người dùng có thể chỉ ra một cuộc tấn công đang diễn ra.

Một điểm quan trọng nữa: xác thực ở mọi lớp. Nếu dữ liệu chảy từ API của bạn đến một công việc nền đến một cơ sở dữ liệu, hãy xác thực ở mỗi bước. Tôi đã thấy những cuộc tấn công khai thác khoảng trống giữa xác thực API và xử lý công việc nền. API xác thực đầu vào một cách chính xác, nhưng công việc nền đã giả định rằng dữ liệu là an toàn vì nó đến từ cơ sở dữ liệu. Một kẻ tấn công có thể ghi trực tiếp vào cơ sở dữ liệu (thông qua một lỗ hổng riêng biệt) có thể vượt qua tất cả các xác thực.

Xác Thực và Ủy Quyền: Biết Ai và Điều Gì

Xác thực trả lời "bạn là ai?" Ủy quyền trả lời "bạn được phép làm gì?" Nhầm lẫn hai khái niệm này, hoặc triển khai chúng kém, tạo ra một số lỗ hổng dễ khai thác nhất mà tôi gặp phải. Tôi đã thấy các hệ thống có xác thực vô cùng vững chắc nhưng cho phép bất kỳ người dùng đã xác thực nào truy cập dữ liệu của người dùng khác vì ủy quyền chỉ là một suy nghĩ sau.