Validering

att kontrollera indata mot reglerna innan man litar på dem

Vad det är

Validering är det steg där ett program ställer inkommande data mot de regler som de är tänkta att följa och avvisar dem som inte håller måttet, innan något lagras, körs eller skickas vidare. Steget har olika namn beroende på lager: indatavalidering för formulärfält och API-anrop, schemavalidering när reglerna är nedskrivna som ett JSON Schema eller en OpenAPI-beskrivning, och validering av uppmärkning när en webbsida kontrolleras mot grammatiken i HTML. Indata som klarar kontrollen kallas giltig.

OWASP delar upp arbetet i två frågor. Syntaxen gäller om ett värde har förväntad typ och form: är det här ett datum, är det ett heltal, går anropets body att tolka som JSON. Semantiken gäller om värdet är rimligt för den operation det ska användas i, så en hotellbokning behöver två giltiga datum och dessutom ett slutdatum som ligger efter startdatumet. Att omvandla strängen ”500” till ett heltal avgör den första frågan och säger ingenting om huruvida 500 nätter är en godtagbar vistelse.

Validering av uppmärkning är den äldsta offentliga formen av idén på webben. W3C:s Markup Validation Service beskriver validering som att kontrollera ett dokument mot den grammatik som det uppger sig använda, och jämför sin validator med lint för C. Dokumentationen är noga med vad det bevisar: en giltig sida är inte nödvändigtvis en bra sida, bara en som ett verktyg har funnit förenlig med en viss uppsättning regler. Samma försiktighet gäller alla andra sorter. Validering säger att data passar de regler du skrev, men inte att reglerna var de rätta.

Två närliggande begrepp blandas ofta ihop med den. Sanering ändrar indata för att göra dem godtagbara, genom att skala bort eller skriva om delar av dem, medan validering godtar eller avvisar dem som de är. Kodning och parametrisering gör data säkra för den plats dit de ska, en HTML-sida eller en databasfråga i SQL, och de behövs fortfarande efter att valideringen har gått igenom.

Varför det spelar roll

Beslutet bakom validering är var ett system drar sin förtroendegräns och vad det kontrollerar där. Varje anrop från en webbläsare, varje meddelande från en kö, varje fil från en partner och varje ändring i konfigurationen från en kollega kommer med antaganden i bagaget. Att kontrollera dem vid kanten innebär att resten av koden kan lita på dem. Att hoppa över kontrollen innebär att varje funktion längre in måste försvara sig själv, och i praktiken gör de flesta inte det.

Det andra beslutet gäller hur reglerna skrivs. Kontroller som skrivs för hand, slutpunkt för slutpunkt, är billiga i början och glider isär när systemet växer, eftersom var och en är sin egen lilla kodsnutt. Regler som deklareras en gång, som typer eller som ett schema, kan upprätthållas av ett bibliotek och publiceras som dokumentation från samma källa, så att beskrivningen och beteendet inte kan säga emot varandra. Priset är ett ramverk att lära sig och standardvärden att förstå, eftersom ett schema upprätthåller exakt det som står i det och ingenting av det som det lämnar osagt.

Striktheten är det sista valet. En tillåtelselista beskriver vad som är godtagbart och avvisar allt annat, vilket OWASP rekommenderar framför att försöka känna igen varje skadlig sträng. Att avvisa fält som ett schema inte känner till fångar stavfel och gamla klienter tidigt. Att avvisa hela anropet vid det första problemet, med ett tydligt felmeddelande, är säkrare än att fortsätta med data som bara delvis har kontrollerats.

Så ser det ut i praktiken

Företagets API började med validering av anrop som skrevs för hand för varje slutpunkt, och flytten till Huma v2 gjorde kontrollerna till typer över 649 sökvägar och 760 operationer. Varje slutpunkt har nu structar för indata och utdata, Huma genererar valideringen av anropen utifrån dem, och en OpenAPI-beskrivning kommer på köpet ur samma typer. Två slutpunkter för WebSocket ligger kvar på ren Fiber, där modellen med anrop och svar inte passar. En kontroll i CI jämför de rutter som servern registrerar med dem som beskrivningen utlovar, överensstämmelsen är 100 %, och den klass av buggar där någon glömde kontrollera ett fält försvann tillsammans med den handskrivna koden.

Konfiguration behöver samma behandling, och SSH-härdningen på företagets värd kör nu validering i tre steg vid varje konvergenskörning. Kandidatfilen syntaxkontrolleras innan den installeras, den sammansatta konfigurationen kontrolleras efter installationen, och sedan läses daemonens egna gällande inställningar tillbaka och 24 direktiv kontrolleras mot dem. Det tredje steget finns därför att en åtkomstrapport i september 2026 hittade två inställningar som automatiseringen hade skrivit vid varje konvergenskörning och som daemonen hade åsidosatt. Operativsystemets egna standardvärden lästes först, och för just de två inställningarna vinner den första förekomsten. Som sidan uttrycker det bevisar en sökning efter ett direktiv med grep bara att det skrevs.

Validering av uppmärkning ingår också i rutinen: HTML-validering är en av kontrollerna i en kvalitetsgrind med 22 lintverktyg som körs vid varje commit och saknar varningsnivå. Varje diagnostik är ett fel och undertryckningar direkt i koden är förbjudna, så en ogiltig sida kan inte committas genom att felet markeras som godtagbart.

Var det går fel

Servern litar på det som webbläsaren redan har kontrollerat. Ett formulär som vägrar ta emot en felaktig e-postadress i webbläsaren ser validerat ut, men anropet kan skickas helt utan formuläret. OWASP räknar kontroller enbart på klientsidan som en vanlig fallgrop: validera på servern, och behandla kontrollen i webbläsaren som en snabb ledtråd till den som skriver.

Ett schema godtar allt som det inte nämner. I JSON Schema gör en listad egenskap varken fältet obligatoriskt eller andra fält förbjudna, och under standardvokabulären i 2020-12 samlas nyckelordet format in som en annotering, med kontrollen av formatet avslagen som standard. Det här schemat ser strikt ut:

{
    "type": "object",
    "properties": {
        "email": { "type": "string", "format": "email" }
    }
}

Det godtar {}, {"email": "nope"} och {"emial": "a@example.com"}. Lägg till required och "additionalProperties": false, och slå på att formatet faktiskt ska hävdas (format assertion) i validatorn, eller kontrollera formatet i koden. Huma avvisar för sin del okända fält i en body som standard, dokumenterar readOnly och writeOnly utan att upprätthålla dem och ignorerar okända query-parametrar om inget annat anges.

Kontrollen godkänner en version av data och programmet använder en annan. En validator som läser det råa anropet medan hanteraren läser en avkodad kopia, eller ett test som granskar filen på disken medan daemonen tillämpar en annan inställning, har kontrollerat något som systemet aldrig använder. OWASP råder dig att validera den representation som faktiskt kommer att användas. SSH-arbetet ovan är samma lärdom i konfigurationens form: bara daemonens återläsning visade vad som faktiskt gällde.

En spärrlista möter nästa variant. Att blockera kända farliga tecken avvisar legitim indata, t.ex. en apostrof i ett efternamn, och lämnar ändå databasfrågan osäker. Bestäm vad varje fält godtar och avvisa resten.

Giltig indata behandlas som säker indata. En sträng som klarade varje regel kan ändå bryta sönder en SQL-sats eller en sida när den klistras in i den. Validering begränsar vad som kommer in. Parametriserade databasfrågor och kodning av utdata skyddar platsen där det hamnar, och båda behövs.

Läs mer

Ordlista