Het Wat heb jij vandaag geprogrammeerd? topic

Sevvlor schreef:

Eerdere citaten tonen

Dionc schreef:

Eerdere citaten tonen

Sevvlor 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?

Yep, helemaal.

Oke bedankt

Overigens ben ik erg benieuwd hoe je het gaat oplossen.

Dionc schreef:

Eerdere citaten tonen

Robindb schreef:

Eerdere citaten tonen

Dionc schreef:

Waarom sla je de gebruikersnaam op in een session?

Je kan het beste de id gebruiken

hij haalt de gebruikers naam uit de sessie door middel van een id

if($data[founds] != 0) {
            $result = $mysql->query("SELECT id, username FROM users WHERE username = ".$mysql->real_escape_string($_POST[username])." LIMIT 1");
            $result = $result->fetch_assoc();
           
            $_SESSION[id] = $result[id];
            $_SESSION[username] = $result[username];
            header("Location: index.php");

Maar dan snap ik niet waarom je dan een sessie maakt met de username
Je kan hem dan toch gewoon ophalen uit de database?

Want als je de gebruikersnaam veranderd dan toont ie de oude aan totdat je uitlogt
En als je die sessie gebruikt om dingen op te slaan in de DB dan klopt het niet meer als je eenmaal de naam hebt gewijzigd...

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.)

Dylanh schreef:

@Jesse, hoe wou je met php een image outputen (dus Content-Type: image/png bijv) en ook nog document.cookie (wat javascript is) opslaan?

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?

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.

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.

Sevvlor 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.

In mijn huidige systeem heb ik er voor gekozen om dat niet te doen. Dat omdat ik alle mogelijke session hijacks wil voorkomen.

Pepijnownt schreef:

Er zijn altijd mensen met een dynamische ip range, zoals treinen

Pepijnownt schreef:

Niet iedereen is slim met internet.

Pepijnownt schreef:

Er zijn altijd mensen met een dynamische ip range, zoals treinen

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.