Request Flows

• Request Line:

  • GET /bundles/users/login.js?v=nkvziAKmVvl5VErpHLkQaJjSSsY HTTP/2: This indicates a GET request for the resource located at "/bundles/users/login.js" with a query parameter "v" having the value "nkvziAKmVvl5VErpHLkQaJjSSsY," using the HTTP/2 protocol.
  • The ' v' value nkvziAKmVvl5VErpHLkQaJjSSsY may represent a specific version or some form of identification for cache-busting or versioning purposes. The server can use this information to determine which version of the file the client is requesting.

  
• Cache busting

  • Is a technique used in web development to force browsers to request a new version of a file, even if the file hasn't changed on the server. The primary purpose is to overcome browser caching mechanisms, ensuring that users receive the latest version of a file when changes are made.
• Cache busting

  • When a browser downloads a file (such as a JavaScript, CSS, or image file) from a server, it stores a copy of that file in its cache. Subsequent requests for the same resource may be served directly from the cache to improve page load times and reduce server load. However, this can pose a problem when developers update the file on the server – users may still see the old, cached version.

  
• Cache busting

  • Cache busting is often achieved by appending a unique query parameter to the URL of the resource. This query parameter doesn't affect the content of the file but makes each request appear as a new, unique request to the browser, forcing it to fetch the latest version from the server. Commonly, timestamps, version numbers, or random strings are used as values for the cache-busting query parameter.
  • Eg in the first line query param, v may serve as unique id to ensure the request gets the latest resource

  
• Requests:

  SessionId Cookie:

  • This cookie appears to be associated with a session, as indicated by the name "SessionId." The value is a long string, likely a unique identifier for the user's session.

  AWSALBAPP Cookies:

  • These cookies have the name format "AWSALBAPP-X" and the value "remove". The value "remove" suggests that these cookies are being marked for removal, possibly to delete or invalidate them.

  
• Requests:

  stg_ Cookies:

  • stg_traffic_source_priority=4;
  • stg_externalReferrer=https://www.google.com/;
  • stg_last_interaction=Sun%2C%2004%20Feb%202024%2009:11:58%20GMT;
  • stg_returning_visitor=Sun%2C%2004%20Feb%202024%2009:11:58%20GMT;
  • These cookies seem to be related to site analytics or tracking. They store information about traffic source priority, external referrer, the timestamp of the last interaction, and whether the user is a returning visitor.
• Requests:

  pk Cookies:

  • _pk_id.287552c2-4917-42e0-8982-ba994a2a73d7.1467=8d3105a377449f27.1707037918.1.1707037918.1707037918.;
  • _pk_ses.287552c2-4917-42e0-8982-ba994a2a73d7.1467=*
  • These cookies are likely associated with Matomo, a web analytics platform. They store information about the user's ID, session, and interactions. pk stands for piwik which Matomo was formerly called.
• Requests;

  • User-Agent: Describes the client making the request, indicating it's Firefox 122.0 running on Windows 10 (x64).
  • Accept: Indicates that the client can accept any media type.
  • Accept-Language: Specifies the preferred languages for the response.
  • Accept-Encoding: Informs the server about the preferred encoding methods for the response, including gzip, deflate, and br (Brotli).
  • Referer: Provides the URL of the page that led to this request, which is "https://portswigger.net/users."
  • Te: trailers: Indicates that the client can process trailers (additional fields in the message footer).
• Sec-Fetch-Dest:

  • Sec-Fetch-Dest: script
  • Indicates the intended destination of the fetch. In this case, it is set to "script," login.js, suggesting that the request is specifically made to fetch a script. This header provides information about the type of resource the client is trying to retrieve.

  
• Sec-Fetch-Mode:

  • Sec-Fetch-Mode: no-cors
  • Describes the CORS (Cross-Origin Resource Sharing) mode of the request. The value "no-cors" indicates that the request does not require CORS headers, and the browser will not perform a CORS preflight check. This is typically used for requests where the browser does not need to access the response data directly. In This case we were logging into the website

  
• Sec-Fetch-Site:

  • Sec-Fetch-Site: same-origin
  • Specifies the site from which the request originated. The value "same-origin" indicates that the request is coming from the same origin as the current page. This is a security measure to ensure that the request is limited to resources from the same site, helping to prevent certain types of cross-site request forgery attacks.

  
• Response:

  • HTTP/2 200 OK: Indicates that the request was successful, and the server is responding with a status code 200 (OK).
  • Date: Sun, 04 Feb 2024 09:11:59 GMT: The date and time when the response was generated.
  • Content-Type: text/javascript; charset=UTF-8: Specifies that the content type of the response is JavaScript, and it's encoded using UTF-8.
  • Server: Kestrel: Indicates the server software or platform used, in this case, Kestrel.

  
• Response:

  • Cache-Control: max-age=31536000,immutable: Instructs the client (e.g., a browser) on how to cache the response. The content can be cached for a maximum of 31,536,000 seconds (1 year), and it is marked as immutable, indicating that it won't change.
  • Etag: "nkvziAKmVvl5VErpHLkQaJjSSsY": An entity tag that uniquely identifies the version of the resource.
  • Last-Modified: Tue, 16 Jan 2024 09:25:36 GMT: Indicates the date and time when the resource was last modified.

  
• Strict-Transport-Security: max-age=31536000; preload: Enforces the use of secure, encrypted connections for a specified duration (1 year) and indicates that the site is eligible for preload in browsers.
• Response:

  • X-Content-Type-Options: nosniff: Advises the browser not to interpret files as a different MIME type.
  • X-Frame-Options: SAMEORIGIN: Prevents the resource from being embedded in frames from other sites.
  • X-Xss-Protection: 1; mode=block: Enables the browser's Cross-Site Scripting (XSS) protection.

  
• Response:

  • These Set-Cookie headers indicate the server is setting or modifying cookies. In this case, it's setting cookies with names AWSALBAPP-0, AWSALBAPP-1, AWSALBAPP-2, and AWSALBAPP-3 to the value "remove". These cookies are set to expire on February 11, 2024, at 09:11:59 GMT and are scoped to the root path (Path=/).

  
• The Alt-Svc

  • header in an HTTP response provides alternative services for the client to connect to, possibly using a different protocol or location. In your example:

  This header specifies alternative services for HTTP/3 (h3) on port 443. Let's break down the components:

  • h3=":443"; ma=2592000: Indicates that the alternative service supports HTTP/3 (h3) on port 443. The ma=2592000 specifies a maximum age (in seconds) for how long the client should consider this alternative service before checking for updates. In this case, it's set to 2,592,000 seconds, which is equivalent to 30 days.

  
• Alt-Svc

  • h3-29=":443"; ma=2592000: This indicates another alternative service, possibly specifying a different version of HTTP/3 (h3-29). The details are similar to the first alternative service, supporting HTTP/3 on port 443 with a maximum age of 30 days.

  
• Alt-Svc:

  • This header helps optimize connection establishment by providing the client with information about available alternative services, allowing it to make more efficient choices for subsequent connections. The client can use this information to connect to the alternative service if the original connection becomes unavailable or to improve performance by selecting a more suitable service based on the context.
• • firstRegisteredDeviceVisit=2024-02-04T08%3A34%3A44.007Z: The value of the cookie is a timestamp representing the date and time of the first registered visit by a device. The timestamp is URL-encoded, where %3A represents a colon. The actual timestamp, when decoded, is "2024-02-04T08:34:44.007Z."
  • Max-Age=31536000: This attribute indicates the maximum age of the cookie in seconds. In this case, the cookie is set to expire after 31,536,000 seconds, which is equivalent to one year.

  
