Bảo mật là một khái niệm thú vị và thu hút rất nhiều người đến với nó. Thật không may, đó là một chủ đề phức tạp và ngay cả các chuyên gia cũng hiểu sai. Tôi đã tìm thấy các lỗ hổng bảo mật trong Google (CSRF), Facebook (nhiều CSRF hơn), một số nhà bán lẻ trực tuyến lớn (chủ yếu là SQL injection / XSS), cũng như hàng nghìn trang web nhỏ hơn cho cả công ty và cá nhân.
Đây là những đề xuất của tôi:
1) Sử dụng các truy vấn được tham số hóa Các truy vấn
được tham số buộc các giá trị được truyền tới truy vấn phải được coi là dữ liệu riêng biệt, do đó, DBMS không thể phân tích cú pháp các giá trị đầu vào dưới dạng mã SQL. Nhiều người sẽ khuyên bạn nên thoát khỏi các chuỗi của mình bằng cách sử dụng mysql_real_escape_string() , nhưng trái với niềm tin phổ biến, đó là không một giải pháp bắt tất cả cho SQL injection. Lấy ví dụ truy vấn này:
SELECT * FROM users WHERE userID = $_GET['userid']
Nếu $_GET['userid'] được đặt thành 1 OR 1=1 , không có ký tự đặc biệt và nó sẽ không được lọc. Điều này dẫn đến tất cả các hàng được trả về. Hoặc thậm chí tệ hơn, điều gì sẽ xảy ra nếu nó được đặt thành 1 OR is_admin = 1 ?
Các truy vấn được tham số ngăn chặn loại tiêm này xảy ra.
2) Xác thực thông tin đầu vào của bạn Các truy vấn được tham số
là rất tốt, nhưng đôi khi các giá trị không mong muốn có thể gây ra sự cố với mã của bạn. Đảm bảo rằng bạn đang xác thực rằng chúng nằm trong phạm vi và chúng sẽ không cho phép người dùng hiện tại thay đổi điều gì đó mà họ không thể thực hiện được.
Ví dụ:bạn có thể có một biểu mẫu thay đổi mật khẩu gửi yêu cầu ĐĂNG đến một tập lệnh thay đổi mật khẩu của họ. Nếu bạn đặt ID người dùng của họ dưới dạng một biến ẩn trong biểu mẫu, họ có thể thay đổi nó. Đang gửi id=123 thay vì id=321 có thể có nghĩa là họ thay đổi mật khẩu của người khác. Đảm bảo rằng MỌI THỨ đều được xác thực chính xác, về loại, phạm vi và quyền truy cập.
3) Sử dụng htmlspecialchars để thoát khỏi đầu vào của người dùng được hiển thị
Giả sử người dùng của bạn nhập "về tôi" của họ như sau:
</div><script>document.alert('hello!');</script><div>
Vấn đề với điều này là đầu ra của bạn sẽ chứa đánh dấu mà người dùng đã nhập. Cố gắng tự lọc điều này bằng danh sách đen chỉ là một ý tưởng tồi. Sử dụng htmlspecialchars lọc ra các chuỗi để các thẻ HTML được chuyển đổi thành các thực thể HTML.
4) Không sử dụng $ _REQUEST Các cuộc tấn công
giả mạo yêu cầu trên nhiều trang web (CSRF) hoạt động bằng cách yêu cầu người dùng nhấp vào liên kết hoặc truy cập vào URL đại diện cho một tập lệnh thực hiện một hành động trên trang web mà họ đã đăng nhập. $_REQUEST biến là sự kết hợp của $_GET , $_POST và $_COOKIE , có nghĩa là bạn không thể phân biệt được biến được gửi trong một yêu cầu ĐĂNG (tức là thông qua input trong biểu mẫu của bạn) hoặc một biến được đặt trong URL của bạn như một phần của GET (ví dụ:page.php?id=1 ).
Giả sử người dùng muốn gửi tin nhắn riêng tư cho ai đó. Họ có thể gửi một yêu cầu ĐĂNG tới sendmessage.php , với to , subject và message dưới dạng các tham số. Bây giờ, hãy tưởng tượng ai đó gửi yêu cầu GET thay thế:
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Nếu bạn đang sử dụng $_POST , bạn sẽ không thấy bất kỳ thông số nào trong số đó, vì chúng được đặt trong $_GET thay thế. Mã của bạn sẽ không thấy $_POST['to'] hoặc bất kỳ biến nào khác, vì vậy nó sẽ không gửi thông báo. Tuy nhiên, nếu bạn đang sử dụng $_REQUEST , $_GET và $_POST bị mắc kẹt với nhau, vì vậy kẻ tấn công có thể đặt các tham số đó như một phần của URL. Khi người dùng truy cập vào URL đó, họ đã vô tình gửi tin nhắn. Phần thực sự đáng lo ngại là người dùng không phải làm bất cứ điều gì. Nếu kẻ tấn công tạo một trang độc hại, nó có thể chứa iframe trỏ đến URL. Ví dụ:
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Điều này dẫn đến việc người dùng gửi tin nhắn cho mọi người mà không bao giờ nhận ra rằng họ đã làm bất cứ điều gì. Vì lý do này, bạn nên tránh $_REQUEST và sử dụng $_POST và $_GET thay vào đó.
5) Coi mọi thứ bạn đưa ra là đáng ngờ (hoặc thậm chí độc hại)
Bạn không biết người dùng đang gửi cho bạn những gì. Nó có thể là hợp pháp. Nó có thể là một cuộc tấn công. Không bao giờ tin tưởng bất cứ điều gì người dùng đã gửi cho bạn. Chuyển đổi thành các loại chính xác, xác nhận các đầu vào, sử dụng danh sách trắng để lọc khi cần thiết (tránh danh sách đen). Điều này bao gồm mọi thứ được gửi qua $_GET , $_POST , $_COOKIE và $_FILES .
Nếu bạn tuân theo các nguyên tắc này, bạn đang ở vị trí hợp lý về mặt bảo mật.
