Verkkosovellusten monimutkaisuus on räjähtänyt viimeisen vuosikymmenen aikana. Ne ovat kehittyneet yksinkertaisista kontteista yhteydenottolomakkeita ja kyselyjä varten täysimittaisiksi sovelluksiksi. Voimme verrata niitä raskaisiin työpöytäsovelluksiin, sekä koossa että suorituskyvyssä. Kun monimutkaisuus kasvaa jyrkästi ja monipuolisten ominaisuuksien sisältävien sovellusten määrä kasvaa, on tullut välttämätöntä investoida paljon aikaa ja huolellisuutta kaikkien sovelluskomponenttien tekemiseksi mahdollisimman turvallisiksi. Internetin käyttäjien valtava kasvu on tehnyt vieläkin tärkeämmäksi tietojen ja sovellusten käyttäjien suojaamisen. Siellä on valtava joukko uhkia, jotka yrittävät hiipiä ja aiheuttaa vakavaa päänsärkyä kaikille mukana oleville.
Vuonna 2001 uusi organisaatio astui vaiheeseen. Sen tavoitteena oli torjua verkkosivustoihin ja sovelluksiin liittyviä turvallisuusongelmia. Se nimettiin asianmukaisesti Open Web Application Security Project (OWASP). Nykyään se julkaisee resursseja, järjestää konferensseja ja ehdottaa verkkojen ja sovellusten turvallisuutta koskevia standardeja. Verkkosovellusten turvallisuuden tosiasiallinen standardi on OWASP Top Ten Project. Siinä luetellaan kymmenen yleisintä turvallisuusuhkaa. Vaikuttavia tekijöitä päätettäessä siitä, mitä pääsee, olivat laaja määrä tietoja ja yhteisöpalautetta. Loppuvuodesta 2017 projekti päivitettiin. Useat uudet ongelmat, jotka ovat kriittisiä monille moderneille verkkosovelluksille, saivat paikkansa, kun taas jotkut ovat paenneet luettelosta.
Tämä artikkeli täydentää alkuperäistä luetteloa ja kuvaa luettelon viimeisimmät muutokset. Siinä kuvataan uhkat, yritetään tarjota selkeitä esimerkkejä ymmärtämisen helpottamiseksi ja ehdotetaan tapoja torjua turvallisuusuhkia.
Ennen vuoden 2017 päivitystä vuoden 2013 luettelo oli viimeisin. Kun otetaan huomioon muutokset verkkosovellusten rakentamisessa ja kulutuksessa, oli järkevää tehdä vain perusteellinen tarkistus. Mikropalvelut vievät palansa piirakasta, ja uudet viileät ja kiiltävät kehykset korvaavat vaniljakooditaisteluvarusteet. Nämä tosiasiat tarkoittavat, että osa aiemmin luetelluista uhista poistettiin ja jotkut uudet otettiin heidän tilalleen.
Päivitämme muistiamme tämän artikkelin kauan unohdetuista asioista ja esittelemme uudet pahat sudet. Historiasta oppiminen on ainoa varma tapa olla toistamatta samoja virheitä.
Sivustojen välinen väärennös (CSRF) on yksi 'häviäjistä' projektin äskettäisessä toistossa. Se meni pois, koska monet modernit verkkokehykset sisältävät CSRF-puolustusmekanismeja. Todennäköisyys altistaa sovelluksesi uhalle vähenee siten nopeasti.
Huolimatta CSRF: n poistumisesta luettelosta, on silti hyvä päivittää muistimme. Varmista, että se ei tule takaisin vahvemmaksi kuin koskaan.
Pohjimmiltaan CSRF on hyväksikäyttö, joka tuntee savupommin. Hyökkääjä huijaa epäilemättömän käyttäjän suorittamaan ei-toivotun pyynnön tai toiminnon verkkosovelluksessa. Yksinkertaisesti sanottuna hyökkääjä pakottaa uhrinsa lähettämään pyynnön kolmannen osapuolen sovellukselle, eikä uhri ole tietoinen koskaan lähetetystä pyynnöstä. Pyyntö voi olla HTTP GET -pyyntö resurssin noutamiseksi tai mikä vielä pahempaa, HTTP POST -pyyntö, joka muuttaa resurssin uhrin hallinnassa. Hyökkäyksen aikana uhri ajattelee, että kaikki on hyvin, useimmiten edes huomaamatta, että jotain tapahtuu taustalla. Kun ilma on poistunut, vahinko on tapahtunut tai jotain puuttuu, eikä kukaan tiedä mitä tapahtui.
Edellisen käyttäjän todennuksen onnistuminen kohdesovelluksessa mahdollistaa ansan tehokkuuden. Käyttäjä oli jossain vaiheessa ennen hyökkäystä kirjautunut sovellukseen. Hakemus lähetti uhrille evästeen muistamaan heidät. Kun verkkoselain lähettää haitallisen pyynnön, eväste lähetetään automaattisesti mahdollisen hyötykuorman mukana, eikä sovellus vastusta pyynnön toimittamista tuntemalleen käyttäjälle.
Yksi tunnetuimmista esimerkeistä on käyttäjän huijaaminen siirtämään rahaa tililtään hyökkääjän hallitsemalle. Käyttäjä kirjautuu verkkopankkijärjestelmään tarkistaakseen tilinsä. Sen jälkeen he käyvät online-foorumissa tarkistaakseen uuden matkapuhelimen arvostelut. Dynaamilla kalastava hyökkääjä lähettää arvostelun, joka sisältää kuvan, jolla on näennäisesti rikki kuvan hyperlinkki. Todellisen hyperlinkin sijaan hyökkääjä käyttää hyperlinkkiä, jota verkkopankkijärjestelmä käyttää sisäisesti rahan siirtämiseen tililtä A tilille B: https://payments.dummybank.com?receiver=attacker&amount=100
Pankkijärjestelmä tekee todennetusta käyttäjästä lähettäjän ja vastaanottaja-parametrin arvon varojen vastaanottajaksi. Hyökkääjä määrittää tietysti offshore-tilinsä vastaanottimeksi.
Koska selain lataa kuvia automaattisesti sivun hahmontamisen yhteydessä, pyyntö tapahtuu taustalla. Jos pankin maksujärjestelmä toteuttaa rahansiirrot HTTP GET -pyynnön avulla, mikään ei estä katastrofia tapahtumasta. Huomaa, että esimerkki on yksinkertainen ja todennäköisesti siirtoja ei käsitellä HTTP GET: n kautta. Hyökkääjä voi kuitenkin vain hieman suuremmilla vaikeuksilla onnistua muuttamaan attribuutin 'action' foorumin HTML-viestien lähetyslomakkeessa. Tämän jälkeen selain lähettää pyynnön pankin maksujärjestelmälle foorumin taustan sijaan.
Rahan varastaminen on vain yksi monista esimerkkeistä. Myös käyttäjien sähköpostiosoitteiden muuttaminen tai tahattomien ostosten tekeminen kuuluvat tähän luokkaan. Kuten usein tapahtuu, sosiaalinen suunnittelu ja osa teknisestä tiedosta ovat tehokas vaikutus ohjelmistosuunnitteluvirheeseen.
Kun suunnittelet järjestelmiäsi, pidä mielessä seuraavat asiat:
Tällä haavoittuvuudella on vielä huonompi vaikutus, kun se yhdistetään sivustojen väliseen komentosarjaan (XSS). Jos hyökkääjä voi pistää haitallista koodia suosikkisivustolle tai -sovellukseen, hyökkäyksen laajuus muuttuu huomattavasti merkittävämmäksi ja vaarallisemmaksi. Vielä kriittisemmin hyökkääjät voivat kiertää joitain CSRF-suojausmekanismeja, jos XSS-hyökkäykset ovat mahdollisia.
Muista, että CSRF ei ole kadonnut, se ei ole vain niin yleistä kuin ennen.
Monet sovellukset ohjaavat tai lähettävät käyttäjän toiminnon päätyttyä saman tai jopa jonkin muun sovelluksen toiseen osaan. Esimerkiksi onnistunut kirjautuminen sovellukseen käynnistää uudelleenohjauksen kotisivulle tai sivulle, jolla käyttäjä alun perin vieraili. Hyvin usein kohde on osa lomakkeen toiminto- tai linkitysosoitetta. Jos uudelleenohjausta tai edelleenlähetystä käsittelevä komponentti ei varmista, että kohdeosoite on todellakin sovelluksen luoma osoite, syntyy mahdollinen uhka. Tämä on tietoturva-aukko, jota kutsutaan 'vahvistamattomiksi uudelleenohjauksiksi'.
Kaksi tärkeintä syytä, miksi vahvistamattomia uudelleenohjauksia ja edelleenlähetyksiä pidetään koskaan vaarallisina, ovat tietojenkalastelu ja tunnistetietojen kaappaaminen. Hyökkääjä voi onnistua muuttamaan uudelleenohjauksen / eteenpäin kohdekohdan ja lähettämään käyttäjän haitalliseen sovellukseen, joka on melkein erotettavissa alkuperäisestä. Epäilemätön käyttäjä paljastaa tunnistetiedot ja luottamukselliset tiedot haitalliselle kolmannelle osapuolelle. Ennen kuin he ymmärtävät tapahtuneen, on jo liian myöhäistä.
Esimerkiksi verkkosovellukset toteuttavat usein sisäänkirjautumisen tuella uudelleenohjauksille viimeksi vierailetulle sivulle. Jotta tämä voidaan tehdä helposti, HTML-lomakkeen toimintoattribuutti saattaa näyttää tältä http://myapp.example.com/signin?url=http://myapp.example.com/pennut . Olet valtava pentujen ihailija, joten oli järkevää asentaa selainlaajennus, joka korvaa verkkosivuston suosikkikuvakkeet suosikkipentujen pikkukuvilla. Valitettavasti se on koira-syö-koira-maailma. Selainlaajennuksen kirjoittaja päätti rahoittaa ehdottoman rakkautesi ja esitellä lisäominaisuuden. Joka kerta, kun vierailet suosikki koiranpennusivustollasi, se korvaa lomakkeen toimintomääritteessä olevan URL-parametrin linkillä heidän omaan sivustoonsa. Koska sivusto näyttää täsmälleen samalta, kun annat luottokorttitietosi ostaaksesi pentujen pelikortteja, rahoitat itse asiassa haitallista hyökkääjää, ei harrastustasi.
Haavoittuvuuden ratkaiseminen edellyttää määränpään sijainnin tarkistamista varmistamalla, että se on tarkoitettu. Jos kehys tai kirjasto suorittaa täydellisen uudelleenohjauksen tai edelleenlogiikan, kannattaa tarkistaa toteutus ja päivittää koodi tarvittaessa. Muussa tapauksessa sinun on suoritettava manuaaliset tarkastukset hyökkäyksiltä suojautumiseksi.
Voit tehdä useita tarkastuksia. Parhaan suojan saavuttamiseksi käytä useiden lähestymistapojen yhdistelmää sen sijaan, että pitäisit kiinni vain yhdessä niistä.
Suurin osa luettelossa olevista asioista voidaan merkitä toteutuksen puutteiksi joko tiedon puutteen tai mahdollisten uhkien riittämättömän perusteellisen tutkimuksen vuoksi. Molemmat syyt johtuvat kokemuksen puutteesta, ja ratkaisu niiden harkitsemiseen tulevaisuudessa on helppoa - muista vain oppia lisää ja olla perusteellisempi. Erityisen hankala vetoaa vaarallisten (mutta hyvin inhimillisten) piirteiden yhdistelmään tehdä liian monta oletusta yhdistettynä vaikeuksiin kehittää ja ylläpitää monimutkaisia tietokonejärjestelmiä. Tähän luokkaan sopiva haavoittuvuus on 'rikkinäinen pääsynvalvonta'.
Haavoittuvuus johtuu valtuutuksen ja pääsyn valvonnan puutteellisesta tai täydellisestä puuttumisesta tietyille sovelluksen osille. OWASP Top Ten -projektin edellisillä iteraatioilla oli kaksi ongelmaa: epävarmat suorat objektiviitteet ja puuttuvat toimintotason käyttöoikeudet. Ne on nyt yhdistetty yhteen niiden samankaltaisuuden vuoksi.
URL-osoitteissa käytetään usein suoria objektiviittauksia operoitavien resurssien tunnistamiseen. Esimerkiksi kun käyttäjä kirjautuu sisään, hän voi vierailla profiilissaan napsauttamalla linkkiä, joka sisältää hänen profiilinsa tunnuksen. Jos sama tunniste on tallennettu tietokantaan ja sitä käytetään profiilitietojen noutamiseen, ja sovellus olettaa, että ihmiset pääsevät profiilisivulle vain kirjautumissivun kautta, URL-osoitteessa olevan profiilin tunnisteen muuttaminen paljastaa toisen käyttäjän profiilitiedot.
Sovellus, joka asettaa poistoprofiilin URL-osoitteen http://myapp.example.com/users/15/delete tekee selväksi, että sovelluksessa on vähintään 14 muuta käyttäjää. Tässä tapauksessa ei ole rakettitiedettä selvittää, miten päästä muiden käyttäjien poistolomakkeeseen.
Ratkaisu tähän ongelmaan on suorittaa jokaisen resurssin valtuutustarkistukset olettaen, että vain tietyt polut voidaan käyttää sovelluksen joihinkin osiin pääsemiseksi. Lisäksi suorien viitteiden poistaminen ja epäsuorien viitteiden käyttö on toinen askel eteenpäin, koska se haitallisten käyttäjien on vaikea selvittää, miten viite luodaan.
Kirjoita kehityksen aikana varotoimenpiteenä yksinkertainen tilakoneen kaavio. Anna tilojen edustaa sovelluksen eri sivuja ja siirtää toimintoja, joita käyttäjät voivat suorittaa. Tämä helpottaa kaikkien erityistä huomiota tarvitsevien siirtymien ja sivujen luetteloimista.
Puuttuva toimintotason käyttöoikeus on hyvin samanlainen kuin epävarmat suorat objektiviitteet. Tässä tapauksessa käyttäjät muokkaavat URL-osoitetta tai muuta parametria yrittäen käyttää sovelluksen suojattuja osia. Jos ei ole asianmukaista pääsynvalvontaa, joka tutkii käyttöoikeustasoja, käyttäjä voi saada etuoikeutetun pääsyn sovellusresursseihin tai ainakin jonkin verran tietoa niiden olemassaolosta.
Lainaus suorien objektiviittausten esimerkistä: Jos sovellus olettaa, että poistolomakkeella käyvä käyttäjä on pääkäyttäjä vain siksi, että pääkäyttäjät näkevät linkin poistolomakkeeseen tekemättä mitään muita valtuuksia, avautuu valtava tietoturva-aukko. Laskeminen joidenkin käyttöliittymäelementtien saatavuuteen ei ole asianmukainen pääsynvalvonta.
Ongelma on ratkaistu varmistamalla aina, että suoritat tarkistuksia sovelluksen kaikissa tasoissa. Etuosa ei välttämättä ole ainoa tapa, jolla haitalliset käyttäjät voivat käyttää verkkotunnuksesi tasoa. Älä myöskään luota käyttäjien välittämiin tietoihin heidän käyttöoikeustasoistaan. Suorita oikea istunnonhallinta ja tarkista aina vastaanotetut tiedot. Se, että pyyntörunko sanoo, että käyttäjä on järjestelmänvalvoja, ei tarkoita sitä, että he ovat.
Rikkinäinen kulunvalvonta yhdistää nyt kaikki ongelmat, jotka liittyvät riittämättömään kulunvalvontaan, olipa kyseessä sovellustaso tai järjestelmätaso, kuten tiedostojärjestelmän väärä määritys.
Uusien käyttöliittymäkehysten tulo ja uusien ohjelmistokehityskäytäntöjen siirtäminen siirtivät turvallisuusongelmat kokonaan uusille aiheille. Uudet tekniikat onnistuivat myös ratkaisemaan joitain yleisiä asioita, joita käsittelimme aiemmin manuaalisesti. Siksi oli hyödyllistä tarkistaa luetteloa ja mukauttaa sitä nykyaikaisten suuntausten mukaan.
XML-standardi tarjoaa vähän tunnetun idean, jota kutsutaan ulkoiseksi kokonaisuudeksi, joka on osa asiakirjan tietotyyppimäärittelyä (DTD). Sen avulla asiakirjan tekijät voivat määrittää linkkejä ulkopuolisiin yksiköihin, joihin voidaan sitten viitata ja sisällyttää pääasiakirjaan. Hyvin yksinkertainen esimerkki olisi:
&bar;
Parsinnan aikana viite &bar;
korvataan määritetyn entiteetin sisällöllä, jolloin saadaan baz
Jos sovellus ottaisi ulkoisen syötteen ja sisältäisi sen ilman tarkastuksia suoraan XML-dokumenttien määrittelyyn, laaja valikoima tietovuotoja ja hyökkäyksiä olisi mahdollista.
Maaginen asia on, että kokonaisuuden ei tarvitse olla yksinkertainen merkkijono - se voi olla viittaus tiedostojärjestelmässä olevaan tiedostoon. XML-jäsennin ottaa mielellään määritetyn tiedoston sisällön ja sisällyttää sen luotuun vastaukseen, mikä saattaa paljastaa arkaluonteisia järjestelmätietoja. Kuten OWASP havainnollistaa, olisi erittäin helppoa saada tietoja järjestelmän käyttäjistä määrittelemällä entiteetti
]>
Tämän haavoittuvuuden erityisen hankala 'ominaisuus' on mahdollisuus suorittaa palvelunestohyökkäys helposti. Yksi helppo tapa tehdä se olisi luetella loputtoman tiedoston sisältö, kuten /dev/random
. Toinen on luoda sarja kokonaisuuksia, joista kukin viittaa edelliseen monta kertaa. Tämä tekee lopullisesta viitteestä mahdollisen hyvin leveän ja syvän puun juuren, jonka jäsentäminen voi tyhjentää järjestelmän muistin. Tämä hyökkäys tunnetaan jopa nimellä Billion Laughs. Kuten Wikipediassa on osoitettu, määritetään sarja nukkekokonaisuuksia, jotka tarjoavat hyökkääjälle mahdollisuuden sisällyttää miljardi lolia lopulliseen asiakirjaan.
&lol9;
XML-ulkoisten entiteettien hyödyntämisen estäminen voidaan tehdä käyttämällä vähemmän monimutkaista tietomuotoa. JSON on hyvä korvaava, edellyttäen, että myös tiettyjä varotoimia toteutetaan sitä vastaan mahdollisesti tapahtuvien hyökkäysten vuoksi. XML-kirjastojen päivittäminen on välttämätöntä yhdistettynä ulkoisen entiteetin käsittelyn ja DTD: n poistamiseen käytöstä. Kuten aina, tarkista ja puhdista epäluotettavista lähteistä tulevat tiedot ennen niiden käyttöä tai sisällyttämistä asiakirjoihisi.
Koodia kirjoittaessaan kehittäjillä on valta hallita kehitettäviä järjestelmiä kirjoittamallaan koodilla. Kuinka mahtavaa olisi hallita kolmansien osapuolten järjestelmien käyttäytymistä, jotka kirjoittavat vain vähän tai ei lainkaan koodia? Kiitos siitä, että ihmiset eivät ole täydellisiä ja että kirjastoissa on puutteita, tämä on ehdottomasti mahdollista.
Sovelluksen tila ja kokoonpano sarjoitetaan ja tallennetaan usein. Joskus selaimet toimivat tallennusmoottoreina, jos sarjatuotteet on kytketty tiiviisti nykyiseen käyttäjään. Sovellus, joka yrittää olla älykäs ja säästää käsittelyaikaa, voi käyttää evästettä merkitsemään, että käyttäjä on kirjautunut sisään. Koska eväste voidaan luoda vasta kirjautumisen onnistumisen jälkeen, on järkevää tallentaa käyttäjänimi evästeeseen. Sitten käyttäjä todennetaan ja valtuutetaan evästeen olemassaolon ja sisällön perusteella. Mikäli ihmisillä ei olisi pahaa aikomusta, mikään ei voisi mennä pieleen. Ollakseni rehellinen, he eivät myöskään saa olla uteliaita.
Jos utelias käyttäjä löysi koneeltaan evästeen, hän voisi nähdä jotain tällaista:
{'username': 'joe.doe', 'expires': '2018-06-01 10:28:16'}
Täysin kelvollinen Python-sanakirja, joka on sarjatu JSON: iin, ei mitään erikoista. Aina utelias käyttäjä voi muuttaa vanhentumispäivää, jotta sovellus ei pakota kirjautumista ulos. Vielä utelias käyttäjä voi yrittää muuttaa käyttäjänimen muotoon 'jane.doe'
. Jos tämä käyttäjänimi olisi ollut, se avaisi kokonaan uuden maailman epäuskoiselle käyttäjälle, jolla on nyt pääsy yksityisiin tietoihin.
Yksinkertainen esimerkki tietojen sarjallisuudesta JSON: ksi ja kaiken läpinäkyvyyden pitämisestä on kaukana pahimmasta, mitä sinulle voi tapahtua. Jos hyökkääjä saavuttaa joitain sarjoitettuja tietoja, he saattavat pystyä muokkaamaan niitä tavalla, joka pakottaa järjestelmän suorittamaan mielivaltaisen koodin.
Oletetaan, että rakennat REST-sovellusliittymää, jonka avulla ihmiset voivat kirjoittaa omia koneoppimismallejaan Pythonissa ja ladata ne palveluun. Palvelu arvioi ladatut mallit ja kouluttaa niitä tietojoukkojesi avulla. Tämän avulla ihmiset voivat käyttää tietokoneresurssejasi ja valtavaa määrää käytettävissä olevia tietojoukkoja mallin nopeaan ja helppoon rakentamiseen.
Palvelu ei tallenna koodia pelkkänä tekstinä. Käyttäjät suolakurkku heidän koodinsa, salaa se yksityisellä avaimellaan ja lähetä se sovellusliittymään koulutusta varten. Kun palvelun on suoritettava malli, se purkaa koodin, purkaa sen ja suorittaa sen. Haastava osa on, että suolakurkkuprotokolla on vaarallinen. Koodi voidaan rakentaa tavalla, joka sallii mielivaltaisen haitallisen koodin suorittamisen deserialisoinnin aikana.
Pythonin suolakurkkuprotokolla antaa luokille mahdollisuuden määritellä menetelmä __reduce__
, joka palauttaa tietoja mukautetun objektin deserialisoinnista. Yksi tuetuista palautusarvoista on kaksi argumenttia: kutsuva ja joukko argumentteja, jotka välitetään kutsuttavalle. Kun otetaan huomioon, että ML-malliharjoittelujärjestelmäsi tarjoaa koodirakenteen mahdollisimman joustavan, on mahdollista kirjoittaa seuraava koodi:
class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))
Kun objekti on deserialisoitava (poistamaton), funktio list
kutsutaan vain yhdellä argumentilla. Toiminto list
on luettelonrakentaja Pythonissa ja funktio itertools.count
tuottaa rajattoman arvojen iteraattorin, joka alkaa välitetystä parametrista. Äärettömän iteraattorin muuttamisesta rajalliseksi luetteloksi voi olla tuhoisia seurauksia järjestelmän suorituskyvylle ja vakaudelle.
Ainoa todellinen parannuskeino tämän tyyppiselle haavoittuvuudelle on päättää olla deserialisoimatta ulkoisista lähteistä peräisin olevia tietoja. Jos tämä ei ole mahdollista, on suositeltavaa käyttää tarkistussummaa tai digitaalista allekirjoitusta estämään haitallisen käyttäjän mahdollisesti muokkaamien tietojen deserialisaatio. Yritä myös luoda hiekkalaatikkoympäristö irrotettuna pääjärjestelmästäsi, jotta voidaan rajoittaa mahdollisten ongelmien vaikutuksia.
Kun käytät ulkoisia kirjastoja tietojen deserialisoimiseksi, esimerkiksi XML: stä tai JSON: sta, yritä valita ne, joiden avulla voit tehdä objektityypin tarkistuksia ennen varsinaisen deserialisointimenettelyn suorittamista. Tämä voi saada kiinni odottamattomia kohdetyyppejä, joiden ainoa tarkoitus on vahingoittaa järjestelmääsi.
Kuten kaikkien muiden sovelluksesi suorittamien toimintojen kohdalla, ota käyttöön kattava kirjaaminen ja valvonta. Usein tapahtuvat deserialisaatiot tai epäonnistuminen normaalia enemmän ovat signaaleja siitä, että jotain pahaa tapahtuu. Ota ongelmat ajoissa.
Kuinka paljon aikaa vietät varmistaaksesi, että kirjaat kaikki sovelluksessasi esiintyvät varoitukset ja virheet? Tallennatko vain koodissa tapahtuvia virheitä vai kirjaatko myös vahvistusvirheitä? Mitä tapahtuu, kun verkkotunnuksesi liiketoimintasääntöjä ei noudateta? Sovelluksen virheellisten ja epäilyttävien toimintojen jatkamatta jättäminen aiheuttaa tietoturva- ja tietovakauden.
Kuvittele seuraava skenaario. Hakemuksesi sisältää kirjautumissivun, kuten useimmat tekevät. Lomakkeessa on kaksi kenttää, yksi sähköpostin syöttämistä varten ja toinen salasanaa varten. Jos käyttäjä yrittää kirjautua sisään ja antaa väärän salasanan, hän voi yrittää uudelleen. Valitettavasti virheellisten yritysten määrää ei ole rajoitettu, joten kirjautumissivua ei lukita N epäonnistuneen yrityksen jälkeen. Hyökkääjä voi käyttää tätä mahdollisuutta ja antaa yhden oikean sähköpostin, jatkaa salasanojen kirjoittamista sateenkaaritaulukosta, kunnes yksi yhdistelmä onnistuu lopulta. Tämä hyökkäys ei toimi, jos sovelluksesi on riittävän turvallinen ja hajautat salasanat ennen kuin syötät ne tietokantaan. Onko sinulla kuitenkin mekanismi tunkeutumisen tunnistamiseksi?
Se, että tämä yksi yritys epäonnistui avaamaan kirjautumissivusi, ei tarkoita, että joku toinen ei. Sisäänkirjautumissivu ei todennäköisesti ole ainoa potentiaalinen takaovesi. Jos ei jotain muuta, joku saattaa yrittää käyttää rikkinäistä kulunvalvontaa sinua vastaan. Jopa täydellisesti muotoiltujen sovellusten tulisi tietää, että joku yrittää hyökätä heitä vastaan, vaikka se ei ehkä olekaan mahdollista. Se on kuitenkin aina.
Suorita paras mahdollinen suojautumisesi tällaisilta hyökkäyksiltä seuraavasti:
Kun ratkaiset ongelmaa, ole erityisen varovainen, ettei virhelokeja vuoda ulkoisille käyttäjille. Jos et tee niin, altistut arkaluontoisille tiedoille. Kirjaamisen ja seurannan pitäisi auttaa sinua ongelmien ratkaisemisessa, etkä hyökkääjiä tekemään työnsä tehokkaammin.
On tärkeää olla tietoinen verkkosovellusten mahdollisista uhista ja haavoittuvuuksista. Vielä tärkeämpää on aloittaa niiden tunnistaminen sovelluksissa ja poistaa korjaustiedostot.
Huomio sovellusten turvallisuuteen on tärkeä osa ohjelmistokehitysprojektin kaikkia vaiheita. Ohjelmistoarkkitehtien, kehittäjien ja testaajien on kaikkien sisällytettävä ohjelmistojen testausmenetelmät työnkulkuihinsa. Turvallisuusriskien vähentämiseksi on hyödyllistä käyttää tietoturvatarkistusluetteloita ja automaattisia testejä ohjelmistokehitysprosessin asianmukaisiin vaiheisiin.
Olitpa analysoimassa olemassa olevaa sovellusta tai kehittämässä uutta uutta, sinun tulisi tutkia sitä OWASP-sovelluksen tietoturvan varmistusstandardiprojekti (ASVS). Projektin tavoitteena on kehittää standardi sovellusten turvallisuustarkastukselle. Standardissa luetellaan testit ja vaatimukset suojattujen verkkosovellusten kehittämiselle. Testeille on määritelty tasot yhdestä kolmeen, missä yksi tarkoittaa vähiten vaaraa ja kolme suurinta mahdollista uhkaa. Luokittelun avulla sovellusten johtajat voivat päättää, mitkä uhat ovat todennäköisempiä ja tärkeämpiä. Kutakin testiä ei tarvitse sisällyttää kuhunkin sovellukseen.
Sekä uudet että nykyiset verkkosovellushankkeet, etenkin ketterien periaatteiden mukaiset, hyötyvät jäsennellystä suunnitelmasta, jolla pyritään suojaamaan sovelluksiaan. OWASP ASVS -testien suunnittelu on helpompaa, jos päätät käyttää niitä OWASP-tietoturvakehys . Se on tietoturvatestaukseen suuntautuneiden sprinttien hallintaohjelma, johon sisältyy joukko esimerkkejä yleisten turvallisuusongelmien ratkaisemisesta, ja helposti seurattavat tarkistusluettelot, jotka perustuvat OWASP ASVS: ään.
Jos olet juuri alkanut tutkia verkkosovellusten tietoturvaa ja tarvitset turvallisen hiekkalaatikkoleikkipaikan, käytä OWASP: n verkkosovelluksen toteutusta - WebGoat . Se on tarkoituksellisesti epävarma verkkosovelluksen toteutus. Sovellus opastaa sinut oppitunneilla, ja jokainen oppitunti keskitetään yhteen turvallisuusuhkaan.
Varmista sovelluskehityksen aikana, että:
Vaikka nimestä käy ilmi, OWASP Top Ten -hankkeessa luetellaan vain kymmenen tietoturva-aukkoa, tuhansia mahdollisia ansoja ja takaovia uhkaa sovelluksiasi ja mikä tärkeintä, käyttäjiäsi ja heidän tietojaan. Varmista, että olet etsimässä ja päivitä tietosi jatkuvasti, koska tekniikan muutoksilla ja parannuksilla on sekä haittoja että haittoja.
Voi, ja älä unohda, maailma ei ole mustavalkoinen. Turvallisuushaavoittuvuudet eivät tule yksin; ne ovat usein toisiinsa. Altistuminen yhdelle tarkoittaa usein, että joukko muita on kulmien takana odottamassa ruman päänsä nostamista ja joskus, vaikka se ei olekaan sinun syytäsi, koska järjestelmän turvallisuuden kehittäjä , sinun on edelleen tarkoitus korjata porsaanreikiä tietoverkkorikollisuuden hillitsemiseksi. Katso esimerkiksi Hakkeroidut luottokorttinumerot ovat edelleen Google-käytettävissä .
Lyhenne OWASP tarkoittaa Open Web Application Security -projektia. Se on verkkoyhteisö, joka tuottaa oppimisresursseja ja työkaluja, jotka käsittelevät verkkosovellusten turvallisuutta.
OWASP Top Ten on luettelo yleisimmistä verkkosovellusten tietoturvauhista, jonka on laatinut tietoturva-asiantuntijat ottaen huomioon yhteisön palaute.
Sivustojen välinen pyyntöjen väärentäminen on hyökkäys, joka saa käyttäjät suorittamaan ei-toivottuja pyyntöjä sovellukseen, jossa heidät todennetaan.
Vahvistamattomat uudelleenohjaukset ja edelleenlähetykset ovat tietoturva-aukko, jonka avulla hyökkääjät voivat ohjata käyttäjiä suojaamaan verkkosovelluksia, pääsemään suojattuihin sovellusresursseihin tai varastamaan etuoikeutettuja käyttäjätietoja.
Injektiohyökkäys on eräänlainen hyökkäys, jonka avulla hyökkääjät voivat injektoida ei-toivottua koodia sovellukseen. Sovellukseen perustuvia hyökkäyksiä on useita, joista yleisimmät ovat SQL-injektio ja sivustojen välinen komentosarja.
Deserialisaatio on prosessi, jolla tavuvirta muunnetaan muistiin ladatuksi koodiksi. Alkuperäinen tavuvirta tuotetaan päinvastaisella sarjallisuusprosessilla.
Hyökkäysvektori tarkoittaa tapaa hyödyntää sovellusten tietoturva-aukkoja. Virheellisen HTML img -elementin injektointi, joka tekee pyynnön pankin API-resurssille, on esimerkki CSRF-hyökkäyksessä käytetystä hyökkäysvektorista.
XML-entiteetti on mekanismi, jolla määritetään aliaksen kohteelle, jota käytetään XML-asiakirjassa tai asiakirjatyypin määrittelyssä (DTD).
Ulkoinen yksikkö on eräänlainen XML-entiteetti. Asiakirjojen tekijöille on helppo sisällyttää ulkoisia resursseja asiakirjoihinsa käyttämällä yhtenäistä resurssitunnistetta (URI).
OWASP WebGoat on tarkoituksellisesti epävarma verkkosovelluksen toteutus, joka toimii oppimismekanismina web-sovellusten suojaustuntien opettamiseen.