Ano ang Session Hijacking? Paano Ito Gumagana at Paano Ito Pipigilan

Ang isang matagumpay na pag-login ay hindi palaging nangangahulugan na ang isang account ay nananatiling ligtas. Nangyayari ang session hijacking kapag ang isang attacker ay nakakuha ng hindi awtorisadong access sa isang authenticated session, kadalasan sa pamamagitan ng pagnanakaw ng session cookie o token. Kung tatanggapin ng application ang ninakaw na sikreto, maaaring makakuha ng access ang attacker nang hindi inilalagay ang password ng user o kinukumpleto ang isa pang multi-factor authentication (MFA) challenge.

Para sa mga IT at security team, ginagawa nitong mahalaga ang pagprotekta sa access na lampas sa unang pag-sign-in. Kailangan nilang maunawaan kung paano nalalantad ang mga sikreto ng session, kilalanin ang kahina-hinalang aktibidad, at tumugon sa mga nakompromisong session.

Ipinapaliwanag ng gabay na ito kung paano gumagana ang session hijacking, mga karaniwang pamamaraan ng pag-atake, at mga praktikal na paraan upang maiwasan, matukoy, at matugunan ang mga pag-atakeng ito.

Ano ang session hijacking?

Ang session hijacking ay ang hindi awtorisadong paggamit ng isang wastong session secret—tulad ng browser session cookie o bearer token—upang magpanggap na isang authenticated user. Kung tatanggapin ng isang application ang ninakaw na sikreto, maaaring kumilos ang isang attacker bilang user nang hindi inilalagay ang password ng user o kinukumpleto ang isang bagong multi-factor authentication (MFA) challenge.

Ang session hijacking ay naiiba sa pagnanakaw ng kredensyal. Ang mga ninakaw na kredensyal ay makakatulong sa isang umaatake na magtatag ng isang bagong sesyon. Ang isang ninakaw na lihim ng sesyon ay nagbibigay-daan sa isang umaatake na muling gamitin ang isang umiiral nang napatunayang estado. Ang epekto ay nakasalalay sa mga pahintulot, saklaw, natitirang buhay ng lihim, at kung ang serbisyo ay makaka-detect o makaka-block ng replay.

Paano gumagana ang isang session hijacking attack?

Mula sa pag-login at pag-isyu ng session ID hanggang sa pagnanakaw ng token at pag-replay

Ang isang normal na sesyon sa web ay karaniwang sumusunod sa ganitong pagkakasunod-sunod:

1. Nag-a-authenticate ang user gamit ang password, passkey, MFA, o iba pang aprubadong pamamaraan.
2. Ang application o identity provider ay naglalabas ng session secret. Sa isang browser, ito ay karaniwang isang opaque identifier na nakaimbak sa isang cookie. Sa OAuth mga deployment, ang isang kliyente ay maaari ring makatanggap ng mga access token at, kung naaangkop, mga refresh token. Ang mga artifact na ito ay may iba't ibang layunin at gawi sa pagbawi.
3. Ipapakita ng browser o client ang kaugnay na sikreto gamit ang mga kahilingan sa ibang pagkakataon.
4. Sinusuri ng server kung ang session o token ay nananatiling balido at tinutukoy kung ano ang maaaring ma-access ng user.
5. Nagtatapos ang sesyon kapag ito ay nag-expire, nag-log out ang user, o kapag pinawalang-bisa ito ng isang administrator o system.

Nangyayari ang session hijacking kapag kinukuha o kinokontrol ng isang attacker ang isang session secret at ipinapakita ito habang itinuturing pa rin itong balido ng serbisyo. Inilalarawan ng NIST ang authenticated session continuity bilang batay sa pagkakaroon ng isang session secret. Patnubay sa pamamahala ng sesyon ng OWASP nagpapaliwanag kung paano maaaring humantong sa pagpapanggap ang pagbubunyag, prediksyon, brute force, o pag-aayos ng isang identifier.

Ang browser session cookie, OAuth access token, at refresh token ay hindi maaaring palitan:

