Nopea esittely verkkoturvallisuuteen

Verkkokehittäjän alusta CORS: ssä, CSP: ssä, HSTS: ssä ja kaikissa verkkoturvallisuuden lyhenteissä!

Verkkosuojauksesta on monia syitä oppia, kuten:

  • Olet huolestunut käyttäjä, joka on huolissaan henkilötietojesi vuotamisesta
  • Olet huolestunut verkkokehittäjä, joka haluaa tehdä verkkosovelluksistaan ​​turvallisempia
  • Olet verkkokehittäjä, joka hakee työpaikkoja, ja haluat olla valmis, jos haastattelijat kysyvät sinulta kysymyksiä verkkoturvallisuudesta

ja niin edelleen.

No, tämä viesti selittää joitain yleisiä verkkoturvallisuuden lyhenteitä tavalla, joka on helppo ymmärtää, mutta silti tarkka.

Ennen kuin teemme sen, varmista, että ymmärrämme muutaman turvallisuuden keskeisen käsitteen.

Kaksi turvallisuuden peruskäsitettä

Kukaan ei ole koskaan 100% turvallinen.

Ei ole ajatusta olla 100-prosenttisesti suojattu hakkeroinnilta. Jos joku joskus kertoo sinulle niin, he ovat väärässä.

Yksi suojakerros ei riitä.

Et voi vain sanoa…

Koska minulla on CSP otettu käyttöön, olen turvassa. Voin poistaa sivustojen välisen komentosarjan haavoittuvuusluettelostani, koska sitä ei voi tapahtua nyt.

Ehkä se on joillekin annettu, mutta on helppo löytää itsesi ajattelemaan tällä tavalla. Mielestäni yksi syy siihen, että ohjelmoijat voivat helposti löytää itsensä ajattelemaan tällä tavoin, johtuu siitä, että niin paljon koodausta on mustavalkoinen, 0 tai 1, tosi tai väärä. Turvallisuus ei ole niin yksinkertaista.

Aloitamme yhdellä, johon jokainen törmää melko varhaisessa vaiheessa verkkokehitysmatkallaan. Ja sitten katsot StackOverflow-ohjelmaa ja löydät joukon vastauksia, jotka kertovat kuinka ohittaa se.

Alkuperien välinen resurssien jakaminen (CORS)

Oletko koskaan saanut virheen, joka näytti tältä tältä?

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

Et todellakaan ole yksin. Ja sitten Google, ja joku käskee hankkia tämä laajennus, joka saa kaikki ongelmat häviämään!

Hienoa, eikö?

CORS suojelee sinua, ei vahingoita sinua!

Selitämme ensin, kuinka CORS auttaa sinua, puhumme ensin evästeistä, erityisesti todennusevästeistä . Todennusevästeitä käytetään kertomaan palvelimelle, että olet kirjautunut sisään, ja ne lähetetään automaattisesti kaikkien pyyntöjen kanssa, jotka teet tälle palvelimelle.

Oletetaan, että olet kirjautunut sisään Facebookiin, ja he käyttävät todennusevästeitä. Napsautat, bit.ly/r43nugimikä ohjaa sinut superevilwebsite.rocks. Sisältyvä komentosarja superevilwebsite.rockstekee asiakaspuolen pyynnön, facebook.comjolle lähetetään todennuseväste!

Ei-CORS-maailmassa he voivat tehdä muutoksia tiliisi ilman sinun edes tietämättä. Kunnes tietysti he julkaisevat bit.ly/r43nugiaikajanallesi, ja kaikki ystäväsi napsauttavat sitä, ja sitten he lähettävät bit.ly/r43nugikaikki ystäväsi aikajanat ja sitten sykli jatkuu pahassa laajuudessa ensin, joka valloittaa kaikki Facebookin käyttäjät, ja maailma kuluttaa superevilwebsite.rocks. ?

CORS-maailmassa Facebook sallisi kuitenkin vain pyynnöt, joiden alkuperä on peräisin, facebook.commuokata palvelimellaan olevia tietoja. Toisin sanoen ne rajoittavat alkuperän välistä resurssien jakamista. Voit sitten kysyä…

Voiko superevilwebsite.rocks vain muuttaa alkuperäisen otsikon heidän pyyntössään niin, että näyttää siltä, ​​että se tulee facebook.comista?

He voivat yrittää, mutta se ei toimi, koska selain vain ohittaa sen ja käyttää todellista alkuperää.

Ok, mutta entä jos superevilwebsite.rocks tekisi pyynnön palvelinpuolelta?

Tässä tapauksessa he voivat ohittaa CORS: n, mutta he eivät voita, koska he eivät voi lähettää todennusevästettäsi matkaa varten. Komentosarja on suoritettava asiakaspuolella saadakseen pääsyn asiakaspuolen evästeisiin.

Sisällön suojauskäytäntö (CSP)

CSP: n ymmärtämiseksi meidän on ensin puhuttava yhdestä yleisimmistä verkon haavoittuvuuksista: XSS, joka tarkoittaa sivustojen välistä komentosarjaa (yay - toinen lyhenne).

XSS on silloin, kun joku paha henkilö pistää JavaScriptin asiakaspuolen koodiin. Saatat ajatella…

Mitä he aikovat tehdä? Vaihdetaanko väri punaisesta siniseksi?

Oletetaan, että joku on onnistuneesti pistellyt JavaScriptiä vierailemasi verkkosivuston asiakaspuolen koodiin.

Mitä he voisivat tehdä, mikä olisi haitallista?

  • He voivat tehdä HTTP-pyyntöjä toiselle sivustolle teeskentelemällä sinua.
  • He voivat lisätä ankkuritunnisteen, joka lähettää sinut verkkosivustolle, joka näyttää identtiseltä verkkosivustollasi, jolla on hieman erilaisia, haitallisia ominaisuuksia.
  • He voivat lisätä komentotunnisteen, jossa on upotettu JavaScript.
  • He voivat lisätä komentotunnisteen, joka hakee Java-etätiedoston jostakin.
  • He voivat lisätä iframe-kehyksen, joka peittää sivun ja näyttää olevan osa verkkosivustoa ja kehottaa sinua lisäämään salasanasi.

Mahdollisuudet ovat rajattomat.

CSP yrittää estää tämän tapahtumisen rajoittamalla:

  • mitä voidaan avata iframe-kehyksessä
  • mitä tyylitaulukoita voidaan ladata
  • missä pyyntöjä voidaan tehdä jne.

Joten miten se toimii?

Kun napsautat linkkiä tai kirjoitat verkkosivuston URL-osoitteen selaimesi osoiteriville, selaimesi tekee GET-pyynnön. Lopulta se kulkee palvelimelle, joka palvelee HTML-koodia yhdessä joidenkin HTTP-otsikkojen kanssa. Jos olet kiinnostunut otsikoista, avaa konsoli Verkko-välilehti ja käy joillakin verkkosivustoilla.

Saatat nähdä vastauksen otsikon, joka näyttää tältä:

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;

Se on facebook.com. Alusta se uudelleen lukemisen helpottamiseksi:

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;

Hajotetaan nyt direktiivit.

  • default-src rajoittaa kaikkia muita CSP-direktiivejä, joita ei ole nimenomaisesti lueteltu.
  • script-srcrajoittaa ladattavia komentosarjoja.
  • style-src rajoittaa ladattavia tyylitaulukoita.
  • connect-src rajoittaa URL-osoitteita, jotka voidaan ladata komentorajapintojen avulla, joten hae, XHR, ajax jne.

Huomaa, että CSP-direktiivejä on paljon enemmän kuin vain nämä neljä yllä esitettyä. Selain lukee CSP-otsikon ja soveltaa näitä direktiivejä kaikkeen HTML-tiedostossa, joka on annettu. Jos direktiivit on asetettu asianmukaisesti, ne sallivat vain sen, mikä on välttämätöntä.

Jos CSP-otsikkoa ei ole, kaikki menee, eikä mitään ole rajoitettu. Joka paikassa näet *, se on jokerimerkki. Voit kuvitella korvaavansi *millä tahansa, ja se sallitaan.

HTTPS tai HTTP Secure

Olet varmasti kuullut HTTPS: stä. Ehkä olet kuullut joidenkin sanovan…

Miksi välitän HTTPS: n käytöstä, jos pelailen vain verkkosivustolla.

Tai ehkä olet kuullut toisen puolen ...

Olet hullu, jos sivustollasi ei ole HTTPS-protokollaa. On vuosi 2018! Älä luota ketään, joka sanoo toisin.

Ehkä olet kuullut, että Chrome merkitsee nyt sivustosi epävarmaksi, jos se ei ole HTTPS.

Ytimessä HTTPS on melko yksinkertainen. HTTPS on salattu ja HTTP ei.

Joten miksi tällä on merkitystä, jos et lähetä arkaluontoisia tietoja?

Valmistaudu toiseen lyhenteeseen ... MITM, joka tarkoittaa ihmistä keskellä.

Jos käytät kahvilassa julkista Wi-Fi-yhteyttä ilman salasanaa, jonkun on melko helppo toimia reitittimesi tapaan, jotta kaikki pyynnöt ja vastaukset käyvät läpi ne. Jos tietojasi ei ole salattu, he voivat tehdä sen kanssa mitä haluavat. He voivat muokata HTML: ää, CSS: ää tai JavaScriptiä ennen kuin se edes pääsee selaimeesi. Ottaen huomioon mitä tiedämme XSS: stä, voit kuvitella kuinka huono tämä voisi olla.

Ok, mutta miten tietokone ja palvelin tietävät kuinka salata / purkaa, mutta tämä MITM ei?

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

Verkkoturva on tärkeää riippumatta siitä, missä olet verkkokehitysmatkallasi. Mitä enemmän altistat itsesi sille, sitä paremmin sinulla on. Turvallisuus on jotain, jonka pitäisi olla tärkeää kaikille, ei vain ihmisille, joiden se nimenomaisesti nimetään tehtävänimikkeessään! ?