9 sigurnosnih savjeta za zaštitu web stranice od hakera

Možda ne mislite da vaša web stranica sadrži bilo što zbog čega se vrijedi hakirati, ali web mjesta su stalno ugrožena. Većina kršenja sigurnosti web mjesta nije krađa vaših podataka ili petljanje s vašim izgled web stranice , ali umjesto toga pokušava vaš poslužitelj koristiti kao relej e-pošte za neželjenu poštu ili za postavljanje privremenog web poslužitelja, obično za posluživanje datoteka ilegalne prirode. Ostali vrlo uobičajeni načini zlouporabe kompromitiranih strojeva uključuju upotrebu vaših poslužitelja kao dijela botneta ili iskopavanje Bitcoina. Čak bi vas mogao pogoditi i ransomware.

Hakiranje se redovito izvodi pomoću automatiziranih skripti napisanih za pretraživanje interneta u pokušaju iskorištavanja poznatih sigurnosnih problema na web mjestu u softveru. Evo naših devet najboljih savjeta koji pomažu da vi i vaša web lokacija budete sigurni na mreži.



01. Redovito ažurirajte softver

Možda se čini očitim, ali osiguravanje redovitog ažuriranja softvera od vitalne je važnosti za zaštitu web mjesta. To se odnosi i na operativni sustav poslužitelja i na bilo koji softver koji pokrećete na svojoj web stranici, poput CMS-a ili foruma. Kada se u softveru pronađu sigurnosne rupe na web mjestu, hakeri ih brzo pokušaju zloupotrijebiti.



Ako koristite rješenje za upravljani hosting, ne trebate se toliko brinuti oko primjene sigurnosnih ažuriranja za operativni sustav, jer bi se tvrtka za hosting trebala pobrinuti za to.

Ako na svom web mjestu koristite softver treće strane, poput CMS-a ili foruma, trebali biste osigurati brzu primjenu sigurnosnih zakrpa. Većina dobavljača ima popis e-pošte ili RSS feed koji detaljno opisuje bilo kakve sigurnosne probleme web mjesta. WordPress , Umbraco i mnogi drugi CMSovi obavještavaju vas o dostupnim ažuriranjima sustava kada se prijavite.



Mnogi programeri koriste alate poput Composer, npm ili RubyGems za upravljanje softverskim ovisnostima, a sigurnosne ranjivosti koje se pojavljuju u paketu o kojem ovisite, ali na koji ne obraćate pažnju, jedan su od najlakših načina da vas uhvate. Obavezno ažurirajte svoje ovisnosti i koristite alate poput Gimnazija da biste dobili automatske obavijesti kad se najavi ranjivost u jednoj od vaših komponenata.

02. Pripazite na ubrizgavanje SQL-a

Napadi SQL ubrizgavanja su kada napadač koristi polje web obrasca ili parametar URL za dobivanje pristupa vašoj bazi podataka ili manipuliranje njom. Kada upotrebljavate standardni Transact SQL, lako ćete nesvjesno u svoj upit unijeti nevaljali kôd koji bi se mogao koristiti za promjenu tablica, dobivanje informacija i brisanje podataka. To možete lako spriječiti uvijek koristeći parametrizirane upite, većina web jezika ima ovu značajku i jednostavna je za implementaciju.

Razmotrite ovaj upit:



kako instalirati Adobe Premiere Pro -
'SELECT * FROM table WHERE column = '' + parameter + '';'

Ako je napadač promijenio parametar URL-a kako bi ušao u 'ili' 1 '=' 1, to će uzrokovati da upit izgleda ovako:

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

Budući da je '1' jednako '1', to će omogućiti napadaču da doda dodatni upit na kraj SQL izraza koji će se također izvršiti.

Ovaj biste upit mogli popraviti izričitim parametriziranjem. Na primjer, ako koristite MySQLi u PHP-u, ovo bi trebalo postati:

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

03. Zaštitite se od XSS napada

Napadi skriptiranjem na više web lokacija (XSS) ubrizgavaju zlonamjerni JavaScript u vaše stranice, koji se zatim pokreće u preglednicima vaših korisnika, a može promijeniti sadržaj stranice ili ukrasti podatke kako bi ih vratio napadaču. Na primjer, ako na stranici prikazujete komentare bez provjere valjanosti, tada bi napadač mogao poslati komentare koji sadrže oznake skripti i JavaScript, koji bi se mogli pokretati u pregledniku svakog drugog korisnika i krasti njihov kolačić za prijavu, što omogućava napadu da preuzme kontrolu nad svakim računom korisnik koji je pogledao komentar. Morate osigurati da korisnici ne mogu ubrizgati aktivni JavaScript sadržaj na vaše stranice.

