9 sikkerhedstip til at beskytte dit websted mod hackere

Du tror måske ikke, at dit websted har noget, der er værd at blive hacket til, men websteder er kompromitteret hele tiden. Størstedelen af ​​websidesikkerhedsbrud er ikke at stjæle dine data eller rod med din webstedslayout , men i stedet forsøger at bruge din server som et e-mail-relæ til spam eller at oprette en midlertidig webserver, normalt til at betjene filer af ulovlig karakter. Andre meget almindelige måder at misbruge kompromitterede maskiner inkluderer brug af dine servere som en del af et botnet eller til minedrift for Bitcoins. Du kan endda blive ramt af ransomware.

Hacking udføres regelmæssigt af automatiserede scripts, der er skrevet for at gennemsøge Internettet i et forsøg på at udnytte kendte websidesikkerhedsproblemer i software. Her er vores top ni tip, der hjælper dig med at beskytte dig og dit websted online.

01. Hold software opdateret

Det kan synes åbenlyst, men det er vigtigt at sikre, at du holder al software opdateret for at holde dit websted sikkert. Dette gælder både serveroperativsystemet og enhver software, du muligvis kører på dit websted, såsom et CMS eller et forum. Når websidesikkerhedshuller findes i software, er hackere hurtige til at forsøge at misbruge dem.



Hvis du bruger en administreret hosting-løsning, behøver du ikke bekymre dig så meget om at anvende sikkerhedsopdateringer til operativsystemet, da hostingfirmaet skal tage sig af dette.

Hvis du bruger tredjepartssoftware på dit websted, såsom et CMS eller et forum, skal du sikre dig, at du er hurtig til at anvende eventuelle sikkerhedsrettelser. De fleste leverandører har en mailingliste eller RSS-feed, der beskriver ethvert websteds sikkerhedsproblemer. WordPress , Umbraco og mange andre CMS'er underretter dig om tilgængelige systemopdateringer, når du logger ind.

Mange udviklere bruger værktøjer som Composer, npm eller RubyGems til at styre deres softwareafhængighed, og sikkerhedssårbarheder, der vises i en pakke, du er afhængig af, men ikke er opmærksom på, er en af ​​de nemmeste måder at blive fanget ud. Sørg for at holde dine afhængigheder ajour og bruge værktøjer som f.eks Gemnasium for at få automatiske meddelelser, når en sårbarhed annonceres i en af ​​dine komponenter.

02. Pas på SQL-injektion

SQL-injektionsangreb er, når en hacker bruger et webformularfelt eller en URL-parameter til at få adgang til eller manipulere din database. Når du bruger standard Transact SQL, er det let at ubevidst indsætte slyngelskode i din forespørgsel, der kan bruges til at ændre tabeller, få oplysninger og slette data. Du kan let forhindre dette ved altid at bruge parametriserede forespørgsler, de fleste websprog har denne funktion, og det er let at implementere.

Overvej denne forespørgsel:

'SELECT * FROM table WHERE column = '' + parameter + '';'

Hvis en hacker ændrede URL-parameteren til at passere i 'eller' 1 '=' 1, får dette forespørgslen til at se sådan ud:

'SELECT * FROM table WHERE column = '' OR '1'='1';'

Da '1' er lig med '1', vil dette gøre det muligt for angriberen at tilføje en yderligere forespørgsel til slutningen af ​​SQL-sætningen, som også vil blive udført.

Du kan rette denne forespørgsel ved eksplicit at parametrere den. For eksempel, hvis du bruger MySQLi i PHP, skal dette blive:

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value'); $stmt->execute(array('value' => $parameter));

03. Beskyt mod XSS-angreb

Cross-site scripting (XSS) -angreb injicerer ondsindet JavaScript på dine sider, som derefter kører i dine brugers browsere og kan ændre sideindhold eller stjæle oplysninger for at sende tilbage til angriberen. For eksempel, hvis du viser kommentarer på en side uden validering, kan en angriber muligvis indsende kommentarer, der indeholder script-tags og JavaScript, som kan køre i enhver anden brugers browser og stjæle deres login-cookie, så angrebet kan tage kontrol over kontoen for hver bruger, der har set kommentaren. Du skal sikre, at brugerne ikke kan indsprøjte aktivt JavaScript-indhold på dine sider.

