Trickuri: Testing URL Spoofing Vulnerabilities with Chromium's Proxy-Based Attack Simulator

Hook

A legitimate banking website URL in your browser's address bar could actually be serving content from an attacker's server—and most developers have never properly tested whether their URL display logic would catch this.

Context

URL spoofing remains one of the web's most persistent security challenges. Despite decades of awareness, phishing attacks continue to succeed by exploiting subtle vulnerabilities in how browsers and applications parse, validate, and display URLs. A URL might look like 'https://yourbank.com' to a user, but actually navigate to 'https://yourbank.com.evil.com' or leverage Unicode homoglyphs, IDN tricks, or path manipulation to disguise malicious intent.

Chromium's security team maintains strict guidelines for URL display to prevent these attacks, but validating compliance requires testing edge cases that are difficult to reproduce in normal browsing environments. You can't simply visit 'https://malicious-test.com' because you'd need to own that domain and configure complex server-side scenarios. Trickuri solves this by acting as a man-in-the-middle proxy that intercepts any URL request and serves local HTML testcase files, letting security testers validate how their applications handle suspicious URLs without requiring domain ownership or complex infrastructure.

Technical Insight

Trickuri's architecture centers on a Go-based HTTP/HTTPS proxy server that performs dynamic request-response mapping. When your browser requests any URL through the proxy, Trickuri intercepts the request and serves a pre-crafted HTML file from your local filesystem instead of fetching the actual remote content. This design enables comprehensive testing of URL display vulnerabilities across arbitrary domains.

The core mechanism works through Go's httputil.ReverseProxy with a custom Director function that rewrites all requests to point to local testcase files. For HTTPS interception, Trickuri generates a self-signed root certificate that must be installed in your OS trust store. Here's the conceptual flow:

// Simplified illustration of Trickuri's interception approach
func (p *Proxy) Director(req *http.Request) {
    // Extract requested URL from browser
    originalHost := req.Host
    originalPath := req.URL.Path
    
    // Map to local testcase file
    testcaseFile := p.getTestcaseForURL(originalHost, originalPath)
    
    // Rewrite request to serve local content
    req.URL.Scheme = "file"
    req.URL.Host = ""
    req.URL.Path = testcaseFile
    
    // Browser sees response as if from originalHost
    // but content comes from local testcase
}

The proxy maintains a mapping between URL patterns and testcase files. For example, you might configure it to serve 'testcases/unicode-domain.html' whenever a request matches certain Unicode character patterns in the hostname. The testcase HTML files themselves contain the scenarios you want to test—perhaps a legitimate-looking login form under a spoofed domain, or navigation attempts using various URL encoding tricks.

What makes Trickuri particularly effective is its PAC (Proxy Auto-Configuration) support. Rather than routing all traffic through the proxy, you can deploy a PAC file that selectively bypasses it for specific domains:

function FindProxyForURL(url, host) {
    // Bypass for critical browser services
    if (shExpMatch(host, "*.google.com") ||
        shExpMatch(host, "safebrowsing.googleapis.com")) {
        return "DIRECT";
    }
    
    // Route test URLs through Trickuri
    if (shExpMatch(host, "*bank*.com") ||
        shExpMatch(host, "*login*.com")) {
        return "PROXY localhost:8080";
    }
    
    return "DIRECT";
}

This selective routing is crucial because browsers make numerous background requests for updates, safe browsing checks, and extension syncing. Intercepting these requests can break browser functionality or trigger security warnings. The PAC approach lets you isolate only the URLs you're actively testing.

The HTTPS interception is where Trickuri's security testing power becomes apparent. By generating and installing a root CA certificate, the proxy can decrypt HTTPS traffic, serve your testcase content, and re-encrypt it with a valid certificate for the requested domain (as far as your browser is concerned). This lets you test whether your application correctly validates certificate information against displayed URLs, or whether it might be vulnerable to attacks where the visual URL doesn't match the certificate subject.

A typical testing workflow involves creating HTML testcases that exercise specific URL parsing edge cases, then manually inspecting how your application displays these URLs in various contexts—address bars, link previews, security indicators, and permission prompts. Trickuri handles the infrastructure complexity of serving these testcases as if they came from arbitrary domains, letting security testers focus on validation rather than environment setup.

Gotcha

The most significant limitation is that Trickuri requires OS-level certificate trust installation, which immediately disqualifies it for testing applications that implement certificate pinning. If your app pins certificates for specific domains (as many banking and security-focused applications do), the proxy's dynamically-generated certificates will be rejected regardless of OS trust settings. You'll need alternative testing approaches for pinned environments.

Trickuri is also fundamentally a manual testing tool with no automation framework. There's no built-in mechanism to programmatically validate that URL displays meet security criteria—you need human eyes to inspect results. This makes it effective for security audits and QA validation but unsuitable for CI/CD pipelines or regression testing. Each test requires manually navigating to URLs, visually confirming behavior, and documenting findings. For teams needing automated security testing, you'd need to build that framework on top of Trickuri or use a different approach entirely.

Finally, the tool's scope is strictly limited to HTTP/HTTPS protocols. If you're testing URL display in contexts using custom schemes (app deep links, intent:// URLs, file:// handlers), Trickuri won't help. It also won't intercept traffic from applications that bypass system proxy settings or use their own network stacks, limiting its usefulness for testing native mobile apps or electron applications with custom networking code.

Verdict

Use Trickuri if you're conducting security audits or QA validation of URL display logic in web browsers or web-based applications, especially when implementing Chromium's URL display guidelines. It's ideal when you need to manually test how your application handles edge cases like IDN homoglyphs, unusual Unicode domains, or path-based spoofing attempts without the overhead of registering test domains or configuring complex server infrastructure. Skip it if you need automated testing capabilities, are testing applications with certificate pinning, or need to validate URL handling in non-HTTP contexts like deep links or custom protocols. This is a specialized manual testing tool for security professionals, not a general-purpose testing framework.