Inngangur að veföryggi og verkfærin okkar

Þú opnar vefsíðu, smellir á hnapp og eitthvað gerist. Kannski birtist vara, innskráning tekst eða villuboð koma upp. Vafrinn sýnir okkur útkomuna, en í vefverkefni gagnaglímu er áhugaverðasta spurningin oft: hvaða samtal fór fram á bak við hnappinn?

Í þessum fyrsta kafla ætlum við ekki að læra langan lista af veikleikum. Við ætlum að læra að horfa. Við skoðum hvað vafrinn sendir, hvað þjónninn svarar og hvernig hægt er að endurtaka sömu beiðni án þess að smella aftur á hnappinn. Þetta er grunnvinnuferlið sem við notum síðar við innskráningar, lotur, aðgangsstýringu og innskot.

Kaflinn fylgir verkefninu Beiðnin týndist. Opnaðu verkefnið þegar það birtist hér, en reyndu ekki strax að giska á fánann. Fyrsta markmiðið er aðeins að finna beiðnina sem hnappurinn sendir.

Vefurinn er samtal

Vafri (e. browser) er forrit eins og Firefox, Chrome eða Safari. Þegar hann sækir síðu gegnir hann hlutverki biðlara (e. client): hann hefur samband við annað forrit og biður um eitthvað. Vefþjónn (e. web server) tekur við beiðninni, vinnur úr henni og sendir svar til baka.

notandi → vafri/biðlari → HTTP-beiðni → vefþjónn
notandi ← vafri         ← HTTP-svar   ← vefþjónn

Vafrinn getur síðan sent fleiri beiðnir. Ein sækir HTML-síðuna, önnur stílsnið, sú þriðja JavaScript og sú fjórða gögn þegar smellt er á hnapp. Síða sem lítur út eins og eitt skjal getur því verið afrakstur margra sjálfstæðra samtala.

HTTP-beiðni (e. HTTP request) og HTTP-svar (e. HTTP response) eru skilaboðin í þessu samtali. Farið verður gaumgæfilega yfir uppbyggingu þeirra í næsta kafla. Í bili nægir að kunna að greina fjóra hluti:

• beiðniaðferð, til dæmis GET eða POST,
• slóðina sem beðið er um,
• hausa sem bera viðbótarupplýsingar,
• og líkama sem getur innihaldið gögn.

Einföld beiðni gæti litið svona út:

GET /sending HTTP/1.1
Host: nordurmarkadur.example
Accept: application/json

Fyrsta línan segir að biðlarinn biðji um /sending. Host segir hvaða hýsi beiðnin á við og Accept lýsir því hvaða svarform biðlarinn kann að vinna með. Auða línan markar endalok hausanna. Þessi beiðni hefur engan líkama.

Svarið gæti verið:

HTTP/1.1 200 OK
Content-Type: application/json
X-Next-Header: X-Lab-Key

{"next":"/flag","message":"Skoðaðu svarhausana."}

Hér er 200 stöðukóði sem gefur til kynna að beiðnin hafi heppnast. Hausinn Content-Type segir að líkaminn sé á textagagnasniðinu JSON. X-Next-Header er ekki almenn HTTP-regla heldur sérsniðin vísbending frá þessu gerviforriti. Í CTF skiptir slíkur munur máli: óvenjulegur haus, kaka, athugasemd eða svarreitur getur verið viljandi slóð að næsta skrefi.

Biðlarinn er ekki þjónninn

HTML og JavaScript í vafranum ákveða hvernig síðan birtist og hvaða beiðnir viðmótið reynir að senda. Vefþjónninn ákveður hins vegar hvernig hann bregst við beiðninni sem raunverulega berst. Þessir tveir hlutar eru ekki sami staðurinn.

Hnappur getur verið falinn eða óvirkur í viðmótinu þótt slóðin á bak við hann sé enn aðgengileg. JavaScript getur líka neitað að senda tiltekið gildi án þess að þjónninn geri sömu athugun. Við eigum ekki að álykta strax að þar sé veikleiki, en við eigum að spyrja réttu spurningarinnar: hvað gerist ef ég sendi beiðnina sjálf(ur)?

Þess vegna eru vafraverkfæri, curl og Burp Suite svo gagnleg. Þau leyfa okkur að færa athyglina frá því sem viðmótið sýnir yfir á gögnin sem fara yfir mörkin milli biðlara og þjóns.

