Liian monille yrityksille se on vasta jälkeen turvallisuusrikkomus on tapahtunut että verkkoturvallisuuden parhaista käytännöistä tulee etusijalla. Työskennellessäni tietoturva-alan ammattilaisena olen nähnyt yhä uudestaan ja uudestaan, kuinka hämärä verkkokehityksen turvallisuuskysymykset voivat olla niin monille minun muita ohjelmoijia .
Tehokkaan lähestymistavan verkkoturvauhkiin on määritelmänsä mukaan oltava ennakoivaa ja puolustavaa. Tätä tarkoitusta varten tämän viestin tarkoituksena on herättää tietoturva-ajattelutapa, toivottavasti pistämällä lukijalle terveellinen annos paranoa.
Tässä oppaassa keskitytään erityisesti kymmeneen yleiseen ja merkittävään verkkoturvallisuuden karhaan, joista on oltava tietoisia, mukaan lukien suositukset niiden lieventämiseksi. Painopiste on 10 parasta verkkohaitaa tunnistettu Avoin verkkosovelluksen suojausprojekti (OWASP) , kansainvälinen voittoa tavoittelematon organisaatio, jonka tavoitteena on parantaa ohjelmistojen turvallisuutta kaikkialla maailmassa.
Puhuessani muiden ohjelmoijien ja IT-ammattilaisten kanssa kohtaan usein hämmennystä valtuutuksen ja todennuksen eron suhteen. Ja tietysti tosiasia lyhenne todennut käytetään usein molempiin, mikä voi pahentaa tätä yleistä sekaannusta. Tämä hämmennys on niin yleistä, että ehkä asia pitäisi sisällyttää tähän viestiin nimellä 'Common Web Vulnerability Zero'.
Joten ennen kuin jatkamme, selvennetään ero näiden kahden termin välillä:
Totesi toisella tavalla, todennus tietää, kuka entiteetti on lupa on tieto siitä, mitä tietty yksikkö voi tehdä. Tässä mielessä päästään kymmenen parhaan Internet-tietoturvakysymyksen joukkoon.
Injektiovirheet johtuvat epäluotettavan syötteen suodattamisen klassisesta epäonnistumisesta. Se voi tapahtua, kun välität suodattamattomia tietoja SQL-palvelimelle (SQL-injektio), selaimelle (XSS - puhumme tästä myöhemmin ), LDAP-palvelimelle (LDAP-injektio) tai mihin tahansa muuhun. Ongelmana on, että hyökkääjä voi injektoida komentoja näille yhteisöille, mikä johtaa tietojen menetykseen ja kaapata asiakkaiden selaimet.
Kaikki, mitä sovelluksesi saa epäluotettavista lähteistä, on suodatettava, mieluiten sallittujen luettelon mukaan. Sinun ei pitäisi melkein koskaan käyttää mustaa listaa, koska oikeuden saaminen on erittäin vaikeaa ja yleensä helppo ohittaa. Virustentorjuntaohjelmistotuotteet tarjoavat tyypillisesti erinomaisia esimerkkejä epäonnistuneista mustista listoista. Kuvion sovitus ei toimi.
Ehkäisy: Hyvä uutinen on, että suojaus injektiota vastaan on 'yksinkertaisesti' suodattaa syötteesi oikein ja miettiä, voidaanko syötteeseen luottaa. Mutta huono uutinen on se kaikki panos on suodatettava kunnolla, ellei siihen voida kiistatta luottaa (mutta sanonta 'älä koskaan sano koskaan' ei tule mieleen tässä).
Esimerkiksi järjestelmässä, jossa on 1 000 tuloa, 999: n onnistunut suodattaminen ei riitä, koska tämä jättää vielä yhden kentän, joka voi toimia Achilles-parantumana järjestelmän kaatamiseksi. Ja saatat ajatella, että SQL-kyselytuloksen sijoittaminen toiseen kyselyyn on hyvä idea, koska tietokantaan luotetaan, mutta jos kehä ei ole, tulo tulee epäsuorasti kavereilta, joilla on väärinkäyttäjiä. Tätä kutsutaan Toisen asteen SQL-injektio jos olet kiinnostunut.
Koska suodatusta on melko vaikea tehdä oikein (kuten salausta), suosittelen yleensä, että luotat kehyksen suodatustoimintoihin: ne ovat osoittautuneet toimiviksi ja tutkitaan perusteellisesti. Jos et käytä kehyksiä, sinun on todella mietittävä kovasti ei niiden käyttäminen on todella järkevää palvelimesi suojauskontekstissa. 99% ajasta ei.
Tämä on kokoelma monista ongelmista, joita saattaa ilmetä rikkinäisen todennuksen aikana, mutta ne kaikki eivät johdu samasta perimmäisestä syystä.
Olettaen, että kukaan haluaa edelleen käyttää omaa todennuskoodiaan vuonna 2014 (mitä ajattelet ??), suosittelen sitä vastaan. On äärimmäisen vaikeaa saada oikeaksi, ja on olemassa lukemattomia mahdollisia kaatumisia, vain muutamia mainitakseni:
Ehkäisy: Selkein tapa välttää tämä verkkoturva-aukko on käyttää kehystä. Saatat pystyä toteuttamaan tämän oikein, mutta edellinen on paljon helpompaa. Jos haluat kääntää oman koodisi, ole erittäin paranoidi ja kouluta itseäsi sudenkuoppia. Niitä on melko paljon.
Tämä on melko laajalle levinnyt epäpuhtauksien syöttövirhe (lähinnä yleinen virhe # 1 ). Hyökkääjä antaa verkkosovelluksellesi JavaScript-tunnisteet syötteeksi. Kun tämä syöte palautetaan käyttäjälle sanattomana, käyttäjän selain suorittaa sen. Se voi olla yhtä yksinkertaista kuin luoda linkki ja suostutella käyttäjä napsauttamaan sitä, tai se voi olla jotain paljon pahempaa. Sivun latauksessa komentosarja suoritetaan ja sitä voidaan käyttää esimerkiksi evästeiden lähettämiseen hyökkääjälle.
Ehkäisy: On olemassa yksinkertainen verkkoturvaratkaisu: älä palauta HTML-tunnisteita asiakkaalle. Tällä on lisäetuna puolustaminen HTML-injektiota vastaan, samanlainen hyökkäys, jossa hyökkääjä ruiskuttaa tavallista HTML-sisältöä (kuten kuvia tai kovaa, näkymättömiä flash-soittimia) - ei kovin vaikuttavaa, mutta varmasti ärsyttävää ('tee se lopetettavaksi!'). Yleensä kiertotapa on yksinkertaisesti muuntaa kaikki HTML-entiteetit , joten se palautetaan muodossa . Toinen usein käytetty puhdistusmenetelmä on käyttää säännöllisiä lausekkeita HTML-tunnisteiden poistamiseksi käyttämällä säännöllisiä lausekkeita
<
ja >
, mutta tämä on vaarallista, koska monet selaimet tulkitsevat ankarasti rikkoutuneen HTML: n hienosti. Parempi muuntaa kaikki merkit pakeneviksi vastineiksi.
Tämä on klassinen tapaus luottaa käyttäjän panokseen ja maksaa hinta seurauksena olevasta tietoturva-aukosta. Suora objektiviite tarkoittaa, että sisäinen objekti, kuten tiedosto tai tietokanta-avain, paljastetaan käyttäjälle. Tämän ongelmana on, että hyökkääjä voi antaa tämän viitteen, ja jos valtuutusta ei pakoteta (tai se rikkoutuu), hyökkääjä voi käyttää tai tehdä asioita, joista heidät tulisi estää.
Esimerkiksi koodilla on download.php
moduuli, joka lukee ja antaa käyttäjän ladata tiedostoja, käyttämällä CGI-parametria tiedoston nimen määrittämiseen (esim. download.php?file=something.txt
). Joko vahingossa tai laiskuuden vuoksi kehittäjä jätti valtuutuksen koodista. Hyökkääjä voi nyt käyttää tätä lataamaan kaikki järjestelmätiedostot, joihin PHP: tä käyttävällä käyttäjällä on pääsy, kuten itse sovelluskoodi tai muut palvelimessa olevat tiedot, kuten varmuuskopiot. Voi ei.
Toinen yleinen esimerkki haavoittuvuudesta on salasanan palautustoiminto, joka perustuu käyttäjän syötteisiin sen määrittämiseksi, kenen salasanan palautamme. Napsautettuaan kelvollista URL-osoitetta hyökkääjä voi vain muokata username
URL-kentässä sanoa jotain 'admin'.
Muuten molemmat esimerkit ovat asioita, jotka olen itse nähnyt esiintyvän usein 'luonnossa'.
Ehkäisy: Suorita käyttäjän valtuutus oikein ja johdonmukaisesti ja lisää valinnat sallittujen luetteloon. Useammin kuin ei, koko ongelma voidaan kuitenkin välttää tallentamalla tietoja sisäisesti eikä luottamalla siihen, että ne välitetään asiakkaalta CGI-parametrien kautta. Istuntomuuttujat useimmissa kehyksissä sopivat hyvin tähän tarkoitukseen.
Kokemukseni mukaan väärin määritetyt verkkopalvelimet ja sovellukset ovat paljon yleisempiä kuin oikein määritetyt. Ehkä tämä johtuu siitä, että keinoista ei ole pulaa. Joitain esimerkkejä:
Ehkäisy: Sinulla on hyvä (mieluiten automatisoitu) 'rakennus ja käyttöönotto' -prosessi, joka voi suorittaa testejä käyttöönotossa. Köyhän miehen turvallisuusvirheiden määritys on sitoutumisen jälkeisiä koukkuja estämään koodia menemästä ulos oletussalasanoilla ja / tai sisäänrakennetuilla kehitystavaroilla.
Tämä verkkoturva-aukko koskee salaus- ja resurssisuojausta. Arkaluonteiset tiedot tulisi salata koko ajan, myös kuljetuksen ja levon aikana. Ei poikkeuksia. Luottokorttitietojen ja käyttäjän salasanojen pitäisi ei koskaan matkustaa tai säilytettävä salaamattomina, ja salasanat tulee aina hajauttaa. Salaus / hajautusalgoritmi ei tietenkään saa olla heikko - epävarmoissa tapauksissa verkkoturvallisuusstandardit suosittelevat AES (256 bittiä ja enemmän) ja RSA (vähintään 2048 bittiä) .
Ja vaikka on sanomattakin selvää, että istuntotunnuksia ja arkaluontoisia tietoja ei pitäisi matkustaa URL-osoitteissa ja arkaluontoisilla evästeillä tulisi olla suojattu lippu, tämä on erittäin tärkeää, eikä sitä voida korostaa liikaa.
Ehkäisy:
Matkalla: Käyttää HTTPS asianmukaisella todistuksella ja PFS (täydellinen salassapito) . Älä hyväksy mitään muiden kuin HTTPS-yhteyksien kautta. Käytä evästeissä suojattua lippua.
Varastossa: Tämä on vaikeampi. Ensinnäkin sinun on pienennettävä valotusta. Jos et tarvitse arkaluontoisia tietoja, murskaa ne. Tietoja, joita sinulla ei ole, ei voi olla varastettu . Älä tallenna luottokorttitietoja koskaan , koska luultavasti et halua joutua käsittelemään olemista PCI-yhteensopiva . Rekisteröidy maksuprosessoriin, kuten Raita tai Braintree . Toiseksi, jos sinulla on arkaluonteisia tietoja, joita todella tarvitset, tallenna ne salattuina ja varmista, että kaikki salasanat on hajautettu. Hajauttamiseen käytetään bcrypt on suositeltavaa. Jos et käytä bcryptia, kouluta itseäsi suolaus ja sateenkaaripöydät .
Ja vaarassa sanoa ilmeinen, älä tallenna salausavaimia suojattujen tietojen viereen . Se on kuin pyörän säilyttäminen lukolla, jossa on avain. Suojaa varmuuskopiot salauksella ja pidä avaimet hyvin yksityisinä. Ja tietysti, älä menetä avaimia!
Tämä on yksinkertaisesti valtuutusvirhe. Se tarkoittaa, että kun toiminto kutsutaan palvelimelle, oikeaa valtuutusta ei suoritettu. Usein kehittäjät luottavat siihen, että palvelinpuoli loi käyttöliittymän, ja heidän mielestään asiakas ei voi käyttää toimintoja, joita palvelin ei tarjoa. Se ei ole niin yksinkertaista, koska hyökkääjä voi aina väärentää pyyntöjä 'piilotetulle' toiminnolle, eikä häntä estä se, että käyttöliittymä ei tee tästä toiminnosta helppoa. Kuvittele, että siellä on /admin
ja painike on käyttöliittymässä vain, jos käyttäjä on itse järjestelmänvalvoja. Mikään ei estä hyökkääjää löytämästä tätä toimintoa ja käyttämästä sitä väärin, jos valtuutus puuttuu.
Ehkäisy: Palvelinpuolella valtuutuksen on oltava aina olla tehty. Kyllä aina. Mikään poikkeus tai haavoittuvuus ei aiheuta vakavia ongelmia.
Tämä on hieno esimerkki hämmentynyt varajäsen hyökkäys, jossa joku muu osapuoli huijaa selainta väärinkäytöksellään. Esimerkiksi kolmannen osapuolen sivusto voi saada käyttäjän selaimen käyttämään väärin valtuuksiaan tehdä jotain hyökkääjän hyväksi.
CSRF: n tapauksessa kolmannen osapuolen sivusto lähettää pyyntöjä kohdesivustolle (esim. Pankkisi) selaimesi avulla evästeiden / istunnon aikana. Jos olet kirjautunut sisään esimerkiksi pankkisi etusivun yhdelle välilehdelle ja he ovat alttiita tälle hyökkäykselle, toinen välilehti voi saada selaimesi väärinkäyttämään kirjautumistietojaan hyökkääjän puolesta, mikä johtaa hämmentyneeseen sijaisongelmaan. Varajäsen on selain, joka käyttää valtaansa väärin (istuntoevästeet) tekemään jotain, johon hyökkääjä käskee.
Harkitse tätä esimerkkiä:
Hyökkääjä Alice haluaa keventää Toddin lompakkoa siirtämällä osan rahoistaan hänelle. Toddin pankki on altis CSRF: lle. Rahan lähettämiseksi Toddilla on oltava seuraava URL:
img / back-end / 29/10-most-common-web-security-haavoittuvuudet.jpg
Kun tämä URL on avattu, menestyssivu näytetään Toddille, ja siirto on suoritettu. Alice tietää myös, että Todd vierailee usein hallinnassaan olevalla sivustolla osoitteessa blog.aliceisawesome.com, jonne hän sijoittaa seuraavan katkelman:
Vieraillessaan Alicen verkkosivustolla Toddin selain ajattelee, että Alice linkittää kuvan ja lähettää automaattisesti HTTP GET -pyynnön kuvan noutamiseksi, mutta todellisuudessa käsketään Toddin pankkia siirtämään 1500 dollaria Aliceen.
CSRF-haavoittuvuuden lisäksi tämä esimerkki osoittaa myös palvelimen tilan muuttamisen idempotenttisella HTTP GET -pyynnöllä, joka itsessään on vakava haavoittuvuus. HTTP GET -pyynnöt on pakko olla idempotentti (turvallinen), mikä tarkoittaa, että ne eivät voi muuttaa resurssia, jota käytetään. Älä koskaan, koskaan, koskaan käytä idempotent-menetelmiä palvelimen tilan muuttamiseen.
Hauska tosiasia: CSRF on myös menetelmä, jota ihmiset käyttivät aiemmin evästeiden täyttämiseen, kunnes tytäryhtiöt tulivat viisaammiksi.
Ehkäisy: Tallenna salainen tunniste piilotettuun lomakekenttään, johon ei pääse kolmannen osapuolen sivustolta. Sinun on tietysti aina vahvistettava tämä piilotettu kenttä. Jotkut sivustot pyytävät salasanaasi myös arkaluontoisia asetuksia muokattaessa (esimerkiksi salasanamuistutussähköpostisi), vaikka epäilen, että tämä on olemassa hylättyjen istuntojen väärinkäytön estämiseksi (esimerkiksi Internet-kahvilassa).
Otsikko kertoo kaiken. Luokittelen tämän jälleen enemmän huolto- / käyttöönotto-ongelmaksi. Ennen uuden koodin sisällyttämistä, tee joitain tutkimuksia, mahdollisesti joitain auditointeja. Käyttämällä koodia, jonka sait satunnaiselta henkilöltä GitHub tai jokin foorumi saattaa olla erittäin kätevä, mutta ei vaaranna vakavaa verkkoturvallisuushaavoittuvuutta.
Olen nähnyt monia tapauksia, esimerkiksi sivustoja omistettu (ts. missä ulkopuolinen saa järjestelmänvalvojan pääsyn järjestelmään), ei siksi, että ohjelmoijat olivat typeriä, vaan siksi, että kolmannen osapuolen ohjelmistoa ei ollut käytetty vuosia tuotannossa. Tätä tapahtuu koko ajan esimerkiksi WordPress-laajennusten kanssa. Jos luulet, etteivät he löydä piilotettua phpmyadmin
asennuksen, haluan esitellä sinulle dirbuster.
Oppitunti on, että ohjelmistokehitys ei lopu, kun sovellus otetaan käyttöön. On oltava dokumentaatio, testit ja suunnitelmat sen ylläpitämiseksi ja päivittämiseksi, varsinkin jos se sisältää kolmannen osapuolen tai avoimen lähdekoodin komponentteja.
Ehkäisy:
Ole varovainen. Sen lisäksi, että käytät tietysti varovaisuutta tällaisten komponenttien käytössä, älä ole copy-paste-kooderi. Tarkista huolellisesti ohjelmistoon lisäämäsi koodikappale, koska se voi olla rikki korjaamattomana (tai joissakin tapauksissa tahallaan haitallinen - verkkoturvallisuushyökkäykset kutsutaan toisinaan tahattomasti tällä tavalla).
Pysyä ajan tasalla. Varmista, että käytät kaikesta luotettavasta versiosta uusinta versiota, ja suunnittele päivittämään ne säännöllisesti. Tilaa ainakin uutiskirje tuotteeseen liittyvistä uusista tietoturva-aukoista.
Tämä on jälleen tulosuodatuskysymys. Oletetaan, että kohdesivustolla on redirect.php
moduuli, joka ottaa URL-osoitteen GET
parametri. Parametrin käsittely voi luoda URL-osoitteen targetsite.com
joka ohjaa selaimen kohtaan malwareinstall.com
. Kun käyttäjä näkee linkin, hän näkee targetsite.com/blahblahblah
käyttäjän mielestä luotettavaksi ja turvalliseksi napsauttaa. He eivät tiedä, että tämä todella siirtää heidät haittaohjelmien pudotussivulle (tai muulle haittaohjelmalle). Vaihtoehtoisesti hyökkääjä voi ohjata selaimen kohtaan targetsite.com/deleteprofile?confirm=1
.
On syytä mainita, että sanioimattoman käyttäjän määrittelemän syötteen täyttäminen HTTP-otsikkoon saattaa johtaa otsikon injektio mikä on aika huono.
Ehkäisy: Vaihtoehtoja ovat:
Toivon, että olen onnistunut kutittamaan aivojasi hieman tällä viestillä ja esittelemään terveellisen annoksen vainoharhaisuutta ja verkkosivustojen tietoturva-alttiutta.
Tärkein takeaway on, että ikivanhoja ohjelmistokäytäntöjä on olemassa syystä ja mitä sovellettiin päivittäin puskurin ylivuotoihin, sovelletaan edelleen marinoituja merkkijonoja Pythonissa. Suojausprotokollat auttavat kirjoittamaan (enemmän) oikeita ohjelmia, joihin kaikkien ohjelmoijien tulisi pyrkiä.
Käytä tätä tietoa vastuullisesti äläkä testaa sivuja ilman lupaa!
Lisätietoja ja lisää tietyt palvelinpuolen hyökkäykset , Katso: https://www.owasp.org/index.php/Category:Attack .
Palaute tästä viestistä ja sen lieventämisestä on tervetullutta ja arvostettua. Tuleviin liittyviin virkoihin on suunnitteilla erityisesti hajautettu palveluneston esto (DDoS) ja vanhan koulun (ei verkko) tietoturva-aukkoja. Jos sinulla on erityinen pyyntö siitä, millaiseen verkkosuojaukseen haluat kirjoittaa, ota rohkeasti yhteyttä minuun osoitteessa [sähköposti suojattu]
Tässä on verkkosivustojen turvallisuus! Kippis.
Liittyvät:Internet-tietoturvauhat ovat tapoja käyttää verkkotekniikkaa väärin verkkosivuston, sen käyttäjien tai jopa Internetin vahingoksi. Ne johtuvat väärin määritetyistä verkkosivustoista, jotka on vahingossa ohjelmoitu haavoittuvuuksilla tai jotka riippuvat itse haavoittuvista komponenteista.
Kymmenen suosituinta Internet-tietoturvauhkaa ovat injektio- ja todennusvirheet, XSS, epävarmat suorat objektiviitteet, turvallisuuden väärä määritys, arkaluontoisten tietojen altistuminen, toimintotason valtuutuksen puute, CSRF, epävarmat komponentit ja suodattamattomat uudelleenohjaukset.
Varmista, että kaikki uudelleenohjaukset, joita sivustosi tekee (HTTP-otsikoiden, sisällönkuvauskenttien, JavaScriptin jne. Kautta), eivät ole riippuvaisia käyttäjän syötteistä, tai jos niin, että käyttäjän syöttö on puhdistettu esimerkiksi sallittujen luettelon kautta.
CSRF-tunnuksen avulla palvelin tietää, että pyyntö tuli sen oman sivuston käyttäjältä, eikä joltakin muulta verkkosivustolta, jolla käyttäjä vierailee. Tämä johtuu siitä, että se lähetetään jokaisen pyynnön kanssa piilotetun lomakekentän kautta, mikä estää haitallisia sivustoja toimimasta katsojiensa puolesta CSRF-hyökkäysten kautta.
Tunnetaan myös nimellä 'likainen' tai 'epäluotettava', validoimaton syöte on mikä tahansa palvelimelle lähetetty syöttö. Jokainen koodikappale, joka käyttää tällaista syötettä puhdistamatta sitä ensin, on tietoturva-aukko, joka voidaan kääntää sinua, käyttäjiäsi ja jopa viattomia sivullisia vastaan.
SQL-injektio on, kun koodisi laittaa vahvistamattoman syötteen suoraan SQL-käskyyn sen sijaan, että käyttäisit parametrisoitua kyselyä (ts. Paikkamerkkiä sisältävän kyselyn). Onneksi SQL-injektiohyökkäykset ovat yksi helpoimmista lieventää, koska parametrisoitu kysely tuki on rakennettu jokaiseen tietokantaan pääsy kirjastoon.
XSS hyödyntää yleisen verkkosovelluksen 'ominaisuuden' harhaanjohtavia toteutuksia: HTML: n vastaanottaminen yhdeltä käyttäjältä ja sen esittäminen muille käyttäjille. Koska suodattamaton HTML voi sisältää JavaScriptiä, hyökkääjä voi sitten suorittaa koodin muiden käyttäjien puolesta, kun he seuraavan kerran käyttävät kyseistä verkkosovellusta.
Turvallisuuden väärään määritykseen liittyy usein oletusasetusten käyttö, jotka tulisi muuttaa: avaimet ja salasanat, alun perin liberaali asennus- ja testausmukavuus sekä käynnissä olevien tietoturvapäivitysten laiminlyönti.
Tällöin palvelinta ei ole ohjelmoitu vahvistamaan tietyn toiminnon valtuutusta. Usein tämä tulee tietoturvan kautta epäselvyydestä: oletetaan väärin, että jos arkaluontoista ominaisuutta ei näytetä kaikille, potentiaaliset hyökkääjät eivät koskaan saa siitä tietää.
Arkaluontoinen tietojen altistuminen on, kun sovellus (joko omalla virheellään tai hyökkääjän haavoittuvuuden väärinkäytöllä) paljastaa käyttäjän yksityiset tiedot (esim. Luottokorttinumerot) luvattomalle kolmannelle osapuolelle: muille käyttäjille, liikekumppaneille, työntekijöille tai julkinen.