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
   

   View Slide

2. View Slide

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)
   

   View Slide

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
   

   View Slide

5. System Diagram in Miro
   

   View Slide

6. View Slide

7. API Application
   Endpoints
   / Services
   Data
   Access
   Layer
   (DAL)
   Business
   Logic
   

   View Slide

8. API Application
   Endpoints / Services Data Access Layer (DAL)
   Business Logic
   Controller
   Routing
   Model
   

   View Slide

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
   

   View Slide