• Cookie ng session: Karaniwang kinikilala ang isang na-authenticate na sesyon ng browser. Inima-map ng application ang identifier sa estado ng server-side o pinapatunayan ang isang protektadong cookie.
• Token ng pag-access: Pinahihintulutan ang pag-access sa isang partikular na API o resource server, napapailalim sa audience, mga pahintulot, at saklaw nito.
• I-refresh ang token: Pinapayagan ang isang kliyente na humiling ng mga bagong access token. Ang mas mahabang kapaki-pakinabang na buhay nito ay maaaring maging lalong mahalaga ang kompromiso.

Ang pagpapawalang-bisa ng isang sesyon ng browser ay hindi nangangahulugang pagpapawalang-bisa ng isang OAuth refresh token. Gayundin, ang pagpapalit ng password ay hindi nangangahulugang nagpapawalang-bisa sa mga umiiral na sesyon o token maliban kung ang application o identity provider ay idinisenyo para gawin ito.

Ano ang magagawa ng isang umaatake sa isang tinanggap na sesyon

Ang isang tinanggap na sesyon ay maaaring magpahintulot sa isang umaatake na magsagawa ng mga aksyon na magagamit ng user na iyon sa apektadong application. Depende sa account at application, maaaring kabilang dito ang pagtingin sa data, pagbabago ng mga setting, paglikha ng mga access key, pagbabago ng impormasyon sa pagbawi, o pagsisimula ng mga aksyong administratibo.

Hindi awtomatikong nagbibigay ng access ang kompromiso sa bawat konektadong serbisyo. Ang abot ay nakadepende sa uri ng artifact, audience, saklaw, mga pahintulot, disenyo ng federasyon, at ang gawi ng sesyon ng bawat konektadong application. Halimbawa, ang isang ninakaw na cookie para sa isang application ay maaaring hindi magamit laban sa isang hiwalay na serbisyo ng SaaS.

Mga karaniwang paraan ng pagkuha o pagkontrol ng mga attacker sa mga sesyon

XSS, phishing, mga nakalantad na token, at malware

Magkakaiba ang mga path ng pagkuha ng session, kaya nangangailangan ang mga ito ng iba't ibang kontrol:

• Pag-script sa iba't ibang site (XSS): Ang injected code ay maaaring magnakaw ng token na naa-access ng JavaScript o magsagawa ng mga aksyon sa pamamagitan ng authenticated browser ng biktima. Pinipigilan ng HttpOnly cookie ang direktang pag-access ng JavaScript sa cookie na iyon, ngunit hindi nito ginagawang immune ang isang application sa XSS.
• Mga Token sa mga URL: Ang isang session identifier sa isang query string o iba pang bahagi ng URL ay maaaring lumitaw sa kasaysayan ng browser, mga bookmark, mga log ng server at proxy, data ng referrer, o pag-index ng paghahanap. Inirerekomenda ng OWASP ang cookies sa halip na palitan ng sesyon na nakabatay sa URL para sa mga normal na sesyon sa web.
• Hindi naka-encrypt na trapiko: Kung walang Transport Layer Security (TLS), maaaring maharang ng isang tagamasid sa network ang data ng sesyon habang inililipat. Pinoprotektahan ng HTTPS ang landas na ito kapag wastong na-deploy.
• Pagkompromiso ng malware o device: Maaaring ma-access ng malisyosong software ang mga database ng cookie ng browser, memorya ng proseso ng browser, o iba pang imbakan ng application. Mga dokumento ng MITRE ATT&CK ang mga ito bilang mga itinatag na pamamaraan para sa pagnanakaw ng mga web session cookies.
• Mga artifact ng sesyon na nakuha habang o pagkatapos ng pagpapatotoo: Maaaring ma-replay ito ng isang attacker na nakakuha ng isang valid na session artifact nang walang isa pang MFA prompt. Hindi dahil sa Login MFA mismo, hindi maaaring i-replay ang isang kasunod na inisyu na bearer session artifact.
• Phishing na Kalaban-sa-gitna (AiTM): Maaaring makuha ng isang phishing proxy na kontrolado ng attacker ang mga session cookies habang isinasagawa ang isang lehitimong proseso ng pagpapatotoo. Kung makumpleto ng user ang authentication at ang resultang cookie ay magagamit muli, maaaring gamitin ito ng attacker upang ma-access ang apektadong application nang hindi inuulit ang proseso ng pag-login. Ito ang dahilan kung bakit dapat tugunan ng mga organisasyon ang pagnanakaw ng session bilang karagdagan sa phishing ng kredensyal.

Mahalaga ang HTTPS, ngunit pinoprotektahan nito ang koneksyon sa halip na sa bawat lugar na maaaring malantad ang isang sikreto. Hindi nito itinatama ang kahinaan ng isang XSS, inaalis ang malware, pinipigilan ang pag-log ng isang token, o ginagawang hindi maaaring i-replay ang isang ninakaw na bearer token.

Pag-aayos ng sesyon at mga nahuhulaang pagkakakilanlan

Hindi kinakailangan ng session fixation na nakawin ng attacker ang isang bagong generated na identifier. Sa halip, hinihikayat o hinihikayat ng attacker ang application na gumamit ng isang identifier na alam na ng attacker, pagkatapos ay hinihintay na mag-authenticate ang biktima gamit ito.

Dapat mag-isyu ang mga aplikasyon ng bagong session identifier pagkatapos ng authentication at pagkatapos ng makabuluhang mga pagbabago sa pribilehiyo. Dapat din nilang tanggihan ang mga identifier na hindi nila nabuo sa halip na tanggapin ang mga arbitraryong halaga ng session na ibinigay ng isang client. Madalas itong tinatawag na mahigpit na pamamahala ng session.

Ang mga session identifier ay dapat mabuo gamit ang isang cryptographically secure na random source at magbigay ng sapat na entropy upang maiwasan ang panghuhula. Dapat din itong maging opaque: ang data ng negosyo, mga detalye ng account, mga pahintulot, at iba pang sensitibong estado ay hindi dapat malantad sa pamamagitan mismo ng identifier.

Paano maiwasan ang session hijacking

Ang mabisang pag-iwas ay nagpoprotekta sa sikreto ng sesyon, naglilimita kung gaano katagal ito mananatiling kapaki-pakinabang, at binabawasan ang bilang ng mga lugar kung saan ito maaaring nakawin. Walang iisang kontrol ang tumutugon sa bawat landas ng pag-atake.

Protektahan ang mga cookies, koneksyon, at ang lifecycle ng session

Gumamit ng HTTPS sa buong napatotohanang karanasan, hindi lamang sa pahina ng pag-login. I-configure ang mga cookie ng sesyon ng browser gamit ang mga katangiang naaangkop sa application:

• Nililimitahan ng Secure ang cookie sa mga koneksyon sa HTTPS.
• Pinipigilan ng HttpOnly ang JavaScript na direktang basahin ang cookie kapag hindi kinakailangan ang pag-access sa script.
• Kinokontrol ng SameSite ang ilang gawi sa pagpapadala ng cross-site cookie at maaaring mabawasan ang ilang panganib sa cross-site request. Ang tamang halaga ay nakasalalay sa lehitimong daloy ng pagpapatotoo at integrasyon.
• Nababawasan ang mga halaga ng Restricted Domain at Path kung saan ipinapadala ng browser ang cookie.
• Ang mga prefix na __Host- at __Secure- cookie ay nagpapatupad ng mga karagdagang paghihigpit sa antas ng browser. Kinakailangan ng __Host- ang Secure attribute, Path=/, at no Domain attribute, habang kinakailangan naman ng __Secure- ang Secure attribute. Ang parehong prefix ay nangangailangan na ang cookies ay nakatakda mula sa isang secure na pinagmulan.

Gabay sa ligtas na cookie ng MDN ipinapaliwanag ang mga katangian at unlapi na ito. Binabawasan nito ang mga partikular na exposure ngunit hindi pinoprotektahan ang isang sesyon mula sa bawat kompromiso sa aplikasyon o endpoint.

