9 biztonsági tipp, amelyek megvédik webhelyét a hackerek ellen

Lehet, hogy nem gondolja, hogy webhelyén van valami, amiért feltörnék, de a webhelyek folyamatosan veszélyeztetettek. A webhely biztonsági megsértéseinek többsége nem az, hogy ellopja az adatait, vagy hogy összevissza keverje az adatait weboldal elrendezése , de ehelyett megkísérli szerverét levélszemétként továbbítani spamként, vagy ideiglenes webszervert állít fel, általában illegális természetű fájlok kiszolgálására. A veszélyeztetett gépekkel való visszaélés másik nagyon gyakori módja a szerverek botnet részeként történő felhasználása, vagy a Bitcoins bányászata. Akár ransomware is eltalálhatja.

A hackelést rendszeresen automatizált szkriptek végzik, amelyek az internet feltérképezésére szolgálnak, és megpróbálják kiaknázni az ismert webhelybiztonsági problémákat a szoftverekben. Itt van a kilenc legfontosabb tipp, amelyek segítenek Ön és webhelye online biztonságában.

01. Tartsa naprakészen a szoftvert

Nyilvánvalónak tűnhet, de az, hogy az összes szoftvert naprakészen tartsa, elengedhetetlen a webhely biztonságának megőrzéséhez. Ez vonatkozik a kiszolgáló operációs rendszerére és az Ön webhelyén esetlegesen futtatott szoftverekre, például egy CMS-re vagy fórumra. Amikor a webhely biztonsági réseit találja a szoftverekben, a hackerek gyorsan megpróbálnak visszaélni velük.



Ha felügyelt tárhelymegoldást használ, akkor nem kell annyira aggódnia az operációs rendszer biztonsági frissítései miatt, mivel a tárhelytársaságnak gondoskodnia kell erről.

Ha webhelyén harmadik féltől származó szoftvert használ, például CMS-t vagy fórumot, győződjön meg arról, hogy gyorsan alkalmazza a biztonsági javításokat. A legtöbb gyártó rendelkezik levelezőlistával vagy RSS-hírcsatornával, amely részletezi a webhely biztonsági kérdéseit. WordPress , Umbraco és sok más CMS bejelentkezésekor értesíti az elérhető rendszerfrissítésekről.

Számos fejlesztő olyan eszközöket használ, mint a Composer, az npm vagy a RubyGems a szoftveres függőségek kezelésére, és a biztonsági rések, amelyek egy olyan csomagban jelennek meg, amelyre függ, de nem figyel oda, az egyik legegyszerűbb módja a kiakadásnak. Győződjön meg arról, hogy naprakészen tartja függőségeit, és használjon hasonló eszközöket Gemnasium automatikus értesítéseket kap, ha az egyik összetevőnél biztonsági rést jelentenek be.

02. Vigyázzon az SQL injekcióra

Az SQL injekciós támadások akkor fordulnak elő, amikor a támadó webes űrlapmezőt vagy URL-paramétert használ az adatbázis eléréséhez vagy manipulálásához. Ha a szokásos Transact SQL-t használja, könnyen tudatlanul beilleszthet egy olyan kódot a lekérdezésébe, amely táblák megváltoztatásához, információk megszerzéséhez és adatok törléséhez használható. Ezt könnyedén megakadályozhatja, ha mindig paraméterezett lekérdezéseket használ, a legtöbb webnyelv rendelkezik ezzel a funkcióval, és könnyen megvalósítható.

Vegye figyelembe ezt a lekérdezést:

'SELECT * FROM table WHERE column = '' + parameter + '';'

Ha a támadó megváltoztatta az URL paramétert, hogy átadja az 'vagy' 1 '=' 1 értéket, akkor a lekérdezés így néz ki:

'SELECT * FROM table WHERE column = '' OR '1'='1';'

Mivel az „1” egyenlő az „1” értékkel, ez lehetővé teszi a támadó számára, hogy további lekérdezést adjon az SQL utasítás végéhez, amelyet szintén végrehajtanak.

