En hurtig introduktion til websikkerhed

En webudviklers primer på CORS, CSP, HSTS og alle websikkerhedsakronymer!

Der er mange grunde til at lære om websikkerhed, såsom:

  • Du er en bekymret bruger, der er bekymret for, at dine personlige data lækkes
  • Du er en bekymret webudvikler, der ønsker at gøre deres webapps mere sikre
  • Du er en webudvikler, der ansøger om job, og du vil være klar, hvis dine interviewere stiller dig spørgsmål om websikkerhed

og så videre.

Nå dette indlæg vil forklare nogle almindelige websikkerhedsakronymer på en måde, der er let at forstå, men stadig nøjagtig.

Før vi gør det, lad os sikre os, at vi forstår et par kernebegreber om sikkerhed.

To kernebegreber om sikkerhed

Ingen er nogensinde 100% sikre.

Der er ingen forestilling om at være 100% beskyttet mod hacking. Hvis nogen nogensinde fortæller dig det, tager de fejl.

Et lag af beskyttelse er ikke nok.

Du kan ikke bare sige ...

Åh, fordi jeg har implementeret CSP, er jeg sikker. Jeg kan krydse cross-site scripting fra min sårbarhedsliste, fordi det ikke kan ske nu.

Måske er det givet for nogle, men det er let at finde dig selv til at tænke på denne måde. Jeg tror, ​​at en af ​​grundene til, at programmører let kan finde sig selv i at tænke på denne måde, er, at så meget af kodning er sort og hvid, 0 eller 1, sand eller falsk. Sikkerhed er ikke så enkel.

Vi starter med en, som alle løber ind temmelig tidligt på deres webudviklingsrejse. Og så ser du på StackOverflow og finder en masse svar, der fortæller dig, hvordan du kan omgå det.

Deling af ressourcer på tværs af oprindelse (CORS)

Har du nogensinde fået en fejl, der lignede dette?

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Du er bestemt ikke alene. Og så googler du det, og nogen fortæller dig, at du skal få denne udvidelse, der får alle dine problemer til at forsvinde!

Fantastisk, ikke?

CORS er der for at beskytte dig og ikke skade dig!

For at forklare, hvordan CORS hjælper dig, lad os først tale om cookies, specifikt godkendelsescookies . Autentificeringscookies bruges til at fortælle en server, at du er logget ind, og de sendes automatisk med enhver anmodning, du foretager til den server.

Lad os sige, at du er logget ind på Facebook, og de bruger godkendelsescookies. Du klikker på, bit.ly/r43nugihvilke omdirigerer dig til superevilwebsite.rocks. Et script inden for superevilwebsite.rocksindgiver en klientside-anmodning, facebook.comsom sender din godkendelsescookie!

I en verden uden CORS kunne de foretage ændringer på din konto uden at du engang vidste det. Indtil de selvfølgelig skriver bit.ly/r43nugipå din tidslinje, og alle dine venner klikker på den, og så poster de bit.ly/r43nugipå alle dine venners tidslinjer, og derefter fortsætter cyklussen i en ond bredde-første ordning, der erobrer alle Facebook-brugere, og verden fortæres af superevilwebsite.rocks. ?

I en CORS-verden tillader Facebook imidlertid kun anmodninger med oprindelse om facebook.comat redigere data på deres server. Med andre ord ville de begrænse deling af ressourcer på tværs af oprindelse. Du kan så spørge ...

Nå kan superevilwebsite.rocks bare ændre oprindelsesoverskriften på deres anmodning, så det ser ud til at det kommer fra facebook.com?

De kan prøve, men det virker ikke, fordi browseren bare ignorerer det og bruger den rigtige oprindelse.

Ok, men hvad hvis superevilwebsite.rocks foretog anmodningen på serversiden?

I dette tilfælde kan de omgå CORS, men de vinder ikke, fordi de ikke kan sende din godkendelsescookie med på turen. Scriptet skal udføres på klientsiden for at få adgang til dine klientsidescookies.

Indholdssikkerhedspolitik (CSP)

For at forstå CSP skal vi først tale om en af ​​de mest almindelige sårbarheder på nettet: XSS, der står for scripting på tværs af websteder (yay - et andet akronym).

XSS er, når en ond person injicerer JavaScript i din klientsides kode. Du tror måske ...

Hvad vil de gøre? Skifte en farve fra rød til blå?

Lad os antage, at nogen med succes har injiceret JavaScript i klientsides kode på et websted, du besøger.

Hvad kunne de gøre, der ville være ondsindet?

  • De kunne komme med HTTP-anmodninger til et andet websted og foregive at være dig.
  • De kunne tilføje et ankermærke, der sender dig til et websted, der ser identisk ud med det, du er på, med nogle lidt forskellige ondsindede egenskaber.
  • De kunne tilføje et script-tag med indbygget JavaScript.
  • De kunne tilføje et script-tag, der henter en ekstern JavaScript-fil et eller andet sted.
  • De kunne tilføje en iframe, der dækker siden og ligner en del af hjemmesiden, der beder dig om at indsætte din adgangskode.

