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.

Ongelmat poistettu OWASP Top 10 -luettelosta

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 pyyntö väärentää

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:

• Älä käyttää HTTP GET -pyyntöjä kapseloimaan resursseja muokkaavia toimintoja. Käytä näitä pyyntöjä vain tietojen hakemiseen. Muista, että peukalon sääntö on tehdä GET-pyynnöistä idempotentteja.
• Tehdä , kun tietoja siirretään sisäisesti HTTP POST -pyyntöjen avulla, ne lähettävät yleensä tietoja JSON-, XML- tai muussa muodossa kuin koodaavat parametreja kyselymerkkijonona. Ei-triviaalin datamuodon käyttäminen vähentää vaaraa, että joku luo väärennetyn HTML-lomakkeen, joka lähettää tiedot palveluun.
• Tehdä Muista luoda ja sisällyttää ainutlaatuinen ja arvaamaton tunnus HTML-lomakkeisiin. Näiden tunnusten tulisi myös olla yksilöllisiä jokaiselle pyynnölle. Tällaisten tunnusten olemassaolon ja oikeellisuuden tarkistaminen pienentää uhkien esiintymisen riskiä. Hyökkääjien on käytettävä järjestelmääsi ja otettava tunniste suoraan sieltä saadakseen tunnuksen käyttöön ja käyttääkseen sitä väärennetyissä pyynnöissään. Koska tunnukset ovat vain kertaluonteisia, he eivät voi käyttää niitä uudelleen haitallisessa koodissa.

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.

Vahvistamattomat uudelleenohjaukset

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ä.

• Vahvista lähtevä URL ja varmista, että se osoittaa ohjaamaasi verkkotunnukseen.
• Koodaa ne käyttöliittymässä sen sijaan, että käyttäisit eksplisiittisiä osoitteita, purkaa ja vahvista ne sitten käyttöliittymässä.
• Valmista luotettujen URL-osoitteiden sallittujen luettelo. Sallii edelleenlähetykset ja uudelleenohjaukset vain sallittujen luetteloon. Mieluummin tämä lähestymistapa mustan listan ylläpitämiseen. Mustat listat täytetään yleensä uusilla kohteilla vasta, kun tapahtuu jotain pahaa. Valkoiset luettelot ovat rajoittavampia.
• Käytä LinkedInin ja joidenkin muiden sovellusten käyttämää lähestymistapaa: Esitä käyttäjillesi sivu, jossa heitä pyydetään vahvistamaan uudelleenohjaus / edelleenlähetys, tehden selväksi, että he lähtevät sovelluksestasi.

Yhdistetyt kysymykset

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'.

Rikkinäinen kulunvalvonta

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.

Suorat objektiviitteet

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.

Toimintotason kulunvalvonta puuttuu

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.

Uudet ongelmat OWASP Top 10 -luettelossa

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-ulkoiset entiteetit

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.

Epävarmat aavistamiset

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.

Riittämätön kirjaaminen ja seuranta

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:

• Kirjaa kaikki sovelluksessa esiintyvät viat ja varoitukset, olivatpa ne koodiin heitettyjä poikkeuksia tai pääsynvalvonta-, tarkistus- ja tietojen käsittelyvirheitä. Kaikki tallennetut tiedot on toistettava ja säilytettävä riittävän kauan, jotta jälkitarkastus ja analyysi ovat mahdollisia.
• Muoto- ja pysyvyyskerroksen määrittäminen on tärkeää. Suuren tiedoston, jolla on mielivaltainen tekstimuoto, on helppo saavuttaa; sen käsittely myöhemmin ei ole. Valitse tallennusvaihtoehto, joka helpottaa tietojen tallentamista ja lukemista, ja muoto, joka mahdollistaa helpon ja nopean (de) sarjallisuuden. JSON: n tallentaminen tietokantaan, joka mahdollistaa nopean pääsyn, helpottaa käyttöä. Pidä tietokanta pienenä varmuuskopioimalla sitä säännöllisesti.
• Jos olet tekemisissä tärkeiden ja arvokkaiden tietojen kanssa, pidä kirjaa toiminnoista, joita voidaan seurata lopullisen tilan tarkastamiseksi. Ota käyttöön mekanismi tietojen manipuloinnin estämiseksi.
• Pyydä taustajärjestelmiä analysoimaan lokit ja ilmoittamaan, jos jotain tulee esiin. Tarkistukset - jotka ovat yhtä yksinkertaisia ​​kuin testaus, jos käyttäjä yrittää toistuvasti käyttää sovelluksen suojattua osaa - auttavat. Älä kuitenkaan ylikuormita järjestelmää nuken tarkastuksilla. Valvontajärjestelmät on käytettävä erillisinä palveluina, eivätkä ne saa vaikuttaa pääjärjestelmän suorituskykyyn.

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.