To je posebno zabrinjavajuće u modernim web aplikacijama, gdje se stranice sada grade prvenstveno od korisničkog sadržaja, a koje u mnogim slučajevima generiraju HTML koji se zatim tumači i preko front-end okvira poput Angular i Ember. Ti okviri pružaju mnogo XSS zaštite, ali miješanje generiranja poslužitelja i klijenta stvara i nove i složenije načine napada: ne samo da je ubrizgavanje JavaScript-a u HTML učinkovito, već možete ubrizgati i sadržaj koji će pokretati kôd umetanjem Angularnih direktiva ili upotrebom Ember-a pomagači.

Ključno je ovdje usredotočiti se na to kako bi vaš korisnički generirani sadržaj mogao izaći izvan granica koje očekujete, a preglednik ga protumačio kao nešto drugo od onoga što ste namjeravali. Ovo je slično obrani od ubrizgavanja SQL-a. Kada dinamički generirate HTML, koristite funkcije koje izričito vrše promjene koje tražite (npr. Koristite element.setAttribute i element.textContent, koje će preglednik automatski izbjeći, umjesto ručnog postavljanja element.innerHTML) ili upotrijebite funkcije u vašem alatu za predloške koji automatski izvršava odgovarajuće izbjegavanje, umjesto spajanja nizova ili postavljanja sirovog HTML sadržaja.

Još jedan moćan alat u alatu XSS branitelja je Politika sigurnosti sadržaja (CSP). CSP je zaglavlje koje vaš poslužitelj može vratiti, a koje govori pregledniku da ograniči kako i koji se JavaScript izvršava na stranici, na primjer da onemogući pokretanje svih skripti koje nisu hostirane na vašoj domeni, onemogući ugrađeni JavaScript ili onemogući eval (). Mozilla ima izvrstan vodič s nekim primjerima konfiguracija. To otežava rad skripti napadača, čak i ako ih može ući na vašu stranicu.

04. Čuvajte se poruka o pogreškama

Budite oprezni s koliko podataka dajete u porukama o pogreškama. Svojim korisnicima pružite samo minimalne pogreške kako biste osigurali da ne propuštaju tajne prisutne na vašem poslužitelju (npr. API ključevi ili lozinke baze podataka). Ne pružajte ni pune detalje o iznimkama, jer oni mogu daleko olakšati složene napade poput SQL injekcije. Čuvajte detaljne pogreške u zapisima poslužitelja i korisnicima prikazujte samo potrebne podatke.

05. Potvrdite s obje strane

Provjeru valjanosti uvijek treba vršiti i na strani preglednika i na poslužitelju. Preglednik može uhvatiti jednostavne kvarove poput obveznih polja koja su prazna i kada tekst unosite u polje samo s brojevima. Međutim, njih se može zaobići i provjerite imate li provjere za provjeru valjanosti i za dublju provjeru na strani poslužitelja, jer ako to ne učini, zlonamjerni kod ili skriptni kôd mogu se umetnuti u bazu podataka ili mogu dovesti do neželjenih rezultata na vašoj web lokaciji.

06. Provjerite lozinke

Svi znaju da bi trebali koristiti složene lozinke, ali to ne znači da uvijek rade. Ključno je koristiti jake lozinke za administratorsko područje vašeg poslužitelja i web stranice, ali jednako tako važno je inzistirati na dobrim praksama lozinki za vaše korisnike kako bi zaštitili sigurnost svojih računa.

Koliko god se korisnicima to ne sviđa, provođenje zahtjeva za lozinkom, kao što je najmanje oko osam znakova, uključujući veliko slovo i broj, dugoročno će zaštititi njihove podatke.

Lozinke se uvijek trebaju pohraniti kao šifrirane vrijednosti, po mogućnosti koristeći jednosmjerni algoritam raspršivanja kao što je SHA. Korištenje ove metode znači da prilikom autentifikacije korisnika uspoređujete samo šifrirane vrijednosti. Za dodatnu sigurnost web mjesta, dobro je posoliti lozinke, koristeći novu sol po lozinci.

U slučaju da netko hakira i ukrade vaše lozinke, upotreba raspršenih lozinki može pomoći u ograničavanju oštećenja, jer njihovo dešifriranje nije moguće. Najbolje što netko može učiniti je napad na rječnik ili napad grubom silom, u osnovi pogađajući svaku kombinaciju dok ne pronađe podudarnost. Kada se koriste slane lozinke, postupak probijanja velikog broja lozinki još je sporiji jer se svaka pretpostavka mora raspršiti zasebno za svaku sol + lozinku, što je računski vrlo skupo.

Srećom, mnogi CMS-ovi pružaju upravljanju korisnicima već s ugrađenim puno ovih sigurnosnih značajki web stranica, iako će možda biti potrebne neke konfiguracije ili dodatni moduli za upotrebu slanih lozinki (pre Drupal 7) ili za postavljanje minimalne snage lozinke. Ako koristite .NET, tada je vrijedno koristiti dobavljače članstva jer su vrlo konfigurabilni, pružaju ugrađenu sigurnost web mjesta i uključuju gotove kontrole za prijavu i poništavanje lozinke.

07. Izbjegavajte prijenose datoteka

Dopuštanje korisnicima da prenose datoteke na vaše web mjesto može predstavljati veliki sigurnosni rizik web mjesta, čak i ako je riječ samo o promjeni avatara. Rizik je da svaka prenesena datoteka, koliko god nevina izgledala, može sadržavati skriptu koja kada se izvrši na vašem poslužitelju potpuno otvori vašu web stranicu.

Ako imate obrazac za prijenos datoteka, prema svim datotekama morate postupati s velikom sumnjom. Ako dopuštate korisnicima da prenose slike, ne možete se osloniti na ekstenziju datoteke ili na vrstu mime kako biste provjerili je li datoteka slika jer se te lako mogu lažirati. Čak i otvaranje datoteke i čitanje zaglavlja ili korištenje funkcija za provjeru veličine slike nisu sigurni. Većina formata slika omogućuje pohranu odjeljka komentara koji može sadržavati PHP kôd koji poslužitelj može izvršiti.

Pa što možete učiniti da to spriječite? U konačnici želite spriječiti korisnike da mogu izvršiti bilo koju datoteku koju prenose. Prema zadanim postavkama web poslužitelji neće pokušavati izvršiti datoteke s ekstenzijama slike, ali ne oslanjajte se samo na provjeru ekstenzije datoteke jer je poznato da datoteka s imenom image.jpg.php prolazi.

Neke su mogućnosti preimenovati datoteku prilikom prijenosa kako bi se osiguralo ispravno proširenje datoteke ili promijeniti dozvole datoteke, na primjer, chmod 0666, tako da se ne može izvršiti. Ako koristite * nix, mogli biste stvoriti .htaccess datoteku (vidi dolje) koja će dopustiti samo pristup postavljenim datotekama sprečavajući prethodno spomenuti napad dvostrukog proširenja.

deny from all order deny,allow allow from all

U konačnici, preporučeno rješenje je potpuno spriječiti izravan pristup prenesenim datotekama. Na taj se način sve datoteke prenesene na vaše web mjesto pohranjuju u mapu izvan webroot-a ili u bazu podataka kao blob. Ako vašim datotekama nije izravno dostupan, morat ćete stvoriti skriptu za preuzimanje datoteka iz privatne mape (ili HTTP rukovatelja u .NET-u) i njihovo predavanje u preglednik. Oznake slike podržavaju src atribut koji nije izravan URL slike, tako da vaš atribut src može ukazivati ​​na skriptu za isporuku datoteka pružajući vam ispravnu vrstu sadržaja u HTTP zaglavlju. Na primjer:

Većina pružatelja usluga hostinga bave se konfiguracijom poslužitelja umjesto vas, ali ako web mjesto hostinga nalazite na vlastitom poslužitelju, malo je stvari koje ćete htjeti provjeriti.

Provjerite imate li postavljen vatrozid i blokirate li sve nebitne priključke. Ako je moguće, postavite DMZ (Demilitariziranu zonu) koja dopušta pristup lukama 80 i 443 samo s vanjskog svijeta. Iako to možda neće biti moguće ako nemate pristup poslužitelju s interne mreže, jer ćete trebati otvoriti priključke kako biste omogućili prijenos datoteka i daljinsku prijavu na svoj poslužitelj putem SSH-a ili RDP-a.

Ako dopuštate prijenos datoteka s Interneta, na poslužitelj koristite samo sigurne načine prijenosa, kao što su SFTP ili SSH.

Ako je moguće, neka vaša baza podataka radi na drugom poslužitelju od onog na vašem web poslužitelju. To znači da se poslužitelju baze podataka ne može pristupiti izravno iz vanjskog svijeta, već mu može pristupiti samo vaš web poslužitelj, umanjujući rizik od izloženosti vaših podataka.

Napokon, ne zaboravite na ograničavanje fizičkog pristupa poslužitelju.

08. Koristite HTTPS

HTTPS je protokol koji se koristi za pružanje sigurnosti putem Interneta. HTTPS jamči da korisnici razgovaraju s poslužiteljem kojeg očekuju i da nitko drugi ne može presretati ili mijenjati sadržaj koji vide u prolazu.

Ako imate nešto što bi vaši korisnici možda željeli privatno, vrlo je poželjno koristiti samo HTTPS za isporuku. To naravno znači stranice s kreditnom karticom i stranicama za prijavu (i URL-ove na koje se prijavljuju), ali obično i mnogo više vašeg web mjesta. Obrazac za prijavu često postavlja primjerice kolačić, koji se šalje uz svaki drugi zahtjev na vašu web stranicu koji prijavljeni korisnik podnese i koristi se za provjeru autentičnosti tih zahtjeva. Napadač koji ovo ukrade mogao bi savršeno oponašati korisnika i preuzeti njegovu sesiju prijave. Da biste pobijedili ovu vrstu napada, gotovo uvijek želite koristiti HTTPS za cijelu web lokaciju.

To više nije tako škakljivo ili skupo kao nekada. Šifrirajmo pruža potpuno besplatne i automatizirane certifikate, koje ćete trebati omogućiti HTTPS-om, a postoje postojeći alati zajednice dostupni za širok raspon uobičajenih platformi i okvira koji vam ovo automatski postavljaju.

kako napraviti uvod s naknadnim efektima

Google je najavio da će vas povećati na ljestvici pretraživanja ako koristite HTTPS, dajući i ovo prednost SEO-u. Nesigurni HTTP je na izmaku, a sada je vrijeme za nadogradnju.

Već svugdje upotrebljavate HTTPS? Idite dalje i pogledajte postavljanje HTTP Strict Transport Security (HSTS), jednostavno zaglavlje koje možete dodati odgovorima poslužitelja kako biste onemogućili nesigurni HTTP za cijelu domenu.

09. Nabavite alate za sigurnost web mjesta

Jednom kada pomislite da ste učinili sve što je u vašoj moći, vrijeme je da testirate sigurnost svoje web stranice. Najučinkovitiji način za to je korištenje nekih sigurnosnih alata za web stranice, koji se često nazivaju testiranjem penetracije ili kratkim ispitivanjem olovke.

Postoje mnogi komercijalni i besplatni proizvodi koji vam pomažu u ovome. Rade na sličnoj osnovi kao i hakeri skripti, jer testiraju sve poznate eksploatacije i pokušavaju ugroziti vaše web mjesto pomoću nekih od prethodno spomenutih metoda, poput SQL Injection.

Nekoliko besplatnih alata koje vrijedi pogledati:

  • Netsparker (Dostupno besplatno izdanje zajednice i probna verzija). Dobro za testiranje SQL ubrizgavanja i XSS-a
  • OpenVAS Tvrdi da je najnapredniji sigurnosni skener otvorenog koda. Dobro za testiranje poznatih ranjivosti, trenutno skenira preko 25 000. Ali to može biti teško za postavljanje i zahtijeva instaliranje OpenVAS poslužitelja koji radi samo na * nixu. OpenVAS je račva Nessusa prije nego što je postao komercijalni proizvod zatvorenog koda.
  • SecurityHeaders.io (besplatna internetska provjera). Alat za brzo izvještavanje koja je gore navedena sigurnosna zaglavlja (poput CSP-a i HSTS-a) domena omogućila i ispravno konfigurirala.
  • Xenotix XSS Exploit Framework Alat iz OWASP-a (Open Web Application Security Project) koji uključuje ogroman izbor primjera XSS napada koje možete pokrenuti da biste brzo potvrdili jesu li unosi vaše web stranice ranjivi u Chrome, Firefox i IE.

Rezultati automatiziranih testova mogu biti zastrašujući jer predstavljaju mnoštvo potencijalnih problema. Važno je prvo se usredotočiti na kritična pitanja. Uz svaki prijavljeni problem obično dolazi dobro objašnjenje potencijalne ranjivosti. Vjerojatno ćete otkriti da neka pitanja srednje i niske razine ne zabrinjavaju vašu web lokaciju.

Postoji nekoliko daljnjih koraka koje možete poduzeti da biste ručno pokušali ugroziti svoje mjesto mijenjanjem vrijednosti POST / GET. Ovdje vam može pomoći proxy za otklanjanje pogrešaka koji vam omogućuje presretanje vrijednosti HTTP zahtjeva između vašeg preglednika i poslužitelja. Popularna besplatna aplikacija nazvana Violinista je dobra polazna točka.

Pa što biste trebali pokušati izmijeniti na zahtjevu? Ako imate stranice koje bi samo prijavljeni korisnik trebao vidjeti, pokušajte promijeniti parametre URL-a, poput korisničkog ID-a ili vrijednosti kolačića, pokušavajući pogledati detalje drugog korisnika. Još jedno područje koje vrijedi testirati su obrasci, promjena vrijednosti POST-a radi pokušaja slanja koda za izvođenje XSS-a ili prijenos skripte na strani poslužitelja.

Povezani članci: