Share
## https://sploitus.com/exploit?id=BB1437D6-05DA-5773-9314-1932CFD1910D
# OWASP Juice Shop Security Testing

A practical security assessment of OWASP Juice Shop demonstrating common web vulnerabilities:

- Stored XSS leading to session theft
- CSRF testing on password change functionality
- IDOR and XSS vulnerability chaining

## Target

OWASP Juice Shop (Local Instance)

```

[http://localhost:3000](http://localhost:3000)

````

---

# 1. Stored XSS โ†’ Session Theft

## Description

Stored Cross-Site Scripting (XSS) occurs when malicious JavaScript is stored by the application and executed when another user visits the affected page.

## Exploitation

A vulnerable input field was identified that allowed JavaScript execution.

Payload:

```html
alert(document.cookie)
````

After submitting the payload, the script was stored and executed when the affected page was loaded.

## Impact

An attacker could:

* Execute arbitrary JavaScript in another user's browser
* Perform actions using the victim's session
* Access sensitive browser information if protections are missing

## Mitigation

* Sanitize user input
* Escape output before rendering
* Implement Content Security Policy (CSP)
* Avoid rendering untrusted HTML

---

# 2. CSRF Testing โ€” Password Change

## Description

Cross-Site Request Forgery (CSRF) allows an attacker to force a victim's browser to send requests using their authenticated session.

## Investigation

The password change request was analyzed through browser developer tools.

Endpoint:

```
GET /rest/user/change-password
```

Parameters:

```
current
new
repeat
```

## Testing

The request was analyzed to determine whether a password change could be triggered only using the victim's authenticated session.

However, the endpoint requires the current password before accepting the change.

## Result

A cookie-only CSRF attack was not successful because the application requires an additional secret value:

```
current password
```

## Mitigation

* Implement CSRF tokens
* Use POST/PUT methods for sensitive actions
* Validate request origin
* Enable SameSite cookies

---

# 3. IDOR + XSS Chain

## Description

An Insecure Direct Object Reference (IDOR) occurs when an application allows users to access or modify objects belonging to other users by changing identifiers.

When combined with Stored XSS, an attacker can inject malicious scripts into resources they should not control.

## IDOR Discovery

A resource identifier was identified in an API request.

Example:

```
/api/resource/{id}
```

The identifier was modified to test authorization controls.

Example:

```
Original:
resource/1

Modified:
resource/2
```

The application response was analyzed to determine whether unauthorized access was possible.

## XSS Injection

After obtaining unauthorized access to the resource, a stored XSS payload was tested.

Payload:

```html
alert('XSS')
```

## Attack Chain

```
IDOR
 |
 | Unauthorized access/modification of another user's resource
 |
 v
Stored XSS injection
 |
 | Victim views affected resource
 |
 v
JavaScript execution
```

## Impact

The combined vulnerability can allow an attacker to:

* Modify another user's content
* Inject malicious scripts into trusted pages
* Execute JavaScript in another user's browser context

## Mitigation

### Prevent IDOR

* Implement server-side authorization checks
* Verify ownership of requested objects
* Do not rely on hidden identifiers

### Prevent XSS

* Encode user-controlled output
* Sanitize input
* Implement Content Security Policy

---

# Tools Used

* OWASP Juice Shop
* Firefox Developer Tools
* Burp Suite (for request analysis)
* Linux environment

---

# Disclaimer

This project was performed in a local OWASP Juice Shop environment for educational purposes only.

```

This is the README format: short, structured, and suitable for GitHub. You can add screenshots under each exploitation section.
```