Bạn không thể từ chối các kết nối một cách hiệu quả trừ khi bạn cung cấp cho mọi khách hàng một khóa riêng mà bạn có thể thu hồi riêng lẻ. Nhưng điều này có lẽ là quá mức cần thiết. Bạn không cần một giải pháp chống đạn nếu hầu hết mọi người sẽ không muốn bắn một viên đạn.
Đó là một câu hỏi bảo mật, vì vậy hãy mô tả một mô hình mối đe dọa và các chiến lược giảm thiểu.
Giả sử bạn có một lần truy cập URL có thể gây ra chi phí đáng chú ý cho bạn (ví dụ: chi phí xử lý) và bạn muốn bảo vệ nó khỏi cả một cuộc tấn công DoS đơn giản và từ các ứng dụng copycat.
Sử dụng SSL để ẩn kết nối khỏi bị phân tích dễ dàng. Sử dụng số cổng không obviuos, trình tự chuyển hướng, trao đổi cookie để làm phức tạp kết nối một chút trước khi bạn thực hiện phần tốn kém của yêu cầu. Sử dụng một số mã bí mật được đưa vào ứng dụng của bạn để cho máy chủ biết rằng nó phải chấp nhận kết nối.
Bây giờ ai đó không thể tìm hiểu URL đắt tiền để truy cập chỉ bằng cách chạy gói sniffer hoặc bằng cách xem các chuỗi giống như URL trong mã của bạn. Kẻ tấn công tiềm năng phải dịch ngược ứng dụng của bạn.
Bạn không thể thực sự bảo vệ mã của mình khỏi bị dịch ngược và / hoặc chạy theo trình gỡ lỗi. Kẻ tấn công cuối cùng cũng học được khóa bí mật và trình tự kết nối.
Bạn nhận thấy rằng bạn bắt đầu nhận được các yêu cầu chia sẻ tại URL tốn kém của mình: dưới hình thức tấn công hoặc dưới dạng một ứng dụng copycat phải truy cập dịch vụ của bạn để chạy hoặc có thể mã khai thác được đăng công khai. Bạn không thể nói một yêu cầu giả mạo từ một yêu cầu hợp pháp, mặc dù.
Tạo một bản cập nhật nhỏ miễn phí cho ứng dụng của bạn, với một khóa bí mật khác. Nó sẽ đạt một URL tốn kém khác phục vụ cùng một dữ liệu như URL tốn kém bị xâm phạm. Trong một thời gian, làm cho cả hai URL có thể truy cập.
Xem chuyển đổi cơ sở người dùng của bạn để phiên bản cập nhật. Điều chỉnh URL tốn kém bị xâm phạm và cuối cùng là 404. Bạn vừa giảm nhẹ vi phạm an ninh, hy vọng không mất quá nhiều. Làm lại từ đầu.
Tuyên bố miễn trừ trách nhiệm: Tôi không phải là chuyên gia bảo mật.