Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Web Security, Frontend Masters

Steve Kinney
May 31, 2024
1.1k

Web Security, Frontend Masters

Steve Kinney

May 31, 2024
Tweet

Transcript

  1. “Oh, well we had to do $thing in order to

    get $feature working.” —Famous last words in a code review.
  2. “I don’t need to learn about web security. $framework just

    handles all of this stuff for me.” —Someone who is accidentally about to create a security hole.
  3. So, let’s dig in. In this course, we’re going to

    cover… Common vulnerabilities found in many web applications.
  4. So, let’s dig in. In this course, we’re going to

    cover… The ways in which attackers can exploit those vulnerabilities.
  5. So, let’s dig in. In this course, we’re going to

    cover… A reasonably deep understanding of the tools provided by the browser and best practices on the server to protect yourself from these vulnerabilities.
  6. So, let’s dig in. In this course, we’re going to

    cover… The trade-offs between security, user experience, and the complexity of our infrastructure.
  7. Keeping track of the currently authenticated user. Storing the contents

    of a shopping cart. Or, more nefariously: tracking users. HTTP is stateless. Cookies are used to implement sessions. Cookies
  8. A brief history. Cookies No Speci fi cation Speci fi

    cation 1994 1997 2000 2011 Today 1994: Implemented by Netscape.
  9. A brief history. Cookies No Speci fi cation Speci fi

    cation 1994 1997 2000 2011 Today 1997: First attempt to standardize.
  10. A brief history. Cookies No Speci fi cation Speci fi

    cation 1994 1997 2000 2011 Today 2000: “Cookie2”, a second attempt to standardize.
  11. A brief history. Cookies No Speci fi cation Speci fi

    cation 1994 1997 2000 2011 Today 2011: Standardized as RFC 6265.
  12. The server sets a cookie with an HTTP header. Cookies

    Set-Cookie: username=bobbytables; HTTP Header Key Value
  13. The browser sends back the cookie on subsequent requests. Cookies

    Cookie: username=bobbytables; HTTP Header Key Value
  14. Expires: Set-Cookie: username=bobbytables; Expires=Thu, 29 Feb 2024 17:45:00 GMT; Max

    Age: Set-Cookie: username=bobbytables; Max- Age=2592000; Without some kind of expiration, cookies last for the duration of the session. Expiration Dates. Cookie Attributes
  15. You can’t. But, you can set it’s expiration date to

    some time in the past. And, this will delete the cookie. I don’t make the rules around here. How to delete a cookie. Cookies
  16. The Path attribute indicates a URL path that must exist

    in the requested URL in order to send the Cookie header. Set-Cookie: username=bobbytables; Path=/profile; This predates a lot of the modern browser securities features and you’re better off not relying on it for security. Scoping. Cookie Attributes
  17. The Domain attribute specifies which server can receive a cookie.

    If specified, cookies are available on the specified server and its subdomains. Set-Cookie: username=bobbytables; Domain=.frontendmasters.com; This would allow the cookie to be sent to any subdomain of frontendmasters.com. Scoping. Cookie Attributes
  18. A security measure implemented by web browsers to restrict how

    documents or scripts loaded from one origin interact with resources from other origins. Two resources from different sites shouldn’t be able to interfere with each other. Same Origin Policy
  19. The browser checks three things: the protocol (e.g. https:// vs

    http://), the domain (e.g. frontendmasters.com) and the port (e.g. 443). If those three things are the same, then the browser considers the two resources to have the same origin. How it works. Same Origin Policy
  20. Cross Origin Resource Sharing (CORS) JSON with Padding (JSONP) Proxies

    PostMessage API WebSockets document.domain Ways around it. Same Origin Policy
  21. Session Hijacking: Exploits active sessions to gain unauthorized access. Basically,

    the attacker can become the user as far as the server is concerned. Cross-Site Scripting (XSS): A Malicious script injected via input fields or URLs. The script then accesses cookies and sends them to an attacker. Cross-Site Request Forgery (CSRF): An innocent user is tricked into executing actions via a forged request, exploiting that user's authenticated session. Some common vulnerabilities. Cookies
  22. A type of security exploit where an attacker gains elevated

    access to resources that are normally protected from an application or user. Privilege Escalation
  23. Initial Access: The attacker gains limited access tot he application

    or system. Discovering Weaknesses: The attacker identifies misconfigurations or vulnerabilities that can be exploited. Exploiting Vulnerabilities: They then use these weaknesses to gain higher privileges than originally intended. Gaining Control: With escalated privileges, they can access sensitive data or execute unauthorized actions. How it works. Privilege Escalation
  24. Using a cookie value in an attempt to try to

    trick the server into thinking that you’re someone that you’re not. Session Hijacking
  25. A type of attack where the attacker secretly intercepts and

    possibly alters the communication between two parties who believe they are directly communicating with each other. Man-in-the-Middle Attacks
  26. Luckily, this has a pretty easy fix: Use HTTPS. (We’ll

    talk a little more about this later.)
  27. HTTPOnly: Prevents client-side scripts from accessing cookies. Secure: Ensures cookies

    are sent over HTTPS only. SameSite: Restricts how cookies are sent with cross-origin requests. Security. Cookie Attributes
  28. It’s not the same as the origin. TLD+1: Two addresses

    are the SameSite if they have the same TLD plus one more level: example.com login.example.com Exceptions: github.io and similar. The SameSite attribute. Cookie Attributes
  29. A class of vulnerabilities caused by the attacker sending malicious

    inputs to your application is homes of breaking out and causing some damage. Injection Attacks
  30. A type of security vulnerability where an attacker can execute

    arbitrary commands on the host operating system via a vulnerable application. Command Injection
  31. Target: Applications that pass unsafe user inputs to system shell

    commands. User Input: Application receives input from a user. Unsanitized Input: The user input is concatenated with a system command in a way that allows additional commands to be executed. Shell Execution: The combined command is executed in the system command shell. Malicious Payload: Attackers inject malicious commands, piggybacking on legitimate commands. How it works. Command Injection
  32. A somewhat silly example that fi ts on a slide.

    Command Injection import { exec } from 'child_process'; app.get('/files', (req, res) = { const command = `ls $ req.body}`; exec(command, (error, stdout, stderr) = { if (error) { return res.status(500).send(error.message); } if (stderr) { return res.status(500).send(stderr); } res.send(stdout); }); }); User Input: test.txt; rm -rf /
  33. First: Just don’t. Second: Use a built-in Node module (e.g.

    fs) if you really need to. Third: Use execFile if you really need to. Fourth: Sanitize, allowlist, and use the principle of least privilege if you really need to. Remediation. Command Injection
  34. A class of security flaws that occur when a web

    application improperly handles the uploading of files. File Upload Vulnerabilities
  35. This one kind of does what it says on the

    tin. Remote Code Execution (RCE) is a vulnerability that allows an attacker to execute arbitrary code on a remote system. Remote Code Execution
  36. Injection: RCE typically occurs when the user input is not

    properly sanitized. Processing: The malicious input is processed by the server through eval functions, un-sanitized inputs to shell commands, or unsafe deserialization. Execution: Malicious code is executed within the server environment, providing the attacker with control over the server resources. How it works. Remote Code Execution
  37. Input Validation: Always validate and sanitize user inputs. Use strict

    data types and constraints. Don’t Do Dangerous Stuff: Avoid using eval(), Function(), exec(), and other potentially dangerous Node.js functions. Use Security Libraries: Utilize libraries such as DOMPurify for sanitizing HTML. Use sandboxed environments like VM2 for executing untrusted code. Principle of Least Privilege: Run services with the minimal required permissions. Do not run your application as a root user. Update Your Stuff: Keep Node.js and all dependencies up-to-date to mitigate known vulnerabilities. Steps to prevent bad things from happening. Remote Code Execution
  38. A vulnerability that allows an attacker to make unauthorized requests

    on the user’s behalf. Side effects include: unauthorized actions like changing account settings, making purchases, and lots of other BAD STUFF™. Cross-Site Request Forgery
  39. Case Study Twitter has a URL that would allow you

    to create a post with a URL. http://twitter.com/share/update?status=Your%20Message The Twitter (CSRF) Worm (2010)
  40. Case Study Netflix had a GET endpoint that allowed you

    to add a DVD to your queue. It was as easy as… <img src="http://www.netflix.com/JSON/AddToQueue? movieid=70110672" /> Netflix (2006)
  41. Case Study The New York Times has a form on

    every article called Email This. This form made a POST request that was vulnerable to CSRF allowing the attacker to have the authenticated user send an email to the attacker, exposing their name and email address. The New York Times (2008)
  42. Case Study The researchers also discovered CSRF vulnerabilities in ING’s

    site that allowed an attacker to open additional accounts on behalf of a user and transfer funds from a user’s account to the attacker’s account. ING Direct (2008)
  43. Case Study They also discovered CSRF vulnerabilities in nearly every

    action a user can perform on YouTube. YouTube (2008)
  44. Case Study A specific endpoint on TikTok, which handled password

    resets for accounts created via third-party applications, was susceptible to CSRF attacks. The vulnerability could be exploited to change the user’s password. TikTok One-Click Account Takeover (2020)
  45. function createAndSubmitForm() { const form = document.createElement('form'); form.method = 'POST';

    form.action = 'https://example.com/delete-account'; form.style.display = 'none'; document.body.appendChild(form); form.submit(); } createAndSubmitForm();
  46. A relevant action. There has to be something interesting to

    the attacker. Relevant actions can include: email or password changes, balance transfers, etc. Cookie-based session handling. In a CSRF attack, the attacker is tricking you into accidentally performing action with your very legitimate session authentication without your knowledge. No unpredictable parameters. The attacker needs to be able to guess what it ought to send to get the desired outcome. The three ingredients to the recipe. Cross-Site Request Forgery
  47. User Authentication: User logs into a web application and receives

    an authentication token (e.g. a cookie). Malicious Site Visit: User visits a malicious website while still authenticated. Malicious Request: The malicious website contains code that sends a request to the authenticated web application. Unauthorized Action: The web application processes the request as if it were made by the user. How does it work? Cross-Site Request Forgery
  48. SameSite=None: Always send the cookie. SameSite=Lax: Allows cookies to be

    sent with top-level navigations and if the request method is safe (e.g. GET or HEAD requests). SameSite=Strict: Only include the cookie if the request is sent from the same site that set the cookie. The SameSite attribute. Cookie Attributes
  49. An action where a user initiates a change in the

    URL through direct methods like entering a URL in the address bar, selecting a bookmark, or clicking on a link that leads to another page, effectively changing the entire browser window's content to load the new page. Top-Level Navigation
  50. SameSite=Lax allows cookies to be sent with top-level navigations that

    are triggered by external sites. This can be important for legitimate use cases (e.g., a link in an email or from another domain). Lax versus Strict: A balance of trade-offs. Cookie Attributes
  51. While SameSite=Strict provides the highest level of security by restricting

    all cross-site cookie sharing (including through top-level navigations), it can disrupt user workflows. For example, if a user follows a link from an email or another site to a SameSite=Strict site where they are normally logged in, they would find themselves unexpectedly logged out. SameSite=Lax prevents this issue, providing a reasonable balance between preventing CSRF attacks and maintaining user session continuity across sites. Lax versus Strict: A balance of trade-offs. Cookie Attributes
  52. Websites often interact with external services, affiliates, or rely on

    marketing and promotional campaigns that direct traffic to their sites through links. SameSite=Lax supports these business needs without sacrificing significant security, allowing services to operate smoothly across different domains. Lax versus Strict: A balance of trade-offs. Cookie Attributes
  53. March 2019: Safari 12.1. January 2020: Chrome 80. June 2020:

    Firefox 79. October 2020: Edge 86. SameSite=Lax is now the default. Cookie Attributes
  54. Generate a unique token: Generate a token that validates that

    this is a legitimate request. Use SameSite Cookies: Limit cookies to only working with requests that come from your domain. Set up a CORS policy: Implement a strict Cross-Origin Resource Sharing (CORS) policy to disallow unauthorized domains. Referer-based validation: This is typically less-than-effective. Techniques for prevention. Cross-Site Request Forgery
  55. A CSRF token is a random value generated by the

    server. If a request is either missing or has an invalid token, then the server will reject the request. <input type="hidden" name="csrf" value=“3964ccc5b64f54696134 3c57cf" required /> Being unpredictable as a defense mechanism. CSRF Tokens
  56. If you’re using mostly AJAX requests—and not forms—you may choose

    to store the CSRF token in a meta tag. <meta name="csrf-token" content=“3964ccc5b64f546961 343c57cf"> Being unpredictable as a defense mechanism. CSRF Tokens
  57. The value proposition of CSRF tokens is that they’re unpredictable.

    As soon as an attacker can guess the token, it’s basically worthless. Some anti-patterns. CSRF Tokens
  58. See if you can get away with omitting it. See

    if you can just hide the information somewhere else. TL;DR—It doesn’t hurt, but it’s not enough on it’s own. And, how to get around it. Referer-Based Validation
  59. If you can’t use a CSRF token, you might consider

    using a second cookie that is used to validate the user’s session. An alternative to CSRF tokens. Double-Signed Cookie Pattern
  60. CSRF attacks are most effective when it’s easy to perform

    the action. So, one very easy solution is to make it harder for users to do a thing. Require them to re-authenticate. Use two-factor authentication for important actions. If you really hate your users, use a CAPTCHA. Or, making your users jump through additional hoops when it matters. UX as a Security Mechanism
  61. “Oh, I only need to worry about CSRF if the

    user is logged in.” —A well-meaning, if naïve software engineer.
  62. Cross-Origin Resource Sharing—or CORS, for short—is a security feature implemented

    by web browsers to restrict web pages from making requests to a different domain than the one that served the web page, addressing the issue of cross-origin requests. Cross-Origin Resource Sharing
  63. CORS is designed to prevent malicious websites from accessing resources

    on another domain without permission. It’s a safe way to get around the Same Origin Policy. The reason for it’s existence. Cross-Origin Resource Sharing
  64. It’s easier to describe what makes a request not simple.

    Content-Type is something other than: application/x-www-form-urlencoded multipart/form-data text/plain Request method is something other than GET, POST, or HEAD. Simple requests aren’t subject to CORS policies. Cross-Origin Resource Sharing
  65. Browsers use preflight checks for complex requests (e.g., using methods

    like PUT or DELETE, or with custom headers) to ensure that the request is safe. The server responds with specific HTTP headers (Access-Control- Allow-Origin, Access-Control-Allow-Methods, etc.) to specify whether the request is allowed. The basic mechanics. Cross-Origin Resource Sharing
  66. Access-Control-Allow-Origin: This header specifies which domains are allowed to access

    the resources. Access-Control-Allow-Origin: https://alloweddomain.com The headers. Cross-Origin Resource Sharing
  67. Access-Control-Allow-Methods: Specifies the methods allowed when accessing the resource. This

    is used in response to a preflight request. Access-Control-Allow-Methods: POST, GET, OPTIONS The headers. Cross-Origin Resource Sharing
  68. Access-Control-Allow-Headers: Used in response to a preflight request to indicate

    which HTTP headers can be used when making the actual request Access-Control-Allow-Headers: X-SUPER-CUSTOM-HEADER, Content-Type The headers. Cross-Origin Resource Sharing
  69. Access-Control-Allow-Credentials: Indicates whether or not the response to the request

    can be exposed when the credentials flag is true. If set to true, cookies and authorization headers are included in cross-origin requests. Access-Control-Allow-Credentials: true The headers. Cross-Origin Resource Sharing
  70. Don’t try to swap out headers that are subject to

    CORS (e.g. PUT, PATCH, DELETE) for simpler ones (e.g. GET, POST). Some anti-patterns. Cross-Origin Resource Sharing
  71. Don’t be fancy: Don’t try to use wildcards to sub

    in a domain or support an array of origins. You might (read: will) opt out. Only use a wildcard for your CORS policy if you never need to allow credentials. Some anti-patterns. Cross-Origin Resource Sharing
  72. Anything that starts with sec- is a header that JavaScript

    can’t touch, which means you can assume it’s safe and hasn’t been tampered with. Some additional headers set by the browsers. Request Security Headers
  73. cross-site: The request initiator and the server hosting the resource

    have a different origin and site. same-site: The request initiator have the same site—but, this could be a different origin. same-origin: The request initiator and the server hosting the resource have the same origin. none: The user did this. They entered a URL into the address bar or opened a bookmark or dragged a file into the browser window. sec-fetch-site Request Security Headers
  74. So, where’s this request going? empty if they used fetch().

    image if it’s an image. worker if it was summoned by new Worker() document for top-level navigations. iframe for—umm—iframes. sec-fetch-dest Request Security Headers
  75. sec-fetch-user: This a boolean (well, technically, it’s only ever true),

    but it’s included when a navigation request was triggered by the user. sec-fetch-mode: One of the following: cors, navigate, no-cors, same-origin, websocket. You can take a lucky guess as to when these are set. Two additional headers. Request Security Headers
  76. Cross-Site Scripting (XSS) is a type of injection attack where

    malicious scripts are injected into otherwise benign, trusted websites. This occurs when an attacker sends malicious code, generally in the form of a browser-side script, to a different end user. Cross-Site Scripting
  77. Stored: The malicious data is stored in the database or

    somewhere else on the backend. Re fl ected: The malicious data is slid into the URL or query parameters. DOM-based: The malicious data is input into the DOM (e.g. an input field that changes the page). It comes in a few different fl avors. Cross-Site Scripting
  78. Case Study A malicious script that injected the text “but

    most of all, samy is my hero” into a user’s MySpace profile page and send Samy a friend request. The payload would then plant itself on that user’s profile page. Within just 20 hours, it spread to over a million users. The Samy Worm (2005)
  79. Some browsers allowed you to execute JavaScript from CSS styles.

    <div style=“background:url('javascript:alert(1)')"></div> How it worked. The Samy Worm
  80. But, in that previous example, you’d already used up single

    and double quotes. So, working with strings would be hard. But, you could hide the code in another attribute. <div id="mycode" expr="alert('hah!')" style="background: url('javascript:eval(document.all.mycode.expr)')" ></div> How it worked. The Samy Worm
  81. MySpace stripped out the word “javascript” from everywhere. But, it

    didn’t strip out java\nscript. And, browsers were totally cool with that new line jammed in there. How it worked. The Samy Worm
  82. MySpace also stripped out any escaped quotes. But, it didn’t

    strip out ASCII character codes. String.fromCharCode(34) How it worked. The Samy Worm
  83. As you can imagine, MySpace was also not found of

    things like innerHTML. But, apparently not eval? alert(eval('document.body.inne' + 'rHTML')); From here, he had access to the full source of the page and the ability to make AJAX requests with the users cookie. You can see the full source here: https://samy.pl/myspace/tech.html How it worked. The Samy Worm
  84. Case Study That time that someone used a stored XSS

    vulnerability in Twitter to create a worm that exploited the onmouseover event on links. When users hovered over these links, the worm retweeted itself. (Another) Twitter Worm (2009)
  85. Let’s say you tweeted something totally normal like, “http:// frontendmasters.com

    is the best!” You’d end up with something like this. <a href="https://frontendmasters" class="tweet-url web" rel="nofollow"> https://frontendmasters </a> is the best! How it worked. The Twitter Worm
  86. Ironically, using the @ character broke Twitter’s HTML parser. http://lol.no/@";onmouseover=";$

    ('textarea:first').val(this.innerHTML);$('.status- update-form').submit();"class="modal-overlay"/ Now, if you hovered over that link, you’d end up posting the same content. Whoops. How it worked. The Twitter Worm
  87. Case Study A wildly simple example of how quickly an

    XSS vulnerability can spread. The TweetDeck Worm (2014)
  88. Case Study eBay had supported a redirectTo query parameter. The

    problem was that the pages you could redirect to didn’t necessarily validate the query parameters in the URL that the user was redirected to—allowing for XSS attacks. eBay (2015–2016)
  89. Case Study We can blame a flaw in Angular’s sandbox

    that allowed the attacker to execute code via a query parameter or we can blame the fact that McDonald’s had made the interesting choice to decrypt passwords client-side. McDonald’s (2017)
  90. Case Study There was a vulnerability in a JavaScript library

    called Feedify, which was used on the British Airway website. The attack affected almost 500,000 customers of British Airways, of which almost 250,000 had their names, addresses, credit card numbers and CVV cards stolen British Airways (2018)
  91. Case Study Fortnite had a legacy page with serious vulnerabilities

    that went unnoticed. The vulnerability allowed an attacker to get access to the data of all Fortnite users. It’s unclear if the vulnerability was ever exploited. Fortnite (2019)
  92. Case Study Yes. The CIA. The Central Intelligence Agency (2011)

    Source: https:// thehackernews.com/2011/06/ xss-attack-on-cia-central- itelligence.html
  93. Case Study Tracked as CVE-2024-4835. This exploit took advantage of

    a flaw in their VS Code plugin that allowed an attacker to craft a malicious page to “exfiltrate sensitive user information.” GitLab (2024)
  94. Injection of a Malicious Script: An attacker injects malicious JavaScript

    (or other scripting languages) into a web application. This usually happens via user input (e.g. the comments section). Execution of Client-Side Code: The malicious script runs in the context of the victim user's session, with the permissions of that user's browser. Data Theft and Manipulation: Since the script executes as if it were part of the original website, it can steal cookies, session tokens, or other sensitive information. How it works. Cross-Site Scripting
  95. Input Validation: Validate and sanitize all user inputs. Output Encoding:

    Escape user-generated content before rendering it in the browser using context-appropriate escaping (HTML, JavaScript, URL, etc.). Content Security Policy (CSP): Implement CSP headers to restrict sources from where scripts, styles, and other resources can be loaded. Use Safe Methods: Avoid using functions that allow raw HTML input like innerHTML or document.write. Libraries and Frameworks: Utilize established libraries and frameworks that auto- escape content and provide built-in protection mechanisms. Best practices for mitigation. Cross-Site Scripting
  96. A place where you can out data without the risk

    of it being vulnerable to XSS. For our purposes, these are places where the browser promises not to execute any code you give it. Safe Sink
  97. element.textContent = randomUserInput is a safe sink. The browser will

    not execute this code. As compared to unsafe sinks. Safe Sinks element.innerHTML = randomUserInput is not a safe sink. The will—sometimes— execute this code.
  98. A security feature that helps prevent a range of attacks,

    including Cross-Site Scripting (XSS) and data injection attacks. CSP works by allowing web developers to control the resources the browser is allowed to load for their site. Content Security Policy
  99. Allowlist Domains: Specify which domains are permitted to load resources

    such as scripts, styles, or images. Directive-Based: Use various directives to control what content is allowed (e.g., script-src, style-src). Report Violations: Optionally, configure CSP to report violations to a specified URI. How it works. Content Security Policy
  100. Content-Security-Policy: script-src 'self' https:// trusted.cdn.com Alternatively, you can use a

    meta tag in the head of your HTML document. <meta http-equiv="Content-Security-Policy" content="script-src 'self' https://trusted.cdn.com"> An example header. Content Security Policy
  101. Yes, you should totally sanitize all user inputs and defensively

    code as best you possibly can. But, having a strong Content Security Policy gives you one extra layer of protection. Purpose: Prevent XSS and data injection attacks. Implementation: Define and apply CSP policies via HTTP headers or <meta> tags. Allowlist: Restrict resource loading to trusted sources. Enforcement: CSP policies can block or report unauthorized scripts. In summary. Content Security Policy
  102. So, what if you can’t use a CSP because it

    will “break stuff.” The Content-Security-Policy-Report-Only will allow you to log CSP violations, while still allowing them to happen. This will allow to collect data and prioritize which pages need some love. Dealing with legacy applications. Content Security Policy
  103. We disallow inline styles and scripts using unsafe-inline. We disallow

    eval and its friends using unsafe-eval. We only allow loaded resources from specific, highly-trusted resources. We implement strict nonce or hash-based techniques to control script and style execution. Really battening down the hatches. Strict CSP
  104. A cute way of saying a “number used once.” It’s

    a token that we intend for one-time use. Nonce
  105. block-all-mixed-content; default-src ‘none'; script-src ‘nonce-rAnd0m’ ‘strict-dynamic'; base-uri ‘self'; Content-Security-Policy: Scripts

    are only allowed if they match the nonce in the HTTP response header, and scripts dynamically added by these scripts are trusted.
  106. block-all-mixed-content; default-src ‘none'; script-src ‘nonce-rAnd0m’ ‘strict-dynamic'; base-uri ‘self'; Content-Security-Policy: Restricts

    the base element, which can prevent injected scripts from changing the locations that resources are loaded from.
  107. It’s a small value, which means your headers will be

    smaller and you’ll need to send fewer bytes over the wire. You won’t need to update anything if the content of your script files change. The pros and cons. Using a Nonce for CSP You’ll need to generate your pages programmatically. This is obviously easier if you’re using server-generated pages. Since the initial page has the nonce, you cannot cache the HTML.
  108. You don’t have to have any special infrastructure outside of

    generating a hash. The ups and the downs. Using a Hash for CSP Depending on how many files you have, this can get big. If you or anyone else changes the file, then it won’t load since the hash is no longer valid. That someone else could be your CDN or anyone in the middle trying to be helpful.
  109. A malicious technique where an attacker tricks a user into

    clicking on something different from what the user perceives, effectively hijacking clicks meant for a legitimate webpage. Clickjacking
  110. Embedding a Webpage: The attacker embeds the target webpage within

    an iframe on their malicious site. Opacity & Positioning: The iframe is made invisible (e.g. the opacity is set to 0) or positioned behind other content. Deceptive UI: The attacker places deceptive buttons or links on top of the invisible iframe elements. User Interaction: The user believes they are interacting with the visible elements but are actually interacting with the concealed iframe. How it works. Clickjacking
  111. The Target: A banking site where a user logs in

    and clicks a button to transfer funds. The Bad Actor: An attacker’s site with an invisible iframe containing the embedded banking site. The Trap: A visible button on the attacker's site saying “Click to Win a Prize!” The Attack: Our friendly user clicks the button, which actually triggers the transfer funds button in the invisible iframe. An example. Clickjacking
  112. DENY: Prevents the site from being displayed in iframe elements

    altogether. SAMEORIGIN: Allows the site to be framed only by pages on the same origin. <meta http-equiv="X-Frame-Options" content=“DENY”> <meta http-equiv="X-Frame-Options" content=“SAMEORIGIN"> app.use((req, res, next) = { res.setHeader('X-Frame-Options', 'DENY'); next(); }); Antidote: Use the X-Frame-Options Header. Clickjacking
  113. Specify which origins are allowed to embed the content. <meta

    http-equiv="Content-Security-Policy" content="frame- ancestors 'self' https://trustedorigin.com”> app.use((req, res, next) = { res.setHeader( 'Content-Security-Policy', "frame-ancestors 'self' https://trustedorigin.com" ); next(); }); Antidote: Use a Content Security Policy. Clickjacking
  114. postMessage is a method that allows for secure cross-origin communication

    between Window objects. It enables data exchange between a page and an iframe irrespective of their origins. postMessage
  115. A security issue arising when postMessage is misused or improperly

    validated. This can lead to data leakage, script injection, or cross-site scripting. postMessage Vulnerability
  116. The Sender uses window.postMessage(message, targetOrigin). The Receiver listens for messages

    with window.addEventListener(“me ssage”, someCallback, false). How it works and what can go wrong. postMessage Vulnerabilities Two Failure Modes: Accepting messages from any origin (e.g. targetOrigin = ‘*’) or trusting the payload (e.g. using the data without any sort of validation).
  117. window.addEventListener('message', (event) = { if (event.origin ! 'https://place-that-i-trust.com') { return;

    // Do not process messages from untrusted origins. } const data = sanitize(event.data); // Do something with the data… });
  118. A data encryption vulnerability occurs when sensitive data is either

    not encrypted or is inadequately encrypted, leading to potential data exposure. Data Encryption
  119. Not encrypting: Sensitive information (like passwords, credit card numbers) is

    stored without encryption. Encrypting, but poorly: Using outdated or broken encryption algorithms that can be easily decrypted. Encrypting, but leaving the keys under the doormat: Poor handling of encryption keys, such as hardcoding keys in the code. Encrypting, but too little and too late: Failing to encrypt data transmitted between the server and the client. Why aren’t you using HTTPS? Common pitfalls. Data Encryption
  120. Encrypt stuff that needs encrypting: Always encrypt sensitive information using

    strong encryption algorithms (e.g., AES-256). Encrypt it from end to end: Use Transport Layer Security (TLS) to encrypt data sent over the network. TL;DR—use HTTPS. Hide your keys: Store encryption keys securely, not in the source code or environment variables. Don’t roll your own crypto: Leverage well-maintained cryptographic libraries and frameworks. An ounce of prevention. Data Encryption
  121. JSON Web Token (JWT) is a compact, URL-safe means of

    representing claims to be transferred between two parties. For some reason, JWT is pronounced “jot.” JSON Web Tokens
  122. Header: Contains metadata such as the type of token and

    the algorithm used for signing (HS256, RS256, etc.). Payload: Contains the actual claims or data. Signature: Ensures that the token hasn’t been tampered with. The anatomy of a JWT. JSON Web Tokens
  123. Claims are name-value pairs. They carry information about a subject,

    like a user or device, securely. For instance, a claim could include a user's name or role. You can use various data as claims, tailoring security and functionality for your application. Claims
  124. Registered Claims: These are suggested, not mandatory, claims. They offer

    basic information. For example, "iss" reveals the JWT issuer. Public Claims: Users can define these. Yet, to avoid conflicts, they should be registered with IANA or use unique URIs. Private Claims: These are custom claims for specific uses, like sharing a user's permissions. Types of claims. Claims
  125. A JWT includes user data directly in the token. This

    data lists user ID, roles, permissions, and more. Importantly, it makes the server "stateless." Each request includes all the details needed to authenticate and authorize the user. Storage of User Data JWTs Versus Session IDs A session ID is a long, random string. It links to user data stored on the server. This data is often in memory or a database. When a request arrives, the server uses the session ID to find user information. This method, however, makes the server "stateful."
  126. JWTs are more scalable. They don't require server-side session storage.

    This makes them perfect for distributed systems. In these setups, users work with many servers in a cloud. By skipping session storage, servers save resources. This also simplifies load balancing. Scalability JWTs Versus Session IDs Scaling is harder with Session IDs. Every server that could serve a user's request must access their session data. This often means using shared storage or replicating sessions. These methods can complicate load balancing and increase overhead.
  127. JWTs can be stolen if stored insecurely. They are saved

    in browsers, making them targets for XSS attacks. Once issued, their information is fixed until they expire. You can instantly revoke them by using a denylist. Security Considerations JWTs Versus Session IDs Generally, session IDs are more secure because the data is stored on the server. However, they are susceptible to session hijacking if the session ID is intercepted by an attacker. Using Secure + HttpOnly cookies can mitigate this risk.
  128. JWTs create a stateless setup. Each request carries its needed

    information, aligning with RESTful API principles. Statelessness and Statefulness JWTs Versus Session IDs Session IDs need the server to keep track of states. This can complicate matters, but it offers precise control over session data. They might be more bandwidth- efficient. Only a small ID is sent with each request.
  129. The JWT controls its own expiration. It's valid until it

    expires. However, checks are needed to revoke it. Expiration Management JWTs Versus Session IDs With session IDs, the server manages expiration. It can quickly end or cancel a session. This method lets the user manage sessions better.
  130. The Vulnerability: The vulnerability arises when JWT accepts weak or

    incorrect algorithms, notably none or switching from HS256 to RS256. An attacker can modify the token header to specify alg: 'none' and remove the signature, potentially bypassing the verification process. Misconfiguration in the JWT library can lead to improper validation, especially when algorithms mix symmetric and asymmetric keys. Algorithm confusion. JSON Web Tokens
  131. Easy Access: Tokens can be easily accessed from JavaScript running

    in the browser, making it straightforward to manage tokens in client-side applications. Persistence: Data stored in local storage persists even after the browser window is closed, facilitating persistent user sessions. Local Storage JWT Storage Vulnerable to XSS: If an attacker can execute JavaScript on the application, they can retrieve the JWTs stored in local storage. No HttpOnly: Local storage does not support HttpOnly cookies, which means all stored data is accessible through client-side scripts.
  132. Tab Speci fi c: Data is accessible only within the

    tab that created it, which provides some level of isolation. Ease of Use: Similar to local storage, session storage is easy to use and integrates well with client-side scripts. Session Storage JWT Storage Limited Lifetime: Data in session storage is cleared when the tab or window is closed, which could be inconvenient for users who expect longer session times. Just like local storage, they’re vulnerable to XSS.
  133. HttpOnly: Cookies can be configured as HttpOnly, making them inaccessible

    to JavaScript and thus protecting them from being stolen through XSS attacks. Secure: Can be configured to be transmitted only over secure channels (HTTPS). Domain and Path Scoping: Provides additional security settings, such as restricting the cookies to certain domains or paths. Cookies JWT Storage CSRF Vulnerability: Unless properly configured with attributes like SameSite, cookies can be susceptible to CSRF attacks. Size Limitations: Cookies are limited in size (around 4KB) and each HTTP request includes cookies, which could potentially increase the load times if not managed correctly.
  134. XSS Safety: Storing JWTs in JavaScript variables can keep them

    out of the reach of XSS attacks, as long as the script itself is not compromised. Fast Access: Tokens stored in memory can be accessed very quickly. In memory (a.k.a not storing them) JWT Storage Lifetime: The token exists only as long as the page session lasts. It will be lost on page reloads or when navigating to a new page, which might not be suitable for all —honestly, most—applications.
  135. Include HttpOnly and Secure: Store JWTs in cookies with these

    attributes. This limits JavaScript access and ensures HTTPS-only transmission. Add SameSite: Set the attribute to Strict or Lax to reduce CSRF risks. Lax allows some cross-site usage. Use HttpOnly cookies for JWTs. JWT Best Practices
  136. Limit JWT Lifespan: Set JWTs to expire in 15 minutes

    to an hour. This reduces risk if a token is stolen. Refresh Tokens: Keep sessions active with refresh tokens. Store them securely and use them to issue new access tokens. Use short-lived JWTs and refresh tokens JWT Best Practices
  137. Regular Updates: Update security systems, libraries, and frameworks to patch

    vulnerabilities. SSL/TLS: Serve your site over HTTPS to secure data in transit. CORS: Carefully set CORS to block unauthorized access. Do the stuff that we all know we’re supposed to do. JWT Best Practices
  138. Avoid Sensitive Info: Don't store sensitive data in JWTs. They

    are easily decoded. De fi ne Scope and Audience: Clearly limit token usage to reduce risks. Control your token usage. JWT Best Practices
  139. Log and Monitor Usage: Track token activities for security. Look

    out for unusual access patterns. Security Audits: Regularly review your JWT handling, storage, and security. Monitor and audit them. JWT Best Practices
  140. A header that allows you to enforce that all of

    your traffic goes through HTTPS. Strict-Transport-Security
  141. “Be aware that inclusion in the preload list cannot really

    be undone. You can request to be removed, but it will take months for the deleted entry to reach users with a Chrome update and we cannot make guarantees about other browser vendors. Don't request inclusion unless you're sure that you can support HTTPS for the long term.” —Words of wisdom Chrome’s HSTS preload site.