Þróunarverkfæri vafrans

Nútímavöfrum fylgja þróunarverkfæri vafra (e. browser developer tools eða DevTools). Þau voru smíðuð fyrir vefþróun og bilanagreiningu, en eru jafnframt fyrstu rannsóknarverkfæri margra vefverkefna.

Oft má opna þau með F12 eða Ctrl+Shift+I. Á macOS er algengt að nota Cmd+Option+I. Einnig má hægrismella á síðu og velja Inspect eða Skoða. Heiti flipa eru örlítið mismunandi milli vafra; Chromium-vafrar nota til dæmis Application þar sem Firefox notar oft Storage.

Network: sjáðu samtalið

Network-flipinn skráir netbeiðnir sem síðan sendir. Opnaðu hann áður en þú framkvæmir aðgerðina sem þú vilt rannsaka. Ef listinn er tómur skaltu endurhlaða síðuna, því verkfærin geta ekki alltaf sýnt beiðnir sem voru sendar áður en skráning hófst.

Farðu nú í Beiðnin týndist, opnaðu Network og hreinsaðu listann. Smelltu einu sinni á Sækja sendingu. Ein eða fleiri nýjar línur birtast. Finndu þá sem tengist augnablikinu þegar þú smelltir og skoðaðu hana.

Þegar beiðni er valin sérðu yfirleitt nokkur svæði:

• Headers sýnir slóð, aðferð og beiðni- og svarhausa.
• Payload eða Request sýnir gögn sem voru send með beiðninni.
• Response eða Preview sýnir svarlíkamann.
• Timing sýnir hvar tíminn fór, en það skiptir minna máli í þessu fyrsta verkefni.

Lestu ekki eingöngu það sem birtist á síðunni sjálfri. Skoðaðu bæði beiðnina og hráa svarið. Vafrinn getur hunsað svarhaus sem er samt mjög gagnlegur fyrir CTF-lausn.

Elements: sjáðu lifandi síðuna

Elements eða Inspector sýnir lifandi HTML-hlutalíkan síðunnar, DOM (e. Document Object Model). Þar má finna slóð í href, nafn á formreit, falinn reit eða data-*-gildi sem JavaScript notar. Leitin með Ctrl+F er gagnleg ef verkefnislýsingin nefnir ákveðið orð eða slóð.

Þú mátt breyta HTML í þessum flipa, en breytingin gerist aðeins í þínu eigin eintaki síðunnar. Ef þú eyðir disabled af hnappi hefurðu ekki breytt vefþjóninum. Þú hefur einungis blekkt vafrann til að leyfa smellinn. Það getur verið gagnlegt til að kalla fram beiðni, en svarið frá þjóninum segir hvort aðgerðin var í raun samþykkt.

Þá er einnig brýnt að rugla ekki View Source saman við Elements. Upprunakóðinn er HTML-svarið eins og það kom frá þjóninum. Elements sýnir stöðuna eftir að vafrinn og JavaScript hafa unnið úr svarinu. Munurinn getur sjálfur verið vísbending.

Console: tilraunaborð JavaScript

Console sýnir villur og skilaboð frá JavaScript og leyfir þér að keyra stuttar JavaScript-segðir í samhengi síðunnar. Til dæmis sýnir þetta núverandi slóð:

location.href

Eftirfarandi stef finnur síðan alla tengla sem eru á síðunni:

[...document.querySelectorAll("a")].map(a => a.href)

Þú þarft ekki að kunna mikið JavaScript enn. Notaðu Console fyrst og fremst til þess að lesa villur, skoða einföld gildi og staðfesta hvað síðan telur sig vera að gera. Ef Network sýnir enga beiðni þegar smellt er gæti Console sýnt að JavaScript hafi stöðvast með villu.

Storage: ástand sem vafrinn geymir

Storage eða Application sýnir meðal annars vefkökur, localStorage og sessionStorage. Slík gildi geta sagt þjóninum hvaða gervinotandi er skráður inn eða hvaða skrefi verkefnis er lokið.

Í þessum kafla þurfum við aðeins að vita að geymslan er til. Síðar skoðum við kökur og lotur vandlega. Mundu þó að lotukaka getur veitt aðgang að reikningi án þess að aðgangsorðið sé þekkt. Ekki birta raunverulegar kökur í skjáskoti eða lausnarskýrslu.

