Met andere woorden: dit heeft niet specifiek iets te maken met Github of Firefox maar is gewoon een gevalletje usererror?

Ik snap nog steeds niet dat je door het stelen van cookies ook gelijk wordt ingelogd. Dan checkt het programma toch op zijn minst de user agens string, in combinatie met het IP-adres?

Nog meer reden om ervoor te kiezen standaard niet je geschiedenis te laten opslaan door welke browser dan ook.

Natuurlijk niet! Het IP adres kan veranderen en dan kan het nog dezelfde user zijn. De user agent string kan ook veranderen en in gevallen waarin dat niet zo is (omdat de browsermaker de string niet meer aanpast) dan is die voor iedereen gelijk en bekend.

Zouden er WERKELIJK zoveel ontwikkelaars zijn die hun hele home directory naar een git repository committen als ze code voor een of ander project waar ze aan bezig zijn in github willen zetten?
Dat vind ik een sterk verhaal... tenzij je als ontwikkelaar maar met EEN ding bezig bent (en daarnaast dan met browsen kennelijk) moet het je toch snel opvallen dat je veel meer aan het uploaden bent dan je project.

User error. Maar dan nog is zou het mooi zijn als gebruikers een GitHub notificatie ontvangen wanneer dit gebeurt.

Het koppelen van cookies aan een IP-adres is een layer violation. Daarnaast geeft het problemen als je van tussen verschillende wifi-netwerken (of 5G) wisselt. Het is gewoon heel erg lelijk. Het zelfde geldt voor cookies koppelen aan een user-agent. De beveiliging daarvan is ook twijfelachtig; aangezien het alleen om Firefox gebruikers gaat kan je goed voorspellen wat die user-agent precies is. Het zou ook iedereen automatisch uitloggen na een update van de browser.

Waarschijnlijk vind je dit nog wel interessant op te lezen (al is het er om meerdere redenen nooit van gekomen): http://www.browserauth.net/home. (ChannelBinding is een stille dood gestorven nadat Google de implementatie uit Chrome heeft gehaald.)

Op mobiele telefoon heb je geen vast IP(v4) adres, die kan om de haverklap veranderen. Niet alle vaste providers leveren vaste IP adressen en in het buitenland is het vaak helemaal niet gebruikelijk om met vaste adressen te werken. Dus die check valt af.

Useragent klinkt eenvoudig, maar wanneer keur je deze goed? Bij een exacte match? Of sluit je de versienummers uit? Je wilt immers niet dat gebruikers na een update meteen overal uitgelogd zijn. Maar hoe zinvol is het dan nog? Er is maar een handjevol grote spelers op de browsermarkt, dus zonder versienummers is de juiste agent voor de gemiddelde gebruiker zo geraden.

Tsja met zo'n 73 miljoen gebruikers (https://expandedramblings.com/index.php/github-statistics/) is het best realistisch dat zo'n 4500 databases te vinden zijn.

Ja bij bedrijven als MS en goochel staan standard alle vinkjes altijd aangevinkt.
Beter kun je niets te maken hebben met dat soort bedrijven die altijd alles aan willen zetten voor jouw.

Het grootste probleem is dat veel users niet uitloggen. Na uitloggen wordt de sessie cookie ongeldig.

Een IP controle kun je soms instellen (In elk geval is dat een optie bij mijn nas systeem.). Maar zoals anderen hierboven al aangeven kan dat problemen geven bij mobiel werken omdat dan het IP in de achtergrond legitiem kan veranderen.

Aha, een bagger implementatie van een specifiek OS waardoor je files die beginnen met een . niet ziet.
Security by obscurity ....

Of niet Toje?

Vergeet ook niet dat "wij" hier in Nederland met onze veelal vaste IP adressen bij providers eerder uitzondering dan regel zijn.
In veel landen is het gebruikelijk dat je IP adres iedere dag verandert (soms voor een aire van "privacy", soms om te ontmoedigen dat je "services" draait op een thuisaansluiting, soms omdat de provider te weinig IP adressen heeft en die "deelt" tussen gebruikers).
Een IP adres aan een gebruiker gelijkstellen is gewoon helemaal fout, zelfs als de wet dat probeert een persoonsgegeven te noemen.

Overigens denk ik nu dat het wellicht gewoon gebruikers betreft die github gebruiken als backup faciliteit, daarom hun hele home directory syncen met github, en alleen ergens iets verkeerd ingesteld hebben waardoor die repository publiek geworden is. Dat was wellicht niet zoals bedoeld.

