Security: Threats & Defense · Study deck
IoT Software Vulnerabilities
Picture a field app that accepts a temperature value far outside the device range and then draws it as a real alarm.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Input and authorization Device names are validated and encoded for HTML output; rejected values are logged without storing unsafe content; sampling-interval changes require an explicit management permission, and denied actions are audited.
- Explain: A vulnerability class is a category of leak: a cracked joint is an input-handling flaw, an unlocked valve is an authorization flaw, and an old corroded pipe is a vulnerable dependency.
- Explain: Software vulnerability review starts by naming the path under review, which in IoT may cross a device interface, gateway service, broker, dashboard, mobile app, update service, database, or cloud API.
Major section
Start With The First Bug Report
The support worker sees a bad screen; the software owner must find where untrusted input became trusted state and what property was lost.
- A fix passes only when the normal path still works and the harmful path is rejected with a useful record.
- A software update is not proof of safety.
- The changed code, built package, installed version, settings, and running service must match.
- Reopen the review when an input path, dependency, permission, or update method changes.
Major section
Overview: Software Sits Between Everything
A weak parser, an unsafe input path, a missing authorization check, a vulnerable dependency, or an unclear remediation process can expose data or change device behavior.
- This chapter keeps the review defensive.
- The goal is not attack procedure.
- The first scoping move is to name the boundary where data becomes trusted.
Major section
Overview: Software Sits Between Everything (continued)
This map is the chapter's running discipline: every broad vulnerability label must become a specific path, control, and observed result.
- That may be an HTTP handler, MQTT topic, gateway parser, dashboard renderer, update manifest, or dependency imported into a reachable service.
- Once the boundary is named, the finding can point to the exact validation, authorization, encoding, monitoring, or dependency-control evidence that is missing.
- If you can describe a reviewable finding, you can stop here.
Major section
Overview: Software Sits Between Everything (continued)
A vulnerability class is a category of leak: a cracked joint is an input-handling flaw, an unlocked valve is an authorization flaw, and an old corroded pipe is a vulnerable dependency.
- You do not fix "the plumbing." You fix the specific joint and then pressure-test it, which is the retest.
- The input boundary identifies where untrusted data enters; authorization decides whether the authenticated actor may perform the requested action; dependency and data-store checks expose inherited and retained risk.
- Classes are questionsVulnerability classes are defensive prompts to ask better questions, not scripts for attack.
Major section
Overview: Software Sits Between Everything (continued)
The One-Minute ViewName the path State which interface, action, parser, or dependency is affected. "The dashboard has vulnerabilities" is not a finding.
- A fix is not done until retestedClose a finding only after retest evidence shows it is fixed, or accept it with a clear exception.
- Beginner Examples "Passed a vulnerability scan" is not evidence of a safe path; the review still needs the affected path and control checked.
- Validating input is not the same as encoding output; both can be needed for the same field.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest
Software vulnerability review starts by naming the path under review, which in IoT may cross a device interface, gateway service, broker, dashboard, mobile app, update service, database, or cloud API.
- The workflow turns each finding into a decision a reviewer can repeat and audit.
- Common Vulnerability ClassesClasses are patterns that help reviewers ask better questions.
- They often overlap; record each weak control separately so each fix can be tested separately.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Validation rules, bounded parser, output-encoding records, rejection logs.
- Scope fixes the authorized component, data, and test boundary; safe confirmation establishes the observed behavior without unnecessary harm.
- Classification names the failed control, prioritization accounts for exposure and consequence, and remediation changes the responsible boundary.
- Bounds checks, safe libraries, fuzz-test evidence, crash handling.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Retesting must exercise the original path and related denied case before the owner records evidence and a future trigger.
- Native parser with no fuzzing or bounds evidence.
- Inventory exists but no owner reviews changes.
- Error-path review, log redaction, safe-failure tests.
- The class list becomes actionable at the point where untrusted data changes meaning.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Receive identifies the source and channel; validation constrains type, size, range, and structure; parsing turns the bounded representation into data.
- This ordered boundary explains why validation, authorization, and encoding are complementary controls rather than interchangeable labels.
- Input Handling: Validation Is Not EncodingInput handling protects the point where untrusted data becomes application state, database content, rendered output, device command parameters, or configuration.
- The same boundary rule applies before data reaches SQL or XML processors.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
SQL injection is a query-construction failure: accepted text is allowed to change the database instruction instead of remaining a value.
- The key distinction: validation decides whether input is acceptable for a purpose, while encoding prevents accepted data from being interpreted as a different kind of instruction in a later context.
- In a browser-facing IoT dashboard, the HTML-output version of that failure is cross-site scripting (XSS) or HTML code injection: attacker-controlled text is rendered as markup or script instead of inert content.
- Authentication names the actor; authorization decides whether that actor may take the action.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
The review should name the output context, escape or sanitize for that context, retest the rendered page, and keep enough evidence to prove the value cannot become executable HTML.
- XML injection is a structure-construction failure: accepted text is allowed to create or alter XML elements, attributes, or parser behavior.
- A defensive review should ask for parameterized queries or equivalent prepared statements, context-aware XML construction, parser limits, rejected malformed-input evidence, and action-level authorization for any database or configuration change.
- Worked ReviewA gateway dashboard accepts device names, shows telemetry, lets operators change sampling intervals, and uses several protocol libraries.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
A weak review says "the dashboard passed a vulnerability scan." A stronger review separates the finding types.
- Input and authorizationDevice names are validated and encoded for HTML output; rejected values are logged without storing unsafe content; sampling-interval changes require an explicit management permission, and denied actions are audited.
- Dependency evidenceThe dashboard and gateway libraries have an inventory; advisory review identifies which components handle exposed input; updated components are retested against dashboard and gateway paths.
- Scoped decision "Accepted for this release after encoding, action authorization, dependency review, and retest logs were checked.
Major section
Under the Hood: Memory Safety, Supply Chain, and Secure SDLC
The deeper layer covers the classes that need more than a single control check: memory safety in native code, how injection and deserialization arise, supply-chain exposure, and the development process that keeps findings from recurring.
- Memory SafetyFirmware and native services written in languages without automatic bounds checking must handle buffers, object lifetimes, and parser states carefully.
- The defensive review focuses on boundary checks, use of safe or hardened libraries, evidence of fuzz testing on input parsers, crash handling, and update readiness, rather than on attack mechanics.
- Prioritizing by ContextA severity label alone is not enough.
Major section
Under the Hood: Memory Safety, Supply Chain, and Secure SDLC (continued)
Where the platform allows, memory-safe languages and compiler mitigations reduce the size of this class.
- The defense is context-aware output encoding or parameterized handling at the boundary where the interpretation occurs; input validation alone does not prevent it, because validated data can still be misinterpreted downstream.
- Insecure deserialization is a related parser-trust failure: software reconstructs objects or state from structured input and trusts that input too much.
- Updating a dependency is not complete until the path that uses it is retested, because the update can change behavior.
Major section
Summary
A software finding is reviewable only when it names the affected path, the security property, and the weak control, and is closed after retest.
- Common classes are input handling, authorization, memory safety, dependency, configuration, and error handling, and they often overlap.
- Injection and insecure deserialization are input-trust failures; dependency findings need reachability and advisory evidence, not just presence.
- Prioritize by system context, and build review, testing, and retest into the development lifecycle so fixes hold across releases.
Deck summary
Key takeaways
The support worker sees a bad screen; the software owner must find where untrusted input became trusted state and what property was lost.
- A weak parser, an unsafe input path, a missing authorization check, a vulnerable dependency, or an unclear remediation process can expose data or change device behavior.
- This map is the chapter's running discipline: every broad vulnerability label must become a specific path, control, and observed result.
- A vulnerability class is a category of leak: a cracked joint is an input-handling flaw, an unlocked valve is an authorization flaw, and an old corroded pipe is a vulnerable dependency.
Retrieval practice
Recall check 1 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q1What makes a software vulnerability finding reviewable in an IoT data system?
Show answer
Answer: A A finding is actionable when it is specific, tied to a control, and verified by retest, not a broad statement.
Retrieval practice
Recall check 2 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q2A dashboard stores user-provided device names and later renders them in an operator page. The review shows validation on input but no output encoding for the HTML context. What is the best defensive finding?
Show answer
Answer: D The finding should name the output context, the missing control, and the retest path.
Retrieval practice
Recall check 3 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q3A dependency scanner flags a vulnerable library in a gateway build. The library is compiled into the image but is never called by any reachable code path. How should this affect the finding?
Show answer
Answer: C Presence still matters and should be tracked, but reachability and exposure drive priority.
Retrieval practice
Recall check 4 of 4
Shield Shelly says: answer from memory, then check your reasoning.
Q4An IoT API accepts untrusted input and calls a device command. Which repair record is strongest?
Show answer
Answer: B The control must match the input and authority risks and have test evidence.
Print reference
Answers
Answer key.
- A · A finding is actionable when it is specific, tied to a control, and verified by retest, not a broad statement.
- D · The finding should name the output context, the missing control, and the retest path.
- C · Presence still matters and should be tracked, but reachability and exposure drive priority.
- B · The control must match the input and authority risks and have test evidence.