Javíthatja ezt a lekérdezést azáltal, hogy kifejezetten paraméterezi. Például, ha a MySQLi-t használja a PHP-ben, ennek a következõvé kell válnia:

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value'); $stmt->execute(array('value' => $parameter));

03. Védelem az XSS támadások ellen

A webhelyek közötti parancsfájlok (XSS) támadásai rosszindulatú JavaScriptet injektálnak az oldalaiba, amelyek ezután a felhasználók böngészőiben futnak, és megváltoztathatják az oldal tartalmát, vagy információkat lophatnak el, hogy visszaküldjék a támadónak. Például, ha érvényesítés nélkül mutatsz megjegyzéseket egy oldalon, akkor a támadó szkriptcímkéket és JavaScriptet tartalmazó megjegyzéseket küldhet be, amelyek minden más felhasználó böngészőjében futtathatók, és ellophatják a bejelentkezési cookie-kat, így a támadás átveheti az összes felhasználó fiókjának irányítását. felhasználó, aki megnézte a megjegyzést. Gondoskodnia kell arról, hogy a felhasználók ne tudjanak aktív JavaScript-tartalmat injektálni az oldalaiba.

Ez különös aggodalomra ad okot a modern webalkalmazásokban, ahol az oldalak ma elsősorban felhasználói tartalmakból épülnek fel, és amelyek sok esetben HTML-t generálnak, amelyet aztán az olyan front-end keretrendszerek is értelmeznek, mint az Angular és az Ember. Ezek a keretrendszerek sok XSS-védelmet nyújtanak, de a kiszolgáló és az ügyfél renderelésének keverése új és bonyolultabb támadási lehetőségeket is teremt: nemcsak a HTML-be történő hatékony injektálás a HTML-be, hanem az Angular direktívák beillesztésével vagy az Ember használatával is futtathat olyan kódot futtató tartalmat. segítők.

A legfontosabb itt arra összpontosítani, hogy a felhasználók által létrehozott tartalom elkerülhesse az elvárt határokat, és a böngésző másként értelmezze, mint amit szándékozott. Ez hasonló az SQL injekció elleni védekezéshez. HTML dinamikus előállításakor használjon olyan funkciókat, amelyek kifejezetten végrehajtják a keresett változtatásokat (pl. Használja az element.setAttribute és az element.textContent elemeket, amelyeket a böngésző automatikusan elkerül, nem pedig az element.innerHTML beállítását kézzel), vagy használjon függvényeket a sabloneszközben, amelyek automatikusan elvégzik a megfelelő menekülést, ahelyett, hogy összefűznék a karakterláncokat vagy beállítanák a nyers HTML-tartalmat.

Az XSS defender eszköztárának másik hatékony eszköze a Tartalombiztonsági irányelv (CSP). A CSP egy fejléc, amelyet a szerver visszaadhat, amely megmondja a böngészőnek, hogy korlátozza az oldalon végrehajtott JavaScript módját és módját, például hogy tiltsa le a szkriptek futtatását, amelyeket nem a domainje üzemeltet, tiltsa le az inline JavaScript parancsot, vagy tiltsa le az eval () parancsot. A Mozillának van kiváló útmutató néhány példakonfigurációval. Ez megnehezíti a támadó szkriptjeinek működését, még akkor is, ha be tudják vinni őket az oldalára.

04. Vigyázni kell a hibaüzenetekkel

Vigyázzon azzal, hogy mennyi információt ad el a hibaüzeneteiben. Csak minimális hibákat adjon meg felhasználóinak, hogy ne szivárogjanak ki a szerverén található titkok (pl. API kulcsok vagy adatbázis jelszavak). Ne adjon meg teljes részleteket sem, mivel ezek az SQL-injekcióhoz hasonló összetett támadásokat sokkal könnyebbé tehetik. Tartson részletes hibákat a kiszolgáló naplóiban, és csak a szükséges információkat jelenítse meg a felhasználók számára.

05. Validálja mindkét oldalon