Iwasang maglagay ng mga sikreto ng sesyon sa mga URL. Huwag ilantad ang mga ito sa mga analytics event, diagnostic output, mga log ng application, mga ulat ng error, o client-side code nang walang dokumentadong pangangailangan. Kung saan ang isang sikreto ng sesyon ng browser ay hindi nangangailangan ng access sa JavaScript, mas mainam ang isang protektadong cookie kaysa sa storage na naa-access ng JavaScript.

Ang server—hindi lang ang browser—ang dapat magpatupad ng session lifecycle:

• I-rotate ang session identifier pagkatapos ng mga pagbabago sa authentication at privilege.
• Ipatupad ang idle at absolute expiration sa server.
• I-invalidate ang server-side session kapag nag-log out ang user.
• Suportahan ang administratibong pagbawi para sa pagtugon sa insidente.
• Muling i-authenticate ang user bago ang mga sensitibong aksyon kapag nararapat lamang ang panganib.
• Panatilihing hindi mas malawak kaysa sa kinakailangan ang mga pahintulot sa sesyon at saklaw ng token.

Walang pangkalahatang timeout na angkop para sa bawat aplikasyon. Ang isang administrator console na humahawak ng sensitibong data ay maaaring mangailangan ng mas maiikling session kaysa sa isang low-risk na serbisyo. Magtakda ng mga limitasyon sa paggamit at ganap na paggamit ayon sa mga kahihinatnan ng walang nagbabantay o ninakaw na access, pagkatapos ay isaalang-alang ang usability at mga pangangailangan sa pagpapatakbo.

Para sa mga sistemang OAuth 2.0, RFC 9700 Nagrerekomenda ng mga access token na nililimitahan ng nagpadala upang mabawasan ang maling paggamit ng mga ninakaw na token. Kapag ang isang authorization server ay nag-isyu ng mga refresh token sa mga pampublikong kliyente, hinihiling ng detalye ang mga refresh token na nililimitahan ng nagpadala o pag-ikot ng refresh-token upang matukoy ang replay. Ang mga hakbang na ito ay kumukumpleto sa mga kontrol ng session ng aplikasyon at nagse-secure ng cookie handling sa halip na palitan ang mga ito.

Bawasan ang pagkakalantad sa endpoint at maglapat ng mga naaangkop na kontrol sa pag-access

Ang pagpigil sa pagnanakaw ng sesyon ay nangangailangan din ng mga kontrol sa labas ng tindahan ng sesyon:

• Tugunan ang XSS sa pamamagitan ng ligtas na paghawak ng output, ligtas na paggamit ng framework, naaangkop na mga kontrol sa nilalaman, at disiplinadong pagsubok.
• Panatilihing naka-patch ang mga browser, application framework, dependencies, at endpoint software.
• Paghigpitan ang mga hindi aprubadong extension ng browser kung saan pinamamahalaan ng organisasyon ang endpoint.
• Gamitin ang seguridad at pagsubaybay ng endpoint upang matukoy ang kahina-hinalang pag-access sa imbakan ng browser o memorya ng proseso.
• Maglapat ng mga kontrol sa pag-access na nakabatay sa panganib o may kamalayan sa device kung saan ang mga hindi pinamamahalaang endpoint ay lumilikha ng hindi katanggap-tanggap na pagkakalantad.
• Mabilis na imbestigahan ang pinaghihinalaang phishing, mga malisyosong extension, at mga alerto sa endpoint.

Ang mahigpit na pagbubuklod ng isang sesyon sa isang IP address ay bihirang maging kumpletong sagot. Ang mga VPN, mobile network, carrier-grade NAT, mga proxy, at mga ordinaryong pagbabago sa network ay maaaring magpabago sa address ng isang lehitimong user. Ang mga katangian ng IP at device ay mas kapaki-pakinabang bilang mga senyales ng panganib na sinamahan ng iba pang ebidensya.

