Trusted System Boundaries

From a short lunch-and-learn session at ConstructConnect: A discussion on why it's important for testers to understand trust boundaries in the systems we work with.

Input processing is complex and expensive. We can't (and shouldn't) do that in every single part of a system, so it's critical to work with developers/architects to create and understand system boundaries. This makes our testing much more effective as we know where to concentrate our efforts.

This L&L session was interactive, so I posed a bunch of questions to get responses, then guided some discussion around what trust boundaries might look like.

Transcript

1. Trusted System Boundaries Learn On the Go 11/2/2022
3. What Do We Test for Input? Responses: • Is the item in the catalog • JS injection / other malicious eg sql injection • Cookies and token—auth • Boundary failures • Authenticity—is correct input in correct field? (cross-wire fields) • Correct character set (Latin-1, e.g.) • Rejecting binary input in text • Max/min length (also a boundary) • Blanks or zero (no input given)
4. What’s involved in building safe code and testing it? Responses: • Build protection into code • Cross-browser support • Design impact (both UI and system) • Complexity, effort • Toolsets, frameworks, and libraries
5. System Diagram in Miro
7. API Application Endpoints / Services Data Access Layer (DAL) Business Logic
8. API Application Endpoints / Services Data Access Layer (DAL) Business Logic Controller Routing Model
9. What do we need to work with these boundaries? Responses: • Do we know the critical flows? What APIs are called for what reasons? • Clarity of each APIs params, etc. • What each field means • Each field’s limits/boundaries and data types • Auth