Toon posts:

Veiligheid GET/POST bij uitlog functie *

Pagina: 1 2 Laatste
Acties:

  • korgakos
  • Registratie: April 2008
  • Laatst online: 03-02 12:28
Wat ikzelf een echte "fail" vond is dat op de site van mijn school. (Hogeschool Zuyd) Een logout knopje aanwezig was. Als je erop klikte (met andere woorden je logt je dan uit)dan kreeg je (op de homepage) in de URL een logout=1 o.i.d. te zien, veranderde je de 1 naar 0, dan was je weer ingelogd..

Ik deze "fail" gemeld bij de ICT maar daar zeiden ze dat het geen issue was en niet onveilig was..blablaba blaat..*

En een tijd erna was opeens de logout knop verdwenen (hmm i wonder why (A))

Modbreak:Dit topic is afgesplitst van [alg] Slechtste programmeervoorbeelden deel 4

[Voor 28% gewijzigd door Woy op 24-03-2010 12:04]


  • netvor
  • Registratie: September 2000
  • Laatst online: 26-11-2021
@korgakos: De logout-knop was dus een link als http://foo/index.bar?logout=1 ? Dan kan ik de reactie van de beheerders goed begrijpen; jij als gebruiker kan natuurlijk de hacker uithangen en die URL veranderen naar logout=0, maar dat is dan functioneel gelijk aan gewoon naar de index-pagina surfen, of überhaupt niet op de logout-knop klikken. Geen enkel beveiligingsprobleem toch :?

Computer Science: describing our world with boxes and arrows.


  • roy-t
  • Registratie: Oktober 2004
  • Laatst online: 26-01 13:37
netvor schreef op maandag 22 maart 2010 @ 10:38:
@korgakos: De logout-knop was dus een link als http://foo/index.bar?logout=1 ? Dan kan ik de reactie van de beheerders goed begrijpen; jij als gebruiker kan natuurlijk de hacker uithangen en die URL veranderen naar logout=0, maar dat is dan functioneel gelijk aan gewoon naar de index-pagina surfen, of überhaupt niet op de logout-knop klikken. Geen enkel beveiligingsprobleem toch :?
Jij logt uit op een publieke computer, (zeg een webkiosk, zoals die bij de rug en hanze in de kantine staan) de volgende persoon navigeert weer naar de main pagina, zet er
?logout=0 achter en kan verder met de vorige sessie, want deze wordt blijkbaar niet verwijderd (of niet direct iig).

~ Mijn prog blog! ~ @RoyTries


  • korgakos
  • Registratie: April 2008
  • Laatst online: 03-02 12:28
netvor schreef op maandag 22 maart 2010 @ 10:38:
@korgakos: De logout-knop was dus een link als http://foo/index.bar?logout=1 ? Dan kan ik de reactie van de beheerders goed begrijpen; jij als gebruiker kan natuurlijk de hacker uithangen en die URL veranderen naar logout=0, maar dat is dan functioneel gelijk aan gewoon naar de index-pagina surfen, of überhaupt niet op de logout-knop klikken. Geen enkel beveiligingsprobleem toch :?
Precies wat roy zegt :) het gaat dan vooral om een publieke computer. Of als je bij iemand anders even inlogt.

Maar gewoon, ik vind het slordig en het kan gewoon anders...

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

@netvor: Dat neem je aan. Hoewel je best gelijk kan hebben gaf Korgakos aan dat je weer ingelogd was. Als je daadwerkelijk uitgelogd leek, maar door later nog een keer de url met logout=0 te doen je weer inlogde, dan was er wel degelijk sprake van een behoorlijk security probleem.

-- hmm, spuit 11 :)

Maar goed. Niet alleen is het voor de gebruikers erg onveilig, het geeft ook een beetje insight in de werking van de code. En dat ziet er niet al te best uit eigenlijk. Nogmaals aannemende dat het verhaal van Korgakos klopt dan zou het heel goed kunenn dat ze niet de sessie invalideren, maar dat er in de sessie gewoon een boolean 'uitgelogd' zit waar je middels de url zo een aanpassing in kunt maken. Gezien de code kwaliteit zou het mij niks verbazen dat er op andere plekken vergeten is op deze boolean te checken en je dus nog steeds allemaal content van de vorige gebruiker zou kunnen benaderen.

Maar nogmaals. Dit alles is puur speculatief en gebaseerd op behoorlijk wat aannames.

[Voor 55% gewijzigd door Janoz op 22-03-2010 10:47]

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Davio
  • Registratie: November 2007
  • Laatst online: 29-07-2022
roy-t schreef op maandag 22 maart 2010 @ 10:41:
[...]


Jij logt uit op een publieke computer, (zeg een webkiosk, zoals die bij de rug en hanze in de kantine staan) de volgende persoon navigeert weer naar de main pagina, zet er
?logout=0 achter en kan verder met de vorige sessie, want deze wordt blijkbaar niet verwijderd (of niet direct iig).
Daarbij moet je natuurlijk zoveel mogelijk van je login-procedure onder water houden.

En nodigt zo'n variabele in de URL niet erg uit tot SQL-injection?

  • netvor
  • Registratie: September 2000
  • Laatst online: 26-11-2021
Aha... je bedoelt dat als ik na het submitten van mijn "?logout=1" de URL "?logout=0" invoer, dat ik dan gewoon weer verder ga met de vorige session? Okee, dat is dan wel even iets anders. Ik dacht dat de korgakos bedoelde dat hij tijdens het submitten van de logout de url kon wijzigen.

Om verder nog even advocaat van de duivel te spelen: het is niet toevallig de situatie dat bij het invoeren van de "?logout=0" de server en de client een nieuwe SSO handshake doen en dat je dus netjes een nieuwe sessionID krijgt? })

Maar verder: session handling en intranet-apps is al jaren een bron van Fail. Bijvoorbeeld de "feature" in ASP.NET dat de gebruiker zelf zijn eigen sessionID kan kiezen, zolang deze maar de juiste lengte heeft. Weer een stapje dichterbij een session fixation attack. :/

Computer Science: describing our world with boxes and arrows.


  • BarôZZa
  • Registratie: Januari 2003
  • Laatst online: 00:50
Bij een logout moet je in mijn ogen altijd een unieke key meegeven, anders kan je iedereen laten uitloggen. Als het op een forum is waar je plaatjes kan posten kan je vaak zelfs het volgende doen:
code:
1
[img]http://foo/index.bar?logout=1[/img]


Ik heb dat al meerdere keren gezien op fora. Waarbij je bijvoorbeeld op iemands profiel dat kon doen, waarbij diegene telkens uitlogde wanneer hij/zij op z'n profiel keek. Of een topic met zoiets erin.

Sowieso zijn veel sites waardeloos wanneer het gaat om XSS zaken. Zelfs die schreeuwpieten van GeenStijl waren gevoelig voor XSS. Kan/kon je iedereen die ingelogd was automagisch iets laten posten.

[Voor 17% gewijzigd door BarôZZa op 23-03-2010 14:54]


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

BarôZZa schreef op dinsdag 23 maart 2010 @ 14:51:
Bij een logout moet je in mijn ogen altijd een unieke key meegeven, anders kan je iedereen laten uitloggen. Als het op een forum is waar je plaatjes kan posten kan je vaak zelfs het volgende doen:
code:
1
[img]http://foo/index.bar?logout=1[/img]


Ik heb dat al meerdere keren gezien op fora. Waarbij je bijvoorbeeld op iemands profiel dat kon doen, waarbij diegene telkens uitlogde wanneer hij/zij op z'n profiel keek. Of een topic met zoiets erin.

Sowieso zijn veel sites waardeloos wanneer het gaat om XSS zaken. Zelfs die schreeuwpieten van GeenStijl waren gevoelig voor XSS. Kan/kon je iedereen die ingelogd was automagisch iets laten posten.
Het probleem klopt, alleen is de oplossing 'fout'. Om een dergelijk probleem op te lossen moet je niet eerst met een key aankomen, maar moet je een POST gebruiken ipv een GET.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Klopt dat het POST zou moeten zijn, maar dan kan ik met wat javascript op mijn eigen site waar ik jou naartoe lok jou alsnog uit laten loggen. Goed, het probleem is dan al wat minder ernstig, maar de key blijft imho gewoon nodig.

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

Vandaar ook de quotes om fout en de "eerst" in de tweede zin. Pas nadat je het logout request alleen maar met een POST afhandeld ga je verder kijken of het eventueel ook nodig is dat een key meegegeven zou moeten worden.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • netvor
  • Registratie: September 2000
  • Laatst online: 26-11-2021
Dit is niet zozeer een voorbeeld van XSS, maar van CSRF (cross-site request forgery); XSS is een van de methodes om CSRF uit te voeren. Maar de grens is wazig en anyway, what's in a name. :)

Punt blijft dat CSRF een vervelend probleem is. Het staat niet voor niets op nummer 4 van de laatste CWE top25. Toch is het redelijk goed op te lossen met nonces of tokens of hoe die dingen heten... tenzij je app vatbaar is voor XSS, dan kan je die nonce natuurlijk makkelijk uit de DOM halen.

offtopic:
Ik ben in Utrecht opgegroeid, en bij zinsnedes als "uit de DOM halen" flitst de domtoren O+ telkens hardnekkig door mijn hoofd :+

Computer Science: describing our world with boxes and arrows.


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

netvor schreef op dinsdag 23 maart 2010 @ 15:33:
Dit is niet zozeer een voorbeeld van XSS, maar van CSRF
Ik ben even confuus, wie beweerde dat precies? ;)

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Zou dit niet opgelost kunnen worden op HTTP/HTML niveau?

  • Sebazzz
  • Registratie: September 2006
  • Laatst online: 17:48
Olaf van der Spek schreef op dinsdag 23 maart 2010 @ 18:04:
Zou dit niet opgelost kunnen worden op HTTP/HTML niveau?
Uhm, HTML is een standaard voor webdocumenten over HTTP. HTTP is een netwerkprotocol. Que?

[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]


  • Matis
  • Registratie: Januari 2007
  • Laatst online: 17:50

Matis

Rubber Rocket

.oisyn schreef op dinsdag 23 maart 2010 @ 15:34:
Ik ben even confuus, wie beweerde dat precies? ;)
BarôZZa in "[alg] Slechtste programmeervoorbeelden d..."

Niemand beweerde wat, alleen werd even aangegeven dat een hoop sites gevoelig zijn op XSS. Wat netvor probeert aan te geven, is dat XSS niet de juiste terminologie, maar CSRF bedoeld werd.

Althans, zo denk ik.

If money talks then I'm a mime
If time is money then I'm out of time


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Sebazzz schreef op dinsdag 23 maart 2010 @ 18:22:
Uhm, HTML is een standaard voor webdocumenten over HTTP. HTTP is een netwerkprotocol. Que?
Eh, ja? En?

  • RetroTycoon
  • Registratie: Juli 2008
  • Laatst online: 18:15
Toch... hoe word je dan geacht een uitlogoptie te maken? Ik trigger zelf vaak via een if(isset(logout)) en die stuur ik dan sessievrij door. Bad practice?

  • Anoniem: 156876
  • Registratie: Oktober 2005
  • Niet online
RetroTycoon schreef op dinsdag 23 maart 2010 @ 20:57:
Toch... hoe word je dan geacht een uitlogoptie te maken? Ik trigger zelf vaak via een if(isset(logout)) en die stuur ik dan sessievrij door. Bad practice?
Hoe bedoel je sessievrij, verwijder je de hele sessie? :+

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
RetroTycoon schreef op dinsdag 23 maart 2010 @ 20:57:
Toch... hoe word je dan geacht een uitlogoptie te maken? Ik trigger zelf vaak via een if(isset(logout)) en die stuur ik dan sessievrij door. Bad practice?
Ik zou er een redirect tussen zetten.

  • BarôZZa
  • Registratie: Januari 2003
  • Laatst online: 00:50
Janoz schreef op dinsdag 23 maart 2010 @ 15:04:
[...]

Het probleem klopt, alleen is de oplossing 'fout'. Om een dergelijk probleem op te lossen moet je niet eerst met een key aankomen, maar moet je een POST gebruiken ipv een GET.
Het probleem is dat je een gebruiker kan laten uitloggen als je geen key gebruikt, of dat nu via POST of GET is. Met een key maakt het eigenlijk niet uit welke van de twee je gebruikt. GET is gemakkelijk voor een tekst link om uit te loggen.

  • Davio
  • Registratie: November 2007
  • Laatst online: 29-07-2022
Olaf van der Spek schreef op dinsdag 23 maart 2010 @ 21:54:
[...]

Ik zou er een redirect tussen zetten.
Ja, je kan toch gewoon een speciale logout-pagina maken en een button of link daarnaartoe verwijzen?

a href = logout.php.

Dan kan je op die pagina alles afhandelen zonder dat je laat zien hoe je dat precies doet, dus zonder gekke variabelen...

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Als ik ergens op een forum oid zet: [img]http://jouwsite.example.com/logout.php[/img] dan is iedereen die dat 'plaatje' probeert te openen opeens uitgelogd.

Okay, er zijn ergere dingen op de wereld, maar je kan het eenvoudig voorkomen.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

BarôZZa schreef op dinsdag 23 maart 2010 @ 22:05:
[...]

Het probleem is dat je een gebruiker kan laten uitloggen als je geen key gebruikt, of dat nu via POST of GET is. Met een key maakt het eigenlijk niet uit welke van de twee je gebruikt. GET is gemakkelijk voor een tekst link om uit te loggen.
Nogmaals, een GET is in deze fout. GET is bedoeld voor idempotente acties. Dat wil zeggen, acties die niks aan de state veranderen. Acties die, wanneer ze meerdere keren aangeroepen worden, geen invloed hebben op de bron*. Met een uiltog actie wordt wel degelijk state veranderd en daarvoor zul je dus een POST moeten gebruiken.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Anoniem: 343818

RetroTycoon schreef op dinsdag 23 maart 2010 @ 20:57:
Toch... hoe word je dan geacht een uitlogoptie te maken? Ik trigger zelf vaak via een if(isset(logout)) en die stuur ik dan sessievrij door. Bad practice?
In princiepe behoor je gewoon een pagina aan te maken, te vragen of ze er zeker van zijn of ze willen uitloggen, een unieke HASH/Key maken die iedere keer anders is, die in de sessie te stoppen, ze het via POST laten versturen en kijken of de Key overeenkomt. Is dat niet het geval, is er een geval geweest van CSRF.

Als je, zoals "men" "vroeger" vaak deden het allemaal via een GET-request laat afhandelen, ben je de sjaak. Een simpele request laten zien op jouw website, of nog erger via de website zelf (een bug dus) en iedereen die op die pagina komt is uitgelogd :P

Edit: Sorry Janoz, zag niet dat jij ook al had gereageerd |:(

[Voor 4% gewijzigd door Anoniem: 343818 op 24-03-2010 09:48]


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Anoniem: 343818 schreef op woensdag 24 maart 2010 @ 09:46:
[...]
In princiepe behoor je gewoon een pagina aan te maken, te vragen of ze er zeker van zijn of ze willen uitloggen, een unieke HASH/Key maken die iedere keer anders is, die in de sessie te stoppen, ze het via POST laten versturen en kijken of de Key overeenkomt. Is dat niet het geval, is er een geval geweest van CSRF.
Ik weet niet precies welke rechten Javascript allemaal heeft wat betreft connecties naar andere hosts, maar die key helpt natuurlijk niet zo zeer tegen CSRF, want een javascriptje kan gewoon die pagina ophalen, key eruithalen, en die key via POST doorsturen.

Zoals gezegd moet je inderdaad geen GET gebruiken want dan is het misbruik wel erg makkelijk.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Technicality
  • Registratie: Juni 2004
  • Laatst online: 04-02 14:16

Technicality

Vliegt rechtsom...

Woy schreef op woensdag 24 maart 2010 @ 10:08:
[...]

Ik weet niet precies welke rechten Javascript allemaal heeft wat betreft connecties naar andere hosts, maar die key helpt natuurlijk niet zo zeer tegen CSRF, want een javascriptje kan gewoon die pagina ophalen, key eruithalen, en die key via POST doorsturen.

Zoals gezegd moet je inderdaad geen GET gebruiken want dan is het misbruik wel erg makkelijk.
Ik had nog nooit stilgestaand bij dit hele punt, maar wat is dan wél een nette oplossing?

  • T-MOB
  • Registratie: Maart 2001
  • Laatst online: 10:45

T-MOB

Echte chocomel eerst!

Woy schreef op woensdag 24 maart 2010 @ 10:08:
[...]
Ik weet niet precies welke rechten Javascript allemaal heeft wat betreft connecties naar andere hosts, maar die key helpt natuurlijk niet zo zeer tegen CSRF, want een javascriptje kan gewoon die pagina ophalen, key eruithalen, en die key via POST doorsturen.
Als dit met javascript zou kunnen dan heb je een ontzettend lekke browser. Niets dat je dan in de weg zou staan om een script op je site te zetten dat iemands Gmail uitleest.

Falling isn't flying \ Floating isn't infinite


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
T-MOB schreef op woensdag 24 maart 2010 @ 10:37:
[...]
Als dit met javascript zou kunnen dan heb je een ontzettend lekke browser. Niets dat je dan in de weg zou staan om een script op je site te zetten dat iemands Gmail uitleest.
Volgens mij zijn er geen restricties op het opvragen en posten naar een pagina in javascript. Wat ik me wel bedenk is dat je met dat stukje javascript natuurlijk niet de cookies van de huidige sessie meestuurt, en je dus geen andere sessie uit kan lezen, en dus ook niet uit kunt loggen.

Maar het lijkt me dat dat bij elke uitlogpagina via een POST request gewoon zo is. Je zou dan al XSS toegepast moeten hebben om uit te kunnen loggen lijkt me.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Woy schreef op woensdag 24 maart 2010 @ 10:44:
Volgens mij zijn er geen restricties op het opvragen en posten naar een pagina in javascript.
Ik dacht het wel.
Wat ik me wel bedenk is dat je met dat stukje javascript natuurlijk niet de cookies van de huidige sessie meestuurt, en je dus geen andere sessie uit kan lezen, en dus ook niet uit kunt loggen.

Maar het lijkt me dat dat bij elke uitlogpagina via een POST request gewoon zo is. Je zou dan al XSS toegepast moeten hebben om uit te kunnen loggen lijkt me.
Dat is juist weer niet zo (helaas). Zodra een request wordt gedaan naar een bepaalde host, worden automatisch de cookies van die host meegestuurd. Dit zijn eigenlijk third-party cookies. Zouden dit soort trucs niet meer werken als third-party cookies worden uitgeschakeld?

[Voor 7% gewijzigd door Olaf van der Spek op 24-03-2010 10:57]


  • Technicality
  • Registratie: Juni 2004
  • Laatst online: 04-02 14:16

Technicality

Vliegt rechtsom...

Hoe doet t.net dit? Kun naar de logoutpagina posten (met JS vanaf je eigen site bijvoorbeeld) dusdanig dat iemand uitgelogd is? Zo niet, hoe hebben ze dat gefixed?
Ik kan me voorstellen dat ze dat niet willen delen met ons. Verdient dit niet onderhand zijn eigen topic?

edit: nog iets verder teruglezen in dit topic en kom tot de conclusie dat het beste/enige wat je kan doen is POSTen (eventueel met een key)

[Voor 20% gewijzigd door Technicality op 24-03-2010 11:03]


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Het zou kunnen hoor. Ik ben niet zo thuis in web-development. Maar ik dacht dat dingen als AddWords ook gewoon via javascript hun content ophaalden bij de google servers.
Dat is juist weer niet zo (helaas). Zodra een request wordt gedaan naar een bepaalde host, worden automatisch de cookies van die host meegestuurd. Dit zijn eigenlijk third-party cookies. Zouden dit soort trucs niet meer werken als third-party cookies worden uitgeschakeld?
Het lijkt me in ieder geval dat als je alleen de cookies van de huidige pagina/domein meegeeft dat je geen dingen uit een sessie van een andere site kan plukken.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
Technicality schreef op woensdag 24 maart 2010 @ 10:21:
[...]

Ik had nog nooit stilgestaand bij dit hele punt, maar wat is dan wél een nette oplossing?
ik zou een beginnen met het valideren van die imgtags. /logout is geen .jpg oid.

Aunt bunny is coming to get me!


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

Woy schreef op woensdag 24 maart 2010 @ 11:12:
Het zou kunnen hoor. Ik ben niet zo thuis in web-development. Maar ik dacht dat dingen als AddWords ook gewoon via javascript hun content ophaalden bij de google servers.
Het google script komt bij google vandaan en mag daarom verbinden met google. Het script staat op de pagina zelf en mag daarom bij de (dom van de) pagina.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Matis
  • Registratie: Januari 2007
  • Laatst online: 17:50

Matis

Rubber Rocket

Bij Tweakers gebruiken ze daar http://tweakers.net/my.tnet/sessions voor. Die unieke sleutel is alleen bij jou (middels een cookie) en bij GoT-middels een DB-entry bekend.

Aangezien andere sites niet bij GoT-cookies kan, moet het dus wel een GoT-actie zijn. Er wordt nergens met een uitlogID (oid) gewerkt. GoT verwijdert je cookie met daarin je sessionID en verwijderd (misschien) ook je sessionID uit de database. Dan ben je uitgelogd, dat is ook de enige manier waarop GoT verifieert dat je aangemeld bent.

Als ik jou nu mijn sessionID zou geven, dan zou jij alles van mij kunnen aanpassen en gebruiken.

If money talks then I'm a mime
If time is money then I'm out of time


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

iH8 schreef op woensdag 24 maart 2010 @ 11:14:
[...]


ik zou een beginnen met het valideren van die imgtags. /logout is geen .jpg oid.
*BUZZ* wrong. Er zijn genoeg valide plaatjes op het internet die keurig te bereiken zijn via een url die niet eindigd op een bekende image extentie. En ookal staat er een plaatje, dan kan de 'hacker' deze alsnog snel vervangen door een redirect header die alsnog naar de /logout url gaat.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
Janoz schreef op woensdag 24 maart 2010 @ 11:17:
[...]

*BUZZ* wrong. Er zijn genoeg valide plaatjes op het internet die keurig te bereiken zijn via een url die niet eindigd op een bekende image extentie. En ookal staat er een plaatje, dan kan de 'hacker' deze alsnog snel vervangen door een redirect header die alsnog naar de /logout url gaat.
Ik zeg beginnen met hè? Als ik iemand een image laat posten dan zorgen ze maar dat het iig de extensie van een image heeft. Er zijn inderdaad ook valide images zonder of met afwijkende extensie. Wie zegt dat ik die accepteren moet? Er zijn wel meer dingen die "gewoon voorkomen" op het internet. Betekent niet dat jij als developer overal maar mee akkoord hoeft te gaan. Dat er buiten dat een valide url & extensie nog tig manieren zijn om zaken uit te buiten dat weet ik. Ik zeg beginnen met, ik noem dat good practice.

[Voor 2% gewijzigd door iH8 op 24-03-2010 11:26. Reden: wat geucfirst etc]

Aunt bunny is coming to get me!


  • mithras
  • Registratie: Maart 2003
  • Niet online
Met extensies bereik je niets. Leg het dan een (klein) stapje hoger en kijk op mime/type niveau :)

  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
mithras schreef op woensdag 24 maart 2010 @ 11:25:
Met extensies bereik je niets. Leg het dan een (klein) stapje hoger en kijk op mime/type niveau :)
Ik weet 't hoor, en dan kan het nog mis. Ik zei beginnen met, het een sluit het ander niet uit

Aunt bunny is coming to get me!


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Woy schreef op woensdag 24 maart 2010 @ 10:44:
[...]

Volgens mij zijn er geen restricties op het opvragen en posten naar een pagina in javascript.
XHR mag alleen naar het domein waar het script vandaan komt. Een andere mogelijkheid om te posten is middels een HTML form, maar dan kan het script weer niet bij het resultaat (ook niet via een hidden iframe oid), dus als er bij de POST ook nog een nonce of id vereist is is er geen manier om de logout te forgen.

@iH8: checken op extensie lijkt me de stomste beveiliging die er is. Je hebt zowel false positives als false negatives, dus je hebt er in de regel niets aan. Niet eens mee beginnen dus.

[Voor 19% gewijzigd door .oisyn op 24-03-2010 11:42]

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
iH8 schreef op woensdag 24 maart 2010 @ 11:23:
Ik zeg beginnen met hè? Als ik iemand een image laat posten dan zorgen ze maar dat het iig de extensie van een image heeft. Er zijn inderdaad ook valide images zonder of met afwijkende extensie. Wie zegt dat ik die accepteren moet?
Wat heb ik een hekel aan developers die gebruikers dwingen dat soort domme dingen te doen...

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Woy schreef op woensdag 24 maart 2010 @ 11:12:
Het lijkt me in ieder geval dat als je alleen de cookies van de huidige pagina/domein meegeeft dat je geen dingen uit een sessie van een andere site kan plukken.
Nope. Als ik een img include van images.net, dan worden bij het request de cookies van images.net meegestuurd en niet de cookies van de pagina waar het image op staat.

  • Matis
  • Registratie: Januari 2007
  • Laatst online: 17:50

Matis

Rubber Rocket

Olaf van der Spek schreef op woensdag 24 maart 2010 @ 11:38:
Wat heb ik een hekel aan developers die gebruikers dwingen dat soort domme dingen te doen...
Idd, ik kan ook prima in een PNG-afbeelding nog 100 dingen doen voordat de uiteindelijke PNG geserveerd wordt in (bijvoorbeeld) php.

If money talks then I'm a mime
If time is money then I'm out of time


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
Olaf van der Spek schreef op woensdag 24 maart 2010 @ 11:38:
[...]

Wat heb ik een hekel aan developers die gebruikers dwingen dat soort domme dingen te doen...
Kan aan mij liggen hoor, maar ik zie echt het probleem niet. Ik ben best wel anal over userinput en ontvang daar alleen maar lof over. Ik heb nog geen klachten gehad in ieder geval en mochten die er komen dan versoepel ik waar nodig. De klant is en blijft koning maar mijn default setups zitten zo dicht mogelijk. Better safe then sorry.

@Oisyn: Ik gaf maar een voorbeeld ter illustratie. Je kunt de eventuele consequenties van het tonen van corrupte userinput voor een groot deel voorkomen door te zorgen dat een user die input niet eens posten kan. Ik hoef hier de voordelen van validatie toch niet uit te leggen of word ik nu gek?

[Voor 20% gewijzigd door iH8 op 24-03-2010 11:55]

Aunt bunny is coming to get me!


  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

iH8, het probleem met jouw validatie is dat je die legt bij de mogelijke kwaadwillende ipv bij de kwetsbare plek.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Maar ondertussen gaat het compleet aan je voorbij dat het een schijnveiligheid is dat niets oplost. Leuk dat je klanten geen klachten hebben, maar dat betekent nog niet dat je systeem verantwoord is. Als ik op een website, als "extra beveiliging" een vinkje toevoeg met het kopje "hiermee verklaar ik de persoon te zijn die ik zeg te zijn" hoeven klanten ook geen klachten te hebben. Maar in de werkelijkheid voegt het niets toe.

en het is "than"

[Voor 32% gewijzigd door .oisyn op 24-03-2010 11:52]

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
.oisyn schreef op woensdag 24 maart 2010 @ 11:34:
[...]
XHR mag alleen naar het domein waar het script vandaan komt. Een andere mogelijkheid om te posten is middels een HTML form, maar dan kan het script weer niet bij het resultaat (ook niet via een hidden iframe oid), dus als er bij de POST ook nog een nonce of id vereist is is er geen manier om de logout te forgen.
Dat is wel een logische regel ja. Maar hoe zit dat precies als je meerdere script files include in een pagina hebt? In principe kan de code uit de ene file toch functies aanroepen uit de andere file?

Geeft het dan geen veiligheidsrisico als je een functie hebt die een XHR doet aan de hand van de parameters die meegegeven worden?

[Voor 5% gewijzigd door Woy op 24-03-2010 12:06]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

iH8 schreef op woensdag 24 maart 2010 @ 11:48:
@Oisyn: Ik gaf maar een voorbeeld ter illustratie. Je kunt de eventuele consequenties van het tonen van corrupte userinput voor een groot deel voorkomen door te zorgen dat een user die input niet eens posten kan. Ik hoef hier de voordelen van validatie toch niet uit te leggen of word ik nu gek?
De discussie ging over het forgen van een logout, en dat dat kon door een plaatje te posten naar de logout link. Jouw Beveiliging™ was vervolgens om de userinput te controleren op extensie. Je hebt misschien je redenen om dat te doen, maar beveiliging tegen request forging is het niet en moet om dus ook niet om die reden ingezet worden, dát is waar iedereen over valt hier. Dit nog even naast het feit dat een extensie niets zegt over de inhoud van de link, en het controleren daarop dus eigenlijk sowieso nutteloos is.

Overigens is het natuurlijk wel een vorm van job security - als er straks een nieuw plaatjesformaat de nieuwe standaard wordt word jij immers weer ingehuurd om al je software aan te passen om de nieuwe extensie te ondersteunen ;)

[Voor 19% gewijzigd door .oisyn op 24-03-2010 12:03]

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
.oisyn schreef op woensdag 24 maart 2010 @ 11:51:
Maar ondertussen gaat het compleet aan je voorbij dat het een schijnveiligheid is dat niets oplost. Leuk dat je klanten geen klachten hebben, maar dat betekent nog niet dat je systeem verantwoord is. Als ik op een website, als "extra beveiliging" een vinkje toevoeg met het kopje "hiermee verklaar ik de persoon te zijn die ik zeg te zijn" hoeven klanten ook geen klachten te hebben. Maar in de werkelijkheid voegt het niets toe.

en het is "than"
Ik zeg alleen dat ik de slimmerik die denkt een image als /logout te posten te snel af was geweest door een simpele check op correcte extensie. Dan heb ik toch gelijk? Nu kan iedereen hier over elkaar heen vallen door mij proberen te leren dat dat qua beveiliging niets voor stelt, dat WEET ik. Ik controleer zelf helemaal niet op extensie, ik gaf een simpel voorbeeld. Een verkeerd voorbeeld blijkbaar, point taken.

Aunt bunny is coming to get me!


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

Ik denk dat de toegenomen 'veiligheid' bij het checken op extentie compleet niet opweegt tegen de toegenomen gebruikers onvriendelijkheid. Eventueel zou je een head of een get kunnen doen om te zien of je een plaatje terug krijgt, maar dat is enkel een moment opname.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Matis schreef op woensdag 24 maart 2010 @ 11:42:
Idd, ik kan ook prima in een PNG-afbeelding nog 100 dingen doen voordat de uiteindelijke PNG geserveerd wordt in (bijvoorbeeld) php.
Client-side? Of wilde je je eigen server hacken ofzo? :p

[Voor 7% gewijzigd door Olaf van der Spek op 24-03-2010 12:08]


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
iH8 schreef op woensdag 24 maart 2010 @ 11:48:
Kan aan mij liggen hoor, maar ik zie echt het probleem niet.
Dat is het hele probleem. Heb je bijvoorbeeld .jpeg, moet je dat hernoemen naar .jpg omdat je het anders niet kunt uploaden (bijvoorbeeld).
Je kunt het wel veranderen zodra je een klacht krijgt, maar dat is eigenlijk al een klacht teveel.
Oh, is "?logout&.jpg" 'valid' volgens jou?

Punt is dat het niet voldoende is, dat het niet nodig is en dat gebruikers er mogelijk last van hebben. Met andere worden: tijdverspilling.

[Voor 18% gewijzigd door Olaf van der Spek op 24-03-2010 12:19]


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

iH8 schreef op woensdag 24 maart 2010 @ 12:04:
[...]


Ik zeg alleen dat ik de slimmerik die denkt een image als /logout te posten te snel af was geweest door een simpele check op correcte extensie. Dan heb ik toch gelijk?
Ah, is het je daarom te doen, het halen van technisch gelijk. Laat ik dan voorop stellen dat je nu de situatie verkeerd schetst, je zei namelijk dat je ermee moest beginnen. Nee, je begint met het opzetten van een fatsoenlijk systeem waarbij niet-idempotente acties via POST verlopen en bovendien een nonce/id vereisen. En als je dat gedaan hebt dan is het controleren op extensie voor dat doel ook nutteloos geworden.

Als je je voordeur vervangt zet je er ook niet eerst een voordeur zonder slot in om op een later tijdstip het slot in te bouwen, om de slimmerik die naar binnen wilt lopen iig alvast tegen te houden. De deur zet je er met slot en al in

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • Anoniem: 156876
  • Registratie: Oktober 2005
  • Niet online
Olaf van der Spek schreef op woensdag 24 maart 2010 @ 12:08:
[...]

Client-side? Of wilde je je eigen server hacken ofzo? :p
8)7
Server-side op je eigen server, en dat plaatje invoeren bij een andere site. ;)

  • DanielG
  • Registratie: Oktober 2005
  • Laatst online: 06-01 13:05

DanielG

i = 0x5f3759df - (i>>1); ☠₧ℳ🀪❣

Trouwens het omzeilen van een check op extentie wordt meestal zo gedaan: [img]http://jouwsite.example.com/logout.php?.jpg[/img]

//edit: Olaf was me voor :p

[Voor 10% gewijzigd door DanielG op 24-03-2010 12:14. Reden: grrmbl]

http://xyproblem.info/


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Anoniem: 156876 schreef op woensdag 24 maart 2010 @ 12:12:
[...]

8)7
Server-side op je eigen server, en dat plaatje invoeren bij een andere site. ;)
Wat wilde je dan zoal server-side gaan doen?

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Defraggen :Y). Het punt was volgens mij meer dat het dan een dynamisch plaatje kon zijn :)

[Voor 74% gewijzigd door .oisyn op 24-03-2010 12:16]

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

iH8 schreef op woensdag 24 maart 2010 @ 12:04:
[...]


Ik zeg alleen dat ik de slimmerik die denkt een image als /logout te posten te snel af was geweest door een simpele check op correcte extensie. Dan heb ik toch gelijk? Nu kan iedereen hier over elkaar heen vallen door mij proberen te leren dat dat qua beveiliging niets voor stelt, dat WEET ik. Ik controleer zelf helemaal niet op extensie, ik gaf een simpel voorbeeld. Een verkeerd voorbeeld blijkbaar, point taken.
MrVegeta heeft als icon: http://no-illusions.nl/images.php

Dat is dus geen correcte extensie?

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
.oisyn schreef op woensdag 24 maart 2010 @ 12:11:
[...]

Ah, is het je daarom te doen, het halen van technisch gelijk. Laat ik dan voorop stellen dat je nu de situatie verkeerd schetst, je zei namelijk dat je ermee moest beginnen. Nee, je begint met het opzetten van een fatsoenlijk systeem waarbij niet-idempotente acties via POST verlopen en bovendien een nonce/id vereisen. En als je dat gedaan hebt dan is het controleren op extensie voor dat doel ook nutteloos geworden.

Als je je voordeur vervangt zet je er ook niet eerst een voordeur zonder slot in om op een later tijdstip het slot in te bouwen, om de slimmerik die naar binnen wilt lopen iig alvast tegen te houden. De deur zet je er met slot en al in
Nee het gaat mij niet om het halen van gelijk. Ik wilde alleen zeggen dat je sommige dingen al afkunt vangen alvorens er naderhand omheen te moeten werken. Dat ik daarvoor het verkeerde voorbeeld gebruik, mijn fout. Je kunt er iets aan doen alvorens je hem in een img src gooit.

@Olaf, Daniel: lees aub even wat ik zeg alvorens nog tig mogelijkheden/exploits te gooien. Ik weet het jongens, nevermind.
kenneth schreef op woensdag 24 maart 2010 @ 12:20:
[...]

MrVegeta heeft als icon: http://no-illusions.nl/images.php

Dat is dus geen correcte extensie?
De purist in mij zegt van niet. Dat het kan en werkt weet ik, of ik het netjes vind, neej.
Filename extensions can be considered a type of metadata. They are commonly used to infer information about the way data might be stored in the file.

[Voor 18% gewijzigd door iH8 op 24-03-2010 12:38]

Aunt bunny is coming to get me!


  • Matis
  • Registratie: Januari 2007
  • Laatst online: 17:50

Matis

Rubber Rocket

Precies wat ik probeerde te voor te stellen, het icoon van ShadowLord
http://hltools.com/avatar/avatar.php

If money talks then I'm a mime
If time is money then I'm out of time


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
iH8 schreef op woensdag 24 maart 2010 @ 12:31:
@Olaf, Daniel: lees aub even wat ik zeg alvorens nog tig mogelijkheden/exploits te gooien. Ik weet het jongens, nevermind.
Ik heb gelezen wat je schreef... Wat je zei heb ik helaas niet gehoord.

Waar komt die quote vandaan? HTTP gebruikt MIME content-type headers, geen extensies.

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Die quote slaat idd niet op een HTTP context. Maar hoe je de metadata overbrengt maakt niet uit, want je mag er toch niet op vertrouwen. :Y) En dus is het zeer twijfelachtig of je het dan in enige mate moet afdwingen.

{signature}


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
Olaf van der Spek schreef op woensdag 24 maart 2010 @ 12:44:
[...]

Ik heb gelezen wat je schreef... Wat je zei heb ik helaas niet gehoord.

Waar komt die quote vandaan? HTTP gebruikt MIME content-type headers, geen extensies.
Zo, zijn lekker aan het muggeziften vandaag hier. Die quote komt gewoon van wikipedia.

Wikipedia: Filename extension

Wat een extensie dan met content-type headers te maken heeft volg ik niet. Een extensie hoort aan te geven wat voor filetype je te maken hebt. Dat de extensie niet overheen hoeft te komen met de content dat is een andere zaak.

Ow en als we toch aan het muggeziften zijn, zou ik toch echt een DELETE gebruiken ipv een POST, je gooit je sessie weg, toch? :X

Aunt bunny is coming to get me!


  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

iH8 schreef op woensdag 24 maart 2010 @ 12:31:
[...]


Nee het gaat mij niet om het halen van gelijk. Ik wilde alleen zeggen dat je sommige dingen al afkunt vangen alvorens er naderhand omheen te moeten werken. Dat ik daarvoor het verkeerde voorbeeld gebruik, mijn fout. Je kunt er iets aan doen alvorens je hem in een img src gooit.
Dus een slechte logout-implementatie op example.com moet afgevangen worden door de img-tags op GoT te controleren?

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
/me keyboardfaceplant |:(

[Voor 27% gewijzigd door iH8 op 24-03-2010 13:01]

Aunt bunny is coming to get me!


Anoniem: 343818

Woy schreef op woensdag 24 maart 2010 @ 10:44:
[...]

Wat ik me wel bedenk is dat je met dat stukje javascript natuurlijk niet de cookies van de huidige sessie meestuurt, en je dus geen andere sessie uit kan lezen, en dus ook niet uit kunt loggen.
:) Er is wel een klein beetje over nagedacht :P
mithras schreef op woensdag 24 maart 2010 @ 11:25:
Met extensies bereik je niets. Leg het dan een (klein) stapje hoger en kijk op mime/type niveau :)
Mime/Type kun je net zo makkelijk faken, dus dat is een net zo hoog stapje..

[Voor 28% gewijzigd door Anoniem: 343818 op 24-03-2010 13:06]


  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Is dat nou een reactie op mijn post? Ik probeer je gewoon te volgen, ik snap namelijk het punt dat je probeert te maken niet. Of ik snap het probleem niet:

example.com heeft een GET-logoutimplementatie. Slecht, daar zijn we het over eens.
Dat kan je exploiten door bijv op forum.org een img-tag met het logoutadres als source te gebruiken.

Jij zegt: je moet je input checken.
Ik vraag dan: waarom moet forum.org iets checken om een exploit op example.com te voorkomen?

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


Anoniem: 343818

kenneth schreef op woensdag 24 maart 2010 @ 13:13:
[...]

Is dat nou een reactie op mijn post? Ik probeer je gewoon te volgen, ik snap namelijk het punt dat je probeert te maken niet. Of ik snap het probleem niet:

example.com heeft een GET-logoutimplementatie. Slecht, daar zijn we het over eens.
Dat kan je exploiten door bijv op forum.org een img-tag met het logoutadres als source te gebruiken.

Jij zegt: je moet je input checken.
Ik vraag dan: waarom moet forum.org iets checken om een exploit op example.com te voorkomen?
Dat zou inderdaad niet hoeven, dat zou onlogisch zijn.. Ben inderdaad wel benieuwd ja..

  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
kenneth schreef op woensdag 24 maart 2010 @ 13:13:
[...]

Is dat nou een reactie op mijn post? Ik probeer je gewoon te volgen, ik snap namelijk het punt dat je probeert te maken niet. Of ik snap het probleem niet:

example.com heeft een GET-logoutimplementatie. Slecht, daar zijn we het over eens.
Dat kan je exploiten door bijv op forum.org een img-tag met het logoutadres als source te gebruiken.

Jij zegt: je moet je input checken.
Ik vraag dan: waarom moet forum.org iets checken om een exploit op example.com te voorkomen?
Ik zag dat iemand opperde dat als je een post achterlaat alszijnde
code:
1
[img]/logout[/img]
dat iedereen die de output bekijkt per direct uitgelogd wordt. Beter via POST/DELETE whatever. Snap ik volkomen. Toen zeg/schreef ik dus, dat had ik afkunnen vangen door bv te controleren op extensie. Maar die bijvoorbeeld werd meteen genomen alszijnde grote fail. Snap ik ook. Nu kan iedereen daar overheen vallen enzo, geen probleem, maar het verandert niets aan wat ik probeer te zeggen. Valideer je input gewoon _zo goed mogelijk_, voorkomt een hoop geouwehoer. Wat de beste manier is laat ik volkomen in het midden.

Aunt bunny is coming to get me!


  • Korben
  • Registratie: Januari 2001
  • Laatst online: 30-08-2022

Korben

() => {};

iH8 schreef op woensdag 24 maart 2010 @ 12:31:
[...]
De purist in mij zegt van niet. Dat het kan en werkt weet ik, of ik het netjes vind, neej.
[...]
De purist in jou heeft geen recht van spreken zou ik zeggen. Dat bla.php uiteindelijk een response oplevert met als MIME-type image/png is volledig legaal. Je kan en mag op internet (en eigenlijk overal) niet aan de extensie van een URL afleiden wat voor content die oplevert. Er zijn steeds meer URL's zonder extensie, ftm.

Bovendien, zoals kenneth zegt, het is niet jouw verantwoordelijkheid om een andere site te beschermen tegen exploits. Aan de andere kant, als jij je log-outpagina niet beschermt tegen XSS, dan plaats ik toch gewoon op mijn site een plaatje met als URL jouw log-outpagina. Aaaaand you're fucked.

Het begin is inderdaad een pagina die een POST vereist met een nonce/id.

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
iH8 schreef op woensdag 24 maart 2010 @ 13:25:
Valideer je input gewoon _zo goed mogelijk_, voorkomt een hoop geouwehoer. Wat de beste manier is laat ik volkomen in het midden.
Hier is het dus niet te valideren zonder valide mogelijkheden in te perken of aannames te doen. Die .jpg hoeft namelijk niet altijd een afbeelding te blijven bijvoorbeeld. Een must have check is of het url is. Als could have kan je heel behulpzaam checken of nu een plaatje is en geen 404, maar verder kan je niets doen.

[Voor 52% gewijzigd door Voutloos op 24-03-2010 13:30]

{signature}


  • Matis
  • Registratie: Januari 2007
  • Laatst online: 17:50

Matis

Rubber Rocket

Je hebt idd genoeg grapjassen die met een jpg-extentie animated-gifs voorschotelen :P

If money talks then I'm a mime
If time is money then I'm out of time


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
offtopic:
dubbelpost

[Voor 96% gewijzigd door Voutloos op 24-03-2010 13:30]

{signature}


  • Korben
  • Registratie: Januari 2001
  • Laatst online: 30-08-2022

Korben

() => {};

Voutloos schreef op woensdag 24 maart 2010 @ 13:28:
[...]
Als could have kan je heel behulpzaam checken of nu een plaatje is en geen 404, maar verder kan je niets doen.
Lijkt me dus niet slim. We gaan er van uit dat je dat server-side doet. Dan is het niet moeilijk om jouw server of die van de andere partij(en) omver te krijgen door een shitload aan plaatjes van een andere server (of je eigen, ftm) te posten. Eens per dag is namelijk controleren is namelijk niet genoeg, het zal eens bijvoorbeeld een bit.ly-URL zijn die ineens verandert.

.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Ik had het enkel over het controleren tijdens het editten van je profiel bijvoorbeeld. Maar goed, het gaat hem niet worden idd.

{signature}


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

bestand.png op een server waar extentie png wordt afgehandeld door php:
PHP:
1
2
3
4
5
6
if (isHackTurnedOn()) {
  header("Redirect: http://twearkes.net/logout");
} else {
  header( "Content-type: image/png" );
  fpassthrough($perfectlyNormalPngImageHandle);
}


Daarnaast. Dat een file-extentie als mimetype definitie wordt gebruikt klopt in de context waarin er niks beters voor handen is. Binnen het http protocol geeft de URL alleen een specifieke lokatie aan, meer niet. Voor het bepalen van het type van het response wordt de (voor dit doel in de HTTP specificaties opgenomen) mimetype header gebruikt.


Owh, en de "isTurnedOn" kun je implementeren middels:
- 1 of andere property op de server.
- op basis van het requesting ip om zo een specifieke gebruiker te targetten.
- op basis van het requesting ip om zo de controleslag van tweakers te misleiden.

[Voor 17% gewijzigd door Janoz op 24-03-2010 13:52]

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
Nogmaals, ik val in herhaling maar toch: ik gaf maar een VOORBEELD van hoe simpel het zou kunnen betreffende die /logout case. Ik controleer niet op extensie en nee, een extensiecheck is geen security, ik gebruik zelf de validators van Zend Framework:

http://framework.zend.com....transfer.validators.html

Een dan ligt het aan de role van de user hoe hard ik zijn input door de mangel haal. Misschien kan iedereen een beetje ophouden mij vertellen wat een user allemaal op m'n setup af vuren kan. Geloof me, ik weet het. Ik heb gezond verstand, unittests en last van lichte paranoia. Dus dat zit allemaal wel goed. Exploiten kan op duizenden manieren en ik ken de meeste dus spaar me, of tenzij iemand een leuke 0-day weet.

@ de mensen die het serveren van content onder de verkeerde headers recht praten, sorry. Dat gaat er bij mij niet in. Ik weet dat het heel stoer is om een variabel avatartje te generen en te gebruiken op je favoriete messageboard ben dan ook zo pro om er een fatsoenlijke rewrite voor te schrijven. Geen half werk, perfectionist tot in de kist!

@ Janoz: Omdat er "niets beters" voor handen is zijn we afhankelijk van dat de mensen het een beetje overzichtelijk houden. function dcgdfgs() { } werkt ook. Net als niceFluidFunction() { }. Zeg jij maar wat je het fijnste vindt.

Aunt bunny is coming to get me!


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

iH8 schreef op woensdag 24 maart 2010 @ 14:00:
Nogmaals, ik val in herhaling maar toch: ik gaf maar een VOORBEELD van hoe simpel het zou kunnen betreffende die /logout case.
Een heel slecht voorbeeld, en daarom viel men erover. Doe nou niet alsof je onrecht wordt aangedaan.

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • Voutloos
  • Registratie: Januari 2002
  • Niet online
iH8 schreef op woensdag 24 maart 2010 @ 14:00:
@ de mensen die het serveren van content onder de verkeerde headers recht praten, sorry. Dat gaat er bij mij niet in. Ik weet dat het heel stoer is om een variabel avatartje te generen en te gebruiken op je favoriete messageboard ben dan ook zo pro om er een fatsoenlijke rewrite voor te schrijven. Geen half werk, perfectionist tot in de kist!
Dus kan je het niet afvangen. En imo (en ik ben blijkbaar niet de enige) kan je je dan het moeite van het afdwingen besparen.

[Voor 9% gewijzigd door Voutloos op 24-03-2010 14:09]

{signature}


  • BarôZZa
  • Registratie: Januari 2003
  • Laatst online: 00:50
Janoz schreef op woensdag 24 maart 2010 @ 09:33:
[...]

Nogmaals, een GET is in deze fout. GET is bedoeld voor idempotente acties. Dat wil zeggen, acties die niks aan de state veranderen. Acties die, wanneer ze meerdere keren aangeroepen worden, geen invloed hebben op de bron*. Met een uiltog actie wordt wel degelijk state veranderd en daarvoor zul je dus een POST moeten gebruiken.
Leuk, maar ik kijk liever naar wat voor invloed het zou hebben. POST gebruik ik in combinatie met een form, dus wanneer een gebruiker zelf input levert. GET voor wanneer dat niet het geval is. Bij counters en dergelijke zijn GET variabelen ook gebruikelijk. Wanneer je een logout met POST zou moeten doen icm een tekstlink, dan zou je of een tussenpagina moeten maken of een form met alleen maar hidden vars en een lelijke JavaScript form submit.
Als je kijkt naar bijvoorbeeld WordPress, een in mijn ogen prima opgebouwd pakketje, dan zie je dat ze daar ook gewoon GET gebruiken met een nonce var. Werkt prima en is veilig.


Ik vind het volgende
code:
1
<a href="/logout/?nonce=a354325asda">Logout</a>

nog altijd mooier dan
code:
1
2
3
4
<form method="post" name="logoutform" action="/logout/">
<input type="hidden" name="nonce" value="a354325asda">
</form>
<a href="#" onclick="document.logoutform.submit();">Log out</a>

  • iH8
  • Registratie: December 2001
  • Laatst online: 13-04-2019
.oisyn schreef op woensdag 24 maart 2010 @ 14:06:
[...]

Een heel slecht voorbeeld, en daarom viel men erover. Doe nou niet alsof je onrecht wordt aangedaan.
:D Na meerdere excuses, tekst en uitleg vond ik het wel welletjes. Stelletje alphamannetjes hier. :+
Voutloos schreef op woensdag 24 maart 2010 @ 14:09:
[...]
Dus kan je het niet afvangen. En imo (en ik ben blijkbaar niet de enige) kan je je dan het moeite van het afdwingen besparen.
Klopt. Wat wel of niet de moeite waard is ligt aan de case. Ik kreeg hier net een mooie Not Found melding op een /logout img. Nice O+

[Voor 38% gewijzigd door iH8 op 24-03-2010 14:18]

Aunt bunny is coming to get me!


  • Matis
  • Registratie: Januari 2007
  • Laatst online: 17:50

Matis

Rubber Rocket

BarôZZa schreef op woensdag 24 maart 2010 @ 14:09:
Ik vind het volgende
code:
1
<a href="/logout/?nonce=a354325asda">Logout</a>

nog altijd mooier dan
code:
1
2
3
4
<form method="post" name="logoutform" action="/logout/">
<input type="hidden" name="nonce" value="a354325asda">
</form>
<a href="#" onclick="document.logoutform.submit();">Log out</a>
Over smaak valt natuurlijk niet te twisten, maar ik vind een eerste constructie mooier, maar laat (imo) ook zien dat de programmeur weet waar hij mee bezig is/was toen hij de code schreef. Persoonlijk zie ik liever zo weinig mogelijk *vervuiling* in URLs.

If money talks then I'm a mime
If time is money then I'm out of time


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 11:33

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

iH8 schreef op woensdag 24 maart 2010 @ 14:11:
:D Na meerdere excuses, tekst en uitleg vond ik het wel welletjes. Stelletje alphamannetjes hier.
Die excuses staan wel flink verstopt dan. Maar goed, het was al duidelijk dat je een PhD had in RechtLullen :Y) ;)
BarôZZa schreef op woensdag 24 maart 2010 @ 14:09:
Wanneer je een logout met POST zou moeten doen icm een tekstlink, dan zou je of een tussenpagina moeten maken of een form met alleen maar hidden vars en een lelijke JavaScript form submit.
Als gebruiker vind ik een single-click logout link maar irritant. Ik zie liever een bevestigingsscherm. Ook zou ik graag de mogelijkheid zien om álle sessies uit te loggen en eventueel in te zien. T.net doet het wat dat betreft heel mooi.

If I had a dollar for every time I didn't know what was going on, I'd be like: "Why am I always getting all this money?!"


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
iH8 schreef op woensdag 24 maart 2010 @ 13:25:
[...]


Ik zag dat iemand opperde dat als je een post achterlaat alszijnde
code:
1
[img]/logout[/img]
dat iedereen die de output bekijkt per direct uitgelogd wordt.
Dat is ook makkelijk te omzeilen. Gewoon een link naar een plaatje die redirect naar die url. Kan je controleren wat je wil, maar je komt nog steeds op de login-pagina uit. Dan zou je dus bij het parsen van de profielpagina al alle content op moeten halen. En dan nog kan er op dat moment best een geldig plaatje staan.

Gewoon onhaalbaar dus.

edit:
O we waren al klaar met iH8 Bashen, sorry ;) laten we er inderdaad maar over op houden, iedereen is het er hopenlijk al over eens dat een url op "correctheid" checken geen oplossing is :)

[Voor 16% gewijzigd door Woy op 24-03-2010 14:20]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • BarôZZa
  • Registratie: Januari 2003
  • Laatst online: 00:50
Matis schreef op woensdag 24 maart 2010 @ 14:13:
[...]

Over smaak valt natuurlijk niet te twisten, maar ik vind een eerste constructie mooier, maar laat (imo) ook zien dat de programmeur weet waar hij mee bezig is/was toen hij de code schreef. Persoonlijk zie ik liever zo weinig mogelijk *vervuiling* in URLs.
Vervuiling ga ik zoveel mogelijk tegen, gotta love de mod-rewrites ;) . Maar onnodige forms en javascriptjes ben ik nog minder fan van vergeleken met één var in de url.
.oisyn schreef op woensdag 24 maart 2010 @ 14:17:
[...]

Als gebruiker vind ik een single-click logout link maar irritant. Ik zie liever een bevestigingsscherm. Ook zou ik graag de mogelijkheid zien om álle sessies uit te loggen en eventueel in te zien. T.net doet het wat dat betreft heel mooi.
Bij Tweakers vind ik het prima, maar dat komt doordat ik simpelweg nooit uitlog :+ . Normaal gesproken wil ik gewoon snel inloggen en uitloggen. Een extra pagina inladen voor een bevestiging vind ik alleen maar irritant. Ik vind een bevestiging van een login al irritant waarbij je na een paar seconden een redirect krijgt.

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
BarôZZa schreef op woensdag 24 maart 2010 @ 14:24:
Vervuiling ga ik zoveel mogelijk tegen, gotta love de mod-rewrites ;) . Maar onnodige forms en javascriptjes ben ik nog minder fan van vergeleken met één var in de url.
Form versus correct HTTP protocol is voor mij wel een heel eenvoudige keuze. Maar goed, vaak is een normale link naar logout pagina gewoon the way to go.

{signature}


  • Technicality
  • Registratie: Juni 2004
  • Laatst online: 04-02 14:16

Technicality

Vliegt rechtsom...

Ik vind die oplossing met een Get + nonce (? wikipedia to the rescue, weer wat geleerd) het meest bruikbaar voor de kleine, vaak interne webapps die ik klus.

Bij ING (even rondkijken) lijken ze trouwens gewoon met javascript je te sturen naar '/internetbankieren/SesamLogoutServlet'.

Overigens is uitloggen het niet de meest pressing security issue ooit imo.

  • T-MOB
  • Registratie: Maart 2001
  • Laatst online: 10:45

T-MOB

Echte chocomel eerst!

Belangrijkste argument tegen logoutlink via get (al dan niet met nonce) is dat je het http-protocol en idempotentie frustreert. Een get-request hoort niets te veranderen op de server (punt). Een web-accelerator, malware-checker of wat voor legitieme toepassing dan ook moet daar op kunnen rekenen. Het is nogal zuur als je gelijk wordt uitgelogd als je zo'n ding wenst te gebruiken. (Nog zuurder is als je een "noob"-klant aan de lijn hebt waarbij om die reden het inloggen niet werkt).

Maar goed, onveilig is het natuurlijk niet (integendeel ;))

Falling isn't flying \ Floating isn't infinite


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

BarôZZa schreef op woensdag 24 maart 2010 @ 14:09:
Leuk, maar ik kijk liever naar wat voor invloed het zou hebben. POST gebruik ik in combinatie met een form, dus wanneer een gebruiker zelf input levert. GET voor wanneer dat niet het geval is. Bij counters en dergelijke zijn GET variabelen ook gebruikelijk. Wanneer je een logout met POST zou moeten doen icm een tekstlink, dan zou je of een tussenpagina moeten maken of een form met alleen maar hidden vars en een lelijke JavaScript form submit.
Het is niet een discussie tussen wat jij vindt en wat ik vind. Het is een discussie tussen wat jij vindt en wat de http specificaties dicteren.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • netvor
  • Registratie: September 2000
  • Laatst online: 26-11-2021
Toch zie je "logout via GET" op zeker de helft van de websites (emperischenattevingerschatting :o ). Waarschijnlijk vanwege de beperking in HTML dat je een tekstlink niet met POST kan submitten. En als je absoluut een tekstlink wil dan heb je twee opties: een ingewikkelde constructie met javascript bouwen, of toch GET gebruiken.

Wat ik wel eens gezien heb is een pagina waarop de actie (in dit geval "delete" en niet "logout") aanvankelijk in een POST <form>, met knop dus, gedefinieerd werd. Een client-side script maakte dit form vervolgens onzichtbaar en maakte een <a></a> link aan die, wanneer aangeklikt, het form verstuurde.
Volgens mij is dat wel een mooie oplossing, want de meeste spiders/accelerators voeren client-side scripts niet uit en zien dus alleen de button. En er is een fallback voor users die javascript uit hebben staan.

Is het trouwens het/dit form of de/deze form? Is form net als topic?

Computer Science: describing our world with boxes and arrows.


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Technicality schreef op woensdag 24 maart 2010 @ 14:42:
Ik vind die oplossing met een Get + nonce (? wikipedia to the rescue, weer wat geleerd) het meest bruikbaar voor de kleine, vaak interne webapps die ik klus.
Tja en als je dan toevallig een browser hebt die aan pre-loading van pagina's doet ( Wat gewoon toegestaan is ), dan word je op die site telkens uitgelogd.

[Voor 19% gewijzigd door Woy op 24-03-2010 17:39]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Technicality
  • Registratie: Juni 2004
  • Laatst online: 04-02 14:16

Technicality

Vliegt rechtsom...

Woy schreef op woensdag 24 maart 2010 @ 17:38:
[...]

Tja en als je dan toevallig een browser hebt die aan pre-loading van pagina's doet ( Wat gewoon toegestaan is ), dan word je op die site telkens uitgelogd.
Oja :P

Maar goed, er zijn genoeg sites die alleen met een $_Get uitloggen, en toch hoor je hier niet veel over :P

  • BarôZZa
  • Registratie: Januari 2003
  • Laatst online: 00:50
Janoz schreef op woensdag 24 maart 2010 @ 17:28:
[...]

Het is niet een discussie tussen wat jij vindt en wat ik vind. Het is een discussie tussen wat jij vindt en wat de http specificaties dicteren.
In dat geval is het een discussie tussen de HTTP specificaties en tig van de meest gebruikte web apps. Als beproefde zaken als Wordpress het op die manier aanpakken, dan zie ik geen noodzaak om het te wijzigen.

Je ziet het ook bij validatiemailtjes met een http://www.domain.com/validate-account?nonce=6aa7f8e8f

Ja, dan kan je ongetwijfeld eerst de GET doen en vervolgens een form met een POST en dat controleren. In mijn ogen geheel overbodig. Ik zie die specificaties dan ook meer als richtlijnen dan als absolute wetten, hetzelfde geldt voor de W3 validaties. Goed om in je achterhoofd te houden, maar niet iets wat je altijd maar ten koste van alles moet toepassen.