Itugma ang bawat kontrol sa landas ng pag-atake na tinutugunan nito

Paano i-verify ang mga depensa ng sesyon

Dapat subukan ang mga kontrol ng sesyon sa isang awtorisadong kapaligiran gamit ang mga test account at isang dokumentadong saklaw ng pagtatasa. Ang pagsusuri ng configuration lamang ay maaaring makaligtaan ang mga pagkabigo sa lifecycle.

Siyasatin ang mga katangian ng cookie at tingnan kung may mga token sa mga URL

Gumamit ng mga tool ng developer ng browser at mga aprubadong tool sa pag-inspeksyon ng trapiko upang suriin ang na-authenticate na daloy:

• Kumpirmahin na ang mga session cookies ay mayroong mga nilalayong katangiang Secure, HttpOnly, at SameSite.
• Suriin kung ang Domain at Path ay mas malawak kaysa sa kinakailangan.
• Tiyakin na ang mga sikreto ng sesyon ay hindi lumalabas sa mga URL, pinagmulan ng pahina, mga tawag sa analytics, mga log sa panig ng kliyente, o data ng referrer.
• Suriin ang mga log ng server, reverse proxy, load balancer, at application para sa aksidenteng pagkuha ng token.
• Tukuyin kung ang mga bearer o refresh token ay nakaimbak kung saan maaaring ma-access ng mga hindi kaugnay na script o application ang mga ito.

Dapat suriin ang mga katangian ng cookie laban sa aktwal na disenyo ng application. Halimbawa, ang pagpapalit ng SameSite nang hindi sinusubukan ang isang lehitimong federasyon o cross-site workflow ay maaaring makasira sa authentication nang hindi tinutugunan ang pangunahing theft path.

Pag-rotate, pag-expire, pag-logout, at pag-invalidate ng Test ID

Dapat patunayan ng isang nakatutok na sesyon ng pagsubok ang mga pag-uugaling ito:

1. Pag-ikot ng pagpapatunay: Paghambingin ang identifier bago at pagkatapos mag-login. Ang na-authenticate na sesyon ay hindi dapat magpatuloy gamit ang isang pre-login identifier na kilala ng attacker.
2. Pag-ikot ng pagbabago ng pribilehiyo: Kumpirmahin ang pagtataas ng tungkulin o iba pang makabuluhang pahintulot mga resulta ng pagbabago sa naaangkop na pag-renew ng sesyon.
3. Pag-expire nang walang ginagawa: Hayaang hindi aktibo ang sesyon nang lampas sa na-configure na limitasyon, pagkatapos ay i-verify na tinatanggihan ito ng server.
4. Ganap na pag-expire: Panatilihing aktibo ang isang sesyon at kumpirmahin na nagtatapos pa rin ito sa pangkalahatang limitasyon.
5. Pagpapawalang-bisa ng pag-logout: Mag-log out, pagkatapos ay subukang i-replay ang artifact ng nakaraang session. Hindi ito dapat tanggapin ng isang pahinang kritikal sa seguridad.
6. Pagpapawalang-bisa sa administrasyon: Bawiin ang sesyon sa pamamagitan ng sinusuportahang proseso ng pagtugon sa insidente at beripikahin na nawawalan ng access ang lumang artifact kung saan pinahihintulutan ng arkitektura.
7. Paghawak ng kaugnay na token: Suriin kung ang pag-logout o pagpigil sa account ay nagpapawalang-bisa rin sa mga refresh token, mga natatandaang kredensyal ng device, at iba pang aktibong sesyon gaya ng nilalayon.

Gabay sa pagsubok ng OWASP Binibigyang-diin nito ang pagpapatupad ng timeout sa server-side at wastong pagpapawalang-bisa ng sesyon habang nagla-logout. Hindi sapat ang pagtanggal ng browser sa lokal na cookie nito kung tinatanggap pa rin ng server ang isang kinopyang halaga.

Para sa federated SSO, aplikasyon sa pagsubok at identity provider (IdP) mga sesyon nang hiwalay. Tiyakin na ang pag-logout ay nagpapawalang-bisa sa nakaraang sesyon ng aplikasyon, pagkatapos ay suriin kung ang isang aktibong sesyon ng IdP ay maaaring magtatag ng isang bagong sesyon ng aplikasyon nang walang bagong pagpapatotoo.

Paano matukoy ang isang posibleng na-hijack na sesyon

Suriin ang isang hindi pangkaraniwang kaganapan sa sesyon batay sa mga hindi kapani-paniwalang paliwanag at mga nagpapatunay na ebidensya

Ang binagong IP address o geolocation ay isang senyales, hindi patunay ng kompromiso. Ang lehitimong paglalakbay, paggamit ng VPN, mga mobile network, mga proxy, mga update sa browser, at mga tool sa privacy ay maaaring magdulot ng mga katulad na pagbabago.

Suriin ang mga kahina-hinalang sesyon sa pamamagitan ng pag-uugnay ng maraming mapagkukunan ng ebidensya:

• May lilitaw na bagong browser o device habang may umiiral na session.
• Ginagamit ng malalayong lokasyon ang parehong sesyon sa loob ng hindi kapani-paniwalang maikling panahon.
• Ang application ay nakakakita ng mga hindi pangkaraniwang user agent, abnormal na timing, o hindi inaasahang paggamit muli ng token.
• Ang mga sensitibong aksyon ay hindi tumutugma sa normal na aktibidad ng gumagamit.
• Ang mga log ng identity provider at application ay nagpapakita ng hindi pare-parehong authentication at mga session event.
• Nag-uulat ang user ng kahina-hinalang pahina sa pag-sign-in, hindi inaasahang kaganapan ng MFA, o hindi pamilyar na aktibidad ng account.
• Ipinapakita ng endpoint telemetry ang kahina-hinalang pag-access sa mga database ng browser cookie o memorya ng proseso ng browser.
• Lumilitaw ang mga bagong sesyon, integrasyon, setting ng pagbawi, o pagbibigay ng pahintulot nang walang inaasahang pagbabagong administratibo.

NIST SP 800-63B Tinutukoy ang kilos, tiyempo, mga katangian ng browser at device, geolocation, at mga katangian ng IP bilang mga posibleng input sa pagsubaybay sa sesyon. Gamitin ang mga signal na ito upang magtatag ng panganib at mag-trigger ng imbestigasyon o muling pagpapatunay sa halip na ituring ang anumang isang katangian bilang kapani-paniwala.

Ano ang gagawin kapag pinaghihinalaang may session hijacking

Bawiin ang mga apektadong sesyon, siyasatin ang path ng pagkuha, at suriin ang kaugnay na access

Unahin ang pag-contain ng active access, pagkatapos ay tukuyin kung paano nakuha ang session:

1. Bawiin ang apektadong sesyon. Bawiin ang mga kaugnay na refresh token at iba pang aktibong sesyon kapag kinakailangan ito ng panganib o kawalan ng katiyakan.
2. Itago ang account. Pansamantalang huwag paganahin ang access o humingi ng muling pagpapatotoo kung ang umaatake ay maaaring aktibo pa rin o hindi tiyak ang saklaw ng pagbawi.
3. Pangalagaan ang ebidensya. Panatilihin ang identity provider, application, proxy, endpoint, at mga audit log bago alisin ang mga ito sa normal na pagpapanatili o paglilinis.
4. Tukuyin ang landas ng pagkuha. Siyasatin ang XSS, mga nakalantad na URL at log, hindi naka-encrypt na trapiko, malware, mga malisyosong extension, pagkapirmi ng sesyon, at mahihinang kontrol sa lifecycle.
5. Suriin ang endpoint. Suriin ang browser, mga extension, nakaimbak na data, mga proseso, mga mekanismo ng persistence, at mga alerto sa seguridad. Huwag ibalik ang isang nakompromisong device sa normal na paggamit dahil lamang sa nagbago ang password ng account.
6. Suriin ang mga aksyong isinagawa sa sesyon. Hanapin ang access sa data, mga pagbabago sa configuration, mga bagong gawang kredensyal, mga pagbabago sa recovery, mga integrasyon, mga pagbibigay ng pahintulot, at mga aksyong administratibo.
7. Suriin nang hiwalay ang mga konektadong aplikasyon. Tukuyin kung aling mga token, sesyon, o federation path ang maaaring nakarating sa bawat serbisyo sa halip na ipagpalagay na nakompromiso ang lahat ng konektadong aplikasyon ng SaaS.
8. I-reset ang mga kredensyal kung naaangkop. Baguhin ang mga password at i-recover ang mga authenticator kung may ebidensya na na-expose ang mga ito, ngunit huwag ituring ang pag-reset ng password bilang kapalit ng pagbawi ng session at token.
9. Itama ang nabigong kontrol. I-patch ang application, alisin ang token leakage, pagbutihin ang pagbawi, linisin o muling itayo ang endpoint, o ayusin ang patakaran sa pag-access ayon sa nakumpirmang attack path.

