XSS on eräänlainen koodinsyöttö, eli hyökkääjä onnistuu pistämään oman haitallisen koodin (yleensä JavaScript) sivuston tarjoamaan luotettuun koodiin (HTML, CSS, JavaScript). Se on samanlainen kuin SQLi, koska sen aiheuttaa dynaamisesti rakennettu koodi, ts. SQL-käskyt, HTML-sivut jne.

Mutta vaikka SQLin ratkaisemiseksi on vakiintuneita tekniikoita (ts. Käytä parametria sitominen), XSS: n kanssa on vielä vaikeampaa. Suojautua XSS: ää vastaan ​​jokaisen käyttäjän hallitseman syötteen on oltava pakotettu kunnolla, mikä on paljon vaikeampaa kuin miltä se kuulostaa:

• Pakenemissäännöt riippuvat kontekstista, ts. HTML, HTML-attribuutti, XHTML, URL, komentosarja, Kaikilla CSS-konteksteilla on erilaiset pakenemissäännöt.
• Nämä asiayhteydet voidaan sisäkkäin, ts. <a href = javascript: XXX > on JavaScript-konteksti URL-kontekstissa HTML-määritteen sisällä. .
• Tämän lisäksi sinulla on koodaussäännöt merkkeille (UTF-8, UTF-7, latin1, ...), jotka taas voivat olla kontekstikohtaisia.
• Konteksti ja koodauksen on oltava tiedossa tulosta rakennettaessa: vaikka useimmat mallimoottorit tukevat HTML-koodien oikeaa poistumista, he eivät useinkaan ole tietoisia ympäröivästä kontekstista eivätkä siten voi soveltaa kontekstikohtaisia ​​pakenemissääntöjä.
• Tämän lisäksi selaimet voivat käyttäytyä hieman eri tavalla pakenemisen tai koodaamisen suhteen.
• Sen lisäksi löydät usein kasvaneesta koodista ilman erillistä logiikkaa ja pr huomautus siitä, että HTML-fragmentit tallentuvat tietokantaan, eikä kehittäjälle ole aina selvää, onko tietty arvo jo HTML-puhdas vai onko siitä välttämätöntä välttää.

Ja vaikka on joitain yksinkertaisia ​​tapoja Suojautua XSS: ltä suunnittelulla (erityisesti Content-Security-Policy) nämä toimivat vain uusimpien selainten kanssa, kehittäjän on nimenomaisesti sallittava ne ja usein tehokkaita vasta, kun koodiin on tehty suuria (ja kalliita) muutoksia (kuten sisäisen komentosarjan poistaminen) .

Mutta silti on hyvät mahdollisuudet tehdä se oikein, jos sinulla on kehittäjät, joilla on asianmukainen tietämys ja pystyt aloittamaan tyhjästä käyttämällä moderneja työkalupaketteja, jotka jo huolehtivat XSS: stä. Valitettavasti monissa tapauksissa on olemassa vanha koodi, jota on vain jatkettava. Ja kehityksen tekevät yleensä kehittäjät, jotka eivät ole tietoisia XSS: stä lainkaan tai eivät tiedä kaikkia sudenkuoppia.

Niin kauan kuin verkkokehitystä tehdään ympäristöissä, jotka ovat hyvin herkkiä kustannuksille ja ajalle, on pienet mahdollisuudet, että tämä muuttuu. Tavoitteena tässä ympäristössä on saada koodi toimimaan lainkaan lyhyessä ajassa ja pienillä kustannuksilla. Yritykset kilpailevat yleensä ominaisuuksien ja markkinoille saattamisen ajan perusteella, eivätkä kuka turvallisimpana tuotteena. XSS-suojaus tarkoittaa tällä hetkellä vain lisäkustannuksia, joista ei ole selvää hyötyä monille johtajille.

Se näyttää helpolta, mutta on vaikeaa

Ensinnäkin hyökkäyspinta on valtava. Sinun on käsiteltävä XSS: ää, jos haluat näyttää käyttäjän syötteen HTML-muodossa missä tahansa. Tätä tekevät melkein kaikki sivustot, elleivät ne ole rakennettu pelkästään staattisessa HTML-muodossa.

