"""
THEORY: How the Remote Challenge Actually Works

After researching --no-sandbox and CDP exploitation, here's the likely setup:

LOCAL (current):
- bot.py defines FLAG but never uses it
- FLAG is just sitting in Python's module scope
- Not accessible to JavaScript

REMOTE (likely):
- FLAG is set as an ENVIRONMENT VARIABLE in Docker
- Bot Python process has access to os.environ['FLAG']
- With --no-sandbox + CDP, you can access process.env from JavaScript

This explains:
1. Why FLAG is in bot.py but unused (hint at where to look)
2. Why --no-sandbox is critical (enables CDP access)
3. Why it's "solvable locally" (same exploit works, just fake flag)
4. Why Dockerfile matters (sets environment)
"""

import time
import os
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

BASE_URL = "http://127.0.0.1:5000"

# REMOTE VERSION: Flag comes from environment
FLAG = os.environ.get('FLAG', 'uoftctf{fake_flag}')


def visit_url(target_url):
    """
    The trick: FLAG is in the Python process environment,
    but with --no-sandbox, CDP can access process.env!

    Exploitation chain:
    1. XSS via DOM clobbering in app.js
    2. Execute arbitrary JavaScript in bot context
    3. Use CDP to access process.env.FLAG
    """
    options = Options()
    options.add_argument("--headless=true")
    options.add_argument("--disable-gpu")
    options.add_argument("--no-sandbox")  # <-- THIS is the hint!

    # These might also be present on remote:
    # options.add_argument("--remote-debugging-port=9222")  # Enables CDP over HTTP

    driver = webdriver.Chrome(options=options)
    try:
        driver.get(target_url)
        time.sleep(30)
    finally:
        driver.quit()


"""
DOCKERFILE ON REMOTE probably has:
ENV FLAG=uoftctf{actual_flag_here}

Then in bot.py:
FLAG = os.environ.get('FLAG')

With CDP access via --no-sandbox:
JavaScript can execute: process.env.FLAG
"""