Gode råd om sikkerhed.

Forms

Alle steder du accepterer data fra brugere af din hjemmeside, skaber du et potentielt sikkerhedshul. Hvis du for eksempel har en kontaktformular på din hjemmeside og bagefter skriver noget i retning af "Du bestilte: VARE" vil eventuel programmeringskode som brugeren har indtast i varefeltet blive eksekveret på serveren.

Du giver altså alle og enhver fuldstændig de samme muligheder som du selv har for at udføre programmeringskode på dit webhotel.

Løsningen er at sikre sig mod at brugeren kan indtaste programmeringskode. Det kan gøres på forskellige måder, det letteste er i ASP at bruge funktionen Server.HTMLEncode der omskriver alle "farlige" tegn til tegn din browser vil forstå men ikke længere eksekvere som kode (i PHP bruges htmlspecialchars).

En anden løsning kan være at bruge regular expressions til at teste for hvilke tegn der indtastes.

Som en ekstra sikkerhed kan du bruge kommandoen Replace(TEKSTSTRENG, "'", "''"). Den gør at hvis en bruger forsøger at udføre SQL kommandoer via din formular, vil en MS SQL server forstå tekststrengen som en note (embedded quote) og ikke som en kommando, så uanset om din primære sikkerhed bliver brudt, kan misbrugeren ikke gøre andet end at indføre tekst i din database.

Form disabled

Stol ikke på form: disabled. Hvis brugeren ikke må kunne rette i dataene må du heller ikke stole på dem, du må altså ikke hente data fra et disabled felt. Brugeren kan bare poste fra sin egen side fra en anden server eller bruge en browser der ikke forstår form: disabled.

Referrer

Som en ekstra sikkerhed kan du checke på hvilken side dataene blev sendt fra og ikke tillade data fra andre sider end localhost. HTTP_REFERRER er dog ikke et bevis på hvor brugeren kom fra, der kan uden de store problemer snydes med denne variabel. Det kan altså bruges til at besværliggøre tingene så de mest ukyndige ikke slipper igennem, men det er ikke sikkert.

Upload

Husk at når du giver en bruger mulighed for at uploade til dit webhotel, kan han uploade kode der giver ham de samme muligheder du som administrator har hvis han kan browse filen bagefter. Det anbefales derfor på det kraftigste at du kun giver mulighed for at uploade til /db folderen, da den ikke er synlig via internettet.

Skal du uploade til en folder der umiddelbart kan browses via internettet, er det derfor vigtigt at du checker på endelsen og f.eks. kun tillader filer der ender på .jpg eller .gif. En bedre løsning er at lade brugere uploade til /db folderen, og derefter bruge programmeringskode til at flytte filen hen et sted hvor den må ligge, samtidig med at du checker endelsen.

Huskelisten

En kort liste med eksempler på hvad man skal gøre for at sikre sig.

SQL injection

Husk at escape tegnet ' hver gang du sender noget til en SQL database, så en misbruger ikke kan indsætte sine egne kommandoer.
ASP/MSSQL: Call Replace(VARIABEL, "'", "''")
PHP/MySQL: $temp = str_replace("'", "\\'", $temp);
Mere info: Wiki, OWASP

Cross site scripting

Husk at HTML-encode alt du skriver ud på skærmen som kommer udefra eller fra databasen, så en bruger ikke kan indføre javascript eller HTML kommandoer.
ASP: Response.Write(Server.HTMLEncode(VARIABEL))
PHP: echo(htmlentities($variabel, ENT_QUOTES));
http://en.wikipedia.org/wiki/Cross_site_scripting Mere info: Wiki, OWASP

Input validering

Tjek alt input med en regular expression, så du ikke får farlige tegn ind i dine variable/database.
Regular til det meste: ^[\a-zA-Z0-9\ \,\.\-\%\_\*\?\@\xC0-\xFF\r\n]$
Mere info: Wiki, OWASP

Code injection

Injection angreb kan også ske via PHP/ASP etc
Mere info: Wiki

Læs eventuelt de mere uddybende ti bud fra OWASP.

FAQ

Hvad er hackere og crackere?

Det findes der flere opfattelser af. Den gængse opfattelse blandt eksperter er at hackere er de gode og crackere er de onde.

Begreberne ses dog ofte blandet sammen af journalister, de originale begreber hacker og cracker er uddybet i Azeros ordbog.

Wired har en god artikel der beskriver nogle af tidens mest kendte hackere.