CS 161, Lesson 41, in 54 slides. It covers the UI attacks that "steal a click" - fake download buttons, mismatched form values, and fake cursors and browser chrome - in section 23.1, with the defenses in section 23.2. It then covers phishing with valid certificates, homograph URLs, and browser-in-browser attacks, in section 23.3. It ends with CAPTCHAs in sections 24.1 and 24.2: what they ask, why they lose the arms race, and the roughly ten-cents-per-solve farm economics that defeat them. It is anchored to textbook sections 23.1 to 24.2.
Subject: Computer Security · 82 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 41 of 45
Attacks that fool the human, not the protocol — stealing a click, faking a site, and why CAPTCHAs lose to a tenth of a penny
Objectives
Warm-up
Discussion prompt
Before we open L41 · Clickjacking, UI Attacks, Phishing & CAPTCHAs: without looking back, what was the main idea of L40 · Cross-Site Scripting (XSS), and what could you do by the end of it that you could not do before?
Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.
Answer:
CS 161, Lesson 40, in 52 slides, on cross-site scripting. It shows how an attacker injects JavaScript that the victim's browser then RUNS with the target site's origin, defeating the same-origin policy, in section 22, and covers stored XSS and reflected XSS in sections 22.1 and 22.2. It then gives the defenses: sanitizing input by HTML-encoding it, in section 22.3, and Content Security Policy, in section 22.4. It is anchored to textbook sections 22.1 to 22.4.
Concept
XSS (L40) needs the victim to click an attacker link; CSRF (L39) needs them to visit an attacker page. UI attacks make that happen — they fool the human into the click. This lesson is about attacking the person, not the protocol.
Section
Part 1 · §23.1 stealing a click
Concept
Many web attacks need the victim to ACT — click an attacker link (reflected XSS, L40) or visit an attacker page (CSRF, L39). A UI attack supplies that action by fooling the victim into clicking something they didn't intend.
Clickjacking (UI attack) — An attack that tricks the victim into clicking something other than what they think they're clicking — 'stealing a click.' Many rely on visual tricks: overlays, mismatched values, fake cursors, or fake browser chrome drawn on the page.
Concept
The textbook example: a download page shows several 'DOWNLOAD' buttons. One is the real download; the others lead to attacker sites or trigger malicious actions.
How do the fake buttons get there? Planted via stored XSS (L40), or simply bought as paid ads placed on the page. The victim, scanning for 'the button,' clicks one — and has no way to tell the real from the fake.
Counterexample
Discussion prompt
The textbook example: a download page shows several 'DOWNLOAD' buttons. One is the real download; the others lead to attacker sites or trigger malicious actions.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Intuition
A web page is just pixels the site (and whoever can inject into it) chose to draw. A button that SAYS 'Download' is not promised to DO 'download' — the label and the action are independent.
Ask yourself: when you click a button, what guarantees the click does what the button claims? (Nothing. The visible label is a hint, not a contract — which is exactly what UI attacks exploit.)
Analogy
Discussion prompt
Explain §23.1 You can't trust what the page shows you by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
A web page is just pixels the site (and whoever can inject into it) chose to draw. A button that SAYS 'Download' is not promised to DO 'download' — the label and the action are independent.
Concept
When the attacker controls more of the page, they can do better than swapping a button. Three classic moves, each defeating what the eye reports:
Matching
Match the pairs
From §23.1 With more page control: three sharper tricks — match each one to what it actually does. The descriptions have been shuffled.
Why: Mismatched form, Fake cursor, Fake browser are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Concept
An HTML form can show the user one value while submitting another. The page displays '$5'; the field actually posted to the server holds '$50'. The user sees a small charge and approves a large one.
<!-- the user reads "$5" ... -->
<span>Pay $5</span>
<!-- ... but the value that submits is $50 -->
<input type="hidden" name="amount" value="50">
<button type="submit">Confirm</button>Concept
(b) Fake cursor: the page draws a second, fake cursor offset from the real one. The user aims the FAKE cursor at a harmless target — while the REAL cursor (which is what actually clicks) sits over a malicious link.
(c) Fake browser / address bar: the page draws its own fake browser chrome — including a spoofed address bar reading bank.com. The user trusts the displayed URL, never realizing the 'address bar' is just a picture the attacker painted.
Ranking
Put in order
Put the moves of §23.1 Trace the $5-shows / $50-submits form into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. The visible text says $5; the user reads the page and believes they're approving a $5 charge.
Worked example
The attacker page renders a payment form labeled 'Pay $5'
Why: The visible text says $5; the user reads the page and believes they're approving a $5 charge.
A hidden input sets amount=50; the displayed $5 is just decorative text
Why: The browser submits the field VALUES, not the visible label. The label and the submitted value are completely independent.
The user clicks 'Confirm', having seen only '$5'
Why: From the user's view this is a routine, cheap purchase — they have no reason to inspect the hidden field.
| what the user sees | what the browser submits | match? |
|---|---|---|
| label text: $5 | amount=50 | NO |
| a small, safe charge | a 10× charge | NO |
| 'I approved $5' | server records $50 | NO |
Verify: the click was real and intended — but it didn't do what the page showed
Why: §23.1: the user clicked exactly the button they saw, yet was still robbed. 'Clicking what you can see' is no protection when the visible value and the submitted value differ.
Comparison
Comparison matrix
From §23.1 Trace the $5-shows / $50-submits form: refill the what the browser submits column from what you know. The rest of the table is as it appeared.
| what the user sees | what the browser submits | match? |
|---|---|---|
| label text: $5 | amount=50 | NO |
| a small, safe charge | a 10× charge | NO |
| 'I approved $5' | server records $50 | NO |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'As long as I only click the button that's actually visible on the page, I can't be tricked into doing something I didn't mean to.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: An overlay can put a malicious target under the visible one; a fake cursor moves the real click elsewhere; a form can DISPLAY $5 and SUBMIT $50.
A student: so what is the click actually bound to?
Why: An overlay can put a malicious target under the visible one; a fake cursor moves the real click elsewhere; a form can DISPLAY $5 and SUBMIT $50. The click is real — but the action isn't what the pixels promised.
Trap
A student: 'As long as I only click the button that's actually visible on the page, I can't be tricked into doing something I didn't mean to.'
Assume the visible button reliably reflects what the click does
Why: Wrong. An overlay can put a malicious target under the visible one; a fake cursor moves the real click elsewhere; a form can DISPLAY $5 and SUBMIT $50. The click is real — but the action isn't what the pixels promised.
A student: so what is the click actually bound to?
Distrust the visuals; the action is whatever the underlying element/value is
Why: §23.1: overlays, fake cursors, and mismatched form values all defeat 'what you see.' The defense isn't 'click carefully' — it's structural (frame controls, attention to the real cursor, §23.2).
Section
Part 2 · §23.2 making the click intentional
Concept
Every clickjacking defense chases one goal: make sure the user is clicking what they intend. The attacks decouple intent from action; the defenses try to re-couple them.
There's no single perfect fix — each defense trades away some usability or leans on the human, who is the weak link. We'll take four in turn, each with its downside.
Explain it
Discussion prompt
Explain §23.2 The general idea to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Every clickjacking defense chases one goal: make sure the user is clicking what they intend. The attacks decouple intent from action; the defenses try to re-couple them.
Concept
Put a confirmation pop-up before a dangerous action ('Really transfer $50?'). The idea is to force the user to look again before committing.
The catch is human factors: users click through pop-ups reflexively, especially frequent ones. A dialog the user dismisses on autopilot stops nothing.
Socratic
Discussion prompt
Put a confirmation pop-up before a dangerous action ('Really transfer $50?'). The idea is to force the user to look again before committing.
Suppose that were not true. What is the first thing in L41 · Clickjacking, UI Attacks, Phishing & CAPTCHAs that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Answer:
The catch is human factors: users click through pop-ups reflexively, especially frequent ones. A dialog the user dismisses on autopilot stops nothing.
Concept
(b) UI randomization: randomize the location of, e.g., a submit button each time. The attacker can't reliably overlay a fake button on a target that keeps moving. Downside: it costs usability — the UI is harder for real users too.
(c) Direct attention to the REAL cursor: freeze the screen except around the cursor, or highlight the cursor, and invalidate clicks outside the relevant region. This fights the fake-cursor trick by making the genuine pointer unmistakable.
Concept
Delay the click: require the user to hover over a control for a moment before a click registers. The pause forces the user to actually look at where they are before the action fires.
Like the others, it trades usability for safety — every legitimate click now costs a deliberate beat of waiting.
Intuition
Notice the shape of all four: they work by making the interface slower, stranger, or more insistent — randomized, frozen, delayed, double-confirmed. The attacker is forced to look — but so is everyone else.
Ask yourself: why is there no free clickjacking fix? (Because the defense has to interrupt the very automaticity that makes a UI pleasant. Security here is bought with usability — a recurring trade-off, §1.3, L1.)
Worked example
List the attacker's tricks, then ask which defense disrupts each
Why: Defenses are best understood as counters to specific moves from §23.1.
| defense | core idea | downside |
|---|---|---|
| Confirmation pop-up | ask again before a dangerous action | users click through — human factors |
| UI randomization | move the button so overlays miss | hurts usability |
| Attention to real cursor | freeze/highlight cursor; void outside clicks | intrusive; restricts the UI |
| Delay the click | require hovering before the click counts | every click is slower |
Verify: none is a complete fix; each costs usability or relies on the human
Why: §23.2: the goal — 'click what you intend' — can only be approximated. That's why structural frame controls (the supplemental note) matter too.
Trade off
Comparison matrix
From §23.2 Match each defense to the trick it blocks: every row here is a choice with a cost. Fill the core idea column, then say which row you would actually pick and what you give up for it.
| defense | core idea | downside |
|---|---|---|
| Confirmation pop-up | ask again before a dangerous action | users click through — human factors |
| UI randomization | move the button so overlays miss | hurts usability |
| Attention to real cursor | freeze/highlight cursor; void outside clicks | intrusive; restricts the UI |
| Delay the click | require hovering before the click counts | every click is slower |
Concept
⊕ Beyond the textbook's four: the classic clickjack overlays the target site in a transparent iframe above a decoy. The standard structural defense is to forbid being framed at all.
X-Frame-Options — an HTTP header (DENY / SAMEORIGIN) telling the browser not to render the page inside a frame.frame-ancestors — the modern Content-Security-Policy directive that controls exactly which origins may frame the page (supersedes X-Frame-Options).Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Just pop up a confirm dialog before any dangerous action — then the user has to approve it, so clickjacking is solved.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Human factors defeat it: users click through pop-ups reflexively, especially when they appear often.
A student: so where do pop-ups fit?
Why: Human factors defeat it: users click through pop-ups reflexively, especially when they appear often. A dialog dismissed on autopilot approves the malicious action just as readily as the safe one.
Trap
A student: 'Just pop up a confirm dialog before any dangerous action — then the user has to approve it, so clickjacking is solved.'
Treat a confirmation pop-up as a complete clickjacking defense
Why: Wrong. Human factors defeat it: users click through pop-ups reflexively, especially when they appear often. A dialog dismissed on autopilot approves the malicious action just as readily as the safe one.
A student: so where do pop-ups fit?
One weak layer among several; lean on structural controls
Why: §23.2: confirmation is a mitigation, not a fix — users click through. Combine it with UI randomization, cursor attention, click delays, and frame controls (frame-ancestors). No single one is sufficient.
Section
Part 3 · §23.3 faking the site itself
Concept
In phishing, the attacker tricks the victim into handing over personal info — passwords, card numbers — by impersonating a legitimate site. The fake site mimics the real one's UI; the attacker exploits the user's inability to tell real from fake.
Phishing — An attack that impersonates a legitimate site (its look, its URL, its branding) to trick the victim into entering personal information, which the attacker then collects. It exploits the human's difficulty distinguishing a real site from a convincing fake.
Definition probe
Sort into buckets
Every line below is part of the definition of Clickjacking (UI attack) or of Phishing — one or the other, never both. Put each where it belongs.
Concept
A crude phishing page is a lookalike at an obviously-wrong URL. Sophisticated phishing closes the remaining tells the user might catch:
Socratic
Discussion prompt
A crude phishing page is a lookalike at an obviously-wrong URL. Sophisticated phishing closes the remaining tells the user might catch:
Suppose that were not true. What is the first thing in L41 · Clickjacking, UI Attacks, Phishing & CAPTCHAs that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Concept
The attacker obtains a real TLS certificate for their phishing domain, so the browser shows the lock icon. Users read the lock as 'this site is safe' — a false sense of security.
Callback to L31: a valid cert only proves you're talking to THAT domain over an encrypted channel. It says nothing about whether the domain is honest. A phishing site can hold a perfectly valid cert for its own malicious domain.
Sorting
Sort into buckets
These are the pieces of L41 · Clickjacking, UI Attacks, Phishing & CAPTCHAs, out of order. Put each one back under the part of the lesson it belongs to.
Concept
A homograph attack registers a domain whose characters render like the real domain's but use non-ASCII code points — a Cyrillic 'а' in place of the Latin 'a,' say. On screen, bаnk.com is indistinguishable from bank.com.
real: bank.com (Latin a, U+0061)
fake: bаnk.com (Cyrillic а, U+0430)
^ looks identical, different domain entirelyConcept
Browser-in-browser: the attacker page uses JavaScript to simulate an entire browser window — title bar, controls, and an address bar — drawn inside the real page. The fake address bar can display any URL the attacker likes.
This is the §23.1 fake-browser trick aimed at phishing: the user trusts the URL in the 'address bar,' but it's just pixels the attacker painted, with no connection to where their data actually goes.
Intuition
Think of the lock icon as a sealed, tamper-proof envelope. It guarantees the letter reached this address unread by anyone in between. It does not guarantee the person at that address is honest.
Ask yourself: a phishing site has a valid cert and shows the lock — what exactly has the cert proven? (Only that you have a private, encrypted channel to the phisher's own domain. Encryption to a crook is still a channel to a crook.)
Ranking
Put in order
Put the moves of §23.3 Spot the homograph login page into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. The phishing page cloned the real bank's UI — branding, layout, login box all match.
Worked example
An email links to 'your bank,' and the page looks pixel-perfect
Why: The phishing page cloned the real bank's UI — branding, layout, login box all match.
The address bar shows bаnk.com and a lock icon
Why: The 'a' is a Cyrillic homograph, and the attacker holds a valid cert for that registered domain — so the lock genuinely appears.
| signal the user checks | what it shows | is it trustworthy? |
|---|---|---|
| page looks right | perfect clone | no — pixels are free to copy |
| URL spelling | b-a-n-k . com (homograph a) | no — different domain |
| lock icon present | valid cert for the fake domain | no — proves channel, not honesty |
Verify: every visible cue can be faked or earned by the attacker
Why: §23.3: clone the look, register a homograph, buy a cert — the lock, the URL, and the UI all check out while the site is hostile. This is why phishing works (Dhamija et al.).
Comparison
Comparison matrix
From §23.3 Spot the homograph login page: refill the what it shows column from what you know. The rest of the table is as it appeared.
| signal the user checks | what it shows | is it trustworthy? |
|---|---|---|
| page looks right | perfect clone | no — pixels are free to copy |
| URL spelling | b-a-n-k . com (homograph a) | no — different domain |
| lock icon present | valid cert for the fake domain | no — proves channel, not honesty |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'There's the padlock and a valid HTTPS certificate, so this site is legitimate and safe to type my password into.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Wrong (and FALSE). A valid certificate only proves the channel is encrypted to THAT domain (L31).
A student: so what does the lock actually certify?
Why: Wrong (and FALSE). A valid certificate only proves the channel is encrypted to THAT domain (L31). It says nothing about the domain's honesty — a phishing site can obtain a perfectly valid cert for its own malicious or homograph domain and show the lock.
Trap
A student: 'There's the padlock and a valid HTTPS certificate, so this site is legitimate and safe to type my password into.'
Read the lock / valid cert as proof the site is honest
Why: Wrong (and FALSE). A valid certificate only proves the channel is encrypted to THAT domain (L31). It says nothing about the domain's honesty — a phishing site can obtain a perfectly valid cert for its own malicious or homograph domain and show the lock.
A student: so what does the lock actually certify?
Only that you have an encrypted channel to whatever domain that is
Why: §23.3 / L31: the cert binds the channel to a domain, not to good intentions. Verify the domain itself (watch for homographs) — and remember the address bar can be a fake (browser-in-browser).
Section
Part 4 · §24.1 'is this a human?'
Concept
A CAPTCHA poses one question: 'is this a human?' It's a puzzle chosen to be easy for humans but hard for computers, used to block automated abuse.
CAPTCHA — A challenge designed to be easy for a human and hard for a computer, used to tell humans from bots and so stop automated abuse. Historically distorted letters/words; reCAPTCHA uses image tasks ('select all squares with boats'). Most target machine-vision problems.
Concept
CAPTCHAs guard actions that are only dangerous at automated scale:
Force a human into the loop and the bot's main weapon — doing the action millions of times cheaply — is blunted.
Concept
Historically a CAPTCHA showed distorted letters or words to read. Modern reCAPTCHA shows images ('select all squares with boats').
Both target machine-vision problems — reading warped text, recognizing objects — chosen because, at the time, they were hard for computers but trivial for people. (Hold that 'at the time' — §24.2 turns on it.)
Socratic
Discussion prompt
Historically a CAPTCHA showed distorted letters or words to read. Modern reCAPTCHA shows images ('select all squares with boats').
Suppose that were not true. What is the first thing in L41 · Clickjacking, UI Attacks, Phishing & CAPTCHAs that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Intuition
Think of a CAPTCHA as a turnstile that only humans can squeeze through. It doesn't stop ANY single person — it stops a script from walking through a million times a second.
Ask yourself: what does passing a CAPTCHA actually prove? (Only that the entity on the other side could solve THIS puzzle once — not that it's a human, and not that it won't do harm. Hold that thought.)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'If something passes the CAPTCHA, I know for certain there's a real human on the other end.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Passing proves only that the puzzle got solved — by a human OR by a paid human-powered solving service OR by an algorithm good enough to crack it.
A student: so what does passing really tell you?
Why: Passing proves only that the puzzle got solved — by a human OR by a paid human-powered solving service OR by an algorithm good enough to crack it. 'Solved this once' is not the same as 'is a human acting in good faith.'
Trap
A student: 'If something passes the CAPTCHA, I know for certain there's a real human on the other end.'
Treat a passed CAPTCHA as proof of humanity
Why: Wrong. Passing proves only that the puzzle got solved — by a human OR by a paid human-powered solving service OR by an algorithm good enough to crack it. 'Solved this once' is not the same as 'is a human acting in good faith.'
A student: so what does passing really tell you?
Only that SOMETHING could solve this one puzzle
Why: §24.1: a CAPTCHA at best says a human OR a paid bot solved it. It's a weak, cheap signal — useful only as one layer, never a proof of humanity.
Section
Part 5 · §24.2 the arms race & the economics
Concept
CAPTCHAs are caught in an arms race: as solving algorithms improve, the CAPTCHA must get harder to stay ahead. But there's a ceiling — push the difficulty up far enough and the puzzle becomes hard for HUMANS too.
(You've felt this: squinting at an unreadable word, or clicking traffic lights five times. That frustration is the arms race reaching the human limit.)
Socratic
Discussion prompt
(You've felt this: squinting at an unreadable word, or clicking traffic lights five times. That frustration is the arms race reaching the human limit.)
Suppose that were not true. What is the first thing in L41 · Clickjacking, UI Attacks, Phishing & CAPTCHAs that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Concept
The original CAPTCHA paper was subtitled 'How Lazy Cryptographers do AI' — the idea was that forcing attackers to solve CAPTCHAs would push them to advance machine vision as a side effect.
The irony: modern reCAPTCHA now harvests human label data ('select all the boats') to TRAIN AI. The very system meant to stop bots is feeding the models that beat it — self-defeating for the deployer.
Explain it
Discussion prompt
Explain §24.2 The irony: CAPTCHAs now train the AI to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
The original CAPTCHA paper was subtitled 'How Lazy Cryptographers do AI' — the idea was that forcing attackers to solve CAPTCHAs would push them to advance machine vision as a side effect.
Concept
For accessibility, CAPTCHAs offer an audio alternative — spoken characters for users who can't see the image. But audio recognition is often an easier problem to automate than the visual one.
So the accessible path becomes a new, often-easier attack vector: an attacker simply solves the audio version instead. A second door, weaker than the first.
Analogy
Discussion prompt
Explain §24.2 Audio CAPTCHAs open a new front by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
For accessibility, CAPTCHAs offer an audio alternative — spoken characters for users who can't see the image. But audio recognition is often an easier problem to automate than the visual one.
Concept
Even a CAPTCHA no algorithm can solve falls to CAPTCHA-solving services that employ real humans at roughly $0.10 per CAPTCHA. The bot just forwards each puzzle to a human and gets the answer back.
So the real question stopped being 'is this a human?' and became: 'is this a human, OR a bot willing to spend a fraction of a penny?'
Intuition
Stop thinking of a CAPTCHA as a test of ability and start thinking of it as a price. It charges the attacker about $0.10 of human labor per attempt. The only question that matters is whether the attacker is willing to pay it.
Ask yourself: if a successful action (a fake account, a stolen login) is worth more than $0.10 to the attacker, does the CAPTCHA stop them? (No — they'll happily pay the toll. The defense's cost must exceed the attacker's value, §1.3, L1.)
Concept
State it plainly: if solving is worth at least ~$0.10 to the attacker, CAPTCHAs DO NOT WORK. A funded or motivated attacker simply buys solutions by the thousand.
So a CAPTCHA is not a substitute for rate limiting or proper authentication (L32). It can slow casual, unfunded automation — but it is one weak layer, not a defense you rely on.
Counterexample
Discussion prompt
State it plainly: if solving is worth at least ~$0.10 to the attacker, CAPTCHAs DO NOT WORK. A funded or motivated attacker simply buys solutions by the thousand.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Ranking
Put in order
Put the moves of §24.2 The cost calculus: when does a CAPTCHA fail? into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. §24.2: human-powered services price each CAPTCHA at roughly a tenth of a penny, available in bulk.
Worked example
Fix the attacker's cost per solve at ~$0.10 (a solving farm)
Why: §24.2: human-powered services price each CAPTCHA at roughly a tenth of a penny, available in bulk.
Compare that cost to the value the attacker extracts per success
Why: If value-per-success ≥ cost-per-solve, the attacker profits and proceeds; the CAPTCHA is just overhead.
| attacker's goal | value per success | vs ~$0.10 solve | CAPTCHA stops it? |
|---|---|---|---|
| spam account for resale | ≈ $1+ | value ≫ cost | no |
| test one stolen credit card | tens of $ | value ≫ cost | no |
| idle, zero-payoff scraping | ≈ $0 | cost > value | yes — not worth paying |
Verify: a CAPTCHA only deters when the payoff is below the ~$0.10 toll
Why: §24.2: against any attacker for whom success is worth ≥ ~$0.10, CAPTCHAs do not work. Real defense comes from rate limiting and proper auth (L32), with the CAPTCHA at most one thin layer.
Comparison
Comparison matrix
From §24.2 The cost calculus: when does a CAPTCHA fail?: refill the value per success column from what you know. The rest of the table is as it appeared.
| attacker's goal | value per success | vs ~$0.10 solve | CAPTCHA stops it? |
|---|---|---|---|
| spam account for resale | ≈ $1+ | value ≫ cost | no |
| test one stolen credit card | tens of $ | value ≫ cost | no |
| idle, zero-payoff scraping | ≈ $0 | cost > value | yes — not worth paying |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'I'll put a CAPTCHA on the login and signup — that'll keep determined attackers out for good.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: CAPTCHA-solving farms employ real humans at ~$0.10 each, and audio CAPTCHAs and improving AI add more cracks.
A student: so what actually limits the attacker?
Why: CAPTCHA-solving farms employ real humans at ~$0.10 each, and audio CAPTCHAs and improving AI add more cracks. Any attacker for whom a success is worth ≥ ~$0.10 simply pays the toll and proceeds.
Trap
A student: 'I'll put a CAPTCHA on the login and signup — that'll keep determined attackers out for good.'
Rely on a CAPTCHA to stop a motivated or funded attacker
Why: Wrong. CAPTCHA-solving farms employ real humans at ~$0.10 each, and audio CAPTCHAs and improving AI add more cracks. Any attacker for whom a success is worth ≥ ~$0.10 simply pays the toll and proceeds.
A student: so what actually limits the attacker?
Rate limiting and proper auth (L32); CAPTCHA is at most one thin layer
Why: §24.2: solving farms defeat CAPTCHAs cheaply, so they don't replace rate limiting. Cap attempts per account/IP and use strong authentication; treat the CAPTCHA as friction against casual bots, not a wall.
Two truths and a lie
Sort into buckets
Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.
Constraint
Discussion prompt
Run The UI-attack & CAPTCHA playbook with this step confiscated:
A CAPTCHA asks 'is this a human?' — easy for humans, hard for computers — to stop automated DoS and login brute-forcing (L32). It proves at most 'a human OR a paid bot solved this once' (§24.1).
Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.
Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.
Answer:
Pattern
X-Frame-Options, CSP frame-ancestors). No single one is a full fix (§23.2).Edge cases
Discussion prompt
The UI-attack & CAPTCHA playbook works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".
Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.
Answer:
Elimination
Eliminate the wrong options
Which statement about this phishing page is TRUE?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: D
Why: §23.3 / L31: a valid certificate proves only that you have an encrypted channel to THAT domain — it says nothing about whether the domain is honest, and an attacker can obtain a valid cert for a homograph domain like bаnk.com (Cyrillic 'а'). The cloned UI, the lookalike URL, and the lock icon are all things the attacker can fake or earn, which is exactly why phishing works (Dhamija et al.). The other options each rest on a misconception this lesson is built to retire.
Check
A phishing page is a pixel-perfect clone of your bank at the homograph domain bаnk.com, served over HTTPS with a valid certificate (the lock icon shows). It also asks you to pass a CAPTCHA before 'logging in.' Think through what the lock proves, what the CAPTCHA proves, and what would actually have protected you before choosing.
Check your understanding
Which statement about this phishing page is TRUE?
Answer: D
Why: §23.3 / L31: a valid certificate proves only that you have an encrypted channel to THAT domain — it says nothing about whether the domain is honest, and an attacker can obtain a valid cert for a homograph domain like bаnk.com (Cyrillic 'а'). The cloned UI, the lookalike URL, and the lock icon are all things the attacker can fake or earn, which is exactly why phishing works (Dhamija et al.). The other options each rest on a misconception this lesson is built to retire.
Concept
Concept
frame-ancestors: forbidding the transparent-iframe overlay is the clean, non-human-dependent fix for clickjacking.Concept
X-Frame-Options / frame-ancestors; Dhamija, Tygar & Hearst, 'Why Phishing Works' (CHI 2006) — the user study showing security cues don't help.Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — Clickjacking & UI Attacks · Clickjacking Defenses · Phishing · CAPTCHAs — The Purpose · Why CAPTCHAs Fail. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now explain UI attacks that steal a click (fake buttons, a $5-shows/$50-submits form, fake cursors and browser chrome) and rank their defenses (each with a downside); describe phishing and why a valid cert, a homograph URL, and the lock icon are false signals; state what a CAPTCHA asks and why the arms race plus ~$0.10 solving farms make it fail; and connect all of it to human factors, economics, and rate limiting (L32).
| Idea | § | The one-line version |
|---|---|---|
| UI attack | 23.1 | steal a click; the visible UI ≠ what the click does |
| $5 / $50 form | 23.1 | displays one value, submits another |
| Fake cursor / browser | 23.1 | real cursor and real URL aren't what's drawn |
| Defenses | 23.2 | pop-ups (click-through), randomize, cursor focus, delay |
| Phishing | 23.3 | clone the site; exploit can't-tell-real-from-fake |
| The lock lies | 23.3 | valid cert = channel to THAT domain, not honesty (L31) |
| CAPTCHA purpose | 24.1 | 'is this a human?'; stops automated abuse (L32) |
| Why it fails | 24.2 | arms race + ~$0.10 solving farms; ≥ $0.10 → it fails |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.