Noin vuosi sitten me DataLinen käynnistimme etsiä ja analysoida IT-sovellusten haavoittuvuuksia. Palvelu perustuu Qualys-pilviratkaisuun, jonka toiminnasta . Vuoden aikana, kun työskentelimme ratkaisun parissa, teimme 291 tarkistusta eri sivustoille ja keräsimme tilastoja verkkosovellusten yleisistä haavoittuvuuksista.
Alla olevassa artikkelissa näytän sinulle tarkalleen, mitkä aukot verkkosivustojen tietoturvassa piilevät eri kriittisyyden takana. Katsotaan, mitä haavoittuvuuksia skanneri löysi erityisen usein, miksi niitä saattaa esiintyä ja miten suojautua.
Qualys jakaa kaikki verkkosovellusten haavoittuvuudet kolmeen kriittisyyden tasoon: matala, keskitaso ja korkea. Jos tarkastellaan jakautumista "vakavuuden mukaan", näyttää siltä, että kaikki ei ole niin huono. On olemassa muutamia haavoittuvuuksia, joiden kriittisyyden taso on korkea, enimmäkseen kaikki ovat ei-kriittisiä:
Mutta kritiikki ei tarkoita vaaratonta. Ne voivat myös aiheuttaa vakavia vahinkoja.
Parhaat "ei-kriittiset" haavoittuvuudet
- Sekalaisen sisällön haavoittuvuudet.
Verkkosivustojen turvallisuuden standardi on tiedonsiirto asiakkaan ja palvelimen välillä HTTPS-protokollan kautta, joka tukee salausta ja suojaa tietoja sieppaukselta.
Jotkut sivustot käyttävät sekoitettua sisältöä: Osa tiedoista siirretään suojaamattoman HTTP-protokollan kautta. Näin se useimmiten ilmaistaan passiivinen sisältö – tiedot, jotka vaikuttavat vain sivuston näyttöön: kuvat, css-tyylit. Mutta joskus se välitetään näin aktiivista sisältöä: komentosarjat, jotka ohjaavat sivuston toimintaa. Tässä tapauksessa voit erikoisohjelmiston avulla analysoida palvelimelta tulevaa aktiivista sisältöä sisältäviä tietoja, muokata vastauksiasi lennossa ja saada koneen toimimaan tavalla, jota sen tekijät eivät ole ajatelleet.
Selaimien uudemmat versiot varoittavat käyttäjiä, että sivustot, joilla on sekasisältöä, ovat vaarallisia ja estävät sisällön. Verkkosivustojen kehittäjät saavat myös selainvaroituksia konsoliin. Esimerkiksi tältä se näyttää sisällä :
Miksi se on vaarallista: Hyökkääjät käyttävät suojaamatonta protokollaa siepatakseen käyttäjätietoja, korvatakseen komentosarjoja ja lähettääkseen pyyntöjä sivustolle hänen puolestaan. Vaikka sivuston vierailija ei olisi syöttänyt tietoja, tämä ei suojaa häntä phishing – luottamuksellisten tietojen hankkiminen vilpillisillä menetelmillä. Esimerkiksi komentosarjan avulla voit ohjata käyttäjän turvattomalle sivustolle, joka naamioituu käyttäjälle tutuksi. Joissakin tapauksissa haitallinen sivusto näyttää jopa paremmalta kuin alkuperäinen, ja käyttäjä voi itse täyttää lomakkeen ja lähettää luottamuksellisia tietoja.Mitä verkkokehittäjän tulee muistaa: Vaikka sivuston järjestelmänvalvoja on asentanut ja määrittänyt SSL/TLS-varmenteen, haavoittuvuus voi syntyä inhimillisen virheen vuoksi. Jos esimerkiksi yhdelle sivulle laitat suhteellista linkkiä, vaan absoluuttisen linkin http:stä, etkä lisäksi määrittänyt uudelleenohjauksia http:stä https:ään.
Voit havaita sivuston sekalaista sisältöä selaimella: hae sivun lähdekoodia, lue ilmoituksia kehittäjäkonsolissa. Kehittäjän on kuitenkin työstettävä koodia pitkään ja ikävästi. Voit nopeuttaa prosessia automaattisilla analyysityökaluilla, esimerkiksi: , ilmainen Lighthouse-ohjelmisto tai maksullinen ohjelmisto Screaming Frog SEO Spider.
Haavoittuvuus voi myös johtua ongelmista legacy-code -koodissa, joka on peritty. Esimerkiksi jos jotkin sivut on luotu käyttämällä vanhaa mallia, joka ei ota huomioon sivustojen siirtymistä https:ään.
- Evästeet ilman "HTTOnly"- ja "secure"-lippuja.
"HTTOnly"-attribuutti suojaa evästeitä käsitteiltä komentosarjat, joita hyökkääjät käyttävät käyttäjätietojen varastamiseen. "Secure"-lippu ei salli evästeiden lähettämistä selkeänä tekstinä. Viestintä sallitaan vain, jos evästeiden lähettämiseen käytetään suojattua HTTPS-protokollaa.
Molemmat attribuutit on määritetty evästeen ominaisuuksissa:
Set-Cookie: Secure; HttpOnlyMiksi se on vaarallista: Jos sivuston kehittäjä ei määrittänyt näitä määritteitä, hyökkääjä voi siepata käyttäjän tiedot evästeestä ja hyödyntää niitä. Jos evästeitä käytetään todentamiseen ja valtuutukseen, hän voi kaapata käyttäjän istunnon ja suorittaa toimintoja sivustolla hänen puolestaan.
Mitä verkkokehittäjän tulee muistaa: Yleensä suosituissa kehyksissä nämä attribuutit asetetaan automaattisesti. Mutta silti tarkista verkkopalvelimen asetukset ja aseta lippu: Set-Cookie HttpOnly; Turvallinen.
Tässä tapauksessa "HTTOnly"-attribuutti tekee evästeistä näkymättömiä omalle JavaScriptillesi.
- Polkupohjaiset haavoittuvuudet.
Skanneri ilmoittaa tällaisesta haavoittuvuudesta, jos se löytää julkisesti saatavilla olevan tiedoston tai verkkosivustohakemiston, joka sisältää mahdollisesti luottamuksellisia tietoja. Se esimerkiksi havaitsee yksittäiset järjestelmän kokoonpanotiedostot tai pääsyn koko tiedostojärjestelmään. Tämä tilanne on mahdollinen, jos käyttöoikeudet on asetettu väärin sivustolla.
Miksi se on vaarallista: Jos tiedostojärjestelmä jää ulos, hyökkääjä voi pudota käyttöjärjestelmän käyttöliittymään ja yrittää löytää kansioita salasanoilla, jos ne on tallennettu tekstimuodossa (älä tee sitä!). Tai voit varastaa salasanojen tiivisteet ja raa'alla väkivallalla salasanan sekä yrittää lisätä järjestelmän käyttöoikeuksia ja siirtyä syvemmälle infrastruktuuriin.
Mitä verkkokehittäjän tulee muistaa: Älä unohda käyttöoikeuksia ja määritä alusta, verkkopalvelin, verkkosovellus niin, että verkkohakemistosta on mahdotonta "paeta".
- Lomakkeet arkaluontoisten tietojen syöttämiseen, kun automaattinen täyttö on käytössä.
Jos käyttäjä täyttää usein lomakkeita verkkosivustoilla, hänen selaimensa tallentaa nämä tiedot automaattisen täytön avulla.
Web-sivustojen lomakkeet voivat sisältää kenttiä, joissa on arkaluonteisia tietoja, kuten salasanoja tai luottokorttien numeroita. Tällaisten kenttien kohdalla kannattaa poistaa käytöstä lomakkeiden automaattinen täyttötoiminto itse sivustolta.
Miksi se on vaarallista: Jos käyttäjän selain tallentaa arkaluontoisia tietoja, hyökkääjä voi siepata ne myöhemmin, esimerkiksi tietojenkalastelulla. Pohjimmiltaan verkkokehittäjä, joka on unohtanut tämän vivahteen, perustaa käyttäjiään.
Mitä verkkokehittäjän tulee muistaa: Tässä tapauksessa meillä on klassinen ristiriita: mukavuus vs turvallisuus. Jos verkkokehittäjä ajattelee käyttökokemusta, hän voi tietoisesti valita automaattisen täydennyksen. Esimerkiksi jos on tärkeää seurata – suosituksia sisällön saatavuudesta vammaisille käyttäjille.
Useimmissa selaimissa voit poistaa automaattisen täydennyksen käytöstä autocompete="off"-attribuutilla, esimerkiksi:
<body> <form action="/fi/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Mutta se ei toimi Chromessa. Tämä kierretään JavaScriptillä, reseptin muunnelma löytyy .
- X-Frame-Options-otsikkoa ei ole asetettu sivustokoodissa.
Tämä otsikko vaikuttaa kehys-, iframe-, upotus- tai objektitunnisteisiin. Sen avulla voit kieltää kokonaan sivustosi upottamisen kehyksen sisään. Tätä varten sinun on määritettävä arvo X-Frame-Options: deny. Tai voit määrittää X-Frame-Options: sameorigin, jolloin upottaminen iframe-kehykseen on käytettävissä vain verkkotunnuksessasi.
Miksi se on vaarallista: Tällaisen otsikon puuttumista voidaan käyttää haitallisilla sivustoilla clickjacking. Tätä hyökkäystä varten hyökkääjä luo läpinäkyvän kehyksen painikkeiden päälle ja huijaa käyttäjää. Esimerkiksi: huijarit kehystävät sosiaalisen verkostoitumisen sivuja verkkosivustolla. Käyttäjä luulee napsauttavansa painiketta tällä sivustolla. Sen sijaan napsautus siepataan ja käyttäjän pyyntö lähetetään sosiaaliseen verkostoon, jossa on aktiivinen istunto. Näin hyökkääjät lähettävät roskapostia käyttäjän puolesta tai saavat tilaajia ja tykkäyksiä.
Jos et poista tätä ominaisuutta käytöstä, hyökkääjä voi sijoittaa sovelluspainikkeesi haitalliseen sivustoon. Hän saattaa olla kiinnostunut viittausohjelmastasi tai käyttäjistäsi.
Mitä verkkokehittäjän tulee muistaa: Haavoittuvuus voi ilmetä, jos X-Frame-Options, jonka arvo on ristiriitainen, on asetettu verkkopalvelimeen tai kuormituksen tasapainottimeen. Tässä tapauksessa palvelin ja tasapainottaja yksinkertaisesti kirjoittavat otsikon uudelleen, koska niillä on korkeampi prioriteetti taustakoodiin verrattuna.
X-Frame-Options-otsikon deny- ja sameorigin-arvot häiritsevät Yandex-verkkokatselun toimintaa. Jos haluat sallia iframe-kehysten käytön web-katseluohjelmassa, sinun on kirjoitettava asetuksiin erillinen sääntö. Esimerkiksi nginxille voit määrittää sen seuraavasti:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI (Path-relative stylesheet import) haavoittuvuudet.
Tämä on haavoittuvuus sivuston tyylissä. Se tapahtuu, jos tyylitiedostojen avaamiseen käytetään suhteellisia linkkejä, kuten href="/fi/somefolder/styles.css/". Hyökkääjä käyttää tätä hyväkseen, jos he löytävät tavan ohjata käyttäjä haitalliselle sivulle. Sivu lisää suhteellisen linkin URL-osoitteeseen ja simuloi tyylikutsua. Saat pyynnön, kuten badsite.ru/…/somefolder/styles.css/, joka voi suorittaa haitallisia toimia tyylin varjolla.
Miksi se on vaarallista: Huijarit voivat käyttää tätä haavoittuvuutta hyväkseen, jos he löytävät toisen tietoturva-aukon. Tämän seurauksena on mahdollista varastaa käyttäjätietoja evästeistä tai tunnuksista.
Mitä verkkokehittäjän tulee muistaa: Aseta X-Content-Type-Options-otsikoksi: nosniff. Tässä tapauksessa selain tarkistaa tyylien sisältötyypin. Jos tyyppi on muu kuin text/css, selain estää pyynnön.
Kriittiset haavoittuvuudet
- Sivu, jossa on salasanakenttä, lähetetään palvelimelta suojaamattoman kanavan kautta (salasanakenttiä sisältävä HTML-lomake toimitetaan HTTP:n kautta).
Palvelimen vastaus salaamattoman kanavan kautta on alttiina "Man in the middle" -hyökkäyksille. Hyökkääjä voi siepata liikennettä ja kiilauttaa itsensä asiakkaan ja palvelimen väliin sivun siirtyessä palvelimelta asiakkaalle.
Miksi se on vaarallista: Huijari voi korvata sivun ja lähettää käyttäjälle luottamuksellisia tietoja koskevan lomakkeen, joka menee hyökkääjän palvelimelle.
Mitä verkkokehittäjän tulee muistaa: Jotkut sivustot lähettävät käyttäjille kertaluonteisen koodin sähköpostitse/puhelimella salasanan sijaan. Tässä tapauksessa haavoittuvuus ei ole niin kriittinen, mutta mekanismi vaikeuttaa käyttäjien elämää.
- Lomakkeen lähettäminen käyttäjätunnuksella ja salasanalla suojaamattoman kanavan kautta (kirjautumislomaketta ei lähetetä HTTPS:n kautta).
Tällöin käyttäjä lähettää palvelimelle salaamattoman kanavan kautta lomakkeen, jossa on käyttäjätunnus ja salasana.
Miksi se on vaarallista: Toisin kuin edellisessä tapauksessa, tämä on jo kriittinen haavoittuvuus. Arkaluontoisten tietojen sieppaaminen on helpompaa, koska sinun ei tarvitse edes kirjoittaa koodia tehdäksesi sen.
- JavaScript-kirjastojen käyttäminen tunnettujen haavoittuvuuksien kanssa.
Skannauksen aikana eniten käytetty kirjasto oli jQuery runsaalla versiomäärällä. Jokaisessa versiossa on ainakin yksi tai jopa useampi tunnettu haavoittuvuus. Vaikutus voi olla hyvin erilainen haavoittuvuuden luonteesta riippuen.
Miksi se on vaarallista: Tunnettuja haavoittuvuuksia varten on hyväksikäyttöä, esimerkiksi:
Mitä verkkokehittäjän tulee muistaa: Palaa säännöllisesti kiertoon: etsi tunnettuja haavoittuvuuksia - korjaa - tarkista. Jos käytät vanhoja kirjastoja tarkoituksella, esimerkiksi tukeaksesi vanhempia selaimia tai säästääksesi rahaa, etsi mahdollisuus korjata tunnettu haavoittuvuus. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS) tai cross-site scripting on hyökkäys verkkosovellusta vastaan, joka johtaa haittaohjelmien tuomiseen tietokantaan. Jos Qualys löytää tällaisen haavoittuvuuden, se tarkoittaa, että mahdollinen hyökkääjä voi tai on jo lisännyt oman js-komentosarjansa sivuston koodiin suorittaakseen haitallisia toimia.Tallennettu XSS vaarallisempi, koska komentosarja upotetaan palvelimelle ja suoritetaan aina, kun hyökkäyksen kohteena oleva sivu avataan selaimessa.
Heijastunut XSS helpompi suorittaa, koska HTTP-pyyntöön voidaan lisätä haitallinen komentosarja. Sovellus vastaanottaa HTTP-pyynnön, ei validoi tietoja, paketoi ne ja lähettää sen välittömästi. Jos hyökkääjä sieppaa liikennettä ja lisää komentosarjan, kuten
<script>/*+что+то+плохое+*/</script>sitten haitallinen pyyntö lähetetään asiakkaan puolesta.
Silmiinpistävä esimerkki XSS:stä: js-snifferit, jotka simuloivat sivuja CVC:n, kortin vanhenemispäivän ja niin edelleen syöttämiseksi.
Mitä verkkokehittäjän tulee muistaa: Käytä Content-Security-Policy-otsikossa attribuuttia script-src pakottaaksesi asiakasselaimen lataamaan ja suorittamaan koodia vain luotetusta lähteestä. Esimerkiksi script-src 'self' lisää kaikki sivustomme komentosarjat sallittujen luetteloon.
Paras käytäntö on tekstin sisäinen koodi: salli vain inline javascript käyttämällä unsafe-inline-arvoa. Tämä arvo sallii rivin js/css:n käytön, mutta ei estä js-tiedostojen sisällyttämistä. Yhdessä script-src 'self' kanssa estämme ulkoisten komentosarjojen suorittamisen.Muista kirjata kaikki report-uri-sovelluksella ja katsoa yrityksiä ottaa se käyttöön sivustolle.
- SQL-injektiot.
Haavoittuvuus viittaa mahdollisuuteen lisätä SQL-koodia verkkosivustoon, joka käyttää suoraan verkkosivuston tietokantaa. SQL-injektio on mahdollista, jos käyttäjän tietoja ei seulota: niiden oikeellisuutta ei tarkisteta ja niitä käytetään välittömästi kyselyssä. Näin tapahtuu esimerkiksi, jos verkkosivustolla oleva lomake ei tarkista, vastaako syöte tietotyyppiä.Miksi se on vaarallista: Jos hyökkääjä kirjoittaa SQL-kyselyn tähän lomakkeeseen, hän voi kaataa tietokannan tai paljastaa luottamuksellisia tietoja.
Mitä verkkokehittäjän tulee muistaa: Älä luota selaimesta tulevaan. Sinun on suojattava itsesi sekä asiakas- että palvelinpuolella.
Kirjoita asiakaspuolella kentän validointi JavaScriptillä.
Suosittujen kehysten sisäänrakennetut toiminnot auttavat myös välttämään epäilyttäviä hahmoja palvelimella. On myös suositeltavaa käyttää parametroituja tietokantakyselyitä palvelimella.
Selvitä, missä tarkalleen vuorovaikutus tietokannan kanssa tapahtuu verkkosovelluksessa.
Vuorovaikutusta tapahtuu, kun saamme mitä tahansa tietoa: pyynnön tunnuksella (tunnuksen muutos), uuden käyttäjän luomisen, uuden kommentin tai uusia merkintöjä tietokantaan. Tässä voi tapahtua SQL-injektioita. Vaikka poistaisimme tietueen tietokannasta, SQL-injektio on mahdollista.
Yleiset suositukset
Älä keksi pyörää uudelleen – käytä hyväksi havaittuja kehyksiä. Yleisesti suositut puitteet ovat turvallisempia. .NET - ASP.NET MVC ja ASP.NET Core, Python - Django tai Flask, Ruby - Ruby on Rails, PHP - Symfony, Laravel, Yii, JavaScript - Node.JS-Express.js, Java - Kevät MVC.
Seuraa toimittajan päivityksiä ja päivitä säännöllisesti. He löytävät haavoittuvuuden, kirjoittavat sitten hyväksikäytön, tuovat sen julkisesti saataville, ja kaikki tapahtuu uudelleen. Tilaa päivitykset vakaaseen versioon ohjelmistotoimittajalta.
Tarkista käyttöoikeudet. Palvelinpuolella kohtele koodiasi aina niin kuin sen ensimmäisestä viimeiseen kirjaimeen olisi kirjoittanut vihatuin vihollisesi, joka haluaa rikkoa sivustosi ja loukata tietojesi eheyttä. Lisäksi joskus tämä on totta.
Käytä klooneja, testipaikkoja ja käytä niitä sitten tuotantoon. Tämä auttaa ensinnäkin välttämään virheitä ja virheitä tuottavassa ympäristössä: tuottava ympäristö tuo rahaa, yksinkertainen tuotantoympäristö on kriittinen. Kun lisäät, korjaat tai suljet mitä tahansa ongelmaa, kannattaa työskennellä testiympäristössä, sitten tarkistaa löydetyt toiminnallisuus ja haavoittuvuudet ja suunnitella työskentelyä tuotantoympäristön kanssa.
Suojaa verkkosovelluksesi ja integroida haavoittuvuustarkistimen raportit siihen. Esimerkiksi DataLine käyttää Qualysia ja FortiWebia palvelupakettina.
Lähde: will.com