Introduction:
Client-side vulnerabilities such as the XSS usually come to mind when we talk about web vulnerabilities. However, server-side vulnerabilities are much hazardous since they target the logical and behavioral core of an application. We shall examine in this blog three prevalent and effectual server-side vulnerabilities such as Host Header Injection, Business Logic Flaws and Web Cache Deception. Bypassing Authentication, Changing Admin Credentials, as well as Stealing Sensitive Data using the models of attack is shown with the help of PortSwigger labs, where the attackers need not do more to cause havoc than simply tamper with the requests. Relax it is not only theory. We are going to see you the real practical example, not in complicated way but in a straightforward way.
1. Host header Injection
Introduction
Host header is a client request-level HTTP header which is employed to set up the name of the domain of the server (website) to which the client intends to join. It is important in virtual hosting, redirection, creation of links, and restriction of access. The vulnerability may be present when the server-side application blindly trusts and uses the Host header value that was sent in an incoming request without properly validating and sanitizing it.
This can be exploited in several ways and some of them are:
- Bypassing authentication / access controls
- Poisoning password reset or verification links
Generic Methodology to hunt for Host Header Injection Attack
Step 1: Recon
Start by exploring the application for any of the following:
- Password reset or email verification.
- Restricted or high privilege areas in web app (like
/admin, /internal)
- URL redirection or page rendering features
- APIs or responses that generate URLs
Look at requests using a tool such as Burp Suite or the DevTools contained within your browser and record any endpoints where the Host header appears in the response or logic.
Step 2: Test for Injection
Use Burp Repeater, or curl, or Postman to send requests to require a changed Host: header:
Host: evil.com
Also try:
Host: localhostHost: 127.0.0.1X-Forwarded-Host: attacker.comHost: 0.0.0.0 Host: server.internal localhost:80, 127.0.0.1:443.
Look out to see the following change in reaction on the part of the server:
- Authentication behavior
- Redirect URLs
- Reset email links
- HTML content with reflected Host values
Step 3: Exploitation
Depending on the app behavior you may leverage the problem by:
- Bypassing access control (e.g., using
Host: localhost to access /admin)
- Phishing via password reset emails (Host header controls the link)
- Redirecting users to attacker-controlled domains
Practice Lab
| Field | Details |
|---|
| Lab Name<br> | Host header authentication bypass |
| Lab URL | Visit Lab |
| Credentials | wiener:peter |
First let’s try and access /admin and we get the following message thrown and we are not able to access the /admin panel.
Let’s take a look at burpsuite and figure out what is happening under the hood. We see that we get 401 http status code, and we do observe and host header at the request.
Let’s try and change the host header to something like localhost and the logic behind this is to bypass authentication by tricking the application to believe that the request is coming from localhost.
We do bypass the authentication successfully and we get 200 status code, so now to delete the account let’s navigate the delete button and get GET request to the delete button to delete carlos user.
With this we should have solved our lab successfully.
2. Business Logic Vulnerabilities
Introduction
Business Logic Vulnerabilities (BLVs) are the vulnerabilities when the application does not impose the desired workflow or trust boundaries appropriately, and an attacker can misuse the features not in the way intended by its developers. Such defects are not cause by defective coded decisions but by defective thought processes-the design of a process-the business rules on how a process is supposed to operate. The difference between traditional security problems and BLVs is that the latter requires an intuition on the part of a hacker: he or she must learn to know how the application works and then invert it. It might be skipping a verification procedure, using coupon codes wrongly, or altering parameters such as role or email, but the attacker exploits the assumed behaviour of the app by making it do something that it expects not to do.
Generic Methodology to hunt for Business Logic Vulnerabilities
Recon: The first stage of the reconnaissance round is to get familiar with the principle workflows of the application password resets, email changes, checkout, referrals, account upgrade or subscription cancellation. Acquire an insight on the way the users normally engage these features. Be attentive to form steps, parameters, and conditions such as whether a confirm or a verify action has to be made.
Intuition & Uniqueness: All applications are unique- there are no similar apps. The reason is that logic bugs tend to lurk in the blinds of the developer. Take your gut feelings and challenge the concept of safe. Do not think like a normal user but like a malicious one. So, what would happen when you omit one step? What happens in case you do this in reverse?
Tamper & Test Everything: Change all parameters of any input, query string, header, and request body. Attempt to change fields such as current password, switch accounts or change usernames, post a negative number in quantity or price, or skip whole steps by sending right to last endpoints. Monitor the functional output of the app after every change.
Exploit: In case you can reset passwords without verification, apply an offer several times, exchange one role with another, perform payment without following steps, remember to what specific conditions and effects it led. Chain with IDOR, CSRF or race conditions, in order to increase severity.
Do make a note that this is a creative, trial-and-error process where experience and curiosity matter more than automated tools.
Practice Lab
| Field | Details |
|---|
| Lab Name<br> | Weak isolation on dual-use endpoint |
| Lab URL | Visit Lab |
| Credentials | wiener:peter |
As soon as we log in, we do see two features to the web app, one to reset password and another to update email. What if we could abuse the reset password feature? sounds cool right?
Let’s fire up burpsuite and see under the hood how things run, we do see POST request made to the server.
The body of the request has a http-parameter called current-password and if we want to test it for some other user let’s say like administrator we might need to remove them.
csrf=56henY7rlRomfNKHSoaQxInkbOe52lKS&username=wiener¤t-password=peter&new-password-1=test123&new-password-2=test123
So let’s quickly remove the current-password area and send the request, we get 200 which means it worked and we were able to reset the password. Do make a note that if you get 302 then it means something wrong happened.
Let’s render the response and we do see that we were able to reset the password of administrator
Now the body of the request which was responsible for changing the password of admin account should look something like this.
csrf=56henY7rlRomfNKHSoaQxInkbOe52lKS&username=wiener&new-password-1=test123&new-password-2=test123
With this we should have solved the lab.
3. Web Cache Deception
Introduction
Web Cache Deception (WCD) is a vulnerability in which an attacker can force Web based caching systems (such as CDNs or reverse proxies) into feeding sensitive, user-specific content to publicly accessible URLs. This happens when dynamic content, e.g. user dashboards, an api-key, etc. is delivered over URLs that look like they should be cacheable, which would permit anyone in the future to view the content delivered earlier in the cached form without authorization.
Generic Methodology to hunt for Web Cache Deception
Identify Sensitive Endpoints : Look for authenticated pages that expose personal data, such as:
/my-account/dashboard/api/key
Craft Cacheable URLs : To these endpoints, append in fake static-looking extensions:
/my-account → /my-account/fake.css
/dashboard → /dashboard/image.jpg
Deliver to Victim : Share the crafted link with a logged-in user (e.g., via CSRF, email, or redirect). When they open it, their private data may get cached under that path.
Check as Attacker : Visit the same crafted URL in an un logged session (i.e. incognito). The site is unsafe in case they continue serving their information.
Refine and Confirm : Try several extensions (.css, .js, .jpg) and verify response headers that contain Cache-Control: public or no restriction of caching.
Practice Lab
| Field | Details |
|---|
| Lab Name<br> | Exploiting path mapping for web cache deception |
| Lab URL | Visit Lab |
| Credentials | wiener:peter |
To exploit this vulnerability one should find endpoint vulnerable to web cache. As you can see when we try to access an non-existent endpoint we get 404 error.
Let’s dig a bit deeper and we do see /my-account endpoint. Which gives our API key (upon successful login), so let’s test this out.
Now we try to access something that does not exists within this directory, and since web cache is enabled, we don’t get any error and we are able to render the website seamlessly.
Since we found an endpoint that might be vulnerable to this attack, use this payload in your exploit-server and make sure to replace the URL with your lab link.
<script>document.location="https://0ae800dd0331b0ca802e03e600ed008b.web-security-academy.net/my-account/doesnotexist.js"</script>
Now paste this into body of your exploit server and deliver it to the victim.
Let’s try and access the doesnotexist.js file, and we do see that our malicious js file gets executed and we do get API key of carlos user.
Let’s submit the answer, and we should have solved the lab.
Conclusion:
Attacks at the server side are not only technical but are logical too. They tend to take advantage of the bad assumptions of the backend request processing. As we have already observed such little tricks such as altering the Host header, or deactivating parameters, can have severe consequences, including a profile takeover and information exfiltration. One should imagine that he is the attacker and examine all endpoints and never assume that the backend has to be safe. Both a novice pentester and an experienced pentester will understand the importance of the need to learn the server-side logic inside out thanks to these labs. Remember to practice and keep doubting flow, remember to stay sharp.