Dette er en særlig bekymring i moderne webapplikationer, hvor sider nu primært er bygget fra brugerindhold, og som i mange tilfælde genererer HTML, som derefter også fortolkes af front-end-rammer som Angular og Ember. Disse rammer giver mange XSS-beskyttelser, men blanding af server- og klientgengivelse skaber også nye og mere komplicerede angrebsmuligheder: Det er ikke kun effektivt at injicere JavaScript i HTML, men du kan også indsprøjte indhold, der kører kode ved at indsætte vinklede direktiver eller bruge Ember hjælpere.

Nøglen her er at fokusere på, hvordan dit brugergenererede indhold kan undslippe de grænser, du forventer og blive fortolket af browseren som noget andet, hvad du havde til hensigt. Dette svarer til at forsvare mod SQL-injektion. Når du genererer HTML dynamisk, skal du bruge funktioner, der eksplicit foretager de ændringer, du leder efter (f.eks. Brug element.setAttribute og element.textContent, som automatisk undslippes af browseren, snarere end at indstille element.innerHTML i hånden), eller brug funktioner i dit skabelonværktøj, der automatisk foretager passende undslip, snarere end sammenkædning af strenge eller indstilling af rå HTML-indhold.

Et andet stærkt værktøj i XSS-forsvarerens værktøjskasse er Content Security Policy (CSP). CSP er et header, som din server kan returnere, som fortæller browseren at begrænse, hvordan og hvad JavaScript udføres på siden, for eksempel for at afvise kørsel af scripts, der ikke er hostet på dit domæne, ikke tillade indbygget JavaScript eller deaktivere eval (). Mozilla har en fremragende guide med nogle eksempler på konfigurationer. Dette gør det sværere for en angribers scripts at arbejde, selvom de kan få dem ind på din side.

04. Pas på fejlmeddelelser

Vær forsigtig med, hvor meget information du giver væk i dine fejlmeddelelser. Giv kun dine brugere minimale fejl for at sikre, at de ikke lækker hemmeligheder på din server (f.eks. API-nøgler eller databaseadgangskoder). Giv heller ikke fulde undtagelsesoplysninger, da disse kan gøre komplekse angreb som SQL-injektion meget lettere. Gem detaljerede fejl i dine serverlogfiler, og vis kun brugerne de oplysninger, de har brug for.

05. Bekræft på begge sider

Validering skal altid udføres både på browser- og serversiden. Browseren kan opfange enkle fejl som obligatoriske felter, der er tomme, og når du indtaster tekst i et kun tal-felt. Disse kan dog omgåes, og du skal sørge for at kontrollere for disse validerings- og dybere valideringsserversider, da det ikke kan føre til, at ondsindet kode eller scriptkode indsættes i databasen eller kan medføre uønskede resultater på dit websted.

06. Tjek dine adgangskoder

Alle ved, at de skal bruge komplekse adgangskoder, men det betyder ikke, at de altid gør det. Det er afgørende at bruge stærke adgangskoder til dit server- og webstedsadministratorområde, men lige så vigtigt også at insistere på god adgangskodepraksis for dine brugere for at beskytte sikkerheden på deres konti.

Så meget som brugere muligvis ikke kan lide det, vil håndhævelse af adgangskodekrav såsom mindst omkring otte tegn, inklusive store bogstaver og tal, hjælpe med at beskytte deres information på lang sigt.

Adgangskoder skal altid gemmes som krypterede værdier, fortrinsvis ved hjælp af en envejs hashing-algoritme som SHA. Brug af denne metode betyder, at når du godkender brugere, sammenligner du kun nogensinde krypterede værdier. For ekstra websidesikkerhed er det en god ide at salte adgangskoderne ved hjælp af et nyt salt pr. Adgangskode.

I tilfælde af at nogen hacker ind og stjæler dine adgangskoder, kan brug af hashede adgangskoder hjælpe med at beskadige begrænsningen, da dekryptering af dem ikke er mulig. Det bedste nogen kan gøre er et ordbogangreb eller et brutalt kraftangreb, der i det væsentlige gætter på enhver kombination, indtil den finder en kamp. Når du bruger saltede adgangskoder, er processen med at knække et stort antal adgangskoder endnu langsommere, da hvert gæt skal hashes separat for hvert salt + kodeord, der er beregningsmæssigt meget dyrt.