curl: beiðni sem hægt er að endurtaka

Vafrinn hentar vel til að uppgötva beiðnir. curl er gott til að endurtaka hana á skýran hátt úr skelinni.

Byrjum á fráteknu dæmaléni:

curl https://nordurmarkadur.example/sending

curl prentar sjálfgefið svarlíkamann. Valkosturinn -i lætur það einnig sýna svarhausana:

curl -i https://nordurmarkadur.example/sending

Til að bæta haus við beiðnina notum við -H:

curl -i -H 'X-Lab-Key: synidaemi' \
  https://nordurmarkadur.example/flag

Dæmalénið hér að ofan er ekki lifandi þjónusta og gildið synidaemi er ekki lausn verkefnisins. Þegar þú vinnur í Beiðnin týndist skaltu nota grunnslóð verkefnisins og aðeins það gildi haussins sem vísbendingar þess styðja.

Ef við viljum sjá nánar hvað curl gerir má nota -v:

curl -v https://nordurmarkadur.example/sending

Línur sem byrja á > lýsa beiðninni en línur sem byrja á < lýsa svarinu. -v getur birt kökur og auðkenningarhausa, svo ekki afrita allt úttakið hugsunarlaust í opinbera lausn.

Copy as cURL

Í Network-flipanum má yfirleitt hægrismella á beiðni og velja Copy as cURL. Þetta er fljótleg leið til að flytja beiðni úr vafranum yfir í skel. Skipunin getur orðið harla löng vegna þess að vafrinn sendir marga hausa.

Keyrðu fyrst afrituðu skipunina óbreytta og athugaðu hvort svarið sé sambærilegt. Fjarlægðu síðan einn óþarfan haus í einu. Góð CTF-lausn geymir minnstu beiðnina sem endurtekur hegðunina. Þannig sérðu hvaða gögn skipta máli í stað þess að bera með þér hundrað stafi sem vafrinn bætti sjálfkrafa við.

Burp Suite Community: halda beiðninni í höndunum

Burp Suite er safn verkfæra til að rannsaka vefumferð. Community-útgáfan nægir fyrir þessa leið. Hún getur staðið á milli vafrans og æfingaþjónsins, skráð beiðnir og leyft okkur að senda breytt eintak aftur.

Ákjósanlegasta byrjendaleiðin er innbyggði Burp-vafrinn. Opnaðu Burp, veldu tímabundið verkefni, farðu í Proxy og veldu Open browser. Þá þarf yfirleitt ekki að breyta milliþjónsstillingum eða vottorðum í aðalvafranum þínum.

Proxy og HTTP history

Undir Proxy sérðu HTTP history, sem er annar listi yfir beiðnir og svör. Hann líkist Network-flipanum, en skráningin tilheyrir Burp og beiðnir má senda beint áfram í önnur Burp-verkfæri.

Burp hefur einnig rofann Intercept is on/off. Þegar Intercept er virkt stöðvar Burp beiðnina og bíður eftir að þú veljir Forward eða Drop. Þetta er gagnlegt þegar breyta þarf beiðni áður en hún fer til þjónsins, en í fyrsta verkefninu er einfaldara að hafa Intercept stillt á **off**, hafa uppi á beiðninni í HTTP history og vinna með afrit. Ef síða virðist hanga í Burp-vafranum skaltu fyrst athuga hvort beiðni bíði í Intercept.

Repeater

Repeater er tilraunaborð fyrir eina beiðni. Finndu /sending-beiðnina í HTTP history, hægrismelltu og veldu Send to Repeater. Þar sérðu beiðnina vinstra megin og getur ýtt á Send eins oft og þú þarft. Svarið birtist hægra megin.

Gerðu eina breytingu í einu. Bættu til dæmis við einum haus, sendu og berðu nýja svarið saman við það fyrra. Ef slóð, aðferð, köku og þremur hausum er breytt samtímis verður ómögulegt að segja til um hvaða breyting skipti raunverulega máli.

Göngudæmi: finnum týndu beiðnina

Nú skulum við tengja verkfærin saman án þess að gefa upp fánann.

