Gyors bevezetés a webbiztonságba

Webfejlesztő alapismeretek a CORS-on, a CSP-n, a HSTS-en és az összes webes biztonsági rövidítésen!

Számos oka lehet a webes biztonság megismerésének, például:

  • Aggódó felhasználó vagy, aki aggódik a személyes adatok kiszivárogtatása miatt
  • Ön egy aggódó webfejlesztő, aki biztonságosabbá akarja tenni webalkalmazásait
  • Webhely-fejlesztő vagy, aki jelentkezik állásokra, és készen állsz arra, hogy kérdezőid feltegyenek kérdéseket a webbiztonsággal kapcsolatban

stb.

Nos, ez a bejegyzés néhány érthető, de mégis pontos módon elmagyarázza néhány általános webbiztonsági rövidítést.

Mielőtt ezt megtennénk, győződjünk meg arról, hogy megértettük a biztonság néhány alapvető fogalmát.

A biztonság két alapvető fogalma

Soha senki nincs 100% -ban biztonságban.

Nincs elképzelés arról, hogy 100% -osan védve legyenek a feltöréstől. Ha valaki valaha ezt mondja neked, téved.

Egy réteg védelem nem elegendő.

Nem mondhatja csak ...

Ó, mivel a CSP-t megvalósítottam, biztonságban vagyok. Kihúzhatom a webhelyek közötti parancsfájlokat a sérülékenységi listámból, mert ez most nem fordulhat elő.

Lehet, hogy ez adott néhány ember számára, de könnyen megtalálja magát ilyen módon gondolkodni. Azt hiszem, az egyik oka annak, hogy a programozók könnyen találhatják magukat ilyen módon, az az oka, hogy a kódolás nagy része fekete-fehér, 0 vagy 1, igaz vagy hamis. A biztonság nem ilyen egyszerű.

Kezdjük azzal, amellyel mindenki meglehetősen korán belefut webfejlesztési útjára. És utána néz a StackOverflow-nak, és egy csomó választ talál, amelyek megmondják, hogyan lehet megkerülni.

Eredetközi erőforrás-megosztás (CORS)

Kaptál már valamilyen hibát, ami ilyesminek tűnt?

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

Biztosan nem vagy egyedül. És akkor a Google-on, és valaki azt mondja neked, hogy szerezd be ezt a kiterjesztést, amely megszünteti az összes problémádat!

Remek, igaz?

A CORS azért van, hogy megvédjen, és ne bántson!

Annak elmagyarázása érdekében, hogy a CORS hogyan segít Önnek, először beszéljünk a sütikről, konkrétan a hitelesítési sütikről . A hitelesítési sütiket arra használják, hogy megmondják a szervernek, hogy bejelentkezett, és automatikusan elküldik őket minden kéréssel, amelyet a szerverre küld.

Tegyük fel, hogy be van jelentkezve a Facebookra, és ők hitelesítési sütiket használnak. Kattintson arra, bit.ly/r43nugiamelyikre átirányít superevilwebsite.rocks. A belüli szkript superevilwebsite.rockskliens oldali kérést facebook.comküld , amelyre elküldi a hitelesítési sütit!

A CORS nélküli világban változtathatnak a fiókján, anélkül, hogy tudná. Amíg természetesen nem tesznek közzé bit.ly/r43nugiaz idővonaladon, és az összes barátod rákattint, majd bit.ly/r43nugiaz összes barátod idővonalára felkerül, majd a ciklus gonosz szélességű sémában folytatódik, amely meghódítja a Facebook összes felhasználóját, és a világot elfogyasztja superevilwebsite.rocks. ?

A CORS-világban a Facebook azonban csak facebook.coma kiszolgálójukon lévő adatok szerkesztését engedélyezi az eredet szerinti kérelmek számára . Más szavakkal, korlátoznák a származási helyek közötti erőforrások megosztását. Ezután megkérdezheti…

Nos, a superevilwebsite.rocks csak megváltoztathatja az eredet fejlécét kérésükre, úgy hogy úgy néz ki, mintha a facebook.com-ról származna?

Megpróbálhatják, de ez nem fog működni, mert a böngésző csak figyelmen kívül hagyja és felhasználja a valódi eredetet.

Oké, de mi van, ha a superevilwebsite.rocks szerveroldalra teszi a kérést?

Ebben az esetben megkerülhetik a CORS-t, de nem nyernek, mert nem tudják elküldeni a hitelesítési sütit az útra. A parancsfájlnak az ügyfél oldalán kell végrehajtania, hogy hozzáférjen az ügyféloldali sütikhez.

Tartalombiztonsági irányelvek (CSP)

A CSP megértéséhez először a web egyik leggyakoribb sebezhetőségéről kell beszélnünk: az XSS-ről, amely a webhelyek közötti szkripteket (yay - egy másik rövidítés) jelenti.

Az XSS az, amikor valami gonosz ember injektálja a JavaScript-et az ügyféloldali kódba. Gondolhatja ...

Mit fognak csinálni? Változtat egy színt pirosról kékre?

Tegyük fel, hogy valaki sikeresen befecskendezte a JavaScript-et egy látogatott webhely kliensoldali kódjába.

Mit tehetnének, ami rosszindulatú lenne?

  • HTTP kéréseket küldhetnek egy másik webhelyre úgy, mintha ön lennének.
  • Hozzáadhatnak egy horgonycímkét, amely egy olyan webhelyre küld, amely megegyezik azzal, amelyen Ön tartózkodik, és kissé eltérő, rosszindulatú tulajdonságokkal rendelkezik.
  • Hozzáadhatnának egy inline JavaScript-szel ellátott szkriptcímkét.
  • Hozzáadhatnának egy szkript címkét, amely valahonnan lekér egy távoli JavaScript fájlt.
  • Hozzáadhatnak egy iframe-et, amely lefedi az oldalt, és úgy néz ki, mint a webhely része, és arra kéri, hogy írja be a jelszavát.

A lehetőségek végtelenek.

A CSP az alábbiak korlátozásával próbálja megakadályozni ezt:

  • mit lehet nyitni iframe-ben
  • milyen stíluslapok tölthetők be
  • hol lehet kéréseket benyújtani stb.

Tehát hogyan működik?

Amikor rákattint egy linkre, vagy beír egy webhely URL-jét a böngésző címsorába, a böngésző GET-kérést küld. Végül eljut egy olyan kiszolgálóhoz, amely HTML-t és néhány HTTP-fejlécet szolgáltat. Ha kíváncsi arra, hogy milyen fejléceket kap, nyissa meg a Hálózat fület a konzolján, és látogasson el néhány webhelyre.

Láthat egy válasz fejlécet, amely így néz ki:

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;

Ez a facebook.com. Formázzuk újra az olvasás megkönnyítése érdekében:

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;

Most bontsuk szét az irányelveket.

  • default-src korlátozza az összes többi CSP-irányelvet, amely nincs kifejezetten felsorolva.
  • script-srckorlátozza a betölthető szkripteket.
  • style-src korlátozza a betölthető stíluslapokat.
  • connect-src korlátozza azokat az URL-eket, amelyek szkript interfészekkel tölthetők be, tehát fetch, XHR, ajax stb.

Ne feledje, hogy sokkal több CSP irányelv létezik, mint a fent bemutatott négy. A böngésző elolvassa a CSP fejlécét, és ezeket az irányelveket a kiszolgált HTML fájlban mindenre alkalmazza. Ha az irányelveket megfelelően határozzák meg, akkor csak a szükségeseket engedik meg.

Ha nincs CSP fejléc, akkor minden megy, és semmi nincs korlátozva. Mindenhol *ez helyettesítő karakter. Elképzelheti, hogy *bármivel helyettesítheti , és ez megengedett.

HTTPS vagy HTTP biztonságos

Természetesen hallottál a HTTPS-ről. Talán hallottál olyanokat, akik azt mondták…

Miért érdekel a HTTPS használata, ha csak egy webhelyen vagyok, és játékot játszok

Vagy talán hallotta a másik oldalt ...

Őrült vagy, ha a webhelyeden nincs HTTPS. 2018 van! Ne bízz senkiben, aki mást mond.

Talán hallotta, hogy a Chrome most bizonytalannak fogja jelölni webhelyét, ha az nem HTTPS.

Lényegében a HTTPS meglehetősen egyszerű. A HTTPS titkosítva van, a HTTP pedig nem.

Akkor miért számít ez, ha nem küld érzékeny adatokat?

Készülj fel egy újabb betűszóra ... A MITM, amely az ember a középen rövidítést jelenti.

Ha nyilvános Wi-Fi-t használ jelszó nélkül egy kávézóban, akkor valakinek elég könnyű úgy viselkednie, mint az útválasztóján, így minden kérés és válasz átesik rajtuk. Ha adatai nincsenek titkosítva, akkor bármit megtehetnek vele. Szerkeszthetik a HTML-t, a CSS-t vagy a JavaScript-et, még mielőtt az az Ön böngészőjébe kerülne. Tekintettel arra, amit tudunk az XSS-ről, el lehet képzelni, milyen rossz lehet ez.

Oké, de hogy van az, hogy a számítógépem és a kiszolgálóm hogyan tudja titkosítani / visszafejteni, de ez a MITM nem?

Itt jön be az SSL (Secure Sockets Layer) és újabban a TLS (Transport Layer Security). A TLS 1999-ben vette át az SSL-t, mint a HTTPS-en belül használt titkosítási technológiát. A TLS működése pontosan nem tartozik e bejegyzés körébe.

HTTP szigorú szállítási biztonság (HSTS)

Ez elég egyértelmű. Használjuk ismét a Facebook fejlécét:

strict-transport-security: max-age=15552000; preload
  • max-age meghatározza, hogy a böngészőnek meddig kell emlékeznie arra, hogy a felhasználót arra kényszerítse, hogy HTTPS használatával férjen hozzá egy webhelyhez.
  • preloadcéljaink szempontjából nem fontos. Ez egy olyan szolgáltatás, amelyet a Google üzemeltet, és nem része a HSTS specifikációnak.

Ez a fejléc csak akkor érvényes, ha a webhelyet HTTPS használatával érte el. Ha HTTP-n keresztül jutott el a webhelyhez, a fejlécet figyelmen kívül hagyja. Ennek oka az, hogy egész egyszerűen a HTTP annyira bizonytalan, hogy nem lehet megbízni benne.

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

Web security is important no matter where you are in your web development journey. The more you expose yourself to it, the better off you will be. Security is something that should be important to everyone, not just the people who have it explicitly named in their job title! ?