Staattinen tyyppianalyysi JavaScriptissä. Kokeillaan Facebookin Flow-analysaattoria. Monimutkaiset tapahtumavuorovaikutukset

Ja netologian opettaja kirjoitti blogiin sarjan artikkeleita EcmaScript6:sta. Ensimmäisessä osassa tarkastellaan dynaamista koodianalyysiä EcmaScriptissä Iroh.js:n avulla esimerkkien avulla.

Staattinen ja dynaaminen koodianalyysi

Koodianalyysityökalut ovat hyödyllinen työkalu, jonka avulla voit havaita ja tunnistaa koodisi virheet ja omituisuudet. Koodianalyysi voi olla staattista tai dynaamista. Ensimmäisessä tapauksessa lähdekoodi jäsennetään ja analysoidaan suorittamatta sitä. Toisessa tapauksessa suoritus tapahtuu ohjatussa hiekkalaatikkoympäristössä, joka tarjoaa metatietoa sovelluksen elementeistä sen suorituksen aikana.

johtopäätöksiä

Iroh.js on tehokas ja toimiva työkalu dynaamiseen koodin analysointiin EcmaScriptissä. Tätä työkalua voidaan käyttää sekä koodin analysointiin, mukaan lukien kutsukaavion rakentamiseen, todellisten tyyppien ja arvojen päättelemiseen muuttujissa ja objekteissa, että lennon aikana tapahtuvaan koodin muokkaamiseen, mukaan lukien tapahtumapohjaiset koodin korjaukset.

Dynaaminen analyysi on melko monimutkainen menetelmä, mutta EcmaScriptille tämä on ainoa tapa analysoida ja korjata koodia, kun otetaan huomioon ankkakirjoitus, isäntäobjektien läsnäolo ja natiivifunktiot, joiden avulla voit muuttaa koodin käyttäytymistä lennossa. teloitus. Iroh.js voi myös käyttää koodia toiminnallisten testien luomiseen ilman, että sitä tarvitsee ensin muokata viemään arvoja.

Aleksanteri MAYOROV, ohjelmoija, on ohjelmoinut 11 vuotta, joista seitsemän hän omisti mobiililaitteiden kehittämiseen

Staattinen tyyppianalyysi JavaScriptissä
Kokeile Facebookin Flow-analysaattoria

Facebook on esitellyt uuden avoimen lähdekoodin projektin, Flow, staattisen koodin analysaattorin JavaScript-kielelle. Analysaattorin kehittämisen päätavoitteena on yksinkertaistaa virheiden etsintää

Lisäksi Flow tarjoaa TypeScript-tyylisen syntaktisen laajennuksen JavaScriptiin tyyppien eksplisiittistä määrittelyä varten. Monet ECMAScript 6 -spesifikaatiossa esitellyt uudet ominaisuudet ovat tuettuja.

Ohjelmointikielillä kirjoittamisesta keskustellaan usein. Tämä on holivarien aihe ja tietyn kielen positiivisten tai negatiivisten piirteiden määrittäminen. Viime aikoina on puhuttu paljon JavaScriptin kirjoittamisesta. Jotkut ihmiset pitävät siitä sellaisena kuin se on. Ihmiset, jotka tuntevat muita ohjelmointikieliä, erityisesti selkeitä kirjoittajia, pitävät tätä lähestymistapaa "kranaattina apinan käsissä". Me kaikki tiedämme, että JavaScript on löyhästi dynaamisesti kirjoitettu kieli. Frontend-kehitysgurut ovat oppineet käyttämään tätä hyväkseen, mutta koodia on joskus vaikea ymmärtää. Ne, jotka ovat juuri tulossa JavaScript-ohjelmoinnin maailmaan, ovat hämmentyneitä tulkin tekemästä taikuudesta ja huomaavat usein virheitä tyhjästä. Mutta ymmärretään ensin hieman kirjoittamisesta yleisesti. Millainen se on?

Ohjelmointikielillä kirjoittaminen

Kirjoituksen perusteella ohjelmointikielet on jaettu kahteen suureen leiriin - kirjoitettuihin ja kirjoittamattomiin. Kirjoitetut kielet sisältävät esimerkiksi kielet, kuten C, Python, PHP, Lua, JavaScript. Esimerkkejä kirjoittamattomista kielistä: assembler, Forth, Brainfuck. Kyllä Kyllä täsmälleen. JavaScript, kuten monet muut tulkitut kielet, kirjoitetaan. Älä siis missään tapauksessa sano, että se on kirjoittamaton. Varsinkin haastattelujen aikana.

Kirjoitetut kielet puolestaan ​​​​jaetaan useisiin päällekkäisiin luokkiin:

• Staattisella tai dynaamisella kirjoituksella.
• Vahva tai löysä kirjoitus.
• Eksplisiittisellä tai epäsuoralla kirjoituksella.

Staattisesti kirjoitetut kielet

Staattisella kirjoituksella muuttujien ja funktioiden lopulliset tyypit asetetaan käännöshetkellä. Kääntäjä korjaa virheet tyyppieroista jo ennen ohjelman suorittamista. Esimerkkejä kielistä: C, Java, C#.

Dynaamisesti kirjoitetut kielet

Dynaamisessa kirjoituksessa kaikki tyypit löydetään ohjelman suorituksen aikana. Ja jos teit virheen, huomaat sen vasta, kun suoritat ohjelman. Siksi dynaamisessa kirjoituksessa on erittäin tärkeää kiinnittää erityistä huomiota tarkistuksiin ja virheiden keräämiseen. Esimerkkejä kielistä: JavaScript, PHP, Python, Ruby.

Vahva kirjoitus (vahva)

Voimakkaasti kirjoitetut kielet eivät salli eri tyyppien sekoittamista lausekkeisiin eivätkä suorita automaattisia implisiittisiä tyyppimuunnoksia. Et esimerkiksi voi vähentää merkkijonosta numeroa tai muuta tyyppiä kuin merkkijonoa. Esimerkkejä kielistä: Java, Python, Haskell, Lisp.

Ei-vahva kirjoitus (heikko)

Löysästi kirjoitetut kielet suorittavat monia implisiittisiä tyyppimuunnoksia automaattisesti. He tekevät tämän, vaikka tarkkuus tai muunnos voi heiketä, epäselvästi. Esimerkkejä kielistä: PHP, JavaScript, Visual Basic.

Selkeä kirjoitus

Eksplisiittisesti kirjoitetuissa kielissä uusien muuttujien/funktioiden ja argumenttien tyyppi on määritettävä eksplisiittisesti. Esimerkkejä kielistä: C++, D, C#.

Implisiittinen kirjoittaminen

