Week 7: Web App Security & the OWASP Top 10 (Part 2)

// app.js -- fetches whatever URL the user supplies, to display as an avatar
app.post('/avatar', async (req, res) => {
  const image = await fetch(req.body.imageUrl);
  // ...saves the image
});

// Normal use: imageUrl = "https://example.com/photo.jpg"

// Attack: imageUrl = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
// This is the AWS instance metadata endpoint -- reachable ONLY from inside
// the cloud instance itself. The SERVER fetches it on the attacker's behalf,
// potentially returning live IAM credentials in the response.

# 1. Allowlist expected domains/protocols -- never fetch arbitrary user-supplied URLs
# 2. Block requests to private IP ranges and the cloud metadata address explicitly:
#    127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254
# 3. Disable HTTP redirects when fetching, or re-validate the destination after
#    following one -- a redirect can point somewhere the original URL didn't
# 4. If the metadata endpoint must be reachable, require IMDSv2 (a session-token
#    based version AWS added specifically because plain GET-based SSRF like
#    this was such a common real-world attack path)

# In languages with "rich" native serialization (Java, PHP, Python's pickle,
# Ruby's Marshal), deserializing a byte stream can reconstruct ANY object
# the language's type system allows -- including objects whose creation
# triggers side effects.

# An attacker who can supply the serialized data (a cookie, a cache value,
# an API payload) can craft one that, when deserialized, executes arbitrary
# code -- this is a well-documented, repeated real-world vulnerability class
# in Java and PHP applications specifically.

# Plain JSON deserialization does NOT have this problem -- JSON.parse()
# only ever produces plain objects/arrays/primitives, never arbitrary
# class instances with executable side effects.

// GET /api/invoices/8842 -- returns alice's own invoice, fine
// GET /api/invoices/8843 -- alice tries the next ID, and gets bob's invoice

app.get('/api/invoices/:id', async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id);
  res.json(invoice);   // BUG: never checked that req.user owns this invoice
});

// Fix: verify ownership as part of every fetch, not just at a higher "you're logged in" gate
app.get('/api/invoices/:id', async (req, res) => {
  const invoice = await db.invoice.findById(req.params.id);
  if (!invoice || invoice.userId !== req.user.id) {
    return res.status(404).send();   // 404, not 403 -- don't confirm the ID even exists
  }
  res.json(invoice);
});

1. Default credentials left unchanged (admin/admin on a database console)
2. Verbose error pages in production, leaking stack traces, file paths,
   or database schema to any user who triggers an error
3. Directory listing enabled on a web server, exposing files never meant
   to be browsed to directly
4. Unnecessary features/services/ports enabled (Week 3's attack surface,
   applied specifically to the app layer -- an admin panel with no
   additional auth, reachable from the public internet)
5. Overly permissive CORS (Access-Control-Allow-Origin: *) on an endpoint
   that returns sensitive, authenticated data
6. Outdated software with known CVEs left unpatched (Week 11)

// An API endpoint returning private user data
app.get('/api/me', (req, res) => {
  res.set('Access-Control-Allow-Origin', '*');       // any site can read this response
  res.set('Access-Control-Allow-Credentials', 'true'); // WITH the user's cookies attached
  res.json(userData);
});

// Any malicious site the victim visits can now fetch their private data
// cross-origin, because the server explicitly told every browser it's fine to

# 1. Start ZAP, configure your browser to proxy through it (usually 127.0.0.1:8080)
# 2. Browse the target app normally -- ZAP passively records every request/response
# 3. Right-click any request -> "Open/Resend with Request Editor" to manually
#    modify it: change a parameter, an ID, a cookie -- and resend
# 4. Run ZAP's "Active Scan" against the target to automatically probe for
#    common issues (reflected XSS, SQL injection patterns, missing security headers)