Veiligheid GET/POST bij uitlog functie *

[korgakos]

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]

@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

[roy-t]

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

[korgakos]

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]

@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]

[Davio]

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]

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.

[BarôZZa]

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:

[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]

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:

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

[.oisyn]

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.

[Janoz]

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.

[netvor]

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 telkens hardnekkig door mijn hoofd

[.oisyn]

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?

[Olaf van der Spek]

Zou dit niet opgelost kunnen worden op HTTP/HTML niveau?

[Sebazzz]

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?

[Matis]

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

[Olaf van der Spek]

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]

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]

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]

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]

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]

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]

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.

[Janoz]

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.

[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

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

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

[Woy]

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.

[Technicality]

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]

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.

[Woy]

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.

[Olaf van der Spek]

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]

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]

Olaf van der Spek schreef op woensdag 24 maart 2010 @ 10:56:
[...]
Ik dacht het wel.

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.

[iH8]

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.

[Janoz]

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.

[Matis]

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.

[Janoz]

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.

[iH8]

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]

[mithras]

Met extensies bereik je niets. Leg het dan een (klein) stapje hoger en kijk op mime/type niveau

[iH8]

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

[.oisyn]

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]

[Olaf van der Spek]

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]

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]

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.

[iH8]

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]

[kenneth]

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

[.oisyn]

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]

[Woy]

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

[.oisyn]

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]

[iH8]

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

[Janoz]

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.

[Olaf van der Spek]

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?

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

[Olaf van der Spek]

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]

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

[Anoniem: 156876]

Olaf van der Spek schreef op woensdag 24 maart 2010 @ 12:08:
[...]

Client-side? Of wilde je je eigen server hacken ofzo?

Server-side op je eigen server, en dat plaatje invoeren bij een andere site.

[DanielG]

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

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

[Olaf van der Spek]

Anoniem: 156876 schreef op woensdag 24 maart 2010 @ 12:12:
[...]


Server-side op je eigen server, en dat plaatje invoeren bij een andere site.

Wat wilde je dan zoal server-side gaan doen?

[.oisyn]

Defraggen . 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]

[kenneth]

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?

[iH8]

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

[Matis]

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?

Precies wat ik probeerde te voor te stellen, het icoon van ShadowLord

[Olaf van der Spek]

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]

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. En dus is het zeer twijfelachtig of je het dan in enige mate moet afdwingen.

[iH8]

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?

[kenneth]

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?

[iH8]

/me keyboardfaceplant

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

[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

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]

iH8 schreef op woensdag 24 maart 2010 @ 12:59:
/me keyboardfaceplant

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?

[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]

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:

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

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

[Voutloos]

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]

[Matis]

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

[Voutloos]

offtopic:
dubbelpost

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

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

[Voutloos]

Ik had het enkel over het controleren tijdens het editten van je profiel bijvoorbeeld. Maar goed, het gaat hem niet worden idd.

[Janoz]

bestand.png op een server waar extentie png wordt afgehandeld door php:

PHP:

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]

[iH8]

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.

[.oisyn]

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.

[Voutloos]

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]

[BarôZZa]

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:

<a href="/logout/?nonce=a354325asda">Logout</a>

nog altijd mooier dan

code:

<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]

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

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

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

[Matis]

BarôZZa schreef op woensdag 24 maart 2010 @ 14:09:
Ik vind het volgende

code:

<a href="/logout/?nonce=a354325asda">Logout</a>

nog altijd mooier dan

code:

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

[.oisyn]

iH8 schreef op woensdag 24 maart 2010 @ 14:11:
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

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.

[Woy]

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


Ik zag dat iemand opperde dat als je een post achterlaat alszijnde

code:

[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]

[BarôZZa]

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]

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.

[Technicality]

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]

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 )

[Janoz]

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.

[netvor]

Toch zie je "logout via GET" op zeker de helft van de websites (emperischenattevingerschatting ). 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?

[Woy]

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]

[Technicality]

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

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

[BarôZZa]

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]

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]

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.

[BarôZZa]

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]

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.

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

[mithras]

HTML6:

HTML:

<a href="logout" method="post">Logout</a>

Solved

[Anoniem: 156876]

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

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

[EdwinG]

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:

<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]