Inventory Management
HTTP basics and cookie manipulation
Apart from using Burp Suite, attackers can use the inspect element features of browsers with Ctrl - I. Once open, by selecting the Application tab on the top and click the cookies button on the left hand side, it is shown a list of all our the cookies categorized per website. We can change the name and value of any cookie by double clicking it.Websites run on web servers. A web server is what is needed to essentially make the web site accessible on the wider internet. To communicate with a web server, the Hyper Text Transfer Protocol (HTTP) is used. HTTP usually works in the form of requests where the client (something like a browser) sends a request to complete a particular action to the website (technically the server). These acctions can range from logging in and retrieving pages to adding some data.
[1] The HTTP verb that tells the server what kind of action the client is requesting. The most common types are:
GET - used to retrieve resources (to pull a book off the shelf or open to a specific page of that book)
POST - used to change the state on the server, to write something down
Both these requests can be implemented incorrectly which can lead to vulnerabilities.
The second part refers to the path the action is directed to (the client is telling the server to get the login page).
The thir part refers to the protocol (version 1.1 of the HTTP protocol).
Lines [2]-[8] are known as HTTP Headers. Headers are used by both the client and the server to pass extra information to each respective entity. Headers are in the form Name:Value.
Here is some description of some of the request headers:
[2] Host - used to pass the domain name of the server. Useful in a situation where a server hosts multiple web sites so the server will know which page to pass back to the browser.
[3] User-Agent - specifies what browser made the request. Useful because different web pages render differently on web browsers so servers would know what exactly to serve depending on what browser requested it.
When the server receives the request, it responds to the action with an HTTP response. This is the response to the previous request:
[1] The first part contains the version of the HTTP protocol that the server uses, and the second part is the status/response code. Response codes are used by the server to indicate the status of a request, and are divided into the following classes:
1xx - Information Requests
2xx - Successful Requests
3xx - Redirects
4xx - Client Errors
5xx - Server Errors
[2]-[6] are response headers used to pass information to the client. [2] is prefaced with "X-", which is the format of a custom header (anytime we see something like that its worth finding out more).
After [6], depending on whether the request is successful, the server will pass in content of a page (usually). The most common requested files are:
HTML - syntax and language used to define the skeleton of a web page.
JavaScript - language used to perform actions related to HTML.
CSS - used to add styling to web pages.
Some important things to note about the HTTP protocol:
HTTP is stateless - the server has no way to keep track of the order of requests the client is sending.
HTTP is unencrypted and is usually used with TLS to form HTTPS, an encrypted form of HTTP which uses certificates to verify that the website really is what it claims to be.
HTTP commonly runs on port 80 while HTTPS on 443.
There are a lot more that goes into making a connection from a client to a server and HTTP is only part of that.
To keep track of what the client is doing, the server uses cookies.
Cookies are a key value pair in the form of name:value and can be used for various purposes. In this example cookies are used for session management, which refers to how the server keeps track of the actions performed by the client. Sessions are created with the following workflow:
User sends username and password to the server to authenticate themselves
Server checks if user details are correct and sets a cookie
Every time the user performs an action, the browser send the cookie as part of the request to the server, which then checks the cookie to ensure the user is authorized to perform a particular action.
It is important to consider that cookie values will be encoded from time to time. A browser and server may not be able to interpret particular characters so the value placed in a cookie is encoded when its sent and decoded under the hood.
An attacker would first try to identify how the cookies are used for session management. Using burp suite they would intercept every request mentioned in the flow above to examine how the server sets the cookie. Common hallmarks of insecure session management include:
Using a fixed cookie value: if the cookie value is always the same, the attacker can use this to gain access to a user's account. Cookie values should be randomly generated whenever a user authenticates, so that attackers cant use it to gain persistent access to user's tokens.
Using a predictable value as part of a cookie: if a server uses values such as username or numbers, an attacker could set his own cookie that a server would authenticate as a different user. Cookie values should be completely random.
1st step -> swap the username test1 with mcinventory and add the fixed cookie part of the value: mcinventoryv4er9ll1!ss
2nd step -> Encode it with base 64:
3rd step -> Add the base64 encoded value to the cookie value in the browser and refresh the page:
Answer:
Last updated
