[ASP]SessionCookies veilig?

[LordAlderaan]

Cookie:
A small text file on the user's browser and hard drive that uniquely identifies the user's browser. There are two types of cookies: persistent cookies and session cookies. Session cookies are temporary and are erased when the browser exits. Persistent cookies remain on the user's hard drive until the user erases them or until they expire.

Session Cookies:
Cookies which are loaded into a computer's RAM, and only work during that browser session. When the browser exits, these cookies are erased. They are "temporary cookies", and no cookie is written to a user's hard drive.

bron=http://www.interactivejar...sary/Term/Session+Cookies

(Vraag 1)
Dus als ik het goed begrijp en ik gebruik gewoon
Response.Cookies ("Naam")("Variabele") = Waarde
gebruik, dan word deze als een Session Cookie opgeslagen (Ik kan 'm namenlijk nergens op de HD vinden).
En als ik vervolgens
Response.Cookies ("Naam").Expires = DATE + 150
gebruik dan word zo'n cookie dus op de HD gezet. Of heb ik het helemaal verkeerd?

(Vraag 2)
En zo'n session cookie staat neem ik aan in het RAM geheugen van de client en niet op de server?

(Vraag 3)
Zo Ja kan ik dan die gegevens aanpassen mbv een proggie?

Ik heb namenlijk een website gebouwed waarbij ik niet bang ben dat mensen die niet mogen inloggen proberen de site te hacken/cracken. Maar waarbij het van redelijk groot belang is dat de ene ingelogde persoon de pagina's en database resultaten van de ander niet kan zien. En dit wil ik dus ook redelijk veilig hebben.

Op iedere pagina word gekontroleerd of de gegevens in de cookie correct zijn.

Dus de makkelijkste en bijna de enige manier om te hacken/cracken is door gegevens in het sessioncookie aan te passen.

(Vraag 3 (maar dan anders gesteld))
Hoe makkelijk is dit?
(Ik kon met google en astalavista.box.sk niet direct proggies vinden die Session cookies konden lezen laat staan aanpassen.)


(Vraag 4)
Of is het echt veel verstandiger om met Sessions te werken? En hoeveel veiliger is dit dan? (Dan moet ik een groot gedeelte van de website ombouwen)


Greetz,
Lord Alderaan

[Verwijderd]

1. In .Net werkt 't precies omgekeerd:

C#:

HttpCookie aCookie = new HttpCookie(<naam>, <value>);
// do not forget to set these properties for persistent cookies:
aCookie.Expires = DateTime.MaxValue;
aCookie.Path = "/"; 

Als je dus de Expires- en Path-properties niet zet, wordt het een "RAM-cookie".

2. idd; op de server wordt onthouden welke sessiesleutel bij een bepaald cookie hoort...

3. ja; iemand toevallig gisteren (maandag 28 oktober) Netwerk nog gezien?
(maar het is niet zo heel makkelijk)

4. ligt eraan waar je het voor wilt gebruiken...

[LordAlderaan]

Aha
dus als ik geen path of Expires properties opgeef wordt het een RAM-Cookie. En dus pas nadat je in ASP een cookie een path property of een Expire property geeft dan word het pas een HD cookie.

Het zijn waarschijnlijk een stelletje Computer analfabeten die gaan inloggen maar ik wilde weten hoe veilig zo'n SessionCookie is. Als er een kant en klaar proggie om SessionCookies te lezen en aan te passen is en als dat makkelijk te vinden is op internet dan ga ik ombouwen naar Sessions. Maar ik ben redelijk gerustgesteld (tot nu toe) dat het grondige kennis vereist om dit aan te passen. Ik sla in dat session cookie de volgende gegevens op:
-Login
-Password
-Bedrijf dat in database was gekoppeld aan de login (Dit word vervolgens als criteria in SQL opdrachten gebruikt om ervoor te zorgen dat alleen gegevens uit de database worden opgehaald die betrekking hebben op dit bedrijf).
-Gebruikers soort (Er zijn 4 groepen ieder met hun eigen website, waar ze naar geredirect worden aan de hand van het gebruikers soort (En iedere pagina die ze openen word het gebruikerssoort gekontroleerd)
-logged (Zijn ze door de inlogproceduren gegaan (Voorkomt directe aanvraag naar specifike pagina's in de web) en zijn ze in het logboek opgenomen). (Vooral om te verkomen dat mensen meerdere malen in het logboek in de database worden gezet als ze op F5 drukken (Ik werk met frames).


newayz tnx.

[Verwijderd]

Ik denk dat je de techniek van sessie cookies nog eens moet teruglezen.

Als je login en wachtwoord in een cookie opslaat, en je steelt zo'n cookie, dan zijn de peren gaar. De bedoeling van zo'n sessie-cookie is dat je alleen een nummer in zo'n cookie opslaat. Op de server staat dan ergens de login en wachtwoord, gekoppeld aan dat nummer.

Trouwens, het stelen van die cookies is met Internet Explorer redelijk eenvoudig. Kijk de laatste IE bugs er maar op na.

[LuCarD]

Verwijderd schreef op 29 oktober 2002 @ 14:33:
Ik denk dat je de techniek van sessie cookies nog eens moet teruglezen.

Als je login en wachtwoord in een cookie opslaat, en je steelt zo'n cookie, dan zijn de peren gaar. De bedoeling van zo'n sessie-cookie is dat je alleen een nummer in zo'n cookie opslaat. Op de server staat dan ergens de login en wachtwoord, gekoppeld aan dat nummer.

Trouwens, het stelen van die cookies is met Internet Explorer redelijk eenvoudig. Kijk de laatste IE bugs er maar op na.

Sorry ben ik niet mee eens....

sessie cookie en sessie variablen.

Sessie cookie zijn cookie die in het geheugen van de browser worden opgeslagen en verdwijnen zodra je de browser afsluit.
Sessie Variablen zijn variablen die op de server worden bewaard en meestal dmv een sessie cookie kunnen worden benaderd (dat nummertje waar jij het over hebt).

LordAlderaan schreef op 29 oktober 2002 @ 14:23:
Aha
dus als ik geen path of Expires properties opgeef wordt het een RAM-Cookie. En dus pas nadat je in ASP een cookie een path property of een Expire property geeft dan word het pas een HD cookie.

Hoe zie jij het verschil tussen sessie cookie's en normale cookie's ? IMHO zijn ze voor de server gelijk.
Daarnaast worden alle cookies als cleartext verstuurt en zijn vrij simpel te faken (sessie cookie's of gewone cookies)

Sorry als jouw beveiliging alleen vertrouwt op sessie cookie dan ben ik als niet hacker er zo door heen.

[LordAlderaan]

LuCarD schreef op 29 oktober 2002 @ 14:43:
Sorry als jouw beveiliging alleen vertrouwt op sessie cookie dan ben ik als niet hacker er zo door heen.

Mijn eerste beveiliging berust op het feit dat de URL alleen bekend is bij die mensen die daadwerklijk mogen inloggen.

Dus je mag bij deze proberen mijn site te hacken... je mag wel zelf gaan uitvinden welke URL het is (ff om duidelijk te maken hoe goed deze eerste beveiliging werkt )


Verder beveiliging werkt als volgt:
Iedere login heeft een eigen password, dat password is alleen te vinden in de database. En daar kom je niet in. Dus als je als hacker zou willen binnenkomen dan moet je dus al het sessie(ram)cookie van iemand die al is ingelogd moeten kunnen lezen. En dan zou je alleen namens die persoon kunnen inloggen. Maar dat is helemaal niet waar ik bang voor ben...

Ik ben bang dat iemand die al erin mag gegevens krijgt te zien die niet voor hem bedoeld zijn.

Hierin zijn twee lagen:
Men past in het sessioncookie de bedrijfscode aan, deze bedrijfscode geld als een criteria bij bijna alle FP_SQL instructies die worden uitgevoerd. Men kan dan alle gegevens van zijn bedrijfsgroep aanpassen (als men weet waarin men de bedrijfscode in het cookie moet aanpassen om welke gegevens te zien te krijgen).

En als men dan ook nog de gebruikersgroep aanpast (weer moet je weten waarin het aan te passen) kan men ook nog eens op de andere websites (die wel ieder weer hun eigen bedrijfscodes hebben).


Om het een beetje duidelijker te maken dit zijn twee stukjes code:

Controle van gebruikersgroep
paginagebruikersgroep = "XYZ"
If Request.Cookies("Meurs")("gebruikersgroep") <> paginagebruikersgroep Then
msg = "Uw bedrijfsgroep heeft geen toegang tot de pagina die u aanvroeg"
response.redirect "mislukt.asp?errormsg=" & msg
End If


Gebruik van bedrijfscode als criteria:
Bedrijfscode = Request.Cookies("Naam")("Bedrijfscode")
fp_sQry="SELECT * FROM WebQuery WHERE (Bedrijfscode = " & Bedrijfscode & " ) ORDER BY Naam ASC"


note: Ik gebruik de standaard classes van Frontpage om gegevens uit de Database te halen.

[LuCarD]

LordAlderaan schreef op 29 oktober 2002 @ 15:20:
[...]


Mijn eerste beveiliging berust op het feit dat de URL alleen bekend is bij die mensen die daadwerklijk mogen inloggen.

Dus je mag bij deze proberen mijn site te hacken... je mag wel zelf gaan uitvinden welke URL het is (ff om duidelijk te maken hoe goed deze eerste beveiliging werkt )

En jij vertrouwt al je klanten? Alle proxy servers waar de klanten door heen gaan?
Alle systeembeheerders?

Dan geloof je zeker ook nog in de paashaas?

Verder beveiliging werkt als volgt:
Iedere login heeft een eigen password, dat password is alleen te vinden in de database. En daar kom je niet in. Dus als je als hacker zou willen binnenkomen dan moet je dus al het sessie(ram)cookie van iemand die al is ingelogd moeten kunnen lezen. En dan zou je alleen namens die persoon kunnen inloggen. Maar dat is helemaal niet waar ik bang voor ben...

Cookies gaan in cleartext over te lijn. Alle mensen die ik hier boven heb beschreven kunnen dat zonder al te veel moeite lezen

Ik ben bang dat iemand die al erin mag gegevens krijgt te zien die niet voor hem bedoeld zijn.

Ahh oke.. het is geen beveiliging tegen hackers maar te per ongeluk fout gebruik?

In dat geval zou het systeem goed kunnen zijn...

Hierin zijn twee lagen:
Men past in het sessioncookie de bedrijfscode aan, deze bedrijfscode geld als een criteria bij bijna alle FP_SQL instructies die worden uitgevoerd. Men kan dan alle gegevens van zijn bedrijfsgroep aanpassen (als men weet waarin men de bedrijfscode in het cookie moet aanpassen om welke gegevens te zien te krijgen).

En als men dan ook nog de gebruikersgroep aanpast (weer moet je weten waarin het aan te passen) kan men ook nog eens op de andere websites (die wel ieder weer hun eigen bedrijfscodes hebben).


Om het een beetje duidelijker te maken dit zijn twee stukjes code:

Controle van gebruikersgroep
paginagebruikersgroep = "XYZ"
If Request.Cookies("Meurs")("gebruikersgroep") <> paginagebruikersgroep Then
msg = "Uw bedrijfsgroep heeft geen toegang tot de pagina die u aanvroeg"
response.redirect "mislukt.asp?errormsg=" & msg
End If


Gebruik van bedrijfscode als criteria:
Bedrijfscode = Request.Cookies("Naam")("Bedrijfscode")
fp_sQry="SELECT * FROM WebQuery WHERE (Bedrijfscode = " & Bedrijfscode & " ) ORDER BY Naam ASC"


note: Ik gebruik de standaard classes van Frontpage om gegevens uit de Database te halen.

[LordAlderaan]

LuCarD schreef op 29 oktober 2002 @ 15:38:

En jij vertrouwt al je klanten? Alle proxy servers waar de klanten door heen gaan?
Alle systeembeheerders?

Dan geloof je zeker ook nog in de paashaas?

Cookies gaan in cleartext over te lijn. Alle mensen die ik hier boven heb beschreven (is dat inclusief de paashaas?!) kunnen dat zonder al te veel moeite lezen

Ahh oke.. het is geen beveiliging tegen hackers maar te per ongeluk fout gebruik?

In dat geval zou het systeem goed kunnen zijn...

Sessions it is then...

Ik vertrouw mijn proxy servers en IT personeel daar grotendeels. Ik geloof in de paashaas. Maar mijn klanten vertrouw ik niet. Het is moeilijk voor de ene klant om gegevens van de andere klant te zien. Maar misschien gaat het toch niet al te veel moeite worden om om te bouwen naar sessions.


BTW die ene keer dat men via een formulier inlogd gaan de gegevens toch ook als plaintext door de proxy's van de gebruikers e.d.

En een keer is genoeg...

[Verwijderd]

Ik denk echt dat je wat beter je huiswerk zou kunnen doen op google;
En dan ook niet je conclusies trekken uit 1 woordenboek a-like description.

En non-session cookies (de gangbare cookies - Response.Cookies) die je optioneel kunt instellen met de '.Expires'-property worden dan niet opeens 'RAM-cookies'. Deze komen wel degelijk fysiek op de hd te staan, maar worden weer verkruimeld bij het sluiten van de browser.

[ Voor 0% gewijzigd door Verwijderd op 30-10-2002 00:27 . Reden: vernetification ]

[LordAlderaan]

Vraagje?
Waar zet hij die Response.Cookies zonder path or expires properties dan op de HD? Welk path?

Het cookie is nergens te vinden. En jah ik heb natuurlijk de browser nog niet afgesloten en de sessie is nog niet verlopen.
Of het moet een ander formaat gebruiken dan txt.


Na ff nogmeer zoeken op google:

1.1 What is a Cookie?

A cookie is a text-only string that gets entered into the memory of your browser. This value of a variable that a website sets. If the lifetime of this value is set to be longer than the time you spend at that site, then this string is saved to file for future reference.
bron: http://www.cookiecentral.com/faq/#1.1

edit:

Sterker nog, in IE zelf (Ik gebruik hier 5.00.2919.6307) word zelfs onderscheid gemaakt tussen Cookies in het geheugen en op de HD. Je kunt ieder appart blokkeren.

Ik heb de site ff snel omgebouwd naar session dmv Zoeken & Vervangen in HTML code van alle pagina's met Fronpage. En hij werkt perfect.

[Verwijderd]

Een typical cookie path: C:\Documents and Settings\{username}\Cookies

For the record: Nog even getest en zolang je geen verlooptijd meegeeft is komt de cookie inderdaad niet fysiek op de hd te staan.

Sue me!

Ik ben blij dat je site goed werkt nu. Good luck ermee.

[raptorix]

Session cookies staan dus in het ram van de server
Clients krijgen een soort van ID, en de server gebruikt dat ID weer om de koppeling te maken met de info in ze ram.

[LordAlderaan]

Nee, raptorix, dat is de beschrijving van een Session.

1. Je hebt een Cookie met verloopdatum en die staat op de HD.

2. Je hebt een Cookie zonder verloopdatum of path en die staat in het gehuigen van de client (Bij deze ff Session-Cookie hernoemd).

3. Je hebt een Session en die staat in het gehuigen van de Server.

Voor een koppeling (de ID waar jij het over hebt) tussen een Session(3) en een Client word geen normale Cookie(1) aangemaakt op de HD dus moet er iets in het geheugen worden gezet*. En aan de hand van testen heb ik uitgevonden dat het blokken van Session-Cookies(2) ook Session(3) uitschakeld, dit kan vervolgens twee dingen betekenen:

A> Session-Cookie(2) en Session(3) zijn twee namen voor hetzelfde (maar waarom dan zoveel moeite om er een ander command in ASP voor aan te maken, en ook nergens op internet heb ik begrepen dat die twee hetzelfde zijn. Menig topic in dit forum toont ook nog eens aan dat het verschillende dingen zijn.
En als het ID dus niet in een Cookie(2) zit en er dus ook geen RAM-Cookie bestaat, waar komt die ID dan?* )

B> Een Session(3) maakt gebruik van een Session-Cookie(2) om de ID in op te slaan die de koppeling tussen die twee mogelijk maakt. En de Session-Cookie(2) staat dus ongetwijfeld in het geheugen van de Client.

* Ik ga ervan uit dan een website alleen maar het recht heeft om Cookies op een computer achter te laten, en dat het dus GEEN mogelijkheid heeft om op andere manieren een ID op de HD of in het Geheugen van een Client te zetten.

Als er ergens iets mis is met mijn conclusies en bevindingen, meld dat dan ff (graag goed onderbouwd dan snap ik ten minste ook waarom ik het fout heb).

[ Voor 0% gewijzigd door LordAlderaan op 30-10-2002 14:04 . Reden: Meer argumenten. ]

[LuCarD]

LordAlderaan schreef op 30 oktober 2002 @ 13:53:
Nee, raptorix, dat is de beschrijving van een <b>Session</b>.

1. Je hebt een Cookie met verloopdatum en die staat op de HD.

2. Je hebt een Cookie zonder verloopdatum of path en die staat in het gehuigen van de client (Bij deze ff Session-Cookie hernoemd).

3. Je hebt een Session en die staat in het gehuigen van de Server.

Voor een koppeling (de ID waar jij het over hebt) tussen een Session(3) en een Client word geen normale Cookie(1) aangemaakt op de HD dus moet er iets in het geheugen worden gezet. En aan de hand van testen heb ik uitgevonden dat het blokken van Session-Cookies(2) ook Session(3) uitschakeld, dit kan vervolgens twee dingen betekenen:

A> Session-Cookie(2) en Session(3) zijn twee namen voor hetzelfde (maar waarom dan zoveel moeite om er een ander command in ASP voor aan te maken, en ook nergens op internet heb ik begrepen dat die twee hetzelfde zijn. Menig topic in dit forum toont ook nog eens aan dat het verschillende dingen zijn.)

B> Een Session(3) maakt gebruik van een Session-Cookie(2) om de ID in op te slaan die de koppeling tussen die twee mogelijk maakt. En de Session-Cookie(2) staat dus ongetwijfeld in het geheugen van de Client.


Als er ergens iets mis is met mijn conclusies en bevindingen, meld dat dan ff (graag goed onderbouwd dan snap ik ten minste ook waarom ik het fout heb).

Bijna goed.

Optie 3:
- Sessie's kunnen ook presistent zijn. Het is mogelijk om met een sessie ook ipv session-cookies te gebruiken om ook normale cookie's te gebruiken. Wordt volgens mij ook hier bij GOT gebruikt

- Je kan sessie' ID ook in een POST of GET variable opslaan.

- Sessie variablen kunnen worden opgeslagen in het geheugen, disk of database.

[LordAlderaan]

Aha, dan kan ik daar nog eens een keer een beetje mee gaan kloten. Maar iig bedankt voor de feedback.

Ik bedacht me net wat:
Als een Session ook persitant kan zijn. Word de ID dan opgeslagen in ee persitant Cookie? Want anders zou de volgende keer dat ik inlog bij (bv) GoF de server toch niet weten welke Session variabele bij mij horen. En als ik zo'n cookie dus van iemand anders kopieer (en IP spoof en al dat soort grapjes) dan zou ik dus namens hem kunnen inloggen...

En zou je dan niet weer terug bij af zijn...
Ik bedoel wat zou het verschil zijn tussen enerzijds
een Persitant Session (server) met een Daarbij horend Persitant Cookie (Client)
en anderzijds
een Database (Server) met de inloggegevens in een Persitant Cookie (Client).

[ Voor 0% gewijzigd door LordAlderaan op 30-10-2002 14:16 . Reden: Ik bedacht me net wat ]