Heldigvis leverer mange CMS'er brugeradministration ud af kassen med mange af disse hjemmesides sikkerhedsfunktioner indbygget, selvom der muligvis kræves nogle konfigurationer eller ekstra moduler for at bruge saltede adgangskoder (før Drupal 7) eller for at indstille den mindste adgangskodestyrke. Hvis du bruger .NET, er det værd at bruge medlemsudbydere, da de er meget konfigurerbare, giver indbygget websidesikkerhed og inkluderer færdige kontroller til login og nulstilling af adgangskode.

07. Undgå filoverførsler

At tillade brugere at uploade filer til dit websted kan være en stor sikkerhedsrisiko for hjemmesiden, selvom det bare er at ændre deres avatar. Risikoen er, at enhver fil, der uploades, uanset hvor uskyldig den ser ud, kan indeholde et script, der åbner dit websted fuldstændigt, når det udføres på din server.

Hvis du har en filoverførselsformular, skal du behandle alle filer med stor mistanke. Hvis du tillader brugere at uploade billeder, kan du ikke stole på filtypen eller mime-typen for at kontrollere, at filen er et billede, da disse let kan falses. Selv at åbne filen og læse overskriften eller bruge funktioner til at kontrollere billedstørrelsen er ikke idiotsikker. De fleste billedformater tillader lagring af en kommentarsektion, der kunne indeholde PHP-kode, der kunne udføres af serveren.

Så hvad kan du gøre for at forhindre dette? I sidste ende vil du forhindre brugere i at være i stand til at udføre enhver fil, de uploader. Som standard forsøger webservere ikke at udføre filer med billedudvidelser, men stol ikke udelukkende på at kontrollere filtypen, da en fil med navnet image.jpg.php har været kendt for at komme igennem.

Nogle muligheder er at omdøbe filen ved upload for at sikre den korrekte filtypenavn eller at ændre filtilladelser, for eksempel chmod 0666, så den ikke kan udføres. Hvis du bruger * nix, kan du oprette en .htaccess-fil (se nedenfor), der kun giver adgang til indstillingsfiler, der forhindrer det tidligere nævnte dobbeltudvidelsesangreb.

deny from all order deny,allow allow from all

I sidste ende er den anbefalede løsning at forhindre direkte adgang til uploadede filer helt. På denne måde gemmes alle filer, der uploades til dit websted, i en mappe uden for webroot eller i databasen som en blob. Hvis dine filer ikke er direkte tilgængelige, skal du oprette et script til at hente filerne fra den private mappe (eller en HTTP-handler i .NET) og levere dem til browseren. Billedkoder understøtter en src-attribut, der ikke er en direkte URL til et billede, så din src-attribut kan pege på dit filleveringsscript, forudsat at du indstiller den korrekte indholdstype i HTTP-headeren. For eksempel:

De fleste hostingudbydere beskæftiger sig med serverkonfigurationen for dig, men hvis du er vært for dit websted på din egen server, er der få ting, du vil kontrollere.

Sørg for, at du har en firewallopsætning og blokerer alle ikke-vigtige porte. Hvis det er muligt at oprette en DMZ (Demilitarized Zone), der kun giver adgang til port 80 og 443 fra omverdenen. Selvom dette muligvis ikke er muligt, hvis du ikke har adgang til din server fra et internt netværk, da du bliver nødt til at åbne porte for at tillade upload af filer og for at logge på din server eksternt via SSH eller RDP.

Hvis du tillader, at filer uploades fra internettet, skal du kun bruge sikre transportmetoder til din server, såsom SFTP eller SSH.

Hvis det er muligt, skal din database køre på en anden server end din webserver. At gøre dette betyder, at databaseserveren ikke kan tilgås direkte fra omverdenen, kun din webserver kan få adgang til den, hvilket minimerer risikoen for, at dine data bliver eksponeret.

Endelig skal du ikke glemme at begrænse fysisk adgang til din server.

08. Brug HTTPS

HTTPS er en protokol, der bruges til at give sikkerhed over Internettet. HTTPS garanterer, at brugerne taler til den server, de forventer, og at ingen andre kan opfange eller ændre det indhold, de ser i transit.

