Krizové velká písmena, o které se nemluví

Vytváříte webovou aplikaci. Na vývojovém stroji jede vše jako po másle. Staging server se nenechá zahanbit. Pak přijde produkce a najednou selhání bez logiky. Nebo security experti najdou díry, na které jste ani nepomysleli.

Často nejde o chybu v kódu nebo špatnou validaci. Vinníkem je něco nenápadnějšího: různé části systému zpracovávají velikost písmen jinak.

Proč je velikost písmen důležitější, než si myslíte

Většina vývojářů ví, že domain jsou case-insensitive. example.com, Example.Com nebo EXAMPLE.COM – to je stejná adresa. Jasné?

Ale co třeba:

• E-maily v autentizaci?
• User ID v databázi?
• Cesty k souborům v cloudu?
• API endpointy od externích služeb?
• Validace SSL certifikátů?

Když různé systémy konvertují stringy na jednotný case jinak, otevíráte dveře útokům.

Skutečný útok krok za krokem

Představte si: Aplikace ověřuje uživatele podle e-mailu. V databázi ukládáte vše v malých písmeních. Logické. Ale OAuth provider pošle John.Doe@Gmail.com s velkými. Vaše autentizace porovnává stringy bez normalizace.

Útočník se zaregistruje na john.doe@gmail.com, přihlásí se a pak zkusí John.Doe@Gmail.com. Při nesouladu v case-handlingu může:

• Obcházet rate limiting (různí uživatelé)
• Vytvářet duplicitní účty s vyššími právy
• Vyhnout se audit logům
• Dostat se k datům, která nemá

Je to ještě horší s:

Internationalizovanými domainy (IDN) – Unicode pravidla pro case se liší podle jazyka. Turecké 'i' bez tečky rozbije běžné ASCII předpoklady. Některé znaky nemají velké verze.

Cloud storage – AWS S3 je case-sensitive u object keys, ale ne u bucketů. Špatná kombinace vede k úniku dat nebo eskalaci práv.

DNS záznamy – DNS dotazy ignorují case, ale vaše validace možná ne. Wildcard certifikáty a CNAME jsou riziko.

Jak ochránit svou infrastrukturu

1. Nastavte standardy normalizace

Rozhodněte o case-handlingu hned na vstupu aplikace, ne v databázi. Normalizujte všechny vstupy okamžitě.

# Správně: Normalizace na hranici
def uprav_email(email):
    return email.lower().strip()

def prihlas_user(email):
    normalizovany = uprav_email(email)
    user = User.query.filter_by(email=normalizovany).first()
    return user

2. Používejte knihovny pro Unicode

Pro mezinárodní obsah si nevymýšlejte vlastní logiku. Vybírejte specializované nástroje:

• Python: unicodedata
• JavaScript: String.localeCompare()
• Go: strings s Unicode podporou

3. Testujte napříč systémy

Aplikace nestojí sama. Ověřte chování case u:

• DNS providera
• SSL certifikátů
• OAuth služeb
• Cloud storage
• CDN pravidel

Zapište si, jak co funguje, a zajistěte shodu.

4. Validujte vstupy přísně

Nedůvěřujte externím systémům. Normalizujte na každém integration pointu.

// Před voláním API
const uprav_pro_api = (vstup, format = 'lowercase') => {
  const vysledek = format === 'lowercase' 
    ? String(vstup).toLowerCase() 
    : String(vstup);
  return vysledek.trim();
};

5. Logujte podezřelé case změny

Nastavte alerty na variace:

def zjisti_case_rozdil(email):
    normalizovany = email.lower()
    if email != normalizovany:
        logger.warning(f"Detekována variace case: {email} vs {normalizovany}")
        # Zkontrolujte útoky

6. NameOcean best practices pro domény a DNS

Při registraci domain nebo nastavování DNS u NameOcean dodržujte:

• V kódu vždy malá písmena pro domain
• DNS záznamy s jednotným case
• Naše API case-insensitive funkce bez obav
• Zdokumentujte strategii v IaC

Hlavní ponaučení

Bezpečnost není jen o heslech a HTTPS. Jde o to chápat celý ekosystém. Malý rozdíl v case může prorazit autentizaci, úložiště i API.

Ti nejlepší vývojáři:

1. Nepředpokládají nic – Testujte normalizaci všude
2. Zkoušejte okraje – Case variace do security testů
3. Dokumentujte – Popište chování systémů
4. Jednotný standard – Vyberte a prosazujte ho

Vaši budoucí testeri (nebo útočníci) to ocení.