Seuraavat vaiheet

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ä:

• Tunnista ja priorisoi uhat. Määritä, mitä uhkia voi realistisesti tapahtua, ja aiheuta riski sovelluksellesi. Priorisoi uhkat ja päättää, mitkä ansaitsevat eniten kehitystä ja testausta. Ei ole mitään järkeä laittaa paljon vaivaa riittämättömän kirjaamisen ja valvonnan ratkaisemiseen, jos palvelet staattista blogia.
• Arvioi sovelluksesi arkkitehtuuri ja muotoilu. Joitakin haavoittuvuuksia on erittäin vaikea ratkaista sovelluskehityksen myöhemmissä vaiheissa. Esimerkiksi, jos aiot suorittaa kolmannen osapuolen koodin etkä aio käyttää hiekkalaatikkoympäristöä, on erittäin vaikeaa puolustautua epävarmasta deserialisaatiosta ja injektiohyökkäyksistä.
• Päivitä ohjelmistokehitysprosessi. Verkkosovellusten uhkien testaamisen on oltava mahdollisimman automaattista. On hyödyllistä lisätä CI / CD-työnkulkuja automaattisilla testeillä, jotka yrittävät löytää suojausreikiä. Voit jopa käyttää olemassa olevaa yksikötestausjärjestelmääsi turvatestien kehittämiseen ja suorittamiseen säännöllisin väliajoin.
• Opi ja paranna. Luettelo ongelmista ja haavoittuvuuksista ei ole staattinen eikä ehdottomasti rajoitu kymmeneen tai viidentoista uhkaan. Uudet toiminnot ja ideat avaavat oven uuden tyyppisille hyökkäyksille. On tärkeää lukea verkkosovellusten tietoturvamaailman nykyisistä trendeistä pysyäksesi ajan tasalla. Käytä mitä opit; muuten tuhlataan aikaa.

Johtopäätös

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ä .

Perustietojen ymmärtäminen

Mitä OWASP tarkoittaa?

Lyhenne OWASP tarkoittaa Open Web Application Security -projektia. Se on verkkoyhteisö, joka tuottaa oppimisresursseja ja työkaluja, jotka käsittelevät verkkosovellusten turvallisuutta.

Mikä on OWASP top 10?

OWASP Top Ten on luettelo yleisimmistä verkkosovellusten tietoturvauhista, jonka on laatinut tietoturva-asiantuntijat ottaen huomioon yhteisön palaute.

Mikä on CSRF-hyökkäys?

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.

Mitä ovat vahvistamattomat uudelleenohjaukset ja edelleenlähetykset?

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.

Mikä on injektiohyökkäys?

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.

Mikä on deserialisaatio?

Deserialisaatio on prosessi, jolla tavuvirta muunnetaan muistiin ladatuksi koodiksi. Alkuperäinen tavuvirta tuotetaan päinvastaisella sarjallisuusprosessilla.

Mikä on hyökkäysvektori?

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.

Mikä on entiteetti XML: ssä?

XML-entiteetti on mekanismi, jolla määritetään aliaksen kohteelle, jota käytetään XML-asiakirjassa tai asiakirjatyypin määrittelyssä (DTD).

Mikä on ulkoinen yksikkö?

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).

Mikä on OWASP WebGoat?

OWASP WebGoat on tarkoituksellisesti epävarma verkkosovelluksen toteutus, joka toimii oppimismekanismina web-sovellusten suojaustuntien opettamiseen.