Javascript chống gian lận cho trình duyệt / trò chơi HTML5

Tôi đang lên kế hoạch mạo hiểm để tạo một rpg hành động một người chơi trong js / html5 và tôi muốn ngăn chặn gian lận. Tôi không cần bảo vệ 100%, vì đây sẽ không phải là một trò chơi nhiều người chơi, nhưng tôi muốn một số mức độ bảo vệ.

Vì vậy, những chiến lược bạn đề xuất ngoài việc giảm thiểu và obfuscation?

Tôi sẽ không làm cho việc kiểm tra đơn giản phía máy chủ, nhưng tôi không muốn đi theo đường dẫn Diablo 3, giữ tất cả các thay đổi trạng thái trò chơi của tôi ở phía máy chủ.

Vì nó sẽ là một loại rpg, tôi đã nảy ra ý tưởng làm một thanh tra thống kê kiểm tra những thay đổi đột ngột trong giá trị của chúng, nhưng tôi không chắc nó có thể phù hợp và đáng tin đến mức nào.

Điều gì về các biến và hàm thoát? Làm việc trên các lối thoát nhỏ hơn bất cứ khi nào có thể sẽ an toàn hơn, nhưng nó có đáng để nỗ lực không?

Có cách nào để javascript tự kiểm tra văn bản của nó không, như trong tổng kiểm tra?

Có giải pháp cụ thể cho trình duyệt? Tôi sẽ không cố gắng hạn chế nó cho Chrome chỉ trong các bản dựng đầu tiên.

Câu trả lời ngắn gọn là bạn không thể làm điều đó. Bất cứ điều gì chạy phía khách hàng, đặc biệt là từ nguồn, có thể được sửa đổi để đánh bại chiến thuật của bạn một cách tầm thường. Nếu bạn đặt một trình kiểm tra phía máy khách để tìm kiếm những thay đổi đột ngột, người dùng chỉ có thể vô hiệu hóa trình kiểm tra.

Tin tốt là, nói chung, có rất ít gian lận trong các trò chơi một người chơi. Ngoại lệ chính duy nhất là các trò chơi có cộng đồng "điểm cao youtube" lớn như Line Rider, nơi người chơi cạnh tranh với nhau trên YouTube.

Nếu bạn đang nhắm đến điều đó, hoặc quá cứng đầu để chấp nhận rằng mọi người có thể gian lận trong trò chơi hoặc đang tự mình giữ điểm số cao (là một hình thức nhiều người chơi) thì những gì bạn phải làm là tất cả các phía máy chủ tính toán . Vâng, tất cả mọi thứ quan trọng. Bạn thậm chí không thể lặp lại phía máy khách tính toán để cố gắng cung cấp cho người dùng điểm số và sau đó 'xác minh' với máy chủ vì người dùng sau đó có thể vô hiệu hóa kiểm tra và vô hiệu hóa bất kỳ hệ thống nào đảm bảo có kiểm tra.

Tôi ước có một câu trả lời tốt hơn cho điều này, nhưng không có.

Điều đó nói rằng, có những điều bạn có thể làm để làm cho nó khó hơn một chút để gian lận. Họ sẽ không ngăn cản bất cứ ai nghiêm túc làm việc đó và phát hành bộ công cụ để gian lận, nhưng điều đó sẽ làm họ chậm lại:

• Giảm thiểu và Obfuscate JS của bạn, điều này hoàn toàn sẽ làm cho mã khó đọc hơn. Bạn có thể khử tối thiểu và sắp xếp khử nhiễu nhưng bạn không bao giờ có thể lấy lại đúng tên biến và tên hàm, cũng như nhận xét.
• Nướng trong các giá trị với một ngôn ngữ khác nhau. Trong trường hợp này, bạn có thể sử dụng PHP hoặc các ngôn ngữ phía máy chủ khác để xử lý các biến thiết lập tĩnh. Nếu khoảng cách nhảy luôn được coi là 2 khoảng trắng, thông thường bạn sẽ xác định khoảng cách nhảy cho đối tượng người chơi. Đừng, xử lý điều đó với PHP để nguồn JS kết thúc với 2 giây được dán trên toàn bộ mã ở một triệu địa điểm. Điều này có tác dụng phụ bổ sung rất vui khi có thể tăng tốc độ JS của bạn.
• Với một số thực hành, bạn sẽ thành thạo với bản phối và thậm chí bạn có thể tùy chỉnh bản dựng JS của mình cho mỗi người chơi. Đó là một cách khác để ngăn chặn gian lận. Nếu mã của mỗi người chơi khác nhau bằng cách nào đó, thì việc viết một mánh gian lận có thể là một phần của bộ công cụ sẽ khó hơn.
• Cuối cùng, bạn có thể kiểm tra nguồn dựa trên danh tính của người chơi. Nói địa chỉ IP và / hoặc tên người dùng của họ. Bạn biết phiên bản dành riêng cho người chơi của JS sẽ là gì, bạn có thể nướng trong tổng kiểm tra và yêu cầu nó phải giống nhau ở đầu bên kia. Dễ dàng vô hiệu hóa như bất kỳ JS phía máy khách nào, nhưng một lần nữa khiến việc tạo bộ công cụ trở nên khó khăn hơn một chút.

Vì thế. Như bạn thấy, có lẽ không đáng để đi theo con đường này. Thật khó Yêu cầu rất nhiều thực hành mã hóa thực sự ngớ ngẩn để làm, và cuối cùng vẫn tương đối dễ dàng để đánh bại. Bạn sẽ cần phải thực hiện tất cả các tính toán phía máy chủ để tránh gian lận. Hoặc buông tay, và chấp nhận rằng gian lận sẽ xảy ra.

Tôi đã trả lời một câu hỏi như thế ở đây và tôi rất tiếc phải nói nhưng:

Tôi sẽ không làm cho việc kiểm tra đơn giản phía máy chủ, nhưng tôi không muốn đi theo đường dẫn Diablo 3, giữ tất cả các thay đổi trạng thái trò chơi của tôi ở phía máy chủ.

Là điều tồi tệ nhất bạn có thể nói ở đây. Nếu bạn muốn làm một công cụ "chống gian lận", bạn sẽ phải làm điều đó. Bạn có thể thêm bất cứ điều gì bạn muốn phía máy khách, để tạo điều kiện cho công việc phía máy chủ, nhưng bạn không bao giờ phải tin tưởng vào máy khách. Tất cả Logic bạn phải có ít nhất là phía máy chủ. Bạn có thể sao chép nó phía máy khách nếu bạn muốn, nhưng không có giải pháp nào chỉ phía máy khách sẽ làm điều đó.

Và nhân tiện, nếu bạn muốn tìm ra điểm yếu của chương trình, đừng làm phiền nó, hãy để mọi người xem mã của bạn và nói với bạn "ở đây, bạn có vấn đề".

Điều đó tốt cho bạn, cho mã của bạn, cho người dùng của bạn và cho cộng đồng.

Chà, một nơi tốt để bắt đầu là sử dụng chức năng Object.freeze (sẽ cho phép bảo vệ chống lại việc vá đối tượng).

Điều này "ngăn các thuộc tính mới được thêm vào", "ngăn các thuộc tính hiện có bị xóa", "ngăn các thuộc tính hiện có hoặc tính liệt kê, cấu hình hoặc khả năng ghi của chúng bị thay đổi"; bất kỳ thay đổi nào đối với trạng thái nội bộ nên được thực hiện thông qua các phụ kiện. Ví dụ sau hoạt động trên chrome (nên hoạt động trên firefox, tôi không biết về IE mặc dù ...):

var b = {}
// Fill your object with whatever you want
b.a = "ewq"
// Freeze all changes
Object.freeze(b)
// Try to put new value. This wont throw any error, put wont work either, 
// as we shall see ...
b.b = "qwe"

// Values 
console.log(b.a); // outputs "eqw"
console.log(b.b); // outputs  undefined

Thật không may, bạn phải đi theo con đường 3 diablo, nếu bạn thực sự lo lắng về hack / cheat. nếu bạn không phải, thì kiểm tra cơ bản bạn phải làm hoặc khuyên bạn nên làm.

