thecodest, Author at The Codest

XSS

Elämme kehysten, ei kielten, aikakautta. Tämä tarkoittaa sitä, että ohjelmoijien pitäisi voida huolehtia vähemmän monista kehitystyön osa-alueista, myös tietoturvasta. Useimmissa nykyisissä backend-kehyksissä on tietoturvamoduulit, joita ulkopuoliset, erikoistuneet yritykset ja suuret yhteisöt testaavat. Siksi, heikentynyt turvallisuustietoisuus voi olla ilmeistä esimerkiksi nuorten ohjelmoijien välillä, jotka ottavat enemmän vastuuta tuotteista, erityisesti freelancerina.

Yksi yleisimmistä hyökkäyksistä sovelluksen asiakaspuolelle on XSS (Cross-Site Scripting). Se toteutetaan syöttämällä ajettavia asiakaspuolen skriptejä verkkosovelluksiin [1] ja se käyttää toteutettuja HTML-renderöintimenetelmiä tai Javascript koodi arvioijat, jotka suorittavat sen. XSS on suhteellisen tuottoisaa, koska siitä voidaan kerätä monia erilaisia tietoja, kuten istunnon evästeitä tai käyttäjätietoja, ja se voi asentaa seurantasovelluksen, kuten keyloggerin, mikä tekee siitä vaarallisen sekä käyttäjille että yritysten omistajille. Joskus XSS:n sallimiseksi sivulle tehdään muitakin hyökkäysmuotoja, kuten SQL-injektio.

Esimerkki

Sivun kirjautumislomake tekee loginName-parametrin, joka lähetetään GET-pyynnössä kirjautumisnimen syötteessä. Arvoa ei käsitellä palvelimella eikä sovelluksen asiakaspuolella. Pyytämällä: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
koodia suoritetaan ja tietoja paljastetaan

Tämä on esimerkki heijastunut XSS-hyökkäys, jossa skriptejä syötetään uhrille toimitetun, erityisesti valmistellun URL-osoitteen kautta, joka näkyy palvelimen vastauksessa. Muita tunnettuja suosittuja hyökkäysmuotoja ovat seuraavat:

Tallennettu XSS suoritetaan palvelinpuolelle tallennetuilla syötetyillä tiedoilla, yleensä sovelluksessa käytettävissä olevilla lomakkeilla. Asiakassovellus renderöi koodia, joka on tallennettu esimerkiksi tietokantaan.
DOM XSS suorittaa XSS-hyökkäyksen ilman palvelinpuolen käyttöä. Artikkelin myöhemmässä osassa keskitymme tähän hyökkäysmuotoon.

Nykyiset haavoittuvuudet React- ja Vue-kirjastoissa

Nykyisissä React/Vue-versioissa oli havaittu kaksi merkittävää ongelmaa, joita ei ollut vielä virallisesti korjattu. Ensimmäinen haavoittuvuus on luonteeltaan samanlainen kaikissa kehyksissä ja liittyy menetelmiin, jotka mahdollistavat raa'an HTML:n renderöinnin malleissa: v-html ja dangerouslySetInnerHTML, respectively, for Vue and React. Each documentation [2] informs readers that unwise usage may expose users to XSS attack. If no other options allow for resolving the problem, ensure that the data is suodatettu ja karannut. Vaikka ne ovat vaarallisia, sinun ei pidä odottaa, että nämä menetelmät korjataan. Käytä niitä omalla vastuullasi.

Vuoden 2018 ensimmäisellä neljänneksellä React:ssä havaittiin suuri virhe, joka mahdollisti koodin suoran suorittamisen asettamalla tag-elementin ominaisuuden. Esimerkkikoodin välittäminen attribuuttien sisällä, kuten esimerkiksi javascript:alert(1) ja renderöidyn linkin suorittaminen suorittaa koodin. Tämä ongelma [4] on edelleen avoin, eikä korjausta ole valmisteltu ja yhdistetty, joten varmista, että koodisi on turvallista. Virallisessa keskustelussa ehdotetuissa esimerkeissä ehdotetaan tapoja tämän ongelman ratkaisemiseksi.

Jos uusimpiin versioihin päivittäminen ei ole mahdollista, varmista, että vanhat ongelmat eivät aiheuta ongelmia varmistamalla, että koodisi ei ole alttiina:

lapsi solmu injektio - React, käyttö React.createElementti [5]
palvelinpuolen renderöinti - React/Vue [6]
CSS-injektio [8]

Kyse on edelleen Javascriptistä. Kyse on edelleen front-end

Älä unohda, että itse kehysten tai kirjastojen lisäksi Javascript-kielessä on joitakin vaarallisia toimintoja, joita on vältettävä tai käytettävä varoen. Ne liittyvät yleensä DOM-käsittelyyn tai skriptin suorittamiseen. eval() edustaa tällaisia lippulaivafunktioita, ja se on erittäin vaarallinen, koska se suorittaa annetun merkkijonokoodin suoraan [9]. Tutki myös koodiasi tarkemmin, kun löydät jonkin näistä funktioista:

document.write
document.writeln
(elementti).innerHTML
(elementti).outerHTML
(elementti).insertAdjacentHTML

Tällaisten haavoittuvien kohtien löytämisessä voi olla apua, jos käytetään lintereitä, joissa on asianmukaiset säännöt. On myös paljon avoimia tai kaupallisia koodianalysaattoreita, jotka voivat auttaa havaitsemaan tietoturva-aukkoja kehitetyssä koodissa.

Riippumatta siitä, mikä kirjasto/kehys valitaan, meidän on silti muistettava front-end-kehitykseen liittyvät perusperiaatteet. Varmista ensinnäkin aina, että ulkoinen koodi, jonka syötät, on peräisin luotettavasta lähteestä. Tilintarkastus riippuvuudet ja valitse ne viisaasti. Jotkin niistä voivat sisältää vakavia haavoittuvuuksia, jotka paljastavat koodisi, vaikka itse koodissa olisi kaikki kunnossa. Voit lukea lisää riippuvuuksien turvallisuudesta täältä:

https://thecodest.co/blog/security-in-javascript-packages/

Pitäisikö sinun silti olla huolissasi?

Kyllä - ja kehotan kaikkia olemaan luottamatta ulkoisiin kirjastoihin tai itseensä tietoturvan suhteen. Riippumatta siitä, kuinka turvalliseksi oletat ohjelmistosi olevan, pyri aina testaamaan sitä mahdollisimman paljon yleisimpien hyökkäysmuotojen osalta [10].

Lue lisää:

5 virhettä, joita sinun tulisi välttää, kun ylläpidät projektia PHP:ssä.

PHP Kehitys. Symfony Console Component - Vinkkejä ja niksejä

Miksi tarvitsemme Symfony Polyfilliä (... ja miksi meidän ei pitäisi)