Hvis jeg nu har defineret accesslevels for en masse forskellige ting på ovenstående måde i session variabler, har brugeren så mulighed for at omgå dette?
Dette spørgsmål er interessant for mig, fordi hvis det ER sikkert nok, så er der jo ingen grund til, at jeg på samtlige funktioner på sitet tjekker op mod databasen - men kan blot nøjes med at validere mod brugerens session.
Altså session i sig selv er sikkert nok. Men det som kan være problemet er, at nogle kan evt. overtage en session. F.eks. har jeg på nuværende tidspunkt dette ID her på exp.dk: 0a1a71e8f50c844b337c8e19c6a018f4
Hvis andre så har viden til det, kan de gå herind, og udgive oplyse samme session, så tror exp.dk at det er mig (hvilket det ikke er)
Men hvis vi ser bort fra nogen overtager en session, så kan de ikke omgå det du sætter i sessions.
du kunne f.eks. lave følgende: $_SESSION['user_ip'] = $_SERVER['REMOTE_ADDR']; Hver gang der så laves noget, så kunne du tjekke: if($_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR']) { //Vi har forsøg på overtage session. }
Sådan kunne man vel evt. tilføje ekstra tjek. Men ellers burde det ikke være let at overtage som sådan.
Hvis du krypterer dem findes der på serveren også en dekrypterings funktionen - og når det er tilfældet kan alle sessions også dekrypteres, hvis de først får adgang til serveren ... så jeg kan ikke se formålet i en kryptering - eller rettere ok, man kan kryptere det hele med en randon værdi og så undlade at gemme denne random værdi - så er alt i sessionen ubrugeligt.
- Eller man kan generere en randon værdi - tilføje den til alle links på siden og så i bunden af php siden kryptere alt i sessions og så ved næste request kan du teste om den tilsendte GET["dekryptkey"] giver den rigtige værdi i en enkelt session værdi som du ikke har krypteret - hvis ja kan du decryptere alle session oplysninger og gentage denne løkke for hver request på siden
... men jeg har sikkert misforstået hvad du mener med kryptering - jeg kan bare ikke lige se ideen eller formålet da du vel skal bruge sessionen til noget ellers hvorfor så have den? Alt indhold i din session lækkes heller ikke til folk der ikke kan få fat i det krypteret/ukrypteret medmindre du laver en fejl i dit script eller serveren er usikker...
- Eller har jeg overset et eller andet formål? (Jeg bruger også selv kun det jakobdo skriver, og hvis den så ikke matcher kaster jeg en include til en php side, der generer en ny 32 tegns sessionid og sætter sessionid, inden jeg starter den nye session...)
[ For jeg bruger aldrig session[brugernavn] og password, da jeg føler at det ikke er sikkert nok ;) ] - Kan du forklare den en gang?
Jeg kan ikke se det store problem hvis du undlader at skrive session variablen oppe i adresselinjen og laver et check på ip-adressen i sammenhæng med den ip-adresse der findes i session'en og undlader at lade session's leve i flere dage før php automatisk rydder op og sletter dataerne ...
Eller rettere jeg forstår egentlig heller ikke den ekstra sikkerhed i denne her: [ Hver dag skifter den en ekstra_id så det ikke altid er den samme session[id] man bruger! ]
Ja, session er sikker nok, og alt det fis med beskyttelse, ip etc. er overkill.
Hvis session var hackable bare ved Jakobdo's sessionID 0a1a71e8f50c844b337c8e19c6a018f4 , så ville jeg skrive fra hans bruger nu. Men det gør jeg jo ikke :) Burde være bevis nok.
[ For jeg bruger aldrig session[brugernavn] og password, da jeg føler at det ikke er sikkert nok ;) ] - Skal folk så logge ind for hver side de requester? - Du behøver selvfølgelig ikke både at have brugernavn og kodeord - brugernavn er rigeligt og så sætter du kun brugernavnet hvis kodeordet stemte ved login og så valiederer du efterfølgende bare på om brugernavnet er sat...
Der er dog ingen risiko ved at have kodeordet samtidig - der er bare ingen "grund" til det. Men selvom du kun måler på et eller andet i din session uden kodeord og brugernavn så kan sessionen stadig hijackes hvis der er en der gætter sessionen og du ikke validerer på ip-adressen samtidig...
[ Ja, session er sikker nok, og alt det fis med beskyttelse, ip etc. er overkill. ] - Jeps, men når man skal have dankort og midlertidige personoplysninger opbevaret til e-mail af dankort bekræftelse er jeg lidt mere paranoid med det så derfor validerer jeg også på ip-adressen...
[Jeps, men når man skal have dankort og midlertidige personoplysninger opbevaret til e-mail af dankort bekræftelse er jeg lidt mere paranoid med det så derfor validerer jeg også på ip-adressen...]
mclemens, det link der.. til din indkøbskurv. Sådan virker det ikke i mine systemer, selvom jeg bruger sessions uden eksta beskyttelse ;) Så det er simpelhen bare elendig kodning på mi.dk
Det hjælper ikke spor, jeg er nødt til at have en session med brugerens ipadresse og e-mail i så når ssl forbindelsen gennem quickpay melder tilbage kan brugeren få bekræftelsen online og e-mail samtidig ... Og nej SSL på hele sitet er overload for mit vedkommende...
[ mclemens, det link der.. til din indkøbskurv. Sådan virker det ikke i mine systemer, selvom jeg bruger sessions uden eksta beskyttelse ;) Så det er simpelhen bare elendig kodning på mi.dk ] Ok, helt enig ... det er dårlig kodning! Det er nu ikke min indkøbsvogn - jeg tog bare første link hvor der var noget i sessionen i forvejen.
Og til slut kan man jo bare vælge cookiesessions :p så kommer linket ikke i adressen. (og ja, sessionen dør stadig efter browseren lukkes, det er en server-setting).
[ Og til slut kan man jo bare vælge cookiesessions :p så kommer linket ikke i adressen. ]- Det gør det jo heller ikke normalt alligevel ... indrømmer dog at enkelte steder (webhoteller) skal denne op i toppen af starten på siden for at undgå at php kaster det på alle urls på den første side... ini_set('url_rewriter.tags', '');
- Vælger sessions fremfor cookies da sessions dør ved lukning af browseren (bevares selvfølgelig et par minutter så jeg kan genstarter sessionen når de kommer retur fra quickpay's ssl relay script ((hvis ip adresse og session id stemmer)) ... så de automatisk er logget ind og får bekræftelsen) - men ok, hvis man lukker browseren ryger sessionen selvfølgelig også ... så skal man reconnecte sessionen inden den udløber med session ligesom jeg også skal med retur svaret fra dankort relay scriptet ... (så min session dør ikke "med det samme" man lukker)
Bruger det her: /* Ved administration / dankort videstilling så genaktiver session */ if(($durled[0]=='biiiiiiip')&&(isset($_GET['booop']))){ $reset=ereg_replace('[]<>\':\+,;\"()[]','',$_GET['booop']); session_id($reset); }
men cookies vs. sessions er igen afhængig af hvad man har det bedst med ...
Kaster lige en sidste kommentar... - typisk er problemet med det at den skriver det automatisk jo også p.gr.a. denne setting: session.use_trans_sid
- Og når php rydder op er det disse der er interessante og afgør hvornår sessionen rent faktisk dør efter at man har lukket browseren (den gør det normalt ikke så sanrt man lukker vinduet) eller man ikke har communikeret med serveren i længere tid... Prøv f.eks. at signe på eksperten og lad vinduet stå uden for et spørgsmål med pro auto update (kan ikke huske hvor lang tid det plejer at tage) - men her dør sessionen også...
[ session.gc_probability integer session.gc_probability in conjunction with session.gc_divisor is used to manage probability that the gc (garbage collection) routine is started. Defaults to 1. See session.gc_divisor for details.
session.gc_divisor integer session.gc_divisor coupled with session.gc_probability defines the probability that the gc (garbage collection) process is started on every session initialization. The probability is calculated by using gc_probability/gc_divisor, e.g. 1/100 means there is a 1% chance that the GC process starts on each request. session.gc_divisor defaults to 100. ]
- Jeps, men du identificerer dem stadig på en måde ... og den variabel du så bruger i sessionen til at validere på log ind status giver jo samme privilegier som hvis det var selve brugernavnet du validerede på i sessionen ... anyhow jeg kan ikke se problemet med at du skal kryptere dataer som kun findes på serveren ... men, jeg kører jo ikke selv kryptering af sessions ... så jeg har måske bare overset noget :o)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
