Security in Browser Games: XSS, CSRF, and Safe APIs Quiz Quiz

Explore essential security concepts for browser-based games, focusing on XSS vulnerabilities, CSRF prevention, and best practices for safe API usage. This quiz challenges your understanding of common threats and defense mechanisms to keep online gaming platforms secure.

1. Identifying Reflected XSS in Browser Games

   Which of the following scenarios best illustrates a reflected cross-site scripting (XSS) vulnerability in a browser game login page?

   1. A malicious script is included in a URL parameter and executed immediately after the login form is submitted.
   2. The game server embeds a static script file to enhance game visuals.
   3. Only administrators are able to input code into the database backend.
   4. Password fields use plain HTML without JavaScript validation.

   Explanation: Reflected XSS occurs when untrusted input from a URL or request is immediately returned and executed by the browser, as seen when a script from a URL parameter runs after form submission. Embedding static script files doesn't involve user input and isn't an XSS risk here. Administrator database access relates to access control, not XSS. Lack of JavaScript validation in password fields does not itself create an XSS vector.

2. Understanding CSRF Risks with Game Actions

   Why can the use of browser cookies for session authentication make a browser game vulnerable to Cross-Site Request Forgery (CSRF) attacks?

   1. Because cookies encrypt all requests and prevent forging of requests from untrusted sources.
   2. Because cookies only work with POST requests and ignore GET requests.
   3. Because browser games do not use cookies to store authentication tokens.
   4. Because cookies are automatically sent with every request, including those initiated by malicious websites.

   Explanation: Cookies are sent automatically with every HTTP request in the browser, so if a player is logged in, a malicious website can initiate requests using those cookies. Encryption by cookies is not a default behavior and does not prevent CSRF on its own. The statement about games not using cookies is incorrect, as many do for sessions. Cookies are sent with both POST and GET requests, not just POST.

3. Safe API Design for In-Game Purchases

   What is an important technique to prevent unauthorized in-game purchases through your game's API endpoint?

   1. Rely solely on client-side JavaScript to manage purchase limits.
   2. Require authentication and server-side validation of every purchase request.
   3. Store purchase confirmation tokens in local browser storage only.
   4. Allow purchase requests from any domain without checking the origin.

   Explanation: Requiring authentication and validating requests on the server ensures only legitimate players can make purchases and that claims cannot be faked. Allowing requests from any domain increases susceptibility to exploits. Storing tokens only in local storage does not guarantee proper validation. Client-side JavaScript can be manipulated and should not be solely relied upon for security.

4. Preventing XSS via User-Generated Content in Chats

   How can a browser game prevent XSS attacks when displaying user-generated chat messages?

   1. Pass user messages to the chat display without modification for performance.
   2. Allow only images and videos but never escape other content.
   3. Trust users to follow the game rules and avoid posting scripts.
   4. Sanitize all user input before rendering, removing or escaping potentially dangerous code.

   Explanation: Sanitizing or escaping user input ensures that embedded scripts or markup don't execute in the browser, stopping XSS attacks through chat. Passing chat without modification risks code injection. Only allowing images or videos doesn't address script injection in text or attributes. Trusting users to follow rules is not a security measure and exposes the game to risk.

5. Preventing CSRF in Secure Game APIs

   Which security feature most effectively prevents CSRF in sensitive browser game endpoints, such as changing account email?

   1. Use only JavaScript to check if forms are being submitted by real users.
   2. Disable cookies for all user authentication sessions.
   3. Allow endpoints to be accessed over HTTP as well as HTTPS.
   4. Require a unique CSRF token in form submissions and verify it on the server.

   Explanation: A CSRF token included in requests and validated by the server ensures that only legitimate actions from the intended user are processed. Disabling cookies breaks session management and is not practical. JavaScript-based checks can often be bypassed by attackers. Allowing HTTP alongside HTTPS weakens transport security, but does not address CSRF directly.