Mulighederne er uendelige.

CSP forsøger at forhindre dette i at begrænse:

  • hvad der kan åbnes i en iframe
  • hvilke stilark, der kan indlæses
  • hvor anmodninger kan fremsættes osv.

Så hvordan fungerer det?

Når du klikker på et link eller skriver en websteds-URL i adresselinjen i din browser, fremsætter din browser en GET-anmodning. Det går til sidst til en server, der serverer HTML sammen med nogle HTTP-headere. Hvis du er nysgerrig efter, hvilke overskrifter du modtager, skal du åbne fanen Netværk i din konsol og besøge nogle websteder.

Du kan muligvis se et svarhoved, der ser sådan ud:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Det er politik for indholdssikkerhed facebook.com. Lad os omformatere det for at gøre det lettere at læse:

content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Lad os nu nedbryde direktiverne.

  • default-src begrænser alle andre CSP-direktiver, der ikke er eksplicit anført.
  • script-srcbegrænser de scripts, der kan indlæses.
  • style-src begrænser de stilark, der kan indlæses.
  • connect-src begrænser de URL'er, der kan indlæses ved hjælp af scriptgrænseflader, så hent, XHR, ajax osv.

Bemærk, at der er mange flere CSP-direktiver end bare disse fire vist ovenfor. Browseren læser CSP-overskriften og anvender disse direktiver på alt inden for den HTML-fil, der blev serveret. Hvis direktiverne er indstillet korrekt, tillader de kun, hvad der er nødvendigt.

Hvis der ikke er nogen CSP-header, går alt, og intet er begrænset. Overalt hvor du ser *, er det et jokertegn. Du kan forestille dig at erstatte *med noget, og det vil være tilladt.

HTTPS eller HTTP Secure

Du har bestemt hørt om HTTPS. Måske har du hørt nogle sige ...

Hvorfor er jeg interesseret i at bruge HTTPS, hvis jeg bare er på et websted og spiller et spil.

Eller måske har du hørt den anden side ...

Du er vild, hvis dit websted ikke har HTTPS. Det er 2018! Stol ikke på nogen, der siger andet.

Måske har du hørt, at Chrome nu markerer dit websted som usikkert, hvis det ikke er HTTPS.

I sin kerne er HTTPS ret ligetil. HTTPS er krypteret, og HTTP er ikke.

Så hvorfor betyder det noget, hvis du ikke sender følsomme data?

Gør dig klar til endnu et akronym ... MITM, som står for Man in the Middle.

Hvis du bruger offentlig Wi-Fi uden adgangskode på en kaffebar, er det ret nemt for nogen at opføre sig som din router, så alle anmodninger og svar gennemgår dem. Hvis dine data ikke er krypteret, kan de gøre hvad de vil med dem. De kan redigere HTML, CSS eller JavaScript, før det overhovedet kommer til din browser. I betragtning af hvad vi ved om XSS, kan du forestille dig, hvor dårlig dette kunne være.

Okay, men hvordan ved det, at min computer og serveren ved, hvordan man krypterer / dekrypterer, men denne MITM gør det ikke?

That’s where SSL (Secure Sockets Layer) and more recently, TLS (Transport Layer Security) come in. TLS took over for SSL in 1999 as the encryption technology used within HTTPS. Exactly how TLS works is outside of the scope of this post.

HTTP Strict-Transport-Security (HSTS)

This one is pretty straightforward. Let’s use Facebook’s header as an example again:

strict-transport-security: max-age=15552000; preload
  • max-age specifies how long a browser should remember to force the user to access a website using HTTPS.
  • preload is not important for our purposes. It is a service hosted by Google and not part of the HSTS specification.

This header only applies if you accessed the site using HTTPS. If you accessed the site via HTTP, the header is ignored. The reason is that, quite simply, HTTP is so insecure that it can’t be trusted.

Let’s use the Facebook example to further illustrate how this is helpful in practice. You are accessing facebook.com for the first time, and you know HTTPS is safer than HTTP, so you access it over HTTPS, //facebook.com. When your browser receives the HTML, it receives the header above which tells your browser to force-redirect you to HTTPS for future requests. One month later, someone sends you a link to Facebook using HTTP, //facebook.com, and you click on it. Since one month is less than the 15552000 seconds specified by the max-age directive, your browser will send the request as HTTPS, preventing a potential MITM attack.

Closing Thoughts

Websikkerhed er vigtig, uanset hvor du er på din webudviklingsrejse. Jo mere du udsætter dig for det, jo bedre har du det. Sikkerhed er noget, der skal være vigtigt for alle, ikke kun de mennesker, der har det udtrykkeligt navngivet i deres jobtitel! ?