Bukod sa pag-secure ng mga indibidwal na sesyon, maaaring palakasin ng mga organisasyon ang access sa application sa pamamagitan ng pagkontrol kung aling mga device ang pinapayagang mag-sign in. Sinusuportahan ng Scalefusion OneIdP ang conditional access para sa mga na-configure na SAML application, na nagpapahintulot sa mga IT admin na paghigpitan ang mga pag-sign in sa mga device na pinamamahalaan ng Scalefusion sa ilalim ng mga sinusuportahang patakaran. Ang mga kontrol na ito ay kumukumpleto sa seguridad ng sesyon sa antas ng application ngunit hindi pinapalitan ang pag-expire, pagsubaybay, o pagbawi ng sesyon.

galugarin Kondisyonal na Pag-access ng Scalefusion OneIdP.

Mga Madalas Itanong

1. Maaari bang mangyari ang session hijacking pagkatapos makumpleto ng isang user ang MFA?

Oo. Bine-verify ng MFA ang user habang nagpapatotoo, ngunit maaaring umasa ang isang application sa pagkakaroon ng ibinigay na sikreto ng sesyon. Kung nakawin ng isang attacker ang sikretong iyon pagkatapos, maaaring magamit muli ito ng attacker nang walang isa pang MFA prompt. Ang pagpapahusay ng pagpapatotoo bago ang mga sensitibong aksyon ay maaaring makabawas sa epekto, habang ang mga disenyo ng token na hindi tinatablan ng pagbawi at replay ay tumutugon sa mismong sesyon.

2. Inaalis ba ng HTTPS ang session hijacking?

Hindi. Pinoprotektahan ng HTTPS ang session data mula sa interception habang naglalakbay ito sa pagitan ng client at server. Hindi nito pinipigilan ang pagnanakaw sa pamamagitan ng malware, XSS, mga malisyosong extension, mga nakalantad na URL o log, pag-aayos ng session, o maling paghawak ng token sa panig ng application.

3. Sapat na ba ang pagpapalit ng password pagkatapos manakaw ang isang session?

Hindi naman kinakailangan. Ang pagpapalit ng password ay maaaring mag-iwan ng valid na session o refresh token sa isang umiiral na session o refresh token, depende sa application at identity provider. Bawiin ang mga apektadong session at token, i-verify ang gawi sa pag-reset ng password ng environment, siyasatin ang endpoint at acquisition path, at suriin ang aktibidad na isinagawa sa pamamagitan ng account.

4. Awtomatikong nagbibigay ba ng access sa mga konektadong SaaS app ang isang ninakaw na sesyon ng app?

Hindi. Ang access ay nakadepende sa uri ng session o token, sa audience at saklaw nito, sa mga pahintulot ng user, sa disenyo ng federation o integration, at sa sariling session behavior ng bawat SaaS application. Suriin ang bawat konektadong application nang hiwalay sa halip na ipagpalagay ang alinman sa ganap na paghihiwalay o universal access.