Yhdistä tämä siihen tosiasiaan, että vaikka XSS saattaa tuntua helpolta käsitellä, se ei ole. OWASP XSS -huijausarkki on 4 000 sanaa. Tarvitset melko suuren arkin, johon kaikki teksti mahtuu.

Monimutkaisuus syntyy, koska XSS toimii eri tavoin eri tilanteissa. Sinun on tehtävä yksi asia, jos lisäät epäluotettavia tietoja JavaScriptiin, yksi asia, jos lisäät attribuuttiarvoihin, toinen asia, jos lisäät tunnisteiden väliin jne. OWASP listaa kuusi erilaista asiayhteyttä, jotka kaikki tarvitsevat erilaisia ​​sääntöjä, sekä useita asiayhteyksiä mihin sinun ei pitäisi koskaan lisätä tietoja.

Sillä välin kehittäjät etsivät aina panacheaa ja hopeamyllyjä. He haluavat poistaa kaiken kovan työn yhdeksi sanitize () -toiminnoksi, johon he voivat aina kutsua epäluotettavia tietoja, kutsua niitä päiväksi ja jatkaa todellista ohjelmointia. Mutta vaikka monet tällaiset toiminnot on koodattu, yksikään niistä ei toimi.

Haluan toistaa: XSS saattaa tuntua helposti käsiteltävältä, mutta se ei ole. Suurin vaara on kyseisen lauseen ensimmäisessä osassa, ei toisessa. Ymmärretty yksinkertaisuus kannustaa kehittäjiä tekemään omat kotiominaisuutensa - omat henkilökohtaiset sanitize () -funktiot, täynnä yleistyksiä, epätäydellisiä mustia listoja ja virheellisiä oletuksia. Suodatit javascript: URL-osoitteista, mutta ajattelitko vbscript: ? Tai javaSCripT: ? Koodasit lainausmerkit, mutta muistako liittää attribuutin arvon lainausmerkkeihin? Entä merkkikoodaukset?

Tilanne on melko samanlainen kuin SQLi. Kaikki etsivät yhtä sanitaatiotoimintoa hallitsemaan kaikkia, olipa se nimeltään addlasheshes , mysql_escape_string tai mysql_real_escape_string . Se on rahtikulttiturva, jossa ihmisten mielestä riittää, että rituaalisesti kutsutaan oikea toiminto rauhoittamaan jumalia sen sijaan, että se omaksuu ongelman monimutkaisuuden.

Vaarana ei siis ole se, että kehittäjät eivät ole onnellisesti tietoisia XSS: stä. He luulevat saavansa tilanteen hallintaan, koska hei, ohjelmoin sen toiminnon.

Mutta miksi se on vaikeaa?

Verkko kärsii ongelmasta rakenne (HTML), esitys (CSS) ja dynamiikka (JavaScript) sekoitetaan pitkiksi tekstijonoiksi, jotka laitamme .html -tiedostoihin. Tämä tarkoittaa, että on monia rajoja, jotka voit ylittää siirtyäksesi kontekstista toiseen.

Tämä on jälleen sama asia kuin SQLissä. Sekoitat ohjeet ja parametriarvot yhteen merkkijonoon. SQLin lopettamiseksi tajusimme, että meidän on erotettava nämä kaksi kokonaan eikä koskaan sekoitettava niitä - toisin sanoen käytettävä parametrisoituja kyselyitä.

XSS-ratkaisu on samanlainen:

1. Erota komentosarjat HTML: stä.
2. Poista HTML-koodin sisäiset komentosarjat käytöstä.

Olemme luoneet helpon tavan tehdä toinen osa - sisältöturvakäytäntö. Sinun tarvitsee vain asettaa HTTP-otsikko. Mutta ensimmäinen osa on vaikea. Vanhan verkkosovelluksen täydellinen uudelleenkirjoittaminen voi olla helpompaa kuin komentosarjojen irrottaminen kirurgisesti HTML: stä. Joten silloin on helpompaa luottaa vain siihen taikaan sanitize () ja toivoa parasta.

