Կայքերի անվտանգության մահացու մեղքերը. այն, ինչ մենք սովորեցինք տարվա խոցելիության սկաների վիճակագրությունից

Մոտ մեկ տարի առաջ մենք DataLine-ում գործարկեցինք ծառայություն որոնել և վերլուծել ՏՏ հավելվածների խոցելիությունը: Ծառայությունը հիմնված է Qualys ամպային լուծման վրա, որի շահագործման մասին մենք արդեն պատմել ենք. Լուծման հետ աշխատելու մեկ տարվա ընթացքում մենք իրականացրել ենք 291 սկանավորում տարբեր կայքերի համար և կուտակել վիճակագրություն վեբ հավելվածների ընդհանուր խոցելիության վերաբերյալ։ 

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

Qualys-ը վեբ հավելվածների բոլոր խոցելիությունները բաժանում է երեք մակարդակի՝ ցածր, միջին և բարձր: Եթե ​​նայեք բաշխմանը «խստությամբ», ապա թվում է, որ ամեն ինչ այնքան էլ վատ չէ։ Կան մի քանի խոցելիություններ, որոնք ունեն քննադատության բարձր մակարդակ, հիմնականում բոլորն էլ ոչ կրիտիկական են. 

Բայց անքննադատ չի նշանակում անվնաս։ Նրանք կարող են նաև լուրջ վնաս պատճառել: 

Լավագույն «ոչ կրիտիկական» խոցելիությունները

1. Խառը բովանդակության խոցելիություններ.

   Կայքի անվտանգության ստանդարտը հաճախորդի և սերվերի միջև տվյալների փոխանցումն է HTTPS արձանագրության միջոցով, որն աջակցում է կոդավորմանը և պաշտպանում է տեղեկատվությունը գաղտնալսումից: 

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

   Բրաուզերների նոր տարբերակները զգուշացնում են օգտատերերին, որ խառը բովանդակությամբ կայքերն անվտանգ չեն և արգելափակում են բովանդակությունը: Վեբ կայքերի մշակողները նաև բրաուզերի նախազգուշացումներ են ստանում վահանակում: Օրինակ, այսպես է երևում firefox: 

   
   
   Ինչու է դա վտանգավոր:Հարձակվողներն օգտագործում են անապահով արձանագրություն՝ օգտատիրոջ տեղեկատվությունը որսալու, սկրիպտները փոխարինելու և նրա անունից կայք հարցումներ ուղարկելու համար: Նույնիսկ եթե կայքի այցելուն տվյալներ չի մուտքագրել, դա նրան չի պաշտպանում ֆիշինգ - խարդախ մեթոդների կիրառմամբ գաղտնի տեղեկատվության ստացում: Օրինակ՝ օգտագործելով սկրիպտը, դուք կարող եք օգտատիրոջը վերահղել դեպի ոչ անվտանգ կայք, որը քողարկվում է որպես օգտագործողին ծանոթ: Որոշ դեպքերում վնասակար կայքը նույնիսկ ավելի լավ տեսք ունի, քան բնօրինակը, և օգտատերը կարող է ինքնուրույն լրացնել ձևը և ներկայացնել գաղտնի տվյալներ։ 

   Ինչ պետք է հիշի վեբ մշակողըՆույնիսկ եթե կայքի ադմինիստրատորը տեղադրել և կազմաձևել է SSL/TLS վկայական, խոցելիությունը կարող է առաջանալ մարդկային սխալի պատճառով: Օրինակ, եթե էջերից մեկում դրել եք ոչ թե հարաբերական հղում, այլ բացարձակ հղում http-ից, և բացի այդ չեք տեղադրել http-ից դեպի https վերահղումներ։ 

   Դուք կարող եք հայտնաբերել խառը բովանդակություն կայքում՝ օգտագործելով զննարկիչը՝ որոնել էջի սկզբնական կոդը, կարդալ ծանուցումները մշակողի վահանակում: Այնուամենայնիվ, մշակողը ստիպված կլինի երկար ժամանակ և հոգնեցուցիչ կերպով կոդի հետ աշխատել: Դուք կարող եք արագացնել գործընթացը ավտոմատացված վերլուծության գործիքների միջոցով, օրինակ. SSL Check- ը, անվճար Lighthouse ծրագրակազմ կամ վճարովի ծրագրակազմ Screaming Frog SEO Spider:

   Բացի այդ, խոցելիությունը կարող է առաջանալ ժառանգված կոդի հետ կապված խնդիրների պատճառով: Օրինակ, եթե որոշ էջեր ստեղծվում են հին կաղապարի միջոցով, որը հաշվի չի առնում կայքերի անցումը https-ի։    

2. Թխուկներ առանց «HTTPOnly» և «անվտանգ» դրոշների:

   «HTTPOnly» հատկանիշը պաշտպանում է քուքիները մշակվելուց սկրիպտներով, որոնք հարձակվողներն օգտագործում են օգտատերերի տվյալները գողանալու համար: «Ապահով» դրոշը թույլ չի տալիս քուքիները հստակ տեքստով ուղարկել: Հաղորդակցությունը կթույլատրվի միայն այն դեպքում, եթե ապահով HTTPS արձանագրությունն օգտագործվի թխուկներ ուղարկելու համար: 

   Երկու ատրիբուտներն էլ նշված են թխուկների հատկություններում.

   Set-Cookie: Secure; HttpOnly

   Ինչու է դա վտանգավոր:Եթե ​​կայքի մշակողը չի նշել այս հատկանիշները, հարձակվողը կարող է գաղտնալսել օգտատիրոջ տեղեկատվությունը քուքիից և օգտագործել այն: Եթե ​​թխուկներն օգտագործվում են նույնականացման և թույլտվության համար, նա կկարողանա առևանգել օգտատիրոջ նիստը և իր անունից գործողություններ կատարել կայքում: 

   Ինչ պետք է հիշի վեբ մշակողըՈրպես կանոն, հանրաճանաչ շրջանակներում այս հատկանիշները սահմանվում են ավտոմատ կերպով: Բայց այնուամենայնիվ ստուգեք վեբ սերվերի կոնֆիգուրացիան և դրեք դրոշը. Set-Cookie HttpOnly; Ապահով.

   Այս դեպքում «HTTPOnly» հատկանիշը քուքիներն անտեսանելի կդարձնի ձեր սեփական JavaScript-ի համար:  

3. Ուղու վրա հիմնված խոցելիություններ.

   Սկաները հայտնում է նման խոցելիության մասին, եթե գտնում է հանրությանը հասանելի ֆայլ կամ վեբկայքի գրացուցակ՝ պոտենցիալ գաղտնի տեղեկություններով: Օրինակ, այն հայտնաբերում է առանձին համակարգի կազմաձևման ֆայլեր կամ մուտք դեպի ամբողջ ֆայլային համակարգ: Այս իրավիճակը հնարավոր է, եթե կայքում մուտքի իրավունքները սխալ են սահմանված:

   Ինչու է դա վտանգավոր:Եթե ​​ֆայլային համակարգը «կպչում է», հարձակվողը կարող է ընկնել օպերացիոն համակարգի ինտերֆեյսի մեջ և փորձել գտնել գաղտնաբառերով թղթապանակներ, եթե դրանք պահվում են հստակ տեքստով (մի արեք դա): Կամ դուք կարող եք գողանալ գաղտնաբառի հեշերը և կոպիտ ուժով գաղտնաբառ, ինչպես նաև փորձել բարձրացնել արտոնությունները համակարգում և ավելի խորանալ ենթակառուցվածքի մեջ:  

   Ինչ պետք է հիշի վեբ մշակողըՄի մոռացեք մուտքի իրավունքի մասին և կարգավորեք հարթակը, վեբ սերվերը, վեբ հավելվածը, որպեսզի անհնար լինի «փախչել» վեբ գրացուցակից:

4. Ինքնալրացումով միացված զգայուն տվյալներ մուտքագրելու ձևեր:

   Եթե ​​օգտատերը հաճախ է լրացնում ձևաթղթերը վեբկայքերում, նրա զննարկիչը պահում է այս տեղեկատվությունը՝ օգտագործելով ավտոմատ լրացման գործառույթը: 

   Կայքերի ձևաթղթերը կարող են ներառել գաղտնի տեղեկություններով դաշտեր, ինչպիսիք են գաղտնաբառերը կամ վարկային քարտերի համարները: Նման դաշտերի համար արժե անջատել ձևի ավտոմատ լրացման գործառույթը հենց կայքում։ 

   Ինչու է դա վտանգավոր:Եթե ​​օգտատիրոջ զննարկիչը պահպանում է զգայուն տեղեկատվությունը, հարձակվողը կարող է այն ավելի ուշ որսալ, օրինակ՝ ֆիշինգի միջոցով: Ըստ էության, վեբ ծրագրավորողը, ով մոռացել է այս նրբերանգի մասին, կարգավորում է իր օգտվողներին: 

   Ինչ պետք է հիշի վեբ մշակողըԱյս դեպքում մենք դասական կոնֆլիկտ ունենք՝ հարմարավետություն ընդդեմ անվտանգության: Եթե ​​վեբ ծրագրավորողը մտածում է օգտագործողի փորձի մասին, նա կարող է գիտակցաբար ընտրել ավտոմատ լրացումը: Օրինակ, եթե կարևոր է հետևել Վեբ բովանդակության մատչելիության ուղեցույցներ – Հաշմանդամություն ունեցող օգտատերերի համար բովանդակության մատչելիության վերաբերյալ առաջարկություններ: 

   Բրաուզերների մեծամասնության համար կարող եք անջատել ավտոմատ լրացումը autocompete="off" հատկանիշով, օրինակ.

    <body>
       <form action="/hy/form/submit" method="get" autocomplete="off">
         <div>
           <input type="text" placeholder="First Name">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Credit card number">
         </div>
         <input type="submit">
       </form>
     </body>

   Բայց Chrome-ի համար դա չի աշխատի: Սա շրջանցվում է JavaScript-ի միջոցով, կարելի է գտնել բաղադրատոմսի տարբերակ այստեղ. 

5. X-Frame-Options վերնագիրը տեղադրված չէ կայքի կոդում: 

   Այս վերնագիրը ազդում է շրջանակի, iframe-ի, ներդրման կամ օբյեկտի պիտակների վրա: Նրա օգնությամբ դուք կարող եք ամբողջությամբ արգելել ձեր կայքի տեղադրումը շրջանակի մեջ: Դա անելու համար անհրաժեշտ է նշել X-Frame-Options արժեքը՝ հերքել: Կամ կարող եք նշել X-Frame-Options. sameorigin, ապա iframe-ում ներկառուցումը հասանելի կլինի միայն ձեր տիրույթում:

   Ինչու է դա վտանգավոր:Նման վերնագրի բացակայությունը կարող է օգտագործվել վնասակար կայքերում clickjacking. Այս հարձակման համար հարձակվողը կոճակների վերևում ստեղծում է թափանցիկ շրջանակ և խաբում օգտագործողին: Օրինակ՝ խաբեբաները սոցիալական ցանցերի էջերը շրջանակում են վեբկայքում: Օգտագործողը կարծում է, որ սեղմում է այս կայքի կոճակը: Փոխարենը կտտոցը գաղտնալսվում է, և օգտատիրոջ հարցումն ուղարկվում է սոցիալական ցանց, որտեղ ակտիվ նիստ կա։ Ահա թե ինչպես են հարձակվողները ուղարկում սպամ օգտատիրոջ անունից կամ ստանում բաժանորդներ և հավանումներ: 

   Եթե ​​դուք չեք անջատում այս հնարավորությունը, հարձակվողը կարող է տեղադրել ձեր հավելվածի կոճակը վնասակար կայքում: Նրան կարող է հետաքրքրել ձեր ուղղորդման ծրագիրը կամ ձեր օգտատերերը:  

   Ինչ պետք է հիշի վեբ մշակողըԽոցելիությունը կարող է առաջանալ, եթե հակասական արժեք ունեցող X-Frame-Options-ը տեղադրված է վեբ սերվերի կամ բեռների հավասարակշռման վրա: Այս դեպքում սերվերը և հաշվեկշիռը պարզապես կվերագրեն վերնագիրը, քանի որ դրանք ավելի բարձր առաջնահերթություն ունեն՝ համեմատած հետնամասի կոդի հետ։  

   X-Frame-Options վերնագրի հերքման և նույն ծագման արժեքները կխանգարեն Yandex վեբ դիտողի աշխատանքին: Վեբ դիտողի համար iframe-ների օգտագործումը թույլատրելու համար հարկավոր է կարգավորումներում գրել առանձին կանոն։ Օրինակ, nginx-ի համար կարող եք այն կարգավորել այսպես.

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. PRSSI (Path-relative stylesheet import) խոցելիություններ:  

   Սա խոցելիություն է կայքի ոճավորման մեջ: Դա տեղի է ունենում, եթե հարաբերական հղումներ, ինչպիսիք են href="/hy/somefolder/styles.css/" օգտագործվում են ոճային ֆայլեր մուտք գործելու համար: Հարձակվողը կօգտվի դրանից, եթե գտնի օգտագործողին վնասակար էջ վերահղելու միջոց: Էջը կտեղադրի հարաբերական հղում իր url-ում և կսիմուլյատորի ոճերի զանգը: Դուք կստանաք այնպիսի հարցում, ինչպիսին է badsite.ru/…/somefolder/styles.css/-ը, որը կարող է չարամիտ գործողություններ կատարել ոճի քողի տակ: 

   Ինչու է դա վտանգավոր:Խարդախը կարող է օգտագործել այս խոցելիությունը, եթե գտնի անվտանգության այլ անցք: Արդյունքում հնարավոր է գողանալ օգտատերերի տվյալները թխուկներից կամ նշաններից:

   Ինչ պետք է հիշի վեբ մշակողըՍահմանեք X-Content-Type-Options վերնագիրը՝ nosniff: Այս դեպքում զննարկիչը կստուգի բովանդակության տեսակը ոճերի համար: Եթե ​​տեսակն այլ է, քան տեքստը/css-ը, զննարկիչը կարգելափակի հարցումը:

Կրիտիկական խոցելիություններ

1. Գաղտնաբառի դաշտով էջը սերվերից փոխանցվում է անապահով ալիքով (գաղտնաբառի դաշտ(ներ) պարունակող HTML ձևը մատուցվում է HTTP-ով):

   Սերվերի պատասխանը չգաղտնագրված ալիքի վրա խոցելի է «Մարդը մեջտեղում» հարձակումների համար: Հարձակվողը կարող է ընդհատել երթևեկությունը և խրվել հաճախորդի և սերվերի միջև, երբ էջը սերվերից գնում է հաճախորդ: 

   Ինչու է դա վտանգավոր:Խարդախը կկարողանա փոխարինել էջը և օգտվողին ուղարկել գաղտնի տվյալների ձև, որը կգնա հարձակվողի սերվեր: 

   Ինչ պետք է հիշի վեբ մշակողըՈրոշ կայքեր գաղտնաբառի փոխարեն օգտվողներին ուղարկում են մեկանգամյա կոդ էլեկտրոնային փոստով/հեռախոսով: Այս դեպքում խոցելիությունն այնքան էլ կրիտիկական չէ, սակայն մեխանիզմը կբարդացնի օգտատերերի կյանքը։

2. Մուտքագրման և գաղտնաբառով ձևի ուղարկում անապահով ալիքով (Մուտքի ձևը չի ներկայացվում HTTPS-ի միջոցով):

   Այս դեպքում մուտքի և գաղտնաբառով ձևաթուղթ օգտագործողից ուղարկվում է սերվեր չգաղտնագրված ալիքի միջոցով:

   Ինչու է դա վտանգավոր:Ի տարբերություն նախորդ դեպքի, սա արդեն կրիտիկական խոցելիություն է: Ավելի հեշտ է գաղտնալսել զգայուն տվյալները, քանի որ դա անելու համար նույնիսկ կոդ գրելու կարիք չկա: 

3. Հայտնի խոցելիություններով JavaScript գրադարանների օգտագործում:

   Սկանավորման ընթացքում ամենաշատ օգտագործվող գրադարանը jQuery-ն էր՝ լայնածավալ տարբերակներով: Յուրաքանչյուր տարբերակ ունի առնվազն մեկ, կամ նույնիսկ ավելի, հայտնի խոցելիություն: Ազդեցությունը կարող է շատ տարբեր լինել՝ կախված խոցելիության բնույթից:

   Ինչու է դա վտանգավոր:Կան շահագործումներ հայտնի խոցելիության համար, օրինակ՝

   
   
   Ինչ պետք է հիշի վեբ մշակողըՊարբերաբար վերադարձեք ցիկլին. որոնել հայտնի խոցելիությունները - ուղղել - ստուգել: Եթե ​​դուք դիտավորյալ օգտագործում եք հին գրադարանները, օրինակ՝ հին բրաուզերներին աջակցելու կամ գումար խնայելու համար, հնարավորություն փնտրեք՝ շտկելու հայտնի խոցելիությունը: 

4. Cross-site scripting (XSS): 
   Cross-Site Scripting (XSS) կամ միջկայքի սկրիպտավորումը հարձակում է վեբ հավելվածի վրա, որը հանգեցնում է չարամիտ ծրագրերի ներդրմանը տվյալների բազա: Եթե ​​Qualys-ը գտնում է նման խոցելիություն, դա նշանակում է, որ պոտենցիալ հարձակվողը կարող է կամ արդեն ներկայացրել է իր սեփական js սցենարը կայքի կոդի մեջ՝ վնասակար գործողություններ կատարելու համար։

   Պահպանված XSS ավելի վտանգավոր, քանի որ սկրիպտը տեղադրվում է սերվերի վրա և կատարվում է ամեն անգամ, երբ հարձակման ենթարկված էջը բացվում է բրաուզերում:

   Արտացոլված XSS ավելի հեշտ է իրականացնել, քանի որ վնասակար սկրիպտը կարող է ներարկվել HTTP հարցում: Հավելվածը կստանա HTTP հարցում, չի վավերացնի տվյալները, կփաթեթավորի և անմիջապես կուղարկի: Եթե ​​հարձակվողը ընդհատում է երթևեկը և տեղադրում նման սցենար

   <script>/*+что+то+плохое+*/</script> 

   ապա հաճախորդի անունից կուղարկվի վնասակար հարցում:

   XSS-ի վառ օրինակ. js sniffers, որոնք մոդելավորում են CVC մուտքագրման էջերը, քարտի ժամկետի ավարտը և այլն: 

   Ինչ պետք է հիշի վեբ մշակողըContent-Security-Policy վերնագրում օգտագործեք script-src հատկանիշը՝ հաճախորդի դիտարկիչին ստիպելու համար ներբեռնել և գործարկել կոդը միայն վստահելի աղբյուրից: Օրինակ, script-src 'self'-ը սպիտակ ցուցակում է միայն մեր կայքի բոլոր սցենարները: 
   Լավագույն պրակտիկան Inline կոդը է. թույլատրել միայն inline javascript-ը՝ օգտագործելով unsafe-inline արժեքը: Այս արժեքը թույլ է տալիս օգտագործել inline js/css, սակայն չի արգելում ներառել js ֆայլերը: script-src «self»-ի հետ համատեղ մենք անջատում ենք արտաքին սկրիպտների կատարումը:

   Համոզվեք, որ գրանցել եք ամեն ինչ՝ օգտագործելով report-uri-ն և նայեք այն կայքում ներդրման փորձերին:

5. SQL ներարկումներ.
   Խոցելիությունը ցույց է տալիս SQL կոդը ներարկելու հնարավորությունը կայք, որն ուղղակիորեն մուտք է գործում կայքի տվյալների բազա: SQL ներարկումը հնարավոր է, եթե օգտագործողի տվյալները չեն ստուգվում. այն չի ստուգվում ճշտության համար և անմիջապես օգտագործվում է հարցումում: Օրինակ, դա տեղի է ունենում, եթե վեբկայքի ձևը չի ստուգում, թե արդյոք մուտքագրումը համապատասխանում է տվյալների տեսակին: 

   Ինչու է դա վտանգավոր:Եթե ​​հարձակվողը մուտքագրում է SQL հարցում այս ձևի մեջ, նա կարող է խափանել տվյալների բազան կամ բացահայտել գաղտնի տեղեկատվություն: 

   Ինչ պետք է հիշի վեբ մշակողըՄի վստահեք այն, ինչ գալիս է դիտարկիչից: Դուք պետք է պաշտպանվեք ինչպես հաճախորդի, այնպես էլ սերվերի կողմից: 

   Հաճախորդի կողմից գրեք դաշտի վավերացում JavaScript-ի միջոցով: 

   Ներկառուցված գործառույթները հանրաճանաչ շրջանակներում նույնպես օգնում են խուսափել սերվերի կասկածելի նիշերից: Առաջարկվում է նաև օգտագործել պարամետրացված տվյալների բազայի հարցումներ սերվերի վրա:

   Որոշեք, թե կոնկրետ որտեղ է տեղի ունենում տվյալների բազայի հետ փոխազդեցությունը վեբ հավելվածում: 

   Փոխազդեցությունը տեղի է ունենում, երբ մենք ստանում ենք որևէ տեղեկատվություն՝ id-ով հարցում (id-ի փոփոխություն), նոր օգտվողի ստեղծում, նոր մեկնաբանություն կամ տվյալների բազայում նոր գրառումներ: Այստեղ կարող են տեղի ունենալ SQL ներարկումներ: Նույնիսկ եթե տվյալների բազայից ռեկորդ ջնջենք, SQL ներարկումը հնարավոր է։

Ընդհանուր առաջարկներ

Մի հայտնագործեք անիվը. օգտագործեք ապացուցված շրջանակներ. Որպես կանոն, հայտնի շրջանակներն ավելի ապահով են։ .NET-ի համար՝ ASP.NET MVC և ASP.NET Core, Python-ի համար՝ Django կամ Flask, Ruby-ի համար՝ Ruby on Rails, PHP-ի համար՝ Symfony, Laravel, Yii, JavaScript-ի համար՝ Node.JS-Express.js, Java-ի համար: - Գարուն MVC:

Հետևեք վաճառողի թարմացումներին և պարբերաբար թարմացրեք. Նրանք կգտնեն խոցելիություն, հետո կգրեն շահագործում, հասանելի կդարձնեն այն հանրությանը, և ամեն ինչ նորից կկրկնվի: Բաժանորդագրվեք ծրագրային ապահովման վաճառողի կայուն տարբերակների թարմացումներին:

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

Օգտագործեք կլոններ, փորձարկման վայրեր, այնուհետև օգտագործեք դրանք արտադրության համար. Սա կօգնի առաջին հերթին խուսափել սխալներից և սխալներից արդյունավետ միջավայրում. արդյունավետ միջավայրը փող է բերում, պարզ արտադրողական միջավայրը կարևոր է: Ցանկացած խնդիր ավելացնելիս, ուղղելիս կամ փակելիս արժե աշխատել թեստային միջավայրում, հետո ստուգել հայտնաբերված ֆունկցիոնալությունն ու խոցելիությունը, ապա պլանավորել աշխատել արտադրական միջավայրի հետ։ 

Պաշտպանեք ձեր վեբ հավելվածը Վեբ կիրառական firewall և դրա հետ ինտեգրել խոցելիության սկաների հաշվետվությունները. Օրինակ, DataLine-ն օգտագործում է Qualys-ը և FortiWeb-ը որպես ծառայությունների փաթեթ:

Source: www.habr.com