Ստատիկ տիպի վերլուծություն JavaScript-ում: Փորձում ենք Facebook-ի Flow անալիզատորը: JavaScript-ի անվտանգություն կամ ինչպես գրել անվտանգ JS կոդ Վերլուծություն և կոդի օպտիմալացման գործիքներ

Իմ կոդի ամեն տող չէ, որ կատարյալ է առաջին անգամ: Դե, որոշ դեպքերում... Երբեմն... Դե, գրեթե երբեք: Ճշմարտությունն այն է, որ ես զգալիորեն ավելի շատ ժամանակ եմ ծախսում սեփական հիմար սխալներն ուղղելու համար, քան կցանկանայի: Սա է պատճառը, որ ես օգտագործում եմ ստատիկ անալիզատորներ իմ գրած գրեթե յուրաքանչյուր JavaScript ֆայլում:

Ստատիկ անալիզատորները նայում են կոդը և գտնում են սխալներ, նախքան այն գործարկելը: Նրանք կատարում են պարզ ստուգումներ, օրինակ՝ ստուգել կիրարկման շարահյուսությունը (օրինակ՝ արդյոք բացատների փոխարեն ներդիրներ կան) և ավելի գլոբալ ստուգումներ, օրինակ՝ համոզվել, որ գործառույթները չափազանց բարդ չեն: Ստատիկ անալիզատորները նաև փնտրում են սխալներ, որոնք հնարավոր չէ գտնել փորձարկման ժամանակ, օրինակ՝ ====-ի փոխարեն:

Խոշոր նախագծերում և մեծ թիմերում աշխատելիս կարող եք օգտագործել մի փոքր օգնությունայնպիսի «պարզ» սխալների որոնման մեջ, որոնք իրականում պարզվում են, որ այնքան էլ պարզ չեն, որքան թվում է:

JSLint, JSHint և փակման կոմպիլյատոր

JavaScript-ի համար կա ստատիկ անալիզատորի երեք հիմնական տարբերակ՝ JSLint, JSHint և Closure Compiler:

JSLint-ը JavaScript-ի առաջին ստատիկ վերլուծիչն էր: Դուք կարող եք այն գործարկել պաշտոնական կայքում կամ օգտագործել հավելումներից մեկը, որը կարող է գործարկվել տեղական ֆայլեր. JSLint-ը գտնում է շատ կարևոր սխալներ, բայց դա շատ դժվար է: Ահա մի պարզ օրինակ.

vars = «mystring»;
համար (var i = 0; i< s.length; i++) {
console.log (s.charAt (i));
}

JSLint-ը ցույց է տալիս այս կոդի երկու սխալ.

Անսպասելի «++»:
Տեղափոխեք «var» հայտարարագրերը գործառույթի վերևում:

Առաջին խնդիրը ցիկլային պայմաններում i փոփոխականի սահմանումն է: JSLint-ը նաև չի ընդունում ++ օպերատորը հանգույցի սահմանման վերջում: Նա ցանկանում է, որ կոդը այսպիսի տեսք ունենա.

vars = «mystring»;
var i;
համար (i = 0; i< s.length; i = i + 1) {
console.log (s.charAt (i));
}

Ես գնահատում եմ JSLint-ի ստեղծողներին, բայց իմ կարծիքով սա չափազանցված է: Անտոն Կովալևի համար նույնպես դժվար էր, ուստի նա ստեղծեց JSHint-ը:

Դուք կարող եք սկսել JSHint-ը ից, բայց շատ դեպքերում ավելի լավ է տեղադրել JSHint-ը որպես տեղական հրամանի տող գործիք՝ օգտագործելով Node.js-ը: JSHint-ը տեղադրելուց հետո կարող եք այն գործարկել ձեր ֆայլերում այս հրամանով.

jshint test.js

JSHint-ը ներառում է նաև հանրաճանաչ հավելվածներ տեքստային խմբագիրներ, այնպես որ այն կարող է գործարկվել կոդավորման ընթացքում:

ՓԱԿՄԱՆ ԿԱՊԻԼԵՐ

Google's Closure Compiler-ը բոլորովին այլ տեսակի ծրագիր է: Ինչպես ցույց է տալիս նրա անունը, այն ոչ միայն ստուգիչ է, այլև կոմպիլյատոր։ Այն գրված է Java-ով և հիմնված է Mozilla-ի Rhino վերլուծիչի վրա: Փակման կոմպիլյատորը ներառում է հիմնական կոդի ստուգման պարզ ռեժիմ և ավելի առաջադեմ ռեժիմներ կատարելու համար լրացուցիչ ստուգումև կիրառել առանձին տեսակների սահմանումները:

Closure Compiler-ը հաղորդում է սխալների մասին JavaScript կոդը, բայց նաև ստեղծում է JavaScript-ի մինիմացված տարբերակները: Կազմողը հեռացնում է սպիտակ տարածությունը, մեկնաբանությունները և չօգտագործված փոփոխականները և պարզեցնում է երկար արտահայտությունները՝ սցենարը հնարավորինս կոմպակտ դարձնելով։

Google-ը կոմպիլյատորի շատ պարզ տարբերակը հասանելի է դարձրել առցանց, բայց դուք, ամենայն հավանականությամբ, կցանկանաք ներբեռնել Closure Compiler-ը և գործարկել այն տեղական մակարդակում:

Closure Compiler-ը ծածկագիրը ստուգելուց հետո ֆայլերի ցանկը թողարկում է մեկ փոքրացված ֆայլի մեջ: Այսպիսով, դուք կարող եք այն գործարկել՝ ներբեռնելով compiler.jar ֆայլը:

java -jar compiler.jar --js_output_file compress.js --js test1.js --js test2.js

Ընտրեք ճիշտ ծրագիրստուգումներ

Իմ նախագծերում ես համատեղում եմ Closure Compiler-ը և JSHint-ը: Closure Compiler-ը կատարում է փոքրացման և հիմնական վավերացումը, մինչդեռ JSHint-ն անում է ավելի բարդ կոդի վերլուծություն: Երկու ծրագրերը հիանալի աշխատում են միասին, և յուրաքանչյուրն ընդգրկում է ոլորտներ, որոնք մյուսը չի կարող: Բացի այդ, ես կարող եմ օգտագործել JSHint ընդլայնումը հատուկ վավերացուցիչներ գրելու համար: Մեկը գրված է իմ կողմից ընդհանուր ծրագիրստուգում է որոշ գործառույթների համար, որոնք ինձ պետք չեն, օրինակ՝ կանչելով գործառույթներ, որոնք չպետք է լինեն իմ նախագծում:

Այժմ, երբ մենք լուսաբանեցինք մի քանի շաշկի, եկեք բաժանենք մի քանի վատ ծածկագիր: Այս վեց օրինակներից յուրաքանչյուրը ներկայացնում է ծածկագիր, որը չպետք է գրվի, և իրավիճակներ, որոնցում կոդերի ստուգիչները կարող են փրկել ձեզ:

Այս հոդվածը օգտագործում է JSHint օրինակների մեծ մասի համար, սակայն փակման կոմպիլյատորը սովորաբար տալիս է նմանատիպ նախազգուշացումներ:

== կամ ===?

JavaScript-ը դինամիկ մուտքագրված լեզու է: Կոդը գրելիս պետք չէ տեսակները սահմանել, բայց դրանք գոյություն ունեն գործարկման ժամանակ:

JavaScript-ն առաջարկում է երկու համեմատական օպերատոր՝ այս դինամիկ տեսակները շահարկելու համար՝ == և ===: Սրան նայենք օրինակով։

լաք = 123;
vars = «123»;

եթե (n == s) (
alert («Փոփոխականները հավասար են»);
}

եթե (n === s) (
alert («Փոփոխականները նույնական են»);
}

Համեմատության օպերատոր == C լեզվի մնացորդներն են, որում արմատավորված է JavaScript-ը։ Դրա օգտագործումը գրեթե միշտ սխալ է. արժեքները տեսակներից առանձին համեմատելը հազվադեպ է այն, ինչ իրականում ցանկանում է անել մշակողը: Փաստորեն, «հարյուր քսաներեք» թիվը տարբերվում է «մեկ երկու երեք» տողից։ Այս օպերատորները հեշտ է սխալ գրվել և նույնիսկ ավելի հեշտ է սխալ կարդալ: Փորձարկեք այս կոդը JSHint-ով և կստանաք սա.

test.js: տող 9, սյունակ 12, սպասվում էր «===" և փոխարենը տեսավ «==":

Չսահմանված փոփոխականներ և ուշ սահմանումներ

Սկսենք մի քանի պարզ կոդից.

ֆունկցիայի թեստ () (
var myVar = «Բարև աշխարհ»;
վահանակի մատյան (myvar);
}

Տեսնու՞մ եք վրիպակը: Ես ամեն անգամ այս սխալն եմ անում. Գործարկեք այս կոդը և կստանաք սխալ.

ReferenceError. myvar-ը սահմանված չէ

Եկեք խնդիրը մի փոքր ավելի բարդացնենք.

ֆունկցիայի թեստ () (
myVar = «Բարև աշխարհ»;
վահանակի մատյան (myVar);
}

Գործարկեք այս կոդը և կստանաք սա.

Բարեւ աշխարհ

Այս երկրորդ օրինակն աշխատում է, բայց այն ունի որոշ շատ անսպասելի կողմնակի ազդեցություններ: JavaScript փոփոխականների և շրջանակի սահմանման կանոնները լավագույն դեպքում շփոթեցնող են: Առաջին դեպքում JSHint-ը կհայտնի հետևյալը.

test.js. տող 3, սյունակ 17, «myvar» սահմանված չէ:

Երկրորդ դեպքում այն կհայտնի այս մասին.

test.js. տող 2, սյունակ 5, «myVar»-ը սահմանված չէ:
test.js. տող 3, սյունակ 17, «myVar»-ը սահմանված չէ:

Առաջին օրինակը կօգնի ձեզ խուսափել գործարկման ժամանակի սխալից: Ձեզ հարկավոր չէ փորձարկել ձեր հավելվածը. JSHint-ը ձեզ համար կգտնի սխալը: Երկրորդ օրինակն ավելի վատն է, քանի որ թեստի արդյունքում սխալ չեք գտնի:

Երկրորդ օրինակի խնդիրը նենգորեն նուրբ է և բարդ: myVar փոփոխականն այժմ անհետացել է իր տիրույթից և տարածվել է համաշխարհային տիրույթում: Սա նշանակում է, որ այն գոյություն կունենա և կունենա Hello, World արժեքը նույնիսկ թեստային ֆունկցիան գործարկելուց հետո: Սա կոչվում է «գլոբալ շրջանակի աղտոտում»:

MyVar փոփոխականը գոյություն կունենա յուրաքանչյուր այլ ֆունկցիայի համար, որը կգործարկվի թեստային ֆունկցիայից հետո: Փորձարկման գործառույթը կատարելուց հետո գործարկեք հետևյալ կոդը.

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

Դուք դեռ կստանաք Բարև, աշխարհ: MyVar փոփոխականը կաղապարի պես կախված կլինի ձեր կոդի շուրջը, ինչը հանգեցնում է բարդ սխալների, որոնք դուք փնտրելու եք թողարկումից առաջ ամբողջ գիշեր, այն պատճառով, որ մոռացել եք տեղադրել var:

Այս գրառումն անցել է Full-Text RSS ծառայության միջոցով. եթե սա ձեր բովանդակությունն է, և դուք այն կարդում եք ուրիշի կայքում, խնդրում ենք կարդալ ՀՏՀ-ն http://ift.tt/jcXqJW հասցեով:

Անվտանգ JavaScript հավելվածների մշակումը բավականին բարդ խնդիր է։ Բայց բավականին հնարավոր է: Այսօրվա հոդվածում մենք կանդրադառնանք JavaScript-ի առանձնահատկություններին, որոնք առաջացնում են անվտանգության խնդիրներ և կխոսենք դրանցից խուսափելու մասին:

Ինչու է դժվար գրել անվտանգ JS կոդ

Այսպիսով, ահա 5 պատճառ, թե ինչու գրելը դժվար է: անվտանգ ծածկագիրՋՍ-ում

Կազմողը չի օգնի:

JavaScript-ը մեկնաբանվող լեզու է: Իսկ դա նշանակում է, որ կոմպիլյատորը միշտ չէ, որ բողոքելու է ինչ-որ բանից՝ հրաժարվելով աշխատելուց և մղելով ձեզ ուղղել սխալներն ու օպտիմալացնել կոդը։

JavaScript-ի դինամիկ բնույթը

JavaScript-ը դինամիկ է, թույլ տպագրված և ասինխրոն: Եվ սրանք բոլորը նշաններ են, որ դժվարությունների մեջ մտնելը հեշտ է:

1. Լեզվական գործիքներ, ինչպիսիք են eval-ըև երրորդ կողմի կոդի ներառումը script src-ի միջոցով թույլ է տալիս կատարել տողեր հենց գործարկման ժամանակ: Որպես հետեւանք, դժվար է «ստատիկ երաշխիքներ» տալ, որ կոդը որոշակի կերպով կվարվի։ Դինամիկ վերլուծությունը նույնպես բարդացնում է դա (տես գիտական աշխատանք):

Օգտագործելով eval

2. Թույլ մուտքագրումհանգեցնում է նրան, որ հեշտ չէ կիրառել ստատիկ վերլուծության հաստատված մեթոդները, գոնե ստատիկ տպագրված լեզուների համեմատությամբ (օրինակ, Java):

3. Ասինխրոն զանգեր,զանգերը, որոնք JavaScript-ը թույլ է տալիս մեխանիզմների միջոցով, ինչպիսիք են setTimeout-ը և XMLHttpRequest-ը (շատ հայտնի AJAX), ըստ վիճակագրության, թաքցնում են ամենանենգ սխալները:

JS-ի բարդ առանձնահատկություններ

Այն, ինչ տարիների ընթացքում չի քաշվել JavaScript-ի մեջ: Մասնավորապես, այն ունի նախատիպեր, առաջին կարգի գործառույթներ, փակումներ։ Նրանք լեզուն ավելի դինամիկ են դարձնում և դժվարացնում են անվտանգ կոդ գրելը:

1. Նախատիպեր.Դրանց իմաստն այն է, որ ծրագրերը գրված են օբյեկտի վրա հիմնված մոտեցման ոգով, բայց առանց դասերի օգտագործման: Այս մոտեցմամբ օբյեկտները ժառանգում են իրենց անհրաժեշտ հատկությունները ուղղակիորեն այլ օբյեկտներից (նախատիպերից): Միևնույն ժամանակ, JS-ում նախատիպերը կարող են վերասահմանվել հենց գործարկման ժամանակ: Եվ եթե այս վերասահմանումը տեղի ունեցավ, ապա էֆեկտը անմիջապես տարածվում է բոլոր օբյեկտների վրա, որոնք ժառանգում են վերացված նախատիպի հատկությունները:

Ինչպես են մշակվում նախատիպերը

Արդարության համար պետք է ասել, որ դասեր կան նաև նոր ECMAScript-ի բնութագրերում:

2. Առաջին կարգի գործառույթներ. JS-ն ունի շատ ճկուն օբյեկտի և ֆունկցիայի մոդել: Օբյեկտների հատկությունները և դրանց արժեքները կարող են ստեղծվել, փոփոխվել կամ ջնջվել հենց գործարկման ժամանակ, և բոլորը հասանելի են առաջին կարգի գործառույթների միջոցով:

3. Փակումներ.Եթե դուք գործառույթ եք հայտարարում մեկ այլ ֆունկցիայի ներսում, ապա առաջինը հասանելի է դառնում վերջինիս փոփոխականներին և արգումենտներին: Ավելին, այս փոփոխականները շարունակում են գոյություն ունենալ և հասանելի են մնում ներքին ֆունկցիային, նույնիսկ այն բանից հետո, երբ արտաքին ֆունկցիան, որով սահմանված են այս փոփոխականները, ավարտված է:

JavaScript-ի նման ճկունության և դինամիզմի շնորհիվ (տես 1-ին և 3-րդ կետերը) ստատիկ վերլուծության ընթացքում օբյեկտի բոլոր հասանելի հատկությունների հավաքածուն որոշելը անլուծելի խնդիր է: Այնուամենայնիվ, վեբ մշակողները ամենուր օգտագործում են լեզվի դինամիկ առանձնահատկությունները, և, համապատասխանաբար, դրանք չեն կարող անտեսվել ծածկագիրը վերլուծելիս: Հակառակ դեպքում ո՞րն է անվտանգության երաշխիքը։

Սերտ փոխազդեցություն JavaScript-ի և DOM-ի միջև

Սա անհրաժեշտ է վեբ էջի «անխափան» թարմացում ապահովելու համար՝ հենց գործարկման ժամանակ: DOM-ը, ինչպես գիտեք, ստանդարտ է օբյեկտի մոդելը, չեզոք հարթակների և լեզուների նկատմամբ, որը նախատեսված է մատուցման համար HTML փաստաթղթերև XML: DOM-ն ունի իր API-ն՝ արտապատկերված փաստաթղթի հետ աշխատելու համար՝ դինամիկ մուտք գործելու, տեղափոխելու և թարմացնելու ներկայացված փաստաթուղթը (նրա բովանդակությունը, կառուցվածքը և ոճը): DOM-ում փոփոխությունները կարելի է դինամիկ կերպով կատարել JavaScript-ի միջոցով: Եվ այս փոփոխությունները անմիջապես ցուցադրվում են բրաուզերում:

DOM-ի շնորհիվ զննարկիչում բեռնված վեբ էջերը կարող են փուլ առ փուլ թարմացվել, երբ տվյալները բեռնվում են սերվերից: Այնուամենայնիվ, այս հարմարությունն ունի մի բացասական կողմ. կոդի հատվածները, որոնք պատասխանատու են JS-ի և DOM-ի միջև դինամիկ փոխազդեցության համար, հատկապես հակված են սխալների:

Վեբ հավելվածների ամենատարածված սխալները

Իրադարձությունների բարդ փոխազդեցություններ

JavaScript-ը իրադարձությունների վրա հիմնված լեզու է: Այն թույլ է տալիս ծրագրավորողներին գրանցել այսպես կոչված «իրադարձությունների ունկնդիրներ» DOM հանգույցներում՝ իրադարձություն լսողներ: Եվ չնայած իրադարձությունների մեծամասնությունը հրահրվում է օգտատերերի գործողությունների արդյունքում, կան այնպիսիք, որոնք կարող են գործարկվել առանց դրա, ինչպիսիք են ժամանակային իրադարձությունները և ասինխրոն զանգերը: Բացի այդ, յուրաքանչյուր իրադարձություն կարող է արձագանքվել ամբողջ DOM ծառի վրա և ակտիվացնել միանգամից մի քանի «լսողներ»: Երբեմն այս ամենին հետևելը բավականին ոչ տրիվիալ խնդիր է։

Ինչպես են վարվում իրադարձությունները

Այս պատճառներով JS կոդը կարող է դժվար լինել հասկանալ, վերլուծել և փորձարկել: Հատուկ կոմունալ ծառայությունները կհեշտացնեն վեբ մշակողի կյանքը և կօգնեն գրել անվտանգ կոդ:

JS կոդի փորձարկման կոմունալ ծառայություններ

Կան կոմունալ ծրագրեր վերլուծության համար (օրինակ՝ Esprima, Rhino), օպտիմալացման (օրինակ՝ Google Closure Compiler) և ստատիկ կոդի վերլուծության համար սովորական շարահյուսական սխալների համար (օրինակ՝ JSHint):

Բացի այդ, կան մի քանի ապացուցված շրջանակներ, որոնք օգնում են վեբ մշակողներին ծածկել JS կոդը թեստերով: Նրանց մեջ:

QUnit-ը միավորների փորձարկման հանրաճանաչ շրջանակ է.
Jasmine - BDD շրջանակ (Behavior-driven Development) կոդի փորձարկման համար;
Mocha-ն կոդի փորձարկման շրջանակ է, որն աշխատում է ինչպես Node.js-ում, այնպես էլ բրաուզերում;
jsTestDriver-ը շրջանակ է, որը, ի թիվս այլ բաների, կարող է միաժամանակ մի քանի բրաուզերների վրա մի շարք թեստեր անցկացնել:

Բացի այդ, կան թեստավորման շրջանակներ, որոնք ընդօրինակում են բրաուզերի վարքը և թույլ են տալիս ավտոմատ կերպով գործարկել թեստային դեպքերը: Դրանք հատկապես կարևոր են կոդի այն հատվածները, որոնք պատասխանատու են JS-ի և DOM-ի փոխազդեցության համար, և ապահովում են հարմար ենթակառուցվածք՝ DOM-ը շահարկելու համար:

Օրինակ, Selenium-ը, PhantomJS-ը և SlimerJS-ը տրամադրում են API, որի միջոցով կարող եք գործարկել և աշխատել բրաուզերի օրինակների հետ: API-ի միջոցով դուք կարող եք ակտիվացնել իրադարձությունները և մուտք գործել DOM տարրեր անմիջապես գործարկման ժամանակ, այսինքն՝ փորձարկել կոդը այնպիսի պայմաններում, որոնք հնարավորինս մոտ են իրականությանը: Իհարկե, շատ աշխատանք պետք է կատարվի ձեռքով, բայց նույնիսկ սա արդեն լավ օգնություն է թեստավորման համար:

Ստատիկ վերլուծության կոմունալ ծառայություններ

Նախկինում խնդրահարույց կոդերի բաժինները հայտնաբերելու կոմունալ ծառայությունները ստատիկ անալիզատորներ էին: Այսինքն, հաշվի առնելով JS-ի բոլոր դինամիկ տարօրինակությունները, կարող էր միայն սահմանափակ օգնություն տրամադրել: Այնուամենայնիվ, դրանք նույնպես օգտակար են վերլուծության մեջ: Ահա մի քանի հիմնական օրինակներ:

WARI-ն ստատիկ անալիզատոր է, որն ուսումնասիրում է JS ֆունկցիաների միջև կախվածությունը, css ոճերը, HTML պիտակներև պատկերներ։ Այս օգտակար ծրագրի նպատակն է ստատիկ վերլուծության ընթացքում չօգտագործված ռեսուրսներ գտնելը: Այնուամենայնիվ, WARI-ն, իհարկե, չի դիմանա դինամիկային:

JSLint-ը ստատիկ կոդի վերլուծության ծրագիր է, որն ինքնին գրված է JavaScript-ով: Այն ստուգում է օրենսգիրքը լավ փորձի դեմ:

Google Closure Compiler-ը JS օպտիմիզատոր է, որն ավտոմատ կերպով վերագրում է կոդը՝ այն ավելի արագ և կոմպակտ դարձնելու համար: Միևնույն ժամանակ, բոլոր մեկնաբանությունները և կոդի ցանկացած չօգտագործված հատվածները թռչում են խողովակի մեջ:

WebScent-ը (տես հետազոտական փաստաթուղթ) առաջադեմ ստատիկ անալիզատոր է: Աշխատանքի մեջ նա ելնում է նրանից, որ հաճախորդի JS կոդը (այն, որը բեռնված է զննարկիչում) ամբողջությամբ չի պահվում սերվերի կողմից, այլ կտոր-կտոր է ցրված սերվերի կոդով։ Այս կտորների «ծծումը» հնարավոր չէ հեշտությամբ հայտնաբերել, քանի դեռ դրանցից չի ստեղծվել ամուր հաճախորդի կոդը: WebScent-ը վերլուծում է հաճախորդի կոդը՝ սերվերի կոդում խնդրահարույց տարածքները գտնելու համար: Միևնույն ժամանակ, WebScent ստատիկ անալիզատորի աշխատանքը հիմնականում կրճատվում է HTML, CSS և JS խմբաքանակների բացահայտման վրա՝ HTML շարահյուսության մեջ կրկնվող կոդ և սխալներ հայտնաբերելու նպատակով:

Կոմունալ ծառայություններ դինամիկ վերլուծության համար

JSNose-ը կոմունալ ծրագիր է, որը համատեղում է ստատիկ և դինամիկ վերլուծությունները: Այն վերլուծում է տասներեք հակապատկերների ծածկագիրը: Դրանցից յոթը (ներառյալ ծույլ օբյեկտը և երկար ֆունկցիան) ընդհանուր են ծրագրավորման բոլոր լեզուների համար, իսկ մյուս վեցը (փակման հոտեր, չափազանց մեծ գլոբալ փոփոխականներ, ներդիր հետադարձ զանգեր և այլն) հատուկ են JavaScript-ին։

DOMPletion-ը ավտոմատացված ծրագիր է, որն օգնում է վեբ ծրագրավորողին հասկանալ կոդը դիտելիս. բացատրում է DOM կառուցվածքների առկայության պատճառը, կատարում է դինամիկ վերլուծություն, ինչպես նաև ապահովում է խելացի ավտոմատ լրացում կոդի համար, որը փոխազդում է DOM-ի հետ:

Clematis-ը շրջանակ է, որն օգնում է բացահայտել բարդ իրադարձությունների փոխազդեցությունները: Clematis-ը մանրամասնորեն ֆիքսում է բոլոր իրադարձությունները, որոնք կրակում են կատարման վրա և պատկերացնում դրանք որպես վերացական վարքային մոդել, որն արտացոլում է բաղադրիչների և իրադարձությունների միջև ժամանակային և պատճառահետևանքային հարաբերությունները:

եզրակացություններ