Implisiittisesti kirjoitetuissa kielissä tyyppien määrittely jätetään kääntäjälle/tulkijalle. Esimerkkejä kielistä: JavaScript, PHP, Lua. Tällaisissa kielissä objekteilla on pääsääntöisesti erityisiä menetelmiä, joita kutsutaan, kun ne lähetetään tyyppiin. Esimerkiksi PHP:ssä on _toString()-menetelmä ja JavaScriptissä samanniminen menetelmä, mutta ilman alaviivaa, toString(). Näitä menetelmiä kutsutaan, kun objekti lähetetään merkkijonotyyppiin. Joskus tällaisia ​​menetelmiä kutsutaan taikoksi (kaikki implisiittiset prosessit ovat aina taikuutta).

On tärkeää huomata, että kaikki nämä luokat menevät päällekkäin. Näiden luokkien perusteella näemme, että JavaScriptillä on dynaaminen implisiittinen kirjoitus. Ja jos puhumme liioitellusti, kielen luonnetta voidaan kuvata seuraavasti: missä tahansa käsittämättömässä tilanteessa pelkistetään kaikki primitiivisiksi, pääasiassa merkkijonoksi. Vaikka todellisuudessa kaikki on hieman monimutkaisempaa, emme mene nyt yksityiskohtiin.

"Miksi tarvitsemme kirjoittamista?" - voit kysyä. Ilman sitä JavaScript toimi hyvin 20 vuotta. Vastaus on yksinkertainen: monimutkaisia ​​yritystason ongelmia ei ole aiemmin ratkaistu JavaScriptillä. Nyt tämä kieli on mennyt selaimen ulkopuolelle ja tullut taustajärjestelmän alueelle. Isoa sovellusta kirjoitettaessa tulee vaikeaksi havaita virheitä, jotka liittyvät usein nimenomaan tyyppivalamiseen.

JavaScript-lisäosat

Koska JavaScript suoritetaan asiakaspuolella (selaimissa), yksi ratkaisu ongelmaan näyttää olevan kielen luominen - murre, joka käännetään JS:ksi. Se toimii kokoajana.

Kielet, kuten TypeScript, Dart, AtScript, ovat ilmaantuneet, jotka lisäävät staattista vahvaa kirjoittamista ja jopa ajonaikaista tyyppitarkistusta (vaikka tämä lisää ylimääräisiä kustannuksia). Kaikki nämä kielet eivät vain lisää tyyppejä, vaan myös joko syntaktista sokeria tai oman VM-toteutuksensa, joka on kirjoitettu JS:llä.

Lue koko artikkeli ”Järjestelmänvalvoja” -lehden 1-2 vuodelta 2015 sivuilta 86-88.

Tämän numeron PDF-version voi ostaa kaupastamme.

1. Flow-verkkosivusto - http://flowtype.org.

Yhteydessä

Turvallisten sovellusten kehittäminen JavaScriptillä on melko monimutkainen tehtävä. Mutta ihan toteutettavissa. Tämän päivän artikkelissa tarkastellaan JavaScriptin ominaisuuksia, jotka aiheuttavat tietoturvaongelmia, ja puhumme tavoista välttää ne.

Miksi suojatun koodin kirjoittaminen JS:ssä on vaikeaa?

Joten tässä on 5 syytä, miksi suojatun koodin kirjoittaminen JS:ssä on vaikeaa

Kääntäjä ei auta

JavaScript on tulkittu kieli. Tämä tarkoittaa, että kääntäjä ei valita jostain koko ajan, kieltäytyy toimimasta ja pakottaa sinua korjaamaan virheitä ja optimoimaan koodia.

JavaScriptin dynaaminen olemus

JavaScript on dynaaminen, heikosti kirjoitettu ja asynkroninen. Ja nämä ovat kaikki merkkejä siitä, että vaikeuksiin joutuminen on helppoa.

1. Kielityökalut, kuten eval ja kolmannen osapuolen koodin sisällyttäminen script src:n kautta mahdollistavat rivien suorittamisen suoraan suorituksen aikana. Tämän seurauksena on vaikea antaa "staattisia takeita" siitä, että koodi käyttäytyy tietyllä tavalla. Tämä tekee myös dynaamisen analyysin vaikeaksi (katso tieteellinen työ).

Käyttämällä eval

2. Heikko kirjoitus Tämä vaikeuttaa vakiintuneiden staattisten analyysitekniikoiden soveltamista, ainakin verrattuna staattisesti kirjoitettuihin kieliin (kuten Java).

3. Asynkroniset takaisinsoitot, kutsut, jotka JavaScript sallii sellaisten mekanismien kautta, kuten setTimeout ja XMLHttpRequest (sama kuuluisa AJAX), tilastojen mukaan piilottavat kavalimmat virheet.

Monimutkaiset JS-ominaisuudet

Mitä ei ole tuotu JavaScriptiin vuosien aikana! Erityisesti siinä on prototyyppejä, ensiluokkaisia ​​toimintoja ja sulkuja. Ne tekevät kielestä entistä dynaamisemman ja suojatun koodin kirjoittamisen vaikeampaa.

1. Prototyypit. Niiden tarkoitus on, että ohjelmat on kirjoitettu oliolähtöisen lähestymistavan hengessä, mutta ilman luokkien käyttöä. Tällä lähestymistavalla objektit perivät tarvitsemansa ominaisuudet suoraan muilta objektilta (prototyypeiltä). Lisäksi JS:ssä prototyypit voidaan määritellä uudelleen suoraan ajon aikana. Ja jos tämä ohitus tapahtuu, vaikutus leviää välittömästi kaikkiin objekteihin, jotka perivät ohitetun prototyypin ominaisuudet.

Kuinka prototyyppejä käsitellään

Ollakseni rehellinen, on sanottava, että luokat ovat mukana myös uusissa ECMAScript-spesifikaatioissa.

2. Ensiluokkaiset toiminnot. JS:llä on erittäin joustava objekti- ja funktiomalli. Objektin ominaisuuksia ja niiden arvoja voidaan luoda, muuttaa tai poistaa heti ajon aikana, ja kaikkiin pääsee käsiksi ensiluokkaisten toimintojen kautta.

3. Sulkemiset. Jos määrität funktion toisen funktion sisällä, ensimmäisellä on pääsy jälkimmäisen funktion muuttujiin ja argumenteihin. Lisäksi nämä muuttujat ovat edelleen olemassa ja pysyvät sisäisen toiminnon käytettävissä - vaikka ulkoinen toiminto, jossa nämä muuttujat on määritelty, on valmis.

Koska JavaScript on niin joustava ja dynaaminen (katso kohdat 1 ja 3), objektin kaikkien käytettävissä olevien ominaisuuksien joukon määrittäminen staattisen analyysin aikana on vaikea tehtävä. Verkkokehittäjät käyttävät kuitenkin kaikkialla kielen dynaamisia ominaisuuksia, joten niitä ei voida jättää huomiotta koodia analysoitaessa. Muuten mikä on turvallisuuden tae?

Tiivis vuorovaikutus JavaScriptin ja DOM:n välillä

Tämä on välttämätöntä verkkosivun "saumattoman" päivityksen varmistamiseksi heti ajon aikana. DOM, sellaisena kuin me sen tunnemme, on standardi, alusta- ja kielineutraali objektimalli HTML- ja XML-dokumenttien hahmontamiseen. DOM:lla on oma API työskennellä hahmonnetun asiakirjan kanssa: dynaamisesti käyttää, siirtää ja päivittää renderöityä asiakirjaa (sen sisältöä, rakennetta ja tyyliä). Muutokset DOM:iin voidaan tehdä dynaamisesti JavaScriptin avulla. Ja nämä muutokset näkyvät välittömästi selaimessa.

DOM:n ansiosta selaimeen ladatut verkkosivut voidaan päivittää askel askeleelta, kun tietoja ladataan palvelimelta. Tällä mukavuudella on kuitenkin myös haittapuoli: JS:n ja DOM:n välisestä dynaamisesta vuorovaikutuksesta vastaavat koodinpalat ovat erityisen alttiita virheille.

Yleisimmät virheet verkkosovelluksissa

Monimutkaiset tapahtumavuorovaikutukset

JavaScript on tapahtumalähtöinen kieli. Sen avulla kehittäjät voivat rekisteröidä niin kutsuttuja tapahtumakuuntelijoita DOM-solmuihin. Ja vaikka useimmat tapahtumat käynnistyvät käyttäjän toimesta, jotkin tapahtumat voidaan käynnistää ilman sitä, kuten ajoitetut tapahtumat ja asynkroniset puhelut. Tässä tapauksessa jokainen tapahtuma voi kaikua koko DOM-puussa ja aktivoida useita "kuuntelijoita" kerralla. Joskus tämän kaiken kirjaaminen on melko ei-triviaali tehtävä.

Miten tapahtumia käsitellään

Näistä syistä JS-koodia voi olla vaikea ymmärtää, analysoida ja testata. Erityiset apuohjelmat helpottavat verkkokehittäjän elämää ja auttavat sinua kirjoittamaan suojattua koodia.

Apuohjelmat JS-koodin testaamiseen

On olemassa apuohjelmia jäsentämiseen (esim. Esprima, Rhino), optimointiin (esim. Google Closure Compiler) ja staattiseen koodianalyysiin yleisiä syntaksivirheitä varten (esim. JSHint).

Lisäksi on olemassa useita todistettuja kehyksiä, jotka auttavat verkkokehittäjiä peittämään JS-koodin testeillä. Heidän joukossa:

• QUnit on suosittu yksikkötestauksen kehys;
• Jasmine - BDD-kehys (Behavior-driven Development) koodin testaamiseen;
• Mocha on koodin testauskehys, joka toimii sekä Node.js:ssä että selaimessa;
• jsTestDriver on kehys, joka muun muassa voi suorittaa joukon testejä useiden selaimien kautta kerralla.

Lisäksi on olemassa testauskehyksiä, jotka jäljittelevät selaimen käyttäytymistä ja mahdollistavat testitapausten automaattisen suorittamisen. Ne ovat erityisen tärkeitä virheenkorjauksessa koodin osissa, jotka ovat vastuussa JS:n ja DOM:n välisestä vuorovaikutuksesta, ja tarjoavat kätevän infrastruktuurin DOM:n manipulointiin.

Esimerkiksi Selenium, PhantomJS ja SlimerJS tarjoavat API:n, jonka kautta voit käynnistää selaimen ilmentymiä ja olla vuorovaikutuksessa niiden kanssa. API:n kautta voit aktivoida tapahtumia ja käyttää DOM-elementtejä suoraan ajon aikana – eli testata koodia olosuhteissa, jotka ovat mahdollisimman lähellä todellisia. Tietysti huomattava osa työstä on tehtävä manuaalisesti, mutta tämäkin on hyvä apu testauksessa.

Static Analysis Utilities

Aiemmin apuohjelmat koodin ongelma-alueiden tunnistamiseen olivat staattisia analysaattoreita. Eli ottaen huomioon kaikki JS:n dynaamiset omituisuudet, he pystyivät tarjoamaan vain rajoitetusti apua. Ne voivat kuitenkin olla hyödyllisiä myös analysoinnissa. Tässä on joitain perusesimerkkejä.

WARI on staattinen analysaattori, joka tutkii riippuvuuksia JS-funktioiden, CSS-tyylien, HTML-tunnisteiden ja kuvien välillä. Tämän apuohjelman tarkoituksena on löytää käyttämättömät resurssit staattisen analyysin aikana. WARI ei tietenkään pysty selviytymään dynamiikasta.

JSLint on staattinen koodianalyysityökalu, joka on itse kirjoitettu JavaScriptillä. Se vertaa koodia hyviin käytäntöihin.

Google Closure Compiler on JS-optimointiohjelma, joka kirjoittaa koodin automaattisesti uudelleen tehdäkseen siitä nopeamman ja kompaktimman. Samalla kaikki kommentit ja kaikki käyttämättömät koodin osat menevät viemäriin.

WebScent (katso tieteellinen työ) on edistynyt staattinen analysaattori. Hän lähtee työssään siitä, että asiakkaan JS-koodia (selaimeen ladattua) ei ole tallennettu palvelinpuolelle kokonaisuudessaan, vaan se on hajallaan palvelinkoodin sisällä paloina. Näiden palojen "tuoksua" ei voida helposti havaita ennen kuin niistä on luotu täydellinen asiakaskoodi. WebScent analysoi asiakaskoodia löytääkseen ongelmakohdat palvelinkoodista. Samaan aikaan WebScentin staattisen analysaattorin työ rajoittuu pääasiassa HTML:n, CSS:n ja JS:n sotkujen purkamiseen - päällekkäisen koodin ja HTML-syntaksin virheiden havaitsemiseksi.

Dynaamisen analyysin apuohjelmat

JSNose on apuohjelma, joka yhdistää staattisen ja dynaamisen analyysin. Se analysoi koodin kolmelletoista antipatternille. Seitsemän niistä (mukaan lukien laiska objekti ja pitkä funktio) ovat yhteisiä kaikille ohjelmointikielille, ja loput kuusi (sulkemishajut, liialliset globaalit muuttujat, sisäkkäiset takaisinkutsut ja muut) ovat ominaisia ​​JavaScriptille.

DOMPletion on automaattinen apuohjelma, joka auttaa verkkokehittäjiä ymmärtämään koodia sitä tarkasteltaessa: selittää, miksi DOM-rakenteet ovat läsnä, suorittaa dynaamisen analyysin ja tarjoaa myös älykkään automaattisen täydennyksen koodille, joka on vuorovaikutuksessa DOM:n kanssa.