• mua séc - Nếu tôi mua thứ gì đó, tôi nên có đủ vàng
• sellchecks - Nếu tôi đang bán thứ gì đó, tôi cần phải có mặt hàng đó trong séc giao dịch hàng tồn kho của mình - giống như bán vũ khí
• trang bị séc - Nếu tôi trang bị vũ khí, tôi có / sở hữu nó không?
• kiểm tra thiệt hại - Nếu tôi đang tấn công thứ gì đó (kẻ thù), tôi không thể đánh nhiều hơn mức sát thương tối đa mà vũ khí của tôi có thể (ở đây bạn không nên hy vọng khách hàng sẽ biết loại vũ khí nào anh ta đã sử dụng vì nó cần được duy trì trước đó)
• kiểm tra chế tạo - Nếu tôi chế tạo một cái gì đó, tôi có cần tất cả các thành phần / thành phần không?

... và cứ thế

1 điểm là một chút khó khăn là vị trí của anh hùng, vì bạn không lo lắng nhiều về nó, bạn có thể rời bỏ nó, nhưng tốt hơn là bạn cũng làm điều đó với một kiểm tra tối thiểu như dưới đây

• Tôi đang ở địa điểm1 @ T1, tôi đang ở địa điểm2 T2, thời gian tối thiểu để đi từ địa điểm 1 đến địa điểm 2 là bao nhiêu và nó phù hợp với T2 - T1 của tôi. Bạn có thể có bản đồ này từ nhỏ đến lớn tùy thuộc vào kích thước bản đồ. Bạn nên có danh sách ít nhất các khu vực chính như, NPC - trùm, NPC - khu vực sinh sản của kẻ thù (không nhất thiết phải là vị trí chính xác)

Hy vọng điều này có ích, nghe có vẻ khó khăn nhưng bạn cần học cách làm những trò chơi thực sự hiệu quả

Về cơ bản là không thể. Nó sẽ rất dễ dàng để làm việc xung quanh bất cứ điều gì bạn đặt tại chỗ để ngăn chặn gian lận.

Điều này là với bất kỳ phần mềm nào bạn phân phối, mọi người có thể sửa đổi nó trong bộ nhớ một cách dễ dàng.

Bên cạnh đó nếu họ muốn lừa dối, hãy để họ. Họ chỉ đang hủy hoại trò chơi cho chính họ. Không có cách sử dụng thực tế nào để gian lận trong tình huống này, bạn sẽ tự mình phá hủy trò chơi.

Tôi đã có một ý tưởng cho một biện pháp bạn có thể thực hiện để ngăn chặn / giảm gian lận (ngoài các câu trả lời khác). Bạn có thể thiết lập nó để khách hàng không được cung cấp tất cả mã nguồn cùng một lúc, thay vào đó, mỗi khi khách hàng muốn, nói, mua một mặt hàng mới trong cửa hàng, khách hàng sẽ phải gửi một số thông tin nhất định tới máy chủ và chỉ nhận tất cả thông tin cho bất cứ thứ gì họ mua nếu tất cả thông tin phù hợp với những gì nó được cho là. Nếu không, máy chủ sẽ liệt kê danh sách đen IP của họ hoặc một cái gì đó.

Bạn có thể sử dụng kết hợp với những gì Dampes8n đã nói về việc sử dụng các phiên bản nguồn khác nhau, rằng nếu bạn có thể tìm ra cách tạo ra nhiều phiên bản khác nhau, để mỗi người dùng sẽ chạy một phiên bản nguồn hoàn toàn khác nhau mỗi lần, điều đó không thành công cũng kiểm tra danh sách đen phiên bản nguồn đó, rằng nó sẽ không bao giờ đưa ra thông tin mục chính xác cho phiên bản nguồn đó nữa.

Lý do chính điều này sẽ có hiệu quả là nếu lần đầu tiên tin tặc không nhận được bản hack, điều này sẽ khiến họ khó sửa đổi bản hack hơn, vì mỗi lần hack không hoạt động hoàn hảo, họ phải thay đổi IP của họ và viết lại bản hack cho phiên bản nguồn mới.

Vâng, nó không thể được thực hiện đầy đủ . Luôn luôn kiểm tra trên máy chủ. Bất cứ điều gì có ảnh hưởng đến trò chơi nên yêu cầu sự cho phép từ máy chủ.

Đó là phần mở rộng mà tôi sẽ lặp lại các câu trả lời khác.