Az érvényesítést mindig a böngésző és a szerver oldalán egyaránt el kell végezni. A böngésző olyan egyszerű hibákat képes felfogni, mint a kötelezően kitöltendő mezők, amelyek üresek, és amikor szöveget ír be a csak számok mezőbe. Ezek azonban megkerülhetők, és mindenképpen ellenőrizze ezeket az érvényesítéseket és a mélyebb érvényesítési kiszolgálói oldalakat, mivel ennek elmulasztása rosszindulatú kódok vagy parancsfájlok kódjának az adatbázisba történő beillesztéséhez vagy nemkívánatos eredményekhez vezethet a webhelyén.

06. Ellenőrizze a jelszavakat

Mindenki tudja, hogy bonyolult jelszavakat kell használnia, de ez nem azt jelenti, hogy mindig használják. Alapvető fontosságú, hogy erős jelszavakat használjon a kiszolgálón és a webhely adminisztrációs területén, de ugyanilyen fontos ragaszkodni a jó jelszó gyakorlatokhoz a felhasználók számára a fiókjuk biztonságának védelme érdekében.

Bármennyire sem tetszik a felhasználóknak, a jelszókövetelmények, például legalább körülbelül nyolc karakter, beleértve a nagybetűt és a számot, kikényszerítése hosszú távon védi az adataikat.

A jelszavakat mindig titkosított értékként kell tárolni, lehetőleg egyirányú hash algoritmust használva, például SHA-t. A módszer használata azt jelenti, hogy amikor hitelesíti a felhasználókat, akkor csak titkosított értékeket hasonlít össze. A webhelyek extra biztonsága érdekében célszerű a jelszavakat sózni, jelszavanként új sót használva.

Abban az esetben, ha valaki feltörné és ellopná a jelszavakat, a kivonatolt jelszavak használata károsíthatja a korlátozást, mivel azok visszafejtése nem lehetséges. A legjobb, amit valaki tehet, egy szótári támadás vagy brutális erőszakos támadás, lényegében minden kombinációt kitalál, amíg talál egyezést. Sózott jelszavak használata esetén a nagyszámú jelszó feltörése még lassabb, mivel minden találgatást külön kell kivonatolni minden só + jelszóért, ami számítási szempontból nagyon drága.

Szerencsére sok CMS biztosítja a felhasználói kezelést a dobozból, sok beépített webhelybiztonsági funkcióval, bár bizonyos konfigurációkra vagy extra modulokra lehet szükség a sózott jelszavak használatához (a Drupal 7 előtti verzió) vagy a minimális jelszóerősség beállításához. Ha .NET-et használ, akkor érdemes tagsági szolgáltatókat használni, mivel azok nagyon konfigurálhatók, biztosítják a beépített webhely biztonságát, és tartalmazzák az elkészített vezérlőket a bejelentkezéshez és a jelszó visszaállításához.

07. Kerülje a fájlok feltöltését

Ha a felhasználóknak feltöltenek fájlokat az Ön webhelyére, akkor ez nagy kockázatot jelenthet a webhely biztonságára, még akkor is, ha egyszerűen csak az avatarjukat kell megváltoztatni. A kockázat az, hogy minden feltöltött fájl, bármennyire is ártatlannak tűnik, tartalmazhat egy szkriptet, amely a szerveren végrehajtva teljesen megnyitja a webhelyet.

Ha rendelkezik fájlfeltöltési űrlappal, akkor az összes fájlt nagy gyanakvással kell kezelnie. Ha engedélyezi a felhasználók számára képek feltöltését, akkor nem támaszkodhat a fájlkiterjesztésre vagy a mime típusra annak igazolására, hogy a fájl kép, mivel ezeket könnyen el lehet hamisítani. Még a fájl megnyitása és a fejléc elolvasása, vagy a képméret ellenőrzésére szolgáló funkciók használata sem hibátlan. A legtöbb képformátum lehetővé teszi olyan megjegyzésrész tárolását, amely tartalmazhat PHP-kódot, amelyet a szerver futtathat.

Tehát mit tehet ennek megakadályozása érdekében? Végül meg akarja akadályozni a felhasználókat abban, hogy bármilyen feltöltött fájlt végrehajtsanak. Alapértelmezés szerint a webszerverek nem próbálják meg kiterjesztésű fájlokat végrehajtani, de ne csak a fájlkiterjesztés ellenőrzésére támaszkodjanak, mivel ismert, hogy az image.jpg.php nevű fájl átjut.

Néhány lehetőség a fájl átnevezése a feltöltéskor a megfelelő fájlkiterjesztés biztosítása érdekében, vagy a fájlengedélyek megváltoztatása, például a chmod 0666, így nem lehet végrehajtani. A * nix használata esetén létrehozhat egy .htaccess fájlt (lásd alább), amely csak a korábban említett kettős kiterjesztéses támadást megakadályozó beállított fájlokhoz enged hozzáférést.

deny from all order deny,allow allow from all

Végül az ajánlott megoldás a feltöltött fájlokhoz való közvetlen hozzáférés megakadályozása. Így a webhelyére feltöltött fájlok a webgyökéren kívüli mappában vagy az adatbázisban találhatók blobként. Ha a fájljai nem érhetők el közvetlenül, létre kell hoznia egy szkriptet, amely a fájlokat a privát mappából (vagy a .NET HTTP kezelőjéből) szeretné lekérni, és eljuttatná a böngészőbe. A képcímkék olyan src attribútumot támogatnak, amely nem egy kép közvetlen URL-je, így az src attribútum a fájl kézbesítési szkriptre mutathat, ha a HTTP fejlécben beállítja a megfelelő tartalomtípust. Például:

A legtöbb tárhelyszolgáltató a szerver konfigurációjával foglalkozik az Ön számára, de ha saját webhelyén tárolja webhelyét, akkor néhány dolgot ellenőrizni szeretne.

Győződjön meg róla, hogy tűzfalbe van állítva, és blokkolja az összes nem alapvető portot. Ha lehetséges, állítson be egy DMZ-t (demilitarizált zóna), amely csak a 80-as és a 443-as porthoz enged hozzáférést a külvilágtól. Bár ez nem biztos, hogy lehetséges, ha nincs hozzáférése a szerveréhez belső hálózatból, mivel a fájlok feltöltésének engedélyezéséhez és a távoli bejelentkezéshez a szerverre SSH vagy RDP használatával portokat kell nyitnia.

Ha engedélyezi a fájlok feltöltését az internetről, csak biztonságos továbbítási módszereket használjon a szerverére, például SFTP vagy SSH.

Ha lehetséges, az adatbázisát a webkiszolgálótól eltérő kiszolgálón futtassa. Ez azt jelenti, hogy az adatbázis-kiszolgálóhoz nem lehet közvetlenül hozzáférni a külvilágtól, csak a webszerver férhet hozzá, minimalizálva az adatok kitettségének kockázatát.

Végül ne feledkezzünk meg a szerverhez való fizikai hozzáférés korlátozásáról.

08. Használja a HTTPS-t

A HTTPS egy olyan protokoll, amelyet az internet biztonságának biztosítására használnak. A HTTPS garantálja, hogy a felhasználók az elvárt kiszolgálóval beszélnek, és hogy senki más nem tudja elfogni vagy megváltoztatni a szállítás közben látott tartalmat.

Ha bármi van, amelyet a felhasználók privátnak szeretnének, akkor nagyon tanácsos csak HTTPS-t használni a szállításhoz. Ez természetesen hitelkártya és bejelentkezési oldalakat (és az általuk benyújtott URL-eket) jelent, de általában sokkal többet a webhelyén is. A bejelentkezési űrlap gyakran beállít egy cookie-t, amelyet minden más kéréssel együtt elküld a webhelyére, amelyet egy bejelentkezett felhasználó küld, és arra szolgál, hogy hitelesítse ezeket a kéréseket. Az ezt ellopó támadó tökéletesen utánozhat egy felhasználót és átveheti a bejelentkezési munkamenetét. Az ilyen típusú támadások legyőzéséhez szinte mindig a teljes webhelyén szeretné használni a HTTPS-t.

Ez már nem olyan trükkös vagy drága, mint egykor volt. Titkosítsuk teljesen ingyenes és automatizált tanúsítványokat biztosít, amelyekre szükséged lesz a HTTPS engedélyezéséhez, és létező közösségi eszközök állnak rendelkezésre a közös platformok és keretrendszerek széles köréhez, hogy ezt automatikusan beállítsák az Ön számára.

