# Weboldal biztonsági ellenőrzése egy percen belül. Weboldal biztonsági ellenőrzése kisvállalkozások oldalaihoz. Ellenőrizze a HTTPS-t, a biztonsági fejléceket, az e-mail-rekordokat és a követőket, majd töltse le a javításokat PDF-ben. ## Mire terjed ki a weboldal biztonsági ellenőrzése? A vizsgálat 28 ellenőrzést futtat a kezdőlapon. Kiterjed a HTTPS-re és az átirányításokra, a biztonsági fejlécekre, a sütikre, az e-mail- és DNS-rekordokra, a külső szkriptekre, a követőkre és az elavult könyvtárakra. Minden eredmény megmondja, mit kell javítani, mit érdemes megnézni és mit nem tudtunk ellenőrizni. ### HTTPS-kapcsolat Titkosítottan válaszol az oldal, és utasítja a böngészőket a HTTPS további használatára? ### Böngészővédelem Le tudja-e tiltani az oldal a nem kívánt szkripteket, meg tudja-e akadályozni, hogy más oldalak beágyazzák, és hogy a böngészők találgassák a fájltípusokat? ### Sütik, követők és szoftverek Ellenőrizzük a sütibeállításokat, a látogatói hozzájárulás előtt betöltődő követőket, az elavult JavaScript könyvtárakat és az oldal által elárult szoftververziókat. ## Hozzon ki többet a weboldal biztonsági ellenőrzése eredményeiből ### Mit mutat meg a weboldal biztonsági ellenőrzése? A weboldal biztonsági ellenőrzése megmutatja, milyen beállításokat küld a kezdőlap minden látogatónak. Ellenőrizzük a HTTPS-t, a biztonsági fejléceket, a sütiket, az e-mail-rekordokat, a követőket és az oldal által elárult szoftvert. A weboldal biztonsági ellenőrzése alapján kérdéseket készíthet a fejlesztőnek, és dátummal ellátott állapotot rögzíthet a változtatások előtt. ### A weboldal biztonsági ellenőrzése eredményeinek megértése A weboldal biztonsági ellenőrzése az eredményeket sürgős szolgáltatói teendőkre, javítandó beállításokra és az oldal működésétől függő döntésekre bontja. Egy hiányzó opcionális fejléc nem támadás jele. A weboldal biztonsági ellenőrzése során kapott pontszám 0 és 100 között mozog, és a sikeres ellenőrzéseket számolja. A színek megmutatják, mivel kezdjen. ### Teendők a weboldal biztonsági ellenőrzése előtt és után Mielőtt tárhelyet vagy biztonsági beállítást vált, készítsen weboldal biztonsági ellenőrzést, hogy legyen mihez viszonyítani. A szabályok szigorítása előtt nézze át a fizetési oldalakat, a bejelentkezést és a beágyazott szolgáltatásokat. Utána készítsen új ellenőrzést, vesse össze a régi jelentéssel, és tesztelje az oldalt egy valódi böngészőben. A szoftverfrissítések és a fiókbiztonság maradjanak a rendszeres karbantartás része. ### A weboldal biztonsági ellenőrzése megosztása a fejlesztővel A weboldal biztonsági ellenőrzése alapján könnyebb dolgozni, ha a munkát végző személy is látja. Töltse le a PDF-et, vagy küldje el a jelentés linkjét a fejlesztőnek. Minden jelentés mutatja, mikor készült. A weboldal tulajdonosa a jelentést közzé is teheti, miután igazolta, hogy az oldalt ő felügyeli. ## Kérdések a webhely biztonságáról ### Bizonyítja a weboldal biztonsági ellenőrzése, hogy a webhely biztonságos? Nem. A nyilvános beállítások egy körét ellenőrzi. Nem talál meg minden sérülékenységet, kártevőt, programhibát vagy feltört fiókot. Egy teljes biztonsági audit ennél jóval tovább megy. ### Befolyásolja a weboldal biztonsági ellenőrzése a webhelyet? Alig. A vizsgálat lekérdezi a DNS-rekordokat, HTTPS-en és titkosítatlan HTTP-n is lekéri a kezdőlapot, legfeljebb öt átirányítást követ, beolvassa a security.txt fájlt, és egyszer betölti a kezdőlapot egy felhős böngészőben. Más oldalakat nem nyit meg, nem küld el űrlapot, nem jelentkezik be és nem próbálkozik támadással. Ha az oldal blokkolja a vizsgálatot, az eredmény hiányos lesz. ### Miért csak napi két alkalommal végezhető a weboldal biztonsági ellenőrzése? A korlát miatt maradhat ingyenes az eszköz, és így nem terheljük feleslegesen a weboldalakat. ### Mit jelentenek a weboldal biztonsági ellenőrzése színei? A piros azt jelenti, hogy a tárhelyszolgáltatónak sürgősen ellenőriznie kell valamit, például egy ismert kritikus hibával érintett régi PHP verziót. A narancs azt jelenti, hogy egy beállítást javítani kell. A kék azt jelenti, hogy érdemes közelebbről megnézni. A zöld azt jelenti, hogy az ellenőrzés rendben van. A szürke azt jelenti, hogy nem tudtuk ellenőrizni. Egyik szín sem jelenti azt, hogy az oldalt feltörték. ### Felismeri a weboldal biztonsági ellenőrzése a PHP2Shell problémát? Jelezni tud egy olyan PHP verziót, amely régebbi a javított kiadásoknál. A verziót jelző fejléc lehet hibás, rejtett vagy módosított, és egyes szolgáltatók a régebbi verziókat is javítják. Kérje meg a tárhelyszolgáltatót, hogy erősítse meg a telepített PHP verziót és a javításokat. Soha nem küldünk támadó kéréseket. Ha nincs PHP fejléc, az nem jelenti azt, hogy nincs PHP, vagy hogy javítva van. ### Miért jelez szoftverfejléceket a weboldal biztonsági ellenőrzése? A verziószámok megkönnyítik a sérülékeny szoftvert futtató oldalak megtalálását. Ahol lehet, távolítsa el őket. Az elrejtés semmit sem javít ki, ezért magát a szoftvert tartsa naprakészen. ### Mi a teendő a weboldal biztonsági ellenőrzése után? Kezdje a piros tételekkel, majd a narancssárgákat nézze át a fejlesztővel vagy a tárhelyszolgáltatóval. Élesítés előtt tesztelje a fejlécmódosításokat, mert a szigorú szabályok elronthatják a fizetést, az űrlapokat és a beágyazott tartalmakat. Töltse le a PDF-et, hogy megoszthassa az eredményeket. A Mecanik Dev segít kiválasztani a megfelelő javításokat, és el is végzi a munkát. ### Nyilvánosak a weboldal biztonsági ellenőrzése eredményei? Nem. A vizsgálatok privátak. Csak a weboldal tulajdonosa teheti közzé a jelentését, miután DNS-rekorddal vagy fájllal igazolta, hogy az oldalt ő felügyeli. Privát linket vagy a PDF-et ettől függetlenül megoszthat. Fiók vagy e-mail nem szükséges. ## A jelentés ellenőrzései ### Titkosított kapcsolat A HTTPS titkosítja az adatokat az oldal és a látogatók között. Ez azt mutatja, hogy a szkenner biztonságosan kapcsolódott. Az oldal többi részét ez nem teszteli. ### Titkosítatlan HTTP átirányítása HTTPS-re Aki https:// nélkül írja be a címet, azt azonnal a biztonságos oldalra kell küldeni. Ezután a HSTS a böngészőt HTTPS-en tartja. ### A látogatók maradjanak HTTPS-en Állítsa be a Strict-Transport-Security fejlécet legalább hat hónapos max-age értékkel. Az includeSubDomains vagy a preload hozzáadása előtt ellenőrizze az aldomaineket. ### A futtatható tartalmak korlátozása A Content-Security-Policy szabályozza, milyen szkripteket és tartalmakat tölthet be az oldal. A megfelelő szabályok az oldaltól függnek, és a hiányzó szabály önmagában nem sérülékenység. Ha az oldal a HTML-ben adja meg a szabályt, a böngészős ellenőrzés azt is beolvassa. A report-only szabályok semmit sem tiltanak. ### Megtévesztő beágyazások megakadályozása Használja a CSP frame-ancestors vagy az X-Frame-Options beállítást, és csak azokat az oldalakat engedje, amelyeknek tényleg be kell ágyazniuk az Önét. ### A fájltípus-találgatás leállítása Állítsa az X-Content-Type-Options értékét nosniff-re, hogy a böngészők minden fájlt a szerver által megadott típusként kezeljenek. ### A továbbított információk korlátozása Egy kifejezett Referrer-Policy egyértelművé teszi a működést. A modern böngészők alapból is korlátozzák ezt, így a hiányzó fejléc nem jelenti azt, hogy adat szivárog. ### Az érzékeny böngészőfunkciók korlátozása A Permissions-Policy kikapcsolhatja a kamerát, a mikrofont és a helymeghatározást az oldalon. A megfelelő beállítás attól függ, mit csinál az oldal. ### X-Powered-By-adatok Ahol lehet, távolítsa el a futtatókörnyezet adatait. Így nehezebb felismerni a szoftvert, de a frissítésekre ugyanúgy szükség van. ### Nyilvános kiszolgálóverzió Kérje meg a tárhelyszolgáltatót, hogy rejtse el a verziószámokat, és tartsa frissen a szervert. Egy verzió nélküli szervernév rendben van. ### PHP-javítások ellenőrzése A PHP2Shell két kritikus hiba neve magában a PHP-ben. A fejléc csak egy verziót jelez, amely lehet hibás, vagy nem mutatja a szolgáltató által telepített javításokat. Kérje meg a szolgáltatót, hogy vesse össze a telepített verziót a friss PHP biztonsági közleményekkel. A fejléc elrejtése semmit sem javít. ### Sütik csak HTTPS-en A Secure azt jelenti, hogy a süti csak HTTPS-en megy át. Csak a kezdőlap válaszában beállított sütiket látjuk. A bejelentkezés után vagy szkriptekből beállított sütik nem tartoznak ide, és a sütik értéke soha nem kerül a jelentésbe. ### Munkamenetsütik védelme A HttpOnly megakadályozza, hogy az oldal szkriptjei kiolvassák a sütit. A munkamenet-sütiket a nevük alapján ismerjük fel, ezért kérje meg a fejlesztőt, hogy erősítse meg. ### Webhelyek közötti sütiszabályok A SameSite szabályozza, mikor mennek a sütik más oldalakról érkező kérésekkel. Egyes integrációknál a None a helyes, és ha hiányzik, a böngészők alapértéket használnak. ### Más eredetű hozzáférés API-khoz és megosztott fájlokhoz gyakran szükség van CORS-ra. Egy helyettesítő karakter önmagában nem tesz közzé privát adatot. Ez a kezdőlap-ellenőrzés nem tudja megállapítani, hogy egy API bármilyen eredetben megbízik-e. ### Böngészőablakok elkülönítése A COOP elválasztja az oldalt a más oldalak által megnyitott ablakoktól. A fizetési és bejelentkezési felugró ablakokhoz lazább beállítás kellhet. A hiánya önmagában nem teszi támadhatóvá az oldalt. ### Erőforrások beágyazása A Cross-Origin-Resource-Policy szabályozza, mely oldalak ágyazhatják be a fájljait. A nyilvános képeknek és megosztott fájloknak nyitva kellhet maradniuk. A legtöbb oldalnak nincs rá szüksége. ### E-mail küldési szabály (SPF) Az SPF segít a levelezőszervereknek elutasítani a domain nevében küldött hamis leveleket. Ha a domain soha nem küld e-mailt, tegye közzé a v=spf1 -all rekordot. A fő domaint ellenőrizzük. ### E-mail hamisítás elleni szabály (DMARC) A DMARC megmondja a levelezőszervereknek, mit tegyenek az SPF és DKIM ellenőrzésen elbukó levelekkel. Kezdje megfigyelő módban, olvassa el a jelentéseket, majd váltson quarantine vagy reject beállításra. ### Tanúsítványkiadói szabályok (CAA) A CAA rekordok felsorolják, mely tanúsítványkiadók adhatnak ki tanúsítványt a domainhez. Csökkentik a tévedésből kiadott tanúsítvány kockázatát. Minden használt szolgáltatót vegyen fel. ### Aláírt DNS (DNSSEC) A DNSSEC segítségével a feloldók kiszűrik a hamis DNS válaszokat. A DNS szolgáltatónál és a regisztrátornál együtt kapcsolja be, mert a hibás beállítás elérhetetlenné teheti a domaint. ### Biztonsági kapcsolattartó (security.txt) Tegye közzé a /.well-known/security.txt fájlt Contact és Expires mezővel, hogy aki hibát talál, tudja, hogyan érheti el. ### Nem biztonságos oldalelemek A nem biztonságos fájlokat útközben módosíthatják, a böngészők pedig blokkolhatják őket, ami elrontja az oldalt. Állítsa át ezeket a címeket HTTPS-re. Csak a kezdőlapot ellenőriztük. ### Külső szolgáltatások Minden külső szkript vagy szolgáltatás látja a látogatókat, és módosíthatja az oldalt. Tartsa rövidre a listát, távolítsa el, amit már nem használ, és nézze meg, mit kapnak az egyes szolgáltatók. A külső szolgáltatások használata önmagában nem sérülékenység. ### Követés hozzájárulás előtt Az adatvédelmi szabályok, például a GDPR, általában hozzájárulást kérnek a nem szükséges követés előtt. A szkenner egyszer tölti be az oldalt a mi szervereinkről, és semmit sem fogad el. A hozzájáruláskezelők országonként másként működhetnek, ezért a saját beállítását is ellenőrizze. ### Elavult JavaScript könyvtárak Felismerjük a jQuery, jQuery UI, Bootstrap, AngularJS, Lodash és Moment.js könyvtárakat, ha mutatják a verziójukat. Frissítse az érintett könyvtárat, vagy az azt tartalmazó sablont vagy bővítményt, majd tesztelje az oldalt. ### Szkriptek integritásellenőrzése A Subresource Integrity lehetővé teszi, hogy a böngésző elutasítsa egy szkriptfájl módosított példányát. Verziózott CDN fájloknál működik. Nem való szándékosan változó szkriptekhez, például címkekezelőkhöz. ### A weboldal platformjának verziója A verziószámot tartalmazó generator címke könnyebb célponttá teszi az oldalt az automatizált támadásoknak. Ahol lehet, távolítsa el, és tartsa frissen a platformot, a sablonokat és a bővítményeket. A verzió elrejtése semmit sem javít. ## Adatvédelmi tájékoztató A visszaélések megelőzése, valamint a panaszok és jogi megkeresések megválaszolása érdekében a Mecanik Dev Ltd minden vizsgálatról nyilvántartást vezet. Ebben szerepel a weboldal, az időpont, a tájékoztató verziója, az Ön IP-címe, a böngészőjének és eszközének adatai, valamint az IP-címe alapján megállapított hozzávetőleges tartózkodási helye. Ezeket a bejegyzéseket 30 napig őrizzük, utána töröljük. Marketingre nem használjuk őket, és csak akkor adjuk át, ha a jog ezt előírja. A tárhely- és biztonsági szolgáltatónk az IP-címét a szolgáltatás és a robotok elleni ellenőrzés működtetéséhez kezeli, és saját naplókat vezet. A vizsgálathoz adott engedély nem jelent hozzájárulást marketinghez. A PDF-et az Ön böngészője készíti el. Az adatkezelő elérhetőségét, az adatvédelmi jogokat és a szolgáltatók adatait a fő adatvédelmi tájékoztató tartalmazza. Ha közzétesz egy jelentést, a domaint, a vizsgálat idejét és az eredményeket legfeljebb 90 napig tároljuk. A nyilvános jegyzék minden weboldalnál a legfrissebb jelentést mutatja. A privát vizsgálatok soha nem kerülnek ide. A korábbi nyilvános jelentések a lejáratukig vagy eltávolításukig elérhetők maradnak. A nyilvános jelentések soha nem tartalmazzák a látogatók IP-címét, böngészőadatait, engedélyezési adatait vagy sütiértékeit. A témaválasztást a böngésző tárolja. Az aktuális jelentés a lap munkamenettárában marad, így nyelvváltáskor nem kell új vizsgálat. A mentett beállításokat és eredményeket a böngésző tárhelyének törlésével távolíthatja el.