Op een ander forum kwam ik een commentaar tegen van iemand die cursussen geeft, onder andere over Git, die met de nodige leerlingen te maken heeft die geen flauw benul hebben wat bestanden of directory's zijn. Die hebben geen idee waar hun cursus-werkruimte is opgeslagen, die denken dat het er gewoon magischerwijze is, of het zal wel in de cloud staan.

Als mensen zonder die basiskennis Git gaan gebruiken, via Github en de GUI-tool van Git zelf, dan kan ik me dit soort ongelukken voorstellen. Een gui-programma dat je via een menu start heeft je home-directory als actieve directory. Iemand die niet weet wat een directory is zal niet op het idee komen dat er een aparte projectdirectory aangemaakt moet worden, en zal ook niet weten wat een home-directory is. De eerste de beste directory die ergens al staat ingevuld is dan de home-directory, en iemand die niet snapt wat hem gevraagd wordt zal vaak genoeg op Ok drukken om te zien of het misschien zo wel werkt. En dat lijkt het te doen, en dan krijg je dit.

Toen ik begin jaren 1980 mijn eerste automatiseringsopleiding deed waren computers voor veel mensen nog niet meer dan iets wat in science fiction voorkwam, dus leerde je alles: wat een processor is, wat geheugen is, werkgeheugen en permanent geheugen, wat een programma is, wat een bestand is, hoe bestanden georganiseerd worden, de hele rimram. Het lijkt erop dat computers zo alomtegenwoordig zijn dat tegenwoordig bij allerlei opleidingen de basis bekend wordt verondersteld bij de studenten, terwijl mensen door de grote softwareleveranciers zo vergaand worden afgeschermd van hoe dingen eigenlijk werken dat menigeen juist geen flauw idee heeft. Geen beste stand van zaken.

Hier is ook weer gemak - niet gemakzuchtigheid, of vergeetachtigheid! - de leidende factor. Browser ontwikkelaars zouden veel meer moeten benadrukken op o.a. hun info, of dowloadpagina's dat security verre van: 'gemak dient de mens' behoort te zijn, en dat gestaag gaan implementeren in hun product.

Voorbeeldje:

Als ik dit tabblad waarin ik nu mijn bijdrage hier aan het typen ben sluit, blijf ik ingelogd. Dat heeft Security.nl zo voor mij geregeld.
Dat is makkelijk, maar is het veilig?
Neen.
Niet dat ik deze website niet vertrouw, maar de browser zou resoluut het koekje dat verantwoordelijk is voor deze sessie (inlog) moeten wissen, en/of de cache legen. En geen opt out of opt in. Wissen die hap ;-)
Tab per abuis gesloten? Dan log je maar opnieuw in! Klaar en wen er maar aan, want het is voor je eigen digitale veiligheid.

Veiligheid is nu eenmaal lastig. Dat moet veel meer dan nu een begrip worden, want anders blijft het telkens weer aanmodderen.

De website kan het verschil niet zien tussen een tabblad dat jij sluit of dat je gewoon naar het scherm staat te staren. Een website kan wel een timer voor inactiviteit toevoegen. En je uitloggen.

Persoonlijk erger ik me aan websites die de inlogoptie helemaal verstoppen op hun pagina. Blijkbaar zijn er zoveel mensen die een pagina verlaten zonder uit te loggen, dat ze er nooit klachten over krijgen. Nog erger is mijn Ziggo router. Die heeft niet eens een normale uitlog optie. Ik kan wel naar de 'avanced' settings gaan, waar wel een uitlog optie zit. Alsof het uitloggen alleen voor geavanceerde gebruikers is.

Maar goed, als je niet uitlogt heeft de sessie cookie dezelfde functie als een wachtwoord: Het geeft je toegang tot jouw account op die site. Dit is er natuurlijk ook voor om als je binnen een site een nieuw tabblad opent, je nog steeds op die site blijft.

Ard: Je hebt gelijk met het tabblad sluiten. Een veilige browser zou dan ook deze ''sessionid" cookie moeten wissen bij sluiten van een tabblad. Voor nu kun je beter jezelf inprenten dat je een site altijd via de uitlogoptie moet verlaten en niet door het sluiten van een tabblad.

Briolet heeft gelijk: de website kan helemaal niet zien of alle tabblad gesloten zijn geweest of niet. En een browser kan niet zien waar een cookie voor dient (dat is niet per se voor een login).