Opnaðu fyrst Beiðnin týndist í venjulegum vafra eða Burp-vafranum. Kveiktu á Network eða HTTP history, hreinsaðu eldri færslur og smelltu einu sinni á Sækja sendingu. Skráðu slóðina, beiðniaðferðina og stöðukóðann. Skoðaðu síðan svarlíkamann og svarhausana. Þú ættir að geta sett fram nákvæmari tilgátu en „eitthvað með haus“: hvaða slóð þarf næst beiðni og hvað heitir hausinn sem þjónninn býst við?

Endurtaktu /sending-beiðnina óbreytta í Repeater eða með curl -i. Ef svarið er það sama hefur þér tekist að búa til endurtakanlega grunnbeiðni. Notaðu þá vísbendinguna í svarinu til að smíða næstu beiðni. Breyttu aðeins slóðinni og þeim eina haus sem verkefnið gefur tilefni til. Þegar þjónninn svarar öðruvísi skaltu bera svörin saman áður en þú prófar næsta gildi.

Ef þú festist skaltu fara aftur um eitt skref fremur en að giska hraðar:

1. Staðfestu að þú sért á réttu verkefnisléni.
2. Athugaðu hvort þú sért að lesa svarhausa, ekki aðeins beiðnihausa.
3. Endursendu óbreytta grunnbeiðni og staðfestu að hún virki enn.
4. Bættu síðan aðeins vísbendingarhausnum við.

Þetta er einfalt verkefni, en vinnuferlið skiptir meira máli en fáninn. Þú fannst aðgerð í viðmótinu, sást HTTP-samtalið, dróst út vísbendingu og smíðaðir sjálf(ur) nýja beiðni.

Staðbundið æfingaumhverfi

Þegar við viljum aðeins æfa curl þurfum við ekki ytri þjónustu. Python getur þjónað skrá úr möppu á tölvunni okkar:

mkdir -p ~/vef-aefing
printf '<h1>Halló frá vefþjóni</h1>\n' > ~/vef-aefing/index.html
cd ~/vef-aefing
python3 -m http.server 8000 --bind 127.0.0.1

Skipunin heldur áfram að keyra. Opnaðu annan skeljaglugga og sæktu síðuna:

curl -i http://127.0.0.1:8000/

--bind 127.0.0.1 lætur þjóninn aðeins hlusta á tengingar frá sömu tölvu. Án þess gæti þjónninn hlustað á fleiri netviðmót og orðið sýnilegur öðrum tækjum á sama neti. Ef tengið 8000 er frátekið má velja annað hátt tengi, til dæmis 8001, í báðum skipunum. Stöðvaðu þjóninn með Ctrl+C þegar æfingunni lýkur.

Prófaðu að breyta index.html, sækja aftur og skoða hvaða hlutar svarsins breytast. Þú getur einnig opnað http://127.0.0.1:8000/ í vafra og fundið beiðnina í Network. Þannig sérðu sama samtal með þremur sjónarhornum: vafranum, curl og úttaki staðbundna þjónsins.

Þegar verkfæri sýna ekki það sem þú bjóst við

Góð rannsókn snýst ekki um að eitt tól varpi strax fram réttu svari. Ef hnappur býr ekki til nýja Network-færslu gæti aðgerðin aðeins hafa breytt DOM í vafranum. Ef curl fær 401 eða 403 en vafrinn fær 200 vantar líklega gögn sem tengjast auðkenningu eða lotu. Ef Burp-vafrinn bíður endalaust gæti Intercept haldið beiðninni.

Stöðukóðar og villur eru ekki endapunktur rannsóknarinnar. Þeir eru mælistikur á ástand. Skráðu hjá þér hvað þú sendir, hvað þú bjóst við og hvað kom til baka. Breyttu síðan einu atriði. Þessi einfalda regla sparar ómældan tíma þegar verkefnin verða flóknari.

Hvert förum við næst?

Nú kanntu að finna beiðni í Network, skoða lifandi síðu í Elements, lesa JavaScript-villur í Console, finna vafrageymslu, endurtaka beiðni með curl og færa hana í Burp Repeater. Lykilatriðið er þó að þú farir að líta á vefsíður ekki lengur sem einn skjá, heldur sem röð beiðna og svara sem hægt er að rannsaka.

Í næsta kafla tökum við HTTP-samtalið í sundur. Við skoðum nákvæmlega hvernig slóðir, aðferðir, stöðukóðar, hausar, líkamar, kökur og kóðun virka. Þá verður auðveldara að vita hvaða hluta beiðninnar á að breyta — og hvaða hlutar eru aðeins hávaði.