Nevezetesen a Google bejelentette, hogy növelni fogják Önt a keresési rangsorban, ha HTTPS-t használ, és ez SEO-előnyt is jelent. A nem biztonságos HTTP kiutazáson van, és itt az ideje a frissítésnek.

Már mindenhol használja a HTTPS-t? Menjen tovább, és nézze meg a HTTP szigorú szállítási biztonság (HSTS) beállítását, amely egy egyszerű fejléc, amelyet hozzáadhat a szerver válaszaihoz, hogy megakadályozza a nem biztonságos HTTP-t az egész tartományban.

09. Szerezzen be webhely-biztonsági eszközöket

Ha úgy gondolja, hogy mindent megtett, akkor ideje tesztelni a webhely biztonságát. Ennek leghatékonyabb módja néhány webhelybiztonsági eszköz használata, amelyeket gyakran penetrációs tesztnek vagy röviden tolltesztnek neveznek.

Számos kereskedelmi és ingyenes termék kínál segítséget ebben. A hackerek szkriptjeihez hasonló alapon működnek, mivel minden ismert kiaknázást kipróbálnak, és az előzőekben említett módszerek, például az SQL Injection segítségével megpróbálják megsérteni a webhelyet.

Néhány ingyenes eszköz, amelyet érdemes megnézni:

  • Netsparker (Ingyenes közösségi és próbaverzió elérhető). Jó az SQL injekció és az XSS teszteléséhez
  • OpenVAS Azt állítja, hogy a legfejlettebb nyílt forráskódú biztonsági szkenner. Jó az ismert sebezhetőségek tesztelésére, jelenleg több mint 25 000 vizsgálatot végez. De nehezen lehet beállítani, és OpenVAS szervert kell telepíteni, amely csak * nix rendszeren fut. Az OpenVAS egy Nessus villája, mielőtt zárt forráskódú kereskedelmi termék lett belőle.
  • SecurityHeaders.io (ingyenes online csekk). Eszköz, amellyel gyorsan be lehet jelenteni, hogy a tartomány mely fent említett biztonsági fejléceket (például CSP és HSTS) engedélyezte és helyesen konfigurálta.
  • Xenotix XSS Exploit Framework Az OWASP (Open Web Application Security Project) eszköze, amely hatalmas választékot tartalmaz az XSS támadási példák közül, amelyek segítségével gyorsan ellenőrizheti, hogy webhelyének bemenetei sérülékenyek-e a Chrome-ban, a Firefoxban és az IE-ben.

Az automatizált tesztek eredményei ijesztőek lehetnek, mivel rengeteg potenciális problémát vetnek fel. A legfontosabb az, hogy először a kritikus kérdésekre összpontosítsunk. Minden jelentett probléma általában jól magyarázza a lehetséges sebezhetőséget. Valószínűleg azt fogja tapasztalni, hogy a közepes / alacsony problémák némelyike ​​nem foglalkoztatja webhelyét.

Néhány további lépést megtehet, hogy manuálisan megkísérelje veszélyeztetni a webhelyet a POST / GET értékek megváltoztatásával. A hibakereső proxy segítséget nyújthat itt, mivel lehetővé teszi a HTTP-kérés értékeinek elfogását a böngésző és a szerver között. A népszerű ingyenes szoftver nevű alkalmazás Hegedűs jó kiindulópont.

Tehát mit kéne próbálnia megváltoztatni a kérésre? Ha olyan oldalai vannak, amelyeket csak egy bejelentkezett felhasználó láthat, próbálja meg megváltoztatni az URL-paramétereket, például a felhasználói azonosítót vagy a cookie-értékeket, és megpróbálja megtekinteni egy másik felhasználó adatait. Egy másik tesztelésre érdemes terület az űrlapok, a POST-értékek megváltoztatása, hogy megpróbáljanak kódot küldeni az XSS végrehajtására, vagy egy szerveroldali szkript feltöltése.

Kapcsolódó cikkek: