Exercises: Application Security

DataField.Dev

Exercises: Application Security

These exercises move from recognizing the OWASP categories to reviewing code, writing requirements, and threat-modeling a feature. Difficulty is marked ⭐ (recall/application), ⭐⭐ (analysis), and ⭐⭐⭐ (synthesis/design/open-ended). A dagger (†) marks problems with a full worked solution in Appendix: Answers to Selected Exercises — attempt every problem before reading a solution.

All code is for reading and reasoning, not running. Where a problem says "review this code," your job is to find the weakness and describe the fix — defensively. Never write or run a working exploit; show the vulnerable pattern only to then secure it.

Part A — OWASP Top 10 and core vocabulary ⭐

1.† In one sentence each, define secure software development lifecycle (SSDLC), input validation, output encoding, and security requirement. Then write one sentence using all four to describe how a single feature gets built securely.

2. Match each scenario to its OWASP Top 10 category (Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable & Outdated Components, Identification & Authentication Failures, Software & Data Integrity Failures, Security Logging & Monitoring Failures, Server-Side Request Forgery): (a) A user changes ?id=1004 to ?id=1005 and reads another customer's statement. (b) The app runs a logging library with a published critical CVE. (c) Passwords are stored as unsalted MD5. (d) A debug endpoint and a default admin password were left enabled in production. (e) There is no rate limit on the password-reset feature — and never was. (f) The server fetches any URL a user supplies, including internal addresses.

3. Explain the difference between the OWASP Top 10 and a CWE. Which one would you expect to see on a single scanner finding for one specific bug, and which describes a whole family of bugs?

4.† Explain why "we ran the OWASP Top 10 before launch and passed" is a weak statement about an application's security. Reframe it as something a mature program would say instead.

5. Define dependency risk and distinguish a direct from a transitive dependency. Which is more dangerous to a defender, and why?

6. For each OWASP category below, name the single program-level practice that most directly prevents the whole class (not a one-off fix): (a) Injection; (b) Vulnerable & Outdated Components; (c) Insecure Design; (d) Broken Access Control.

Part B — Find the vulnerability (secure-code review) ⭐⭐

For each, (i) name the weakness and its OWASP category, (ii) explain how it is abused, and (iii) describe the secure fix. Do not write a working exploit.

7.† Review this server-side handler. What is wrong, and how do you fix it?

def get_document(request):
    doc_id = request.params["doc_id"]           # comes straight from the URL
    # user is authenticated, so we trust them:
    return storage.fetch(doc_id)                 # return whatever doc_id names

8. Review this "validation." Why does it fail to make the value safe, and what should replace it?

def clean_search(term):
    return term.replace("<script>", "").replace("'", "")   # strip "bad" things

9.† Review this configuration choice. Which OWASP category does it fall under, and what is the risk?

# application.conf
debug_mode = true
show_stack_traces = true        # full traces returned to the browser on error
admin_user = "admin"
admin_password = "admin"        # default, never changed

10. Review this dependency declaration found in a build file. What should a defender do, and which tool would have surfaced the problem automatically?

dependencies:
  - log4j-core: 2.14.1        # pulled in transitively by the reporting library
  - some-json-lib: 1.2.0      # last released 6 years ago, unmaintained

11.† Review this credential handling. State the weakness, why it is severe even if the line is later deleted, and the correct pattern.

DB_PASSWORD = "Sup3rSecret!2024"     # hard-coded, committed to the repo
conn = connect(user="svc_app", password=DB_PASSWORD)

12. Review this template fragment that renders a user-supplied display name into a web page. Explain the missing control and the context-specific fix (describe it; do not write an exploit).

<h1>Welcome, {{ raw_display_name }}</h1>     <!-- inserted without encoding -->

Part C — Write the security requirement / policy ⭐⭐

13.† Rewrite each piece of vague advice as a single, verifiable security requirement using "SHALL," and name how a tester could verify it: (a) "Validate the upload." (b) "Make sure only the right people see the file." (c) "Don't store secrets in code." (d) "Log important stuff."

14. Draft a four-line secure-coding standard snippet (policy language) covering: server-side input validation, output encoding, parameterized queries, and no hard-coded secrets. Write it as mandatory statements a developer could be held to.

15.† A team proposes a new "export all customer transactions to CSV" feature. Write three security requirements for it, each tied to a STRIDE letter, and state what each prevents.

16. Write a one-paragraph SSDLC gate policy: for each of design, code, build, and test, state the one security activity that is mandatory before work proceeds to the next phase.

Part D — SAST / DAST / SCA in practice ⭐⭐

17.† For each question, state which of SAST, DAST, or SCA answers it best, and why the other two do not: (a) "Is any imported library running a known-vulnerable version?" (b) "Does the running login page leak a stack trace on malformed input?" (c) "Does any code path send user input into a SQL string without parameterization?"

18. A SAST tool flags a line as a SQL-injection risk; a DAST scan of the same deployed app does not flag the corresponding behavior. Give two different, legitimate explanations and say which is more worrying.

19.† Your SAST tool returns 4,000 findings before a release. Describe, in steps, how you would turn that into a defensible "block the release on these N issues" decision. Which findings would you suppress, and on what basis would you gate?

20. Place each tool at its SDLC phase from Figure 12.1 (design / code / build / test / operate) and state one thing it can find that the others cannot.

Part E — Threat-model a feature ⭐⭐–⭐⭐⭐

21.† Meridian is adding a feature: customers can add a new payee (name, account number, routing number) to their bill-pay list, then send money to it. Run a STRIDE threat model: (a) Draw (in text) the feature and its primary trust boundary. (b) List one credible threat for each STRIDE letter. (c) Turn three of those threats into verifiable security requirements.

22. For the payee feature in Exercise 21, identify the single threat you judge highest-risk (using likelihood × impact from Chapter 1) and justify the rating. What residual risk remains after your control?

23. ⭐⭐⭐ Pick a feature from an app you use (password reset, profile-photo upload, comment posting, file sharing). Threat-model it with STRIDE, produce at least five security requirements, and identify which OWASP category each requirement defends. Keep it to one page.

Part F — Analyze this (log / scenario) ⭐⭐

24.† During a Log4Shell-class event, a defender greps web logs and finds entries like this (illustrative; the payload is shown defanged as [JNDI-LOOKUP] — do not reconstruct a live payload):

12:04:11  GET /search  ua="Mozilla/5.0"  q="[JNDI-LOOKUP]"   src=203.0.113.7
12:04:12  GET /login   ua="[JNDI-LOOKUP]" user=guest          src=203.0.113.7
12:04:15  GET /  ua="[JNDI-LOOKUP]"                            src=198.51.100.9

(a) What is the attacker probing for, and what does the spread across multiple fields and paths tell you? (b) Is finding these log lines evidence that you are vulnerable? What additional information settles it? (c) Which tool (SAST/DAST/SCA) determines whether you are actually exposed, and why?

25. A vendor emails Meridian: "Our product is not affected by Log4Shell." What three questions should Elena Vasquez ask before accepting that, and what artifact would let the vendor prove it (preview of Chapter 29)?

Part G — Design it ⭐⭐⭐

26. ⭐⭐⭐ Design the AppSec gates. Meridian's developers push code 30 times a day. Design a set of SSDLC security gates (which checks run, at which phase, and what fails the build vs. merely warns) that catches the issues in this chapter without grinding development to a halt. Justify each block-vs-warn choice. (This is the design Chapter 31 automates.)

27. Design a dependency-risk process. Sketch how Meridian should (a) inventory dependencies, (b) learn the day a component it runs becomes vulnerable, and (c) decide how fast to patch. What artifact from Chapter 23/29 makes step (a) a query instead of an archaeology project?

Part H — CTF-style challenge ⭐⭐⭐

28.† The "secure" code review. A developer submits this function and a note: "Fully secured — I validate the input and use the database." Find every distinct security problem, name each one's OWASP category, and rewrite the function correctly (in pseudocode or Python). There is more than one issue.

def login(request):
    user = request.params["user"]
    pw   = request.params["pw"]
    if len(user) < 50:                                   # "input validation"
        query = "SELECT * FROM users WHERE name='" + user + "' AND pw='" + pw + "'"
        row = db.execute(query)                          # build query by concatenation
        if row:
            log.info("login ok")                         # what's missing here?
            return ok(set_cookie="session=" + user)      # session = the username
    return deny()

Part I — Interleaved & forward-looking ⭐⭐

29. (Interleave Ch.3) This chapter said we validate input and encode output and (in Chapter 13) run a WAF. Which Chapter 3 principle is that an example of, and why does it apply even when each individual control is "good enough"?

30. (Interleave Ch.1) Restate the Log4Shell lesson ("know what you run") in the exact vocabulary of Chapter 1 (asset, vulnerability, risk, control). Which Chapter 1 maxim does it most directly illustrate?

31. ⭐⭐⭐ (Forward to Ch.23, 29, 31) Log4Shell appears again in three later chapters as a different kind of problem each time (vulnerability prioritization, supply-chain/SBOM, pipeline integrity). For each, predict in one sentence what new question the same incident will be used to teach. Revisit after Part VII.

32. (Forward to Ch.13) Based only on this chapter's "separate code from data" principle, predict how parameterized queries stop SQL injection — before Chapter 13 explains it. Write two sentences.

Solutions to daggered (†) problems are in the Answers appendix. The remaining problems are deliberately open — bring them to a study group, a code-review session, or your instructor. Remember: show a vulnerable pattern only to secure it; never produce a working exploit.