[ASP] Cookies Faken *

[ZjieB]

Ik weet eigenlijk niet of dit hier thuishoort of niet, ik probeer het toch:

ik draai een ASP-forum met een auto-login. Deze auto-login kijkt of er een cookie op het systeem staat en haalt daar de UserID uit. Als hij een user-id vindt dan ben je automatisch ingelogd.

Is het mogelijk om cookies te faken? M.a.w. kan ik ZELF een cookie creëren waarin een ander User_ID staat en op die manier 'automatisch' inloggen op een ander account? Algemene vraag: zijn cookies te faken en is mijn forum dus hackable?

En nu de P&W vraag: hoe kan ik m.b.v. ASP een cookie faken (is het mogelijk om headers zo te wijzigen dat de cookie wordt opgeslagen op de HD van een gebruiker alsof hij afkomstig is van een andere site?)

[CyeZ]

Zelf lokaal je cookies veranderen, en op die manier een ander UserID invullen kan inderdaad prima. Je zult dan ook meer op moeten slaan als alleen een UserID in het cookie.

Dmv ASP of andere serverside scripttalen is het niet mogelijk om op iemands machine een cookie aan te maken op een ander domain. Al zijn er in het verleden wel bugs geweest in browsers waardoor het wel kon als ik me niet vergis.

[Verwijderd]

Met PhP is heb je een optie om cokies server-site te zetten. zal je ook met ASP hebben... lost veel problemen van cookies faken op

[gorgi_19]

Verwijderd schreef op 25 augustus 2003 @ 09:49:
Met PhP is heb je een optie om cokies server-site te zetten. zal je ook met ASP hebben... lost veel problemen van cookies faken op

Oftewel Sessions dus.

[GrimaceODespair]

edit:
^^^

Door cookies serverside bij te houden, kan je volgens mij het hijacken van andermans sessie nog niet voorkomen. Bij serverside cookies reist nl volgens mij een SID (session id) mee in de http headers, die een client bij zijn response best zou kunnen veranderen.

[ Voor 5% gewijzigd door GrimaceODespair op 25-08-2003 09:55 ]

[jurri@n]

gorgi_19 schreef op 25 August 2003 @ 09:52:
[...]

Oftewel Sessions dus.

En dan heb je nog steeds een cookie client-side nodig met het session-id (of je moet in iedere URL het session ID hebben zitten, dat kan ook).

[gorgi_19]

jurri@n schreef op 25 August 2003 @ 09:56:
[...]

En dan heb je nog steeds een cookie client-side nodig met het session-id (of je moet in iedere URL het session ID hebben zitten, dat kan ook).

Klopt.. Maar hij beschreef het principe van sessions. En de 'randverschijnselen' die je noemt zijn de nadelen.

[Verwijderd]

Het is volgens mij redelijk eenvoudig: je maakt een eigen server op je lokale netwerk, zorgt (via hosts of DNS) dat je die kan bereiken onder "www.jouwforum.nl" en laat deze het cookie plaatsen. Daarnaast is het waarschijnlijk ook niet zo heel moeilijk om gewoon zelf met notepad een cookie.txt aan te maken.

Je zult de beveiliging van je forum dus van meer moeten laten afhangen dan een cookie.

[Yoeri]

En nu de P&W vraag: hoe kan ik m.b.v. ASP een cookie faken (is het mogelijk om headers zo te wijzigen dat de cookie wordt opgeslagen op de HD van een gebruiker alsof hij afkomstig is van een andere site?)

offtopic:
is heel je topic slechts een excuus om dit te weten... foute dingen van plan?

[curry684]

is heel je topic slechts een excuus om dit te weten... foute dingen van plan?

Als je echt slechte bedoelingen hebt is het een stuk makkelijker om met de hand een cookie op je lokale computer aan te maken dan al de moeite te doen van het via ASP te faken

[ZjieB]

bedoelingen slecht? mwa, ik ben gewoon aan het kijken hoe veilig alles is. Ik had nl. een nieuws-gedeelte op een site, waarbij ik zo stom was geweest om de database (met daarin de admin-logingegevens) in een via het web bereikbare dir te zetten. De database is gedowned en één of andere onverlaat heeft al mijn nieuws-items vern##kt.

Ik ben nu gewoon aan het kijken hoe het zit met de beveiliging van dat soort dingen op mijn site.

[gorgi_19]

ZjieB schreef op 25 August 2003 @ 12:43:
bedoelingen slecht? mwa, ik ben gewoon aan het kijken hoe veilig alles is. Ik had nl. een nieuws-gedeelte op een site, waarbij ik zo stom was geweest om de database (met daarin de admin-logingegevens) in een via het web bereikbare dir te zetten. De database is gedowned en één of andere onverlaat heeft al mijn nieuws-items vern##kt.

Ik ben nu gewoon aan het kijken hoe het zit met de beveiliging van dat soort dingen op mijn site.

Erhm.. Downloaden is 1, maar hoe kan hij hem dan weer uploaden?

Verder kan je je database in een folder buiten de webroot zetten.

[GrimaceODespair]

gorgi_19 schreef op 25 August 2003 @ 12:43:
[...]

Erhm.. Downloaden is 1, maar hoe kan hij hem dan weer uploaden?

ZjieB schreef op 25 August 2003 @ 12:43:
de database (met daarin de admin-logingegevens)

[gorgi_19]

GrimaceODespair schreef op 25 augustus 2003 @ 12:44:
[...]


[...]

Tsk.. Als hij dat voor simpele gorgi's nou eens in <h1>-tags zou zetten....

[djexplo]

Eh.. Je kan je de data in je cookies toch gewoon versleutelen md5 ?

[CaptBiele]

volgens mij kan je niet je cookies versleutelen... ze worden toch uitgelezen door je browsers, oftewel: het moet plain text zijn...

en als het al mogelijk is, dan is natuurlijk ook makkelijk om het weer te ontcijferen.....

(d8 ik hoor)

[gorgi_19]

CaptBiele schreef op 25 augustus 2003 @ 18:31:
volgens mij kan je niet je cookies versleutelen... ze worden toch uitgelezen door je browsers, oftewel: het moet plain text zijn...

en als het al mogelijk is, dan is natuurlijk ook makkelijk om het weer te ontcijferen.....

(d8 ik hoor)

Waarom kan je ze niet versleutelen? Je ziet in een cookie dan een versleutelde waarde.
Sleutel is dan wel aanwezig op de server, welke de versleutelde waarde inleest en decrypt.

[ Voor 10% gewijzigd door gorgi_19 op 25-08-2003 18:33 ]

[whoami]

CaptBiele schreef op 25 August 2003 @ 18:31:
volgens mij kan je niet je cookies versleutelen... ze worden toch uitgelezen door je browsers, oftewel: het moet plain text zijn...

Als de applicatie die de cookies uitleest weet dat ze versleuteld zijn, is dat geen probleem. En dat is meestal geen probleem, aangezien de applicatie die ze uitleest, ze ook wel meestal zelf gezet heeft.
(Het is trouwens niet de browser die de cookies uitleest, maar de web-applicatie).

Echter, ik dacht dat een MD5 een one-way encryptie was, dus je zal een andere encryptie-techniek moeten gebruiken.

[ Voor 11% gewijzigd door whoami op 25-08-2003 18:33 ]

[CaptBiele]

ah ok. Tnx voor de verheldering whoami!

[gorgi_19]

whoami schreef op 25 August 2003 @ 18:33:
Echter, ik dacht dat een MD5 een one-way encryptie was, dus je zal een andere encryptie-techniek moeten gebruiken.

* gorgi_19 weet het eigenlijk wel zeker..

[whoami]

Ik zelf maak nl. ook wel gebruik van versleuteling voor de user-info die ik in cookies wegschrijf.

code:

authTicket = new FormsAuthenticationTicket (1,
                                            _userInfo.UserNaam,
                                            DateTime.Now,
                                            DateTime.MaxValue,
                                            true,
                                            _userInfo.UserId.ToString());

authCookie              = new HttpCookie (FormsAuthentication.FormsCookieName);
authCookie.Value    = FormsAuthentication.Encrypt (authTicket);
authCookie.Expires  = DateTime.MaxValue;

Response.Cookies.Add (authCookie);

[ZjieB]

versleutelen is idd de oplossing: ik gebruik nu HashEncode & Salt, lijkt goed te werken.

Heb trouwens geprobeerd een cookie hier lokaal aan te passen, dus gewoon geopend in kladblok en de UserID gewijzigd. Vervolgens opgeslagen en mn site bezocht. Het koekje was geheel verwijderd. Met andere woorden: gewoon aanpassen van een cookie kan niet zomaar???

[Verwijderd]

of Triple-DES encryptie : 3 voudige versleuteling (56bits per x)

[raptorix]

Mjah, je bent met een forum bezig niet met een banking application zou ik zeggen.

Zou zeggen sla het password op via MD5 Hash value en stop dat ook in het Cookie, das echt veilig zat voor een Forum.

[Verwijderd]

raptorix schreef op 26 August 2003 @ 12:18:
Mjah, je bent met een forum bezig niet met een banking application zou ik zeggen.

Zou zeggen sla het password op via MD5 Hash value en stop dat ook in het Cookie, das echt veilig zat voor een Forum.

Nee dat moet je dus ook niet doen.
Een md5 hash is ook te decoderen, alleen kost dit wel veel tijd.
Als je dus een md5 password in ee cookie opslaat kan een andere gebruiker(of een website+goed script) op die computer je md5 weghalen en gaan decoderen.

Ik gebruik zelf altijd sessies, het enige wat er dan op de computer van de gebruiker staat is dus de session_id.

Ik ga tewerk op de volgende manier

code:

1) gebruiker wil inloggen
2) ik kijk of username(plaintext)+password(md5) overeenkomen
3) als het overeenkomt start ik een sessie(gaat alleen voor
  het opslaan van een unieke code zonder veel moeite).
4) na het inloggen sla ik de session_id op in een db
  - session_id
  - user id
  - create timestamp
  - ip
  - lasthit timestamp

Hierdoor moet ook nog eens je IP gelijk zijn, dus als je de session_id zou veranderen, dan conteroleer je gewoon de gegevens in de database, komt het ip niet overeen? gelijk de entry verwijderen uit de database(dan bestaat de session_id dus gewoon niet meer, en kan je dus met die session_id niet meer inloggen).

[raptorix]

Verwijderd schreef op 26 August 2003 @ 12:41:
[...]

Nee dat moet je dus ook niet doen.
Een md5 hash is ook te decoderen, alleen kost dit wel veel tijd.
Als je dus een md5 password in ee cookie opslaat kan een andere gebruiker(of een website+goed script) op die computer je md5 weghalen en gaan decoderen.

Ik gebruik zelf altijd sessies, het enige wat er dan op de computer van de gebruiker staat is dus de session_id.

Ik ga tewerk op de volgende manier

code:

1) gebruiker wil inloggen
2) ik kijk of username(plaintext)+password(md5) overeenkomen
3) als het overeenkomt start ik een sessie(gaat alleen voor
  het opslaan van een unieke code zonder veel moeite).
4) na het inloggen sla ik de session_id op in een db
  - session_id
  - user id
  - create timestamp
  - ip
  - lasthit timestamp

Hierdoor moet ook nog eens je IP gelijk zijn, dus als je de session_id zou veranderen, dan conteroleer je gewoon de gegevens in de database, komt het ip niet overeen? gelijk de entry verwijderen uit de database(dan bestaat de session_id dus gewoon niet meer, en kan je dus met die session_id niet meer inloggen).

Gebruik je dan ook SSL?

[faabman]

Volgens mij heb je het hier over een internetapplicatie en kan je er dus niet van uit gaan dat al je gebruikers sessies / cookies hebben ingeschakeld

Dus, als je je applicatie voor al je bezoekers beschikbaar wilt stellen dan zul je of heel duidelijk aan moeten geven hoe cookies aangezet moeten worden (en dat is bijna onmogelijk aangezien elke nieuwe IE een andere manier heeft om dat te doen). Of je zult je eigen 'sessies' aan moeten maken (via je database)

[raptorix]

FvKnijff schreef op 26 August 2003 @ 13:03:
Volgens mij heb je het hier over een internetapplicatie en kan je er dus niet van uit gaan dat al je gebruikers sessies / cookies hebben ingeschakeld

Dus, als je je applicatie voor al je bezoekers beschikbaar wilt stellen dan zul je of heel duidelijk aan moeten geven hoe cookies aangezet moeten worden (en dat is bijna onmogelijk aangezien elke nieuwe IE een andere manier heeft om dat te doen). Of je zult je eigen 'sessies' aan moeten maken (via je database)

Mjah, mensen die hun cookies uitzetten, zullen er mee moeten leven dat het merendeel van de dynamische websites niet of slechts gedeeltelijk goed werkt.

Er is feitelijk geen enkel fatsoenlijke reden om cookies uit te zetten.

[whoami]

raptorix schreef op 26 August 2003 @ 13:14:
[...]


Mjah, mensen die hun cookies uitzetten, zullen er mee moeten leven dat het merendeel van de dynamische websites niet of slechts gedeeltelijk goed werkt.

In ASP.NET kan je probleemloos session-state ed bewaren zonder gebruik te maken van cookies.

[Verwijderd]

raptorix schreef op 26 August 2003 @ 12:52:
Gebruik je dan ook SSL?

Waarom dit? Het versturen van de inloggegevens is slechts eenmalig. vedder kan toch niemand zonder veel moeite dit systeem binnendringen.

FvKnijff schreef op 26 August 2003 @ 13:03:
Volgens mij heb je het hier over een internetapplicatie en kan je er dus niet van uit gaan dat al je gebruikers sessies / cookies hebben ingeschakeld

Sinds wanneer kan een gebruiker een sessie niet accepteren? Deze worden altijd geaccepteerd. Geen cookies? Dan via de url.

En dandaarbij als de gebruiker geen cookies accepteerd dan is dat toch niet mijn probleem? Wel dan?

whoami schreef op 26 August 2003 @ 13:22:
In ASP.NET kan je probleemloos session-state ed bewaren zonder gebruik te maken van cookies.

Ah dus dat kan ook nog, nouja ik programmeer script nooit met ASP(alleen php)

[ Voor 17% gewijzigd door Verwijderd op 26-08-2003 13:24 ]

[faabman]

raptorix schreef op 26 August 2003 @ 13:14:
[...]

Mjah, mensen die hun cookies uitzetten, zullen er mee moeten leven dat het merendeel van de dynamische websites niet of slechts gedeeltelijk goed werkt.

Er is feitelijk geen enkel fatsoenlijke reden om cookies uit te zetten.

offtopic:
Ben ik met je eens, maar, er zijn veel mensen die wel eens een computerblaadje lezen waarin staat dat ze cookies e.d. uit moeten zetten omdat hun compie anders in gevaar is...

Ik gebruik zelf eigenlijk ook overal wel cookies, maar, als je je bereik zo hoog mogelijk wilt houden moet je het gebruik van cookies voor op het internet zoveel mogelijk vermijden en alleen gebruiken in een omgeving die je beheerst (intranet) of een omgeving waarvan je van je gebruikers / bezoekers kan 'eisen' dat ze cookies aanzetten (extranet).

[whoami]

Verwijderd schreef op 26 August 2003 @ 13:22:
[...]

Ah dus dat kan ook nog, nouja ik programmeer script nooit met ASP(alleen php)

offtopic:
ASP.NET is echt wel programmeren hoor.