Den skjulte faren med store og små bokstaver

Du utvikler en webapp. Alt flyter i dev-miljøet. Staging er perfekt. Men i produksjon kræsjer det mystisk. Eller sikkerhetsforskere finner hull du aldri så komme.

Ofte ligger skylda ikke i koden eller validering. Det er store og små bokstaver som spøker.

Hvorfor dette ødelegger mer enn du tror

Alle vet at domain-navn ignorerer store bokstaver. example.com, Example.com eller EXAMPLE.COM – samme ting.

Men tenk på:

• E-postadresser i login-systemet ditt?
• Bruker-ID-er i databasen?
• Filstier i cloud storage?
• API-endepunkter fra eksterne tjenester?
• SSL-sjekker?

Når deler av infrastrukturen behandler store/små forskjellig, åpner du for angrep.

Et ekte angrepsscenario

Si applikasjonen din lagrer e-poster i små bokstaver i hoveddatabasen. Smart. Men OAuth-leverandøren sender John.Smith@gmail.com med blandet tilfelle. Logikken din sammenligner strenger uten å jevne ut.

Angriper registrerer john.smith@gmail.com, logger inn, prøver så John.Smith@gmail.com. Med ujevn håndtering kan de:

• Slippe unna rate limiting (ny bruker)
• Lage duplikatkontoer med høyere rettigheter
• Unngå logger
• Nå data de ikke skal ha

Verre med:

IDN-er – Internasjonale domener. Unicode-regler varierer. Tyrkisk 'i' uten prikk ødelegger engelske antagelser. Noen tegn har ingen store versjon.

Cloud storage – AWS S3 er case-sensitive på objekt-nøkler, men ikke bucket-navn. Feil her lekker data eller gir privilegier.

DNS – Søknader er case-insensitive, men appens validering kanskje ikke. Wildcard-sertifikater og CNAME blir svake punkter.

Slik sikrer du infrastrukturen

1. Sett faste normaliseringsregler

Bestem regler på app-nivå, ikke database. Jevn ut input med en gang.

# Normaliser ved inngang
def jevn_ut_email(email):
    return email.lower().strip()

def logg_inn(email):
    normalisert = jevn_ut_email(email)
    bruker = Bruker.query.filter_by(email=normalisert).first()
    return bruker

2. Bruk Unicode-biblioteker

Med internasjonalt innhold: Ikke lag din egen logikk. Velg proffer:

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

3. Test på tvers av systemer

Appen din står ikke alene. Sjekk case-håndtering hos:

• DNS-leverandørens API
• SSL-utsteder
• OAuth-tjenester
• Cloud storage
• CDN-regler

Noter oppførsel. Sørg for enhet.

4. Valider input strengt

Stol ikke på eksterne systemer. Normaliser ved hver kobling.

// Før API-kall
const jevn_til_api = (input, stil = 'små') => {
  const normalisert = stil === 'små' 
    ? String(input).toLowerCase() 
    : String(input);
  return normalisert.trim();
};

5. Logg case-problemer

Varsle om mistenkelig variasjon:

def sjekk_case_variasjon(email):
    normalisert = email.lower()
    if email != normalisert:
        logger.warning(f"Case-endring: {email} -> {normalisert}")
        # Sjekk for angrep

6. Følg NameOcean sine beste praksiser

Ved domain-registrering eller DNS via NameOcean:

• Bruk alltid små bokstaver i kode
• Lagre DNS-poster med faste regler
• Stol på vår case-insensitive API
• Dokumenter case-strategi i infra-as-code

Lærdommen

Sikkerhet handler ikke bare om passord og HTTPS. Det er hele økosystemet. En liten case-uoverensstemmelse sprer seg til auth, storage og API-er.

De smarte utviklerne:

1. Utfordrer antagelser – Aldri anta normalisering
2. Tester kanter – Inkluder case-variasjoner i sikkerhetstester
3. Dokumenterer – Skriv ned nøyaktig oppførsel per system
4. Jevner ut overalt – Velg standard, bruk den strengt

Dine fremtidige sikkerhetseksperter (eller angripere) vil sette pris på det.