Samsett vefverkefni: Norðurmarkaðurinn

Þú hefur nú skoðað vafraverkfæri, HTTP, JavaScript, auðkenning, lotur, aðgangsstýringu, SQL-innskot og vefkóðainnskoti. Lokaverkefnið bætir ekki við nýjum veikleikaflokki. Það reynir á að halda utan um nokkrar beiðnir án þess að stökkva strax að flóknustu tilgátunni.

Norðurmarkaðurinn er tilbúin verslun með gervireikningum, pöntunum og vöruleit. Þú færð aðgang að reikningi Önnu. Markmiðið er að rekja lotuna, sýna einn aðgangsstýringarmun, greina samhengi endurvarpaðs gildis og staðfesta SQL-innskot sem leiðir að lokafánanum.

Rannsóknarreglan

Í stað þess að safna nytjahleðslum skaltu vinna í þessari röð:

beiðni → tilgáta → ein breyting → samanburður → staðfest geta

Beiðnin er grunnlína sem þú veist hvað gerir. Tilgátan nefnir eina forsendu þjónsins. Ein breyting einangrar prófið. Samanburðurinn sýnir hvort svarið breyttist. Getan lýsir því sem þú gast í raun gert, ekki því sem veikleikaflokkur getur stundum gert í öðrum kerfum.

Haltu litla rannsóknartöflu á meðan þú vinnur:

Fylltu sjálf/ur inn nákvæmar slóðir, auðkenni og svör. Taflan er glósa, ekki snið sem þarf að skila orðrétt.

Undirbúningur

Hafðu Network og Burp HTTP history tiltæk, en veldu eitt aðalverkfæri fyrir hverja tilraun. Vafrinn er góður til að sjá flæðið og Repeater til að bera saman beiðnir. curl er gott þegar endurtakanleg lausn er orðin skýr.

Farðu stuttlega yfir:

• byggingu HTTP-beiðni,
• kökur og lotur,
• IDOR-prófið með einni auðkennisbreytingu,
• XSS-samhengi,
• og sönn/ósönn SQL-skilyrði.

Þú þarft ekki að lesa kaflana aftur frá byrjun. Notaðu þá þegar ákveðin mæling eða setningafræði veldur vafa.

Skref 1: finndu lotuna

Opnaðu innskráningarsíðuna með Network-listann hreinan og skráðu þig inn með gerviupplýsingum Önnu. Finndu POST /login, svarið við henni og næsta skref framsendingarinnar.

Leitaðu að:

Set-Cookie: <heiti>=<gervigildi>; ...

og staðfestu að næsta beiðni sendi:

Cookie: <heiti>=<sama gervigildi>

Þú þarft ekki að afkóða kökuna. Markmiðið er að vita hvaða gildi heldur lotunni saman og varðveita það þegar beiðni er flutt í Repeater eða curl.

Skráðu í einni setningu:

Auðkenning tókst vegna þess að ... og lotan sést í ...

Ekki setja fullt lotugildi í skýrslu sem aðrir lesa. Heiti kökunnar og afmáð sýnishorn nægir.

Skref 2: aðgreindu auðkenning og aðgangsstýringu

Farðu á pöntunarlistann og opnaðu pöntun Önnu. Varðveittu beiðnina:

GET /orders/<auðkenni Önnu> HTTP/1.1
Host: <hýsir verkefnisins>
Cookie: <lota Önnu>

Svarið á að nefna Önnu. Þetta er grunnbeiðnin.

Verkefnið inniheldur afmarkaða stuðningsfærslu sem nefnir pöntunarauðkenni Bjarna. Notaðu það nákvæma gildi og breyttu aðeins slóðarhlutanum í Repeater. Kakan, aðferðin og aðrir hausar eiga að vera óbreyttir.

Ef svarið sýnir pöntun Bjarna hefur þjónninn auðkennd Önnu en ekki tengt valda pöntun við hana. Lýstu niðurstöðunni nákvæmlega:

Lota Önnu gat lesið eina þekkta pöntun Bjarna með því að breyta auðkenninu.

Ekki kalla þetta innskráningarbypass; Anna var þegar rétt innskráð. Ekki prófa næstu tíu auðkenni; eitt þekkt samanburðargildi nægir.

Athugasemd Bjarna gefur einnig vísbendingu um seinni vöruleitina. Vistaðu hana í glósunum en hoppaðu ekki strax yfir XSS-skrefið.

Skref 3: greindu endurvarpaða leit

Opnaðu /search með venjulegu orði og finndu q í hráa HTTP-svarinu. Sendu síðan einstakt merki:

NORDUR_XSS_42

Svaraðu þessum spurningum áður en þú reynir HTML:

1. Er merkið í hráa svarinu eða aðeins lifandi DOM?
2. Er það milli HTML-merkja, inni í eigind eða í JavaScript-streng?
3. Eru <, >, gæsalappir eða önnur tákn kóðuð?

Notaðu lítið sniðmerki til að staðfesta HTML-túlkun. Ef það myndar nýja HTML-einingu skaltu nota sömu skaðlausu data-xss-DOM-breytingu og í XSS-kaflanum til að staðfesta JavaScript-keyrslu.