Clematis on kehys, joka auttaa purkamaan monimutkaisia ​​tapahtumavuorovaikutuksia. Clematis vangitsee yksityiskohtaisesti kaikki tapahtumat, jotka käynnistyvät suorituksen aikana, ja visualisoi ne abstraktin käyttäytymismallin muodossa, joka heijastaa komponenttien ja tapahtumien välisiä ajallisia ja syy-seuraus-suhteita.

johtopäätöksiä

Joten voi olla vaikeaa seurata, mitä tapahtuu suoritettaessa skriptejä JS:ssä, mutta oikeilla työkaluilla voit löytää ja kirjoittaa uudelleen ongelma-alueita jopa hämmentävämmästä koodista. JavaScript ei kuitenkaan pysähdy: siihen ilmestyy uusia ja uusia ominaisuuksia, nyt sitä käytetään usein sovellusten kirjoittamiseen (sekä mobiili- että työpöytäkoneille), ja se löytyy myös yhä enemmän palvelimilta (eikä vain) Node.js:n ansiosta. Tämä tarkoittaa, että bugien pyydystämisen taito on vietävä uudelle tasolle.

Jokaisella ][-tiimin jäsenellä on omat mieltymyksensä koskien pentestauksen ohjelmistoja ja apuohjelmia. Pienen keskustelun jälkeen totesimme: valikoima vaihtelee niin paljon, että voit koota todellisen herrasmiehen sarjan hyväksi havaittuja ohjelmia. Näin päätimme. Jotta ei syntyisi sotkua, koko luettelo on jaettu aiheisiin. Tänään katsotaan staattisen koodin analysaattorit etsiäksesi haavoittuvuuksia sovelluksista, kun sinulla on niiden lähdekoodit käsissäsi.

Ohjelmien lähdekoodien saatavuus yksinkertaistaa huomattavasti haavoittuvuuksien etsimistä. Sen sijaan, että manipuloisit sokeasti sovellukselle välitettyjä parametreja, on paljon helpompi tarkastella lähteitä nähdäksesi, kuinka se käsittelee ne. Jos esimerkiksi käyttäjän tiedot lähetetään ilman tarkistuksia ja muunnoksia ja ne saavuttavat SQL-kyselyn, meillä on SQL-injektiotyypin haavoittuvuus. Jos he pääsevät ulostuloon HTML-koodissa, saamme klassisen XSS:n. Staattinen skanneri tarvitaan tällaisten tilanteiden selkeään havaitsemiseen, mutta valitettavasti se ei ole aina niin helppoa kuin miltä näyttää.

Nykyaikaiset kääntäjät

Saattaa tuntua hauskalta, mutta yhdeltä tehokkaimmista koodianalysaattorit ovat kääntäjät itse. Tietenkin ne on tarkoitettu johonkin täysin erilaiseen, mutta bonuksena jokainen niistä tarjoaa hyvän lähdevarmentajan, joka voi havaita suuren määrän virheitä. Miksei hän säästä? Aluksi tällaisen koodin vahvistuksen asetukset asetetaan melko uskollisesti: seurauksena, jotta ohjelmoijaa ei hämmennetä, kääntäjä alkaa vannoa vain vakavimpien virheiden tapauksessa. Mutta tämä on turhaa - jos asetat varoitustason korkeammalle, on täysin mahdollista löytää monia epäilyttäviä paikkoja koodista. Se näyttää jotakuinkin tältä: Oletetaan, että koodissa ei tarkisteta merkkijonon pituutta ennen sen kopioimista puskuriin. Skanneri löytää toiminnon, joka kopioi merkkijonon (tai sen osan) kiinteän kokoiseen puskuriin tarkistamatta ensin sen pituutta. Hän jäljittää argumentin kulkemisen liikeradan: syöttötiedoista haavoittuvaan funktioon ja näkee, onko mahdollista valita merkkijonon pituus, joka aiheuttaisi ylivuodon haavoittuvassa funktiossa ja jota sitä edeltävät tarkistukset eivät katkaisisi. Jos tällaista tarkistusta ei ole, löydämme lähes 100 % puskurin ylivuotoja. Suurin vaikeus kääntäjän käyttämisessä tarkistamiseen on pakottaa se "nielemään" jonkun toisen koodia. Jos olet koskaan yrittänyt kääntää sovellusta lähdekoodista, tiedät kuinka vaikeaa on tyydyttää kaikki riippuvuudet, etenkin suurissa projekteissa. Mutta tulos on sen arvoinen! Lisäksi tehokkaat IDE:t sisältävät kääntäjän lisäksi joitain muita työkaluja koodianalyysi. Esimerkiksi Visual Studion seuraava koodinpätkä varoittaa sinua _alloca-funktion käytöstä silmukassa, mikä voi nopeasti ylittää pinon:

char *b;
tehdä (
b = (merkki*)_alloca(9)
) kun(1)

Tämä on PREfast-staattisen analysaattorin ansiota. Kuten FxCop, joka oli suunniteltu hallitun koodin analysointiin, PREfast jaettiin alun perin erillisenä apuohjelmana ja vasta myöhemmin siitä tuli osa Visual Studiota.

RATS - Rough Auditing Tool for Security

Verkkosivusto: www.securesoftware.com
Lisenssi: GNU GPL
Alusta: Unix, Windows
Kielet: C++, PHP, Python, Ruby

Virheestä virheeseen - ristiriita. Jotkut ohjelmoijien tekemistä virheistä ovat kritiikkiä ja uhkaavat vain ohjelman epävakautta. Toiset päinvastoin antavat sinun syöttää shell-koodin ja suorittaa mielivaltaisia ​​komentoja etäpalvelimella. Erityisen vaarallisia koodissa ovat komennot, jotka sallivat puskurin ylivuodon ja muut vastaavat hyökkäykset. Tällaisia ​​komentoja on paljon, C/C++:n tapauksessa nämä ovat funktioita merkkijonojen käsittelyyn (xstrcpy(), strcat(), gets(), sprintf(), printf(), snprintf(), syslog() ), järjestelmäkomennot ( access(), chown(), chgrp(), chmod(), tmpfile(), tmpnam(), tempnam(), mktemp()) sekä järjestelmäkutsukomennot (exec(), system (), popen() ). Koko koodin manuaalinen tutkiminen (varsinkin jos se koostuu useista tuhansista riveistä) on melko työlästä. Tämä tarkoittaa, että voit helposti jättää huomiotta tarkistamattomien parametrien siirtämisen johonkin toimintoon. Erityiset tarkastustyökalut, mukaan lukien tunnettu apuohjelma, voivat helpottaa tehtävää huomattavasti ROTTIA (Karkea tarkastustyökalu turvallisuutta varten) kuuluisalta Fortify-yhtiöltä. Se ei ainoastaan ​​käsittele onnistuneesti C/C++-kielellä kirjoitettua koodia, vaan pystyy myös käsittelemään skriptejä Perlissä, PHP:ssä ja Pythonissa. Apuohjelmatietokanta sisältää vaikuttavan valikoiman ja yksityiskohtaisen kuvauksen koodin ongelma-alueista. Analysaattorin avulla se käsittelee sille syötetyn sorbetin ja yrittää tunnistaa vikoja, minkä jälkeen se antaa tietoa löydetyistä vioista. ROTTIA toimii komentorivin kautta sekä Windows- että *nix-järjestelmissä.

Yasca

Verkkosivusto: www.yasca.org
Lisenssi: Open Source
Alusta: Unix, Windows
Kielet: C++, Java, .NET, ASP, Perl, PHP, Python ja muut.

Yasca aivan kuten RATS, se ei vaadi asennusta, ja siinä ei ole vain konsolikäyttöliittymä, vaan myös yksinkertainen käyttöliittymä. Kehittäjät suosittelevat apuohjelman suorittamista konsolin kautta - he sanovat, että tällä tavalla on enemmän mahdollisuuksia. Hassua, että Yasca-moottori on kirjoitettu PHP 5.2.5:llä, ja tulkki (sen riisutuimmassa versiossa) sijaitsee yhdessä ohjelman kanssa olevan arkiston alikansioista. Koko ohjelma koostuu loogisesti etuosasta, joukosta skannauslaajennuksia, raporttigeneraattorista ja itse moottorista, joka saa kaikki vaihteet pyörimään yhdessä. Plugins upotetaan plugins-hakemistoon - sinne on myös asennettava lisäosia. Tärkeä pointti! Mukana kolme vakiolaajennusta Yasca, joilla on epämiellyttäviä riippuvuuksia. JLint, joka skannaa Java .class -tiedostoja, vaatii jlint.exe-tiedoston resurssi-/apuohjelmahakemistossa. Toinen laajennus, antiC, jota käytetään Java- ja C/C++-lajitteluihin, vaatii antic.exe-tiedoston samassa hakemistossa. joka käsittelee Java-koodia, on asennettava järjestelmään Java JRE 1.4 tai uudempi. Voit tarkistaa oikean asennuksen kirjoittamalla komennon "yasca ./resources/test/". Yasca tuottaa tuloksen erityisraportin muodossa. Esimerkiksi yksi tavallisista GREP-laajennuksista antaa sinun määrittää haavoittuvia rakenteita .grep-tiedostoissa kuvattujen mallien avulla ja tunnistaa helposti useita haavoittuvuuksia. Joukko tällaisia ​​​​malleja on jo mukana ohjelmassa: heikon salauksen etsimiseen, valtuutukseen "salasana on sama kuin sisäänkirjautumiseen", mahdollisiin SQL-injektioihin ja paljon muuta. Kun haluat nähdä raportissa tarkempia tietoja, älä ole laiska asentamaan lisälaajennuksia. Sen arvoista on, että heidän avullaan voit lisäksi skannata koodia .NET:issä (VB.NET, C#, ASP.NET), PHP:ssä, ColdFusionissa, COBOLissa, HTML:ssä, JavaScriptissä, CSS:ssä, Visual Basicissa, ASP:ssä, Pythonissa, Perlissä.

Cppcheck

Verkkosivusto:
Lisenssi: Open Source
Alusta: Unix, Windows
Kielet: C++

Kehittäjät Cppcheck He päättivät olla tuhlaamatta aikaa pikkuasioihin, ja siksi he pyydystävät vain tiukasti määritellyt bugiluokat ja vain C++-koodilla. Älä odota ohjelman kopioivan kääntäjän varoituksia - se pärjää ilman kehotteita. Käytä siksi aikaa asettaaksesi kääntäjän enimmäisvaroitustasolle ja käytä Cppcheckiä tarkistaaksesi muistivuotoja, varauksen ja purkamisen rikkomuksia, erilaisia ​​puskurin ylivuotoja, vanhentuneiden toimintojen käyttöä ja paljon muuta. Tärkeä yksityiskohta: Cppcheck-kehittäjät yrittivät vähentää väärien positiivisten tulosten määrää minimiin. Siksi, jos ohjelma havaitsee virheen, voit todennäköisesti sanoa: "Se on todella olemassa!" Voit suorittaa analyysin joko konsolista tai käyttämällä mukavaa Qt-kielellä kirjoitettua graafista käyttöliittymää, joka toimii millä tahansa alustalla.

gradit

Verkkosivusto: www.justanotherhacker.com/projects/graudit.html
Lisenssi: Open Source
Alusta: Unix, Windows
Kielet: C++, PHP, Python, Perl

Tämä yksinkertainen komentosarja yhdistettynä joukkoon allekirjoituksia mahdollistaa joukon kriittisten haavoittuvuuksien löytämistä koodista, ja haku suoritetaan tunnetulla grep-apuohjelmalla. Tässä on sopimatonta edes mainita GUI-käyttöliittymää: kaikki tehdään konsolin kautta. Käynnistysnäppäimiä on useita, mutta yksinkertaisimmassa tapauksessa riittää, että määrität lähteen polun parametriksi:

gradit /polku/skannaukseen

Palkinto ponnisteluistasi on värikäs raportti mahdollisesti hyödynnettävistä paikoista koodissa. On sanottava, että itse skriptin (joka on vain 100 koodiriviä Bashissa) lisäksi arvokkaita ovat allekirjoitustietokannat, jotka sisältävät regexpejä ja mahdollisesti haavoittuvien toimintojen nimiä eri kielillä. Oletuksena Pythonin, Perlin, PHP:n, C++:n pohjat ovat mukana - voit ottaa tiedostot allekirjoituskansiosta ja käyttää niitä omassa kehitystyössäsi.

SWAAT

Verkkosivusto: www.owasp.org
Lisenssi: Open Source
Alusta: Unix, Windows
Kielet: Java, JSP, ASP .Net, PHP

Jos graudit käyttää tekstitiedostoja haavoittuvuuden allekirjoituksen asettamiseen, niin SWAAT– progressiivisempi lähestymistapa XML-tiedostojen avulla. Tältä näyttää tyypillinen allekirjoitus:

vuln match - säännöllinen lauseke hakuun;
tyyppi - osoittaa haavoittuvuuden tyypin:
vakavuus - osoittaa riskitason (korkea, keskitaso tai matala)
alt - vaihtoehtoinen koodi ongelman ratkaisemiseksi

SWAAT lukee allekirjoitustietokannan ja yrittää sen avulla löytää koodin ongelma-alueita Java-, JSP-, ASP .Net- ja PHP-lähteistä. Tietokanta päivittyy jatkuvasti ja sisältää "vaarallisten" funktioiden listan lisäksi tyypillisiä virheitä merkkijonojen muotoilussa ja SQL-kyselyjen kirjoittamisessa. On huomionarvoista, että ohjelma on kirjoitettu C#-kielellä, mutta se toimii täydellisesti niksin alla, kiitos Mono-projektin - avoimen .Net-alustan toteutuksen.

PHP Bug Scanner

Verkkosivusto: raz0r.name/releases/php-bug-scanner
Lisenssi: Freeware
Alusta: Windows
Kielet: PHP

Jos sinun on suoritettava PHP-sovelluksen staattinen analyysi, suosittelen kokeilemaan sitä PHP Bug Scanner, jonka on kirjoittanut kirjoittajamme - raz0r. Ohjelman työ perustuu PHP-skriptien erilaisten funktioiden ja muuttujien skannaamiseen, joita voidaan käyttää verkkohyökkäyksissä. Tällaisten tilanteiden kuvaus on esitetty ns. esiasetusten muodossa, ja ohjelma sisältää jo 7 erityistä esiasetusta kategorioittain ryhmiteltynä:

• koodin suorittaminen;
• komennon suorittaminen;
• hakemiston läpikäynti;
• globaalit päällekirjoitus;
• sisältää;
• SQL-injektio;
• sekalaista.

On hauskaa, että ohjelma on kirjoitettu PHP/WinBinderillä ja käännetty bamcompilella, joten se näyttää samalta kuin tavallinen Windows-sovellus. Kätevän käyttöliittymän kautta läpäisytestauslaite voi ottaa käyttöön tai poistaa käytöstä koodianalyysin tiettyjen haavoittuvuuksien varalta.

Pixy

Verkkosivusto: pixybox.seclab.tuwien.ac.at
Lisenssi: Freeware
Alusta: Unix, Windows
Kielet: PHP

Työkalu perustuu lähdekoodin skannaamiseen ja tietovirtakaavioiden rakentamiseen. Tämä kaavio seuraa ohjelman ulkopuolelta tulevien tietojen polkua - käyttäjältä, tietokannasta, jostain ulkoisesta laajennuksesta jne. Tällä tavalla luodaan luettelo sovellusten haavoittuvista kohdista (tai syötteistä). Käyttämällä malleja, jotka kuvaavat haavoittuvuuksia, Pixy tarkistaa tällaiset kohdat ja antaa sinun tunnistaa XSS- ja SQL-haavoittuvuudet. Lisäksi itse kaavioita, jotka rakennetaan analyysin aikana, voidaan tarkastella graafit-kansiossa (esimerkiksi xss_file.php_1_dep.dot) - tämä on erittäin hyödyllistä ymmärtääksesi, miksi tätä tai toista koodin osaa pidetään Pixy-haavoittuvaisena. Yleisesti ottaen kehitys itsessään on erittäin opettavaista ja osoittaa, kuinka edistyneet apuohjelmat staattisen koodin analysointiin toimivat. Dokumentaatiosivulla kehittäjä kertoo selkeästi ohjelman toiminnan eri vaiheista, selittää logiikan ja algoritmin, kuinka ohjelman tulee analysoida tämä tai toinen koodinpätkä. Itse ohjelma on kirjoitettu Java-kielellä ja sitä jaetaan avoimessa lähdekoodissa, ja kotisivulla on jopa yksinkertainen verkkopalvelu koodin tarkistamiseen XSS-haavoittuvuuksien varalta.

Unssi 6

Verkkosivusto: www.ouncelabs.com/products
Lisenssi: Shareware
Alusta: Windows

Valitettavasti olemassa olevat ilmaiset ratkaisut ovat edelleen kaupallisten vastineidensa alapuolella. Riittää, kun tutkitaan raportin laatua ja yksityiskohtia, mikä on Unssi 6– ja ymmärrä miksi. Ohjelma perustuu erityiseen analyysimoottoriin, Ounce Coreen, joka tarkistaa koodin sääntöjen ja käytäntöjen noudattamisen. Sen on koonnut ammattilaisten testaajien tiimi, joka on kerännyt kokemusta tunnetuista tietoturvayrityksistä, hakkeriyhteisöstä ja turvallisuusstandardeista. Ohjelma havaitsee koodissa useita haavoittuvuuksia: puskurin ylivuodosta SQL-injektointiin. Haluttaessa Unce integroituu helposti suosittujen IDE:iden kanssa automaattisen koodintarkistuksen toteuttamiseksi kehitettävän sovelluksen jokaisen uuden koontiversion kokoamisen aikana. Muuten, kehitysyhtiö - Ounce Labs - osti IBM itse tänä kesänä. Tuote tulee siis todennäköisesti jatkamaan kehitystä osana yhtä IBM:n kaupallisista sovelluksista.

Klocwork Insight

Verkkosivusto: www.klocwork.com
Lisenssi: Shareware
Alusta: Windows
Kielet: C++, Java, C#

Tämä jälleen kaupallinen tuote toteutti pitkään staattista koodiskannausta vain C:lle, C+:lle ja Javalle. Mutta heti kun Visual Studio 2008 ja .NET Framework 3.5 julkaistiin, kehittäjät ilmoittivat tuesta C#:lle. Ajoin ohjelmaa kahdessa apuprojektissani, jotka kirjoitin nopeasti Sharpiin, ja ohjelma tunnisti 7 kriittistä haavoittuvuutta. On hyvä, että ne on kirjoitettu yksinomaan sisäiseen käyttöön :). Klocwork Insight alun perin määritetty ensisijaisesti toimimaan yhdessä integroitujen kehitysympäristöjen kanssa. Integrointi samaan Visual Studioon tai Eclipseen on tehty erittäin hyvin - alkaa vakavasti ajatella, että tällainen toiminnallisuus pitäisi olla niissä oletuksena toteutettu :). Jos emme ota huomioon sovelluksen logiikkaan liittyviä ongelmia ja suorituskykyongelmia, niin Klocwork Insight tekee erinomaista työtä puskurin ylivuotojen, käyttäjäkoodin suodatuksen puutteen, SQL/Path/Cross-site-injektointimahdollisuuksien, heikon salauksen jne. löytämisessä. Toinen mielenkiintoinen vaihtoehto on rakentaa sovelluksen suorituspuu, jonka avulla voit nopeasti ymmärtää sovelluksen yleisperiaatteen ja seurata erikseen esimerkiksi minkä tahansa käyttäjän syötteen käsittelyä. Ja koodin tarkistussääntöjen nopeaan rakentamiseen tarjotaan jopa erikoistyökalu - Klocwork Checker Studio.

Coverity Prevent Staattinen analyysi

Verkkosivusto: www.coverity.com/products
Lisenssi: Shareware
Alusta: Windows
Kielet: C++, Java, C#

Yksi tunnetuimmista staattisen koodin analysaattoreista C/C++, Java ja C#. Sen tekijöiden mukaan ratkaisua käyttää yli 100 000 kehittäjää ympäri maailmaa. Hyvin harkittujen mekanismien avulla voit automatisoida muistivuotojen, havaitsemattomien poikkeusten, suorituskykyongelmien ja tietysti tietoturva-aukkojen etsimisen. Tuote tukee erilaisia ​​alustoja, kääntäjiä (gcc, Microsoft Visual C++ ja monia muita) ja integroituu myös erilaisiin kehitysympäristöihin, ensisijaisesti Eclipseen ja Visual Studioon. Koodin läpikulku ei perustu typeriin päästä päähän -läpikulkualgoritmeihin, vaan pikemminkin johonkin debuggerin tapaan, joka analysoi, miten ohjelma käyttäytyy eri tilanteissa haaran kohtaamisen jälkeen. Tällä tavalla saavutetaan 100 % koodipeitto. Tällaista monimutkaista lähestymistapaa vaadittiin muun muassa monisäikeisten sovellusten täydelliseen analysointiin, jotka on erityisesti optimoitu toimimaan moniytimisillä prosessoreilla. Coverity Integrity Center avulla voit löytää virheitä, kuten kilpailuolosuhteet (suunnitteluvirhe monitoimijärjestelmässä, jossa järjestelmän toiminta riippuu koodin osien suoritusjärjestyksestä), lukkiutumisesta ja paljon muuta. Miksi kääntäjät tarvitsevat tätä? Kysy tästä Firefoxin ja IE:n 0day exploitien kehittäjiltä :).

OWASP-koodin indeksointirobotti

Verkkosivusto: www.owasp.org
Lisenssi: GNU GPL
Alusta: Windows
Kielet: Java, C#, VB

Tämän työkalun luoja, Alessio Marziali, on kirjoittanut kaksi kirjaa ASP.NET:stä, arvovaltaisesta korkean kuormituksen sovellusten koodaajasta finanssisektorille ja myös koodaajaksi. Vuonna 2007 hän julkaisi tietoja kriittisistä haavoittuvuuksista 27 Italian hallituksen verkkosivustolla. Hänen aivonsa - OWASP-koodin indeksointirobotti- suunniteltu .NET- ja J2EE/JAVA-koodin staattiseen analysointiin, on avoimesti saatavilla Internetissä, ja vuoden lopussa tekijä lupaa julkaista ohjelmasta uuden version, jossa on paljon enemmän toimintoja. Mutta tärkein asia on jo toteutettu - lähdekoodien analysointi C#:ssa, Visual Basicissa ja Javassa. Skannatut tiedostot valitaan graafisen käyttöliittymän kautta, ja skannaus alkaa automaattisesti. Jokaisen ongelmallisen koodin osan osalta haavoittuvuuden kuvaus näkyy Uhkien kuvaus -osiossa. Totta, kenttä OWASP-ohjeet, joka todennäköisesti osoittaa tapoja ratkaista ongelma, ei valitettavasti ole vielä saatavilla. Voit kuitenkin käyttää kokeellista koodin skannausominaisuutta etäkoneella, joka on saatavilla Etäskannaus-välilehdessä. Kirjoittaja lupaa parantaa tätä ominaisuutta vakavasti ja muun muassa koota sovelluslähteet analysoitavaksi suoraan versionhallintajärjestelmästä.

VAROITUS

Tiedot on tarkoitettu tiedoksi, ja ne osoittavat ensisijaisesti, kuinka kehittäjät voivat välttää kriittiset virheet sovelluskehityksen aikana. Tekijä tai toimittajat eivät ole vastuussa hankitun tiedon käyttämisestä laittomiin tarkoituksiin.

Kaikki koodini rivit eivät ole täydellisiä ensimmäisellä kerralla. No, joissain tapauksissa... Joskus... Okei - tuskin koskaan. Totuus on, että käytän huomattavasti enemmän aikaa omien typerien virheideni korjaamiseen kuin haluaisin. Tästä syystä käytän staattisia analysaattoreita melkein jokaisessa kirjoittamassani JavaScript-tiedostossa.

Staattiset analysaattorit tarkastelevat koodiasi ja löytävät siitä virheitä ennen sen suorittamista. Ne suorittavat yksinkertaisia ​​tarkistuksia, kuten valvontasyntaksin (esimerkiksi onko välilyöntien sijasta sarkaimia) ja yleisempiä tarkistuksia, kuten sen, että toiminnot eivät ole liian monimutkaisia. Staattiset analysaattorit etsivät myös virheitä, joita ei löydy testauksen aikana, esimerkiksi == === sijaan.

Suurissa projekteissa ja suurissa ryhmissä työskennellessäsi voisit käyttää hieman apua niiden "yksinkertaisten" vikojen löytämisessä, jotka eivät itse asiassa ole niin yksinkertaisia ​​kuin miltä ne näyttävät.

JSLint, JSHint ja Closure Compiler

JavaScriptin staattisille analysaattoreille on kolme päävaihtoehtoa: JSLint, JSHint ja Closure Compiler.

JSLint oli ensimmäinen staattinen JavaScriptin jäsentäjä. Voit suorittaa sen virallisella verkkosivustolla tai käyttää jotakin lisäosista, jotka voidaan suorittaa paikallisissa tiedostoissa. JSLint löytää monia tärkeitä virheitä, mutta se on erittäin vaikeaa. Tässä on selkeä esimerkki:

var s = "mystring";
for (var i = 0; i< s.length; i++) {
console.log(s.charAt(i));
}

JSLint näyttää kaksi virhettä tässä koodissa:

Odottamaton "++".
Siirrä "var"-ilmoitukset funktion yläosaan.

Ensimmäinen ongelma on muuttujan i määritteleminen silmukkaehdoissa. JSLint ei myöskään hyväksy ++-operaattoria silmukan määritelmän lopussa. Hän haluaa koodin näyttävän tältä:

var s = "mystring";
var i;
for (i = 0; i< s.length; i = i + 1) {
console.log(s.charAt(i));
}

Arvostan JSLintin tekijöitä, mutta mielestäni tämä on liioittelua. Se osoittautui vaikeaksi myös Anton Kovaleville, joten hän loi JSHint.

JSHint toimii samalla tavalla kuin JSLint, mutta se on kirjoitettu Node.js:n lisäksi ja on siksi joustavampi. JSHint sisältää suuren määrän vaihtoehtoja, joiden avulla voit suorittaa mukautettuja tarkistuksia kirjoittamalla oman raporttigeneraattorin.

Voit ajaa JSHint-verkkosivustolta, mutta useimmissa tapauksissa on parempi asentaa JSHint paikalliseksi komentorivityökaluksi Node.js:n avulla. Kun olet asentanut JSHint, voit suorittaa sen tiedostoissasi seuraavan kaltaisella komennolla:

jshint test.js

JSHint sisältää myös laajennuksia suosittuihin tekstieditoreihin, joten voit käyttää sitä samalla, kun kirjoitat koodia.

CLOSURE COMILER

Googlen Closure Compiler on täysin erilainen ohjelma. Kuten nimestä voi päätellä, se ei ole vain varmennusohjelma, vaan myös kääntäjä. Se on kirjoitettu Java-kielellä ja perustuu Mozillan Rhino-parseriin. Closure Compiler sisältää yksinkertaisen tilan peruskoodin tarkistuksen suorittamiseen ja monimutkaisemmat tilat, jotka mahdollistavat tiettyjen näkymämääritelmien lisätarkistuksen ja täytäntöönpanon.

Closure Compiler raportoi JavaScript-koodin virheistä, mutta tuottaa myös JavaScriptin pienennettyjä versioita. Kääntäjä poistaa välilyönnit, kommentit ja käyttämättömät muuttujat ja yksinkertaistaa pitkiä lausekkeita tehden skriptistä mahdollisimman kompaktin.

Google on tehnyt erittäin yksinkertaisen version kääntäjästä saataville verkossa, mutta sinun kannattaa todennäköisesti ladata Closure Compiler ja suorittaa se paikallisesti.

Closure Compiler, tarkistettuaan koodin, tulostaa tiedostoluettelon yhdeksi pienennetyksi tiedostoksi. Voit siis suorittaa sen lataamalla compiler.jar-tiedoston.

java -jar kääntäjä.jar --js_output_file compress.js --js test1.js --js test2.js

Oikean vahvistusohjelman valinta

Projekteissani yhdistän Closure Compiler ja JSHint. Closure Compiler tekee pienentämisen ja perustarkistuksen, kun taas JSHint tekee monimutkaisemman koodianalyysin. Nämä kaksi ohjelmaa toimivat hyvin yhdessä ja kumpikin kattaa alueita, joita toinen ei voi. Lisäksi voin käyttää JSHint-laajennusominaisuuksia mukautettujen tarkistusten kirjoittamiseen. Yksi yleinen ohjelma, jonka kirjoitin, tarkistaa tietyt toiminnot, joita en tarvitse, kuten sellaisten funktioiden kutsuminen, joita ei pitäisi olla projektissani.

Nyt kun olemme tarkastelleet muutamia ohjelmia tarkistettavaksi, katsotaanpa huonoa koodia. Jokainen näistä kuudesta esimerkistä edustaa koodia, jota ei pitäisi kirjoittaa, ja tilanteita, joissa koodin tarkistajat voivat säästää sinut.

Tässä artikkelissa käytetään JSHintia useimmissa esimerkeissä, mutta Closure Compiler tuottaa yleensä samanlaisia ​​varoituksia.

== vai ===?

JavaScript on dynaamisesti kirjoitettu kieli. Sinun ei tarvitse määrittää tyyppejä, kun kirjoitat koodia, mutta ne ovat olemassa käynnistyksen yhteydessä.

JavaScript tarjoaa kaksi vertailuoperaattoria näiden dynaamisten tyyppien käsittelemiseen: == ja ===. Katsotaanpa tätä esimerkin avulla.

var n = 123;
var s = "123";

jos (n == s) (
alert("Muuttujat ovat yhtä suuret");
}

jos (n === s) (
alert("Muuttujat ovat identtisiä");
}

Vertailuoperaattori == on jäännös C-kielestä, jossa JavaScriptin juuret ovat. Sen käyttäminen on lähes aina virhe: arvojen vertaaminen erillään tyypeistä on harvoin sitä, mitä kehittäjä todella haluaa tehdä. Itse asiassa luku "satakaksikymmentäkolme" eroaa rivistä "yksi kaksi kolme". Nämä lausunnot on helppo kirjoittaa väärin ja vielä helpompi lukea väärin. Testaa tätä koodia JSHintilla ja saat seuraavan:

test.js: rivi 9, sarake 12, odotettiin "===" ja sen sijaan näki "==".

Määrittämättömät muuttujat ja myöhäiset määritelmät

Aloitetaan yksinkertaisella koodilla:

toimivuustesti() (
var myVar = "Hei, maailma";
console.log(myvar);
}

Näetkö bugin? Teen tämän virheen joka kerta. Suorita tämä koodi ja saat virheilmoituksen:

ReferenceError: myvar ei ole määritetty

Tehdään ongelmasta hieman monimutkaisempi:

toimivuustesti() (
myVar = "Hei, maailma";
console.log(myVar);
}

Suorita tämä koodi ja saat seuraavan:

Hei maailma

Tämä toinen esimerkki toimii, mutta sillä on joitain hyvin odottamattomia sivuvaikutuksia. JavaScript-muuttujien ja laajuuden määrittelysäännöt ovat parhaimmillaan hämmentäviä. Ensimmäisessä tapauksessa JSHint raportoi seuraavaa:

test.js: rivi 3, sarake 17, "myvar" ei ole määritetty.

Toisessa tapauksessa hän raportoi tämän:

test.js: rivi 2, sarake 5, "myVar" ei ole määritetty.
test.js: rivi 3, sarake 17, "myVar" ei ole määritetty.

Ensimmäinen esimerkki auttaa sinua välttämään ajonaikaisen virheen. Sinun ei tarvitse testata sovellustasi - JSHint löytää vian puolestasi. Toinen esimerkki on huonompi, koska testauksen tuloksena et löydä vikaa.

Toisen esimerkin ongelma on salakavalan hienovarainen ja monimutkainen. Muuttuja myVar on nyt kadonnut laajuudestaan ​​ja siirtynyt globaaliin laajuuteen. Tämä tarkoittaa, että se on olemassa ja sen arvo on Hello, World myös testitoiminnon suorittamisen jälkeen. Tätä kutsutaan globaaliksi saasteeksi.

myVar-muuttuja on olemassa kaikille muille funktioille, jotka suoritetaan testifunktion jälkeen. Suorita seuraava koodi, kun olet suorittanut testitoiminnon:

console.log("myVar: " + myVar);

Saat edelleen Hello, World. myVar-muuttuja roikkuu koko koodisi ympärillä kuin kuvio, joka johtaa monimutkaisiin bugeihin, joita etsit koko yön ennen julkaisua, koska unohdit sisällyttää var.

Tämä merkintä kulki Full-Text RSS -palvelun kautta - jos tämä on sinun sisältösi ja luet sitä jonkun muun sivustolla, lue UKK osoitteessa http://ift.tt/jcXqJW.