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

Վիքիպեդիայից՝ ազատ հանրագիտարանից

SQL ներմուծում[խմբագրել | խմբագրել կոդը]

Classification of SQL injection attack vectors in 2010
SQL ներմուծման հարձակման վեկտորի դասակարգումը 2010 թ

SQL ներմուծումը Կոդի ներմուծման տեխնիկա է, որն օգտագործվում է տվյալների վրա հիմնված հավելվածների վրա հարձակվելու համար, որտեղ վնասակար SQL հայտարարությունները տեղադրվում են մուտքի դաշտում՝ կատարման համար (օրինակ՝ տվյալների բազայի բովանդակությունը հարձակվողին նետելու համար):[1] SQL ներմուծումը պետք է օգտագործի հավելվածի ծրագրային ապահովման անվտանգության խոցելիությունը, օրինակ, երբ օգտվողի մուտքագրումը կամ սխալ է զտված SQL հայտարարություններում ներկառուցված տողերի բառացի փախուստի նիշերի համար, կամ օգտագործողի մուտքագրումը խիստ մուտքագրված չէ և անսպասելիորեն կատարվում է: SQL հիմնականում հայտնի է որպես հարձակման վեկտոր կայքերի համար, բայց կարող է օգտագործվել ցանկացած տեսակի SQL տվյալների բազայի վրա հարձակվելու համար:

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

2012-ի ուսումնասիրության մեջ նկատվեց, որ միջին վեբ հավելվածը ամսական ստանում էր չորս հարձակման արշավ, իսկ մանրածախ առևտրականները երկու անգամ ավելի շատ հարձակումներ էին ստանում, քան մյուս ոլորտները:[2]

Պատմությունը[խմբագրել | խմբագրել կոդը]

SQL ներմուծման առաջին հանրային քննարկումները սկսեցին հայտնվել մոտ 1998 թ;[3]օրինակ՝ Phrack Magazine-ում 1998թ հոդվածը:[4]

Կազմությունը[խմբագրել | խմբագրել կոդը]

SQL ներմուծումը (SQLI) Open Web Application Security Project-ի[5] կողմից համարվում էր 2007 և 2010 թվականների վեբ հավելվածների լավագույն 10 խոցելիություններից մեկը: 2013 թվականին SQLI-ն գնահատվել է որպես թիվ մեկ հարձակում OWASP-ի[6] լավագույն տասնյակում: SQL ներմուծման չորս հիմնական ենթադաս կա․

  • Դասական SQLI
  • Կույր SQL ներարկում կամ եզրակացություն
  • Տվյալների բազայի կառավարման համակարգի հատուկ SQLI
  • Բաղադրյալ SQLI

The Storm Worm-ը Compounded SQLI-ի ներկայացումներից մեկն է:[11]

Այս դասակարգումը ներկայացնում է SQLI-ի վիճակը՝ հաշվի առնելով դրա էվոլյուցիան մինչև 2010 թվականը. հետագա կատարելագործումը շարունակվում է:[12]

Տեխնիկական իրականացումներ[խմբագրել | խմբագրել կոդը]

Սխալ կառուցված SQL հայտարարություններ[խմբագրել | խմբագրել կոդը]

Ներարկման այս ձևը հիմնված է այն փաստի վրա, որ SQL հայտարարությունները բաղկացած են ինչպես տվյալներից, որոնք օգտագործվում են SQL հայտարարության կողմից, այնպես էլ հրամաններից, որոնք վերահսկում են, թե ինչպես է SQL հայտարարությունը կատարվում: Օրինակ, SQL հայտարարության մեջ select * from person where name = 'susan' and age = 2 տողը'susan' տվյալներն են և հատվածըand age = 2հրամանի օրինակ է(իմաստը 2 այս օրինակում նույնպես տվյալներ են)։

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

Որպես պարզ օրինակ, պատկերացրեք, որ տվյալները 'susan'վերը նշված հայտարարության մեջ տրամադրվել է օգտվողի մուտքագրմամբ:Օգտագործողը մուտքագրել է տողը 'susan' (առանց ապոստրոֆների) վեբ ձևի տեքստի մուտքագրման դաշտում, և ծրագիրը օգտագործել է տողերի միացման հայտարարություններ՝ երեք բեկորներից վերը նշված SQL հայտարարությունը ձևավորելու համար․ select * from person where name=', օգտագործողի մուտքագրումը'susan',և ' and age = 2։

Հիմա պատկերացրեք, որ մուտքագրելու փոխարեն 'susan' հարձակվողը մուտքագրել է ' or 1=1; --.

Ծրագիրը կօգտագործի տողերի միացման նույն մոտեցումը 3 մասերի հետ select * from person where name=', օգտագործողի մուտքագրումը' or 1=1; --, և ' and age = 2և կառուցիր հայտարարությունը select * from person where name='' or 1=1; -- and age = 2. Շատ տվյալների բազաներ անտեսելու են տեքստը '--' տողից հետո, քանի որ դա նշանակում է մեկնաբանություն: SQL հրամանի կառուցվածքն այժմ select * from person where name='' or 1=1; է,և սա կընտրի բոլոր մարդկանց տողերը, այլ ոչ միայն նրանք, ովքեր կոչվում են «susan», որոնց տարիքը 2 է: Հարձակվողին հաջողվել է ստեղծել տվյալների տող, որը դուրս է գալիս տվյալների համատեքստից և մուտքագրում հրամանի համատեքստ:

Այժմ ներկայացված է ավելի բարդ օրինակ.

Պատկերացրեք, որ ծրագիրը ստեղծում է SQL հայտարարություն՝ օգտագործելով հետևյալ տողերի նշանակման հրամանը .

var statement = "SELECT * FROM users WHERE name = '" + userName + "'";

Այս SQL կոդը նախատեսված է օգտագործողների աղյուսակից նշված օգտվողի անվան գրառումները հանելու համար: Այնուամենայնիվ, եթե «userName» փոփոխականը մշակված է հատուկ ձևով չարամիտ օգտագործողի կողմից, SQL հայտարարությունը կարող է անել ավելին, քան նախատեսել էր կոդի հեղինակը: Օրինակ՝ «userName» փոփոխականը դնելով հետևյալ կերպ. 

' OR '1'='1

կամ օգտագործել մեկնաբանություններ՝ նույնիսկ մնացած հարցումը արգելափակելու համար(SQL մեկնաբանությունների երեք տեսակ կա[13]). Բոլոր երեք տողերը վերջում ունեն տարածություն : 

' OR '1'='1' --
' OR '1'='1' {
' OR '1'='1' /*

ներկայացնում է հետևյալ SQL հայտարարություններից մեկը մայր լեզվով. 

SELECT * FROM users WHERE name = '' OR '1'='1';

SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

Եթե ​​այս կոդը պետք է օգտագործվեր նույնականացման ընթացակարգում, ապա այս օրինակը կարող է օգտագործվել յուրաքանչյուր տվյալների դաշտի ընտրությունը հարկադրելու համար (*)բոլոր օգտվողներից, այլ ոչ թե մեկ կոնկրետ օգտվողի անունից, ինչպես նախատեսված էր կոդավորողը, քանի որ '1'='1' գնահատումը միշտ ճիշտ է:

Ստորև բերված հայտարարության մեջ «userName»-ի հետևյալ քանակը կհանգեցնի «users» աղյուսակի ջնջմանը, ինչպես նաև «userinfo» աղյուսակից բոլոր տվյալների ընտրությանը (ըստ էության բացահայտում է յուրաքանչյուր օգտագործողի տեղեկատվությունը), օգտագործելով API, որը թույլ է տալիս մի քանի հայտարարություններ. 

a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

Այս մուտքագրումը ներկայացնում է վերջնական SQL հայտարարությունը հետևյալ կերպ և նշվում. 

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

Թեև SQL սերվերի ներդրման մեծ մասը թույլ է տալիս մի քանի հայտարարություններ կատարել մեկ զանգով այս ձևով, որոշ SQL API-ներ, ինչպիսիք են PHP'-ի mysql_query()գործառույթը դա թույլ չի տալիս անվտանգության նկատառումներից ելնելով: Սա խանգարում է հարձակվողներին ամբողջովին առանձին հարցումներ ներարկել, բայց չի խանգարում նրանց հարցումները փոփոխելուց:

Կույր SQL ներմուծում[խմբագրել | խմբագրել կոդը]

Կույր SQL ներմուծուման օգտագործվում է, երբ վեբ հավելվածը խոցելի է SQL ներմուծման համար, սակայն ներմուծման արդյունքները տեսանելի չեն հարձակվողին: Խոցելիություն ունեցող էջը կարող է չլինել այնպիսին, որը ցուցադրում է տվյալներ, այլ կցուցադրվի տարբեր կերպ՝ կախված այդ էջի համար կանչված օրինական SQL հայտարարության մեջ ներարկված տրամաբանական հայտարարության արդյունքներից: Հարձակման այս տեսակը ավանդաբար համարվում է ժամանակատար, քանի որ յուրաքանչյուր վերականգնված բիթերի համար անհրաժեշտ էր ստեղծել նոր հայտարարություն, և կախված դրա կառուցվածքից՝ հարձակումը կարող է բաղկացած լինել բազմաթիվ անհաջող հարցումներից:Վերջին առաջխաղացումները թույլ են տվել յուրաքանչյուր հարցում վերականգնել մի քանի բիթ, առանց անհաջող հարցումների, ինչը թույլ է տալիս ավելի հետևողական և արդյունավետ արդյունահանում:[14] Կան մի քանի գործիքներ, որոնք կարող են ավտոմատացնել այս հարձակումները, երբ հաստատվի խոցելիության գտնվելու վայրը և թիրախային տեղեկատվությունը:[15]

Պայմանական պատասխաններ[խմբագրել | խմբագրել կոդը]

Կույր SQL ներմուծուման մի տեսակ ստիպում է տվյալների բազան գնահատել տրամաբանական հայտարարություն սովորական հավելվածի էկրանին: Որպես օրինակ՝ գրքի ակնարկի կայքը օգտագործում է հարցումների տող՝ որոշելու համար, թե որ գրքի ակնարկը պետք է ցուցադրվի: Այսպիսով, URL https://books.example.com/review?id=5 կստիպի սերվերին գործարկել հարցումը․ 

SELECT * FROM bookreviews WHERE ID = '5';

որտեղից այն կհամալրեր վերանայման էջը վերանայման տվյալների հետ ID 5-ի, պահվում է աղյուսակի գրախույզներում: Հարցումն ամբողջությամբ կատարվում է սերվերի վրա. օգտատերը չգիտի տվյալների բազայի, աղյուսակի կամ դաշտերի անունները, ինչպես նաև օգտատերը չգիտի հարցման տողը: Օգտագործողը միայն տեսնում է, որ վերը նշված URL-ը վերադարձնում է գրքի ակնարկ։ Հաքերը կարող է բեռնել URL-ները https://books.example.com/review?id=5 OR 1=1 և https://books.example.com/review?id=5 AND 1=2,ինչը կարող է հանգեցնել հարցումների։ 

SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';

Եթե ​​սկզբնական ակնարկը բեռնվում է «1=1» URL-ով, և «1=2» URL-ից վերադարձվում է դատարկ կամ սխալ էջ, և վերադարձված էջը չի ստեղծվել օգտատիրոջը ծանուցելու համար, որ մուտքագրումն անվավեր է, կամ այլ կերպ. բառերով, որը բռնվել է մուտքագրման թեստային սցենարով, կայքը, հավանաբար, խոցելի է SQL ներարկման հարձակման համար, քանի որ հարցումը, հավանաբար, հաջողությամբ կանցնի երկու դեպքում էՀաքերը կարող է շարունակել այս հարցման տողը, որը նախատեսված է սերվերում աշխատող MySQL-ի տարբերակի համարը բացահայտելու համար.աշխատում է սերվերի վրա․ https://books.example.com/review?id=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4,որը ցույց կտա գրքի ակնարկը MySQL 4-ով աշխատող սերվերի վրա, իսկ հակառակ դեպքում՝ դատարկ կամ սխալ էջ: Հաքերը կարող է շարունակել օգտագործել կոդ հարցումների տողերի մեջ՝ ուղղակիորեն հասնելու իրենց նպատակին, կամ սերվերից ավելի շատ տեղեկություններ քաղել՝ հարձակման այլ ճանապարհ գտնելու հույսով:[16][17]

Երկրորդ կարգի SQL ներմուծում[խմբագրել | խմբագրել կոդը]

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

Մեղմացում[խմբագրել | խմբագրել կոդը]

SQL ներմուծումը հայտնի հարձակում է և հեշտությամբ կանխվում է պարզ միջոցներով: 2015 թվականին TalkTalk-ի վրա SQL ներմուծման ակնհայտ հարձակումից հետո BBC-ն հաղորդում է, որ անվտանգության փորձագետները ապշած էին, որ նման խոշոր ընկերությունը խոցելի կլինի դրա համար:[18]

Օբյեկտների հարաբերական քարտեզագրիչներ (Object Relational Mappers or ORM)[խմբագրել | խմբագրել կոդը]

Մշակողները կարող են օգտագործել ORM շրջանակներ, ինչպիսիք են Hibernate-ը[19] ստեղծել տվյալների բազայի հարցումներ անվտանգ և մշակողների համար հարմար եղանակով: Քանի որ տվյալների բազայի հարցումներն այլևս չեն կառուցվում որպես տողեր, ներարկման խոցելիության վտանգ չկա:[20]

Վեբ հավելվածի Firewall (Web Application Firewalls)[խմբագրել | խմբագրել կոդը]

Մինչ WAF արտադրանքները, ինչպիսիք են ModSecurity CRS-ը[21] չեն կարող կանխել SQL ներմուծման խոցելիությունները կոդի բազայի մեջ սողոսկելուց, դրանք կարող են հայտնաբերումն ու շահագործումը զգալիորեն ավելի բարդացնել հարձակվողի համար:

Դրսևորում[խմբագրել | խմբագրել կոդը]

SQL ներմուծման զտիչն աշխատում է այնպես, ինչպես էլփոստի սպամի զտիչները: Տվյալների բազայի firewalls-ը հայտնաբերում է SQL ներմուծումներ՝ հիմնվելով հոսթից անվավեր հարցումների քանակի, հարցումի ներսում OR և UNION բլոկների առկայության կամ այլ բնութագրերի վրա։[22]

Պարամետրացված հայտարարություններ[խմբագրել | խմբագրել կոդը]

Հիմնական հոդված՝ Prepared statement

Զարգացման պլատֆորմների մեծ մասում կարող են օգտագործվել պարամետրերով աշխատող պարամետրացված հայտարարություններ (երբեմն կոչվում են տեղապահներ(անգլ՝ placeholders ) կամ կապող փոփոխականներ)՝ օգտատիրոջ մուտքագրումը հայտարարությունում ներառելու փոխարեն: Տեղապահը կարող է պահել միայն տվյալ տեսակի արժեք, այլ ոչ թե կամայական SQL հատված: Հետևաբար, SQL ներմուծումը պարզապես կդիտարկվի որպես տարօրինակ (և հավանաբար անվավեր) պարամետրի արժեք: Շատ դեպքերում SQL հայտարարությունը ամրագրված է, և յուրաքանչյուր պարամետր սկալյար է, այլ ոչ թե աղյուսակ:[23]

Հեշտ ասած, պարամետրացված հարցումների օգտագործումը կարող է միանշանակ կանխել SQL ներմուծումը: Սա հիմնականում նշանակում է, որ ձեր փոփոխականները հարցումների տողեր չեն, որոնք կընդունեն կամայական SQL մուտքեր, այնուամենայնիվ, տվյալ տեսակների որոշ պարամետրեր անպայման անհրաժեշտ են։ Պարամետրացված հարցումները պահանջում են, որ մշակողը սահմանի ամբողջ կոդը: Հետևաբար, առանց պարամետրացված հարցումների, յուրաքանչյուրը կարող էր դաշտում տեղադրել ցանկացած տեսակի SQL կոդ և ջնջել տվյալների բազան: Բայց եթե պարամետրերը սահմանվեին «@username», ապա անձը կկարողանա տեղադրել միայն օգտանուն առանց որևէ տեսակի կոդի:[24]

Հարկադրում կոդավորման մակարդակով (Enforcement at the coding level)[խմբագրել | խմբագրել կոդը]

Օբյեկտ-հարաբերական (անգլ․՝ object-relational mapping) քարտեզագրման գրադարանների օգտագործումը խուսափում է SQL կոդ գրելու անհրաժեշտությունից: Գործող ORM գրադարանը կստեղծի պարամետրացված SQL հայտարարություններ օբյեկտի վրա հիմնված կոդից:

Շրջանցում[խմբագրել | խմբագրել կոդը]

Ներարկումները կանխելու հանրաճանաչ, թեև սխալների հակված և, ի վերջո, դատապարտված միջոցը SQL-ում հատուկ նշանակություն ունեցող բոլոր նիշերից խուսափելն է: SQL DBMS-ի ձեռնարկը բացատրում է, թե որ նիշերն ունեն հատուկ նշանակություն, ինչը թույլ է տալիս ստեղծել թարգմանության կարիք ունեցող նիշերի համապարփակ սև ցուցակ (անգլ․՝ blacklist)։ Օրինակ՝ մեկ չակերտի յուրաքանչյուր դեպք (') մի պարամետրում պետք է փոխարինվի երկու առանձին չակերտներով('') վավեր SQL տող բառացի ձևավորելու համար: Օրինակ, PHP-ում սովորական է ֆունկցիայի միջոցով փախչել պարամետրերից mysqli_real_escape_string(); նախքան SQL հարցումն ուղարկելը. 

$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
                  $mysqli->real_escape_string($username),
                  $mysqli->real_escape_string($password));
$mysqli->query($query);

Այս ֆունկցիան հետևում է հետևյալ նիշերին.\x00, \n, \r, \, ', " և \x1a. Այս ֆունկցիան սովորաբար օգտագործվում է տվյալների անվտանգությունն ապահովելու համար՝ նախքան հարցում ուղարկելը MySQL․[25]
PHP-ն ունի նմանատիպ գործառույթներ տվյալների բազայի այլ համակարգերի համար, ինչպիսիք են pg_escape_string() PostgreSQL -ի համար: Ֆունկցիան addslashes(string $str)աշխատում է նիշերից խուսափելու համար և օգտագործվում է հատկապես տվյալների բազաներում հարցումներ կատարելու համար, որոնք չունեն PHP-ում խուսափան գործառույթներ: Այն վերադարձնում է մի տող՝ հետադարձ տողերով, նախքան նիշերը, որոնք պետք է խուսափեն տվյալների բազայի հարցումներում, և այլն: Այս նիշերն են մեկ մեջբերում ('), կրկնակի մեջբերում ("), հետին կտրվածք (\) և NUL (NULL բայթ):[26]
Խուսափած տողերի սովորական փոխանցումը SQL-ին հակված է սխալների, քանի որ հեշտ է մոռանալ տրված տողից խուսափումը: Մուտքագրումն ապահովելու համար թափանցիկ շերտ ստեղծելը կարող է նվազեցնել այս սխալի հակվածությունը, եթե ոչ ամբողջությամբ վերացնել այն:[27]

Նմուշի ստուգում[խմբագրել | խմբագրել կոդը]

Ամբողջական, լողացող կամ բուլյան, լարային պարամետրերը կարող են ստուգվել, եթե դրանց արժեքը վավեր է տվյալ տեսակի համար: Տողերը, որոնք պետք է հետևեն որոշակի խիստ օրինաչափության (ամսաթիվ, UUID, միայն այբբենական թվային և այլն), կարող են ստուգվել, եթե դրանք համապատասխանում են այս օրինաչափությանը:

Տվյալների բազայի թույլտվությունները[խմբագրել | խմբագրել կոդը]

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

Օրինակ, Microsoft SQL Server-ի վրա ,տվյալների բազայի մուտքը կարող է սահմանափակվել համակարգի որոշ աղյուսակների վրա ընտրելու հնարավորությունից, ինչը կսահմանափակի շահագործումները, որոնք փորձում են JavaScript-ը տեղադրել տվյալների բազայի բոլոր տեքստային սյունակներում: 

deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;

Օրինակներ[խմբագրել | խմբագրել կոդը]

  • 2002 թվականի փետրվարին Ջերեմիա Ջեքսը հայտնաբերեց, որ Guess.com-ը խոցելի է SQL ններմուծման հարձակման համար, ինչը թույլ է տալիս յուրաքանչյուրին, ով կարող է ճիշտ մշակված URL ստեղծել՝ կայքի հաճախորդների տվյալների բազայում 200,000+ անուններ, կրեդիտ քարտերի համարներ և պիտանելիության ժամկետներ տեղադրելու համար:[28]
  • 2005 թվականի նոյեմբերի 1-ին դեռահաս հաքերն օգտագործել է SQL ներմուծում՝ ներխուժելու Tech Target խմբի թայվանական տեղեկատվական անվտանգության ամսագրի կայք և գողանալ հաճախորդների տեղեկությունները:[29]
  • 2006 թվականի հունվարի 13-ին ռուս համակարգչային հանցագործները ներխուժեցին Ռոդ Այլենդի կառավարական կայք և իբր գողացան կրեդիտ քարտի տվյալները այն անձանցից, ովքեր առցանց բիզնես են վարել պետական ​​գերատեսչությունների հետ:[30]
  • 2006 թվականի մարտի 29-ին հաքերը հայտնաբերեց SQL ներմուծման թերություն Հնդկաստանի կառավարության զբոսաշրջության պաշտոնական կայքում։[31]
  • 2008թ. մայիսին Չինաստանում գտնվող սերվերային ֆերմա օգտագործեց ավտոմատացված հարցումներ Google-ի որոնողական համակարգին՝ բացահայտելու SQL սերվերի կայքերը, որոնք խոցելի էին ավտոմատացված SQL ներարկման գործիքի հարձակման նկատմամբ:[32][33]
  • 2009 թվականի դեկտեմբերին հարձակվողը խախտել է RockYou պարզ տեքստային տվյալների բազան, որը պարունակում է մոտ 32 միլիոն օգտատերերի չգաղտնագրված օգտանուններ և գաղտնաբառեր՝ օգտագործելով SQL ներմուծան հարձակումը:[34]
  • Սեպտեմբերի 19-ին 2010-ի Շվեդիայի համընդհանուր ընտրությունների ժամանակ ընտրողը փորձեց կոդի ներմուծում՝ ձեռքով գրելով SQL հրամաններ՝ որպես գրելու քվեարկության մաս:[35]
  • 2010 թվականի նոյեմբերի 8-ին բրիտանական թագավորական նավատորմի կայքը վտանգի ենթարկվեց Tin Kode անունով ռումինացի հաքերների կողմից՝ օգտագործելով SQL ներմուծում։[36][37]
  • 2011 թվականի փետրվարի 5-ին HBGary, տեխնոլոգիական անվտանգության ընկերություն, ներխուժել է LulzSec-ը՝ օգտագործելով SQL ներմուծում իրենց CMS-ի վրա հիմնված կայքում:[38]
  • 2011 թվականի ապրիլի 11-ին Barracuda Networks-ը վտանգի ենթարկվեց՝ օգտագործելով SQL ներմուծման թերությունը: Ձեռք բերված տեղեկությունների թվում էին աշխատակիցների էլեկտրոնային փոստի հասցեները և օգտվողների անունները:.[39]
  • 2011թ. ապրիլի 27-ին 4 ժամ տևողությամբ ավտոմատացված SQL ներմուծման հարձակում տեղի ունեցավ Broadband Reports կայքում, որը կարողացավ հանել օգտվողի անուն/գաղտնաբառ զույգերի 8%-ը.[40][41][42]
  • 2011 թվականի հունիսի 1-ին LulzSec խմբի «հաքթիվիստները» մեղադրվեցին SQLI-ի միջոցով գողանալու կտրոններ, ներբեռնման բանալիներ և գաղտնաբառեր, որոնք պահվում էին պարզ տեքստով Sony-ի կայքում՝ մուտք գործելով միլիոն օգտատերերի անձնական տվյալները.[43]
  • 2012 թվականի հուլիսին հաքերային խումբը գողացել է Yahoo!-ից 450,000 մուտքի հավատարմագրեր: Մուտքագրումները պահվում էին պարզ տեքստով և իբր վերցված էին Yahoo ենթադոմեյնից՝ Yahoo! Ձայներ. Խումբը խախտել է Yahoo-ի անվտանգությունը՝ օգտագործելով «միության վրա հիմնված SQL ներմուծման տեխնիկա»:[44][45]
  • 2013 թվականի հունիսի 27-ին «RedHack» հաքերային խումբը կոտրել է Ստամբուլի վարչական կայքը։[46] Նրանք պնդում էին, որ կարողացել են ջնջել ջրի, գազի, ինտերնետի, էլեկտրաէներգիայի, հեռախոսային ընկերություններին ունեցած պարտքերը։ Բացի այդ, նրանք հրապարակեցին ադմինիստրատորի օգտանունը և գաղտնաբառը, որպեսզի այլ քաղաքացիներ մուտք գործեն և վաղ առավոտյան մարեն իրենց պարտքերը: Նրանք այդ լուրը հայտնել են Twitter-ից։[47]
  • 2013 թվականի նոյեմբերի 4-ին «RaptorSwag» հաքերային խումբն իբր կոտրել է Չինաստանի կառավարության 71 տվյալների բազա՝ օգտագործելով SQL ներմուծման հարձակման Չինաստանի միջազգային առևտրի պալատի վրա: Արտահոսած տվյալները հրապարակվել են Anonymous-ի հետ համագործակցությամբ։[48]
  • 2014 թվականի փետրվարի 2-ին AVS TV-ն ուներ 40,000 հաշիվներ, որոնք արտահոսել էին հաքերային խումբը, որը կոչվում էր @deletesec: [49]
  • 2015 թվականի հոկտեմբերին SQL ներմուծման հարձակումն օգտագործվել է բրիտանական TalkTalk հեռահաղորդակցական ընկերության սերվերներից 156,959 հաճախորդների անձնական տվյալները գողանալու համար՝ օգտվելով ժառանգական վեբ պորտալի խոցելիությունից:[50]
  • 2020 թվականի օգոստոսին SQL ներմուծման հարձակումը կիրառվեց Ստենֆորդի շատ ուսանողների ռոմանտիկ հետաքրքրությունների մասին տեղեկատվություն ստանալու համար՝ Link-ի կողմից տվյալների ախտահանման անապահով ստանդարտների հետևանքով, որը հիմնադրվել էր համալսարանում բակալավրիատի Իշան Գանդիի կողմից:[51]
  • 2021 թվականի սկզբին 70 գիգաբայթ տվյալներ են արտահանվել ծայրահեղ աջակողմյան Gab կայքից SQL ներմուծման հարձակման միջոցով։ Խոցելիությունը ներմուծվել է Gab կոդերի բազա Ֆոսկո Մարոտտոյի՝ Gab-ի CTO-ի կողմից:[52]Երկրորդ հարձակումը Gab-ի դեմ սկսվեց հաջորդ շաբաթ՝ օգտագործելով առաջին հարձակման ժամանակ գողացված OAuth2 նշանները:[53]

Տես նաև[խմբագրել | խմբագրել կոդը]

Աղբյուրներ[խմբագրել | խմբագրել կոդը]

  1. ↑ Microsoft. «SQL Injection». Արխիվացված օրիգինալից August 2, 2013-ին. Վերցված է 2013-08-04-ին. «SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution. Any procedure that constructs SQL statements should be reviewed for injection vulnerabilities because SQLi Server will execute all syntactically valid queries that it receives. Even parameterized data can be manipulated by a skilled and determined attacker.»
  2. ↑ Imperva (July 2012). «Imperva Web Application Attack Report» (PDF). Արխիվացված (PDF) օրիգինալից September 7, 2013-ին. Վերցված է 2013-08-04-ին. «Retailers suffer 2x as many SQL injection attacks as other industries. / While most web applications receive 4 or more web attack campaigns per month, some websites are constantly under attack. / One observed website was under attack 176 out of 180 days, or 98% of the time.»
  3. ↑ Sean Michael Kerner (November 25, 2013). «How Was SQL Injection Discovered? The researcher once known as Rain Forrest Puppy explains how he discovered the first SQL injection more than 15 years ago». Արխիվացված օրիգինալից March 18, 2014-ին.
  4. ↑ Jeff Forristal (signing as rain.forest.puppy) (Dec 25, 1998). «NT Web Technology Vulnerabilities». Phrack Magazine. 8 (54 (article 8)). Արխիվացված օրիգինալից March 19, 2014-ին.
  5. ↑ «Category:OWASP Top Ten Project». OWASP. Արխիվացված օրիգինալից May 19, 2011-ին. Վերցված է 2011-06-03-ին.
  6. ↑ «Category:OWASP Top Ten Project». OWASP. Արխիվացված օրիգինալից October 9, 2013-ին. Վերցված է 2013-08-13-ին.
  7. ↑ «WHID 2007-60: The blog of a Cambridge University security team hacked». Xiom. Արխիվացված է օրիգինալից June 19, 2011-ին. Վերցված է 2011-06-03-ին.
  8. ↑ «WHID 2009-1: Gaza conflict cyber war». Xiom. Արխիվացված է օրիգինալից October 7, 2011-ին. Վերցված է 2011-06-03-ին.
  9. ↑ «List of Web Hacking Incidents: DNS Hijacking». Xiom. Արխիվացված է օրիգինալից June 18, 2009-ին.
  10. ↑ «Third Wave of Web Attacks Not the Last». Dark Reading. Վերցված է 2012-07-29-ին.
  11. ↑ Danchev, Dancho (2007-01-23). «Mind Streams of Information Security Knowledge: Social Engineering and Malware». Ddanchev.blogspot.com. Արխիվացված օրիգինալից July 21, 2011-ին. Վերցված է 2011-06-03-ին.
  12. ↑ Deltchev, Krassen. «New Web 2.0 Attacks». B.Sc. Thesis. Ruhr-University Bochum. Վերցված է February 18, 2010-ին.
  13. ↑ «How to Enter SQL Comments» (PDF), IBM Informix Guide to SQL: Syntax, IBM, էջեր 13–14, Վերցված է 2018-06-04-ին
  14. ↑ «Extracting Multiple Bits Per Request From Full-blind SQL Injection Vulnerabilities». Hack All The Things. Արխիվացված է օրիգինալից July 8, 2016-ին. Վերցված է July 8, 2016-ին.
  15. ↑ «Using SQLBrute to brute force data from a blind SQL injection point». Justin Clarke. Արխիվացված է օրիգինալից June 14, 2008-ին. Վերցված է October 18, 2008-ին.
  16. ↑ macd3v. «Blind SQL Injection tutorial». Արխիվացված է օրիգինալից December 14, 2012-ին. Վերցված է 6 December 2012-ին.{{cite web}}: CS1 սպաս․ թվային անուններ: authors list (link)
  17. ↑ Andrey Rassokhin; Dmitry Oleksyuk. «TDSS botnet: full disclosure». Արխիվացված է օրիգինալից December 9, 2012-ին. Վերցված է 6 December 2012-ին.
  18. ↑ «Questions for TalkTalk - BBC News». BBC News (անգլերեն). October 26, 2015. Արխիվացված օրիգինալից October 26, 2015-ին. Վերցված է 2015-10-26-ին.
  19. ↑ «Hibernate». hibernate.org. Վերցված է 2021-02-24-ին.
  20. ↑ «SQL Injection Attacks & Prevention: Complete Guide». appsecmonkey.com. February 13, 2021. Վերցված է 2021-02-24-ին.
  21. ↑ «ModSecurity: Rules». modsecurity.org. Վերցված է 2021-02-24-ին.
  22. ↑ Security, DataSunrise (2019-02-01). «Methods of SQL Injections Detection». DataSunrise Database Security. (ամերիկյան անգլերեն). Վերցված է 2019-08-28-ին.
  23. ↑ «SQL Injection Prevention Cheat Sheet». Open Web Application Security Project. Արխիվացված օրիգինալից January 20, 2012-ին. Վերցված է 3 March 2012-ին.
  24. ↑ Security, Penta (2016-05-26). «What is SQL injection and how can you prevent it from happening?». Penta Security Systems Inc. (ամերիկյան անգլերեն). Վերցված է 2019-08-08-ին.
  25. ↑ «mysqli->real_escape_string - PHP Manual». PHP.net. Վերցված է October 11, 2013-ին.
  26. ↑ «Addslashes - PHP Manual». PHP.net. Արխիվացված է օրիգինալից September 5, 2011-ին.
  27. ↑ «Transparent query layer for MySQL». Robert Eisele. November 8, 2010. Արխիվացված օրիգինալից November 11, 2010-ին.
  28. ↑ «Guesswork Plagues Web Hole Reporting». SecurityFocus. March 6, 2002. Արխիվացված օրիգինալից July 9, 2012-ին.
  29. ↑ «WHID 2005-46: Teen uses SQL injection to break to a security magazine web site». Web Application Security Consortium. November 1, 2005. Արխիվացված է օրիգինալից January 17, 2010-ին. Վերցված է December 1, 2009-ին.
  30. ↑ «WHID 2006-3: Russian hackers broke into a RI GOV website». Web Application Security Consortium. January 13, 2006. Արխիվացված է օրիգինալից February 13, 2011-ին. Վերցված է May 16, 2008-ին.
  31. ↑ «WHID 2006-27: SQL Injection in incredibleindia.org». Web Application Security Consortium. March 29, 2006. Արխիվացված է օրիգինալից July 1, 2009-ին. Վերցված է March 12, 2010-ին.
  32. ↑ Sumner Lemon, IDG News Service (May 19, 2008). «Mass SQL Injection Attack Targets Chinese Web Sites». PCWorld. Վերցված է May 27, 2008-ին.
  33. ↑ Michael Zino (May 1, 2008). «ASCII Encoded/Binary String Automated SQL Injection Attack». Արխիվացված օրիգինալից June 1, 2008-ին.
  34. ↑ O'Dell, Jolie (December 16, 2009). «RockYou Hacker - 30% of Sites Store Plain Text Passwords». New York Times. Վերցված է May 23, 2010-ին.
  35. ↑ «Did Little Bobby Tables migrate to Sweden?». Alicebobandmallory.com. Արխիվացված օրիգինալից July 1, 2012-ին. Վերցված է 2011-06-03-ին.
  36. ↑ Royal Navy website attacked by Romanian hacker Արխիվացված Նոյեմբեր 9, 2010 Wayback Machine BBC News, 8-11-10, Accessed November 2010
  37. ↑ Sam Kiley (November 25, 2010). «Super Virus A Target For Cyber Terrorists». Արխիվացված օրիգինալից November 28, 2010-ին. Վերցված է November 25, 2010-ին.
  38. ↑ «We Are Anonymous: Inside the Hacker World of LulzSec» (PDF). Little, Brown and Company. Արխիվացված է օրիգինալից (PDF) July 18, 2012-ին.
  39. ↑ «Hacker breaks into Barracuda Networks database». Արխիվացված է օրիգինալից July 27, 2011-ին.
  40. ↑ «site user password intrusion info». Dslreports.com. Արխիվացված օրիգինալից October 18, 2012-ին. Վերցված է 2011-06-03-ին.
  41. ↑ «DSLReports says member information stolen». Cnet News. 2011-04-28. Արխիվացված օրիգինալից March 21, 2012-ին. Վերցված է 2011-04-29-ին.
  42. ↑ «DSLReports.com breach exposed more than 100,000 accounts». The Tech Herald. 2011-04-29. Արխիվացված է օրիգինալից April 30, 2011-ին. Վերցված է 2011-04-29-ին.
  43. ↑ «LulzSec hacks Sony Pictures, reveals 1m passwords unguarded», electronista.com, June 2, 2011, Արխիվացված է օրիգինալից June 6, 2011-ին, Վերցված է June 3, 2011-ին
  44. ↑ Chenda Ngak. "Yahoo reportedly hacked: Is your account safe?" Արխիվացված Հուլիս 14, 2012 Wayback Machine, CBS News. July 12, 2012. Retrieved July 16, 2012.
  45. ↑ Yap, Jamie (July 12, 2012). «450,000 user passwords leaked in Yahoo breach». ZDNet. Արխիվացված օրիգինալից July 2, 2014-ին. Վերցված է 2017-02-18-ին.
  46. ↑ «RedHack Breaches Istanbul Administration Site, Hackers Claim to Have Erased Debts». Արխիվացված օրիգինալից June 29, 2013-ին.
  47. ↑ @RedHack_EN (June 28, 2013). «Open to public hacking. One of Governor of Istanbul's site User: 'or=' Pass: 'or=' Site:http://ioi.gov.tr/fatura/login.php http://pic.twitter.com/ZEHBFJLVfT» (Թվիթ). Արխիվացված է օրիգինալից August 12, 2016-ին – via Թվիթթեր.
  48. ↑ Kovacs, Eduard (November 4, 2013). «Hackers Leak Data Allegedly Stolen from Chinese Chamber of Commerce Website». Softpedia News. Արխիվացված օրիգինալից March 2, 2014-ին. Վերցված է 2014-02-27-ին.
  49. ↑ «40,000 AVS TV Accounts Leaked». Maurihackers. Արխիվացված օրիգինալից February 19, 2015-ին. Վերցված է 2015-02-19-ին.
  50. ↑ «TalkTalk gets record £400,000 fine for failing to prevent October 2015 attack». 5 October 2016. Արխիվացված է օրիգինալից October 24, 2016-ին. Վերցված է 2016-10-23-ին.
  51. ↑ Catania, Sam (August 13, 2020). «Vulnerability in 'Link' website may have exposed data on Stanford students' crushes». The Stanfort Daily. Վերցված է September 5, 2020-ին.
  52. ↑ Goodin, Dan (March 2, 2021). «Rookie coding mistake prior to Gab hack came from site's CTO». Ars Technica.
  53. ↑ Goodin, Dan (March 8, 2021). «Gab, a haven for pro-Trump conspiracy theories, has been hacked again». Ars Technica.

Արտաքին կապեր[խմբագրել | խմբագրել կոդը]

Կատեգորիա:Injection exploits Կատեգորիա:SQL Կատեգորիա:Articles with example SQL code Կատեգորիա:Computer security exploits

Ստացված է «https://hy.wikipedia.org/w/index.php?title=Մասնակից:Valentina27112004/Ավազարկղ&oldid=8190441» էջից