Այսպիսով, հետևելը, թե ինչ է տեղի ունենում, երբ JS սկրիպտները կատարվում են, կարող է դժվար լինել, բայց զինված լինելով ճիշտ գործիքներով, դուք կարող եք գտնել և վերաշարադրել խնդրահարույց տարածքները նույնիսկ ամենատարբեր կոդով: Այնուամենայնիվ, JavaScript-ը կանգ չի առնում. նրանում հայտնվում են նոր և նոր հնարավորություններ, այժմ այն հաճախ օգտագործվում է հավելվածներ գրելու համար (ինչպես բջջային, այնպես էլ աշխատասեղան), ինչպես նաև այն ավելի ու ավելի է հանդիպում սերվերներում (և ոչ միայն) շնորհիվ Node.js-ի: Իսկ դա նշանակում է, որ սխալներ որսալու արվեստը պետք է նոր մակարդակի հասցվի։

Ստատիկ անալիզատորները նայում են կոդը և գտնում են սխալներ, նախքան այն գործարկելը: Նրանք կատարում են պարզ ստուգումներ, օրինակ՝ ստուգում են կատարման շարահյուսությունը (օրինակ՝ բացատների փոխարեն ներդիրներ կան) և ավելի գլոբալ ստուգումներ, օրինակ՝ ստուգելով, որ գործառույթները չափազանց բարդ չեն: Ստատիկ անալիզատորները նաև փնտրում են սխալներ, որոնք հնարավոր չէ գտնել փորձարկման ժամանակ, օրինակ՝ ====-ի փոխարեն:

Խոշոր նախագծերում և մեծ թիմերում աշխատելիս կարող եք մի փոքր օգնություն օգտագործել այնպիսի «պարզ» սխալներ գտնելու համար, որոնք իրականում այնքան էլ պարզ չեն, որքան թվում է:

JSLint, JSHint և փակման կոմպիլյատոր

JavaScript-ի համար կա ստատիկ անալիզատորի երեք հիմնական տարբերակ՝ JSLint, JSHint և Closure Compiler:

JSLint-ը JavaScript-ի առաջին ստատիկ վերլուծիչն էր: Դուք կարող եք այն գործարկել պաշտոնական կայքում կամ օգտագործել հավելումներից մեկը, որը կարող է գործարկվել տեղական ֆայլերի վրա: JSLint-ը գտնում է շատ կարևոր սխալներ, բայց դա շատ դժվար է: Ահա մի պարզ օրինակ.

vars = «mystring»; համար (var i = 0; i< s.length; i++) { console.log(s.charAt(i)); }

JSLint-ը ցույց է տալիս այս կոդի երկու սխալ.

Անսպասելի «++»: Տեղափոխեք «var» հայտարարագրերը գործառույթի վերևում:

vars = «mystring»; var i; համար (i = 0; i< s.length; i = i + 1) { console.log(s.charAt(i)); }

JSHint-ն աշխատում է այնպես, ինչպես JSLint-ը, բայց այն գրված է ի հավելումն Node.js-ի և հետևաբար ավելի ճկուն: JSHint-ը ներառում է մեծ թվով տարբերակներ, որոնք թույլ են տալիս կատարել անհատական ստուգումներ՝ գրելով ձեր սեփական հաշվետվությունների գեներատորը:
Դուք կարող եք սկսել JSHint-ը ից, բայց շատ դեպքերում ավելի լավ է տեղադրել JSHint-ը որպես տեղական հրամանի տող գործիք՝ օգտագործելով Node.js-ը: JSHint-ը տեղադրելուց հետո կարող եք այն գործարկել ձեր ֆայլերում այս հրամանով.

jshint test.js

JSHint-ը ներառում է նաև հավելվածներ հանրաճանաչ տեքստային խմբագրիչների համար, այնպես որ կարող եք գործարկել այն կոդ գրելիս:

ՓԱԿՄԱՆ ԿԱՊԻԼԵՐ

Google's Closure Compiler-ը բոլորովին այլ տեսակի ծրագիր է: Ինչպես ցույց է տալիս նրա անունը, այն ոչ միայն ստուգիչ է, այլև կոմպիլյատոր։ Այն գրված է Java-ով և հիմնված է Mozilla-ի Rhino վերլուծիչի վրա: Փակման կոմպիլյատորը ներառում է պարզ ռեժիմ՝ հիմնական կոդի վավերացումն իրականացնելու համար, և ավելի առաջադեմ ռեժիմներ՝ լրացուցիչ վավերացում կատարելու և դիտման հատուկ սահմանումներ կիրառելու համար:

Closure Compiler-ը հաղորդում է JavaScript-ի կոդի սխալների մասին, բայց նաև արտադրում է JavaScript-ի նվազագույն տարբերակներ: Կազմողը հեռացնում է սպիտակ տարածությունը, մեկնաբանությունները և չօգտագործված փոփոխականները և պարզեցնում է երկար արտահայտությունները՝ սցենարը հնարավորինս կոմպակտ դարձնելով։

Java -jar compiler.jar --js_output_file compress.js --js test1.js --js test2.js

Ընտրելով ճիշտ թեստային ծրագիր

Իմ նախագծերում ես համատեղում եմ Closure Compiler-ը և JSHint-ը: Closure Compiler-ը կատարում է փոքրացման և հիմնական վավերացումը, մինչդեռ JSHint-ն անում է ավելի բարդ կոդի վերլուծություն: Երկու ծրագրերը հիանալի աշխատում են միասին, և յուրաքանչյուրն ընդգրկում է ոլորտներ, որոնք մյուսը չի կարող: Բացի այդ, ես կարող եմ օգտագործել JSHint ընդլայնումը հատուկ վավերացուցիչներ գրելու համար: Մի ընդհանուր ծրագիր, որը ես գրել եմ, ստուգում է որոշ գործառույթներ, որոնք ինձ պետք չեն, օրինակ՝ կանչելով գործառույթներ, որոնք չպետք է լինեն իմ նախագծում:

== կամ ===?

Վարն = 123; vars = «123»; if (n == s) ( alert ("Փոփոխականները հավասար են"); ) if (n === s) ( alert ("Փոփոխականները նույնական են"); )

Համեմատության օպերատոր == C լեզվի մնացորդներն են, որով արմատավորված է JavaScript-ը: Դրա օգտագործումը գրեթե միշտ սխալ է. արժեքները տեսակներից առանձին համեմատելը հազվադեպ է այն, ինչ իրականում ցանկանում է անել մշակողը: Փաստորեն, «հարյուր քսաներեք» թիվը տարբերվում է «մեկ երկու երեք» տողից։ Այս օպերատորները հեշտ է սխալ գրվել և նույնիսկ ավելի հեշտ է սխալ կարդալ: Փորձարկեք այս կոդը JSHint-ով և կստանաք սա.

Test.js. տող 9, սյունակ 12, սպասվում էր «===" և փոխարենը տեսավ «==":

Չսահմանված փոփոխականներ և ուշ սահմանումներ

Սկսենք մի քանի պարզ կոդից.

Function test() ( var myVar = «Բարև, աշխարհ»; console.log(myvar); )

Տեսնու՞մ եք վրիպակը: Ես ամեն անգամ այս սխալն եմ անում. Գործարկեք այս կոդը և կստանաք սխալ.

ReferenceError. myvar-ը սահմանված չէ

Եկեք խնդիրը մի փոքր ավելի բարդացնենք.

Function test() ( myVar = «Բարև, աշխարհ»; console.log (myVar); )

Գործարկեք այս կոդը և կստանաք սա.

Բարեւ աշխարհ

Test.js. տող 3, սյունակ 17, «myvar» սահմանված չէ:

Երկրորդ դեպքում այն կհայտնի այս մասին.

Test.js. տող 2, սյունակ 5, «myVar» սահմանված չէ: test.js. տող 3, սյունակ 17, «myVar»-ը սահմանված չէ:

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

ԱԼԵՔՍԱՆԴՐ ՄԱՅՈՐՈՎ,ծրագրավորող, ծրագրավորման 11 տարվա փորձ, որից յոթը նվիրված է շարժական սարքերի մշակմանը

Ստատիկ տիպի վերլուծություն JavaScript-ում
Փորձում ենք Facebook-ի Flow անալիզատորը

Facebook-ը ներկայացրել է Flow բաց կոդով նոր նախագիծ՝ ստատիկ կոդերի անալիզատոր JavaScript լեզվի համար: Անալիզատորի մշակման հիմնական նպատակն է պարզեցնել սխալների որոնումը

Բացի այդ, Flow-ը միջոցներ է տրամադրում JavaScript լեզվի TypeScript ոճի շարահյուսական ընդլայնման տեսքով՝ հստակորեն նշելու տեսակները: ECMAScript 6-ում ներկայացված նոր հնարավորություններից շատերն ապահովված են:

Ծրագրավորման լեզուներով մուտքագրելու թեման հաճախ է շոշափվում։ Սա հոլիվարների և որոշակի լեզվի դրական կամ բացասական հատկանիշների որոշման թեմա է: Վերջերս շատ է խոսվում JavaScript-ով մուտքագրելու մասին: Ոմանց դուր է գալիս այն, ինչպես կա: Մարդիկ, ովքեր ծանոթ են ծրագրավորման այլ լեզուներին, հատկապես նրանք, ովքեր հստակ տպագրում են, այս մոտեցումը համարում են «նռնակ կապիկի ձեռքում»: Մենք բոլորս գիտենք, որ JavaScript-ը թույլ դինամիկ մուտքագրված լեզու է: Front-end-ի զարգացման գուրուները սովորել են դա օգտագործել լավ, բայց կոդը երբեմն դժվար է հասկանալ: Նրանք, ովքեր նոր են մտել JavaScript ծրագրավորման աշխարհ, շփոթված են թարգմանչի կատարած կախարդանքից և հաճախ բացահայտում են սխալները: Բայց նախ, եկեք մի փոքր հասկանանք ընդհանրապես մուտքագրելու մասին։ Ինչի է դա նման?

Մուտքագրում ծրագրավորման լեզուներով

Տպագրված ծրագրավորման լեզուները բաժանվում են երկու լայն ճամբարի՝ տպագրված և անտիպ: Տպված լեզուները, օրինակ, ներառում են այնպիսի լեզուներ, ինչպիսիք են C, Python, PHP, Lua, JavaScript: Չտիպված լեզուների օրինակներ՝ assembler, Forth, Brainfuck: Այո Այո ճիշտ: JavaScript-ը, ինչպես շատ այլ մեկնաբանվող լեզուներ, տպագրված է: Ուստի ոչ մի դեպքում մի ասեք, որ անտիպ է։ Հատկապես հարցազրույցներում:

Իր հերթին, տպագրված լեզուները բաժանվում են ևս մի քանի համընկնող կատեգորիաների.

Ստատիկ կամ դինամիկ մուտքագրմամբ:
Ուժեղ կամ ազատ տպագրությամբ:
Բացահայտ կամ անուղղակի մուտքագրումով:

Լեզուներ ստատիկ մուտքագրմամբ

Ստատիկ մուտքագրման դեպքում փոփոխականների և ֆունկցիաների վերջնական տեսակները սահմանվում են կոմպիլյացիայի ժամանակ: Կազմողն ուղղում է ձեր տեսակի անհամապատասխանության սխալները՝ նախքան ծրագիրը գործարկելը: Օրինակ լեզուներ՝ C, Java, C#:

Լեզուներ դինամիկ մուտքագրմամբ

IN դինամիկ մուտքագրումբոլոր տեսակները որոշվում են գործարկման ժամանակ: Եվ եթե դուք սխալվեք, ապա դրա մասին կիմանաք միայն այն ժամանակ, երբ գործարկեք ծրագիրը: Հետևաբար, շատ կարևոր է դինամիկ մուտքագրման ժամանակ հատուկ ուշադրություն դարձնել ստուգումներին և սխալների թակարդին: Օրինակ լեզուներ՝ JavaScript, PHP, Python, Ruby:

Ուժեղ մուտքագրում (ուժեղ)

Խիստ տպագրված լեզուները թույլ չեն տալիս խառնել արտահայտությունները Տարբեր տեսակներև չի կատարի ավտոմատ ենթադրյալ տիպի փոխարկումներ: Օրինակ, դուք չեք կարող տողից հանել թիվ կամ այլ տեսակ, բացի տողից: Օրինակ լեզուներ՝ Java, Python, Haskell, Lisp:

Ազատ մուտքագրում (թույլ)

Լայն տպագրված լեզուները ինքնաբերաբար կատարում են բազմաթիվ անուղղակի տիպի փոխարկումներ: Նրանք դա անում են, թեև ճշգրտության կամ փոխակերպման կորուստը կարող է տեղի ունենալ ոչ միանշանակորեն: Օրինակ լեզուներ՝ PHP, JavaScript, Visual Basic:

Բացահայտ մուտքագրում

Հստակ մուտքագրված լեզուներում նոր փոփոխականների/ֆունկցիաների և արգումենտների տեսակը պետք է հստակորեն սահմանվի: Օրինակ լեզուներ՝ C++, D, C#:

Անուղղակի մուտքագրում

Անուղղակի մուտքագրում ունեցող լեզուներում տեսակները նշելու խնդիրը տեղափոխվում է կոմպիլյատոր / թարգմանիչ: Օրինակ լեզուներ՝ JavaScript, PHP, Lua: Նման լեզուներում, որպես կանոն, օբյեկտներն ունեն հատուկ մեթոդներ, որոնք կոչվում են տիպի վրա նետվելիս։ Օրինակ, PHP-ն ունի _toString() մեթոդը, իսկ JavaScript-ն ունի նույնանուն մեթոդ, բայց առանց ընդգծման՝ toString(): Այս մեթոդները կոչվում են, երբ օբյեկտը փոխանցվում է լարային տիպի: Երբեմն նման մեթոդները կոչվում են մոգություն (ցանկացած անուղղակի գործընթաց միշտ կախարդական է):

Կարևոր է նշել, որ այս բոլոր կատեգորիաները համընկնում են: Այս կատեգորիաների հիման վրա մենք եզրակացնում ենք, որ JavaScript-ն ունի դինամիկ անուղղակի մուտքագրում: Իսկ չափազանցված խոսելով՝ լեզվի բնույթը կարելի է բնութագրել այսպես՝ ցանկացած անհասկանալի իրավիճակում ամեն ինչ հասցրե՛ք պարզունակության, հիմնականում՝ լարայինի։ Թեև իրականում ամեն ինչ մի փոքր ավելի բարդ է, բայց մենք հիմա չենք մանրամասնի։

Ինչու՞ մեզ պետք է մուտքագրել: դուք կարող եք հարցնել. Առանց դրա JavaScript-ը լավ ապրեց 20 տարի: Պատասխանը պարզ է. նախկինում ձեռնարկության մակարդակի բարդ խնդիրները չէին լուծվում JavaScript-ում: Այժմ այս լեզուն դուրս է եկել զննարկիչից և մտել է հետին պլանի տարածք։ Մեծ հավելված գրելիս դժվար է դառնում սխալներ հայտնաբերելը, որոնք հաճախ կապված են տիպի ձուլման հետ:

JavaScript հավելումներ

Քանի որ JavaScript-ը կատարվում է հաճախորդի կողմը(բրաուզերներում), ապա խնդրի լուծման տարբերակներից մեկը լեզու ստեղծելն է՝ բարբառ, որը կկազմվի JS-ում։ Այն գործում է որպես մոնտաժող:

Լեզուներ, ինչպիսիք են TypeScript-ը, Dart-ը, AtScript-ը, ի հայտ են եկել, որոնք ավելացնում են ստատիկ ուժեղ մուտքագրում և նույնիսկ գործարկման տիպի ստուգում (չնայած դա ավելացնում է ծախսերը): Այս բոլոր լեզուները ոչ միայն ավելացնում են տեսակներ, այլ նաև ավելացնում են կամ շարահյուսական շաքար կամ նույնիսկ իրենց սեփական VM իրականացումը, որը գրված է JS-ով:

Ամբողջական հոդվածը կարդացեք ամսագրում Համակարգի ադմինիստրատոր», թիվ 1-2 2015 թ. 86-88 էջերում։

PDF տարբերակը տրված համարըկարելի է գնել մեր խանութ-սրահից։

Flow կայքը http://flowtype.org է:

հետ շփման մեջ

][ թիմից յուրաքանչյուրն ունի իր նախապատվությունները՝ կապված ծրագրային ապահովման և փորձարկման համար կոմունալ ծառայությունների հետ: Խորհրդակցելուց հետո պարզեցինք՝ ընտրությունն այնքան տարբեր է, որ կարող ես իրական ջենթլմենական ապացուցված ծրագրերի հավաքածու պատրաստել։ Այդ մասին նրանք որոշեցին. Որպեսզի համակցված խոզուկ չստեղծվի, ամբողջ ցանկը բաժանված է թեմաների: Այսօր մենք կվերլուծենք ստատիկ կոդի անալիզատորներհավելվածներում խոցելիություններ որոնելու համար, երբ դրանց սկզբնական կոդերը հասանելի են:

Ծրագրի սկզբնական կոդերի առկայությունը մեծապես հեշտացնում է խոցելիության որոնումը: Հավելվածին փոխանցվող տարբեր պարամետրերը կուրորեն շահարկելու փոխարեն, շատ ավելի հեշտ է տեսնել, թե ինչպես է այն մշակում դրանք: Ասենք, եթե օգտատիրոջ տվյալները փոխանցվում են առանց ստուգումների և փոխակերպումների, այն հասնում է SQL հարցումին, մենք ունենք SQL ներարկման խոցելիություն։ Եթե նրանք հասնում են HTML կոդի ելքին, մենք ստանում ենք դասական XSS: Նման իրավիճակները հստակ հայտնաբերելու համար անհրաժեշտ է ստատիկ սկաներ, բայց, ցավոք, դա միշտ չէ, որ հեշտ է, ինչպես թվում է:

Ժամանակակից կոմպիլյատորներ

Դա կարող է թվալ ծիծաղելի, բայց ամենաարդյունավետներից մեկը կոդերի անալիզատորներիրենք կազմողներն են։ Իհարկե, դրանք նախատեսված են բոլորովին այլ բանի համար, բայց որպես բոնուս՝ նրանցից յուրաքանչյուրն առաջարկում է լավ կոդերի ստուգիչ, որը կարող է հայտնաբերել մեծ թվով սխալներ։ Ինչո՞ւ չի խնայում։ Սկզբում նման կոդի ստուգման կարգավորումները բավականին հավատարիմ են դրված. արդյունքում, որպեսզի ծրագրավորողին խայտառակ չլինի, կոմպիլյատորը սկսում է հայհոյել միայն ամենալուրջ խցանումների դեպքում։ Բայց ապարդյուն. եթե նախազգուշացումների մակարդակն ավելի բարձր եք սահմանում, ապա միանգամայն հնարավոր է կոդի մեջ շատ կասկածելի տեղեր փորել: Կարծես սա է. Ենթադրենք, կոդի մեջ պակասում է ստուգել տողի երկարությունը բուֆերում պատճենելուց առաջ։ Սկաները գտնում է ֆունկցիա, որը պատճենում է տողը (կամ դրա հատվածը) ֆիքսված չափի բուֆերի մեջ՝ առանց դրա երկարությունը նախապես ստուգելու: Այն հետևում է արգումենտների փոխանցման հետագիծը՝ մուտքային տվյալներից մինչև խոցելի ֆունկցիա, և տեսնում է, թե արդյոք հնարավոր է ընտրել լարային երկարություն, որը կառաջացնի գերհոսք խոցելի ֆունկցիայի մեջ և չի կտրվի դրան նախորդող ստուգումներով: Եթե նման ստուգում չկա, մենք հայտնաբերում ենք գրեթե 100% բուֆերային արտահոսք: Կոմպիլյատորը ստուգելու համար օգտագործելու հիմնական դժվարությունն այն է, որ այն «կուլ տա» ուրիշի կոդը: Եթե երբևէ փորձել եք հավելված կազմել աղբյուրից, ապա գիտեք, թե որքան դժվար է բավարարել բոլոր կախվածությունները, հատկապես խոշոր նախագծերում: Բայց արդյունքն արժե այն: Ավելին, բացի կոմպիլյատորից, հզոր IDE-ներն ունեն նաև այլ գործիքներ կոդի վերլուծություն. Օրինակ՝ Visual Studio-ում կոդի հետևյալ հատվածը նախազգուշացում կհրապարակի օղակում _alloca ֆունկցիայի օգտագործման մասին, որը կարող է արագորեն հեղեղել կույտը.

char*b;
անել (
b = (char*)_alloca (9)
) մինչդեռ (1)

Սա PREfast ստատիկ անալիզատորի արժանիքն է: Ինչպես FxCop-ը կառավարվող կոդերի վերլուծության համար, PREfast-ն ի սկզբանե բաշխվել է որպես առանձին կոմունալև միայն ավելի ուշ դարձավ Visual Studio-ի մի մասը:

RATS - Անվտանգության կոպիտ աուդիտի գործիք

Կայք: www.securesoftware.com
Լիցենզիա՝ GNU GPL
Պլատֆորմ՝ Unix, Windows
Լեզուներ՝ C++, PHP, Python, Ruby

Սխալ սխալ - վեճ: Որոշ թերություններ, որոնք թույլ են տալիս ծրագրավորողները, կրիտիկական չեն և սպառնում են միայն ծրագրի անկայունությամբ: Մյուսները, ընդհակառակը, թույլ են տալիս ներարկել shellcode և կատարել կամայական հրամաններ հեռավոր սերվերի վրա: Կոդի մեջ առանձնահատուկ ռիսկի են ենթարկվում հրամանները, որոնք թույլ են տալիս բուֆերի արտահոսք և նմանատիպ այլ տեսակի հարձակումներ: Նման հրամանները շատ են, C/C++-ի դեպքում դրանք տողերի հետ աշխատելու ֆունկցիաներ են (xstrcpy(), strcat(), gets(), sprintf(), printf(), snprintf(), syslog() ), համակարգի հրամաններ (մուտք(), chown(), chgrp(), chmod(), tmpfile(), tmpnam(), tempnam(), mktemp()), ինչպես նաև համակարգի կանչի հրամաններ (exec(), համակարգ (), popen() ). Ամբողջ ծածկագիրը ձեռքով ուսումնասիրելը (հատկապես եթե այն բաղկացած է մի քանի հազար տողից) բավականին հոգնեցուցիչ է։ Սա նշանակում է, որ դուք հեշտությամբ կարող եք անտեսել չստուգված պարամետրերի որոշ գործառույթների փոխանցումը: Հատուկ գործիքներ աուդիտի համար, ներառյալ հայտնի կոմունալը առնետներ (Անվտանգության կոպիտ աուդիտի գործիք) հայտնի Fortify ընկերությունից։ Այն ոչ միայն հաջողությամբ կկառավարի C/C ++-ով գրված կոդը, այլև կկարողանա մշակել Perl, PHP և Python սկրիպտները: Կոմունալ տվյալների բազան պարունակում է տպավորիչ ընտրություն կոդում խնդրահարույց տարածքների մանրամասն նկարագրությամբ: Անալիզատորի օգնությամբ նա կմշակի իրեն սնվող աղբյուրը և կփորձի բացահայտել սխալները, որից հետո տեղեկատվություն կտրամադրի հայտնաբերված թերությունների մասին։ առնետներաշխատում է միջոցով հրամանի տող, ինչպես Windows, այնպես էլ *nix համակարգերի ներքո։

Յասկա

Կայք: www.yasca.org
Լիցենզիա՝ բաց կոդով
Պլատֆորմ՝ Unix, Windows
Լեզուներ՝ C++, Java, .NET, ASP, Perl, PHP, Python և այլն:

Յասկաճիշտ այնպես, ինչպես RATS-ը տեղադրման կարիք չունի, մինչդեռ այն ունի ոչ միայն կոնսոլային ինտերֆեյս, այլև պարզ GUI: Մշակողները խորհուրդ են տալիս գործարկել կոմունալը վահանակի միջոցով. նրանք ասում են, որ ավելի շատ հնարավորություններ կան: Ծիծաղելի է, որ Yasca շարժիչը գրված է PHP 5.2.5-ով, իսկ թարգմանիչը (ամենակտրված տարբերակով) գտնվում է ծրագրի հետ արխիվի ենթաթղթապանակներից մեկում։ Ամբողջ ծրագիրը տրամաբանորեն բաղկացած է ճակատային մասից, սկանավորող պլագինների մի շարքից, հաշվետվությունների գեներատորից և ինքնին շարժիչից, որը ստիպում է բոլոր փոխանցումները միասին պտտվել: Փլագինները թափվում են plugins գրացուցակում. այնտեղ պետք է տեղադրվեն նաև լրացուցիչ հավելումներ: Կարևոր կետ! Ստանդարտ պլագիններից երեքը, որոնք գալիս են Յասկա, ունեն տհաճ կախվածություններ: JLint-ը, որը սկանավորում է Java-ի .class ֆայլերը, պահանջում է jlint.exe ռեսուրսների/կոմունալ գրացուցակում: Երկրորդ փլագինը` antiC-ը, որն օգտագործվում է Java և C/C++ տեսակները վերլուծելու համար, պահանջում է antic.exe նույն գրացուցակում: PMD, որը մշակում է Java կոդը, պահանջում է համակարգում տեղադրված Java JRE 1.4 կամ ավելի բարձր տարբերակը: Կարող եք ստուգել, արդյոք տեղադրումը ճիշտ է, մուտքագրելով «yasca ./resources/test/» հրամանը: Ինչ տեսք ունի սկանավորումը: Յասկաարդյունքը տալիս է հատուկ հաշվետվության տեսքով: Օրինակ, ստանդարտ GREP հավելվածներից մեկը թույլ է տալիս օգտագործել .grep ֆայլերում նկարագրված օրինաչափությունները՝ նշելու խոցելի կառուցվածքները և հեշտությամբ բացահայտելու մի շարք խոցելիություններ: Նման օրինաչափությունների մի շարք արդեն ներառված է ծրագրում՝ թույլ կոդավորումը որոնելու համար, «գաղտնաբառը հավասար է մուտքի» թույլտվություն, հնարավոր SQL ներարկումներ և շատ ավելին: Երբ զեկույցում ցանկանում եք ավելին տեսնել մանրամասն տեղեկություններ, շատ մի ծույլ մի՛ եղեք լրացուցիչ պլագիններ տեղադրել։ Մի բան արժե այն, որ նրանց օգնությամբ դուք կարող եք լրացուցիչ սկանավորել կոդը .NET (VB.NET, C#, ASP.NET), PHP, ColdFusion, COBOL, HTML, JavaScript, CSS, Visual Basic, ASP, Python, Perl-ում: .

Cppcheck

Կայք:
Լիցենզիա՝ բաց կոդով
Պլատֆորմ՝ Unix, Windows
Լեզուներ՝ C++

Կառուցապատողներ Cppcheckորոշեց չցրվել մանրուքների վրա և, հետևաբար, բռնել սխալների միայն խիստ սահմանված կատեգորիաները և միայն C ++ կոդով: Մի ակնկալեք, որ ծրագիրը կրկնօրինակի կոմպիլյատորի նախազգուշացումները. դա կանի առանց հուշագրի: Հետևաբար, մի ծույլ մի՛ եղեք կոմպիլյատորի համար նախազգուշացումների առավելագույն մակարդակ սահմանելու համար, և օգտագործեք Cppcheck՝ ստուգելու հիշողության արտահոսքը, տեղաբաշխման-տեղաբաշխման գործողությունների խախտումները, տարբեր բուֆերային հեղեղումները, հնացած գործառույթների օգտագործումը և շատ ավելին: Կարևոր դետալ՝ Cppcheck-ի մշակողները փորձել են նվազագույնի հասցնել կեղծ պոզիտիվների քանակը։ Հետևաբար, եթե ծրագիրը շտկում է սխալ, ամենայն հավանականությամբ կարող եք ասել. Վերլուծությունը կարող եք սկսել և՛ վահանակից, և՛ Qt-ով գրված և ցանկացած հարթակի տակ աշխատող գեղեցիկ GUI-ինտերֆեյսի օգնությամբ։

Graudit

Կայք՝ www.justanotherhacker.com/projects/graudit.html
Լիցենզիա՝ բաց կոդով
Պլատֆորմ՝ Unix, Windows
Լեզուներ՝ C++, PHP, Python, Perl

Այս պարզ սկրիպտը, որը համակցված է մի շարք ստորագրությունների հետ, թույլ է տալիս գտնել մի շարք կարևոր խոցելիություններ կոդի մեջ, և որոնումն իրականացվում է հայտնի grep կոմունալ ծրագրի միջոցով: Այստեղ նույնիսկ GUI ինտերֆեյսի մասին հիշատակելը տեղին չէ. ամեն ինչ արվում է վահանակի միջոցով: Սկսելու համար կան մի քանի բանալիներ, բայց ամենապարզ դեպքում բավական է որպես պարամետր նշել աղբյուրների ուղին.

Graudit / ուղի / դեպի / սկան

Աշխատասիրության համար պարգևը կլինի գունեղ զեկույց կոդի պոտենցիալ շահագործվող վայրերի մասին: Պետք է ասեմ, որ բացի սկրիպտից (որը Bash կոդը ընդամենը 100 տող է), արժեքավոր են ստորագրության տվյալների բազաները, որոնք պարունակում են ռեգեքսներ և տարբեր լեզուներով պոտենցիալ խոցելի գործառույթների անուններ: Լռելյայնորեն, ներառված են Python-ի, Perl-ի, PHP-ի, C++-ի հիմքերը. դուք կարող եք ֆայլեր վերցնել ստորագրությունների թղթապանակից և օգտագործել դրանք ձեր սեփական մշակումների մեջ:

SWAAT

Կայք: www.owasp.org
Լիցենզիա՝ բաց կոդով
Պլատֆորմ՝ Unix, Windows
Լեզուներ՝ Java, JSP, ASP.Net, PHP

Եթե graudit-ն օգտագործում է տեքստային ֆայլեր՝ խոցելիության ստորագրությունը սահմանելու համար, ապա մուտքագրեք SWAAT- ավելի առաջադեմ մոտեցում XML ֆայլերի հետ: Ահա թե ինչ տեսք ունի տիպիկ ստորագրությունը.

vuln match- կանոնավոր արտահայտությունՈրոնման համար;
տեսակ - ցույց է տալիս խոցելիության տեսակը.
խստություն - ցույց է տալիս ռիսկի մակարդակը (բարձր, միջին կամ ցածր)
alt- Այլընտրանքային տարբերակկոդ՝ խնդիրը լուծելու համար

SWAATկարդում է ստորագրության տվյալների բազան և օգտագործում այն Java, JSP, ASP .Net և PHP աղբյուրներում խնդրահարույց տարածքները գտնելու համար: Տվյալների բազան անընդհատ թարմացվում է և բացի «վտանգավոր» գործառույթների ցանկից, սա ներառում է բնորոշ սխալներտողերի ձևաչափման և SQL հարցումներ կազմելու մեջ: Հատկանշական է, որ ծրագիրը գրված է C #-ով, բայց այն նաև լավ է աշխատում nix-ի տակ՝ շնորհիվ Mono նախագծի՝ .Net հարթակի բաց իրականացում։

PHP սխալների սկաներ

Կայք՝ raz0r.name/releases/php-bug-scanner
Լիցենզիա՝ անվճար ծրագիր
Հարթակ՝ Windows
Լեզուներ՝ PHP

Եթե Ձեզ անհրաժեշտ է ստատիկ կերպով վերլուծել PHP հավելվածը, խորհուրդ եմ տալիս փորձել PHP սխալների սկաներ, որը գրել է մեր հեղինակը՝ raz0r. Ծրագրի աշխատանքը հիմնված է սկանավորման վրա տարբեր գործառույթներև փոփոխականներ PHP սկրիպտներում, որոնք կարող են օգտագործվել վեբ հարձակումների ժամանակ: Նման իրավիճակների նկարագրությունը կատարվում է այսպես կոչված նախադրյալների տեսքով, և ծրագիրն արդեն ներառում է 7 հատուկ նախադրյալներ՝ խմբավորված կատեգորիաների.

կոդի կատարում;
հրամանի կատարում;
գրացուցակի անցում;
գլոբալները վերագրել;
ներառում;
SQL ներարկում;
տարբեր.

Ծիծաղելի է, որ ծրագիրը գրված է PHP/WinBinder-ով և կազմված է bamcompile-ով, այնպես որ այն կարծես սովորական Windows հավելված լինի: Օգտագործողի համար հարմար ինտերֆեյսի միջոցով pentester-ը կարող է միացնել կամ անջատել կոդի վերլուծությունը որոշակի խոցելիության համար:

pixie

Կայք՝ pixybox.seclab.tuwien.ac.at
Լիցենզիա՝ անվճար ծրագիր
Պլատֆորմ՝ Unix, Windows
Լեզուներ՝ PHP

Գործիքի հիմքում սկանավորումն է աղբյուր կոդըև կառուցել տվյալների հոսքի գրաֆիկներ: Այս գրաֆիկը ցույց է տալիս տվյալների ուղին, որը գալիս է ծրագրի դրսից՝ օգտագործողից, տվյալների բազայից, ինչ-որ արտաքին հավելվածից և այլն: Այս կերպ կառուցվում է հավելվածների խոցելի կետերի (կամ մուտքերի) ցանկը: Խոցելիությունները նկարագրող օրինաչափությունների օգնությամբ Pixy-ն ստուգում է այդպիսի կետերը և թույլ է տալիս որոշել XSS և SQL խոցելիությունները։ Ավելին, գրաֆիկները, որոնք ստեղծվել են վերլուծության ընթացքում, կարող են դիտվել գրաֆիկների թղթապանակում (օրինակ, xss_file.php_1_dep.dot) - սա շատ օգտակար է հասկանալու համար, թե ինչու է կոդի այս կամ այն բաժինը համարվում Pixy: - խոցելի. Ընդհանուր առմամբ, մշակումն ինքնին չափազանց տեղեկատվական է և ցույց է տալիս, թե ինչպես են աշխատում ստատիկ կոդի վերլուծության առաջադեմ կոմունալ ծառայությունները: Փաստաթղթերի էջում ծրագրավորողը հստակ խոսում է ծրագրի տարբեր փուլերի մասին, բացատրում է տրամաբանությունն ու ալգորիթմը, թե ինչպես պետք է ծրագրի կողմից վերլուծվի այս կամ այն կոդը։ Ծրագիրն ինքնին գրված է Java-ով և տարածվում է բաց կոդով, իսկ գլխավոր էջում կա նույնիսկ պարզ առցանց ծառայություն՝ XSS-ի խոցելիության համար ծածկագիրը ստուգելու համար:

ունցիա 6

Կայք՝ www.ouncelabs.com/products
Լիցենզիա. shareware
Հարթակ՝ Windows

Ավաղ, գոյություն ունեցող անվճար լուծումները դեռևս մի փոքր ավելի ցածր են, քան իրենց առևտրային գործընկերները: Բավական է ուսումնասիրել զեկույցի որակն ու մանրամասնությունը, որն է ունցիա 6- և հասկանալ, թե ինչու: Ծրագիրը հիմնված է Ounce Core վերլուծության հատուկ շարժիչի վրա, որը ստուգում է ծածկագիրը կանոններին և քաղաքականությանը համապատասխանելու համար, որոնք կազմվել են պրոֆեսիոնալ ներխուժողների թիմի կողմից, ովքեր կուտակել են հայտնի անվտանգության ընկերությունների, հաքերների համայնքի և անվտանգության ստանդարտների փորձը: . Ծրագիրը հայտնաբերում է կոդի մի շարք խոցելիություններ՝ բուֆերային հոսքերից մինչև SQL ներարկումներ: Ցանկության դեպքում, Ounce-ը հեշտությամբ ինտեգրվում է հանրաճանաչ IDE-ներին՝ մշակվող հավելվածի յուրաքանչյուր նոր կառուցվածքի կառուցման ընթացքում կոդերի ավտոմատ ստուգում իրականացնելու համար: Ի դեպ, ծրագրավորող ընկերությունը՝ Ounce Labs-ը գնել է հենց IBM-ն այս ամառ։ Այսպիսով, արտադրանքը, ամենայն հավանականությամբ, կշարունակի մշակվել որպես IBM-ի կոմերցիոն հավելվածներից մեկի մաս:

Klocwork Insight

Կայք: www.klocwork.com
Լիցենզիա. shareware
Հարթակ՝ Windows
Լեզուներ՝ C++, Java, C#

Երկար ժամանակ այս, կրկին, առևտրային արտադրանքն իրականացնում էր ստատիկ կոդի սկանավորում միայն C, C+ և Java-ի համար: Բայց հենց որ Visual Studio 2008-ը և .NET Framework 3.5-ը դուրս եկան, մշակողները հայտարարեցին C #-ին աջակցելու մասին: Ծրագիրը վարեցի իմ օժանդակ նախագծերից երկուսի վրա, որոնք հապճեպ գրեցի «սուր» վրա, և ծրագիրը բացահայտեց 7 կրիտիկական խոցելիություն։ Լավ է, որ դրանք գրված են բացառապես ներքին օգտագործման համար :)։ Klocwork Insightի սկզբանե կազմաձևված, առաջին հերթին, աշխատելու ինտեգրված զարգացման միջավայրերի հետ համատեղ: Նույն Visual Studio-ի կամ Eclipse-ի հետ ինտեգրումը չափազանց հաջող է. սկսում ես լրջորեն մտածել, որ նման ֆունկցիոնալությունը պետք է լռելյայն ներդրված լինի դրանցում :): Եթե հաշվի չառնենք հավելվածի տրամաբանության հետ կապված խնդիրները և արագության հետ կապված խնդիրները, ապա Klocwork Insightհիանալի աշխատանք է կատարում՝ գտնելու բուֆերային հոսքեր, բացակայող օգտվողի կոդերի զտում, SQL/Path/Cross-site ներարկում, թույլ գաղտնագրում և այլն: Մեկ այլ հետաքրքիր տարբերակ է հավելվածի կատարման ծառ կառուցելը, որը թույլ է տալիս արագ խորանալ դրա մեջ ընդհանուր սկզբունքհավելվածի աշխատանքը և առանձին հետևել, օրինակ, օգտագործողի ցանկացած մուտքի մշակմանը: Իսկ կոդը ստուգելու կանոնների արագ կառուցման համար առաջարկվում է նույնիսկ հատուկ գործիք՝ Klocwork Checker Studio.

Coverity Prevent Static Analysis

Կայք: www.coverity.com/products
Լիցենզիա. shareware
Հարթակ՝ Windows
Լեզուներ՝ C++, Java, C#

C/C++, Java-ի և C#-ի ամենահայտնի ստատիկ կոդերի անալիզատորներից մեկը: Ըստ դրա ստեղծողների՝ լուծումն օգտագործվում է աշխարհի ավելի քան 100,000 ծրագրավորողների կողմից։ Մտածված մեխանիզմները թույլ են տալիս ավտոմատացնել հիշողության արտահոսքի, չբացահայտված բացառությունների, կատարողականի խնդիրների և, իհարկե, անվտանգության խոցելիության որոնումը: Արտադրանքն աջակցում է տարբեր հարթակներ, կոմպիլյատորներ (gcc, Microsoft Visual C++ և շատ ուրիշներ), ինչպես նաև ինտեգրվում է զարգացման տարբեր միջավայրերի, հիմնականում՝ Eclipse-ի և Visual Studio-ի հետ: Կոդի անցումը հիմնված է ոչ թե սկզբից մինչև վերջ համր անցման ալգորիթմների վրա, այլ վրիպազերծիչի նման մի բան, որը վերլուծում է, թե ինչպես է ծրագիրը վարվելու տարբեր իրավիճակներում ճյուղի հանդիպումից հետո: Այսպիսով, ձեռք է բերվում ծածկագրի 100% ծածկույթ: Նման բարդ մոտեցում էր պահանջվում, ի թիվս այլ բաների, ամբողջությամբ վերլուծելու բազմաթելային հավելվածները, որոնք հատուկ օպտիմիզացված են բազմամիջուկ պրոցեսորների վրա աշխատելու համար: Coverity Integrity Centerթույլ է տալիս գտնել այնպիսի սխալներ, ինչպիսիք են մրցավազքի պայմանները (սխալ բազմաֆունկցիոնալ համակարգի նախագծման մեջ, որի դեպքում համակարգի աշխատանքը կախված է կոդի մասերի կատարման հերթականությունից), փակուղիներ և շատ ավելին: Ինչու է դա անհրաժեշտ հակադարձների համար: Հարցրեք Firefox-ի և IE-ի 0day sploits մշակողներին դրա մասին :):

OWASP Code Crawler

Կայք: www.owasp.org
Լիցենզիա՝ GNU GPL
Հարթակ՝ Windows
Լեզուներ՝ Java, C#, VB

Այս գործիքի ստեղծողը` Ալեսիո Մարզիալին, ASP.NET-ում երկու գրքի հեղինակ է, ֆինանսական հատվածի համար բարձր բեռնված հավելվածների հեղինակավոր կոդավորող և գրող: 2007 թվականին նա հրապարակել է քննադատական խոցելի կետեր Իտալիայի կառավարության 27 կայքերում: Նրա սերունդը - OWASP Code Crawler- նախատեսված է .NET և J2EE / JAVA կոդի ստատիկ վերլուծության համար, որը բաց է հասանելի ինտերնետում, իսկ տարեվերջին հեղինակը խոստանում է թողարկել նոր տարբերակշատ ավելի ֆունկցիոնալությամբ ծրագրեր: Բայց ամենակարևորն արդեն իրականացվել է՝ կոդերի վերլուծությունը C #-ում, Visual Basic-ում և Java-ում։ Սկանավորման համար նախատեսված ֆայլերը ընտրվում են GUI-ի միջոցով, և սկանավորումն ինքնաբերաբար սկսվում է: Յուրաքանչյուր խնդրահարույց կոդի բաժնի համար խոցելիության նկարագրությունը ցուցադրվում է «Սպառնալիքի նկարագրություն» բաժնում: Ճիշտ է, դաշտ OWASP ուղեցույցներ, հավանաբար նշելով խնդրի լուծման ուղիները, ավաղ, դեռ հասանելի չէ։ Բայց դուք կարող եք օգտագործել հեռակառավարվող մեքենայի վրա կոդի սկանավորման փորձարարական հնարավորությունը, որը հասանելի է «Հեռակա սկանավորում» ներդիրում: Հեղինակը խոստանում է լրջորեն արդիականացնել այս հատկությունը և, ի թիվս այլ բաների, համախմբել հավելվածի սկզբնական կոդը վերլուծության համար անմիջապես տարբերակների կառավարման համակարգից:

ԶԳՈՒՇԱՑՈՒՄ

Տեղեկատվությունը տրամադրվում է տեղեկատվական նպատակներով և հիմնականում ցույց է տալիս, թե ինչպես կարող են մշակողները խուսափել կրիտիկական սխալներից հավելվածի մշակման ժամանակ: Ոչ հեղինակը, ոչ էլ խմբագիրները պատասխանատվություն չեն կրում ձեռք բերված գիտելիքներն անօրինական նպատակներով օգտագործելու համար: