Het Wat heb jij vandaag geprogrammeerd? topic

Timkb schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Dionc schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Dionc schreef:

Waarom sla je de gebruikersnaam op in een session?

Je kan het beste de id gebruiken

Eh nee.
Dat is best onveilig
Altijd hash gebruiken welke moeilijk te raden is.

Stel, jouw website slaat je user id in een sessie.
Het is bèst makkelijk om achter een user id te komen op menig website.
En als ik ergens op jouw website een url tussen img tags zet, bijvoorbeeld
//reitsma.co/image.jpg
image.jpg kan bijvoorbeeld een script bevatten, en met rewrite url (nginx config of htaccess) kan je het bestand heel eenvoudig image.jpg noemen.

Als jij als admin nou mijn plaatje ziet, bijvoorbeeld in een privebericht of op het forum dan doe jij een request naar image.jpg
image.jpg is dan eigenlijk een script, met de headers van een image (en om het onschuldig te laten lijken geeft hij als output ook een image)
Wat dat script doet is jouw cookie opslaan (document.cookie) welke ook het PHPSESSIONID bevat, dan verander je jouw PHPSESSIONID cookie in dat van die admin op die website, en je hebt toegang tot de $_SESSION van de admin.

Wat je dus moet doen is, een hash als cookie of sessie gebruiken, en élke pageview moet je die hash selecteren uit de database en kijken of het ip adres + useragent gelijk is aan dat van de bezoeker dat de hash heeft.
Zo niet: direct uitloggen. (Niet direct blokkeren, kan zijn dat hij zijn browser geüpdatet heeft)

document.cookie kan je niet zomaar op alle websites uitvoeren, als een website overal beveiligd is tegen xss kan je altijd nog een browser extension maken (bijvoorbeeld voor chrome) en de admin deze laten installeren.
"Kijk eens, ik heb een coole make-over voor je website gemaakt, wat vind je?"
Veel mensen installeren dit wel, en na de eerste pageview heb jij dus als zijn cookies voor die website. Fuck u xss beveiliging.

TL;DR

Koppel een sessie aan een IP + useragent en sessie stelen wordt al een stuk lastiger. Dit kan via een database maar hoeft niet.
(Voorkom XSS lekken ook.)

Dus als de IP en useragent niet klopt gewoon laten uitloggen?

Ik zou IP eruit laten, er is niets irritanters als dat je in de trein zit en elke minuut opnieuw moet inloggen.

Dat had ik eerst ook op One2xs en DirectAdmin, op mijn eerdere werk vooral.
Die gebruikt dan ineens een ander ip.
Je moet het wel met ip doen, maar dan oudere sessies ook door laten lopen.
Dus als je ip1 hebt dat je inlogt, bij overshakeling maar ip2 log je opmieuw in en als je dan weer ip1 krijgt ben je weer ingelogd.

Ik kies bij dit soort situaties toch voor gemak over veiligheid, ik laat het IP (bijna) altijd buiten schot in mijn session manager class want het is super vervelend om steeds opnieuw te moeten inloggen. Als je toch zo nodig veilig bezig wilt zijn en session hijacking wilt voorkomen dan is SSL de way to go vind ik.

Pepijnownt schreef:

Nogmaals, je hebt gebruikers die niet weten wat dat inhoud!

Sevvlor schreef:

Eerdere citaten tonen

Pepijnownt schreef:

Nogmaals, je hebt gebruikers die niet weten wat dat inhoud!

Mag ik vragen wat je punt is? Er zullen altijd mensen zijn die sommige "instellingen" niet snappen.

Robiin schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Dionc schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Dionc schreef:

Waarom sla je de gebruikersnaam op in een session?

Je kan het beste de id gebruiken

Eh nee.
Dat is best onveilig
Altijd hash gebruiken welke moeilijk te raden is.

Stel, jouw website slaat je user id in een sessie.
Het is bèst makkelijk om achter een user id te komen op menig website.
En als ik ergens op jouw website een url tussen img tags zet, bijvoorbeeld
//reitsma.co/image.jpg
image.jpg kan bijvoorbeeld een script bevatten, en met rewrite url (nginx config of htaccess) kan je het bestand heel eenvoudig image.jpg noemen.

Als jij als admin nou mijn plaatje ziet, bijvoorbeeld in een privebericht of op het forum dan doe jij een request naar image.jpg
image.jpg is dan eigenlijk een script, met de headers van een image (en om het onschuldig te laten lijken geeft hij als output ook een image)
Wat dat script doet is jouw cookie opslaan (document.cookie) welke ook het PHPSESSIONID bevat, dan verander je jouw PHPSESSIONID cookie in dat van die admin op die website, en je hebt toegang tot de $_SESSION van de admin.

Wat je dus moet doen is, een hash als cookie of sessie gebruiken, en élke pageview moet je die hash selecteren uit de database en kijken of het ip adres + useragent gelijk is aan dat van de bezoeker dat de hash heeft.
Zo niet: direct uitloggen. (Niet direct blokkeren, kan zijn dat hij zijn browser geüpdatet heeft)

document.cookie kan je niet zomaar op alle websites uitvoeren, als een website overal beveiligd is tegen xss kan je altijd nog een browser extension maken (bijvoorbeeld voor chrome) en de admin deze laten installeren.
"Kijk eens, ik heb een coole make-over voor je website gemaakt, wat vind je?"
Veel mensen installeren dit wel, en na de eerste pageview heb jij dus als zijn cookies voor die website. Fuck u xss beveiliging.

TL;DR

Koppel een sessie aan een IP + useragent en sessie stelen wordt al een stuk lastiger. Dit kan via een database maar hoeft niet.
(Voorkom XSS lekken ook.)

Dus als de IP en useragent niet klopt gewoon laten uitloggen?

Ik zou IP eruit laten, er is niets irritanters als dat je in de trein zit en elke minuut opnieuw moet inloggen.

Dat had ik eerst ook op One2xs en DirectAdmin, op mijn eerdere werk vooral.
Die gebruikt dan ineens een ander ip.
Je moet het wel met ip doen, maar dan oudere sessies ook door laten lopen.
Dus als je ip1 hebt dat je inlogt, bij overshakeling maar ip2 log je opmieuw in en als je dan weer ip1 krijgt ben je weer ingelogd.

Ik kies bij dit soort situaties toch voor gemak over veiligheid, ik laat het IP (bijna) altijd buiten schot in mijn session manager class want het is super vervelend om steeds opnieuw te moeten inloggen. Als je toch zo nodig veilig bezig wilt zijn en session hijacking wilt voorkomen dan is SSL de way to go vind ik.

Ik begrijp je. Maar dan zou ik toch echt een uitzonderingen systeem inbouwen of bij het inloggen een checkbox met de vraag of je op IP wil inloggen.

Xjessex schreef:

Eerdere citaten tonen

Timkb schreef:

Eerdere citaten tonen

Dionc schreef:

Eerdere citaten tonen

Sevvlor schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Dionc schreef:

Waarom sla je de gebruikersnaam op in een session?

Je kan het beste de id gebruiken

Eh nee.
Dat is best onveilig
Altijd hash gebruiken welke moeilijk te raden is.

Stel, jouw website slaat je user id in een sessie.
Het is bèst makkelijk om achter een user id te komen op menig website.
En als ik ergens op jouw website een url tussen img tags zet, bijvoorbeeld
//reitsma.co/image.jpg
image.jpg kan bijvoorbeeld een script bevatten, en met rewrite url (nginx config of htaccess) kan je het bestand heel eenvoudig image.jpg noemen.

Als jij als admin nou mijn plaatje ziet, bijvoorbeeld in een privebericht of op het forum dan doe jij een request naar image.jpg
image.jpg is dan eigenlijk een script, met de headers van een image (en om het onschuldig te laten lijken geeft hij als output ook een image)
Wat dat script doet is jouw cookie opslaan (document.cookie) welke ook het PHPSESSIONID bevat, dan verander je jouw PHPSESSIONID cookie in dat van die admin op die website, en je hebt toegang tot de $_SESSION van de admin.

Wat je dus moet doen is, een hash als cookie of sessie gebruiken, en élke pageview moet je die hash selecteren uit de database en kijken of het ip adres + useragent gelijk is aan dat van de bezoeker dat de hash heeft.
Zo niet: direct uitloggen. (Niet direct blokkeren, kan zijn dat hij zijn browser geüpdatet heeft)

document.cookie kan je niet zomaar op alle websites uitvoeren, als een website overal beveiligd is tegen xss kan je altijd nog een browser extension maken (bijvoorbeeld voor chrome) en de admin deze laten installeren.
"Kijk eens, ik heb een coole make-over voor je website gemaakt, wat vind je?"
Veel mensen installeren dit wel, en na de eerste pageview heb jij dus als zijn cookies voor die website. Fuck u xss beveiliging.

TL;DR

Koppel een sessie aan een IP + useragent en sessie stelen wordt al een stuk lastiger. Dit kan via een database maar hoeft niet.
(Voorkom XSS lekken ook.)

Dus als de IP en useragent niet klopt gewoon laten uitloggen?

Ik zou IP eruit laten, er is niets irritanters als dat je in de trein zit en elke minuut opnieuw moet inloggen.

Dat had ik eerst ook op One2xs en DirectAdmin, op mijn eerdere werk vooral.
Die gebruikt dan ineens een ander ip.
Je moet het wel met ip doen, maar dan oudere sessies ook door laten lopen.
Dus als je ip1 hebt dat je inlogt, bij overshakeling maar ip2 log je opmieuw in en als je dan weer ip1 krijgt ben je weer ingelogd.

Pepijnownt schreef:

Inderdaad, volgens mij zit er een heel beveiligings-systeem in, als ik met hetzelfde ip een account aanmaak, krijg(t)(e)n de beheerder(s) een bericht.
Zelfde geld bij een DoS, je wordt gelijk geblokkeerd en je account ook.

Zit een heel systeem achter met VELEN functies