Unit 9: Web, Cloud, IoT, and Emerging Technology Security

Lesson at a glance

| Item | Detail | | --------------------- | ------------------------------------------------------------------------------------------ | | Suggested length | 4 × 60 minutes | | Recommended placement | Weeks 15–16 of Cybersecurity I | | Prerequisite | Units 1–8 | | Materials | Browser DevTools, Kali, OWASP Juice Shop (or DVWA) running in lab, IoT risk-matrix handout |

Safety: Web app testing happens only against the lab Juice Shop / DVWA. Cloud labs use teacher-provided sandbox accounts. IoT discussion is conceptual unless you have a teacher-managed lab device.

Standards & credential alignment

• EHE Domain 7: Application-Level Attacks and Web App Vulnerabilities.
• VA CTE: Identify common web vulnerabilities and cloud security concepts.
• OWASP Top 10: introductory exposure (deep dive in Cyber II Unit 7).

Learning objectives

By the end of this unit, students can:

1. Read an HTTP request and response and identify method, headers, body, status.
2. Explain how cookies and sessions work and why they're a target.
3. Recognize input-validation failures (XSS, SQLi, IDOR) at the conceptual level.
4. Describe the cloud shared-responsibility model for IaaS, PaaS, and SaaS.
5. Identify three common IoT security failures.
6. Articulate at least three privacy and security concerns about generative AI.

Vocabulary

• HTTP method - GET, POST, PUT, DELETE, etc.
• Status code - 200 OK, 301 redirect, 401 unauthorized, 403 forbidden, 404 not found, 500 server error.
• Cookie / session - A small token the browser stores; the server uses it to recognize you.
• XSS (Cross-site scripting) - Attacker injects script that runs in another user's browser.
• SQLi - Attacker injects database commands through a vulnerable input.
• IDOR - Insecure Direct Object Reference. Changing a number in a URL to access someone else's stuff.
• Shared responsibility model - Cloud security split: provider does some, you do the rest.
• IaaS / PaaS / SaaS - Infrastructure / Platform / Software as a Service.
• MDM - Mobile Device Management.

Teacher background

This unit is the on-ramp to Cyber II Units 6–7 (web app security and exploitation). Don't try to teach SQLi mechanics in depth here - the goal is recognition, not exploitation. Students should leave able to read an HTTP exchange and suspect a vulnerability when they see one.

The cloud shared-responsibility model is a recurring source of incidents. Most cloud breaches are not "AWS got hacked." They are "the customer left an S3 bucket open." Make the line "the cloud is shared - your job and theirs" stick.

Materials checklist

• [ ] Browsers with DevTools (Chrome/Firefox)
• [ ] Kali VM
• [ ] OWASP Juice Shop running on host-only network (docker run --rm -p 3000:3000 bkimminich/juice-shop)
• [ ] Cloud-responsibility table handout
• [ ] IoT risk-matrix handout

Pacing - Day 1 (60 min): How the web actually works

| Time | Segment | Notes | | ----------- | ------------------------------------------- | ---------------------------------------------------------------------------- | | 0:00 – 0:20 | Mini-lesson - HTTP request/response anatomy | Method, headers, body, status. | | 0:20 – 0:50 | Lab - DevTools tour | Network tab, request inspection, edit-and-replay (DevTools console is fine). | | 0:50 – 1:00 | Discussion - what's in a header? | User-Agent, Cookie, Authorization. |

Day 1 - Lab: read the wire

1. Visit the Juice Shop (http://192.168.56.20:3000).
2. Open DevTools → Network tab.
3. Log in with a test account. Watch the requests.
4. Find the POST /rest/user/login. Inspect:
   • Request URL, method, headers, body (the JSON with email and password).
   • Response status (200 if successful), response body (the JWT token).
5. Refresh. Find a GET for products. Identify the Authorization: Bearer ... header. That's the session.

Discussion: "Where in this exchange could an attacker break things?"

Pacing - Day 2 (60 min): Web vulnerability recognition

| Time | Segment | Notes | | ----------- | -------------------------------------------------------- | -------------------------------------------------------------- | | 0:00 – 0:20 | Mini-lesson - XSS, SQLi, IDOR | Concept and indicator only. | | 0:20 – 0:50 | Activity - find one of each in Juice Shop | Teacher-guided; do not exploit beyond the demo. | | 0:50 – 1:00 | Discussion - what does the developer do wrong each time? | Input validation, parameterized queries, authorization checks. |

Day 2 - The three classes, recognized

| Vulnerability | One-line tell | Real fix | | ------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------ | | XSS | User-supplied data shows up in the page without escaping | Output encoding + Content-Security-Policy | | SQLi | User-supplied data appears in a query string | Parameterized queries; never string-concatenate SQL | | IDOR | URL or API path includes an object ID anyone can change | Server checks "is this user allowed to see this object?" - every request, every time |

Demonstrate IDOR in Juice Shop: log in as one user, visit /api/Users/1 (or similar), change the ID. That is IDOR. The fix: server enforces authorization based on the session, not the URL.

Pacing - Day 3 (60 min): Cloud + shared responsibility

| Time | Segment | Notes | | ----------- | ----------------------------------- | ---------------------------------------------- | | 0:00 – 0:20 | Mini-lesson - IaaS/PaaS/SaaS | What you own at each level. | | 0:20 – 0:50 | Activity - the responsibility table | Pairs fill in who's responsible for each line. | | 0:50 – 1:00 | Discussion - recent cloud incidents | What did the customer fail at? |

Day 3 - The shared-responsibility table

| Concern | On-prem | IaaS (e.g., EC2) | PaaS (e.g., App Service) | SaaS (e.g., Gmail) | | -------------------------------- | ------- | ---------------- | ------------------------ | ------------------ | | Physical security | You | Provider | Provider | Provider | | Network controls | You | You + provider | Mostly provider | Provider | | OS patching | You | You | Provider | Provider | | Application code | You | You | You | Provider | | Identity/access | You | You | You | You | | Data classification + access | You | You | You | You |

Land it: "No matter what flavor of cloud you buy, identity and your data are always your job."

Pacing - Day 4 (60 min): IoT, mobile, and AI

| Time | Segment | Notes | | ----------- | --------------------------- | -------------------------------------------------------- | | 0:00 – 0:15 | Mini-lesson - IoT realities | Default creds, no patching, always-on. | | 0:15 – 0:30 | Activity - IoT risk matrix | 5 devices, score risk and mitigation. | | 0:30 – 0:45 | Mini-lesson - mobile + MDM | App stores, sideloading, MDM, BYOD. | | 0:45 – 0:58 | Discussion - generative AI | Privacy, prompt injection, hallucination, training data. | | 0:58 – 1:00 | Exit ticket | "Name three AI security concerns from class." |

Day 4 - IoT risk matrix (5 devices)

| Device | Default credentials? | Patches? | Network exposure | Risk score (1–5) | Mitigation | | ----------------- | -------------------- | -------------- | ---------------------- | ---------------- | ---------- | | Smart bulb | Often | Rare | LAN broadcast | | | | IP camera | Frequently | Inconsistent | Often internet-exposed | | | | Smart TV | Rarely admin | OEM controlled | LAN + often cloud | | | | Connected printer | Yes (admin/admin) | Manual only | LAN | | | | Voice assistant | Account-bound | Auto | Internet | | |

Day 4 - Generative AI security concerns (the honest list)

1. Data leakage in prompts. What you paste into a chatbot may be retained, logged, or used in training. Treat it like a public mailing list.
2. Prompt injection. Attackers can hide instructions inside documents the AI processes. The AI follows the hidden instructions because it can't tell them apart from legitimate ones.
3. Hallucinations. AI confidently makes things up. Verify every fact. Especially code, citations, and numbers.
4. Training data exposure. Models can sometimes be coaxed to reveal training data, including sensitive info.
5. Authoritative tone, no accountability. Students will trust AI more than warranted. Build the habit of verifying.

Common misconceptions

• "HTTPS protects me from web vulns." - HTTPS encrypts the traffic. It does nothing about XSS, SQLi, or IDOR.
• "The cloud is more secure than my laptop." - It can be. It can also be much worse, depending on configuration.
• "AI gets it right because the answer sounds smart." - Confidence ≠ correctness. Verify everything.

Differentiation

• Reading support: HTTP request anatomy is a printable one-pager.
• Stretch: students complete additional Juice Shop challenges from the in-game scoreboard.

Assessment

• Day 1 deliverable: annotated screenshot of one HTTP request showing method, URL, headers, body, response status.
• Day 2 deliverable: short paragraph identifying which of XSS/SQLi/IDOR you found and how you'd fix it.
• Day 3 deliverable: completed shared-responsibility table.
• Day 4 deliverable: completed IoT risk matrix.

Career connection

Web app security testers ($85K–$130K), cloud security engineers ($110K–$160K), AI security researchers (a brand-new role with extreme demand). Every one of these roles starts with the basics from this unit.

Homework / next class

Find one IoT device in your home. Look up whether it has known CVEs in the last 12 months. Bring the model number and one-paragraph summary.