Wat betreft pre-fetching: ik kan me niet voorstellen dat je op die manier dan uberhaubt fatsoenlijk kan surfen. Zelfs Google is al jaren geleden gestopt met hun Web Accelerator omdat het niet goed functioneerde en webservers onnodig belastte.

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 04-02 10:20
netvor schreef op woensdag 24 maart 2010 @ 17:34:
Is het trouwens het/dit form of de/deze form? Is form net als topic?
Waarschijnlijk zijn beide acceptabel. De officiële basisregel is dat Engelse leenwoorden gewoon de als lidwoord krijgen, maar het correct is als er een (onzijdig) Nederlands equivalent is dat vergelijkbare spelling en betekenis heeft. Vandaar de topic en ook de form, tenzij je er vanuit gaat dat het formulier genoeg overeenkomst vertoond om het te gebruiken.

Nu is form geen officieel erkend leenwoord (zoals topic wel is) dus een officiële regel is er niet. Beide lijkt me dus te verdedigen, hoewel de waarschijnlijk de voorkeur heeft.

[Voor 3% gewijzigd door Soultaker op 24-03-2010 18:02]


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 17:45

Janoz

Moderator Devschuur®

!litemod

BarôZZa schreef op woensdag 24 maart 2010 @ 17:59:
In dat geval is het een discussie tussen de HTTP specificaties en tig van de meest gebruikte web apps. Als beproefde zaken als Wordpress het op die manier aanpakken, dan zie ik geen noodzaak om het te wijzigen.
Wat een gevolg is van de grote hoeveelheid prutsers die eigenlijk niet helemaal weten waar ze mee bezig zijn. Combineer dat met dat veel van die 'meest gebruikte web apps' vaak uit de hand gelopen hobby projecten zijn.

Vervolgens is dat blijkbaar voor andere ontwikkelaars een 'ach, als zij in de sloot springen dan doen wij dat ook'.
Je ziet het ook bij validatiemailtjes met een http://www.domain.com/validate-account?nonce=6aa7f8e8f

Ja, dan kan je ongetwijfeld eerst de GET doen en vervolgens een form met een POST en dat controleren. In mijn ogen geheel overbodig. Ik zie die specificaties dan ook meer als richtlijnen dan als absolute wetten, hetzelfde geldt voor de W3 validaties. Goed om in je achterhoofd te houden, maar niet iets wat je altijd maar ten koste van alles moet toepassen.
In een email ben je wel heel beperkt qua mogelijkheden dus heb je eigenlijk geen enkele andere keuze, maar de (misschien verregaande) correcte oplossing is inderdaad naar een pagina gaan waar die activatie code inderdaad vooringevuld op een form staat en vanaf daar vervolgens middels POST het form submitten.
Wat betreft pre-fetching: ik kan me niet voorstellen dat je op die manier dan uberhaubt fatsoenlijk kan surfen. Zelfs Google is al jaren geleden gestopt met hun Web Accelerator omdat het niet goed functioneerde en webservers onnodig belastte.
Google is gestopt omdat ze inderdaad tegen het probleem aanliepen dat het web stikt van de brakke webapplicaties. Zij kregen klachten dat hun web accelerators er voor zorgde dat gebruikers werden gebanned of topics werden verwijderd. Mij lijkt dat meer de fout van een brakke forum implementatie.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • BarôZZa
  • Registratie: Januari 2003
  • Laatst online: 00:50
Tsja, als je sites als Google, Facebook en Wordpress uit de hand gelopen hobbyprojectjes wilt noemen, dan is dat uiteraard je goed recht. Voor mij is het eerder een bevestiging dat beide oplossingen prima zijn en hun doel dienen.

Je zou eerder kunnen discussiëren of HTTP al dan niet verouderd is, waardoor ontwikkelaars er creatief mee om moeten gaan. Als je overigens toch geheel correct wilt doen: 'HTTP protocol' is natuurlijk dubbelop ;)

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 04-02 10:20
Janoz schreef op woensdag 24 maart 2010 @ 18:10:
Wat een gevolg is van de grote hoeveelheid prutsers die eigenlijk niet helemaal weten waar ze mee bezig zijn. Combineer dat met dat veel van die 'meest gebruikte web apps' vaak uit de hand gelopen hobby projecten zijn.
Op zich waar, maar het probleem is ook dat dit soort issues lang na de ontwikkeling van HTTP en HTML ontstaan zijn. Er is helemaal geen rekening gehouden met privacy, 3rd party cookies, cross-site scripting, cross-site request forgery, et cetera bij het ontwerpen van essentiële protocollen en formaten en daardoor zitten we nu met de gebakken peren. Het gebruik van een nonce is ook een soort hack eigenlijk, om het probleem op te lossen dat bepaalde resources niet van buitenaf gerefereerd mogen worden.

Voor de concrete uitlogknop heb je nu eigenlijk geen goede opties. Anchors leveren altijd GET linkjes op. Voor een POST request zul je een form moeten bouwen, wat betekent dat je ofwel een form button moet introduceren (wat lelijk is, hoewel je die nog wel kunt stylen), of je moet een plaatje gebruiken, want een plaatje kan wél een form submit opleveren, maar die schalen niet goed mee. Het laatste alternatief is dan de boel met JavaScript aan elkaar te hangen, maar dan nog moet je eigenlijk een non-JavaScript alternatief ernaast implementeren.

Feit is dus dat de mogelijkheden die er zijn nogal beperkt en willekeurig zijn. Dat is niet de schuld van amateuristische webdesigners. Of kun je me uitleggen waarom geanchorde tekst alleen maar naar resources mag verwijzen waarop GET requests gedaan worden, terwijl plaatjes (door middel van image buttons) wel POST requests tot gevolg kunnen hebben?

edit:
Trouwens, nu we het toch over "prutsers die niet weten waar ze mee bezig zijn" (jouw woorden ;)) hebben: Tweakers.net doet dit ook fout. Uitloggen moet weliswaar met een sessie-id, maar een reset van de RSS key op dezelfde pagina kan wél met een cross-site HTTP request.

Proof of concept: http://hell.student.utwen...10-03-24-reset-rssid.html (Klik deze link niet als je een RSS reader gebruikt en geen zin hebt om die opnieuw in te stellen!) Die redirect kan natuurlijk ook in een iframe of iets dergelijks waardoor de gebruiker er niets van ziet.

Dus ofwel professionele webdevelopers maken dit soort fouten ook, of Tweakers.net zijn een stelletje prutz0rs. :P

[Voor 16% gewijzigd door Soultaker op 24-03-2010 18:56]


  • mithras
  • Registratie: Maart 2003
  • Niet online
HTML6:
HTML:
1
<a href="logout" method="post">Logout</a>

Solved :Y)

  • Anoniem: 156876
  • Registratie: Oktober 2005
  • Niet online
Sommige dingen kan je nou eenmaal niet voorblijven, je kan niet elke link die iets uitvoert via een post gaan sturen... :+ Whehe, ik heb te weinig T.net buddies, denk dat ik deze url aan een plaatje ga koppelen. :+

edit: Btw, je "proof of concept" ik faalt.. :9

[Voor 9% gewijzigd door Anoniem: 156876 op 24-03-2010 20:09]


  • EdwinG
  • Registratie: Oktober 2002
  • Laatst online: 10:31
Soultaker schreef op woensdag 24 maart 2010 @ 18:44:
Uitloggen moet weliswaar met een sessie-id.
Waar in de uitlogpagina vindt je een sessie-id als parameter?

(opmaak verwijderd, broncode van het formulier op http://tweakers.net/my.tnet/logout)
HTML:
1
2
3
4
5
6
7
8
9
10
<form method="post" action="http://tweakers.net/my.tnet/logout">
  <input type="hidden" name="logout" value="1">
  <input type="radio" name="option" value="this" checked id="logout_this">
    <label for="logout_this">Alleen deze sessie beëindigen</label>
  <input type="radio" name="option" value="all" id="logout_all">
    <label for="logout_all">Al mijn sessies beëindigen</label>
  <input type="radio" name="option" value="allbutthis" id="logout_allbutthis">
    <label for="logout_allbutthis">Al mijn sessies beëindigen, behalve deze</label>
  <input type="submit" value="Uitloggen" accesskey="s" class="submitbuttonLarge">
</form>


Helaas, CSRF op de uitlogfunctie gaat ook bij tweakers.net gewoon werken. (Net op mezelf getest).

[edit]
Waarschijnlijk heb je het sessie-id gezien op de pagina http://tweakers.net/my.tnet/sessions, welke gebruikt kan worden om specifieke sessies af te sluiten.

Een probleem met de manier waarop dat is opgebouwd is overigens dat ik een request kan forgen met daarin vele (honderdduizenden?) POST parameters met namen in de vorm van 'delete[willekeurigsessieid]', die elk de waarde '1' hebben. Elke geldige sessie-ID van de getroffen gebruiker die er tussen zit resulteerd dan in een uitgelogde sessie.

[Voor 19% gewijzigd door EdwinG op 24-03-2010 20:25]

Bezoek eens een willekeurige pagina

Pagina: 1 2 Laatste


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee