Բովանդակություն
- 1. softwareրագրակազմը թարմ պահեք
- 2. SQL ներարկում
- 3. XSS
- 4. Սխալ հաղորդագրություններ
- 5. Սերվերի կողմից վավերացում / ձևի վավերացում
- 6. Գաղտնաբառեր
- 7. Ֆայլերի վերբեռնումներ
- 8. Սերվերի անվտանգություն
- 9. ՍՍԼ
- 10. Անվտանգության գործիքներ
Կարող եք չմտածել, որ ձեր կայքում կա ինչ-որ բան, որի համար արժի կոտրել, բայց կայքերը անընդհատ վտանգված են: Անվտանգության խախտումների մեծամասնությունը ոչ թե ձեր տվյալները գողանալու կամ ձեր կայքը խեղաթյուրելու համար է, այլ փոխարենը փորձում է օգտագործել ձեր սերվերը որպես էլփոստի փոխանցում սպամի համար, կամ կարգավորել ժամանակավոր վեբ սերվեր, որը սովորաբար ծառայում է անօրինական բնույթի ֆայլեր:
- Լավագույն հակավիրուսային ծրագրակազմ
Հակերացումը պարբերաբար իրականացվում է ավտոմատ սցենարների միջոցով, որոնք գրված են ինտերնետը աղտոտելու համար ՝ փորձելով ծրագրային ապահովման մեջ օգտագործել անվտանգության հայտնի խնդիրները: Ահա մեր լավագույն 10 խորհուրդները, որոնք կօգնեն ձեզ և ձեր կայքը առցանց անվտանգ պահել:
1. softwareրագրակազմը թարմ պահեք
Դա կարող է թվալ ակնհայտ, բայց ձեր կայքի անվտանգությունը պահպանելու համար կարևոր է ապահովել ամբողջ ծրագրակազմի թարմացումը: Սա վերաբերում է ինչպես սերվերի օպերացիոն համակարգին, այնպես էլ ցանկացած ծրագրակազմի, որը կարող եք գործարկել ձեր կայքում, ինչպիսիք են CMS- ը կամ ֆորումը: Երբ ծրագրային ապահովման մեջ հայտնաբերվում են անվտանգության անցքեր, հակերները շտապում են փորձել չարաշահել դրանք:
Եթե օգտագործում եք կառավարվող հոսթինգի լուծում, ապա ձեզ հարկավոր չէ այդքան շատ անհանգստանալ օպերացիոն համակարգի անվտանգության թարմացումները կիրառելու մասին, քանի որ հոստինգի ընկերությունը պետք է հոգ տանի դրա մասին:
Եթե ձեր կայքում օգտագործում եք երրորդ կողմի ծրագրակազմ, ինչպիսին է CMS- ը կամ ֆորումը, ապա պետք է համոզվեք, որ արագորեն կիրառում եք անվտանգության ցանկացած ուղղումներ: Վաճառողների մեծամասնությունն ունի փոստային ցուցակ կամ RSS հոսք, որը մանրամասն նկարագրում է անվտանգության հետ կապված որևէ խնդիր: WordPress- ը, Umbraco- ն և շատ այլ CMSes մուտք են գործում ձեզ համակարգային թարմացումների մասին:
2. SQL ներարկում
SQL ներարկման գրոհներն այն դեպքերն են, երբ հարձակվողը օգտագործում է վեբ ձևի դաշտ կամ URL պարամետր ՝ ձեր տվյալների շտեմարան մուտք գործելու կամ շահարկելու համար: Երբ օգտագործում եք ստանդարտ Transact SQL, հեշտ է ձեր հարցման մեջ անգիտակցաբար ներդնել սրիկա ծածկագիր, որը կարող է օգտագործվել աղյուսակները փոխելու, տեղեկատվություն ստանալու և տվյալները ջնջելու համար: Դուք կարող եք հեշտությամբ կանխել դա ՝ միշտ օգտագործելով պարամետրավորված հարցումներ, վեբ լեզուների մեծամասնությունն ունի այս հատկությունը և այն հեշտ է իրականացնել:
Հաշվի առեք այս հարցումը.
"ԸՆՏՐԵՔ * Աղյուսակից ՈՒՐ սյունակ = '" + պարամետր + "';"
Եթե հարձակվողը փոխել է URL- ի պարամետրը 'կամ' 1 '=' 1 փոխանցելու համար, դա կհանգեցնի հարցման այսպիսի տեսքի.
«ԸՆՏՐԵՔ * ԱՐԴՅՈՒՆՔԻ աղյուսակից, որտեղ սյունակ = '' ԿԱՄ '1' = '1';"
Քանի որ ‘1-ը հավասար է‘ 1-ի, սա հարձակվողին թույլ կտա SQL հայտարարության վերջում ավելացնել լրացուցիչ հարցում, որը նույնպես կկատարվի:
3. XSS
Cross site scripting- ը այն է, երբ հարձակվողը փորձում է JavaScript կամ այլ սցենարային ծածկագիր փոխանցել վեբ ձևի մեջ ՝ փորձելով վնասակար ծածկագիր գործարկել ձեր կայքի այցելուների համար: Ձև ստեղծելիս միշտ համոզվեք, որ ստուգում եք ներկայացվող տվյալները և կոդավորեք կամ հանեք որևէ HTML:
4. Սխալ հաղորդագրություններ
Errorգուշացեք ձեր սխալ հաղորդագրություններում որքան տեղեկատվություն եք տալիս: Օրինակ, եթե ձեր կայքում մուտքի ձև ունեք, մուտքերը փորձելիս պետք է մտածեք այն լեզվի մասին, որն օգտագործում եք հաղորդակցման ձախողման համար: Դուք պետք է օգտագործեք ընդհանուր հաղորդագրություններ, ինչպիսիք են ՝ «Սխալ օգտվողի անուն կամ գաղտնաբառ», որպեսզի չհամընկնեն, թե երբ օգտվողը ստացել է հարցման կեսի իրավունքը: Եթե հարձակվողը փորձում է կոպտորեն հարձակվել ՝ օգտանուն և գաղտնաբառ ստանալու համար, և սխալի հաղորդագրությունը տալիս է, երբ դաշտերից մեկը ճիշտ է, հարձակվողը գիտի, որ դաշտերից մեկը ունի և կարող է կենտրոնանալ մյուս դաշտում:
5. Սերվերի կողմից վավերացում / ձևի վավերացում
Վավերացումը միշտ պետք է կատարվի ինչպես զննարկչի, այնպես էլ սերվերի կողմից:Theննարկիչը կարող է հայտնաբերել պարզ ձախողումներ, ինչպիսիք են պարտադիր դաշտերը, որոնք դատարկ են, և երբ տեքստ եք մուտքագրում միայն թվերի դաշտ: Դրանք, այնուամենայնիվ, կարող են շրջանցվել, և դուք պետք է համոզվեք, որ ստուգում եք այս վավերացման և ավելի խորը վավերացման սերվերի կողմը, քանի որ դա չկատարելը կարող է հանգեցնել տվյալների բազայում չարամիտ կոդի կամ սցենարական կոդի տեղադրման կամ կարող է անցանկալի արդյունքների հանգեցնել ձեր կայքում:
6. Գաղտնաբառեր
Բոլորն էլ գիտեն, որ նրանք պետք է օգտագործեն բարդ գաղտնաբառեր, բայց դա չի նշանակում, որ նրանք միշտ օգտագործում են: Կարևոր է օգտագործել ուժեղ գաղտնաբառերը ձեր սերվերի և կայքի ադմինիստրատորի տարածքում, բայց նաև կարևոր է պնդել գաղտնաբառերի լավ գործելակերպի վրա, որպեսզի օգտագործողները պաշտպանեն իրենց հաշիվների անվտանգությունը:
Ինչքան էլ դա դուր չգա օգտվողներին, գաղտնաբառի պահանջների կիրառում, ինչպիսիք են առնվազն ութ նիշ, ներառյալ մեծատառ և թիվ, կօգնեն պաշտպանել նրանց տեղեկատվությունը երկարաժամկետ հեռանկարում:
Գաղտնաբառերը միշտ պետք է պահվեն որպես ծածկագրված արժեքներ, նախընտրելի է օգտագործել մեկ եղանակով խաշման ալգորիթմ, ինչպիսին է SHA- ն: Այս մեթոդի օգտագործումը նշանակում է, որ երբ վավերացնում եք օգտվողներին, դուք միայն երբևէ համեմատում եք կոդավորված արժեքները: Լրացուցիչ անվտանգության համար լավ գաղափար է ծածկագրել գաղտնաբառերը ՝ օգտագործելով յուրաքանչյուր գաղտնաբառի համար նոր աղ:
Ինչ-որ մեկի կողմից ձեր գաղտնաբառերը կոտրելու և գողանալու դեպքում կոդավորված գաղտնաբառերի օգտագործումը կարող է օգնել վնասի սահմանափակումին, քանի որ դրանց վերծանումը անհնար է: Լավագույնը, ինչ որ մեկը կարող է անել, բառարանային գրոհն է կամ կոպիտ ուժի հարձակումը ՝ ըստ էության գուշակելով յուրաքանչյուր համադրություն, մինչև որ այն համապատասխան գտնի: Աղի գաղտնաբառեր օգտագործելիս մեծ թվով գաղտնաբառեր կոտրելու գործընթացը նույնիսկ ավելի դանդաղ է ընթանում, քանի որ յուրաքանչյուր գուշակություն պետք է առանձին ուղարկվի յուրաքանչյուր աղ + գաղտնաբառի համար, որը հաշվարկով շատ թանկ է:
Բարեբախտաբար, շատ CMS- ներ ապահովում են օգտագործողի կառավարումը տուփից դուրս ՝ ներկառուցված այս անվտանգության շատ առանձնահատկություններով, չնայած որոշ կազմաձևման կամ լրացուցիչ մոդուլների կարող է պահանջվել աղած գաղտնաբառեր օգտագործելու համար (նախքան Drupal 7) կամ գաղտնաբառի նվազագույն ուժը սահմանելու համար: Եթե օգտագործում եք .NET, ապա արժե օգտագործել անդամության պրովայդերները, քանի որ դրանք շատ կազմաձևելի են, ապահովում են ներկառուցված անվտանգություն և ներառում են մուտքի և գաղտնաբառի վերակայման համար պատրաստի հսկողություն:
7. Ֆայլերի վերբեռնումներ
Թույլատրել օգտվողներին ֆայլեր վերբեռնել ձեր վեբ կայք, կարող է լինել անվտանգության մեծ ռիսկ, նույնիսկ եթե դա պարզապես նրանց ավատարը փոխելու համար է: Ռիսկն այն է, որ ցանկացած վերբեռնված ֆայլ, որքան էլ որ անմեղ լինի, կարող է պարունակել մի սցենար, որը գործարկվելիս ձեր սերվերի վրա ամբողջությամբ բացում է ձեր կայքը:
Եթե ունեք ֆայլ վերբեռնելու ձև, ապա ձեզ հարկավոր է մեծ կասկածանքով վերաբերվել բոլոր ֆայլերին: Եթե օգտվողներին թույլ եք տալիս պատկերներ վերբեռնել, չեք կարող ապավինել ֆայլի ընդլայնմանը կամ mime տիպին ՝ հաստատելու համար, որ ֆայլը պատկեր է, քանի որ դրանք հեշտությամբ կեղծվում են: Նույնիսկ ֆայլը բացելը և վերնագիրը կարդալը կամ պատկերի չափը ստուգելու համար գործառույթներ օգտագործելը լիովին ապացույց չեն: Պատկերների ձևաչափերի մեծ մասը թույլ է տալիս պահպանել մեկնաբանության բաժինը, որը կարող է պարունակել PHP կոդ, որը կարող է կատարվել սերվերի կողմից:
Այսպիսով, ի՞նչ կարող ես անել դա կանխելու համար: Ի վերջո, դուք ուզում եք դադարեցնել օգտվողներին ի վիճակի լինել կատարելու իրենց վերբեռնած ցանկացած ֆայլ: Լռելյայն, վեբ սերվերները չեն փորձի կատարել ֆայլեր պատկերի ընդլայնումներով, սակայն խորհուրդ չի տրվում ապավինել միայն ֆայլի ընդլայնումը ստուգելուն, քանի որ հայտնի է, որ այդ ֆայլը ընդլայնվում է: image.webp.php:
Որոշ տարբերակներ `վերբեռնման վրա ֆայլը վերանվանելը` ֆայլի ճիշտ ընդլայնումն ապահովելու համար կամ ֆայլի թույլտվությունները փոխելու համար, օրինակ `chmod 0666, այնպես որ այն հնարավոր չէ կատարել: * Nix- ի օգտագործման դեպքում դուք կարող եք ստեղծել .htaccess ֆայլ (տե՛ս ստորև), որը թույլ կտա մուտք գործել միայն այն ֆայլերը, որոնք կանխում են նախկինում նշված կրկնակի ընդլայնման հարձակումը:
հերքել բոլոր Ֆայլերից "^ w + . (gif | jpe? g | png) $"> կարգը հերքել, թույլատրել բոլորից / Ֆայլեր>
Ի վերջո, առաջարկվող լուծումն է `կանխել բեռնված ֆայլերի անմիջական մուտքը միասին: Այսպիսով, ձեր կայքում վերբեռնված ցանկացած ֆայլ պահվում է վեբ արմատից դուրս գտնվող թղթապանակում կամ տվյալների շտեմարանում որպես բլոբ: Եթե ձեր ֆայլերն ուղղակիորեն հասանելի չեն, ապա ձեզ հարկավոր է ստեղծել սկրիպտ ՝ ֆայլերը մասնավոր թղթապանակից (կամ HTTP կարգավորիչից .NET- ում) բերելու և դրանք զննարկչին հասցնելու համար: Պատկերի պիտակներն աջակցում են src հատկանիշին, որը պատկերի ուղղակի URL չէ, այնպես որ ձեր src հատկանիշը կարող է մատնանշել ձեր ֆայլերի առաքման սցենարը ՝ ապահովելով որ դուք տեղադրեք ճիշտ բովանդակության տեսակ HTTP վերնագրում: Օրինակ:
img src = "/ imageDelivery.php? id = 1234" />? php // imageDelivery.php // Ստացեք տվյալների ֆայլի անունը տվյալների բազայից $ _GET ["id"] - ի հիման վրա ... // Պատկերն առաքեք զննարկչի վերնագիր ( Բովանդակության տեսակը. Պատկեր / gif '); readfile (’images /’.$ fileName); ?> var13 ->
8. Սերվերի անվտանգություն
Հոսթինգ մատակարարներից շատերը զբաղվում են ձեզ համար սերվերի կազմաձևով, բայց եթե ձեր վեբ կայքը հյուրընկալում եք ձեր սեփական սերվերի վրա, ապա քիչ բաներ կան, որոնք կցանկանաք ստուգել:
Համոզվեք, որ ունեք firewall- ի կարգավորում և արգելափակում եք բոլոր ոչ էական նավահանգիստները: Հնարավորության դեպքում ստեղծել DMZ (ապառազմականացված գոտի), որը թույլ է տալիս մուտք գործել միայն արտաքին և աշխարհի 80 և 443 նավահանգիստները: Չնայած դա հնարավոր է, որ հնարավոր չլինի, եթե ձեր սերվերին ներքին ցանցից մուտք չունեք, քանի որ պետք է նավահանգիստներ բացեք ՝ ֆայլեր վերբեռնելու թույլտվություն տալու և SSH- ի կամ RDP- ի միջոցով ձեր սերվերից հեռակա մուտք գործելու համար:
Եթե դուք թույլ եք տալիս ֆայլեր վերբեռնվել ինտերնետից, օգտագործեք միայն անվտանգ տրանսպորտային մեթոդներ ձեր սերվեր, ինչպիսիք են SFTP կամ SSH:
Հնարավորության դեպքում ձեր տվյալների բազան աշխատի ձեր վեբ սերվերի տարբեր այլ սերվերի վրա: Դա անելը նշանակում է, որ տվյալների շտեմարանի սերվերին անհնար է մուտք գործել անմիջապես արտաքին աշխարհից, միայն ձեր վեբ սերվերն է կարող մուտք գործել դրան ՝ նվազագույնի հասցնելով ձեր տվյալների բացահայտման ռիսկը:
Վերջապես, մի մոռացեք ձեր սերվեր ֆիզիկական մուտքի սահմանափակման մասին:
9. ՍՍԼ
SSL- ը պրոտոկոլ է, որն օգտագործվում է ինտերնետի միջոցով անվտանգություն ապահովելու համար: Լավ կլինի օգտագործել անվտանգության վկայագիր, երբ դուք անձնական տեղեկություններ եք փոխանցում կայքի և վեբ սերվերի կամ տվյալների բազայի միջև: Հարձակվողները կարող են փնթփնթալ այս տեղեկատվության համար, և եթե կապի միջոցը անվտանգ չէ, կարող են այն գրավել և օգտագործել այս տեղեկատվությունը օգտագործողների հաշիվներին և անձնական տվյալների հասանելիություն ստանալու համար:
10. Անվտանգության գործիքներ
Երբ մտածեք, որ ամեն ինչ արել եք ձեր կայքը ապահովելու համար, ապա ժամանակն է ստուգել ձեր անվտանգությունը: Դա անելու ամենաարդյունավետ միջոցը անվտանգության որոշ գործիքների օգտագործման միջոցով է, որոնք հաճախ անվանում են ներթափանցման փորձարկում կամ հակիրճ գրիչի փորձարկում:
Կան բազմաթիվ առևտրային և անվճար ապրանքներ, որոնք կօգնեն ձեզ այս հարցում: Նրանք աշխատում են սցենարների նման հիմքերի վրա, որոնք հակերները կօգտագործեն այն բանի համար, որ նրանք ստուգում են բոլոր գիտելիքների շահագործումները և փորձում են փոխզիջման ենթարկել ձեր կայքը ՝ օգտագործելով նախորդ նշված որոշ մեթոդներ, ինչպիսիք են SQL ներարկումը:
Որոշ անվճար գործիքներ, որոնք արժե դիտել.
- Netsparker (հասանելի է համայնքի անվճար հրատարակություն և փորձնական տարբերակ): Լավ է SQL ներարկման և XSS- ի փորձարկման համար
- OpenVAS- ը: Հայտարարում է լինել ամենաառաջատար բաց աղբյուրի անվտանգության սկաները: Հարմար է հայտնի խոցելի տեղերը ստուգելու համար, ներկայումս ստուգում է ավելի քան 25,000: Բայց կարգաբերումը կարող է դժվար լինել և պահանջում է, որ տեղադրվի OpenVAS սերվեր, որն աշխատում է միայն * nix- ով: OpenVAS- ը Nessus- ի պատառաքաղ է, նախքան այն դառնա փակ աղբյուրների առևտրային արտադրանք:
Ավտոմատացված փորձարկումներից ստացված արդյունքները կարող են հիասթափեցնող լինել, քանի որ դրանք ներկայացնում են հարուստ պոտենցիալ խնդիրներ: Կարևորը նախ կենտրոնանալ կարևորագույն հարցերի վրա: Սովորաբար զեկուցվող յուրաքանչյուր խնդիր լավ բացատրում է հնարավոր խոցելիությունը: Հավանաբար կտեսնեք, որ որոշ միջին / ցածր խնդիրներ ձեր կայքի համար մտահոգիչ չեն:
Եթե ցանկանում եք գործը մի քայլ առաջ տանել, ապա կան մի քանի հետագա քայլեր, որոնք դուք կարող եք ձեռնարկել ՝ ձեռքով փորձելու փոխզիջման ենթարկել ձեր կայքը ՝ փոխելով POST / GET արժեքները: Վրիպազերծման վստահված անձը կարող է ձեզ օգնել այստեղ, քանի որ այն թույլ է տալիս գաղտնալսել HTTP հարցման արժեքները ձեր զննարկչի և սերվերի միջև: Fiddler անունով հանրահայտ անվճար ծրագիր, որը լավ մեկնակետ է:
Այսպիսով, ի՞նչը պետք է փորձեիք փոխել հարցման վերաբերյալ: Եթե ունեք էջեր, որոնք պետք է տեսանելի լինեն միայն մուտքագրված օգտագործողի համար, ապա ես կփորձեմ փոխել URL- ի պարամետրերը, ինչպիսիք են օգտվողի ID- ն կամ cookie- ի արժեքները `փորձելով դիտել այլ օգտվողի տվյալները: Փորձարկման ենթակա մեկ այլ տարածք են ձևաթղթերը ՝ փոխելով POST արժեքները ՝ XSS կատարելու համար կոդ ներկայացնելու կամ սերվերի կողմի սցենար վերբեռնելու փորձ կատարելու համար:
Հուսով եմ, այս խորհուրդները կօգնեն ձեր կայքը և տեղեկատվությունն անվտանգ պահել: Բարեբախտաբար, CMS- ների մեծամասնությունը ներկառուցված անվտանգության շատ առանձնահատկություններ ունի, բայց դեռևս լավ գաղափար է ունենալ անվտանգության ամենատարածված շահագործումների մասին գիտելիքներ, որպեսզի կարողանաք ապահովել, որ ծածկված եք:
Կան նաև որոշ օգտակար մոդուլներ, որոնք մատչելի են CMSes- ի համար `ձեր տեղադրումը ստուգելու անվտանգության ընդհանուր թերությունների համար, ինչպիսիք են անվտանգության ստուգումը Drupal- ի և WP անվտանգության սկանավորումը WordPress- ի համար:
