Antihero stories.

mdx/article/2024/antihero_stories.mdx

@@ -0,0 +1,127 @@
+---
+title: Antihero Stories
+date:
+  - 22
+  - nov
+  - 2024
+tags:
+  - writing
+  - security
+language: en-GB
+description: Article where I explain why I think a user story written from the point of view of an attacker should be mandatory.
+---
+
+                                Antihero Stories.
+-------------------------------------------------------------------------------
+
+*In this article, I explain why I think it should be *mandatory* for security vulnerabilities to come with a form of ‘user story’ – a short, first-person story from the point of view of an attacker and I decry [weasel-word] usage of technical security terms to create the appearance of vulnerability where there is none.*
+
+[weasel-word]: https://en.wikipedia.org/wiki/Weasel_word "Weasel word (Wikipedia)"
+
+In the early days of computer hacking, everything had to happen by destruction
+or whining.
+
+In Hackers (1994) 11-year-old Dade “Zero Cool” Murphy’s family is fined $45,000
+for his crashing of 1,507 computer systems, causing a seven-point drop in the
+New York Stock Exchange. This is destruction. I'm certain the NYSE fixed the
+issue within 30 business days.
+
+Hackers (1994) is a fiction. Real hackers mostly had to get by with whining,
+which is where I send an email explaining how bad the issue is, pleading to
+have it fixed. In a twist of fate I argue is convergent evolution, the best of these look like [user stories][user story]:
+
+[user story]: https://en.wikipedia.org/wiki/user_story "User story (Wikipedia)"
+
+> (As an attacker,) I want to get access to a victim’s account, so I can divert
+> their payout information to my bank account. When I send the victim user my
+> special link, it causes their browser to send my server their authorization
+> token. I, (as an attacker,) use this token to change the victim's payout
+> information.
+
+I think this is the golden standard of describing a vulnerability. The intent
+is clear. The means is clear. The impact is clear. Whining is a clear and
+concise method of explanation to non-hackers born of necessity.
+
+A vulnerability is a path through a very complex system. Most of those paths go nowhere. Even ones that fit into vulnerability taxonomies. A hacker puts all these complex pieces together and – in theory – creates a path through them that starts at something an attacker can control, and ends in something the attacker wants.
+
+Thanks to the advent of Bug Bounty and Responsible Disclosure, even to the the
+outside world, sometimes all we need to say is ‘XSS’, or ‘SQLi’, ‘open
+redirect’, ‘buffer overflow’, or traversing into the barely legitimate:
+‘content injection’, ‘information leak’, ‘confused deputy’. Security vendors
+will be string these together like novel animal species or viral strains and
+season with a smattering of CVSS values based on vibes.
+
+Many of these technical terms came to exist as legitimate shorthand between comrades who trust each and want to short-cut the explaining. Most hackers know what `alert(document.origin)` means. Everyone knows what it means to pop a calculator. These are all shorthands. They do not demostrate the existence of the paths I mentioned before.
+
+I do genuinely think that our usage of this type of security terminology has, in the hands of some, taken on a distinctly dark and insincere bent that I think that user stories could dispel. I will follow this with an example I came across that I think illustrates this well, but before that, let’s analyse some terms I particularly dislike.
+
+                      “Broken”, “Missing”, and “Improper”.
+===============================================================================
+
+Vulnerability taxonomies exist to categorise vulnerabilities for tracking. But
+they are irrevocably tied to the idea that demonstrating a category of taxonomy
+inherently demonstrates vulnerability. In this sense, Everything in the
+[Bugcrowd Vulnerability Taxonomy] that includes ‘broken’ is on my shitlist.
+This includes: **Broken Authentication and Session Management**, **Broken
+Access Control (BAC)**, **Broken Access Control (BAC)**, and **Broken
+Cryptography**.
+
+[Bugcrowd Vulnerability Taxonomy]: https://bugcrowd.com/vulnerability-rating-taxonomy
+
+I also include the more standard CWE terms “missing”, and “improper” when it is
+presented without reference to a specific technology: [CWE-862] “Missing
+Authorization”, [CWE-20] “Improper Input Validation”, [CWE-287] “Improper
+Authentication”, [CWE-269] “Improper Privilege Management”, and so on.
+
+[CWE-862]: https://cwe.mitre.org/data/definitions/862.html
+[CWE-20]: https://cwe.mitre.org/data/definitions/20.html
+[CWE-297]: https://cwe.mitre.org/data/definitions/287.html
+[CWE-269]: https://cwe.mitre.org/data/definitions/269.html
+
+These terms fulfil only the function of telling the reader that the reporter
+thinks the thing in question is bad, without any information at all about why
+it is bad. *Of course* the reporter thinks the thing is bad. They would not be
+reporting it otherwise.
+
+It is eminently obvious that demonstration of ‘Missing Authorization’ is not
+itself a demonstration of a security vulnerability. Nobody should be making
+arguments that being able to access ChatGPT without being logged in is a
+vulnerability. The term _begs the question_ of _why_ the reporter thinks
+missing authorization is an issue.
+
+If I asked them why it was an issue, perhaps they would say ‘unauthorized access to customer data’ – in which case, congratulations! We've found an actually good way of describing the vulnerability at hand.
+
+I think in a way, this is a reflection of the ‘[five whys]’ principle. The answer to ‘why did we have an incident yesterday’ should not be ‘the website was down’. It should be ‘we do not prevent two commits being deployed to production at the same time’ or some other statement reflecting a resolution that cuts deep enough to not have to ask ‘why?’ one more time.
+
+[five whys]: https://en.wikipedia.org/wiki/Five_whys "Wikipedia: Five whys"
+
+
+
+
+
+Thomas
+
+San Francisco, California, USA
+
+Below are segments from the old article! They should be re-incorperated where
+appropritate:
+
+Data URI Injection
+This was a craaazy vulnerability type between probably sometime in the 90s until about 2017. When you use the web, you're on 'http:'. That's the protocol. But there's also 'mailto:' for email, and there once was 'ftp:' for file transfer. After Web 2.0 became a thing, data: URIs became a thing.
+Normally, if I put a picture such as below, a beautiful picture of San Francisco's Civic Centre plaza in 1940, it is a link (like with 'http:') loaded off the internet. So your browser goes to that link for you that has the picture, downloads it, and puts it in the page. But that means loading 2 things, and it's 2010 and loads are slow!
+Ray M. Mann, Jr. Color Slides of Golden Gate International Exposition, 1940. SFPL AAZ-1445So when I put this other picture of the same location in 2024 in my web page, I may use a data: URI. And this data: URI might specify the full content of the image in-line, without a second request being made. That way, you can see the tragic extent of the demolition of San Francisco's civic space much more quickly.
+Google Street ViewI can't put one here in Medium, because they're banned. Why are they banned? Because until 2017, a data: URI was considered a fully trusted part of the page it appeared in, and that meant security issues. Sure, it was most often used for images, like this 1907 photo of the gardens surrounding San Francisco's Pioneer Monument:
+Pioneer Monument in Civic Center, San Francisco Department of Public Works (San Francisco, Calif.) 1907–1920 SFPL DPW-4794But it could be used to also specify web pages, such as data:text/html,<script>alert(document.domain)</script> . This web page is a tiny little one, and it contains a single piece of code. That little piece of code makes a pop-up on the screen saying what the web browser thinks the security identity of the page is. In 2010, a link like that on Medium.com would cause a pop-up window saying 'medium.com'. This meant that the mere action of making a link resulted in an attacker being able to inject code into the page! In other words:
+As an attacker, I want to delete your Medium posts, because they're not good. I make my own Medium post and in the first paragraph I make a prominent link along the lines of:
+"first, please note the required watching"
+ When my victim (you) clicks this link, my injected code runs. The browser believes that my injected code comes from Medium.com, and the code directs your browser to act as though you clicked 'delete' on your article. Your article is deleted.
+But by 2017, browser vendors realised data: URIs being treated like they were blessed by the page where the link was present was a really bad idea. They made it so that these links are treated by the browser as though they are in an opaque origin, a kind of shadow realm that unsafe code is sent to where it may not be blessed with the gift of knowing its own origin.
+In a modern browser, clicking a data: URI with my code results in a single word null , which is the human name for the opaque origin.
+This hasn't stopped people claiming it's a security issue though! They just removed the document.domain proof that the origin is inherited and instead the pop-up just says "XSS!". A quick Google shows payouts on HackerOne for this as late as 2020 using exactly this sleight of hand (by 2021, it looks like people had caught on). I remember responding to these for years.
+I don't think these payouts were from well-informed individuals making carefully considered decisions about their long-tail of users who haven't upgraded their web browsers since 2017.
+The first XSS of this kind I'm sure had to justify itself; but by 2020 we were happy to fork over $500 at the first sign of a pop-up, having totally forgotten what the meaning of the action was.
+By the way, this is what the Pioneer Monument looks like today:
+Google MapsCall to Action
+I am not saying that user stories are bulletproof. A malicious reporter absolutely could concoct a user story that appears true, but is not. But the difference is the currency. The fact is, what the reporter demonstrated was XSS. They have presented valid currency in the system we have built.
+But the real currency is risk, and that's a product of probability and impact, something expressed intuitively in a user story. I think if we more often did, we would be much easier to understand. 
+I want to live in a world where someone mostly non-technical can read a security vendor report and intuitively understand why 'network-local hypertext information leak sidechannel' was rated CVSS 3.0 4.7 (Medium) CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N. I don't think it's too far away. I promise, you can still send your reports in PDFs 0.5–1 vulnerabilities to a piece of paper. With cover sheets for each section, and some pages intentionally left blank. I'll leave a few SSL cipher suites a few years out of date as a treat.