HTTP(S) is op zich een stateless protocol, wat wil zeggen dat elke request van de browser aan de server in beginsel gezien wordt als iets dat compleet los staat van alle andere requests, en dus geen mogelijkheid bevat voor de server om de reactie op de request aan te passen aan dingen die de bezoeker eerder heeft gedaan. Dat komt voort uit waar het oorspronkelijk voor diende: om openbare documentatie die op verschillende servers staat met hyperlinks naar elkaar te kunnen laten verwijzen, het is een toepassing voor gedistribueerde hypertext.

Cookies zijn daaraan toegevoegd om toch staat toe te kunnen voegen. Het kan (via persistente cookies die voor lange tijd bewaard worden) gebruikt worden om voorkeuren van gebruikers op te slaan zonder de server met die opslag te belasten, en het kan (via sessiecookies die net lang bewaard worden) gebruikt worden om de server te laten weten dat meerdere requests van dezelfde bezoeker afkomstig zijn, zodat de server in de request-afhandeling niet alleen kan reageren op de inhoud van de huidige request maar ook op wat eraan vooraf is gegaan. Technisch is het natuurlijk geen enkel probleem om een "sessie" tot in de oneindigheid te laten duren door er een expiratiedatum in de verre toekomst aan te koppelen. Daarom worden cookies zo dankbaar gebruikt voor tracking en profiling.

Een sessie op de webserver staat niet per se gelijk aan inloggen. Een webwinkel waar je zonder account iets kan kopen bijvoorbeeld zal ook voor een in eerste instantie nog anonieme bezoeker een winkelwagentje moeten kunnen bijhouden, en dat is niet te doen als de server niet kan zien dat meerdere requests bij dezelfde bezoeker horen. Dan is er al een sessie op de server en is er een sessiecookie nodig. Een login betekent voor de webbrowser eigenlijk helemaal niets, die ziet alleen dat er cookies zijn en het is de server die een inlogpagina laat voorafgaan aan het kunnen doen van dingen waarvoor je ingelogd moet zijn.

Voor sessiecookies, cookies zonder expiratiedatum of maximumleeftijd, is het op het niveau van de communicatieprotocollen niet aan de server maar aan de client (de browser) om te bepalen wanner die wordt verwijderd, waneer de sessie eindigt dus. Browsers doen dat in de praktijk als de browser wordt afgesloten. Een webserver zal typisch besluiten om een sessie na een periode van inactiviteit (geen requests) op te ruimen, wat de sessiecookie effectief doet vervallen. Bij toepassingen met een groot risico op misbruik (zoals online bankieren) zullen servers dat al na een paar minuten doen, bij minder kritische toepassingen kan er een langere inactiviteitsperiode worden aangehouden.

Browsers zijn duidelijk voorzichtig met het weggooien van cookies. Je kan in Firefox instellen dat persistente cookies (die waarvoor de server een expiratiedatum of maximum leeftijd heeft ingesteld) toch worden weggegooid als de browser wordt afgesloten, maar niet dat sessiecookies al worden weggegooid als je een tab afsluit. Ik snap die voorzichtigheid wel: het zijn instellingen waarmee websites mogelijk niet meer werken zoals een gebruiker verwacht, en mensen zitten nou eenmaal aan instellingen die ze niet snappen en weten daar vervolgens zelf niet meer uit te komen. Het is altijd de vraag hoe ver je gaat met geavanceerde dingen in de browser zelf in te bouwen, of het over te laten aan makers van add-ons zodat gebruikers die het wel snappen en willen het zelf kunnen toevoegen.

Ik gebruik de add-on Cookie AutoDelete. Die kan je cookies en andere website-data laten verwijderen als (of een aantal seconden nadat) de laatste tab van een website gesloten wordt, of alternatief zodra (of een aantal seconden nadat) een domein in geen enkele tab meer voorkomt. Pas op met dat laatste: aanloggen met DigiD en betalen met iDEAL zijn uitstapjes naar een andere website, en er gaan dingen mis als je bij terugkeer naar de oorspronkelijke website je sessiecookie kwijt bent.

Je zou als GitHub zijnde natuurlijk wel een warning kunnen gooien naar je gebruikers die cookies.sqlite committen.

Maar ja, zorgplicht of dergelijke bestaat natuurlijk niet voor dat soort platformen, zelfs niet als je ze erop tipt.

