Kas teid rünnatakse? Võtke ühendust intsidentidele reageerimise meeskonnaga

Turvaline arendus

Sessioonihalduse kontrollid: küpsised, aegumine ja väljalogimine

Veebisessioonide testimise kontrollnimekiri: ID tugevus, küpsised, ID vahetus sisselogimisel, aegumine, väljalogimine ja curl-käsud.

Saadaval ka:EnglishTürkçeDeutschFrançaisEspañolItalianoPolskiNederlands

Illustratsioon: Sessioonihalduse kontrollid: küpsised, aegumine ja väljalogimine

Kui kasutaja on sisse loginud, on sessiooni ID ajutiselt samaväärne tugevaima autentimismeetodiga, mida rakendus kasutas, olgu selleks parool, ühekordne kood, kliendisertifikaat, kiipkaart või sõrmejälg. Kui ründaja suudab selle ID ära arvata, kinni püüda või ette sööta, on tema see kasutaja ning sisselogimisvormi pole tal vaja. Sessioonide testimine tähendab seega ID, seda kandva küpsise ja serveri tegevuse kontrollimist sisselogimisel, tegevusetuse korral ja väljalogimisel.

See kontrollnimekiri põhineb dokumentidel OWASP Session Management Cheat Sheet ja RFC 6265, mis on küpsiste spetsifikatsioon.

Sessiooni ID ise

Alustage sellest, kuidas ID luuakse. Cheat Sheet nõuab vähemalt 64 bitti entroopiat krüptograafiliselt turvalisest juhuarvugeneraatorist. Selle suuruse korral hinnatakse kehtiva ID äraarvamiseks kuluvaks umbes 585 aastat, eeldusel et pakkumisi tehakse 10 000 sekundis ja korraga on aktiivseid sessioone 100 000. Kui genereerite ID-sid ise, selle asemel et kasutada raamistiku oma, soovitatakse vähemalt 128 bitti ja iga sessiooni jaoks unikaalset väärtust.

Otsige fikseeritud või ennustatavaid osi. 16-märgilisel kuueteistkümnendsüsteemis ID-l, mille pool on fikseeritud, on entroopiat vaid 32 bitti, mis ei ole piisav. Väärtus ei tohi kliendile ka midagi tähendada: selle sees ei tohi olla kasutaja ID-d, rolli ega e-posti aadressi. Hoidke see olek serveris.

Kontrollige ka nime. Vaikenimed nagu PHPSESSID, JSESSIONID, CFID/CFTOKEN ja ASP.NET_SessionId annavad ründajale teada, millist tehnoloogiapaketti te kasutate. Cheat Sheet soovitab üldist nime, näiteks id.

Ärge kunagi aktsepteerige ID-d URL-is. URL-is olevad ID-d lekivad linkide, logide, brauseriajaloo, järjehoidjate, Referer-päise ja otsingumootorite kaudu ning need teevad sessiooni fikseerimise lihtsamaks.

Kui teie ohumudelis on sessioonihoidla lugemisjuurdepääs, on toortokenid risk. Cheat Sheet kirjeldab jaotatud lahendust: küpsis kannab identifikaatorit ja salajast verifierit, server aga salvestab identifikaatori ning verifieri SHA-256 räsi, mida võrreldakse konstantse ajaga. Identifikaatorit üksi ei aktsepteerita kunagi.

Küpsiste atribuudid

RFC 6265 määratleb Set-Cookie päise jaoks järgmised atribuudid: Expires, Max-Age, Domain, Path, Secure ja HttpOnly.

  • Secure märgib küpsise kasutamiseks turvaliste ühendustega. RFC hoiatab, et see ei taga terviklust aktiivse võrguründaja vastu, seega ärge käsitlege seda kaitsena tema eest.
  • HttpOnly peab olema igal sessiooniküpsisel. Kontrollige lippu brauseri arendajatööriistades.
  • Domain ja Path määravad ulatuse. Hoidke mõlemad mitte laiemad, kui rakendus vajab.
  • Expires ja Max-Age ütlevad brauserile, kui kaua küpsist hoida. Ärge kasutage neid oma aegumisena.

Vaadake ülejäänud vastusepäised üle meie turvapäiste tööriistaga.

Sisselogimine, aegumine ja väljalogimine

Sessiooni ID, mis oli brauseril enne sisselogimist ja jääb alles ka pärast seda, on see, millele fikseerimisrünnakud tuginevad. Väljastage kasutaja autentimisel uus ID, et eelmine muutuks kehtetuks.

Aegumisel on vaja kahte piirangut. Tegevusetuse aegumine (idle timeout) lõpetab sessioonid, mida keegi ei kasuta. Absoluutne aegumine (absolute timeout) lõpetab sessioonid, mis püsivad aktiivsena lõputult, ning piirab seega, kui kaua varastatud ID kasulik on. Kirjutage numbrid üles, tehke need halduse ja maksete jaoks lühemaks ning jõustage need serveris, kontrollides salvestatud sessioonikirjet, mitte küpsise aegumiskuupäeva.

