Kolla om förra sidan låg på den egna servern, eller om man kom 'utifrån'?

Du kan ju köra med sessions, men det går ju alltid att slå av även det...

Det gör jag, men om man lämnar webbläsaren uppe, och inte stänger den, och lämnar datorn, så kan ju någon annan bara backar rätt in igen.

Lite småknivigt problem? ;)
MVH Patrik

man kan ju bifoga sessionid i varje länk i stället för att skicka det som en cookie. användaren i sig stänger inte av själva session utan bara cookie som session i vanliga fall använder.

skickar man det via länk så kvittar det som användaren stänger av session. för att förhindra att någon att använda en gammal session är det ju bara att ha en databas där du lagrar session ID och hur länge den är giltlig. låt oss säga att du du tillåter varje session 10min, låter då en användare sin browser vara igång mer än 10min mellan besöken på hemsidan blir han/hon utloggad.

för att förhindra en användare att backa tillbaka ända till inloggningen kan du skicka med ett unikt nummer i något dolt input-fält så kan du lätt se om någon försöker logga in på det sättet.

det var några av mina funderingar, hoppas det hjälper dig lite.

Fixa en Logout knapp, man får väl hoppas på att användarna själva har lite säkerhetstänkande osso...

Det går att göra något liknande i javascript m.h.a frames.

Om du först gör en framesida där alla dina andra sidor läses in:

<frameset rows="0,*" frameborder="0">
    <frame name="hidden_frame" src="dold.html" noresize="noresize">
    <frame name="main" src="main.php" scrolling="auto">
</frameset>

I dold.html lägger du detta:

<script type="text/javascript">
    var onmysite = 'yes';
</script>

Och i alla sidor där du ska kolla om man kommer från din sida:

<script type="text/javascript">
    if (top.frames['hidden_frame'].onmysite != 'yes') {
        // Man är inte på din sida. Släng in en navigate till en php-sida.
        top.location.href = 'framesidan.php';
    } else {
        // Om du vill att det ska hända något om man kommer från din sida.
    }
</script>

Vet dock inte hur det fungerar då jag just skrev det och inte har testat det än. :)

The_Hulk: Det där med sessionid i adressen har alltid verkat lite riskabelt tycker jag, och det blir ju lite dumt eftersom en användare skall kunna vara inloggad i princip evig tid, så sessionen får ju inte självdö bara helt plötsligt.
Men annars var det ju en rätt intressant tanke. Och man skulle ju kunna uppdatera tiden giltighetstiden... men då skulle man behöva anropa databasen en gång var tionde minut för varje ansluten användare... men det var en tankebana jag inte begrundat eller ens tänkt ut förut, så jag skall fundera lite mer på detta. Tack =)

munktell: Hehe, jag önskar att det var en perfekt värld, men man får ju helt enkelt förutsätta att alla användare inte är lika säkerhetsmedvetna. Men logoutknapp finnes redan, det är som sagt bara backup:er för när logoutknappen inte används, som jag behöver.

Nexus86: Det javascriptet kommer väl inte att förhindra användare som slagit av javascript, från att komma in?

Jag inser iofs. att inget system här på nätet kommer att bli helt vattentätt, för det finns för många saker som kan hända, för många olika läsare, och för många olika inställningar, som kommer att göra det i princip omöjligt, men det måste ju gå att lösa det mesta?

För jag satt själv och funderade igår, på om man inte kunde gå in i javascripts history funktioner, och kolla om det fanns något lagrat i history objektet som kom före den nuvarande sidan. Och isåfall kanske man kunde få fram att det inte fanns något där, eller att det var från en annan server, eller att det var från en sida på denna servern. Men så kom jag ju som sagt på att javascript kan ju vara avslaget...

Jag önskar lite att det kunde höra till god ton, pga vissa orsaker naturligtvis, så som tillexempel säkerhet, då man kunde kräva av användaren att de hade javascript påslaget.

Hade en annan fundering, som gick ut på att ha en dold frame som uppdaterade sig var 10:e minut, med ett phpscript som kollade om en cookie på användaren hade en timestamp som var äldre än två minuter, och var den det så stänga ute honom/henne, och om den var mindre eller lika med, så uppdatera den med en ny timestamp, och låta användaren fortsätta sin färd på siten. Men cookies kan ju också stängas av.

Även om session_onend eller vad den hette i ASP´s global.asa inte fungerade så jättebra (inte i min erfarenhet iaf.) så saknar jag något liknande i php... Jag tror faktiskt att det är det enda jag saknar överhuvudtaget från ASP.

Nåväl, kommer jag på något så kommer ni att få höra, och kommer ni på något, så är jag idel öra.

Tack för alla svar hittills. :bire

MVH Patrik

Du kan ju alltid kolla först om användaren har javascript påslaget eller inte. Om den har det så använder du mitt förslag. Om inte, låter du användaren surfa med andra säkerhetslösningar. :)

Jag har redan klurat ut en annan lösning för att se om användaren har javascript påslaget, som jag slängt in i loginformen. Det är bara ett hidden-field, som har "0" som value och "JSActive" som name.
Och sedan ett javascript som onload ändrar värdet till "1"
Detta sker ju bara om javascript är påslaget, och alla måste passera loginformuläret för att komma in, så jag känenr att den kollen fungerar. ;) Men skulle vilja ha en lösning som fungerade på allt och alla, så att man slapp ha flera smålösningar för varje enstaka möjlighet... det känns så plottrigt med flera. Och det är mer som kan balla ur och dumma till resten av scriptet.

Men funderar redan på att sätta javascript som en requirement för att kunna använda sidan... Det skulle lösa många problem...

Är det dumt att kräva att javascript är påslaget? Det är ju trots allt för en god sak.

MVH Patrik

Jag tycker inte att det är dumt. De allra flesta har javascript påslaget och de som inte har det får skylla sig själva. :p

R// Känner personligen ingen som har det avslaget.

Om du bygger sidan med postningar, så om man trycker back så måste det hela postas om... så ser du om samma postning sker två gånger så är det bara att sparka ut, annars är det ok... det borde ju lösa "back" problemet iafa...

dock är jag rädd att dina användare kommer bli ganska så less på att bli urloggad hela tiden.. :P

Nexus, om man kan bygga sidan utan att kräva java så tycker jag att man skall försöka göra så... (iof så är jag lite extrem åt andra hållet osso.. :)

Tycker jag med men när javascriptet är säkerhetskritiskt tycker jag inte det spelar någon större roll.

vad blri det för skillnad om du har en frame som laddas om var 10:e minut för att se om användaren gjort något de senaste två minuterna jämfört med att sätta timeout på en session?

vad är det för riskabelt med att ha sessionid i länken?
allt du lägger i cookie skickas ju som ren text så vidar du inte använder SSL. då är det ju bara att ha en packet sniffer som kollar vad cookien är.
dessutom kan man själv be browsern att visa cookien varje gång.
givetvist blir det kanske lite mer riskabelt men så pass lite som det blir så tycker jag nästan det är bättre om man nu vill tillåta de som inte tillåter cookie att komma in på sidan.

vad var det som var så bra med session_onend?

de som använder vissa textbaserad webbläsare har inte alltid tillgång till att kunna använda javascript så det kanske är lite taskigt mot dem. använder själv ibland Lynx vilken inte använder javascript.

PHP.Net skrev:

There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.

Nu säger inte jag att det är riskabelt med sessionid i länken men man får se upp så att man inte lägger till SID automatiskt till utomstående länkar. Det mest riskabla annars är väl om någon "kompis" ser sessionid:t medan en användare är ute och surfar och går till sidan med sessionid och på så sätt tar sig in i dennes användare.

är bara att lägga in ip'et i session, och checka att det fortfarande samma ip till det akuella sessionid'et... så för att använda samma id så måste man vart fall vara på samma dator/nat... ökar säkerheten lite iafa...

Men hur blir det då i skolor? Där har de ofta samma ip. :OO

Och hur skulle han spara det sessionid:t och ip:t? Om han sparar det i en databas måste han ju ta bort det efter ett tag och hur långt är ett tag. Om jag t.ex. hade varit inloggad och varit tvungen att starta om datorn och min dator fått nytt ip under omstarten så kan inte jag logga in sen för att jag har fel ip. Då är det bättre med bara sessionid. ;)

man sparar ip'et i $_SESSION helt enkelt...

Alltså, eftersom jag vet att jag inte i det närmaste kommer börja syssla med SSL så är mitt mål att försöka göra en site som tål att bli avlyssnad, utan att man för den sakens skull ändå kan logga in. Men jag tror mig ha hittat ett alternativ som iofs har sprickor i försvaret, men som är acceptabla, eftersom jag ändå inte egentligen behöver såhär hård säkerhet.
Jag tar en tabell i vilken jag listar alla session id´s och tidpunkten nu, och sedan har jag en kontroll på varje sida, som först kollar om användaren som gick till sidan inte varit borta för länge, och sedan tar bort alla andra inlägg i den tabellen, där dessa sessioners tid inte uppdaterats på länge... luddig förklaring, men är trött och har redan gått på alkoholen lite lätt. :birp
Det är klurigt att försöka göra något helt säkert på nätet ;)

MVH Patrik