Enginn bot opnar slóðina og engin gögn eiga að fara út fyrir vafrann þinn. Þetta skref biður um samhengi og staðfesta keyrslu, ekki annan fána.

Skráðu muninn:

Uppspretta: q í ...
Svelgur: ...
Samhengi: ...
Mæling: ... breyttist í eigin DOM

Ef HTML er kóðað og JavaScript keyrir ekki skaltu skrá þá vísbendingu í stað þess að fullyrða um XSS.

Skref 4: staðfestu SQL-túlkun

Vöruleitin er annað inntak en endurvarpaða leitin. Byrjaðu með venjulegri /catalog-beiðni sem skilar einni vöru. Varðveittu svarlengd og nöfn dálka sem síðan birtir.

Prófaðu næst einn gæsalappa. Afmörkuð villa verkefnisins og athugasemdin úr pöntun Bjarna eiga saman að gefa nægar upplýsingar um SQLite-samhengið. Ekki nota sjálfvirkt SQLi-tól; markmiðið er að sýna að þú skiljir eina fyrirspurn.

Byggðu par af inntökum þar sem aðeins skilyrðið breytist:

<samhengislokun> AND 1=1 <athugasemd>
<samhengislokun> AND 1=2 <athugasemd>

Sendu þau með --data-urlencode eða Repeater. Ef sanna skilyrðið og ósanna skilyrðið gefa stöðugt ólíkar vöruniðurstöður hefurðu staðfest SQL-innskot.

Næst þarf að finna dálkafjöldann. Byrjaðu með NULL-gildum og bættu einu í einu þar til UNION passar við venjulegu fyrirspurnina. Notaðu tvö ólík textamerki til að sjá hvaða dálkur birtist. Verkefnið er hannað fyrir lítið, fast skema; engin sjálfvirk töfluupptalning er nauðsynleg.

Lokafyrirspurnin á aðeins að sækja fánann úr töflunni sem verkefnisvísbendingin nefnir. Kaflinn gefur hvorki fulla fyrirspurn né töflu- og dálkaheiti. Varðveittu minnstu beiðnina sem skilar gg{...}.

Ef þú festist

Farðu aftur að síðasta staðfesta skrefi. Ef Repeater fær innskráningarsíðu skaltu athuga kökuna, ekki breyta SQL-inntakinu. Ef XSS-merki sést aðeins í Elements skaltu rekja JavaScript, ekki kalla það endurvarpað. Ef gæsalappi veldur villu en satt og ósatt gefa sama svar hefur SQL-tilgátan ekki enn verið staðfest.

Algengast er að óvart sé breytt fleiri en einu atriði:

önnur slóð + önnur aðferð + engin kaka + nýtt inntak

Endurbyggðu grunnbeiðnina og bættu aðeins einni breytingu við.

Notaðu vísbendingu verkefnisins þegar þú hefur skráða spurningu. „Ég veit að tveir dálkar birtast en UNION fær dálkavillu“ er gagnleg staða. „Ekkert virkar“ segir ekki hvaða þröskuld þarf að hjálpa yfir.

Endurtakanleg lausn

Góð lausn lokaverkefnisins er stutt en nákvæm. Hún þarf ekki að birta hvert mistak eða langan lista af inntökum. Skrifaðu hana í þeirri röð sem gögnin leiddu þig:

1. Umfang og aðgangur: hvaða gervireikning og þjónustu notaðirðu?
2. Lota: hvaða svar stofnaði kökuna og hvernig varðveittirðu hana?
3. IDOR: hvaða eina auðkenni breyttist og hvaða eigandi birtist?
4. XSS-samhengi: hvar lenti q og hvaða staðbundna mæling staðfesti eða mótmælti keyrslu?
5. SQLi: hvaða satt/ósatt par staðfesti túlkun og hvernig fannstu sýnilegan dálk?
6. Lokabeiðni: minnsta beiðni sem skilaði fánanum, með fánanum afmáðum í opinberri skýrslu.

Fyrir hvert veikleikaskref skaltu nefna staðfesta getu:

IDOR → lesa eina pöntun annars gervinotanda
XSS → keyra staðbundið JavaScript í eigin Norðurmarkaðsuppruna
SQLi → lesa eina tilbúna röð úr flaggtöflu

Ekki stækka áhrifin í „full stjórn á þjóninum“. Verkefnið veitir hvorki skráaraðgang né skel.

Lokayfirferð

Áður en þú skilar fánanum skaltu ganga úr skugga um að:

• allar beiðnir fóru aðeins á úthlutaða Norðurmarkaðsþjónustu,
• auðkenni komu úr viðmóti eða vísbendingu, ekki skönnun,
• IDOR-beiðnin notaði lotu Önnu,
• XSS-mælingin sendi engin gögn út fyrir vafrann,
• SQLi var staðfest með samanburði áður en flaggröðin var sótt,
• og lausnin er hægt að endurtaka frá nýrri gervilotu.

Lokaverkefnið snýst ekki um lengstu nytjahleðsluna. Það snýst um að halda rauða þræðinum:

notandastýrt gildi → mörk → röng forsenda → mæling → CTF-markmið

Í síðasta kafla vefleiðarinnar veljum við næstu æfingavettvanga og verkefni eftir því hvaða hluta þessa vinnuferlis við viljum styrkja.