[ASP] Veiligheid van Session opbjecten

[HunterPro]

Is een session object veilig? Met andere woorden, als ik een access level van een gebruiker in een session object gooi, kan de gebruiker dit dan niet veranderen? Ik wil namelijk administrator-functies op basis van een dergelijke access-level opzet bouwen. Is het beter dit steeds uit de database te laten uitlezen?

Ow ook een vraag twee:

Ik wil een scriptje bouwen dat via een request object een minimum access level krijgt + een pagina waar ie heen moet (en een als de aanvraag gedeclined wordt), maar nu is de bedoeling dat die dan bepaalt of de gebruiker genoeg access heeft (uit dit session object) maar hoe doe ik dit zonder dat gebruikers dit request object kunnen veranderen/verminken? Kan dit intern (in de server) gepuzzeld worden zonder dat de browser eigenlijk wat merkt van dat heen-en-weer gegooi van variabelen en objecten?

Xen

[RupS]

Ik ben ook met zoiets bezig..

Wat ik ga doen: Bij het begin een session.abandon

dan een login + pass uit de database, dan pas een cookie zetten, en zo instellen dat het cookie wordt weggegooid op het moment dat je de browser sluit, of op uitloggen klikt.....

[PhoneTech]

Op maandag 15 oktober 2001 20:13 schreef dutchrups het volgende:
Ik ben ook met zoiets bezig..

Wat ik ga doen: Bij het begin een session.abandon

dan een login + pass uit de database, dan pas een cookie zetten, en zo instellen dat het cookie wordt weggegooid op het moment dat je de browser sluit, of op uitloggen klikt.....

Nu moet je mij uitleggen wat session.abandon en cookies met elkaar te maken hebben...

[Basszje]

Session == cookies ongeveer.
Cookies zijn trouwens meer achterhaalbaar ( op een of andere manier ) dan sessions dacht ik.

Je moet er trouwens wel op letten dat je appje niet crasht als je session uittimen (meestal na 20 minuten niets doen ) .

[HunterPro]

jahw maar is een session niet te bewerken? Bijvoorbeeld een Querystring, die kan ik faken door zelf een formpje te bouwen. Kan zoiets niet voor session's?

En dan kom ik dus ook bij me tweede vraag: kan ik intern in de server die variables heen en weer gooien zonder dat de gebruiker dit merkt, zodat ik dus VEILIG over een script kan beschikken wat kijkt of je genoeg access hebt voor een resource, doormiddel van input van de resource + de minimum vereiste access level + databeest-koppeling)?

xen

[raptorix]

Is zeer veilig daar hoef je echt geen zorgen over te maken, wil je het echt super veilig doen, dan zou je bijvoorbeeld ook nog zaken als hostnames kunnen gaan checken.

[PhoneTech]

Op maandag 15 oktober 2001 21:24 schreef xeninex het volgende:
jahw maar is een session niet te bewerken? Bijvoorbeeld een Querystring, die kan ik faken door zelf een formpje te bouwen. Kan zoiets niet voor session's?

En dan kom ik dus ook bij me tweede vraag: kan ik intern in de server die variables heen en weer gooien zonder dat de gebruiker dit merkt, zodat ik dus VEILIG over een script kan beschikken wat kijkt of je genoeg access hebt voor een resource, doormiddel van input van de resource + de minimum vereiste access level + databeest-koppeling)?

xen

Een sessie is in princiepe niet te bewerken door de gebruiker.een cookie makkelijker omdat dat een fysiek bestand op je client zijn computer is. Het is een van de 4 manieren om data van de ene naar de andere pagina te sturen. Je ken het dmv Post, Get, Sessions en cookies doen.
Het voordeel van sessies en cookies is dat je ze 1 keer schrijft en dan overal in de asp pagina's kan opvragen zonder formulieren of dat soort shit...

Wat je hierboven beschreven hebt kan idd met cookies en/of sessies maar echt superveilig is het niet maar veel sites werken met deze verificatie...

[Basszje]

En het nadeel van sessions is dan weer dat het geheugen vreet en als je er veel van gebruikt je niet echt tot duidelijke code komt .
Geniet maar gebruik met mate

[Verwijderd]

Volgens mij kan je het ook in de header van je browser plaatsen.

[Mart!]

Session object is zeker veiliger als cookies, al is de identificatie van een session een cookie.
Als je cookies gebruikt dan worden deze tussen server en client heen en weer gestuurd en de cookies worden op de schijf van de gebruiker bewaard. Zo gauw een sessie start krijg je een uniek sessie-id, bv: ASPSESSIONIDGQQQGQFC=HJGPAPPBIGIHCCBHHMIGACAP
Dit is ook een cookie, maar zal niet meer geldig zijn als dit aan de serverkant d.m.v. session.abandon wordt aangegeven of er een session-timeout optreedt.

Ofwel 8 + 24 karakters ter identificatie van de client. De variabelen die behoren bij de sessie (bijv. userid, userlevel) worden alleen op de server bijgehouden. De kans dat een ander jou sessievariabele raad, is ZEER klein, want er zijn minimaal 30^26 (uitgaande van 30 karakters en 26 (A-Z) mogelijkheden per karakter) mogelijkheden. Bovendien heeft hij daar dan ook nog zeer weinig aan omdat hij de variabelen die behoren bij de sessie niet zomaar op kan vragen (dit kan alleen maar op de server waar de asp-applicatie op draait). Hij zou zich echter wel kunnen doen als jou als hij jou sessie-variabele weet.

Meer info is natuurlijk te vinden op MSDN: http://msdn.microsoft.com/library/en-us/dnasp/html/aspwsm.asp?frame=true