• Set-Cookie:

  • Path=/: This attribute specifies the path for which the cookie is valid. In this case, the cookie is valid for the entire domain, as indicated by the root path ("/").
  • HttpOnly: This attribute is a security feature that ensures that the cookie is only accessible through HTTP(S) requests and cannot be accessed by client-side scripts. This helps protect against certain types of cross-site scripting (XSS) attacks.

  
• Set-Cookie:

  • Secure: This attribute indicates that the cookie should only be sent over secure, encrypted connections (HTTPS). It enhances the security of the cookie by ensuring it is transmitted securely.
  • SameSite=Strict: This attribute is a part of the SameSite cookie attribute, which controls when cookies are sent with cross-site requests. Setting it to "Strict" means that the cookie will only be sent in a first-party context and not in cross-site requests.

  
• X-Request-ID:

  • X-Request-Id: This is a custom header, often employed for logging and debugging purposes. It allows the server and other components involved in processing the request to associate log entries with a particular request. The value of the header, in this case, is a unique identifier for the request. Allows for searching of loggings and ensuring uniqueness
• Pragma:

  • The Pragma: no-cache header is a directive that indicates the sender of the HTTP response does not want the response to be cached by the client. This header is primarily used to control caching behavior in HTTP/1.0, but it's also recognized by some HTTP/1.1 clients for backward compatibility.
• Pragma:

  • While Pragma: no-cache is a valid way to control caching behavior, the more modern and widely supported approach for controlling caching is to use the Cache-Control header. The Cache-Control header provides more fine-grained control over caching mechanisms, and it is the preferred method in HTTP/1.1.
• Here's what the Pragma: no-cache header means:

  • Pragma Header: The Pragma header historically has been used for various directives in HTTP. In the context of caching, it's used to control caching behaviors.
  • no-cache Directive: The no-cache directive within the Pragma header specifically instructs the client not to use a cached version of the response for subsequent requests. When a client receives a response with Pragma: no-cache, it is expected to fetch a fresh copy of the resource from the server, even if it has a cached version.
• Content Security Policy:

  • A Content Security Policy (CSP) is a security standard implemented by web browsers to mitigate the risk of cross-site scripting (XSS) attacks.
  • The main purpose of CSP is to define and enforce a set of rules specifying which resources (such as scripts, stylesheets, images, etc.) are allowed to be loaded and executed on a web page. By doing so, CSP helps prevent the execution of malicious scripts injected into a web page.
• CSPs: Script Source Control:

  • CSP allows you to specify from which sources scripts can be executed. This includes inline scripts, external scripts, and scripts loaded from specific domains.
  • Content-Security-Policy: script-src 'self' https://trusted-scripts.com;

  Style Source Control:

  • Similar to scripts, CSP enables control over the sources from which styles (CSS) can be loaded and applied.
  • Content-Security-Policy: style-src 'self' https://trusted-styles.com;
• CSPs:

  Image, Font, and Media Source Control:

  • CSP allows you to specify the domains from which images, fonts, and media files can be loaded.
  • Eg. Content-Security-Policy: img-src 'self' https://trusted-images.com; font-src 'self' https://trusted-fonts.com; media-src 'self' https://trusted-media.com

  Connect Source Control (XHR and Fetch):

  • Control over the domains from which the page can make network requests using XMLHttpRequest (XHR) or the Fetch API.
  • Content-Security-Policy: connect-src 'self' https://api.example.com;
• CSPs:

  Frame and Object Source Control:

  • Specify the domains from which the page can embed frames and load objects.
  • eg. Content-Security-Policy: frame-src 'self' https://trusted-frames.com; object-src 'none';

  Plugin Control:

  • Define the sources from which plugins (e.g., Flash) can be loaded.
  • Content-Security-Policy: plugin-types application/pdf;
• CSPs:

  Strict-Dynamic:

  • Allow the execution of inline scripts only if they are associated with an event handler triggered by user action (e.g., a button click). This helps mitigate the risk of inline script execution
  • Content-Security-Policy: script-src 'self' 'strict-dynamic';

  Report-Only Mode:

  • CSP supports a "report-only" mode where the policy is not enforced, but violation reports are sent to a specified endpoint for analysis. This helps website developers test and fine-tune their CSP rules.
  • Content-Security-Policy-Report-Only: script-src 'self'; report-uri /endpoint-for-csp-reports;
• Inline Script Execution

  • Inline script execution refers to the execution of JavaScript code that is directly embedded within the HTML document rather than being loaded from an external file. In other words, inline scripts are included within the HTML markup using the <script> element with the code placed directly between the opening <script> tag and the closing </script> tag.

  
• Inline Script Execution

  • Inline scripts have been a common practice in web development for a long time. However, they come with security risks, particularly related to cross-site scripting (XSS) attacks. If an attacker is able to inject malicious code into the inline script, it can be executed in the context of the web page, potentially leading to security vulnerabilities.
• Inline Script Execution

  • To mitigate XSS risks, security best practices recommend avoiding or minimizing the use of inline scripts. Instead, web developers are encouraged to use external scripts and implement Content Security Policies (CSP) to control and restrict the sources from which scripts can be executed. CSP allows developers to specify which script sources are allowed, reducing the risk of unauthorized or malicious inline script execution.
• 1. Cross-Origin-Opener-Policy: same-origin

  • This header sets the Cross-Origin Opener Policy (COOP) to "same-origin," meaning that the document is only allowed to be opened by pages from the same origin.

  1. Cross-Origin-Embedder-Policy: require-corp

  • This header sets the Cross-Origin Embedder Policy (COEP) to "require-corp," indicating that the resource must be embedded in a cross-origin document with a cross-origin mode.

  
• 1. Cross-Origin-Resource-Policy: same-site

  • This header sets the Cross-Origin Resource Policy (CORP) to "same-site," meaning that the resource should only be requested by the same-site origin.

  1. Accept-Ch: Sec-CH-UA-Arch, Sec-CH-UA-Bitness, ...

  • This header is used to communicate Client Hints to the server. It includes various client hint names, such as Sec-CH-UA-Arch, Sec-CH-UA-Bitness, etc., which provide information about the user agent (browser) and its environment. These hints allow the server to optimize content delivery based on the client's capabilities.

  
• Permissions-Policy: ch-ua-arch=*, ch-ua-bitness=*, ...

  • This header sets the Permissions Policy for the page. It includes various client hint names (ch-ua-arch, ch-ua-bitness, etc.) with a wildcard (*) as the value. This allows the browser to communicate information about the user agent to the server, and the server can use this information to tailor the content accordingly.

  
• HTTP request smuggling is a technique for interfering with the way a website processes sequences of HTTP requests that are received from one or more users. Request smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users.
• Cloudfront Response:

  • Via: 1.1 f376d87611123aa47c006262522a6a94.cloudfront.net (CloudFront): This header indicates that the request passed through a proxy or intermediary, in this case, CloudFront. It provides information about the version of the HTTP protocol and the domain name of the proxy server.
  • X-Amz-Cf-Pop: SIN2-P2: This header specifies the CloudFront Point of Presence (POP) that served the request. In this case, it is "SIN2-P2."
• Cloudfront Response:

  • Alt-Svc: h3=":443"; ma=86400: The Alt-Svc (Alternative Services) header provides information about alternative services available. In this case, it mentions HTTP/3 (h3) on port 443. The "ma=86400" indicates that the alternative service information is valid for 86,400 seconds (24 hours).
  • X-Amz-Cf-Id: Ewt_ei2_vlsWZZfm0L7_m-A2bTsOeUsS109qhaV9plUBT8K8VptKOQ==: This header contains a unique identifier associated with the CloudFront distribution or request. It is often used for troubleshooting or tracking purposes.