WEB Fundamentals
This post is a sequel of sorts to the previous post “How does the WEB work!!”
Imagine if you had to remember the IP address of every single of your favorite websites. An IP address is a number assigned to every server and computer connected to the internet. An IP address is of the format x.x.x.x and each x can go upto 255.
To ease your mind and save you from using your exceptional memory, DNS (Domain Name System) steps in. The DNS has a mega library of websites and their IP addresses. So if you go to your browser and enter ‘www.google.com’ you are basically making a DNS request. Once the IP address is provided to the browser, the browser is eligible for making an HTTP request.
There are 9 basic kinds of HTTP verbs — GET , POST , PUT , DELETE and some more but we won’t care much as of now.
Once the request is GET request is acknowledged by the server it responds with the webpage we requested.
Now you must be aware that HTTPS is more secure than HTTP but both of these schemes work essentially the same way, using TLS (Transport Layer Security) to communicate in a way that:
- Other parties being able to read the data.
- Other parties being able to modify the data.
By default, HTTP runs on port 80 and HTTPS runs on port 443.
Let’s take a look at some of the verbs →
Requests
A request has can be broken down to pieces of information that can help us in forensics and and analysis of packet captures.
verb / path to the resource on the server
GET /index.htmlThe next part is the header of the request which contains cookies and metadata.
Here’s an example for a GET request retrieving a simple JS file:
GET /main.js HTTP/1.1
Host: 192.168.170.129:8081
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36
Accept: */*
Referer: http://192.168.170.129:8081/
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8From the headers, you can tell what I performed the request from (Chrome version 80, from Windows 10).
Responses
The server should reply with a response. The response follows a similar structure to the request, but the first line describes the status rather than a verb and a path.
The status will normally be a code, you’re probably already familiar with 404: Not found.
A basic breakdown of the status codes is:
- 100–199: Information
- 200–299: Successes (200 OK is the “normal” response for a GET)
- 300–399: Redirects (the information you want is elsewhere)
- 400–499: Client errors (You did something wrong, like asking for something that doesn’t exist)
- 500–599: Server errors (The server tried, but something went wrong on their side)
Response headers can be very important. They can often tell you something about the web server sending them, or give you cookies that may prove useful later on.
The response will also have a body. For GET requests, this is normally web content or information such as JSON. For POST requests, it may be a status message or similar.
Here’s a response to the GET request shown above:
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 28
Content-Type: application/javascript; charset=utf-8
Last-Modified: Wed, 12 Feb 2020 12:51:44 GMT
Date: Thu, 27 Feb 2020 21:47:30 GMTconsole.log("Hello, World!")
Let’s talk a little about cookies in the header section of HTTP requests.
Cookies are stored locally somewhere in your browser’s directory. Cookies from Chrome will not be stored in Firefox. Cookies have 2 common functions — to manage a session and for advertising relevant content to you. I am not a fan of the second one. But why do we need cookies ??
Because HTTP and HTTPS are both stateless protocols we need a mechanism to track our sessions — Cookies…
The server is normally what sets cookies, and these come in the response headers (“Set-Cookie” looking similar to JavaScript objects ). Alternatively, these can be set from JavaScript inside your browser.
When you log in to a web application, normally you are given a Session Token. This allows the web server to identify your requests from someone else’s. Stealing someone else’s session token can often allow you to impersonate them.
Manipulating cookies
Using your browser’s developer tools, you can view and modify cookies. In Firefox, you can open the dev tools with F12. In the Storage tab, you can see cookies that the website has set. There’s also a “+” button to allow you to create your own cookies which will come in handy in a minute. You can modify all cookies that you can see in this panel, as well as adding more.
cURL command will perform GET requests on whatever URL you supply it
Using command line flags for cURL, we can do a lot more than just GET content. The -X flag allows us to specify the request type, eg -X POST. You can specify the data to POST with — data, which will default to plain text data
Now ending this post I will like you to imagine a CTF of sorts taken from one of the rooms on TRY HACK ME.
Tasks
There’s a web server running on http://10.10.145.69:8081. Connect to it and get the flags!
STEP 1 →GET request. Make a GET request to the web server with path /ctf/get
STEP 2 →POST request. Make a POST request with the body “flag_please” to /ctf/post
STEP 3 →Get a cookie. Make a GET request to /ctf/getcookie and check the cookie the server gives you
Execution of this command will give you a message in the terminal to check our cookies. To check your cookies you can navigate throught dev tools or you could view the cookie data sleek…by running the following command
curl -c - http://10.10.203.217:8081/ctf/getcookie
STEP 4 →Set a cookie. Set a cookie with name “flagpls” and value “flagpls” in your devtools (or with curl!) and make a GET request to /ctf/sendcookie
curl -v -- cookie ‘flagpls=flagpls’ http://10.10.203.217:8081/ctf/sendcookie