dit is f*ing pijnlijk denk ik....

@ Briolet, en Anoniem, 06:13 uur,

Ten eerste dank voor jullie reacties!

Ik heb nog een terzijde opmerking over sessiekoekjes zoals door bijv. de ING-bank worden geplaatst. Tot voor zo'n anderhalf jaar geleden wiste de ING een sessiekoekje - waarmee dus je inlog verviel - al vrij snel en zonder waarschuwing vooraf. Een verandering is opgetreden tegelijkertijd met de introductie van de compleet nieuwe layout van de ING internetbankierpagina's.
Sindsdien valt mij op dat het zeker 10 minuten duurt voordat je de waarschuwing krijgt: "ben je er nog?". en dan gaat ook nog een responstijd lopen om in de betreffende pop-up op ja of neen te klikken.

Ik plaats die, overigens off-topic opmerking toch omdat we hier op een IT security site zijn.

Ik vind het vreemd om de effectiviteitsduur van het sessiekoekje te verlengen. Waarom? Omdat het strijdig is met Internet veiligheid. Uitgebreider: om de inactieve tijd van inlog nu juist op te rekken terwijl we allemaal weten dat we gevaarlijker en vaker worden geconfronteerd met criminele pogingen om je persoonlijke (financiële) integriteit te verliezen zodra je gebruik maakt van IT networking.

@ Anoniem,

Ik heb de extensie Cookie AutoDelete ook in gebruik en was mij bewust van het risico om automatisch koekjes te laten wissen tijdens een browsersessie. Het is goed dat je er hier voor waarschuwt. Dank.

+1

Dank voor de genomen tijd voor een degelijke uitleg.

Die 10 minuten zal een compromis zijn. Als je b.v. met de boekhouding bezig bent, wil je soms tussentijd even de binnenkomende betalingen controleren. Dan wil je niet elke paar minuten weer moeten inloggen. 10 minuten klinkt als een acceptabele tijd. Als je zo lang niet naar de betalingen gekeken hebt, dan log je maar weer in. Korter zou ik zelf ook vervelend vinden. Ik heb het bij de ABN niet getimed, maar dat is voor mijn gevoel ook iets van 10 minuten.

Als ik er bij mijn Duitse bank via een time-out uitgegooid wordt, krijg ik bij de volgende inlog een 'reprimande' dat ik de volgende keer netjes moet uitlogen.

Dat laatste wat je schrijft is een uitstekende actie van die bank!

...en het ware beter deze functionaliteit zelfs uit te breiden naar ook een waarschuwing als je de browser afsluit zonder uitloggen. Browsers maken na afsluiten hun communicatie af met een webserver, dus als het sessiekoekje zo wordt geprogrammeerd dat het vóórdat het automatisch wordt gewist het signaal zendt naar een webserver dat er niet is uitgelogd, moet dat ook mogelijk zijn, of zie ik iets over het hoofd? Ik ben geen IT-deskundige. Ik maak slechts de vergelijking met FileMaker Pro die je ook een script kan laten uitvoeren bij sluiten van een DB maar ook bij afsluiten van het programma zelf.

Hoewel het niet behoort tot hun hoofdactiviteit zou de DNB (De Nederlandse Bank) er misschien op aan moeten dringen bij Nederlandse banken dit óók in te bouwen in hun webinterface. Ik weet niet welk overkoepelend orgaan anders deze opdracht bij banken zou kunnen neerleggen. De Autoriteit Financiële markten zeker niet.

Je hebt geen idee hoeveel software ontwikkelaars eigenlijk gewoon scriptkiddies zijn. Vooral in PHP-land is het soms schrijnend. Die lui doen echt maar wat.

Zo werkt het internet alleen niet, de connectie is al lang klaar voordat jij je page sulit.

knip heel prima uitleg .

Ik wil alleen nog opmerken dat de _andere_ reden voor het nut van sessie cookies is dat een beetje grote site niet "DE" http server heeft, maar een hele farm aan HTTP servers .

Een volgend request van dezelfde gebruiker kan op een andere server terecht komen - als de relevante informatie van wat die gebruiker aan het doen was in het cookie staat , kan die _andere_ HTTP server "verder gaan waar de gebruiker gebleven was" .

Je kunt stellen dat de HTTP servers stateless zijn . Stateless is ontzettend fijn om te schalen en redundantie te te bouwen.
Het zijn de clients die de state bewaren in het cookie .

Mobiel is nog veel simpeler : als je telefoon 'seamless' omschakelt van je Wifi naar je data omdat je buiten Wifi bereik loopt verandert je IP natuurlijk ook.

Inderdaad vrij standaard. Gedreven door de wens van het snelle resultaat en als algemene tools gebuikt dan lossen anderen toch al die problemen wel op. ... foutje en bedankt.

Volgens het vermoeden van Marlin doen deze mensen dit niet om code te uploden, maar als een synchronisatietool om verschillende werkplekken in sync te houden.


Dus een bewuste keuze om niet alleen een project in sync te houden, maar dan direct je hele home directory.

4500 nep ontwikkelaars. Eerder allemaal noobs. Maarja, d'r er zijn er veel die aan een project beginnen en zich al meteen een ontwikkelaar noemen. Hoe zou m'n ze ook anders moeten noemen als er geen andere naam voor bestaat.

Dat citeer je uit een alinea die begint met:
Ze doen het dus wél om code te uploaden, vermoedt hij. Dat sluit niet uit dat ze GitHub gebruiken om die code over meerdere werkplekken te synchroniseren, maar de bedoeling is dan om de code waaraan ze werken te synchroniseren.

Da's niet wat Marlin vermoedt, zoals ik het lees.

Niet dat er niet wat op dat vermoeden aan te merken valt, en op de opmerking van Sophos waar de update in het artikel naar linkt dat in Linux en Unix bestandsnamen die met een punt beginnen verborgen zijn, tenzij je moeite doet om ze te laten tonen. Dat gaat namelijk niet op voor git: 'git status' en 'git gui' laten verborgen bestanden juist wél zien, en 'git commit' laat alle in de commit gewijzigde bestanden zien. Dan heb je nog niet de 'git push' gedaan waarmee het in een remote repository (zoals github) belandt, dat kan je dus nog voorkomen. Je moet bij git dus niet je best doen om verborgen bestanden wel te zien, je moet je best doen om ze niet te zien, en dat doe je door dingen te negeren die wel degelijk gemeld worden.

Je hoeft maar op dit forum te kijken om te zien hoeveel mensen een quote verprutsen, een url verprutsen, zinnen vol spel- en grammaticafouten uitspugen, en duidelijk op "Reageren" klikken zonder eerst langs "Preview" te gaan om te zien of het wel klopt. Als ongezien doorduwen de gehanteerde werkwijze is dan helpt geen enkele informatie om fouten te voorkomen.

Je kan gelijk hebben dat bewust de hele home-directory wordt gesynchroniseerd, al is dat niet het vermoeden dat Marlin uitsprak. Het hierboven al genoemde idee dat er mensen zijn die git en github beginnen te gebruiken zonder nog enig benul te hebben van wat bestanden en directory's zijn kan ook een verklaring zijn. Blind dingen doordouwen zonder te kijken wat er eigenlijk gebeurt kan ook een factor zijn.

Met 4500 gevallen zijn er waarschijnlijk nog vele andere verklaringen die zo ver afstaan van wat iemand zou doen die wel weet waar hij mee bezig is dat we niet eens op het idee komen wat het allemaal zou kunnen zijn.

Dat is exact wat ik waarneem in de alledaagse praktijk, bij ontwikkelaars en andere IT-ers. Zorgwekkend wat mij betreft.

Ik denk niet dat ontwikkelaars hun hele home dir committen om dat daar hun code in zit. Ik denk eerder dat het gebruikt wordt als "roaming" profile. Ik weet niet hoe bij de gemiddelde security.nl bezoeker is, maar als je pakket x installeert en je complete libs naar de klote zijn, dan wil je je het OS opnieuw installeren. En om snel weer verder te kunnen zet je je home dir terug. en vanaf git heb je het voordeel dat je ook nog terug kan in versies. Leuk als het terminal thema toch niet helemaal bevalt.
En als je meerdere werkplekken hebt, is het fijn dat je tussen de verschillende werkplekken kan switchen, maar met toch overal de zelfde settings. (en dus zelfde cookies dankzij firefox).

Al zou ik zelf het in een private git zetten, en het ophalen via ssh met ssh-key.

WTF? Het is bij normaal gebruik nooit nodig om het hele besturingssysteem opnieuw te installeren! Als je daar écht last van denkt te hebben, verdiep je dan eens in het opzetten van een ontwikkelomgeving met Docker.