Design, Develop and Implement Secure Code to Minimise Vulnerabilities in User Action Controls

Broken Authentication and Session Management

Broken authentication occurs when an attacker exploits vulnerabilities in the authentication process, which can lead to:

• Stolen login credentials
• Exploiting session handling weaknesses

Broken authentication vulnerabilities

• Weak passwords
• Insecure session management
• Failure to log out (by users and the system)

Preventing broken authentication

• Enforcing strong password policies
• Use MFA
• Implement secure session management
• Code review and security testing
• Input validation and sanitisation

Cross-Site Scripting (XSS)

Cross-Site Scripting is a type of security vulnerability that allows attackers to inject malicious scripts into web pages that are viewed by other users. They are executed in the user's browser, potentially allowing the attacker to steal sensitive information like session cookies, redirect the user or perform actions on behalf of the user.

How does it work?

For example, in an application that allows users to post comments, an attacker could inject a script that's executed when another user visits the page.

Types of XSS

• Stored XSS
  • Malicious script is stored on the server and executed every time the affected page is loaded by any user
• Reflected XSS
  • Malicious script is immediately reflected back to the user and executed in their browser. Usually to trick the user into clicking a link
• DOM-based XSS
  • Injected into the Document Object Model and executed by the browser without interacting with the server. DOM is a programming interface for web documents that represents the structure as a tree of objects/part of the document (elements, attributes, text)

Prevention

• Sanitise inputs before being stored or displayed
• Use output encoding to ensure data is treated as text, not executable code

Cross-Site Request Forgery (CSRF)

An attack where a malicious script or website tricks a user's browser into making unintended requests to a different website where the user is authenticated. This can lead to unauthorised actions being performed on behalf of the user like transferring money, changing their password or deleting the account.

How does it work?

• The user is logged into a trusted website
• The attacker tricks them into visiting a malicious site, which sends a request to the trusted site without their knowledge
• The trusted site processes the request as if it were legitimate because the user's browser automatically sends session cookies or authentication tokens

Prevention

• Use CSRF tokens, which are a unique, secret value that's generated by the server and included in forms. When the form is submitted, the server checks the token to ensure the request is legitimate
• Use the SameSite attribute on cookies to prevent them from being sent with cross-site requests

Invalid Forwarding and Redirecting

Can occur when users are redirected or forwarded to unintended pages, partially due to manipulated URLs or unvalidated redirects. This leads to 'open redirect' vulnerabilities.

Secure code practices

• Strict validation and sanitisation of URLs used in redirects and forwards
• Use a list of allowed/safe URLs to prevent invalid redirects
• Use relative URLs instead of absolute for internal redirects
• Avoid user-controlled input for determining redirections, and instead use predefined paths/verify against a strict allowlist
• Redirect users to a safe default page in cases of failed redirects instead of exposing ambiguous error states

Race Conditions

A vulnerability that arises when the timing of events in a system affects its behaviour, as multiple processes or threads access shared resources simultaneously. If not managed correctly, race conditions can lead to unexpected behaviour, data corruption or unauthorised access.

Secure code practices

• Use locks, mutexes, or semaphores to restrict access to shared resources (only one thread can access the resource at a time)
  • A lock is acquired before accessing the resource and released afterwards - if another thread tries to access the locked resource, it will be paused until the lock is released
  • Mutexes include built-in features to prevent deadlocks, where two threads wait indefinitely for each other
  • Semaphores control access based on a counter that specifies the number of processes that can access a resource simultaneously
• Using atomic operations, which are actions that are performed as a single, uninterruptible step
• Double check mechanism verifies the state of a resource before and after it's locked to confirm it hasn't changed