Trust Boundary Violation

csharp.trust_boundary_violation

Severity

high

Resource

Information Leak

Language

CSharp

Description

Trust boundary violation occurs when the application improperly validates or trusts data crossing from an untrusted to a trusted domain.

This may involve inadequate checks on data from sources like user inputs or external systems, allowing malformed or malicious data to affect the application.

Rationale

Data often traverses from untrusted sources such as user inputs, external APIs, or network connections to the more trusted internals of the application.

A trust boundary violation arises when this transition allows unvalidated or improperly sanitized data to impact the application’s operations or security.

Here is a simple example:

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Http;

public class MyController : Controller
{
    private const string ATTR_USR = "USER";

    [HttpPost]
    public IActionResult Index()
    {
        string username = Request.Form["user"];

        if (HttpContext.Session.GetString(USER) == null)
        {
            // VULNERABLE: setting session data from untrusted input
            // without proper validation
            HttpContext.Session.SetString(USER, username);
        }

        // ... other logic

        return View();
    }
}

In the above example, a user-controlled input was added to the session without proper validation. Later, this stored value could be used to access a resource, where an attacker could inject unintended data. The value crossed a trust boundary, where session data is considered trusted, but no validation was performed.

Inadequate handling of trust boundaries can lead to various attacks, including injection attacks, data integrity violations, and unauthorized access to sensitive data or system resources.

Remediation

To mitigate the risks of trust boundary violations, implement the following practices for secure handling of data across trust boundaries:

1. Input Validation: Ensure all inputs from untrusted sources are rigorously validated and sanitized before use. Implement input constraints like length checks, pattern matching, or using whitelists to enforce valid data formats.

2. Use Security Libraries: Leverage existing libraries that offer strong validation routines and error handling measures (e.g., Apache Commons Validator or OWASP Java Validator projects).

3. Error Handling: Implement robust error handling to gracefully handle and log exceptions caused by unexpected input, reducing exposure of error messages or stack traces that could provide insights to an attacker.

4. Principle of Least Privilege: Apply access controls and execute code with the least privileges necessary. Enforce stringent role-based access controls to minimize risk.

5. Static Analysis Tools: Utilize SAST tools to automate the detection of potential trust boundary vulnerabilities and integrate them into your continuous integration pipelines.

In the previous example, the program should validate the input before using it to set the session data. For example, checking that the

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Http;

public class MyController : Controller
{
    private const string ATTR_USR = "USER";
    private const Regex UsernameRegex = new Regex(@"^[a-zA-Z0-9_]{3,20}$");

    [HttpPost]
    public IActionResult Index()
    {
        string username = Request.Form["user"];

        // FIXED: validate username so downstream code is not affected
        if (UsernameRegex.IsMatch(username))
        {
            if (HttpContext.Session.GetString(USER) == null)
            {
                // now safe
                HttpContext.Session.SetString(USER, username);
            }

            // ... other logic

            return View();
        }
        else
        {
            return BadRequest("Invalid username");
        }
    }
}

Configuration

The detector has the following configurable parameters:

sources, that indicates the source kinds to check.
neutralizations, that indicates the neutralization kinds to check.

Unless you need to change the default behavior, you typically do not need to configure this detector.

References

CWE-501 : Trust Boundary Violation.