Bảo mật ứng dụng web từ góc nhìn của người viết code hằng ngày
Bảo mật thường bị xem là trách nhiệm của một bộ phận chuyên biệt, thứ chỉ được nghĩ đến khi sắp ra mắt hoặc khi đã xảy ra sự cố. Cách nhìn này nguy hiểm, bởi phần lớn lỗ hổng bảo mật bắt nguồn từ những quyết định nhỏ trong code hằng ngày. Một lập trình viên hiểu các nguyên tắc bảo mật cơ bản sẽ phòng tránh được đa số rủi ro phổ biến ngay từ khi gõ những dòng đầu tiên, rẻ và hiệu quả hơn nhiều so với việc vá lỗi sau khi bị tấn công.
Không bao giờ tin tưởng dữ liệu từ bên ngoài
Nguyên tắc nền tảng của bảo mật ứng dụng là mọi dữ liệu đến từ bên ngoài hệ thống đều phải bị coi là không đáng tin cho đến khi được kiểm chứng. Điều này bao gồm dữ liệu người dùng nhập vào biểu mẫu, tham số trên đường dẫn, nội dung tệp tải lên, và cả phản hồi từ các dịch vụ bên thứ ba. Nhiều loại tấn công nghiêm trọng nhất đều khai thác việc ứng dụng tin tưởng mù quáng vào dữ liệu đầu vào.
Hai họ lỗ hổng kinh điển minh họa rõ điều này. Tấn công tiêm nhiễm xảy ra khi dữ liệu người dùng bị trộn lẫn với câu lệnh, chẳng hạn một chuỗi nhập vào được ghép thẳng vào truy vấn cơ sở dữ liệu, cho phép kẻ tấn công thay đổi ý nghĩa của câu lệnh đó. Cách phòng chống là luôn tách dữ liệu khỏi lệnh, sử dụng truy vấn tham số hóa thay vì ghép chuỗi. Họ lỗ hổng thứ hai là chèn mã kịch bản phía trình duyệt, khi nội dung do người dùng cung cấp được hiển thị lại mà không được làm sạch, khiến mã độc chạy trong trình duyệt của nạn nhân. Cách phòng chống là luôn mã hóa dữ liệu phù hợp với ngữ cảnh hiển thị.
Xác thực và phân quyền là hai việc khác nhau
Nhiều người nhầm lẫn giữa xác thực và phân quyền, nhưng đây là hai khái niệm tách biệt và đều quan trọng. Xác thực trả lời câu hỏi bạn là ai, trong khi phân quyền trả lời câu hỏi bạn được phép làm gì. Một hệ thống có thể xác thực đúng người dùng nhưng vẫn để lộ dữ liệu nếu quên kiểm tra quyền truy cập ở từng thao tác.
- Lưu mật khẩu bằng hàm băm chuyên dụng cho mật khẩu, không bao giờ lưu dưới dạng văn bản gốc hay mã hóa có thể đảo ngược.
- Kiểm tra phân quyền ở phía máy chủ cho mọi yêu cầu, không bao giờ chỉ dựa vào việc ẩn nút bấm ở giao diện.
- Áp dụng nguyên tắc đặc quyền tối thiểu, chỉ cấp cho mỗi thành phần đúng quyền nó cần để hoạt động.
- Cẩn thận với lỗ hổng truy cập trực tiếp đối tượng, khi người dùng đổi một mã định danh trên đường dẫn để xem dữ liệu của người khác.
Quản lý bí mật và phụ thuộc
Một nguồn rò rỉ phổ biến đến mức đáng ngạc nhiên là việc đưa các thông tin bí mật như khóa truy cập và mật khẩu cơ sở dữ liệu thẳng vào mã nguồn, rồi vô tình đẩy chúng lên kho mã công khai. Bí mật nên được lưu trong cấu hình môi trường hoặc dịch vụ quản lý bí mật chuyên dụng, tách hoàn toàn khỏi code. Một khi một bí mật đã bị lộ trong lịch sử kho mã, nó phải được coi là đã bị xâm phạm và cần thay mới ngay, vì lịch sử rất khó xóa sạch.
Phần mềm hiện đại được xây dựng trên hàng loạt thư viện của bên thứ ba, và mỗi thư viện đều có thể chứa lỗ hổng. Một lỗ hổng nghiêm trọng trong một thư viện được dùng rộng rãi có thể ảnh hưởng đến vô số ứng dụng cùng lúc. Vì vậy, hãy theo dõi các phụ thuộc của bạn, cập nhật chúng kịp thời khi có bản vá bảo mật, và sử dụng công cụ tự động quét để phát hiện những phụ thuộc đã biết là có vấn đề.
Phòng thủ theo chiều sâu và tư duy đúng đắn
Không có biện pháp bảo mật đơn lẻ nào là hoàn hảo, nên cách tiếp cận khôn ngoan là phòng thủ theo chiều sâu: nhiều lớp bảo vệ độc lập sao cho khi một lớp thất bại, các lớp khác vẫn đứng vững. Mã hóa dữ liệu nhạy cảm cả khi lưu trữ lẫn khi truyền đi, giới hạn tần suất yêu cầu để chống dò mật khẩu, ghi nhật ký để phát hiện hành vi bất thường, tất cả bổ sung cho nhau.
Quan trọng nhất là thay đổi tư duy. Bảo mật không phải tính năng có thể gắn vào cuối, mà là một thuộc tính cần được cân nhắc trong từng quyết định thiết kế. Hãy tập thói quen tự hỏi điều tồi tệ nhất có thể xảy ra với đoạn code này là gì, một kẻ xấu sẽ lạm dụng nó ra sao. Tư duy phòng thủ này, kết hợp với những nguyên tắc cơ bản ở trên, sẽ giúp bạn xây dựng những ứng dụng vừa hữu ích vừa đáng tin cậy cho người dùng giao phó dữ liệu của họ.