Hvis du har noget, som dine brugere måske vil have privat, er det meget tilrådeligt at kun bruge HTTPS til at levere det. Det betyder naturligvis kreditkort- og login-sider (og de URL'er, de sender til), men typisk også meget mere af dit websted. En loginformular indstiller ofte f.eks. En cookie, der sendes med hver anden anmodning til dit websted, som en logget bruger foretager, og bruges til at godkende disse anmodninger. En hacker, der stjæler dette, ville være i stand til perfekt at efterligne en bruger og overtage deres login-session. For at besejre denne form for angreb, vil du næsten altid bruge HTTPS til hele dit websted.

Det er ikke længere så vanskeligt eller dyrt som det engang var. Lad os kryptere giver helt gratis og automatiserede certifikater, som du skal bruge for at aktivere HTTPS, og der findes eksisterende fællesskabsværktøjer til en bred vifte af fælles platforme og rammer for automatisk at konfigurere dette for dig.

Især Google har meddelt, at de vil øge dig i søgerangeringer, hvis du bruger HTTPS, hvilket også giver dette en SEO-fordel. Usikker HTTP er på vej ud, og nu er det tid til at opgradere.

Bruger du allerede HTTPS overalt? Gå videre og se på opsætning af HTTP Strict Transport Security (HSTS), en nem header, du kan føje til dine serverresponser for at afvise usikker HTTP for hele dit domæne.

09. Få websitets sikkerhedsværktøjer

Når du først tror, ​​du har gjort alt hvad du kan, er det tid til at teste dit websteds sikkerhed. Den mest effektive måde at gøre dette på er ved brug af nogle websidesikkerhedsværktøjer, ofte kaldet penetrationstest eller kort testning af penne.

Der er mange kommercielle og gratis produkter, der kan hjælpe dig med dette. De arbejder på samme måde som scripts hackere, idet de tester alle kendte bedrifter og forsøger at kompromittere dit websted ved hjælp af nogle af de tidligere nævnte metoder såsom SQL Injection.

Nogle gratis værktøjer, der er værd at se på:

  • Netsparker (Gratis community-udgave og prøveversion tilgængelig). God til test af SQL-injektion og XSS
  • OpenVAS Påstår at være den mest avancerede open source sikkerhedsscanner. God til test af kendte sårbarheder, scanner i øjeblikket over 25.000. Men det kan være svært at konfigurere og kræver, at der er installeret en OpenVAS-server, som kun kører på * nix. OpenVAS er fork af en Nessus, før den blev et kommercielt produkt med lukket kilde.
  • SecurityHeaders.io (gratis online check). Et værktøj til hurtigt at rapportere, hvilke sikkerhedsoverskrifter der er nævnt ovenfor (såsom CSP og HSTS) et domæne har aktiveret og korrekt konfigureret.
  • Xenotix XSS Exploit Framework Et værktøj fra OWASP (Open Web Application Security Project), der inkluderer et stort udvalg af XSS-angrebseksempler, som du kan køre for hurtigt at bekræfte, om dit websteds input er sårbare i Chrome, Firefox og IE.

Resultaterne fra automatiserede tests kan være skræmmende, da de præsenterer et væld af potentielle problemer. Det vigtige er først at fokusere på de kritiske spørgsmål. Hvert rapporteret problem leveres normalt med en god forklaring på den potentielle sårbarhed. Du vil sandsynligvis finde ud af, at nogle af mellemstore / lave problemer ikke er et problem for dit websted.

Der er nogle yderligere trin, du kan tage for manuelt at prøve at kompromittere dit websted ved at ændre POST / GET-værdier. En debugging-proxy kan hjælpe dig her, da det giver dig mulighed for at opfange værdierne for en HTTP-anmodning mellem din browser og serveren. En populær freeware-applikation kaldet Violinist er et godt udgangspunkt.

Så hvad skal du prøve at ændre på anmodningen? Hvis du har sider, der kun skal være synlige for en logget bruger, så prøv at ændre URL-parametre som bruger-id eller cookieværdier i et forsøg på at se detaljer om en anden bruger. Et andet område, der er værd at teste, er formularer, der ændrer POST-værdierne for at forsøge at indsende kode for at udføre XSS eller uploade et serversidescript.

Relaterede artikler: