# Trust Boundary Violations

*Trust boundaries* in computer science are where uncontrolled input from an external source – like HTTP requests, file uploads, or network sockets – are taken into a controlled environment, like a web-server. To maintain a good security stance, it is important to keep data taken in across a trust boundary at arms length until it has been verified.

If you stored trusted and untrusted data in the same data store, the trust status of individual data points will inevitably get confused somewhere down the line. Either downstream code components will make incorrect assumptions about the status of the data points, or future code changes will make the same erroneous assumptions.

## Trust Boundary Violations in Python

Consider the following web application that writes the username to the session before authentication has completed, along with a `validated` flag:

“`python
@app.route(‘/login’, methods=[‘POST’])
def do_login():
username = request.form[‘username’]
password = request.form[‘password’]session[‘username’] = username
session[‘validated’] = False

user = find_user_with_password(username, password)

if not user:
flash(‘Invalid credentials’, ‘error’)
return redirect(‘/login’)

session[‘validated’] = True

return redirect(‘/timeline’)
“`

There is enough information in the session to determine whether the user is logged in, but it relies on the code checking a trusted data point (the `validated` flag), and an untrusted data point (the `username`). This confusing design opens the door to security bugs, because most developers will assume the user has been authenticated if the `username` appears in the session state.

## Mitigation

Never write untrusted input to your session store until is has been verified. For example, this code writes the username to the session state only after authentication checks have been passed:

“`python
@app.route(‘/login’, methods=[‘POST’])
def do_login():
username = request.form[‘username’]
password = request.form[‘password’]user = find_user_with_password(username, password)

if not user:
flash(‘Invalid credentials’, ‘error’)
return redirect(‘/login’)

session[‘username’] = username

return redirect(‘/timeline’)
“`

## CWEs

* [CWE-501](https://cwe.mitre.org/data/definitions/501.html)

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit: www.shiftleft.io.

Share

See for yourself – run a scan on your code right now