Väljalogimine peab hävitama serveripoolse sessiooni. Küpsise kustutamisest brauseris ei piisa, sest identifikaator ongi mandaat: igaüks, kes selle varem kopeeris, saab seda ikka saata. Pärast väljalogimist ei tohi vana ID viidata millelegi. Cheat Sheetis on ka jaotis veebisisu vahemällu salvestamise ja Clear-Site-Data kohta, mida tasub lugeda, et teada saada, mida brauser pärast väljalogimist alles hoiab.

Kasutage võimaluse korral raamistiku sisseehitatud sessioonihaldust. Cheat Sheet märgib, et nendes teostustes on esinenud haavatavusi, seega kasutage uusimat versiooni ja vaadake vaikeseaded üle.

Mida testida

  1. Püüdke küpsis kinni enne ja pärast sisselogimist. Esimene päring peab tõepoolest sessiooniküpsise seadma, seega kontrollige, et before.txt ei ole tühi. Hoidke mandaate failis (creds.txt, mis sisaldab user=test&pass=...), et need ei jääks käsuajalukku. Kaks ID-d peavad erinema.

curl -i -c before.txt https://app.example/login curl -i -b before.txt -c after.txt -d @creds.txt https://app.example/login

  1. Logige välja autenditud küpsisega ja saatke seejärel vana väärtus uuesti, võttes selle faili after.txt viimasest veerust. See peab olema tagasi lükatud. Kui väljalogimine on POST, lisage esimesele käsule -d ''.

curl -i -b after.txt https://app.example/logout curl -i -b 'id=VALUE_FROM_AFTER_TXT' https://app.example/account

  1. Logige sisse, olge tegevusetu kauem kui tegevusetuse aegumine lubab, ja saatke siis päring. See peab nõudma uuesti autentimist.
  2. Hoidke sessioon aktiivsena üle absoluutse aegumise. See peab ikkagi lõppema.
  3. Vaadake sisselogimisvastuse Set-Cookie päisest, kas seal on Secure, HttpOnly ning Domain ja Path mitte laiemad, kui vaja.
  4. Koguge paarsada ID-d ja võrrelge neid. Fikseeritud lõigud ja järjestikused väärtused on leiud. Kontrollige küpsise nime ülaltoodud raamistike vaikenimede vastu.
  5. Otsige rakendusest, logidest ja linkidest sessiooni ID-sid URL-idest.

Esitage leiud OWASP ASVS-i suhtes koos versiooniga: v5.0.0-<chapter>.<section>.<requirement>. ASVS 5.0.0 avaldati 30. mail 2025 ja selle nõuded on saadaval CSV-vormingus. Lisage oma testitabelisse veerg iga testi identifikaatoriga, et ebaõnnestunud test oleks leid, mis viitab oma nõudele.

Kust alustada

  1. Käivitage testid 1 ja 2 esmalt staging-keskkonnas: ID võrdlus enne ja pärast sisselogimist ning seejärel väljalogimise kordusülesanne.
  2. Püüdke oma sessiooniküpsise Set-Cookie päis kinni ning parandage puuduvad või liiga laiad atribuudid.
  3. Kontrollige, kuidas ID-sid genereeritakse. Kui olete ehitanud oma generaatori, minge üle raamistiku omale või veenduge, et see kasutab turvalist juhuallikat vähemalt 128 bitiga.
  4. Kirjutage üles tegevusetuse ja absoluutne aegumine, jõustage need serveris ning lisage testid, mis kukuvad läbi, kui keegi need eemaldab.
  5. Tehke nii, et väljalogimine kustutab serveripoolse sessioonikirje, ning lisage kordustestid oma regressioonikomplekti.

Kuidas saame aidata

Läbistustestimine

Ründame teie võrke, rakendusi ja inimesi nagu päris vastane ning näitame, kuidas iga turvaauk sulgeda.

Turvapäiste skanner

Hinnake veebisaidi HTTP-turvapäiseid, küpsiseid ja TLS-sertifikaati ning saage iga leiu kohta parandus.

Kirjutage meile
AngelForce’i meeskond

Kirjutanud AngelForce’i meeskond: CEH-, LPT Masteri ja CISA-sertifikaadiga turvakonsultandid, kes testivad, jälgivad ja kaitsevad organisatsioonide süsteeme kogu Euroopas.

Artikkel on kirjutatud tehisintellekti abil allpool loetletud avalike allikate põhjal ning AngelForce’i meeskond vaatas selle enne avaldamist üle.

Allikad

  1. cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
  2. www.rfc-editor.org/rfc/rfc6265.html
  3. asvs.owasp.org/

Artiklid teemal „Turvaline arendus“

Rääkige meile, mida soovite kaitsta

Kirjeldage oma keskkonda ja seda, mida soovite saavutada. Vastame e-posti teel.

Kirjutage meile
info@angelforce.eu +372 5705 2044

AngelForce OÜ · Tallinn, Eesti