project/zemn.me/app/article/2024/antihero_stories/BUILD.bazel

@@ -0,0 +1,20 @@
+load("//bzl:rules.bzl", "bazel_lint")
+load("//ts:rules.bzl", "ts_project")
+
+ts_project(
+    name = "antihero_stories",
+    assets = glob(["**/*.css"]),
+    visibility = ["//project/zemn.me:__subpackages__"],
+    deps = [
+        "//:node_modules/next",
+        "//mdx:mdx_js",
+        "//project/zemn.me/components/Article",
+        "//ts/react/lang",
+        "//ts/time",
+    ],
+)
+
+bazel_lint(
+    name = "bazel_lint",
+    srcs = ["BUILD.bazel"],
+)

project/zemn.me/app/article/2024/antihero_stories/page.tsx

@@ -0,0 +1,17 @@
+
+import { Metadata } from 'next/types';
+
+import Content from '#root/mdx/article/2024/antihero_stories.js'
+import { frontmatter } from '#root/mdx/article/2024/antihero_stories.js';
+import { articleMetadata } from '#root/project/zemn.me/components/Article/article_metadata.js';
+import { MDXArticle } from '#root/project/zemn.me/components/Article/mdx_article.js';
+
+
+
+export default function Page() {
+	return <MDXArticle {...{frontmatter}}>
+		<Content/>
+	</MDXArticle>
+}
+
+export const metadata: Metadata = articleMetadata(frontmatter);

project/zemn.me/app/article/BUILD.bazel

@@ -7,6 +7,7 @@ ts_project(
     deps = [
         "//project/zemn.me/app/article/2014/csp",
         "//project/zemn.me/app/article/2019/cors",
+        "//project/zemn.me/app/article/2024/antihero_stories",
         "//project/zemn.me/app/article/2024/missing",
     ],
 )