Tuy nhiên, chúng ta có thể làm nhiều hơn vào việc ngăn chặn gian lận thay vì chỉ kiểm tra trên máy chủ. Vâng, chúng tôi có thể phải thêm một số kiểm tra máy chủ đặc biệt. Tuy nhiên, lưu ý rằng kiểm tra phía máy khách không phải là vô ích, chúng tiết kiệm băng thông và máy chủ hoạt động khi không có kẻ gian.

Với câu nói đó:

• Giảm thiểu các máy khách thô: Phục vụ trên HTTPS, sử dụng chia sẻ tài nguyên nguồn gốc chéo (CORS), chỉ cho phép cùng một nguồn gốc, sử dụng tính toàn vẹn của nguồn phụ. Tôi đề nghị triển khai một nhân viên dịch vụ để thực thi nó trên tất cả các yêu cầu, điều đó cũng có nghĩa là trò chơi sẽ không hoạt động bằng cách đơn giản chuyển nó sang HTTP (vì không có HTTPS, nhân viên máy chủ sẽ thực hiện phần máy khách của CORS và máy chủ mong đợi CORS) và nếu họ phục vụ qua HTTPS thì nó sẽ không hoạt động vì máy chủ sẽ từ chối nguồn gốc khác.
• Giảm thiểu kịch bản: Sử dụng xác thực và yêu cầu mã thông báo để thực hiện bất kỳ hành động nào. Mỗi chu kỳ cập nhật, máy chủ sẽ cung cấp cho khách hàng một mã thông báo mới và mã thông báo được sử dụng bằng cách làm bất cứ điều gì ... làm bất cứ điều gì đều yêu cầu mã thông báo hợp lệ, mã thông báo luôn thay đổi và do đó không thể đoán được và nếu khách hàng gửi cùng một mã thông báo hai lần hoặc gửi mã thông báo sai, máy chủ biết rằng có gì đó không ổn. Để bảo vệ thêm: tạo mã xác thực Tin nhắn (MAC) của mã thông báo bằng một khóa bí mật và thêm nó vào te cookie. Sửa đổi cookie sẽ giết phiên (và họ cần đoán khóa) và sửa đổi mã thông báo sẽ khiến việc kiểm tra MAC thất bại.
• Giảm thiểu sửa đổi mã: Ngoài tính toàn vẹn của nguồn con (mà các trình duyệt hiện đại cũng sẽ kiểm tra trong thời gian chạy), hãy giữ các biến của bạn trong một phạm vi giới hạn (sử dụng let, tự thực thi các hàm ẩn danh và các mô-đun javascript). Ngoài ra, không dựa vào DOM (DOM chỉ dành cho IO, không lưu trữ, nếu bạn cần đính kèm các thuộc tính bọc các đối tượng DOM của bạn và thêm chúng vào trình bao bọc). Bằng cách này, bất cứ điều gì bạn trên bảng điều khiển sẽ không thể đạt được logic trò chơi (trừ khi bạn khai thác một số lỗ hổng trình duyệt). Bạn cũng có thể cân nhắc sử dụng các kỹ thuật để phát hiện các công cụ dành cho nhà phát triển (đây là các công cụ cụ thể cho mỗi trình duyệt và có thể không hoạt động trong mọi trường hợp hoặc ngừng hoạt động trong tương lai ... do đó, đây là một cuộc chạy đua vũ trang).
• Có chuyện gì thế? Có phải phiên nghỉ? Đá cầu thủ từ trận đấu hiện tại, yêu cầu đăng nhập lại. Hãy xem xét một hình ảnh xác thực ... cũng có lợi ích khi nói với người dùng rằng "chúng tôi biết điều gì đó hiếm gặp đang xảy ra" (đó không phải là lỗi máy chủ ngẫu nhiên), và vâng, đó là một hình thức giảm thiểu. Oh, và đừng có sương mù để đăng nhập những thứ này. Bạn cần có thể xác minh lý do tại sao chúng xảy ra, cả hai để ngăn chặn các thông báo sai và trả lời vé hỗ trợ.

Vâng, đây là tất cả giảm nhẹ. Chúng tôi vẫn có thể có một trình duyệt được tạo tùy chỉnh sẽ không kiểm tra tính toàn vẹn và cho phép bạn tiếp cận và xử lý các biến trong phạm vi cục bộ ... sau đó mã trò chơi sẽ gửi dữ liệu đã sửa đổi bằng mã thông báo phù hợp và đó là nơi máy chủ kiểm tra chơi.