ngăn chặn gian lận cho trình duyệt dựa trên xmlhttp/js/perl/php trò chơi

Question

Cho phép nói rằng trong một trò chơi dựa trên trình duyệt, hoàn thành một số hành động (để đơn giản cho phép ai đó nhấp vào liên kết làm tăng điểm số của họ bằng 100) nhấp vào liên kết này sẽ có một url ví dụ increase_score.pl?amount=100 loại phòng có từ một người nào đó chỉ đơn giản là gửi yêu cầu đến máy chủ web để thực hiện lệnh này:

1. Lặp đi lặp lại một lần nữa mà không thực sự làm nhiệm vụ cách nhấn vào liên kết và
2. Gửi yêu cầu sai đến máy chủ có số tiền được đặt thành một số nội dung rediculus như 100000.

Tôi biết việc kiểm tra HTTP_REFERER tuy nhiên tôi biết mọi người có thể vượt qua điều đó (không chắc chắn chính xác) và khác với kiểm tra giới hạn cho tùy chọn thứ 2. Bất cứ ai từng gặp vấn đề tương tự? Các giải pháp?

Answer 1

Không gì có thể ngăn họ thực hiện việc này nếu bạn triển khai trò chơi của mình theo cách bạn đề xuất.

Bạn cần triển khai logic trò chơi trên máy chủ và chỉ định điểm khi máy chủ xác thực hành động.

Ví dụ: trên SO khi người nào đó bỏ phiếu cho câu hỏi của bạn, điều này không được gửi dưới dạng lệnh để tăng danh tiếng của bạn. Ứng dụng web chỉ nói với người dùng máy chủ X đã bỏ phiếu cho câu hỏi Y up. Máy chủ sau đó xác thực dữ liệu và gán các điểm nếu mọi thứ kiểm tra. (Không nói SO là trò chơi, nhưng logic yêu cầu tương tự.)

Answer 2

Mã thông báo với cookie/phiên.

Answer 3

Bạn có thể tạo liên kết động và có băm thay đổi ở cuối. Xác minh rằng hàm băm đúng cho khoảng thời gian đó.

Điều này sẽ thay đổi theo độ phức tạp tùy thuộc vào tần suất bạn cho phép nhấp chuột.

Answer 4

Logic của trò chơi (ứng dụng) phải dựa trên quy tắc để không tin tưởng bất kỳ thứ gì đến từ người dùng.

HTTP_REFERER có thể được giả mạo với bất kỳ ứng dụng web nào.

Answer 5

Mở rộng phản hồi của Ahmet, mỗi lần tải trang, tạo một khóa ngẫu nhiên. Lưu khóa trong phiên người dùng. Thêm phím ngẫu nhiên cho mỗi liên kết, do đó liên kết mới để có được những 100 điểm là:

increase_score.pl?amount=100&token=AF32Z90 

Khi mọi liên kết được nhấp, kiểm tra để chắc chắn rằng các dấu hiệu phù hợp với một trong phiên giao dịch, và sau đó tạo ra một khóa mới và lưu nó trong phiên. Một khóa ngẫu nhiên mới cho mỗi lần họ đưa ra yêu cầu.

Nếu họ cung cấp cho bạn khóa sai, họ đang cố gắng tải lại trang.

Answer 6

Tôi khuyên bạn nên tạo một URL cụ thể cho từng hành động. Một cái gì đó dọc theo dòng:

/score/link_88_clicked/ 
/score/link_69_clicked/ 
/score/link_42_clicked/ 

Mỗi liên kết có thể làm hai việc:

1. Đánh dấu trong phiên rằng liên kết đã được nhấp để nó sẽ không theo dõi liên kết đó một lần nữa.
2. Thêm vào điểm số của họ.

Answer 7

Phiên bản ngắn: bạn không thể. Mọi phần dữ liệu bạn nhận được từ trình duyệt (trình duyệt) đều có thể được người khác biết đến những gì họ đang làm.

Bạn cần phải suy nghĩ cơ bản về cách ứng dụng được cấu trúc. Bạn cần mã phía máy chủ của ứng dụng theo cách nó xử lý mọi phần dữ liệu đến từ máy khách như một gói bẩn thỉu bẩn thỉu nằm cho đến khi nó có thể tự chứng minh rằng dữ liệu trên thực tế là hợp lý. Bạn cần phải tránh cho máy chủ một suy nghĩ của "Nếu khách hàng nói với tôi để làm điều này, rõ ràng nó là cho phép để cho tôi biết để làm điều này."

WRONG WAY:
Chủ đầu tư: Một Người Chơi Steve nói để cung cấp cho Người Chơi Steve một điểm gazillion.
Máy chủ: OK!

QUYỀN PHẢI:
Khách hàng: Người chơi Steve nói để cung cấp cho người chơi Steve một điểm gazillion.
Máy chủ: Vâng, trước hết hãy để tôi kiểm tra xem liệu Steve có chơi hay không, tại thời điểm này, được phép tự cho mình một điểm quan trọng ... ah. Anh ấy không phải. Xin vui lòng hiển thị thông báo "Go Fsck Yourself, Cheater" này cho người chơi Steve.

Như đã nói với ai đã đăng nhập, đó là vấn đề đơn giản khi giao cho khách hàng một cookie với giá trị gần như không thể đoán được mà bạn theo dõi trên máy chủ - nhưng tôi sẽ giả sử bạn biết cách đối phó với quản lý phiên. :-) (Và nếu bạn không, Google awaits.)

Answer 8

Một vài điều cần lưu ý ở đây.

Đầu tiên, yêu cầu máy chủ của bạn cho một thứ như thế này phải là POST, chứ không phải GET. Chỉ các yêu cầu GET phải là ngẫu nhiên, và không thực hiện như vậy thực ra là a violation of the HTTP specification.

Thứ hai, những gì bạn đang xem ở đây là số Vấn đề về sự tin cậy của khách hàng. Bạn có để tin tưởng khách hàng gửi điểm hoặc thông tin về khoảng thời gian trò chơi khác đến máy chủ, nhưng bạn không muốn khách hàng gửi dữ liệu bất hợp pháp. Ngăn chặn các hành động không được phép là dễ dàng - nhưng ngăn chặn dữ liệu phát hôi trong một hành động được phép được phép có nhiều vấn đề hơn.

Ben S làm cho một điểm tuyệt vời về cách bạn thiết kế giao thức truyền thông giữa máy khách và máy chủ như thế này. Cho phép các giá trị điểm được gửi dưới dạng dữ liệu đáng tin cậy thường sẽ là một ý tưởng tồi. Nó thích hợp hơn để chỉ ra rằng một hành động đã diễn ra, và để cho máy chủ tìm ra số điểm cần được chỉ định, nếu có. Nhưng đôi khi bạn không thể vượt qua điều đó. Hãy xem xét kịch bản của một trò chơi đua xe. Khách hàng có để gửi thời gian của người dùng và không thể bị tóm tắt thành một số cuộc gọi khác như "completedLevelFour". Vậy bây giờ bạn muốn làm gì?

Cách tiếp cận mã thông báo mà Ahmet và Dean gợi ý là âm thanh - nhưng nó không hoàn hảo. Thứ nhất, mã thông báo vẫn còn phải được truyền tới máy khách, điều này có nghĩa là nó có thể phát hiện được bởi kẻ tấn công tiềm năng và có thể được sử dụng độc hại. Ngoài ra, điều gì sẽ xảy ra nếu API trò chơi của bạn cần phải là quốc gia? Điều đó có nghĩa là xác thực mã thông báo dựa trên phiên. Và bây giờ bạn vào sâu, ruột đen của vấn đề Trust Client.

Có rất ít bạn có thể làm cho nó trở nên dễ dàng 100%. Nhưng bạn có thể làm cho nó rất bất tiện để gian lận. Hãy xem xét mô hình bảo mật của Facebook (mọi yêu cầu API được ký). Điều này là khá tốt và yêu cầu kẻ tấn công thực sự đào sâu vào mã phía máy khách của bạn trước khi họ có thể tìm ra cách giả mạo một reqeust.

Một cách tiếp cận khác là phát lại trên máy chủ. Giống như cho một trò chơi đua xe, thay vì chỉ có một giá trị "thời gian" được gửi đến máy chủ, có các trạm kiểm soát cũng ghi lại thời gian và gửi tất cả. Thiết lập mức tối thiểu thực tế cho mỗi khoảng thời gian và xác minh trên máy chủ rằng tất cả dữ liệu này nằm trong giới hạn được thiết lập.

Chúc may mắn!

Answer 9

Có vẻ như một thành phần trong trò chơi của bạn sẽ cần điều chỉnh yêu cầu. Về cơ bản, bạn theo dõi tốc độ một khách hàng cụ thể truy cập trang web của bạn nhanh như thế nào và bạn bắt đầu làm chậm phản hồi của mình cho khách hàng đó khi tỷ lệ của họ vượt quá mức bạn cho là hợp lý. Có nhiều cấp độ khác nhau, bắt đầu từ bộ lọc IP cấp thấp cho đến thứ bạn xử lý trong máy chủ web. Ví dụ, Stackoverflow có một chút trong ứng dụng web mà bắt được những gì nó nghĩ là quá nhiều chỉnh sửa quá gần nhau. Nó chuyển hướng bạn đến một hình ảnh xác thực mà bạn cần trả lời nếu bạn muốn tiếp tục. Đối với các bit khác, bạn nên xác thực tất cả đầu vào không chỉ cho biểu mẫu của nó (ví dụ: đó là số) mà còn giá trị hợp lý (ví dụ: dưới 100 hoặc bất kỳ giá trị nào). Nếu bạn bắt được một khách hàng làm điều gì đó vui nhộn, hãy nhớ điều đó. Nếu bạn bắt cùng một khách hàng làm điều gì đó buồn cười thường xuyên, bạn có thể cấm khách hàng đó.

Answer 10

Nếu bạn muốn trò chơi chỉ chạy trên máy chủ của mình, bạn cũng có thể phát hiện vị trí tín hiệu được gửi từ mẹo truy xuất và bỏ qua mọi thứ không đến từ miền của bạn. Nó sẽ là một nỗi đau thực sự để làm xáo trộn mã của bạn, nếu bạn phải chạy từ miền chuyên dụng của bạn để gửi điểm số.

Điều này cũng chặn hầu hết các thủ thuật của CheatEngine.