IdeaWell

Project ideas from Hacker News discussions.

When str.lower() is a security vulnerability in Python – Seth Larson

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1 – Implementation differences create exploitable parser differentials

"A straightforward way to exploit an implementation differential like this is if you have a software system that contains two different implementations of IDNA 2003 processing user input. One part of the process processes the domain correctly, the other incorrectly, and in this case you can have one part of a system (such as a policy/filter) 'see' the data one way and the other part of the system (such as, taking an action as a result of the data) see the data in another way." – SethMLarson

Theme 2 – The issue is situational but becomes dangerous when the right conditions exist

"It creates a parser differential; two different components of the system can treat the same string as different hostnames. Things that have trusted hostnames, or privileged/admin hostnames that are screened out, or SSRF filters all depend on accurately comparing presented hostnames. This is pretty situational, though, isn't it? You still have to be dealing with IDN names." – tptacek

Theme 3 – Correctness bugs should be treated as security issues until proven otherwise

"We have a working exploit (OOB access in the V8 heap)... In general, we find that correctness issues like this are pretty much always exploitable with a bit of effort (not even that much effort normally, just gluing together a few gadgets), so we treat correctness issues as security issues until they are proven not to be, rather than the other way around." – wren6991

🚀 Project Ideas

Generating project ideas…

IDNA Safety Linter

Summary

  • Static analysis tool that flags unsafe .lower(), .upper(), or case‑folding calls on user‑supplied hostname strings that could lead to IDNA parsing differentials and SSRF exploits.
  • Core value: prevents implementation‑spec mismatches by ensuring developers use proper IDNA normalization (e.g., idna.encode/idna.decode) before any security checks.

Details

Key Value
Target Audience Backend developers, security engineers, DevOps teams handling user‑provided domains
Core Feature AST‑based detection of case‑changing functions on domain inputs, with suggested fixes and automatic IDNA‑safe replacement
Tech Stack Python (AST/tokenize), Rust (optional for speed), integrates via pre‑commit or CI plugins
Difficulty Medium
Monetization Revenue-ready: SaaS subscription tiered by scan volume (free tier for open source)

Notes

  • HN commenters noted the risk: “If you have a software system that contains two different implementations of IDNA 2003 processing user input… you can have one part… see the data one way and the other part… see the data in another way” (SethMLarson).
  • Provides immediate utility in CI pipelines to catch subtle bugs before they become exploitable, sparking discussion on secure IDNA handling across languages.

Homograph Detection API

Summary

  • RESTful service that analyzes a hostname for Unicode homograph/confusability risks (e.g., Cyrillic “а” vs Latin “a”) and returns a safety score plus suggestions for blocked or sanitized names.
  • Core value: gives product teams a programmable way to stop SSRF and phishing attacks that rely on IDN spoofing before they reach internal services.

Details

Key Value
Target Audience Platform operators, SaaS providers, DNS admins, security product teams
Core Feature Real‑time homograph checking using Unicode TR‑39 data, with configurable allow/block lists and batch processing
Tech Stack Go microservice, RocksDB for trichard lookup, Docker/Kubernetes deployment, OpenAPI spec
Difficulty Medium
Monetization Revenue-ready: Pay‑per‑API‑call with free quota for low‑volume usage

Notes

  • Commenters highlighted the exploit path: “Enterprising malicious actor registers mangled-popular-unicode-domain-plus-garbage.com, and now gets a hold of user password reset requests” (floxy). This API directly blocks such registrations.
  • Enables proactive defense and can be integrated into signup flows, inviting discussion on best practices for IDN acceptance policies.

Consistent IDNA Normalization Middleware

Summary

  • Pluggable middleware for popular web frameworks (Flask, Django, Express, Spring) that automatically normalizes every inbound hostname header/parameter via IDNA2008 (or a configurable version) before routing, authentication, or SSRF checks.
  • Core value: eliminates implementation differentials by guaranteeing a single, spec‑compliant representation of domain names across all system components.

Details

Key Value
Target Audience Web service developers, API gateway operators, microservice architects
Core Feature Intercept request, extract hostname fields, apply idna.encode/idna.decode (or idna.core), replace raw value, continue chain
Tech Stack Language‑specific packages: Python (idna + framework hooks), Node.js (node-idna + Express middleware), Java (icu4j + Spring Filter)
Difficulty Low
Monetization Hobby (open‑source library; optional paid support/consulting)

Notes

  • As rcxdude observed: “With web applications it's not particularly unusual… if one part of the system is doing authentication and the other part is actually doing the action then it can be a real problem when they interpret the input differently.” This middleware removes that discrepancy.
  • Low effort to adopt, high impact; likely to generate discussion on standardizing IDNA handling in framework documentation and security audits.

Read Later