Mutta hyvä uutinen on, että uudemmat sovellukset kehitetään usein tiukempien käytäntöjen mukaisesti CSP: n mahdollista, ja melkein kaikki selaimet tukevat sitä nyt. En sano, että haavoittuvien sivustojen prosenttiosuus laskee 0 prosenttiin, mutta toivon, että se laskee paljon 60 prosentista tulevina vuosina.

TL; DR: Tämä muuttui melko pitkäksi ääneksi. Etkö ole varma, onko täällä paljon hyödyllistä tietoa - lue vain Steffen Ullrichsin hyvä vastaus, jos haluat selkeän analyysin.

Oma mielipiteeni turvallisuudesta ja XSS: stä:

1. Ohjelmointisääntö: Et voi tietää kaikkea. Ennemmin tai myöhemmin aiot tehdä virheen.
2. Ohjelmoijan sääntö: Ohjelmoija työskentelee 12 tuntia päivässä: 3 keskustelee muiden ohjelmoijien kanssa satunnaisia ​​asioita, 3 ajattelee muita asioita, 3 keskustelee siitä, mitä sen pitäisi koodata, 3 se ohjelmoi .... projektit tehdään 12 tuntia päivässä lähes pysähtymättä.
3. XSS on yksinkertainen. Ja XSS: ää odottaa paljon syötteitä.
4. Turvallisuus on edelleen viimeinen ja suurimman osan ajasta pidetään puutteellisena.

Kuten mainitsit vastauksessasi vastaavaan viestiisi ( SQL-injektio on 17 vuotta vanha. Miksi se on edelleen olemassa?):

Ei ole SQLin yleinen korjaus koska inhimilliselle tyhmyydelle ei ole korjausta

Kehittäjät saattavat joskus olla laiskoja tai huolimattomia, mikä saa heidät tarkistamaan kehittämänsä sovelluksen.

Toinen suosittu syy on se, että kehittäjät eivät tiedä tietoturvaongelmasta. He eivät koskaan käyneet mitään turvallisuuskoulutusta, joten he eivät tiedä mikä on mahdollinen turvallisuusuhka ja mikä ei. Ja yrityksille, jotka eivät ymmärrä tunkeutumistestin merkitystä, tämä tietoturvatiedon puute on itsessään mahdollinen uhka.

Yksinkertaiset tietoturvakysymykset, kuten SQLI ja XSS, korjataan vasta, kun yritys päättää käyttää aikaa koodien tarkistamiseen ja testaamiseen. Siihen asti 65% kaikista verkkosivustoista kärsii maailmanlaajuisesti XSS-haavoittuvuudesta.

Perusongelma

Verkkoa ei yksinkertaisesti ole suunniteltu mahdollistamaan turvallista usean tekijän tai monipuolista vuorovaikutusta. Kukaan ei puhunut sisällön erottamisesta esityksestä vasta 1990-luvun lopulle saakka. Siihen mennessä, kuten QWERTY-näppäimistö, olimme periaatteessa juuttuneet olemassa olevaan järjestelmään ilman mitään syytä. Kukaan ei halunnut "rikkoa verkkoa", joten virheet kopioitiin ja siirrettiin selaimille, jotka olivat "vektorivektorin" ulkopuolella.

Raskauttava tekijä

Ennen ~ 2005, käytännössä kaiken, mitä näet tietyllä verkkosivustolla, ovat kirjoittaneet tai hyväksyneet sivustoa hallitsevat ihmiset. Kun Web2.0-liike eteni ja ihmiset vaativat vuorovaikutusta (ainakin lisää kommentteja, tule!), Paine lisätä näitä ominaisuuksia olemassa oleviin sivustoihin oli suuri. Verkkoyhteisöt tekivät kaikkensa tyydyttääkseen pomon vaatimukset täyttääkseen tehtävän, josta he eivät tienneet mitään: turvallista vuorovaikutusta. Ja jonkin aikaa, luultavasti liian kauan, he pääsivät siitä. Kuinka moni ihmisistä ostaa murtovaroittimia ennen , joihin on edes murskattu?

Nykyajan ajat

