Når angribere går efter formularer, udfylder de dem ikke på normal vis. I stedet sender de kode, der skal bryde ind i dine systemer eller stjæle data. De kan indsende JavaScript, som kører i besøgendes browsere, SQL-kommandoer, der ødelægger din database, eller skadeligt indhold. Inputvalidering og sanering er forsvaret, der stopper de angreb.
Det lærer du: Hvad inputvalidering og sanering er, hvordan de adskiller sig, hvordan injektionsangreb virker, hvilken beskyttelse der passer til hver datatype, og hvordan du bruger det på dine formularer.
Hvad er inputvalidering?
Inputvalidering er en kontrol af, at de data, der sendes til din formular, har det format, du forventer, og lever op til dine krav. Det er den første forsvarslinje mod skadeligt input.
Validering svarer på spørgsmål som: Er det en e-mailadresse eller tilfældig tekst? Er det et tal eller et ord? Er feltet tomt, selvom det ikke burde være det? Har den besøgende skrevet noget, der giver mening i feltet, eller noget mistænkeligt?
Eksempler på, hvad validering kontrollerer:
- Et e-mailfelt skal indeholde et @ og et domæne
- Et telefonnummerfelt må kun indeholde cifre og bindestreger
- Et talfelt må ikke indeholde bogstaver
- Et obligatorisk felt må ikke være tomt
- Et adgangskodefelt skal opfylde et krav til mindstelængde
Validering sker to steder. På den besøgendes enhed hedder det validering i browseren (client-side). På din server hedder det validering på serveren (server-side). Validering i browseren giver den besøgende hurtig feedback, hvis han eller hun laver en fejl. Validering på serveren er det, der faktisk beskytter mod angreb, fordi angribere kan springe kontrollerne i browseren over.
Hvad er inputsanering?
Sanering betyder, at du fjerner eller uskadeliggør alt farligt i brugerens input, før du gemmer eller bruger det. Selv data, der består valideringen, kan indeholde kode eller tegn, der er lavet til at gøre skade.
Eksempler på, hvad sanering gør:
- Fjerner HTML-tags som `<script>` og `<img>` fra tekstfelter
- Fjerner SQL-specialtegn, der kan bruges til at bryde ind i databaser
- Escaper specialtegn, så de behandles som tekst og ikke som kode
- Begrænser inputtets længde for at forhindre buffer overflow-angreb
Validering og sanering arbejder sammen, men har hvert sit formål. Validering kontrollerer, at dataene har det rigtige format. Sanering fjerner alt farligt, selv når formatet teknisk set er i orden.
Sådan virker injektionsangreb
SQL-injektion
Et SQL-injektionsangreb sker, når en angriber skriver SQL-kode i et formularfelt. Hvis din formularkode ikke saner inputtet, bliver SQL-koden kørt på din database.
Eksempel: En loginformular beder om en e-mailadresse. I stedet for sin e-mail indsender en angriber:
' OR '1'='1Hvis din formular ikke saner det, kan din kode køre en SQL-forespørgsel, der ser sådan ud:
SELECT * FROM users WHERE email = '' OR '1'='1'Delen `OR '1'='1'` gør betingelsen altid sand, så forespørgslen returnerer alle brugere i stedet for kun den ene med den e-mail. Nu har angriberen omgået loginsystemet.
Cross-Site Scripting (XSS)
Et XSS-angreb sker, når en angriber indsender JavaScript-kode i et formularfelt. Hvis formularen ikke saner koden og gemmer den, kører JavaScript'en i browseren hos alle, der senere ser de data.
Eksempel: En kommentarformular tager imod brugerkommentarer. En angriber indsender:
<script>alert('hacked')</script>Hvis det ikke saneres og gemmes i databasen, kører JavaScript'en og viser en advarsel, når nogen åbner kommentarsektionen. En farligere version kan stjæle cookies, sende besøgende til en phishing-side eller trække formulardata ud.
Kommandoinjektion
Hvis dine formulardata bruges i systemkommandoer (det sker i nogle backend-systemer), kan en angriber indsætte kommandoer til operativsystemet.
Eksempel: Et formularfelt bruges i en kommando som:
ffmpeg -i $filename output.mp4Hvis `$filename` ikke saneres, og en angriber indsender `;rm -rf /`, bliver kommandoen:
ffmpeg -i ;rm -rf / output.mp4Kommandoen `rm -rf /` kører og sletter filer på systemet. Derfor må systemkommandoer aldrig få usaneret brugerinput.
Validering og sanering for forskellige datatyper
E-mailadresser
Validering: Kontroller, at inputtet passer til et e-mailmønster (noget i retning af tekst@domæne.endelse). Bekræft, at det kun har tilladte tegn.
Sanering: Fjern HTML-tags og specialtegn. Behold kun bogstaver, cifre, punktummer, bindestreger og @.
Telefonnumre
Validering: Kontroller, at det kun indeholder cifre, bindestreger, parenteser og mellemrum. Tjek, at længden passer til det forventede land.
Sanering: Fjern alle ikke-numeriske tegn undtagen bindestreger og parenteser. Fjern indledende nuller eller mellemrum, hvis det er nødvendigt.
Tekstfelter (kommentarer, navne, adresser)
Validering: Kontroller, at feltet ikke er tomt, og at længden er rimelig (ikke millioner af tegn).
Sanering: Fjern eller escap HTML-tags, JavaScript og SQL-specialtegn. Behold kun almindelig tekst og almindelige tegnsætningstegn.
Tal og beløb
Validering: Kontroller, at inputtet er et tal. For priser eller antal skal du kontrollere, at det er et positivt tal.
Sanering: Fjern alle ikke-numeriske tegn. Afrund om nødvendigt til det rigtige antal decimaler.
Adgangskoder
Validering: Kontroller mindstelængden (mindst 8 tegn), og kræv eventuelt en blanding af store og små bogstaver, tal og symboler.
Sanering: Fjern eller ændr ikke i adgangskoder. De skal gemmes præcis, som de er (hashede, aldrig som almindelig tekst). Hvis du fjerner tegn fra en adgangskode, kan brugerne ikke logge ind.
Filuploads
Validering: Kontroller, at filtypen er den, du forventer (fx kun PDF-filer eller kun billeder). Tjek, at filen ikke er for stor.
Sanering: Omdøb filen, så angribere ikke kan bruge særlige filnavne. Scan filen for malware. Gem den uden for webroden, så den ikke kan køres som kode.
Sådan indfører du validering og sanering
I browseren (client-side)
Brug HTML5's valideringsattributter, så besøgende får hurtig feedback:
<input type="email" name="email" required> <input type="tel" name="phone" pattern="[0-9]{10}"> <input type="number" name="age" min="0" max="120">Det fanger de åbenlyse fejl og gør oplevelsen bedre. Men validering i browseren kan omgås, så den er ikke sikkerhed i sig selv.
På serveren (server-side)
Det er her, sikkerheden sker. Din backend-kode skal validere og sanere hver eneste dataværdi:
// Pseudo-code example if (email does not match email pattern) { reject the submission } // Remove HTML tags sanitized_comment = remove_html_tags(comment_text) // Escape special characters for database safe_name = escape_sql_characters(user_name) // Only then store the data store_in_database(safe_name, sanitized_comment)Brug parametriserede forespørgsler til databaser
Det bedste forsvar mod SQL-injektion er parametriserede forespørgsler (også kaldet prepared statements). I stedet for at sætte brugerens input direkte ind i en SQL-forespørgsel bruger du pladsholdere og sender dataene separat:
// Bad (vulnerable): query = "SELECT * FROM users WHERE email = '" + email + "'" // Good (safe): query = "SELECT * FROM users WHERE email = ?" execute(query, [email])Med parametriserede forespørgsler ved SQL-parseren, at brugerens input er data og ikke kode. Selv hvis en angriber indsender SQL-kode, behandles den som almindelig tekst.
Brug biblioteker og frameworks
Skriv ikke saneringskode fra bunden. Brug etablerede biblioteker, der er lavet til formålet. I PHP kan du bruge htmlspecialchars() eller et bibliotek som HTML Purifier. I Python kan du bruge modulet `html` eller et bibliotek som bleach. I Node.js kan du bruge `express-validator` eller noget lignende. Bibliotekerne er testet og opdateret til at håndtere nye angrebstyper.
Almindelige fejl ved validering og sanering
Du validerer kun i browseren. Validering i browseren er til brugeroplevelsen, ikke til sikkerheden. En angriber kan omgå den. Du skal også validere på serveren.
Du blokerer farlige tegn i stedet for kun at tillade sikre. Hvis du forsøger at stoppe SQL-injektion ved at fjerne semikoloner og citationstegn, finder angribere en vej uden om. Tillad i stedet kun de tegn, du forventer (til telefonnumre fx kun cifre og bindestreger), og afvis alt andet.
Du stoler på formularfeltets datatype. Hvis du har et talfelt, sender browseren tekst, der ligner et tal. Din server skal stadig kontrollere, at det faktisk er et tal, før du bruger det. Gå aldrig ud fra, at datatypen er rigtig.
Du glemmer at sanere data, der vises. Selv hvis data er gemt sikkert, kan angribere indsætte kode, der kører i besøgendes browsere, hvis du viser dem på en side uden at escape HTML.
Du saner i den forkerte rækkefølge. Valider først (har det det rigtige format?), og saner bagefter (er det sikkert?). Hvis du saner og derefter validerer, kan du komme til at afvise data, der faktisk var sikre.
Det gør WEMASY ved inputvalidering
WEMASY validerer formularfelter automatisk ud fra den felttype, du vælger. E-mailfelter kontrolleres for et gyldigt e-mailformat. Talfelter kontrolleres for numerisk input. Obligatoriske felter kontrolleres for indhold, før formularen sendes. På serversiden saner WEMASY alt input og fjerner HTML, JavaScript og anden farlig kode, før indsendelserne gemmes. Du vælger, hvilke felter du vil indsamle, og WEMASY klarer validering og sanering i baggrunden.
Se, hvilke formularfunktioner der er med i din plan, på prissiden.