HTTPS էջը, որը սկրիպտներ է բեռնում HTTP-ով, կատարում է երկու հարցում՝ պաշտպանության երկու տարբեր մակարդակով, և կողպեքը նկարագրում է միայն առաջինը։ Թունելը դա չի փոխում, քանի որ պաշտպանում է կրիչը, ոչ թե ռեսուրսի սեփական սխեման։ Դիտարկիչն արդեն ասում է, թե որ հարցումն է ձախողվել, եթե հասցեի տողի փոխարեն կարդաք կոնսոլը։ Երեք ստուգում ձեզ տանում են կիսով չափ աշխատող էջից դեպի իրական վերանորոգում։

Կարդացեք հարցումը, ոչ թե հասցեի տողը

HTTPS-ով ստացված փաստաթուղթը կարող է հղում անել սկրիպտի, ոճաթերթի, տառատեսակի կամ շրջանակի սովորական HTTP-ով։ Այդ հղումը առանձին հարցում է, և հենց դրա մասին է բողոքում դիտարկիչը։ Հիմնական փաստաթղթի պաշտպանությունը հետ չի տարածվում դրա վրա, և երկու հոսքերն էլ կրող թունելը չի փոխում ոչ մի սխեմա։ Ուստի էջը կարող է միաժամանակ լինել իսկապես անվտանգ և իսկապես կոտրված։

Ռեսուրսը պարզապես ներառված ֆայլ անվանելը չի դարձնում դրա փոխարինումը անվնաս։

Եթե անապահով սկրիպտի բովանդակությունը կարելի է փոխել ճանապարհին և ապա գործարկել, այն կարող է փոխել էջի վարքը, ինչը ավելի մեծ խնդիր է, քան կոսմետիկ խափանումը։ Պատկերները կրում են ավելի փոքր, բայց իրական ռիսկ, երբ փոփոխվում են ճանապարհին։ Կողպեքը ոչ մի բանի մասին չի ստում։ Այն պատասխանում է ավելի նեղ հարցի, քան այն, ինչ դուք տվել էիք նրան։

Իմացեք, թե որ ռեսուրսներն են արգելափակվում և որոնք՝ բարձրացվում

Դիտարկիչները բոլոր տեսակի ռեսուրսներին նույն կերպ չեն վերաբերվում։ խառը բովանդակության ուղեցույցը բաժանում է HTTPS-ի բարձրացվող հարցումները լրիվ արգելափակվող հարցումներից. սկրիպտները, ոճաթերթերը և ծրագրային հարցումները արգելափակված կողմում են, մինչդեռ պատկերներն ու մեդիան կարող են փոխարենը բարձրացվել կամ նշվել։

Այդ տարբերությունը բացատրում է շփոթեցնող հաշվետվությունները։ Արգելափակված սկրիպտով էջը լրիվ կորցնում է մի գործառույթ, մինչդեռ բարձրացված պատկերով էջը լավ տեսք ունի և լուռ փոխել է իր հարցումը։ Փաստաթղթավորված կատեգորիաներն ունեն նաև բացառություններ, ուստի մի ենթադրեք, որ տվյալ տիպի յուրաքանչյուր URL հաջողությամբ կբարձրացվի։ Կարդացեք, թե ինչ է ասում կոնսոլը կոնկրետ հարցման մասին, փոխարենը ֆայլի ընդլայնումից դատելու։

Արգելափակված վիջեթը ապացույց չէ, որ թունելը ձախողվել է։ Դա ապացույց է, որ դիտարկիչն արել է իր գործը։

Վերանորոգեք հղումն իր աղբյուրում

Կայքի տիրոջ համար վերանորոգումը տեղին է այնտեղ, որտեղ գրվել է անապահով URL-ը՝ ձևանմուշ, ոճաթերթ, URL-ներ հավաքող սկրիպտ կամ երրորդ կողմի բաղադրիչ։ Տեսանելի էջի հասցեն փոխելը թողնում է այդ ամենն անձեռնմխելի։ Փնտրեք աղբյուրում հոսթը և վերանորոգեք յուրաքանչյուր հղում, ոչ միայն այն մեկը, որը կոնսոլը պատահաբար նշել է։

Ապա հաստատեք, որ ռեսուրսն իսկապես մատուցվում է HTTPS-ով՝ վավեր ինքնությամբ, քանի որ սխեմայի փոխարկումը չի կարող ստեղծել ծառայություն, որը երբեք այնտեղ չի հրապարակվել։

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

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

Նորից ստուգեք էջն այնպես, ինչպես օգտատերերը դիպչում են դրան

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

Թունելը դեռ ունի իր աշխատանքը, և այդ աշխատանքը ցանցային հասանելիությունն է, ոչ թե էջի ամբողջականությունը։

Հենց երբ երթևեկությունը լքում է թունելի վերջնակետը, ոչ մի մնացած HTTP հարցում ոչինչ չի շահել կրիչից։ Վերանորոգեք ռեսուրսի ուղին և պահեք դիտարկիչի կիրարկումը տեղում։ Եվս մեկ տրանսպորտային շերտ անապահով կախվածության վերանորոգում համարելը այն ճանապարհն է, որով թիմը հայտնվում է աջակցության սեղանի սկրիպտի հետ, որն անջատում է ճիշտ աշխատող վերահսկողությունը։

Առնչվող հոդվածներ