CSP: n käyttäminen suuresti vähentää toisen pallon pudottamisen aiheuttamia haittoja. Tämä ei tarkoita, että sinun tulisi luopua varmennuksesta ja puhtaanapidosta millään tavalla Save As .. -kopioiden, välimuistiin tallennettujen otsikoiden jne. Vuoksi, mutta se tarkoittaa, että voit olla paljon turvallisempi muutaman tunnin ponnistelulla. Kyllä, otsikko on pitkäkestoinen ja aluksi hämmentävässä muodossa, mutta sijoita tunti tai kaksi, mitä kuluttaa grokki, ja muutama muu, joka tarvitaan sivustosi testaamiseen. CSP: tä on todella helppo testata, koska voit suorittaa hiljaisen vain varoittavan ajon (etsiä sitä).

Jos heität CSP: tä ja ryhdyt perinteisiin toimenpiteisiin, vanhat selaimet kuolevat, kun kiintolevy lakkaa pyörimästä , ja me kaikki elämme turvallisesti ja onnellisesti ...

Toiset ovat koskettaneet klassisia kysymyksiä, jotka liittyvät ihmisten muille ihmisille suunnittelemiin järjestelmiin: Todellisuus on laiskuutta ja - toisinaan - tyhmyyttä yhdistettynä "Miksi näin tapahtuisi minulle?" ylimielisyys.

Voi, kuinka monta tuntia elämästäni on käytetty järjestelmien korjaamiseen ja - mikä tärkeintä - taistelemiseen johdon kanssa saadaksemme korjausjärjestelmille varatun ajan / resurssit, jotta ne voivat olla "luodinkestäviä".

Ja olen onnekas tältä osin: Vaikka olen turhautunut taistelemaan organisaation johdon kanssa järjestelmän korjaamiseksi, monet paikat palkkaavat kehittäjiä kehittämään järjestelmää, mutta eivät sen jälkeen pidä perus- (ja tylsiä) huolto on jotain, johon kannattaa sijoittaa. Miksi maksaa tekniikalle kuukausittainen ylläpitäjä järjestelmän ylläpitämiseksi, kun on usein halvempaa antaa järjestelmän seistä, kunnes se kaatuu, ja sitten jahdata korjausta keskellä rikkomusta?

Pieni pari ennaltaehkäisyä, joka on parempi kuin paunan parannuskeino, vie usein takapenkin ihmisille, jotka ovat penniäkään, punta-typeriä.

Tästä huolimatta parasta, mitä kukaan järjestelmän ylläpitäjä voi tehdä, on vakava katastrofi (tai muu kuin katastrofi) elvytyssuunnitelma. Pyydä koodiversiota hallitsemaan, palvelimen käyttöönoton määritys automatisoitava valmistelukomentosarjassa ja varmuuskopiot tietokannoista. Tällä tavoin, jos / kun järjestelmä kaatuu, siivous on nopeaa eikä tylsää katastrofia.

Vaarallisten tietoturva-aukkojen, kuten SQLI ja XSS, tarkka tunnistaminen SDLC: n koodin käyttöönottovaiheessa rajoittuu edelleen ohjelmointikielen tyyppiin.

• Tällaisten haavoittuvuuksien staattinen analyysi tehdään laajimmin PHP: ssä.
• Joissakin dynaamisissa menetelmissä käytetään sumeaja tekniikoita testaus- tai käyttöönottovaiheessa.

Valitettavasti molempien menetelmien tarkkuus on edelleen melko rajallinen. Lisäksi XSS- ja SQLI-haavoittuvuudet kohdistuvat tietokonesovelluksiin, ja ne voivat näkyä niin monissa naamioiduissa muodoissa, joita ohjelmistokehittäjät eivät tunne. Sellaisena en usko, että kyse on tyhmyydestä. Voin vakuuttaa, että jotkut yritykset ovat jo kouluttaneet kehittäjät turvalliseen ohjelmointiin, mutta eivät voi täysin estää näitä heikkouksia. Olen samaa mieltä siitä, että on tehtävä paljon enemmän sellaisten kriittisten hyökkäysten estämiseksi.