Az Önhöz hasonló olvasók támogatják a MUO-t. Amikor a webhelyünkön található linkek használatával vásárol, társult jutalékot kaphatunk.
Amikor meg szeretne látogatni egy webhelyet, az Ön által használt internetböngésző kap bizonyos adatokat az adott webhelyről. Ennek eredményeként párbeszéd lép fel az eszköz és a webhely között. Ez történik a HTTP nevű protokollal. Lehetőség van további biztonsági intézkedések meghozatalára, ha beavatkozunk ebbe a párbeszédbe.
Ha weboldalt üzemeltet, vagy webfejlesztői karrierre törekszik, a HTTP biztonsági fejlécek felbecsülhetetlen értékűek az Ön számára, mert mind a felhasználó, mind a webhely biztonságában aktív szerepet játszanak.
Mi az a HTTP Strict-Transport-Security (HSTS)?
A HTTP Strict Transport Security (HSTS) arra kényszeríti a felhasználókat, hogy a böngészőjükben tett minden kérésnél HTTPS-t használjanak. Ez egy szilárd módszer a kibertámadások, például a leminősítések leküzdésére és az összes forgalom biztonságának biztosítására.
A HSTS aktiválása meglehetősen egyszerű. Vegye figyelembe a kliens és a szerver közötti párbeszédet. Amikor böngészőjén keresztül próbál elérni egy webhelyet, Ön az ügyfél. A megnyitni kívánt webhely a szervertől függ. A cél az, hogy közölje a szerverrel: "Meg akarom nyitni ezt az oldalt". Ez egy kérési művelet. A szerver viszont az oldalra irányít, ha megfelel a kívánt feltételeknek.
Ne feledje ezt a minta HTTP-fejléc jelzővel kapcsolatban:
Szigorú közlekedési biztonság: max-age=16070200;
Ha hozzáadja ezt a jelzőt a HTTP-válasz fejlécinformációihoz, az összes felhasználó által generált kérés HTTPS-vé válik. Bármit ír is a felhasználó ide, a böngésző automatikusan HTTPS-ként értékeli a protokollt, és biztonságos kapcsolatot létesít.
A HSTS használata
Ahelyett, hogy ezeket a HTTP-fejléc-információkat hozzáadná a kódréteghez, ezt megteheti Apache, IIS, Nginx, Tomcat és más webszerver-alkalmazásokon.
A HSTS engedélyezése az Apache-ban:
LoadModule headers_module modules/mod_headers.so
<VirtualHost *:443>
Fejléc mindig készletSzigorú-Szállítás-Biztonság "max-age=2592000; includeSubDomains"
</VirtualHost>
A HSTS engedélyezése az Nginxben:
add_header Strict-Transport-Security max-age=2592000; includeSubdomains
A HSTS engedélyezése az IIS web.config segítségével:
<system.webServer>
<http Protokoll>
<egyéni fejlécek>
<add name="Szigorú közlekedési biztonság" érték="max-age=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Cloudflare felhasználóknak
A Cloudflare Keyless SSL szolgáltatásával mindenki számára ingyenes HTTPS-szolgáltatást biztosít; Mielőtt HSTS előtöltésre jelentkezne, tudnia kell, hogy a tanúsítványa nem az Öné. Sok webhely használ SSL-tanúsítványt mert egyszerű módszert jelentenek az adatok biztonságának megőrzésére.
Azonban Cloudflare most támogatja a HSTS funkciót. A Cloudflare webes felületén keresztül aktiválhatja az összes HSTS funkciót, beleértve az előtöltést is, anélkül, hogy a webszerver konfigurációival küszködne.
Mi az X-Frame-Options?
Az X-Frame-Options egy biztonsági fejléc, amelyet minden modern böngésző támogat. Az X-Frame-Options célja, hogy megvédje a kattintásos lopást, például a Clickjacking-et. Ahogy a neve is sugallja, egy sérülékeny belső keret, más néven iframe működéséről van szó. Ezek olyan elemek a webhelyen, amelyek egy másik HTML-oldalt ágyaznak be a „szülő” webhelyen belül, így a webhelyen más forrásokból származó tartalmat is használhat. A támadók azonban saját irányításuk alatt használják az iframe-eket, hogy olyan műveleteket hajtsanak végre, amelyeket nem akarnak.
Emiatt meg kell akadályoznia, hogy a támadók iframe-eket találjanak a webhelyen.
Hol és hogyan kell használni az X-Frame-Options-t?
Amit az X-Frame-Options csinál, azt egyes fejlesztők olyan nyelvekkel próbálják elérni, mint a JavaScript. Ez nem teljesen rossz. Azonban még mindig fennáll a kockázat, mert a sok szempontból megírt kódok nem elegendőek. Ezért bölcs dolog ezt a feladatot az Ön által használt internetböngészőre bízni.
Fejlesztőként azonban három paramétert kell tudni az X-Frame-Optionsről:
- Tagadni: Teljesen megakadályozza az oldal meghívását bármely iframe-ben.
- AZONOS EREDET: Megakadályozza, hogy a saját domainen kívül más domain hívjon az iframe-en belül.
- ALOW-FROM uri: A paraméterként megadott URI iframe-hívásainak elfogadása. Mások letiltása.
Itt, a AZONOS EREDET funkció jobban kiemelkedik. Mert bár a különböző aldomainekben lévő alkalmazásokat meghívhatja egymáson belüli iframe-ekkel, megakadályozhatja, hogy a támadó irányítása alatt a tartományon keresztül hívják meg őket.
Példák a SAMEORIGIN és az X-Frame-Options használatára NGINX, Apache és IIS rendszerekkel:
Az X-Frame-Options SAMEORIGIN használata az Nginx számára:
add_header X-Frame-Options SAMEORIGIN;
Az X-Frame-Options SAMEORIGIN használata Apache-hoz:
A fejléchez mindig csatolja az X-Frame-Options SAMEORIGIN-t
Az X-Frame-Options SAMEORIGIN használata az IIS-hez:
<http Protokoll>
<egyéni fejlécek>
<add name="X-Frame-Options" érték="AZONOS EREDET" />
</customHeaders>
</httpProtocol>
A SAMEORIGIN fejléc egyszerű hozzáadása nagyobb biztonságot nyújt látogatói számára.
Mi az X-XSS-védelem?
Az X-XSS-Protection fejlécinformációk használata megvédheti a felhasználókat az XSS-támadásoktól. Először is meg kell szüntetni XSS biztonsági rések az alkalmazás oldalán. A kódalapú biztonság biztosítása után további intézkedésekre, azaz X-XSS-Protection fejlécekre van szükség a böngészők XSS-sebezhetőségei ellen.
Az X-XSS-Protection használata
A modern böngészők az alkalmazások által generált tartalmak szűrésével képesek észlelni a potenciális XSS hasznos terheket. Ez a funkció az X-XSS-Protection fejléc információival aktiválható.
Az X-XSS-Protection fejléc engedélyezése az Nginxben:
add_header X-Frame-X-XSS-Protection 1;
Az X-XSS-Protection fejléc engedélyezése az Apache-ban:
A fejléchez mindig csatolja az X-XSS-Protection 1-et
Az X-XSS-Protection fejléc engedélyezése az IIS-ben:
<http Protokoll>
<egyéni fejlécek>
<add name="X-XSS-védelem" érték="1" />
</customHeaders>
</httpProtocol>
Ha meg szeretné akadályozni, hogy az XSS-támadást használó kódblokk alapértelmezés szerint lefusson, használhatja a következőket:
X-XSS-védelem: 1; mód=blokk
Ezt a kisebb módosítást akkor kell végrehajtani, ha potenciálisan veszélyes helyzet áll fenn, és meg akarja akadályozni, hogy minden tartalom megjelenjen.
Mi az X-Content-Type-Options?
A böngészők a webalkalmazás által számukra bemutatott tartalomról MIME-típusszaglásnak nevezett elemzést hajtanak végre. Például, ha egy PDF- vagy PNG-fájlhoz való hozzáférést kérik, a HTTP-válasz elemzését végző böngészők kikövetkeztetik a fájltípust.
Vegyünk egy jpeg kiterjesztésű fájlt, amely valójában szöveges/HTML-tartalommal rendelkezik. A feltöltési modulban a kiterjesztések használata és a védelmek átadása után a fájl sikeresen feltöltődik. A feltöltött fájlt az URL-en keresztül hívják meg, és a MIME Type sniffing a szöveget/HTML-t adja vissza. A tartalmat HTML-ként jeleníti meg. Ekkor jelentkezik az XSS sebezhetősége.
Ezért meg kell akadályoznia, hogy a böngészők a MIME-típusú szippantás alapján döntsenek a tartalomról. Ehhez használhatja a nosniff-et.
X-Content-Type-Options fejléc az Nginx számára:
add_header X-Content-Type-Options nosniff;
X-Content-Type-Options fejléc Apache-hoz:
Fejléc mindig X-Content-Type-Options nosniff
X-Content-Type-Options fejléc az IIS-hez:
<http Protokoll>
<egyéni fejlécek>
<add name="X-Content-Type-Options" érték="nosniff" />
</customHeaders>
</httpProtocol>
Mi az a HttpOnly Cookie Flag?
A webalkalmazások munkamenet-azonosítóval követik nyomon a felhasználók munkameneteit. A böngészők eltárolják ezt, és automatikusan hozzáadják minden HTTP-kéréshez a cookie hatókörén belül.
Lehetséges sütiket célból használni a munkamenetkulcs átvitelén kívül azonban. A hackerek a fent említett XSS-sebezhetőség vagy a Cross-Site Request Forgery (CSRF) támadás segítségével tudhatták meg a felhasználói adatokat. Tehát mely cookie-k a legfontosabbak a biztonság szempontjából?
Példaként tekintheti a képgalériában az utolsó képen található információkat, amelyekre kattintott. Így kisebb a HTTP forgalom, és a terhelés egy részét a felhasználó internetböngészője tudja megoldani kliensoldali szkriptekkel.
Ahol HttpOnly bejön. Az alábbiakban egy példa látható a cookie-hozzárendelésre:
Készlet-Aprósütemény: felhasználó=t=cdabe8a1c2153d726; útvonal=/; HttpOnly
Figyelje meg a HttpOnly értéket, amelyet a Set-Cookie művelet. A böngésző látni fogja ezt, és nem dolgozza fel a HttpOnly jelzővel ellátott értékeket, ha a cookie-t a document.cookie változó. A Set-Cookie folyamatban használt másik jelző a Secure flag. Ez azt jelzi, hogy a cookie értéke csak a HTTPS-kéréseknél kerül hozzáadásra a fejléchez. Az e-kereskedelmi oldalak általában azért használják, mert csökkenteni akarják a hálózati forgalmat és növelni szeretnék a teljesítményt.
Ezzel a módszerrel elrejtheti a felhasználók kritikus adatait, például felhasználóneveket, jelszavakat és hitelkártyaadatokat. De van egy probléma. A bejelentkezési folyamatot végrehajtó felhasználókhoz a Biztonságos jelző nélküli cookie-értéket rendelik. A felhasználó rendelkezhet a munkamenetkulccsal, amikor HTTP-kérést küld nem HTTPS-hivatkozásokra. A biztonságos zászló hozzáadása egyszerű:
Készlet-Aprósütemény: felhasználó=t=cdabe8a1c2153d726; útvonal=/; Biztonságos
Mikor ne használja a HttpOnly-t? Ha a Javascriptre támaszkodik, legyen óvatos, mivel ez kevésbé biztonságossá teheti webhelyét.
Kis lépések a szélesebb internetes biztonságért
A webalkalmazások biztonságának növeléséhez nincs szükség fejlett szoftver- és szerverismeretekre. Csak néhány sor megváltoztatásával megelőzhet néhány komoly támadást. Természetesen ez nem elég. Ez azonban egy kicsi, de hatékony lépés a webhely biztonsága érdekében. A tudás a legjobb megelőzés, ezért hasznos tudni, hogy a HTTPS hogyan védi az adatokat az átvitel során.
