Wanneer URL-manipulatie strafbaar is als computervredebreuk

nos-url-manipulatieDe man die de kersttoespraak van koningin Beatrix op internet vond, heeft zich strafbaar gemaakt. Zoiets zei ik Eerste Kerstdag tegen de NOS. En dat maakte nogal wat los. URL’s zijn toch openbare adressen, wat op een server staat is niet geheim, er wordt niets gekraakt, dit is toch pure domheid van de RVD, en ga zo maar door. Ja ja dat klopt allemaal en de RVD is ook een stel prutsers maar het blijft een feit dat binnendringen óók zonder iets te kraken strafbaar is.

Sinds 2006 hebben we een brede definitie van computervredebreuk: ieder opzettelijk en wederrechtelijk “binnendringen” in een computersysteem is strafbaar, ook als er niets wordt gekraakt, omzeild, geïnjecteerd of vervalst. Zodra je ergens bent waarvan je wéét dat je er niet mag zijn, ben je formeel al in overtreding. En ik zie werkelijk niet waarom dat wél zou gelden bij een SQL injectie en niet bij een trivialer vorm van URL-manipulatie – zoals bij de kersttoespraakurl waarbij het een kwestie was van jaartal en UID aanpassen. Beiden zijn aanpassen van URLs.

Natuurlijk, het is technisch bepaald triviaal en volstrekt onvergelijkbaar met het soort hack waarmee Diginotar gekraakt werd, dus om het nou “hacken” te noemen is wel erg veel eer. Maar het formele punt blijft. Je verandert een webadres om informatie te krijgen die niet openbaar bedoeld was. Waarom maakt het uit of je dat met de toevoeging ” OR 1=1; SELECT * FROM userdata” doet of door 31337 te veranderen in 31338?

Een veelgehoord argument was dat informatie op een website openbaar is tenzij deze afgeschermd is. Dan zou er per definitie dus geen sprake van binnendringen kunnen zijn. Sympathiek, en ik zou het graag zo zien, maar dat staat niet in de wet. Net zo min als er in de wet staat dat je mijn achtertuin mag betreden als er geen hek omheen staat. Dat is en blijft mijn eigendom en ik beslis wie daar mag lopen of kamperen.

Het blijft natuurlijk van de zotte dat de RVD een “onderzoek” gaat instellen, en ik kan me níet voorstellen dat het OM meer dan vijf minuten besteedt aan een eventuele aangifte.

Arnoud

197 reacties

      1. Helemaal eens, het moet zonder vergelijkingen.

        We weten uit de rechtspraak dat SQL injectie een vorm van binnendringen is, omdat je daarmee toegang krijgt tot informatie die niet bedoeld was om opgevraagd te worden. Ik zie SQL injectie als een moeilijke vorm van URL aanpassen. Dus volgens mij is dan elke vorm van URL aanpassen een vorm van binnendringen.

        Rechtbank Rotterdam 14 april 2010, LJN BM1172:

        de verdachte [heeft in het computersysteem van een derde ingebroken door de op die computer aanwezige SQL-database te manipuleren middels een SQL-injectie, waardoor hij de beschikking kreeg over creditcardgegevens van derden.

        Gerechtshof ‘s-Gravenhage 3 februari 2012, LJN BV3397:

        dat door middel van een SQL-injectie toegang kan worden verkregen tot informatie op een server, welke toegang zonder die SQL-injectie niet mogelijk zou zijn. Met andere woorden: het gaat om gebruikmaking van een ‘achteringang’ tot de informatie op de serveren daarmee naar ’s hofs oordeel derhalve tot die server zelf.

        En in de parlementaire behandeling van dit wetsartikel (TK 1991-1992, 21551, nr 11, p. 23):

        Uiterst eenvoudige technische ingrepen of valse signalen waaraan geen listig aspect valt te bekennen, kunnen worden aangewend om diensten te verwerven die met behulp van telecommunicatie worden aangeboden. Ik acht het van belang dat al dergelijke vormen van bedrieglijkheden met behulp van informatietechniek worden gedekt, zonder dat in rechte behoeft te worden vastgesteld of het geautomatiseerd werk dat met dergelijke signalen of technische ingrepen wordt geconfronteerd, dergelijke trucs eenvoudig had moeten “doorzien”.

        Een getal ophogen in een URL is een “uiterst eenvoudige technische ingreep” lijkt me. Uit deze passage maak ik toch echt op dat het de bedoeling van de wetgever was om ook zo’n triviale techniek onder de strafbaarstelling te scharen.

        1. De derde quote is naar mijn idee niet van toepassing, want er is geen sprake van een bedrieglijkheid. Laat staan dat er sprake van een SQL injectie is, dus die eerste twee doen er ook niet toe.

          Heb je nog andere gronden?

          1. Die eerste twee doen er wel toe want ik zie het principiële verschil niet tussen een ID aanpassen en SQL injectiecode toevoegen. Beiden zijn aanpassen van een URL met als oogmerk de server iets te laten uitleveren dat de server niet had mogen uitleveren. Beiden gebruiken bugs in de server; de een een gebrekkige/afwezige check op openbaarheid van de resource en de andere een gebrekkige validatie op SQL in een parameter.

            Met “er is geen sprake van SQL injectie” heb je dus het argument niet weerlegd. Wat maakt injectie wézenlijk anders dan een string aanpassen? Een injectie ís een string.

        2. Een tehnische ingreep is het in grijpen in de werking van een systeem met behulp van technische kennis. Voor het uitvoeren van een SQL injectie heb je technische kennis nodig. Voor het veranderen van een numerieke waarde heb je deze kennis niet nodig. Bij dit laatste kunnen we ons ook de vraag stellen of we hiermee wel ingrijpen in de werking van een systeem? Deze vraag beantwoord ik negatief.

  1. dit is je reinste onzin. wanneer pagina’s (URL) publiek zijn, zijn deze dan ook publiek. Dat is nu eenmaal eigen aan het woord. Gaat men Google een proces voor huisvrvedebreuk aandoen omdat zo’n pagina gescreend wordt en weergegeven in zoekresultaten? Wwarom kan men niet gewoon toegeven dat dit een spijtige fout van de webmaster is?

      1. Deze vergelijking gaat niet op. Het opvragen van willekeurige URL bij een webserver is niet hetzelfde als het wegnemen van andermans eigendommen.

        Je kan het beter vergelijken met dat de DNB de kluisdeur open laat staat en ik daar gebruik van maak om naar binnen te kijken en de inhoud van de kluis te zien.

    1. Ik ben het niet met de vergelijking met de tuin eens: Een tuin ga je binnen. Dat binnengaan is hier het heikele punt en het is zeer aanvechtbaar of de betreffende persoon hier een computersysteem is binnengegaan.

      De juiste analogie is naar mijn mening een aanplakbiljet in de openbare ruimte, dat is afgeschermd zodat mensen het nog niet zien. Iemand ziet het toch, kijkt even achter de afscherming en maakt het bericht wereldkundig.

      Welnu, een interessante vraag is of het lezen van dat afgeschermde bericht strafbaar is en of naar analogie daarvan het lezen van de kersttoespraak strafbaar moet zijn.

  2. maakt de wet verder geen onderscheid tussen dingen die bedoelt zijn voor publicatie en het daadwerkelijk ontsluiten van informatie die nooit gepubliceerd moest worden. Ik kan me zo voorstellen dat http://rvd/toespraken/2012.mp4 benaderen als ../2011.mp4 ook bestaat iets heel anders is dan moedwillig met technische kennis dingen in het url typen die daar niet thuishoorde, zoals een stuk sql om authenticatie te omzeilen. En om toch de echte wereld vergelijking te doen: Is het inbraak/insluiping als ik het gemeente huis in loop, de publieke ruimtes waar de balies zijn, als de beveiliging is vergeten de deur af te sluiten

  3. Waarom maakt het uit of je dat met de toevoeging ” OR 1=1; SELECT * FROM userdata” doet of door 31337 te veranderen in 31338?

    Dat kan ik wel beredeneren.

    Wat mij betreft ben je een computer binnengedrongen op het moment dat je je hem commando’s kunt geven. Bij de SQL-injectie is dat het geval: Je kunt de database ieder commando geven die je wilt, de eigenaar van de server heeft geen controle over wat je doet.

    Een HTTP-verzoek is niets anders dan het opvragen van een document. Het is te vergelijken met de belastingdienst die aangifteformulier T heeft en je eens telefonisch probeert formulier U op te vragen, hetwelk al dan niet zal lukken. Bij het veranderen van 31337 in 31338 kan het HTTP-verzoek eventueel als commando aan de server gezien worden, je kunt alleen maar dat soort commando’s geven zoals de programmeur en daarmee eigenaar ze voorzien heeft. Je blijft binnen de controle die de eigenaar van de server uitoefend.

    Op het moment dat een server via HTTP een uitgebreide set commando’s gegeven kan worden zou je kunnen beredeneren dat je wel controle kan uitoefenen op de server op afstand en dat het dan wel binnendringen van een computer is.

    Bij het louter opvragen van een URL is daar nog lang geen sprake van.

    1. Maar een HTTP verzoek van de vorm ?id=123 is toch in feite een SQL query? Je wéét dat dit vertaalt naar “SELECT title,content FROM articles WHERE articleid=123”.

      Dan klein stapje verder: “?id=123 OR 1=1; SELECT content FROM articles –“. Nu krijg ik niet alleen artikel 123 maar ook alle andere. Dat is dan geen injectie zeg jij?

      1. Je voorbeeld is zeer slecht bij de SQL injectie kan ik de database overnemen als het gat daar voor zich leent, daarbij probeer je willens en wetens de database over te nemen. Bij het aanpassen van de URL kan het ook nog een type fout betreffen. De id=xxx is gewoon een URL als ik bij id=123 bij dit bericht uit kom dan is het voor andere mensen misschien logisch dat id=122 het bericht van gisteren is.

        De wet zo maken/oprekken dat een URL aanpassen verboden is dat is bedrijven beschermen of personen die niet weten hoe het internet werkt. Daarbij heb je nog een regering die zover van de hedendaagse techniek staan dat ze denken dat ze alles weten, kijk maar naar ICT en de staat de vele fouten die daar uit voortkomen is vragen om problemen.

        1. De intentie is voor mij cruciaal. Er is een verschil tussen een typfout in een URL maken en opzettelijk een URL aanpassen, ook al leidt de typfout tot dezelfde aangepaste URL. Net zoals er een verschil is tussen per ongeluk de verkeerde deur binnen gaan en opzettelijk diezelfde deur binnengaan.

          En tuurlijk, met SQL injectie kun je vaak élk commando uitvoeren dat je wilt. Met een buffel overflow kun je arbitraire commando’s op de shell uitvoeren. Maar fundamenteel blijft het URL manipulatie, want de injectie of de overflow exploit code plak je in de URL (oké soms de POST data maar dat even terzijde). Wáár houdt “gewoon de URL aanpassen” op en begint “de URL manipuleren met toegevoegde commando’s”?

          Ik ben het er helemaal mee eens dat deze wet heel fout is, maar volgens mij is het een feature en geen bug dat dit er onder valt.

          1. Dan zou ik ten allertijden fout bezig zijn aangezien ik meestal wel het geen wat ik wil hebben uit mijn hoofd weet. Zo zijn er websites die /2012/12/01 gebruiken om alles te laten zien wat er op die dag is gepost. Hierbij zijn type fouten snel gemaakt door op een dubble toets te drukken wat bij mij nog wel eens gebeurd.

            Trouwens bij de DNB als die de kluisdeur open laat staan dan kunnen hun ook gestraft worden aangezien ze iets uitlokken, maar op internet gelden ineens andere regels aangezien het voor bedrijven met een sisser afloopt.

          2. Ander voorbeeldje dan: Ik lees wel eens de commentaren op nujij.nl en soms zijn dat er nog al veel. nujij.nl begint met het laten zien van de meest recente en dus pas ik in de url de start van commentaar naar nummer 1 om zo de 1e te zien. Nu ben ik dus volgens de wet (en jouw beredenering) strafbaar? Lijkt me nogal ver gaan. Wat ik wel fout vind aan het toespraak verhaal is dat de persoon in kwestie het wereldkundig heeft gemaakt. Het aanpassen aan van de URL zelf niet.

              1. Ja, maar is die intentie ook cruciaal voor een ander? Er zijn genoeg hebberige graaiers in de wereld die maar wát graag ge/misbruik maken van dat illegale-url-gedoe. En we kunnen ons niet allemaal een advocaat veroorloven.

                  1. Als de intentie zo belangrijk is, dan had die journalist dus moeten zeggen: Ik keek of de kersttoespraak al toegankelijk was gemaakt op de website en dat bleek zo te zijn. Spreekt hij nog de waarheid ook 😉

                    1. @Arnoud (hmm ik kan niet op jouw reactie reageren). Of iemand werkelijk van beroep journalist is, is natuurlijk wel relevant voor zijn of haar werkelijke intenties. Dat geef je zelf ook al min of meer aan in je commentaar op de Nieuwe Revu uitspraak:

                      Waar ik nu heel bang voor ben, is dat al die scriptkiddies die eerst riepen “ik bewijs mensen een dienst door de beveiliging te checken” nu gaan roepen “oh ik ben journalist want ik onderzoek maatschappelijke misstanden door onvoldoende beveiliging”.
                      http://blog.iusmentis.com/2009/11/24/journalistieke-hack-van-revu-legaal/ Argh zelfs deze link naar jouw eigen blog triggerde Askimet al

                      1. Wauw, mijn blog is zo populair dat het WordPress-limieten en bugs blootlegt.

                        Inderdaad, het kan een maatstaf voor intenties zijn en inderdaad het argument is te misbruiken maar feit is en blijft dat een gewone burger die een misstand ontdekt, deze aan de kaak mag stellen en dan nét zo veel bescherming verdient van de wet als een NVJ-kaartdragende regenjas met typemachine.

  4. Maar een HTTP verzoek van de vorm ?id=123 is toch in feite een SQL query?

    Waarom? Het kan net zo goed het volgnummer zijn van een document op schijf.

    Dan klein stapje verder: “?id=123 OR 1=1; SELECT content FROM articles –”. Nu krijg ik niet alleen artikel 123 maar ook alle andere. Dat is dan geen injectie zeg jij?

    Wat ik zeg, is dat je op dat moment een manier hebt gevonden om het gebaande pad door de programmeur (het PHP-script) te omzielen en de computer willekeurige commando’s te geven. Behalve die “select” kun je bijvoorbeeld ook “drop database” doen.

    Het eerste is het opvragen van een genummerd document. Het tweede het bedienen van een computer.

    1. Wat is in deze context het relevante verschil tussen een SQL database en een lineaire lijst op een harde schijf? Beiden bieden een ID->content mapping.

      En oké, het gaat dus om het pad dat de programmeur baande. Met een DROP DATABASE ga je duidelijk van het padje af. Maar doe ik dat niet ook met ID=31337 waar de programmeur zelf alleen ID=123 en ID=124 publiceerde? Dat 31337 verzin ik zelf immers. Ik weet dat het best kan werken maar in feite is het toch net zo zelfverzonnen als DROP DATABASE?

      1. Blijft het feit dat iets wat direct via een URL te benaderen is openbaar is. Heel veel artikelen op het internet die doorlopend genummerd zijn, bijvoorbeeld op datum. Ik zou dit niet een achteringang willen noemen, maar je rijdt gewoon door de hoofdpoort! En daar is die voor bedoeld.

        Soms linken die niet door naar het volgende artikel, maar moet je terug via een hoofdpagina. Nu zeg je dus dat als ik dat niet doe en direct de URL verander ik in de situatie kan komen dat het illegaal is? Als ik toevallig het nummertje 1 teveel verhoog en op het artikel van morgen kom wat niet op de hoofdpagina is gelinkt, dan pleeg ik computervrede breuk?

        Ik vind dat persoonlijk nogal een groot verschil met SQL injecties. Een URL invoeren is opvragen van informatie, als je die niet openbaar wil hebben moet je die niet opvraagbaar maken. Als je een systeem gebruikt, moet je er vajnui9tgaan dat mensen dat herkennen.

        SQL injectie is gebruik maken van fouten in de beveiliging, heeft niets met opvragen van een pagina te maken, maar met manipuleren en gebruik maken van fouten/eigenschappen van de server om informatie op te vragen die niet opvraagbaar zou moeten zijn.

        Meegeven van ID=1337 ip ID=n00b is geen SQL injectie, ook al kan het best zo zijn dat die ID meegegeven wordt aan een Query. In dat geval als je 1337 niet wil publiceren, moet je database een foutmelding geven als je 1337 opvraagt.

        En waar eindigt het illegale dan? Als je met een gewone URL computervrede breuk pleegt, riskeer je dat dan iedere keer als je op een link klikt? Ieder link naar zo’n site zal immers de standaard vorm URL hebben.

        En oké, het gaat dus om het pad dat de programmeur baande. Met een DROP DATABASE ga je duidelijk van het padje af. Maar doe ik dat niet ook met ID=31337 waar de programmeur zelf alleen ID=123 en ID=124 publiceerde? Dat 31337 verzin ik zelf immers. Ik weet dat het best kan werken maar in feite is het toch net zo zelfverzonnen als DROP DATABASE?

        Hoe weet jij wat de de programmeur gepubliceerd heeft? Misschien linkt hij ergens anders wel naar 31337 ipv 123 en 124. En als er een systeem achter zit, wellicht zo simpel als doornummeren, dan verzin ik het niet. Dan gebruik ik een eigenenschap van die website. Ik weet dan dat ik bij het volgende artikel kom door het nummer te verhogen. Zet jij dan iets geheims op het volgende nummer dan ben je gewoon een idioot en moeten ze eigenlijk alle computers uit je beheer halen. Maar om dan maar meteen computervredebreuk te roepen? Dat is volstrekte willekeur en dat kan niet de bedoeling van de wet zijn.

        Waar staat tevens geschreven dat je alen op een URL mag komen als die gelinkt is? Begin 1993 typten de meeste mensen die ik kende hun URLs direct in, zoek machines waren er nog niet echt. Vaak ging dat proberen van www . (naamorganisatie) . edu/gov/com om te kijken of men uberhaupt een website had. Vandaag de dag zeg je dat dat computervredebreuk zou zijn als de organisatie nergens die URL had vrijgegeven?

        Sorry, maar jouw redenatie komt bij mij de giecheltest niet door. Dit is simpelweg schuld proberen af te schuiven van de RVD.

        Als dit dus inderdaad strafbaar is, dan zitten we met een heel foute wet die onschuldige mensen criminaliseert. Dat zou een erg kwalijke zaak zijn, waar de politiek niets aan zal doen. Diverse bewindslieden hebben al regelmatig aangetoont dat het ze niets interesseerd zoland ze maar naar infomartie kunnen graaien ‘in de strijd tegen kp en terrorisme’ (yuck wat ben ik ziek van dat argument) en als ze maar een stok hebben om te slaan naar alles wat ze niet zint. (ja ik wordt inmiddels ziek van de nederlandse politiek)

      2. Maar doe ik dat niet ook met ID=31337 waar de programmeur zelf alleen ID=123 en ID=124 publiceerde?

        Dit is inderdaad een hele belangrijke vraag voor de redeneerdoctrine die ik volg, maar hij is goed te beantwoorden.

        Je kunt een website zien als het systeem dat de programmeur aanbiedt, en je gaat buiten de gebaande paden als je andere dingen opvraagt dan de links waar je op kunt klikken. Ik ben geen voorstander van deze benadering, omdat het hele internet gebaseerd is op en aan elkaar hangt van de URL. Het is bij het internet explciet de bedoeling dan mensen URL’s invoeren, onthouden, en als gevolg daarvan op variëren.

        Als ik iets op Wikipedia iets opzoek dan doe ik dat meestal via de URL, bijvoorbeeld:

        http://nl.wikipedia.org/wiki/Arnoud_Engelfried

        Hierbij doe ik dan de ontdekking dat er geen artikel over jou bestaat. Het lijkt mij ongewenst dat bij mijn poging een artikel over jou te vinden mij eerst moet gaan afvragen of ik wellicht een strafbaar feit pleeg.

        Centraal staat daarom niet de website als geheel, maar de toonvideo.php?id=. Dat is de interface die de programmeur aan de buitenwereld aanbiedt. Die interface is gewoon zichtbaar in de URL-balk en daarmee toont de programmeur wat mensen kunnen onthouden, invoeren en variëren. Het aanroepen daarvan is in mijn visie normaal gebruik van de aangeboden documentopvraagdienst.

        1. Vervolgens zie ik een fout in jouw url en verander de laatste ‘d’ door een ’t’ en druk op enter. Die pagina bestaat wel op Wikipedia. Heb ik nu iets verkeerd gedaan? Lijkt mij niet.

          In bovenstaand geval ziet iemand een url die eindigt op: KH-181212-3998hd.mp4 Vervolgens probeert hij een variatie daarop uit: KH-251212-4003hd.mp4

          Ik kan daar op zich niets verkeerds in ontdekken. Heel veel mensen hebben ooit wel eens een url aangepast, bijvoorbeeld omdat de link niet klopte door een (typ)foutje. Ook als je op zoek bent naar het meeste recente wat er op de site te vinden is, dan zie ik niet zo wat daar precies het probleem is. Ze hadden het kunnen afschermen, dus als het vrij gemakkelijk toegankelijk is dan komt dit over op mij alsof dat bewust is gedaan of in ieder geval dat men het niet erg vindt als het dan toch gevonden wordt. Het is misschien eerder gevonden dan verwacht, maar dat betekent naar mijn idee niet dat men de intentie had het volledig af te schermen.

          Deze casus is eigenlijk al puur theoretisch (wie gaat hier nou een zaak van maken?), maar ik kan in alle redelijkheid geen (door 138a WvS beschermd) belang zien dat hier wordt geschaad. Zoals ook al in deze uitspraak staat: http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BP7080 “De wetgever heeft, zoals uit de wetsgeschiedenis blijkt, met artikel 138a, eerste lid, van het Wetboek van Strafrecht (‘computervredebreuk’) diegene willen beschermen “die blijkens feitelijke beveiliging heeft duidelijk gemaakt dat hij zijn gegevens heeft willen afschermen tegen nieuwsgierige blikken” (Kamerstukken II 1989/90, 21 551, nr. 3, p. 15). ” Ik mis hier die feitelijke beveiliging waardoor duidelijk was dat deze gegevens nog niet toegankelijk behoorden te zijn. Wanneer mocht je die url dan wel bezoeken? Als dit echt al strafbaar zou zijn, dan zouden enorm veel andere gevallen ook computervredebreuk zijn. Hoe vaak gebeurt het immers wel niet dat iets ‘uitlekt’ doordat iemand creatief was met de url?

  5. Het lijkt mij dat dit dan onder “een technische ingreep” zoals genoemd in de wet valt? Dan zou het strafbaar zijn, hoe bizar ook, maar dan vraag ik me dus af wanneer je niet strafbaar bent: met zoeken of klikken op een website geef je de webserver eveneens een dergelijk commando? (Je zou zeggen: met het bezoeken al.)

    We gaan er daarbij natuurlijk vanuit dat het het bedoelde gebruik is, maar feitelijk weet je dat niet per se zeker. Nu snap ik wel dat je voor deze toespraak bewust op zoek gaat door een datum aan te passen (en ik snap je punt over injectie), maar ik vind het wel erg moeilijk de precieze grens dan aan te geven. Als het gaat om geïndexeerde pagina’s, dan zijn er talloze aan te wijzen die onbedoeld toch openlijk toegankelijk zijn en gewoon doorzoekbaar en vindbaar met Google. (Een ‘open DIR’, bijvoorbeeld.) Daar kun je specifiek naar op zoek, maar evengoed ook ’toevallig’ uitkomen als je net naar heel specifieke informatie op zoek was.

  6. Maar Arnoud: Als jij geen hek om je tuin zet en jij vorig jaar ook een leuke gimmick in je tuin had staan, kan je er van uit gaan dat mensen in jouw tuin gaan kijken of er dit jaar ook weer een leuke gimmick staat? Dat je die gimmick geheim wilde houden tot een bepaald moment is je goed recht. Maar ga niet zeuren als er iemand voor die tijd in je tuin kijkt en er staat gewoon al iets, wat ie dan vervolgens op twitter gooit. Er stond ook geen bordje naast je gimmick met “niet verklappen tot na 1e kerstdag” of zoiets, of een zeiltje er overheen getrokken. Puur het weten dat het in jouw tuin staat was al genoeg om de gimmick te ontdekken. Er is niemand die je tuin ingelopen is, of op andere manieren huisvredebreuk heeft gepleegd, want jouw tuin is gewoon te zien vanaf de openbare weg. Ja, vorig jaar stond je gimmick achter de tuinkabouter naast de windmolen en nu staat de gimmick aan de andere kant van de windmolen. Dat is niet hetzelfde als “afgeschermd” maar gewoon net op een andere plek neergezet. Dat kan ook haast niet anders, tenzij je de gimmick van vorig jaar wilt vervangen met die van dit jaar. Je wilt er elk jaar eentje bijplaatsen, dus je zet hem keurig op een voor de hand liggende plek, op volgorde naast die van vorig jaar.

    Er zijn industry standards en best practices die gaan over het be- en afschermen van gegevens. Geen van deze schrijven voor dat je URLs niet moet linken en claimen dat ze zo vielig weggezet zijn. Afschermen en beschermen kan je doen door middel van wachtwoorden op de content, versleuteling van de content en dergelijke. Al deze technieken worden door de overheid gebruikt, ook op de website(s) waar deze content op stond. Je kan er dus redelijkerwijs van uit gaan dat alles wat niet door deze maatregelen beschermd wordt, openbare informatie is, tenzij er expliciet bij staat dat dat niet zo is.

    Deze fout is meerdere malen eerder door de overheid gemaakt. Ondanks dat, is er klaarblijkelijk geen protocol om dit soort dingen te voorkomen, of niet afdoende controle op het naleven daarvan. Als een beroeps-journalist dit had gedaan, was er niemand geweest die het strafbaar had gevonden, want dan viel het gewoon onder nieuwsgaring. Dan was de aandacht niet op die journalist gevestigd, maar alleen maar op het stukje overheid die dit zo klungelig online heeft gezet.

    Misschien dat deze handeling volgens de letter van de wet strafbaar zou zijn. Ik weet dat nog niet zo zeker, maar zelfs als dat zo is, kan je de persoon die de handeling uitvoerde en daarna de “openbaarmaking” deed niet aanrekenen dat door zijn toedoen een ingeblikte speech ietsje eerder te bewonderen viel dan de bedoeling is. Er is op zoveel manieren zo laks omgegaan met de hele beveiliging van de bestandjes en de schade die hierdoor is ontstaan is zo ontzettend triviaal dat vervolgen of zwartmaken van de “ontdekker” me totaal niet gepast lijkt. Het lijkt me eerder een aanleiding om de hele overheid eens door te lichten. Welke dingen die er wel toe doen zijn ook op zo’n knullige manier online te vinden? Daar hoor je helemaal niets en niemand over, terwijl me dat oneindig veel belangrijker lijkt.

    Eigenlijk zou Beatrix volgend jaar gewoon haar speech weer live moeten geven. Dat geeft toch een beter gevoel van commitment van ons staatshoofd dan een vooraf ingeblikt stukje stemmige beelden en dan zou al dit gedoe met afschermen ook niet nodig zijn.

  7. Het blijft natuurlijk van de zotte dat de RVD een “onderzoek” gaat instellen, en ik kan me níet voorstellen dat het OM meer dan vijf minuten besteedt aan een eventuele aangifte.

    Als het strafbaar is, wat de stelling is van Arnoud, moet het OM dan niet gewoon vervolgen? En is het dan niet aan de rechter om te kijken hoe de context van deze ‘hack’ op een juiste manier moet worden toegepast op een eventuele strafmaat?

    Stel het OM werkt niet mee… En RVD start een art. 12 procedure… Wat dan? Dan moet er dus uitkomen dat het strafbaar is… en dan moet het OM dus alsnog vervolgen?

    Zit ik hier nu te binair in of klopt het wat ik zeg?

  8. Ja, we hebben sinds 2006 brede definitie van computervredebreuk, maar dat wil nog niet zeggen dat hier spraken is van binnen dringen. De wet geeft een niet-limitatieve opsomming van wanneer er in ieder geval spraken is van binnendringen. In het geval van SQL injecties wordt er duidelijk een technische ingreep uitgevoerd. Dit is een handeling die een doorsnee gebruiker c.q. leek niet zou kunnen uitvoeren. Daarom zie ik het aanpassen van een URL niet als een technische ingreep.

    Hier komt bij dat er met behulp van SQL injecties gebruik wordt gemaakt van bugs in de software, terwijl dit niet het geval is bij het aanpassen van de URL. In het laatste geval wordt verzoekt de bezoeker een pagina en wordt dit verzoek gehonoreerd. Als dit binnendringen is dan is de RVD verzoeken om alvast de kersttoespraak op te sturen dat ook.

    De vergelijking met je achtertuin zie ik niet. De intentie van de eigenaar heeft met het installeren van een webserver de intentie om de bezoekers toegang te geven tot zijn computer. Een website zou vergeleken moeten worden met de openbare ruimte. Het plaatsen van de kersttoespraak op de webserver is een vorm van distribueren. Hiermee komt het namelijk ter beschikking van het publiek.

  9. Wat ik mij dan afvraag is waar ligt de grens tussen een typfout in de URL (waardoor je op zo’n pagina komt) en manipuleren? Bovendien is het pas een “probleem” geworden toen de media er bovenop dook. Als de media er niet bovenop was gedoken had verder niemand het geweten.

    1. De tekst uit de aangehaalde parlementaire behandeling heeft het over bedriegelijkheden. Terwijl het aanpassen van een cijfer in de URL m.i. eerder ligt in de lijn van vraagstelling. Hoe bedriegelijk is het om een systeem een vraag te stellen waarop een (bij dat systeem) voorzien (eenduidig) antwoord komt, al dan niet op een te vroeg tijdstip …

  10. Dus de wet zou bepalen dat het strafbaar is voor een derde om iets dat publiek op een webserver beschikbaar gesteld is daadwerkelijk op te halen.?

    Lijkt me leuk, mensen vertellen dat ze een misdrijf danwel overtreding kunnen plegen door in het adresveld van hun browser een tikfout te maken.

    Terwijl de essentie toch altijd was om iets niet op een publieke webserver te plaatsen als het niet publiek beschikbaar mocht zijn.

  11. Ik vind het idee dat het gebruik van een URL in principe een verzoek is tot datgene waar de URL naar verwijst, zoals in de reacties hiervoor wordt genoemd, wel een goed uitgangspunt. Het is de verantwoordelijkheid van de eigenaar/beheerder van een site om te bepalen wie er na een verzoek (bijvoorbeeld middels een URL) toegang heeft tot de gegevens op de site. Het argument dat er sprake is van een technische ingreep houdt in dit geval geen stand. De betreffende URL was (en is) een geldige URL die leidt naar de opname van de kersttoespraak. Er is geen valse identiteit gebruikt en er is ook geen gebruik gemaakt van een bug zoals bij een SQL-injectie wel het geval is. Dat men de bedoeling had om de URL (tijdelijk) geheim te houden valt nergens uit af te leiden.

  12. Poging vijf, mijn posts verdwijnen in het niets. Nu eens met wat minder hyperlinks. Ja, dat helpt, en als ik dan ‘bewerken’ doe en zin voor zin weer toevoeg dan kom ik ergens. Arnoud, kan jij eens kijken wat er hier aan de hand is, gelukkig had ik nu mijn reactie nog in het clipboard maar ik raak wel vaker iets kwijt op deze site en het vergalt mijn enthousiasme wel een beetje.

    Observatie: de discussies rondom openbaarmaking, auteursrecht en nu ook computervredebreuk spitsen zich steeds vaker toe rondom de vraag of het feitelijke openbaarmaken gebeurt door het plaatsen van hyperlinks of door het ter beschikking stellen van het feitelijke bestand. Dit argument komt hierboven langs maar ook in bv Edskes vs Realnetworks en de Buma/Stemra embed-discussie.

    Ik kan er een stuk in meegaan. Maar SQL injectie gaat buiten de lijnen van wat de ontwikkelaar van de website heeft beoogd, en het veranderen van 31337 in 31338 (leuk voorbeeld BTW) niet.

    Echter, als ik niet meer aan URL’s mag knoeien, mag ik dan wel nog een slash ergens achter zetten? Of www ervoor? Of zelf een URL invoeren? En als ik op http://blog.iusmentis.com zit weer kijken of er ook een gewone site bestaat door ‘blog’in ‘www’ te veranderen? En als ik naar http://blog.iusmentis.com/wp-admin ga? En wat als een lezer gewoon op de link uit de vorige zin in deze reactie klikt? Waar trekken we de lijn in wat knoeien is en wat niet?

    -edit Arnoud: ik heb géén idee waarom jij voor spammer aangezien wordt. Je pogingen 1 t/m 3 kan ik niet vinden, poging 4 zat in de spam en deze kwam er inderdaad door. Ik mail je even.-

  13. Het moge duidelijk zijn dat dit gewoon een catch-all wetje is, puur om dubieuze en onbekende manieren van informatievergaring strafbaar te stellen. In principe stellen ze hiermee alle vormen van browsen strafbaar. Van de andere kant… probeer maar eens hard te maken en te bewijzen dat die url met dat ‘foute’ ID niet op een moment wél (even) online heeft gestaan.

  14. De vergelijking met SQL injectie gaat niet op. Bij SQL injectie laat je een achterliggend systeem dingen doen die niet de bedoeling zijn. In het HTTP protocol is niet voor niets de ‘404 Not Found’ code opgenomen om een reactie te kunnen geven op URL’s waar geen content achter hangt. Het opvragen van een willekeurige pagina bij een webserver strafbaar stellen is hetzelfde als iemand voor inbraak aanklagen omdat hij opzoek ging naar een huisnummer in een straat waarbij dat huisnummer niet bestaat.

    Bij het opvragen van een willekeurige pagina door een zelf verzonnen URL of een aangepaste URL is er ook helemaal geen sprake van ‘binnendringen van een systeem’. Je doet namelijk niets wat niet in het HTTP protocol is opgenomen. Je spreekt daarbij 100% HTTP. Je maakt dus geen misbruik van een systeem. Je doet niets meer dan gebruik maken van een openbaar systeem volgens een internationaal afgesproken standaard.

    1. Het opvragen van een willekeurige pagina bij een webserver strafbaar stellen is hetzelfde als iemand voor inbraak aanklagen omdat hij opzoek ging naar een huisnummer in een straat waarbij dat huisnummer niet bestaat.
      Dit soort metaforen is echt dodelijk, maar als je het dan toch in een metafoor wil gieten dan komt het overeen met alle huizen in een straat binnengaan op zoek naar mijn vrienden, onder het motto ‘ik doe niks verkeerd de achterdeur stond toch open’.

      Juridisch gezien is voor dit soort gevallen “huisvredebreuk” bedacht, voor inbraak zonder braak, zogezegd.

        1. Ja precies. Je mag best bij iedereen aanbellen en vragen “Mag Patrick buiten komen spelen?” ook al ken je Patrick niet eens. Als dan vervolgens de ouders van Patrick hem naar buiten duwen (“Hiero, spelen jullie!”) dan is dat geen huisvredebreuk, je bent niet eens binnen geweest. Je mag ook vragen of je de tv mag hebben, of de kersttoespraak van volgend jaar.

          Hetzelfde geldt voor een systeem dat documenten serveert naar hand van een ID. Daar kun je een document aan vragen naar hand van een link (docs.php?id=123) of je kunt vragen of document 124 buiten mag komen spelen. Als dan vervolgens de ouders van document 124 “ja hoor, hiero (200 OK)” zegt, dan is er niks aan de hand. Je hebt het systeem gebruikt zoals bedoeld en netjes gevraagd of het mag (een HTTP verzoek is een verzoek). Je verkrijgt ook geen toegang tot het systeem in de zin dat je ‘binnen’ bent. Je mag documenten opvragen, niet meer en niet minder. Computervredebreuk kan dus niet van toepassing zijn.

          Bij SQL injectie gebruik je weliswaar het systeem qua onderliggende software als bedoeld: webserver en database maken dit prima voor je mogelijk. Maar de uiteindelijke inrichting, de website, geeft niet expliciet de mogelijkheid om willekeurig iets uit de DB op te halen, tenzij je truukt. Nu begrijp ik wel dat hacken geen vereiste is voor computervredebreuk. Maar iets met het “breken” van die computervrede, moet het toch wel te maken hebben.

    2. Bij SQL injectie laat je een achterliggend systeem dingen doen die niet de bedoeling zijn.

      De URL-manipulatie laat de webserver iets doen dat niet de bedoeling is (van de webmaster). Dus het maakt uit of het de frontend of de backend is die je dingen laat doen?

      Er was jaren terug een bug in ik meen Microsoft IIS waarbij je DOS-commando’s kon opgeven in een URL, en die werden dan uitgevoerd (iets met “../../../../cmd.exe format c: /yes” in de URL, ah ja, dit). Is dat dan het achterliggend systeem? Manipuleer ik nu of roep ik gewoon een URL op gewoon volgens de http standaard? Immers .. is gewoon iets dat in een pad mag staan, en tsja dat de server me dan buiten de webdocs/ padstructuur laat uitkomen en ook nog eens zo dom is om een interpreter te starten die met admin privileges een disk formatteeert, tsja..

      1. Er is een belangrijk verschil tussen het ophogen van een datum of volgnummer in een URL en het uitvoeren van command-injection (je ‘cmd.exe’ verhaal) via een URL.

        Bij het ophogen van een datum of volgnummer maak je geen misbruik van een technische fout in het systeem en je omzeilt geen beveiliging. Je gebruikt het systeem zoals het technisch gezien bedoeld is.

        Bij command-injection misbruik je een technische fout in de applicatie om opdrachten uit te voeren waartoe je niet gemachtigd bent. Je omzeilt daarmee ook een eventueel aanwezige beveiliging. Je gebruikt het systeem niet zoals het technisch gezien bedoeld is.

        In het geval van de kersttoespraak was er sprake van een functionele fout in de website, geen technische fout. Er kan alleen sprake zijn van ‘inbreken in een systeem’ als er misbruik gemaakt wordt van een technische fout in een systeem of waarbij je een beveiliging omzeilt.

        1. Er kan alleen sprake zijn van ‘inbreken in een systeem’ als er misbruik gemaakt wordt van een technische fout in een systeem of waarbij je een beveiliging omzeilt.

          Alleen staat in de wet dat je ‘binnendringt’ in een systeem zodra je willens en wetens je op onbevoegd terrein bent. Niet pas nadat je een beveiliging hebt omzeild of een technische ingreep of valse sleutel hebt toegepast.

          Je gebruikt het systeem niet zoals het technisch gezien bedoeld is.

          Het systeem van een website is ook niet bedoeld (door de RVD) om met ID nummers te gaan zitten spelen. Dat je browser dat toelaat, wil nog niet zeggen dat de RVD dat bedoeld heeft.

          Wiens bedoeling moet je hier voor ogen hebben? De website-exploitant? De browserbouwer?

          1. Alleen staat in de wet dat je ‘binnendringt’ in een systeem zodra je willens en wetens je op onbevoegd terrein bent. Niet pas nadat je een beveiliging hebt omzeild of een technische ingreep of valse sleutel hebt toegepast.

            Alleen kan je aan een URL niet zien of het gaat om bevoegd of onbevoegd terrein. Dat kan alleen maar blijken uit het antwoord van de webserver (200 OK, 401 Unauthorized, 403 Forbidden). Dus van ‘willens en wetens’ kan tijdens het eerste keer intikken van een URL geen sprake zijn.

            Het systeem van een website is ook niet bedoeld (door de RVD) om met ID nummers te gaan zitten spelen. Dat je browser dat toelaat, wil nog niet zeggen dat de RVD dat bedoeld heeft.

            De RVD kan wel meer wel of niet bedoelen, maar dat is niet hoe websites werken. Het zou bijzonder zwak zijn als de RVD zich beroept op dat zij het niet zo bedoelden, terwijl de rest van de wereld het anders ziet. “Ja, sorry meneer de rechter. Ik heb vertrouwelijke informatie voor het raam neergelegd, maar het was niet mijn bedoeling dat voorgangers het gingen lezen. Dus het is niet mijn fout, maar die van de voorbijgangers.” Er zijn meer dan genoeg mogelijkheden om informatie ‘klaar te zetten’ op een webserver voor toekomstige publicatie. Dat konden we 15 jaar geleden al. Als je daar geen gebruik van maakt, dan is het dus openbare informatie.

            1. Alleen kan je aan een URL niet zien of het gaat om bevoegd of onbevoegd terrein. Dat kan alleen maar blijken uit het antwoord van de webserver (200 OK, 401 Unauthorized, 403 Forbidden). Dus van ‘willens en wetens’ kan tijdens het eerste keer intikken van een URL geen sprake zijn.

              Het antwoord is niet doorslaggevend, want ook bij een hack via de URL krijg je een 200 OK terug. Denk aan een SQL injectie wederom, of een exploitcode in de URL die een buffer overflow exploiteert. Als ik “user=robert%20tables;)%20DROP%20%database” in een query URL toevoeg dan zal de server echt 200 OK terugzeggen, maar de database is wel weg.

              Het is ook geen automatisme dat zelf intikken = onbevoegd terrein, dat ben ik met je eens.

              Je moet kijken naar intentie van de typer, de gewoonte op die site en wat je redelijkerwijs algemeen mag verwachten. Net zoals je bij een café niet zomaar kunt zeggen “je ging een deur door dús lokaalvredebreuk” maar iets moet vinden als een bordje Privé of het feit dat de deur achter een stapel kratten weggewerkt was (of dat er een keuken hoorbaar was achter de deur).

              1. Het antwoord is niet doorslaggevend, want ook bij een hack via de URL krijg je een 200 OK terug. Denk aan een SQL injectie wederom, of een exploitcode in de URL die een buffer overflow exploiteert. Als ik “user=robert%20tables;)%20DROP%20%database” in een query URL toevoeg dan zal de server echt 200 OK terugzeggen, maar de database is wel weg.

                Ik blijf het zeggen, de vergelijking met SQL injection is niet terecht. Bij een SQL injection maak je misbruik van een technische fout, bij het ophogen van een volgnummer in een URL niet. Het verschil tussen het gebruiken van een technische fout om informatie in te zien en het gebruiken van een functionele fout om informatie in te zien is waar het hier om gaat. Daarin zit de essentie. Bij SQL-injectie gaat het om het gebruiken van een technische fout, het ophogen van een volgnummer is het gebruiken van een functionele fout.

                Wat betreft je buffer overflow. Als een programmeur slechts rekening houdt met plaatsnamen als Oss, Delft en Breda, terwijl ik toch echt in Gasselterboerveenschemond woon, dan is het niet mijn schuld als de applicatie daardoor crasht en ben ik dus niet schuldig aan computervredebreuk. Echter, als ik deze fout misbruik om in te breken, dan weer wel.

                Je moet kijken naar intentie van de typer, de gewoonte op die site en wat je redelijkerwijs algemeen mag verwachten. Net zoals je bij een café niet zomaar kunt zeggen “je ging een deur door dús lokaalvredebreuk” maar iets moet vinden als een bordje Privé of het feit dat de deur achter een stapel kratten weggewerkt was (of dat er een keuken hoorbaar was achter de deur).

                Als de intentie zo belangrijk is, dan snap ik helemaal niet waarom je van mening bent dat het hier computervredebreuk betreft. Anne Jan was namelijk helemaal niet op zoek naar vertrouwelijke informatie, laat staan de kersttoespraak. Het ging hem om SEO-achtige zaken met betrekking tot de website.

                En wat betreft je privebordje, die is echt nergens aanwezig op de website. Iets vergelijkbaars was ook niet te zien na het voortijdig opvragen van de kersttoespraak.

                Maar het belangrijkste vind ik nog wel dat met het strafbaar stellen van dit soort handelingen je echt een heeeel gevaarlijk signaal afgeeft. De overheid (en andere organisaties) zijn al zo extreem naief en klungelig als het gaat om informatiebeveiliging. Het wordt echt tijd om met de beschuldigende vinger te wijzen naar waar de fout ligt en niet de veroorzaker daarbij een half excuus mee te geven.

                1. Bij een SQL injection maak je misbruik van een technische fout, bij het ophogen van een volgnummer in een URL niet.

                  Fout is fout, denk ik dan. Of het nu het niet valideren van input is of het vinkje “concept/privé” vergeten bij een video uploaden, het is en blijft een fout van de webmaster.

                  Wat jij zegt komt neer op, er staat “ID=” dus daarachter mag ik elk getal invoeren dat ik wil en dat kan nooit binnendringen zijn. Wie me een ID laat opgeven, moet niet gek opkijken als ik een ID opgeef. Maar een ID van de vorm “35; drop database” is geen echt ID en dus wezenlijk wat anders. Maar waar trek je dan de grens? Als ik ID=12342345541472492459425249542947544239345437439 invul en dat blijkt een buffer overflow te triggeren, heb ik dan nu eigenlijk geen echt ID ingevuld (en dus gehackt) of mag ik deze overflow nu exploiteren?

                  Echter, als ik deze fout misbruik om in te breken, dan weer wel.

                  Maar wat is inbreken? Ik vraag alleen maar data op. Dat de server dan dingen wist in de database (of me dingen laat zien die niet via de eigenlijke website online staan), tsja.

                  Als de intentie zo belangrijk is, dan snap ik helemaal niet waarom je van mening bent dat het hier computervredebreuk betreft. Anne Jan was namelijk helemaal niet op zoek naar vertrouwelijke informatie, laat staan de kersttoespraak. Het ging hem om SEO-achtige zaken met betrekking tot de website.

                  Goed punt, hoewel ik twijfel naar dat “ik keek alleen naar de SEO”. Ik vind het iets te toevallig, de datum van de kersttoespraak 2011 aanpassen naar dit jaar en dan verbaasd zijn dat je de kersttoespraak van dit jaar krijgt. Maar inderdaad, als het écht toeval was of een onbedoeld bijeffect van iets heel anders dan is het geen computervredebreuk. Net zoals gisteren toen ik ineens in de keuken stond van een restaurant terwijl ik de wc zocht.

                  1. Fout is fout, denk ik dan. Of het nu het niet valideren van input is of het vinkje “concept/privé” vergeten bij een video uploaden, het is en blijft een fout van de webmaster.

                    Ben ik niet met je eens. Het niet valideren is niet een fout van de webmaster, maar van de programmeur. Het is een technische fout. Een gebruiker moet iets ‘speciaals’ doen om dit te misbruiken. Het vinkje concept/prive vergeten is een functionele fout. Dezelfde URL invoeren maar dan met dat vinkje aan geeft een melding: “mag u (nog) niet kijken” of iets van dien aard. De gebruiker doet niks verkeerd bij het opvragen van die pagina, met of zonder vinkje.

                    Wat jij zegt komt neer op, er staat “ID=” dus daarachter mag ik elk getal invoeren dat ik wil en dat kan nooit binnendringen zijn.

                    Correct.

                    Wie me een ID laat opgeven, moet niet gek opkijken als ik een ID opgeef. Maar een ID van de vorm “35; drop database” is geen echt ID en dus wezenlijk wat anders.

                    Ook correct. En daarom is dit wel hacken. Je probeert hiermee een fout te misbruiken.

                    Maar waar trek je dan de grens? Als ik ID=12342345541472492459425249542947544239345437439 invul en dat blijkt een buffer overflow te triggeren, heb ik dan nu eigenlijk geen echt ID ingevuld (en dus gehackt) of mag ik deze overflow nu exploiteren?

                    Het invullen van een heeel groot getal is geen hacken. Echter, een heel groot getal invullen dat een buffer overflow triggert gevolgd door exploit code weer wel. Zou ik zeggen dan 🙂

                    1. Het invullen van een heeel groot getal is geen hacken. Echter, een heel groot getal invullen dat een buffer overflow triggert gevolgd door exploit code weer wel.
                      Volgens mij kun je geen buffer overflow genereren door alleen een URL aan te passen, tenzij de ontwikkelaar die de site heeft gebouwd een enorme onbenul is en de server software in C++ of C heeft ontwikkeld. Maar moderne ontwikkelaars gebruiken vooral PHP of .NET en deze twee omgevingen zijn goed bestend tegen buffer overflows. Daarnaast, exploit-code toevoegen bij gebruik van een buffer overflow is vergelijkbaar met “35; drop database” toevoegen aan een URL. Je voegt dan namelijk naast het nummer ook extra exploit-code toe.

                      In .NET worden dergelijke parameters via routing gedefinieerd en is de .NET runtime verantwoordelijk voor het correct vertalen van de ID’s naar functie-parameters van een bepaald type. Mede dankzij de routing-technieken die .NET maar ook andere ontwikkel-omgevingen bieden is het ook logisch dat bezoekers die bekend zijn met de routing parameters dus zelf een URL aanpassen om naar een specifiek product te gaan.

              2. wat je redelijkerwijs algemeen mag verwachten

                Het manipuleren van URL’s is een gebruikelijke en achtenswaardige manier van navigeren door internetdiensten die paradoxaal genoeg veel ouder is dan de URL zelf (1994).

                  1. Een URL als ftp://dinges.com/pad/naar/mijn.doc is een shortcut om met een FTP-client in te loggen, ‘cd pad/naar’ te doen en dan met ‘get mijn.doc’ het document op te vragen. Voordat URLs bestonden was inloggen op een server, rondneuzen met ‘cd’ en ‘ls’ en dan documenten naar keuze ophalen de manier om aan elders opgeslagen bestanden te komen. Iedereen wist dat als je iets op een FTP-server neerzet en je wilt niet dat de hele wereld het kan downloaden je dan de bestandspermissies moet beperken zodat anonieme gebruikers geen leesrechten hebben; dat iets moeilijk vindbaar maken en dan achteraf zeuren dat mensen het toch hebben gevonden geen geldige manier van werken is. Die wetenschap is dus ouder dan de URL.

          2. Even een ander voorbeeld. Stel, het koninklijk huis heeft http://www.koninklijkhuis.nl/kersttoespraak als URL voor de kersttoespraak. In het hoofdmenu is een link naar die pagina opgenomen. Halverwege het jaar halen ze die link weer weg uit het hoofdmenu. De pagina blijft echter bestaan. Een paar dagen voor kerst passen ze die pagina aan door er de nieuwe kersttoespraak op te zetten. In hun planning staat dat ze op 1ste kerstdag de link naar die pagina weer in het hoofdmenu opnemen om de kersttoespraak aan het publiek vrij te geven.

            Nu wil ik graag de dag voor kerst de kersttoespraak van vorig jaar nog eens zien. Ik heb de URL van toen onthouden en tik deze in met de verwachting de kersttoespraak van vorig jaar te zien te krijgen. Echter, ik krijg nu de kersttoespraak van dit jaar al te zien. Volgens jou redenering ben ik nu schuldig aan computervredebreuk terwijl alles wat ik deed is een URL intikken zonder daarbij enige vorm van beveiliging te omzeilen of misbruik te maken van een technische fout. Ik heb de website van het koninklijk huis op een normale manier gebruikt, gebruikt zoals alle websites gebruikt kunnen worden.

            Het intikken van een URL, zonder daarbij bewust misbruik te maken van een technische fout of een beveiliging te omzeilen zou volgens mijn mening nooit computervredebreuk als gevolg moeten hebben. Als door het intikken van een normale URL vertrouwelijke informatie ingezien kan worden, dan ligt de fout voor de volle 100% bij de website-eigenaar. Het betreft dan namelijk een functionele fout, geen technische fout.

            1. @Wim ten Brink: je kan prima een buffer overflow genereren door alleen een URL aan te passen. Vergeet niet dat in .NET of PHP zelf ook een buffer overflow bug kan zitten.

              En iemand die een webapplicatie in C(++) bouwt is niet per se een onbenul. Denk maar aan embedded software.

              1. En iemand die een webapplicatie in C(++) bouwt is niet per se een onbenul.
                Maar iemand die een buffer overflow toelaat in een C++ applicatie is wel degelijk een onbenul, vooral ook omdat deze kwetsbaarheid al enorm lang bekend is. Een ervaren C++ programmeur weet hoe hij buffer overflows voorkomt. Mede ook omdat ze al rond 1975 bekend waren. Ruim 20 jaar geleden waren al de eerste virussen aktief die misbruik maakten van buffer overflows.

                Een buffer overflow genereren via de URL is in principe wel mogelijk bij gebruik van eigengemaakte web server software. Maar zowel Apache als IIS hebben al behoorlijk wat bescherming aktief tegen dergelijke aanvallen. Java, .NET en de meeste script-based talen zullen ook de nodige controles uitvoeren tegen de meest voorkomende buffer overflow aanvallen. Maar inderdaad, er kan altijd nog ergens een bug in de code zitten van de server.

                De buffer overflow is vooral een probleem bij applicaties die in C of C++ zijn ontwikkeld omdat deze talen niet altijd controles uitvoeren op de maximale grootte van geheugenblokken. Je kunt dan 200 bytes stoppen op een plaats waar maar 100 bytes passen. En jammer genoeg worden er dan 100 bytes van iets anders overschreven met mogelijk rampzalige gevolgen. Bij C en C++ is hier juist voor gekozen om de performance nog iets meer te verbeteren, want die controles kosten extra processortijd. En een goede programmeur weet ook wanneer een dergelijke controle overbodig is omdat hij al zekerheid heeft dat de data exact zal passen in de buffer. Je hebt voor C en C++ dan ook veel ervaring nodig om goed met dergelijke code om te kunnen gaan. Maar zoals bij iedere ontwikkel-omgeving heeft ook C en C++ veel last van onbenullen met te weinig programmeer-ervaring die dit soort kwetsbaarheden in de code laten zitten.

          3. Alleen staat in de wet dat je ‘binnendringt’ in een systeem zodra je willens en wetens je op onbevoegd terrein bent.

            Dat lijkt me hier heel lastig aan te tonen. Immers, de kersttoespraak werd teruggegeven. Dat klinkt als bevoegd terrein. Als het onbevoegd terrein was, had de RVD het wel beveiligd.

            Doet me denken aan toen ik (piep)jong was. Mijn ouders hadden beloofd dat de paashaas eieren zou verstoppen in de tuin, en dat mijn broertjes en ik die mochten gaan zoeken. Wij vroeg opstaan, en zoeken, en zoeken, maar niks gevonden. Een van ons kwam op het idee eens in het schuurtje te kijken, strikt genomen niet “de tuin”, en daar bleken alle eieren te liggen, netjes in een traytje bij elkaar. De paashaas had zich verslapen.

            Om de een of andere reden waren onze ouders kwaad, en sterker nog, ze leken kwaad op ons.

  15. Even vanuit een andere hoek bekeken: Stel ik geef iemand mijn laptop om wat te tikken. De persoon is nieuwsgierig en opent een document dat op de harde schijf staat. Ik word boos. Kan ik aangifte doen van computervredebreuk?

    Ik denk het niet: De betreffende persoon gebruikte de computer met mijn toestemming. Als ik niet wilde dat hij bestanden zou openen, had ik hem geen toestemming moeten geven mijn apparaat te gebruiken. Zelfs als ik erbij gezegd had dat hij geen documenten mocht openen, dan was het waarschijnlijk enkel contractbreuk geweest en geen computervredebreuk.

    Zo is het hier ook: Het Koninklijk Huis geeft het publiek toestemming hun webserver te gebruiken voor het bekijken van video’s. Dat iemand toevallig een video ontdekt waarvan men wilde dat hij niet bekeken werd, is vervelend, maar doet niets af aan het feit dat de persoon hier in kwestie toestemming had die webserver te gebruiken om video’s te bekijken.

    Voor computervredebreuk is het echt noodzakelijk dat je een computersysteem binnendringt. Dat binnendringen is strafbaar en niet het uitvoeren van een commando dat de eigenaar niet leuk vindt.

    Het gevaarlijkste stukje wetstekst is “door een technsiche ingreep”. Die ingreep mag inderdaad eenvoudig/triviaal zijn. Maar we moeten niet vergeten dat een technische ingreep bedoeld wordt die leidt tot het binnendringen van een computersysteem. Als geen sprake is van binnendringen dan doet al de rest niet ter sprake.

    1. Oké, stel het is geen computervredebreuk dat hij die map openmaakt. Maar stel jij zet een wachtwoord op die map, en hij start je laptop opnieuw op met een rescue CD en passeert zo het wachtwoord. Vind je het dan nóg geen computervredebreuk?

      Het opvragen van data uit een computersysteem is een vorm van binnendringen. Zie de jurisprudentie over SQL injectie die ik eerder noemde. Bij een injectie heb je ook geen prompt of iets dergelijks dat we traditioneel “binnen” noemen, maar je hebt wel controle over wat het systeem doet.

  16. Dit is een gebied met wel meer dan 50 tinten grijs. Inderdaad. Vroeger tikte je de URL gewoon in. Zo kon het zijn dat als je ipv ORG een COM achter Nasa intikte, je op een pornisite kwam. En wat als je de weervoorspelling wil bekijken van morgen… Dit doe je elke dag. Je weet de url uit je hoofd. Maar dit keer maak je een tikfout. (En dat hoeft helemaal geen ingewikkelde url te zijn; het gaat hier om de manupilatie van een url.) je komt op een testpagina van het knmi. Wat nu? Volgens bovenstaande blog ben je dan strafbaar. Je hebt het gevonden. Net zoals je een portemonnee vind op straat. Kijk je erin om de eigenaar te achterhalen? Kijkt een baliemedewerker erin om de naam van de eigenaar om te laten roepen?

  17. Ik probeerde hier een vergelijking te vinden met het teletekst systeem. Je geeft een paginanummer (url) en het scherm toont je – indien aanwezig – de bewuste pagina.

    Stel nu, de redactie van teletekst heeft ’s morgens een belangrijk persbericht gekregen maar mag dit pas om 12 uur publiceren. Om de tekst om 12 uur beschikbaar te hebben wordt deze vast uitgewerkt en klaar gezet op pagina 129. Ik noem maar wat. Er is verder geen verwijzing zichtbaar op pagina 101 of welke pagina ook. Iedereen weet dat teletekst een beperkt aantal pagina’s heeft. Van 100 tot 899. Een druk op de afstandsbediening laat een hoger paginanummer zien. In mijn voorbeeld kan het dus makkelijk gebeuren dat iemand op pagina 129 komt het het bericht ziet. Dat was niet de bedoeling, er is nergens naar verwezen, en toch staat het daar. Ik kan me niet voorstellen dat een rechter daar een strafbaar feit in zal zien.

  18. Mijn twee centjes… Het aanpassen van een URL kun je ook doen om er alvast een bookmark voor aan te maken, omdat je verwacht dat er over een paar dagen ook daadwerkelijk enige content te vinden is. (In dit geval een kerstrede.) Zo zou ik http://blog.iusmentis.com/2013/01/01/ alvast kunnen invoeren om je eerste post van het volgende jaar te kunnen lezen. (Jammer genoeg werkt dat hier niet want ik moet ook de titel weten, maar laten we dat voor deze discussie even vergeten.) Hoe dan ook, door een patroon in je URL weet ik waar ik de volgende posts kan verwachten en als er eentje is die mij belangrijk lijkt dan kan ik daar vast een bookmark voor aanmaken.

    Maar wat als ik zodoende ontdek dat jij die post van volgend jaar nu al klaar hebt staan op die URL? Dan zou ik die post nu al kunnen lezen omdat jij hem eigenlijk al hebt vrijgegeven. Jij maakt openbaar via een patroon, wat betekent dat anderen kunnen inspelen op dat patroon. Je hebt het patroon openbaar gemaakt, en daarmee dus ook al je toekomstige posts. En een patroon volgen is iets heel anders dan b.v. “OR 1=1” toevoegen aan de URL.

    Toch vind ik dat er een gedegen onderzoek moet plaatsvinden. Maar niet naar de hacker, want die volgde alleen een openbaar patroon. Er moet onderzocht worden welke “Idioot” de kerstrede al op die server toegankelijk heeft gemaakt zodat deze nog voor het nieuwe jaar begint al op zoek kan naar een nieuwe werkgever. De ICT-afdeling van de Staat is al behoorlijk waardeloos op sommige punten en dit is gewoon een extreme vorm van nalatigheid.

    1. Wie zegt dat het nalatigheid is? Misschien is het wel met opzet gedaan, gewoon om te kijken wat er gebeurt. Waarschijnlijk hebben er nu meer mensen de kersttoespraak gezien dan in al die jaren ervoor. We leven nu eenmaal in een tijdperk waarin mensen zelf willen bepalen wanneer ze iets zien. Dat er bijna 800.000 mensen toch nog voor de buis hebben gezeten om de toespraak ‘live’ te zien, moet je eigenlijk interpreteren als 15 miljoen mensen die niet voor de buis hebben gezeten. Televisie is niet langer het leidend medium en het zal mij dan ook niets verbazen als de kersttoespraak volgend jaar gewoon op kerstavond al op YouTube staat.

      1. Tja, nalatigheid of niet, uit de reacties te merken van de RVD was dit niet de bedoeling.

        Maar de discussie gaat vooral of het een openbaarmaking is of niet en ik vind het een normale openbaarmaking. Want ondanks dat er geen directe link was geplaatst werd wel gebruik gemaakt van een openbaar gemaakt patroon. Door het patroon te volgen kun je vervolgens door een verzameling artikelen heen lopen. De WordPress-software die Arnoud gebruikt voegt een extra laag toe in de vorm van de titel van de post, waardoor je minder makkelijk door de posts heen loopt door alleen de URL aan te passen. Je moet dan gebruik maken van de navigatie-functies. (Maar ik ontdek net dat de WordPress software ook zonder titel de URL accepteert en je b.v. met http://blog.iusmentis.com/2012/12/20/ bij een vorige post komt.)

        Wie enige kennis heeft van de routing-technieken die webservers gebruiken om pagina’s op te halen, die weet ook dat de URL gewoon enkele parameters bevat die je gewoon kunt aanpassen om rechtstreeks een bepaalde pagina op te vragen. Dit blog heeft uiteindelijk vier parameters die ook nog eens allemaal optioneel kunnen zijn. Met http://blog.iusmentis.com/2010/ krijg je alle posts te zien van Arnoud in 2010. Gebruik je http://blog.iusmentis.com/2011/12/ dan zie je alle posts van december 2011. Nu geeft Arnoud geen handleiding mee met zijn site betreffende hoe je posts uit een bepaald jaar of maand zo kunt opvragen maar even uitproberen en je komt er snel achter. En omdat heel veel sites dergelijke technieken gebruiken is het maar de vraag of ik zojuist deze site heb “gehacked” of dat ik gewoon een algemeen bekend en openbaar patroon heb gevolgd.

        Oh, ik heb het overigens eerst op mijn eigen WordPress blog geprobeerd. 🙂 En omdat ik dus weet dat WordPress gewoon zo werkt kan het ook geen hacking genoemd worden. Dan had Arnoud maar geen WordPress moeten gebruiken. 😉

  19. Zou een rechter bij het bepalen of een document publiek is niet simpelweg naar het individuele geval kijken, en overwegen of naar alle redelijkheid de ‘hacker’ zou hebben moeten weten dat het document niet als publiek bedoeld was?

    1. Dat lijkt me absurd, het wel of niet publiek zijn van documenten heeft niets te maken met computervredebreuk en bovendien zou het verbieden van het bekend maken van niet-publieke documenten veel journalisten in de bak doen belanden: Het recht om gelekte informatie te publiceren is fundamenteel onderdeel van de persvrijheid.

      1. Mijn opmerking haakt aan op de discussie hierboven over of het raden van een link computervredebreuk is: Het idee is dat je verkeerd bezig bent als je jezelf toegang weet te verschaffen tot een document wat duidelijk niet publiek hoort te zijn. De reden waarom ik denk dat een rechter er wel eens op deze manier naar zou kijken, is het feit dat het doorbreken van een beveiliging geen vereiste is van computervredebreuk.

        (Het publiceren van gelekte informatie is een heel ander verhaal, dat niet ter zake doet voor de discussie over computervredebreuk.)

        1. Dat is het verschuiven van de verantwoordelijkheid. Het is aan de eigenaar/beheerder om te bepalen wie toegang heeft tot bepaalde documenten. En leg mij maar eens uit hoe je op basis van de naam ‘KH-251212-4003_hd.mp4’ kunt vaststellen dat het om de ‘verboden’ kersttoespraak gaat. Daarvoor zul je het filmpje eerst moeten bekijken, maar dan ben je volgens jouw redenatie al strafbaar.

          1. Je draait het om. De test die ik noemde is dat er pas sprake zou zijn van computer vredebruik als het voor de ‘hacker’ redelijkerwijs duidelijk zou moeten zijn dat het document (of de functionaliteit) niet publiek toegankelijk had moeten zijn (en aan de overige voorwaarden voldaan is) dat er dan sprake is van computervredebreuk. De rechter beoordeelt dan of de ‘hacker’ had moeten weten dat het document (of de functionaliteit) niet voor het publiek bedoeld is, op dezelfde manier als de rechter in het OTTO-arest oordeelde dat de koper van een high-end LCD-televisie voor €99,00 had moeten weten dat die prijs een fout was.

  20. Het is al vaker genoemd, maar zou Arnoud misschien beter kunnen beargumenteren hoe het doen van een paginaverzoek aan een webserver onder ‘binnendringen’ kan vallen? Als men niet gerechtigd was om die pagina te zien, dan had die webserver gewoon kunnen weigeren. Er wordt toch slechts een verzoek gedaan?

    1. Bij een menselijke portier heeft dat argument kans van slagen. Bij een automatisch systeem niet. Je wéét dat die gewoon dom oplepelt wat je vraagt. Daaruit kun je geen wensen van de eigenaar afleiden.

      Verder is het niet “slechts” een verzoek, maar een opzettelijk zo geconstrueerd verzoek dat iets opgelepeld wordt waarvan de verzoeker weet dat het nog niet publiek is.

      1. Niet mee eens. De ontdekker geeft zelf aan in zijn blog dat hij in eerste instantie dacht de kersttoespraak van vorig jaar te pakken te hebben, dus zo evident was dat kennelijk niet.

        Verder, maar dat is hierboven ook al gezegd, vind ik het hele verhaal té zot voor woorden. Ze hadden die webserver toch ook gewoon een HTP-404 kunnen laten teruggeven? Het maakt me wel heel nieuwsgierig wat ze dan gedaan hebben met die hele grote portemonnee waarmee ze die website hebben laten verbouwen.

      2. Je wéét dat die gewoon dom oplepelt wat je vraagt. Daaruit kun je geen wensen van de eigenaar afleiden.

        Is dat zo? De eigenaar stelt toch in wat er wel en niet aan verzoeken wordt ingewilligd? Daarnaast: waaruit kan ik dan wél de wensen van de eigenaar afleiden? Ik tik een url in en ik krijg hem. Dan kan ik toch niet weten dat die pagina niet openbaar is?

      3. Ik ben dit met je oneens. De voorraad van grote winkelketens wordt tegenwoordig volledig door computersystemen op peil gehouden. Het zijn computers die de aankoop verzoeken indienen en compuers die deze verzoeken afhandelen. Naar alle redelijkheid moet het gedrag van de computers voor risico komen van de eigenaar komen. Zo bezien mag een bezoeker op een website er vanuit gaan dat de website zich gedraagt zoals de eigenaar wilt.

        1. De wil van de eigenaar mag je alléén afleiden uit wat zijn computer doet wanneer je de officiële interfaces gebruikt. Zodra jij handmatig de URL gaat aanpassen, mag je niet langer vertrouwen dat dit volgens de wil van de eigenaar gaat.

          Paar jaar terug bleek een pizza-site een domme fout te hebben: de prijs van de pizza zat in de POST data als je bestelde. Een slimme student zette de prijs op 1 cent en mocht inderdaad 100 pizza’s ontvangen voor 1 cent elk. Geen rechter die dan zal zeggen “de kennelijke wil van de eigenaar was de pizza voor 1 cent te verkopen”. (En dat zal ie ook zeggen als de prijs een op zich redelijke prijs was trouwens.)

            1. Van de browser ja, niet van mijn site. Het is prima dat jouw browser je zo’n achterdeur geeft, maar je moet niet gek opkijken als er dan iets gebeurt dat ik niet gewild heb. De gevolgen zijn dan voor jou, en je kunt mij niet verwijten dat de achterdeur jou gekke resultaten oplevert.

              Ik zie allemaal mensen nu grappig doen bijvoorbeeld met de ?p URL-aanroep van deze blog. Als ik daar een redirect naar goatse.cx of rickroll.nl van maak, dan is dat écht hun eigen risico en niet een “officieel” document van mij.

              1. Maar de adresbalk van je browser is toch geen achterdeur? Als dat zo was, waarom wordt er dan geadverteerd met watvooreikelbenjij.nl en dergelijke. Is dat een uitnodiging om de achterdeur te gebruiken? Of is alleen de domeinnaam de voordeur en de rest achterdeur?

                Overigens ben ik helemaal geen voorstander van de strafbaarheid van computervredebreuk, ook niet via SQL injectie. Als je schade aanricht (zoals in Richards verhaal), dan is dat een civiele kwestie, waarbij de rechter moet kijken of de eigenaar het redelijkerwijs had kunnen voorkomen (dus geen grote knop op je site met “wis de database” en een redelijke poging tot beveiliging). Een geautomatiseerd systeem die willekeurig gegenereerde URL’s opvraagt kan dus niet strafbaar zijn, maar moet de schade die het aanricht wel vergoeden.

            1. Als ik blog.iusmentis.com invoer in de adresbalk, dan mag ik er niet op vertrouwen dat de webserver doet wat jij wilt? Hoe kan ik me tegen dergelijke claims verweren?

              Bij de homepage wel, maar als jij blog.iusmentis.com/wp-admin/../../../../../../cmd.exe%20format%20c: in gaat typen dan mag je niet veronderstellen dat ik die actie graag wil laten gebeuren. Dat het kan, wil niet zeggen dat ik het wil.

              Even toch weer vergelijking: als jij op het codeslot op mijn deur de juiste code weet te raden, betekent dat dat je erop mag vertrouwen dat je naar binnen mag?

              Als er een sleutel in de klomp naast mijn voordeur ligt, betekent dat dan dat je de deur mag opendoen? En wat als er ook nog eens een deurmat met “Welkom!” bij ligt?

              1. Arnoud,

                Eerder vond je nog dat een bezoeker alleen mocht aannemen dat de machine zich gedoeg zoals de eigenaar bedoelt heeft wanneer er gebruik werdt gemaakt van de officiele interfaces. En de browserbalk noemde je een achterdeur. Nu blijkt dat dit toch ruimer ligt dan je eerder betoogt heb. Sterker nog die browserbalk is onmisbaar.

                Ik ben het met de anderen eens dat ik je vergelijkingen niet vind passen. Ik heb dit ook al eerder aangegeven. Een website eigenaar weet best dat zo’n beetje alle browsers zo’n balk hebben. En hij weet ook dat leken hier gebruik van maken. Hij neemt willens en wetens een risico wanneer hij informatie op publiceert zonder dit wereldkundig te maken. Dit zou ook voor zijn risico moeten komen.

                Daarom vind ik dat aan het bestandsdeel wederredelijk niet voldaan is. IK vind overigens dat er helemaal geen spraken is van binnen dringen, maar dat is een andere discussie, die hier onder gevoerd wordt.

        2. Als de url geen onderdeel is van de interface met de gebruiker, waarom nemen zoveel webbouwers dan de moeite om nuttige informatie zoals titel of datum in de adresbalk te zetten? Als dat allemaal technisch geneuzel is waar de gebruiker niet aan hoort te komen, waarom heeft deze discussie niet de url http://iusmentis.com/12398127389r73265743979832432 ?

          De adresbalk is helemaal niet ‘onder de motorkap’!

          Wat mij betreft is dat de reden dat url-manipulatie niet onder ’technische ingreep’ valt, zoals een SQL-injectie dat wel doet.

        3. Als de url geen onderdeel is van de interface met de gebruiker, waarom nemen zoveel webbouwers dan de moeite om nuttige informatie zoals titel of datum in de adresbalk te zetten? Als dat allemaal technisch geneuzel is waar de gebruiker niet aan hoort te komen, waarom heeft deze discussie geen url met een of ander dom nummer?

          De adresbalk is helemaal niet ‘onder de motorkap’!

          Wat mij betreft is dat de reden dat url-manipulatie niet onder ’technische ingreep’ valt, zoals een SQL-injectie dat wel doet.

            1. Dus als ik de SQL injectie uitvoer door de URL in de adresbalk aan te passen dan is het ineens wél een legale injectie?
              De meeste url’s worden op een of andere manier geconverteerd naar een SQL query, dus ook een ‘gewone’ URL is een vorm van SQL injectie, en URL-manipulatie dus ook.

              Dus zonder beschadiging geen computervredebreuk? Dat gaat er bij mij niet in; als ik met een slimme SQL query jouw database leegtrek dan heb jij geen schade (de site draait vrolijk door) maar dit moet toch wel strafbaar zijn.
              Als je iets beschadigd dan moet je de schade betalen (civiel), mits de andere partij geen nalatigheid aangerekend kan worden. Als je alleen maar de database kopieert dan heb je waarschijnlijk op een andere manier wel schade. Data is geen eigendom, maar de inhoud van een database kan wel auteursrechtelijk beschermd zijn. Een gebruikersdatabase met creditcardgegevens mag je ook natuurlijk niet zomaar gebruiken. Maar de daad van het uitvoeren van een slimme HTTP request mag in mijn ogen niet strafbaar zijn.

  21. Iedereen bedankt voor de nuttige en inhoudelijke reacties. Stof tot nadenken.

    Wat me opvalt is dat veel mensen een wezenlijk verschil zien tussen een ID aanpassen en dingen als SQL injectie of buffer overflows, die je toch ook via de URL doet. Zit hem het verschil dan in hoe moeilijk het is om dit te doen? Een ID aanpassen kan een kind, een buffer overflow exploiteren vereist toch enige expertise (of een gegoogeld script).

    Of gaat het erom dat een ID duidelijk herkenbaar is als een ID, zodat aanpassen daarvan in de lijn der verwachtingen ligt? Zo van, hier zit een grote rode knop, natúúrlijk gaan mensen daarop klikken. Natuurlijk gaan mensen 201112253998 veranderen in 201212254003. En SQL injectie is dan anders omdat dat volstrekt onlogisch is om te doen. Niemand heet “Robert’); DROP TABLE students –” immers.

    1. Voor mij zit het verschil niet in hoe ingewikkeld het is. Waar het om gaat is dat een URL bedoeld is om content op te vragen. Als je ervoor kiest om met behulp van een ID in je URL specifieke content te identificeren zie ik dat niet anders dan dat je dat met namen doet. Op mijn eigen website kan ik direct bij muziek of film streams komen door /music of /movies achter de URL te plakken.

      Als iemand de /music url weet, is het dan illegaal als hij kijkt op /movies (een gok) om te kijken of ik ook filmpjes aan bied? Voor mij is het evident dat het mijn taak is om te zorgen dat dit niet werkt als ik dit niet wil. Het wordt voor mij niet anders als ik muziek aanbied op /?id=1 en film op /?id=2. Er is geen enkele restrictie op de beschikbaarheid van de informatie, je vraagt gewoon lukraak wat op, als er niets is krijg je (bij een fatsoenlijke website) . In alle gevallen hebben we het gewoon over het opvragen van informatie, die je alleen krijgt als deze al publiekelijk beschikbaar is.

      De SQL injectie daarentegen vraagt niet ‘is deze informatie publiek beschikbaar ‘, maar probeert van een fout in de beveiliging gebruik te maken om informatie op te vragen die duidelijk niet beschikbaar is. SQL injecties maken vrijwel altijd gebruik van (al dan niet in beperkte kring of nieuwe) bekende beveiligingsgaten in software om restricties van de site te omzeilen.

      Het verschil is dus dat de RVD niet vertrouwde op een beveiliging, maar vertrouwde op geheimhouding van waar ze de informatie al voor iedereen toegankelijk hadden neergezet. terwijl met SQL injectie gepoogd wordt een beveiligign te omzeilen. Security through obscurity, je zou denken dat zelfs de grootste idioot inmiddels wel weet dat dit niet werkt. Helaas bewijst de overheid weereens dat we toch nog verbaasd kunnen worden.

      (die streams zijn overigens echt en met wachtwoorden beschermd zodat ik ze alleen zelf kan luisteren, had RVD misschien ook moeten doen 😉 ) Edit: Overigens is dit hoe wij in 1993 op de universiteit al muziek deelden via het web in IFF 8SVX formaat. Napster was voor ons niets nieuws 😉

      1. De SQL injectie daarentegen vraagt niet ‘is deze informatie publiek beschikbaar ‘,

        Een SQL injectie met een SELECT doet dat wel. Toegegeven, je passeert de normale interface/omgeving waarin informatie wordt aangeleverd maar met zo’n query wil je niets stukmaken, je wilt alleen maar informatie hebben en je maakt het wat makkelijker voor jezelf door gelijk de SQL te schrijven in plaats van pagina voor pagina op te vragen.

        En qua beveiliging: ten eerste is “beveiliging doorbreken” géén argument bij computervredebreuk, en ten tweede, wat nu als de video geëmbed zat in een pagina die wél wachtwoordbeveiligd was? Ben je dan niet de beveiliging aan het omzeilen door niet de pagina maar de dieplink op te vragen?

        Of stel er zit wél een wachtwoord op de stream maar dat is 12345?

        Maakt het uit of de video in de URL heeft staan id=4003 of id=4003&password=12345?

        1. Een SQL injectie met een SELECT doet dat wel. Toegegeven, je passeert de normale interface/omgeving waarin informatie wordt aangeleverd maar met zo’n query wil je niets stukmaken, je wilt alleen maar informatie hebben en je maakt het wat makkelijker voor jezelf door gelijk de SQL te schrijven in plaats van pagina voor pagina op te vragen
          Een tijdje geleden besloot een of andere knurft om op soortgelijke wijze te proberen mijn informatieve site te rippen (scrapen i.c.m. URL manipulatie). Dat lukte niet op de beoogde wijze maar wat wel lukte was dat diegene mijn database volledig klemzette (andere index i.c.m. andere sortering, samen met erg veel requests). Daardoor bleef een ander script hangen wat ertoe leidde dat een API-partner een flinke storing opliep en vervolgens de samenwerking beeindigde. Schade plusminus 5000 euro.

          Nu kan je roepen ’tja daar moet je website maar tegenkunnen’ maar dan ga ik toch even in de metaforen duiken met de vraag of mijn voordeurruit tegen een stoeptegel moet kunnen. Of moet je geen stoeptegels tegen mijn voorruit gooien?

          Door een goede reactie op abuse@ kwam ik in contact met de betreffende knurft, en die riep ook ‘ik wilde niks stukmaken’. Overigens heeft het wat discussie gekost maar heeft zijn werkgever uiteindelijk de schade deels vergoed.

    2. Ik sluit me aan bij Elroy, daar nog even aan toevoegend:

      1. Je hebt van de RVD toestemming om de toonvideo.php te gebruiken, dat “systeem” kun je per definitie niet zonder toestemming binnendringen. Toestemming gebeurt door aanbieden op webserver en het uitnodigen van mensen video’s op te vragen. Daarmee geeft de RVD je niet ook automatisch toestemming om hun database, het systeem daarachter, te gebruiken. Een “Robert’); DROP TABLE students –” is inderdaad een evident geen poging de toonvideo.php te gebruiken, maar een poging commando’s te sturen aan het systeem daarachter, waarvoor geen toestemming bestaat.

      2. Om die database te gebruiken, moet je een bug vinden. Voor dat de die persoon met naam “Robert’); DROP TABLE students –” kunt opvragen, moet je al behoorlijk wat kennis van het te kraken systeem hebben vergaard. Een getalletje aanpassen een technische ingreep noemen (hoe technisch moet je daarvoor precies zijn?), is een stuk dubieuzer dan alle handelingen die leiden tot “Robert’); DROP TABLE students –” een technische ingreep noemen. Die combinatie van handelingen vereisen wel degelijk technische kennis, op het moment dat je die drop table uitvoert wordt het een ingreep.

    3. Arnoud schreef: > Wat me opvalt is dat veel mensen een wezenlijk verschil zien tussen een ID aanpassen en dingen als SQL injectie > of buffer overflows, die je toch ook via de URL doet.

      Alle communicatie richting webservers verloopt uiteindelijk via URL’s (en post opdrachten). Ook die naar jouw bank, webmail, DigiD, de belastingdienst en jouw EPD.

      Afhankelijk van de waarde (niet alleen financieel) van de gegevens hoort daar, mijns inziens, een proportionele beveiliging bij. Aangezien die kersttoespraak een dusdanige waarde lijkt te hebben dat het voortijdig inzien ervan tot een strafbaarstelling lijkt te kunnen leiden, was de beveiliging ervan m.i. onvoldoende. En, er zijn de laatste jaren zover (overheids-) lekken geweest (denk o.a. aan Prinsjesdag), dat de webmaster geacht mag worden hiervan op de hoogte te zijn en dus afdoende maatregelen te nemen (dit was bijna uitlokken).

      Het risico is dat de rechterlijke macht jouw “stelling” (uitleg van de wet) doortrekt en je straks http://mijn.epd.nl/nnn (waarbij nnn jouw BSN is) kunt bezoeken om jouw eigen dossier in te zien. Immers, het benaderen van het EPD met een ander dan jouw eigen BSN nummer is strafbaar – van die EPD club kan dan redelijkerwijs niet te worden verwacht dat zij de zaak beter beveiligen!

      M.a.w., schep alsjeblieft geen precedent. Het niet redelijkerwijs beveiligen van via internet bereikbare informatie zou strafbaar moeten zijn. Ga dit soort blunders alsjeblieft niet “repareren” door een kennelijk ondoordachte wet op een voor de “benadeelde” gunstige wijze uit te leggen…

      Arnoud schreef: > Zit hem het verschil dan in hoe moeilijk het is om dit te doen?

      Niet alleen hoe moeilijk, maar ook het risico dat je bewust neemt dat je iets beschadigt: “../../../../cmd.exe format c: /yes” is een goed voobeeld, maar ook SQL injectie (-pogingen) leiden niet zelden tot defecte sites (onnozele script-kiddies nemen dit risico wellicht niet bewust, maar dat maakt de schade er niet minder om – en kan worden vergeleken met kattenkwaad).

      1. Hm. Ik snap je argument, maar ’t doet me denken aan “we hebben bij de bank geen kluis nodig want diefstal is strafbaar”. Daar komen ze echt niet mee weg. Ook een EPD dat zó hard niet beveiligt en roept “jamaar strafbaar” zal dus niet ver komen.

        Feit is dat in 2006 de eis van een beveiliging doorbreken uit de wet geschrapt is. Die nu weer terugzetten lijkt me niet heel erg kansrijk. En hem impliciet er weer terug in lezen gaat écht niet lukken.

        Niet alleen hoe moeilijk, maar ook het risico dat je bewust neemt dat je iets beschadigt:

        Dus zonder beschadiging geen computervredebreuk? Dat gaat er bij mij niet in; als ik met een slimme SQL query jouw database leegtrek dan heb jij geen schade (de site draait vrolijk door) maar dit moet toch wel strafbaar zijn.

    4. Dat is inderdaad mijn mening… De URL was herkenbaar als een domeinnaam met een pad en daarin enkele ID’s erin verwerkt. Die ID’s verwijzen naar een specifiek onderdeel, zoals ik al aangaf met de WordPress URL’s. In de meeste gevallen zijn dergelijke ID’s gewoon oplopende nummers of datums en voor de ervaren internet-gebruikers is het volgen van een dergerlijk patroon gewoon standaard. Het is ook iets dat enorm vaak wordt toegepast en wat eigenlijk ook zo bedoeld zou moeten zijn om toegepast te worden omdat gebruikers dan makkelijk een bepaald artikel kunnen bookmarken. Dit soort patronen worden ook regelmatig herkend door zoek-engines en webspiders. Fusker websites maken er vrij veel gebruik van om afbeeldingen uit andere sites op te halen, waarbij gebruikers URL’s kunnen toevoegen aan het systeem waarbij ze aangeven waar de index-velden zitten en welk bereik deze index-velden hebben.

      SQL Injections gaan verder dan alleen een ID aanpassen. Bij SQL Injection probeer je extra code uit te laten voeren op de server. Je laat deze iets doen wat de maker van de site niet had bedoeld. Bij een index wordt geen extra code uitgevoerd. Het systeem controleert alleen maar of een bepaald item wel of niet aanwezig is en zo ja, dan wordt dat item teruggegeven. In het andere geval komt er een foutmelding.

      Vraag is alleen of er ID’s zijn die je niet zou mogen manipuleren. Het Burger-Service Nummer is al genoemd, meen ik. (P.s. BSN nummer is dubbel-op. De N in BSN staat al voor nummer…) Als een site toegang biedt tot gegevens met alleen een BSN, dan zou je kunnen stellen dat je dan niet het BSN van een ander hiervoor mag gebruiken. Maar die site heeft dan wel een enorm beveiligingslek en iedereen die mijn BSN weet zou dan toegang tot deze gegevens hebben en anderen die gewoon alle combinaties uitproberen zouden de site helemaal uit kunnen lezen. Een dergelijke website heeft dan mijn persoonsgegevens onbeschermd op het Internet geplaatst en is dan ernstig nalatig in het beschermen van mijn persoonsgegevens. Nee, een site die een BSN in het pad gebruikt zou niet mogen, tenzij de site extra beveiligingsmaatregelen toepast. Ik denk hierbij aan een REST web service, die ook via patronen in de URL werkt, maar die geen HTML pagina teruggeeft maar een brokje XML die door een client applicatie weer vertaalt kan worden. Dan kun je met een BSN dus gegevens opvragen uit de service die door een client applicatie (Silverlight, Flash, desktop/tablet app) weergegeven wordt. Maar ik hoop dan wel dat hier een extra beveiligingsstap is genomen, zoals b.v. een vereiste authenticatie.

      1. Beste Wim, Een BSN in een pad mag m.i. nooit, zelfs niet met de beste beveiliging. Er is geen enkele reden om het BSN daarvoor op die manier te gebruiken. Ik houd van simpel; de URL is het boek, het nummer de bladzijde. En een lezer is iemand die bladert …

        1. Ben ik het niet helemaal mee eens, zeker niet als het gaat om een REST service, waarbij je eigenlijk XML/JSON data ophaalt in plaats van een HTML pagina. Maar die gebruik je in het algemeen ook in combinatie met een client applicatie. Je kunt je daarbij voorstellen dat een BSN wordt gebruikt als key voor de overige gegevens van een burger, en dan in principe binnen de software van een gemeente. Bij het aanvragen van b.v. een paspoort kunnen ze je BSN opvragen en invoeren in het systeem. Dat nummer gaat vervolgens als parameter binnen een URL naar een REST service, inclusief extra beveiligings-methodes, en vervolgens komt er een response terug die aangeeft of de aanvrager al een paspoort heeft of dat er redenen zijn om een paspoort te weigeren.

          Communicatie tussen burger en overheid mag alleen via een BSN gaan. Dit BSN is daarom zelfs een verplicht onderdeel van software die binnen de overheid wordt ontwikkeld ten behoeve van de administratie van hun burgers. Dit betekent ook dat bij client/server toepassingen het BSN over het Internet verstuurd wordt richting de overheid. Zo ook b.v. voor werkgevers die van hun werknemers een BSN nodig hebben om deze door te geven aan de overheid ten behoeve van de belastingen en het innen van bepaalde premies.

          Hoe uiteindelijk de implementatie gebeurt hangt van de overheid en de diverse gemeentes af. Iedere gemeente kan namelijk naast de normale software ook speciaal maatwerk laten ontwikkelen voor de communicatie met de burgers waarbij er de mogelijkheid ontstaat dat het BSN een onderdeel wordt van de URL. Die beslissing ligt uiteindelijk bij de makers van de betreffende software.

          Maar inderdaad, correct: een BSN mag alleen voor overheids-doeleinden gebruikt worden. Er zijn nog teveel bedrijven die een BSN eigenlijk misbruiken, net zoals er iets teveel bedrijven zijn die vragen om een kopie van een paspoort voor b.v. het afsluiten van een abonnement.

  22. Nog ff een nabrander. Als dit al strafbaar is, is dit dan niet gewoon uitlokking? Als ik een laptop in mijn auto laat liggen en ik doe mijn auto vervolgens niet op slot kan IK een bon van de politie verwachten, ook al is degene die die auto opentrekt ook schuldig aan auto-inbraak. Lijkt me leuk om als je vervolgd wordt de RVD ook voor het hekje te dagen.

    1. Als jij je auto openlaat, zal de dief schuldig zijn aan diefstal, maar zeker niet aan braak. Maakt voor de dief weinig verschil, mara je verzekeraar zal zeker over beginnen!

      Ik ben het overigens niet met je eens dat het uitlokking is. Het is gewoon onbedoelde openbaarmaking door de RVD. Dom, maar hun fout, niet van degene die de link vond.

  23. Ik mis de volgende zaken in de discussie die volgens mij wel zeer relevant zijn.

    1. Websites van de overheid moeten voldoen aan de open standaard Webrichtlijnen die zorgt voor goede toegankelijkheid van online informatie. Zie : http://www.koninklijkhuis.nl/toegankelijkheid/toegankelijkheid/

    2. Eén van de eisen van de Webrichtlijnen is “R-pd.4.6 Gebruik vriendelijke URL’s, die leesbaar en herkenbaar zijn.” In de uitleg staat o.a.:

      “Vriendelijke URL’s dragen bij aan de gebruiksvriendelijkheid van websites. Ze zijn gemakkelijk te onthouden en in te typen, en de bezoeker kan op basis van de URL beredeneren hoe de informatiestructuur van de website is opgebouwd.”
      “URLs that are ‘hackable’ to allow users to move to higher levels of information architecture by hacking off the end of the URL”.
      Voor de gehele uitleg zie: http://www.webrichtlijnen.nl/richtlijnen/webrichtlijnen-1/r-pd-4-6

    3. Als ik het goed zie, gaat het in casu om een (redelijk) vriendelijke URL, die inderdaad leesbaar en herkenbaar is. Iedere gepubliceerde video krijgt namelijk een datum en volgnummer mee. De URL van de kerstoespraak 2011 is http://server.rijksoverheidsvideo.nl/high/KH-251211-2960hd.mp4. Die van 2012 is http://server.rijksoverheidsvideo.nl/high/KH-251212-4003hd.mp4

    Overige bronnen: http://mndell.posterous.com/waarom-de-kersttoespraak-url-publiek-was-en-i

      1. Beoogd gebruik, inderdaad. Toch is er een deel twijfelachtig. Okay, de datum is herkenbaar en duidelijk te manipuleren, maar hoe vind je nou het juiste volgnummer dat ook onderdeel is van de URL? Want tussen 2960 en 4003 zit een groot verschil. Heeft de “hacker” dit gewoon gegokt door alle mogelijke nummers te proberen of wist hij het volgnummers wegens een vorige URL die het voorgaande nummer bevatte? Ofwel, hoe was dat volgnummer bepaald?

  24. Hele vreemde discussie is dit. Zoiets als url-manipulatie om te kijken wat er aan informatie te vinden is, is gemeengoed en geen black hat hackerstechniek. Iedere leek kan het en iedereen doet het. Meestal valt dit niet onder ongewenst gebruik, laat staan onder computervredebreuk. ‘Beoogd gebruik’ misschien ook niet, maar er wordt doorgaans rekening mee gehouden. Normaal gesproken is er niks aan de hand met getalletjes veranderen in de url. Hoe kan iemand dan weten dat er dit keer een probleem is?

    Hier zit volgens mij het probleem: url-manipulatie is normaal en bepaald niet ingewikkeld. Voor een webbouwer is url-manipulatie door gewone gebruikers een gegeven. Url-manipulatie is een technische ingreep van niks!

    1. Fijn dat je de hele discussie op deze manier even platslaat, maar zou je een inhoudelijke onderbouwing kunnen geven over waaróm er geen binnendringen is en wat dan het “wezenlijke” verschil is?

      Je Facebook-link vereist een account aldaar, en niet iedere lezer hier heeft dat. Misschien kun je relevante passages citeren.

      1. Excuus. De “public” instelling laat te wensen over, merk ik. 😉 Ik heb zelf geen blog o.i.d. dus had geen andere plek om het te plaatsen. Hier inderdaad de kern van mijn betoog:

        “Ten eerste moet men zich afvragen of er uberhaupt sprake is van “binnendringen”. Arnoud’s vergelijking met een tuin geeft te kennen dat hij vindt dat er toch op een zeker moment een voet is gezet binnen de grenzen van het systeem. Dat is echter technisch onjuist. Het videobestand is immers gedownload in een browser, door middel van het versturen van een URL verzoek. De bewuste communicatiestandaard is dan het HTTP-protocol (http://nl.wikipedia.org/wiki/HypertextTransferProtocol). Het HTTP-protocol is te vergelijken met een telefonische klantenservice. Je belt, geeft een vraag door, en aan de andere kant van de lijn komt er (na verloop van tijd) een antwoord. De kracht van een dergelijk systeem is juist dat je het bedrijf niet hoeft ‘binnen te dringen’ om toch een communicatiekanaal op te zetten. Beide partijen bevinden zich van begin tot eind op afstand van elkaar en treden niet elkaars systeem of domein binnen. De communicatie is toch mogelijk omdat er een neutrale tussenlaag (in het voorbeeld, de telefoonverbinding) bestaat. Communicatie over HTTP van welke aard dan ook is daarom per definitie geen vorm van ‘binnendringen’. Er is niemand op het systeem ingelogd en er heeft geen invloed of verandering plaatsgevonden in de werking of instelling van dat systeem. Het systeem heeft simpelweg gewerkt zoals het is ingesteld. Om die reden zijn de vergelijking van de tuin zonder hek en alle voorbeelden met huizen met open ramen en deuren, onjuist. Er wordt geen tuin of huis betreden. Het voorbeeld van de winkel in mijn vorige post is wel een correcte weerspiegeling van dit feit.

        Er is ook wat te zeggen over de vergelijking met SQL-injectie. Zoals ik eerder stelde is dit eigenlijk het sterkste argument om te betogen dat het strafbaar is. In mijn ogen is dat argument echter niet sterk genoeg om in de expertise overtuigend te zijn. Hoewel URL manipulatie in simpele vorm sterk vergelijkbaar is met SQL-injectie, is er een wezenlijk verschil. Dat verschil ligt in het feit dat de manipulator zich bij SQL injectie bewust is en misbruik maakt van de interne werking van het systeem. Hij bezit de kennis dat parameters in URL’s soms ongefilterd in een SQL query belanden en zodoende met wat kunst en vliegwerk de vorm gegeven kunnen worden waarop deze in de SQL module of server uitgevoerd worden alsof het losstaande queries zijn. Dat is een enorm beveiligingslek omdat men dan op afstand SQL queries kan laten uitvoeren op het systeem zelf. Databases en hun vraagtalen zijn processen die zich in tegenstelling tot de URL manipulatie zelf, volledig binnen het systeem afspelen. Iemand die SQL injection gebruikt, beïnvloedt daarmee op afstand de werking van het systeem op een wijze die zich volledig binnen de grenzen van dat systeem afspeelt. Zijn intenties zijn daarbij duidelijk, omdat hij op een niet voor de hand liggende manier een URL bewerkt zodat ingespeeld wordt op een bekende gevoeligheid. Een soort van voorbedachte rade. Echter, het veranderen van een paar cijfers in een URL, bijvoorbeeld op basis van patroonherkenning, kan nog steeds geschieden als het systeem (de server) voor de manipulator volledig een black box is. Dat wil zeggen dat de aard en hoedanigheid van interne processen voor de manipulator geheel onbekend is. Daardoor is geen bewijs mogelijk van het feit dat de manipulator bewust invloed wilde uitoefenen op die interne processen. Het patroon zat in de URL zelf en niet in het gegeven dat een complexe samenstelling van een URL kan leiden tot een interne injectie van gegevens. Daar zit in mijn ogen het verschil tussen eenvoudige URL manipulatie en SQL injectie. Het eerste is niet strafbaar, het laatste wel.

        Sterker nog, je browser manipuleert intern URL’s om bijvoorbeeld favicons (de icoontjes links van de pagina titel in de tab of schermbalk van je browser) te downloaden. De browser neemt daarbij het domeingedeelte van de URL en plakt daar, zonder vooraf te weten of het bestand bestaat of niet en of er sprake is van bedoelde geautoriseerde toegang, de tekst ‘favicon.ico’ achter. Het resultaat is óf het icoontje zelf of een standaardicoontje als er om wat voor reden dan ook geen bestand wordt teruggegeven door de server. Zoekmachine crawlers manipuleren in hun eeuwige zoektocht van indexeerbare websites en -pagina’s aan de hand van patroonherkenning op basis van regular expressions ook URL’s om hun crawlmethodes sneller en efficienter te maken.”

        1. Zoekmachine crawlers manipuleren in hun eeuwige zoektocht van indexeerbare websites en -pagina’s aan de hand van patroonherkenning op basis van regular expressions ook URL’s om hun crawlmethodes sneller en efficienter te maken
          Kan je hier een bron van geven? Ik heb dit met mijn 18 jaar web-ervaring nog nooit gezien.
          Communicatie over HTTP van welke aard dan ook is daarom per definitie geen vorm van ‘binnendringen’. Er is niemand op het systeem ingelogd en er heeft geen invloed of verandering plaatsgevonden in de werking of instelling van dat systeem
          Ik snap best dat dit gevoelsmatig zo is. Maar “inloggen” op een systeem is toch ook niets anders als over het SSH, telnet, RDP of noem-maar-op protocol een server benaderen. Maakt het echt uit dat daar dan een shell achterhangt en of die login en/of GINA opstart? Ik ben op zoek naar een harde grens, en die zie ik niet. In beide gevallen is er een protocol en opereer je daarbinnen en jij kiest nu toevallig het HTTP protocol als beoordelingsvlak. Maar ook een URL met een SQL-injectie erin is een valide HTTP-URL. Iets analoogs geldt voor geavanceerdere aanvallen op de webserver zelf, zoals HTTP response splitting. Daar stuur je wellicht invalide HTTP requests, maar het is wel een geldige TCP-IP verbinding. Het enige verschil tussen dit soort aanvallen is de OSI-laag waarop de aanval plaats vindt.

          Het tweede deel van je zin insinueert dat er sprake moet zijn van iets wat gewijzigd is na het ‘binnendringen’. Dat vind ik vreemd. We zijn het er allemaal over eens dat een inbreker die niets wegneemt, toch een inbreker is?

          Het is echt heel simpel. Bij simpele URL manipulatie hoef ik de werking van een webserver niet te kennen. Ik kan gewoon met trial-and-error uitproberen wat de respons is. Bij SQL injectie beroep ik me op de kennis dat er in het systeem een proces gaande is wat ik met een specifieke manipulatie kan beïnvloeden. Het ene is een black box, het andere vereist kennis over de werking van die box. Het ene kan een gemiddelde basisschoolleerling, het andere vereist toch een flinke dosis computer ervaring. Maar de nadruk ligt op het feit dat de manipulator zijn handeling heeft gefundeerd op kennis van het reilen en zeilen binnen een server. Eenvoudige URL manipulatie is een gang van zaken waarbij de denkstappen helemaal buiten het systeem te formuleren zijn.
          Dat is een beetje flauw. Omdat databases nou toevallig met een autoincrement ID werken en optellen makkelijker is dan SQL statements maken, baseer jij de ene handeling op kennis en de andere niet. Ik stel dat snappen dat zo’n nummertje in de URL een document identificeert, de kennis van het bestaan van incrementerende ID’s en de vaardigheid om op te kunnen tellen, óók kennis is. Wellicht trivialere kennis, maar toch. Mijn bejaarde vader zou dit niet snappen. Hoe hoger de OSI-laag die je aanvalt, hoe dichter bij de mens het ligt, en hoe meer mensen het snappen. Maar ook hier ontbreekt weer die harde grens.

          Ik zou er de voorkeur aan geven om de definitie ‘het is hacken wanneer de exploitant van de website de handeling niet heeft bedoeld’ te hanteren boven de definitie ‘het is hacken wanneer het best lastig was’. En ja, dan is een ID ophogen dus ook hacken.

  25. Dank voor het reposten.

    Arnoud’s vergelijking met een tuin geeft te kennen dat hij vindt dat er toch op een zeker moment een voet is gezet binnen de grenzen van het systeem. Dat is echter technisch onjuist.

    Inderdaad, je opereert niet binnen het systeem zelf – er is geen prompt of zo waar je interactief commando’s uitvoert. Echter, dat is geen beletsel om van “binnendringen” te kunnen spreken. Ook bij SQL injectie opereer je niet in het systeem, je geeft een URL en/of post-data en je krijgt data terug. Dat is volgens diverse vonnissen toch echt binnendringen.

    Gerechtshof ‘s-Gravenhage 3 februari 2012, LJN BV3397:

    dat door middel van een SQL-injectie toegang kan worden verkregen tot informatie op een server, welke toegang zonder die SQL-injectie niet mogelijk zou zijn. Met andere woorden: het gaat om gebruikmaking van een ‘achteringang’ tot de informatie op de serveren daarmee naar ‘s hofs oordeel derhalve tot die server zelf.

    Als een SQL injectie de ‘achteringang’ is, dan is een simpele URL manipulatie dat ook. Vervang “sql injectie” in deze passage door “aanpassing van het ID-nummer” en dan zegt het Hof dat URL’s aanpassen strafbaar is. En waarom zou die vervanging niet kunnen?

    Dat verschil ligt in het feit dat de manipulator zich bij SQL injectie bewust is en misbruik maakt van de interne werking van het systeem. Hij bezit de kennis dat parameters in URL’s soms ongefilterd in een SQL query belanden en zodoende met wat kunst en vliegwerk de vorm gegeven kunnen worden waarop deze in de SQL module of server uitgevoerd worden alsof het losstaande queries zijn. Dat is een enorm beveiligingslek omdat men dan op afstand SQL queries kan laten uitvoeren op het systeem zelf.

    Of je een beveiligingslek misbruikt of niet, is niet meer relevant sinds 2006. Toen is immers de eis “een beveiliging doorbreken” UIT de wet gehaald. Het is dus sindsdien ook mogelijk om zónder een beveiliging te doorbreken tot computervredebreuk te komen. Je argument kán dus niet slagen want het veronderstelt een relevant onderscheid tussen wel of geen lek misbruiken.

    Ik ben het ermee eens dat een beetje injectie moeilijker is dan een ID ophogen. Ik weet dan alleen niet waar de grens ligt. Als ik in een formulier “%” invul en ik krijg alle data terug (immers SQL ziet dat als wildcard), is dat dan een injectie? Hoe moeilijk moet het zijn?

    Als ik in de URL zie “&content=../pagina1.html” en ik maak daarvan “&content=../../../etc/passwd”, heb ik dan gewoon een URL aangepast of vind je dit al manipulatie?

    Echter, het veranderen van een paar cijfers in een URL, bijvoorbeeld op basis van patroonherkenning, kan nog steeds geschieden als het systeem (de server) voor de manipulator volledig een black box is.

    Een SQL injectie is in principe ook gericht op een black box. Het is veel trial en error en maar hopen dat ze de gebruikelijke patronen volgen op de server. Je kent zelden de tabelstructuur in de database.

    Daardoor is geen bewijs mogelijk van het feit dat de manipulator bewust invloed wilde uitoefenen op die interne processen.

    Het bewijsbaar zijn van een situatie is geen argument om te bepalen of het strafbaar is. Het bewijs zou in concreet de kersttoespraakzaak kunnen volgen uit de uitingen van de dader, hij heeft immers op tv gezegd wat hij van plan was.

    En ook objectief gezien: wat dácht je dat er zou gebeuren toen je van toespraak2011.mp4 toespraak2012.mp4 ging maken? Ik kan dat toch moeilijk een black box noemen. Gezien die URL structuur wil je dan de toespraak uit 2012, dat krijg ik zelfs een alfa-rechtbank wel uitgelegd.

    Zoekmachine crawlers manipuleren in hun eeuwige zoektocht van indexeerbare websites en -pagina’s aan de hand van patroonherkenning op basis van regular expressions ook URL’s om hun crawlmethodes sneller en efficienter te maken.

    Gatver. Echt? Als ik dat zou zien gebeuren dan gaan ze heel regulier expressief naar een eeuwig redirectend scriptje of zo. Een normale robot volgt links, meer niet.

    En ja, voor favicon.ico wordt de URL aangepast maar dat is een bekende en gedocumenteerde feature gericht op iets dat er óf niet is óf bedoeld is voor die feature. Ik vind dat heel wat anders dan “laat ik eens 2011 in 2012 veranderen” of “laat ik eens 3998 in 4003 veranderen”.

    1. Ook bij SQL injectie opereer je niet in het systeem, je geeft een URL en/of post-data en je krijgt data terug. Dat is volgens diverse vonnissen toch echt binnendringen.
      Niet helemaal juist, natuurlijk. Bij SQL injection geef je namelijk een stukje extra code mee om uit te laten voeren op de server. Daardoor krijg je een resultaat dat niet de bedoeling is van de makers/beheerders van de website.

      Bij URL manipulatie, waarbij je een ID aanpast is hier geen sprake van. De URL zelf is misschien nog niet vrijgegeven maar het patroon waarmee je pagina’s kunt ophalen is al snel duidelijk en dus toe te passen om door de diverse pagina’s heen te bladeren zonder de noodzaak van een index. Omdat dit een vrij populaire toepassing is kunnen bezoekers dus al eenvoudig gebruik maken van dergelijke URL parameters om zelf op zoek te gaan naar iets dat hen interessant lijkt. Er zijn duizenden websites waar URL manipulatie gewoon standaard is, met Google als de meest eenvoudige voorbeeld. (Plaats achter google.com een vraagteken en daarna een reeks woorden en poef! zoekopdracht.) Maar ook diverse blogs maken veelvuldig gebruik van URL manipulatie, waaronder je eigen website! Als ik al jouw artikelen uit maart 2007 wil zien dan kan ik dat met een eenvoudige URL manipulatie simpel doen. Daar is de software namelijk ook voor ontwikkeld. Daarom zijn de routing technieken tegenwoordig ook zo populair. Wie met .NET werkt kan namelijk heel eenvoudig zelf parameters in URL’s definieren die gebruikers dan kunnen aanvullen met hun eigen waardes.

      Juist omdat veel websites gebruik maken van dergelijke patronen in de URL is het maar de vraag of je nou wel of niet deze ID’s mag manipuleren. Er zijn genoeg websites die dat helemaal geen probleem vinden. Die zijn dan ook erop gebouwd om pas een artikel openbaar te maken zodra de maker ervan dit ook als dusdanig aangeeft. Zo ook met WordPress, waar je als auteur al tientallen posts van tevoren kunt uitwerken zonder deze te publiceren zodat je uiteindelijk zelf bepaalt wanneer je de post ook daadwerkelijk publiceert.

      Maar goed, als jij vindt dat URL manipulatie niet zou mogen, waarom gebruikt je blog dan software die dergelijk gebruik via PermaLinks expliciet toestaat? 🙂

      1. Bij URL manipulatie, waarbij je een ID aanpast is hier geen sprake van. De URL zelf is misschien nog niet vrijgegeven maar het patroon waarmee je pagina’s kunt ophalen is al snel duidelijk
        Ook hier weer: omdat het ‘al snel duidelijk is’ maakt het nog niet okee.

        1. Ook hier weer: omdat het ‘al snel duidelijk is’ maakt het nog niet okee.
          Probleem is alleen dat bij veel websites de beheerder het geen probleem vindt dat via URL manipulatie door de website wordt gebladerd. WordPress blogs zijn hierbij het meest duidelijke voorbeeld en Arnoud heeft hier gewoon een website staan waar URL manipulatie gewoon geaccepteerd wordt door de software. (Zoals ik al eerder aangaf.) Mijn idee is dan ook dat URL manipulatie gewoon toegestaan is, simpelweg omdat het voor velen handige functionaliteit is. En omdat veel web designers hier ook juist functionaliteit inbouwen!

    2. En ook objectief gezien: wat dácht je dat er zou gebeuren toen je van toespraak2011.mp4 toespraak2012.mp4 ging maken? Ik kan dat toch moeilijk een black box noemen. Gezien die URL structuur wil je dan de toespraak uit 2012, dat krijg ik zelfs een alfa-rechtbank wel uitgelegd.

      We kunnen deze hele discussie dus overslaan want om het bestand zoals boven omschreven te kunnen lezen als bezoeker moet de beheerder het met leesrechten voor iedereen op de server hebben gezet. Als je op een openbare server een bestand zet dat voor iedereen toegankelijk is, dan is niets logischer dan aan te nemen dat publicatie bedoeld was. Hoe kan je dan beschuldigd worden van binnendringen?

      Het is op het web dan ook onzinnig om een eis van omzeilen van beveiliging te stellen, die is er impliciet namelijk altijd al. Alles wat je zonder beveiliging op het web set is per definitie openbaar gemaakt, het is immers beschikbaar voor iedereen die er naar vraagt. Oneigenlijk opvragen van onbeveiligde gegevens is dus niet mogelijk en de wet hoeft hierin niet te voorzien.

      1. Even afgezien wat de wet zegt: zo zou ik het graag willen zien. Webbouwers moeten hun data maar fatsoenlijk afschermen. Er is geen manier voor de gebruiker om te weten dat hij niet gerechtigd was om iets te zien, als hij geen 403 (of liever 404) krijgt.

        1. 401 is de manier om aan te geven dat iets niet beschikbaar voor het publiek op het internet. Je geeft dan aan dat je er met een wachtwoord wel bij kan. 403 is als het uberhaupt niet beschikbaar is, ook niet met autorisatie. Dat lijkt nutteloos, maar is het niet: 403 kan je gebruiken als mensen proberen directories ipv bestanden te benaderen op je webserver. 404 is de melding voor als iets uberhaupt niet bestaat. Dat is al jaren zo, als die error niet terugkomt, maar een webpagina dan is het publiek beschikbare info.

          Degene die nu dus beschuldigd wordt van computer vrede breuk zou dit in een zaak mee moeten nemen. Als een rechter dit vervolgens niet mee neemt in zijn overwegingen, sorry , maar dan heeft hij dus niet voldoende kennis van zaken of is hij stront eigenwijs. Het internet heeft namelijk al jaren deze standaard om toegang duidelijk te maken en dit kan je naadloos aansluiten op de wet: Wanneer computervredebreuk? Als je toegang probeert te krijgen na een error 401, als je ‘hackt’ om wachtwoordbeveiligingen te omzeilen. Of als je probeert (SQL) code uit te voeren die niet bedoeld is om door een gebruiker te worden uitgevoerd.

          Een voor mij essentieel verschil tussen een ID veranderen en SQL injectie: Bij een ID verhoging wordt een voor de gebruiker beschikbaar gestelde query uitgevoerd. Bij SQL injectie creëer je je eigen query. Lijkt mij wezenlijk voor de uitspraak en een reden om de uitspraak over SQL injectie niet ‘zomaar’ toe te passen op ID aanpassen.

          Geen van bovenstaande was aan de hand bij de kersttoespraak.

          1. Sorry, ik had mijn codes mixed up. Volgens mij is het staande praktijk om 404 te gebruiken voor alles wat niet gezien mag worden: je wil een slechterik niet laten weten wat er wel en niet bestaat.

            Voorts helemaal eens met je verhaal.

  26. “Echter, dat is geen beletsel om van “binnendringen” te kunnen spreken. “

    Het is in technische zin geen binnendringen. Het HTTP protocol is ontworpen zodat, zonder binnen te dringen in de server, informatie over een neutraal communicatiekanaal kan verstuurd worden, zodat het de basis kan vormen voor een publiekelijk toegankelijk internet zonder dat de servers zelf blootgelegd worden. Als dat in de wet anders wordt gesteld dan zij dat zo, maar dat is dan niet in lijn met de technische werkelijkheid.

    “Ik ben het ermee eens dat een beetje injectie moeilijker is dan een ID ophogen. Ik weet dan alleen niet waar de grens ligt. Als ik in een formulier “%” invul en ik krijg alle data terug (immers SQL ziet dat als wildcard), is dat dan een injectie? Hoe moeilijk moet het zijn?”

    Het is echt heel simpel. Bij simpele URL manipulatie hoef ik de werking van een webserver niet te kennen. Ik kan gewoon met trial-and-error uitproberen wat de respons is. Bij SQL injectie beroep ik me op de kennis dat er in het systeem een proces gaande is wat ik met een specifieke manipulatie kan beïnvloeden. Het ene is een black box, het andere vereist kennis over de werking van die box. Het ene kan een gemiddelde basisschoolleerling, het andere vereist toch een flinke dosis computer ervaring. Maar de nadruk ligt op het feit dat de manipulator zijn handeling heeft gefundeerd op kennis van het reilen en zeilen binnen een server. Eenvoudige URL manipulatie is een gang van zaken waarbij de denkstappen helemaal buiten het systeem te formuleren zijn.

    “Een SQL injectie is in principe ook gericht op een black box. Het is veel trial en error en maar hopen dat ze de gebruikelijke patronen volgen op de server. Je kent zelden de tabelstructuur in de database.”

    De kennis over de tabelstructuur is inderdaad onbekend, en daarom trial-and-error, maar de kennis dat er een SQL database server draait die daar in combinatie met scripts mogelijkerwijs gevoelig voor is, is hele concrete kennis van de werking van het systeem, en maakt dat SQL-injectie niet in een black box werkt, en URL manipulatie wel.

    Vergelijking (sorry!): Ik bel de klantenservice van een bedrijf en druk een toetsencombinatie waarvan ik weet dat ik daardoor wordt doorverbonden met de directeur. OF Ik bel een klantenservice van een bedrijf en druk na het horen van wat keuzeopties op een nummer wat niet vermeld werd, maar qua patroonherkenning een logische keuze zou kunnen zijn. Ik weet echter op voorhand niet wat er gebeurt. Bij het een heeft men kennis van de interne werking van het systeem (en maakt daar misbruik van) bij het andere niet.

  27. Gatver. Echt? Als ik dat zou zien gebeuren dan gaan ze heel regulier expressief naar een eeuwig redirectend scriptje of zo. Een normale robot volgt links, meer niet.
    Google doet dit overigens niet. Bij Google volgen ze alleen maar de URL’s die ze binnen de webpagina’s kunnen herkennen, inclusief relatieve URL’s. En ja, robots.txt werkt bij Google prima. Desondanks weet Google best veel terug te vinden!

    Maar dat neemt niet weg dat er webcrawlers zijn die wel degelijk dergelijke patronen kunnen herkennen en aktief manipuleren. Er zijn ook webcrawlers die de inhoud van robots.txt gewoon negeren of juist gebruiken om interessante locaties op een server te vinden. Maar dergelijke crawlers hebben vaak een ander doel dan het maken van een zoek-index. Je moet dan eerder denken aan hacker-applicaties die zoeken naar kwetsbaarheden op een site. Maar ook de eerder genoemde Fusker-sites maken dankbaar gebruik van URL manipulatie om series van afbeeldingen te kunnen ophalen van diverse websites.

    Ten slotte, Google analyseert het complete web. In dit geval zal het mij niet verbazen dat Google binnen twee uur tijd de URL naar de kerstrede van 2012 had gevonden nadat deze op Twitter werd gepubliceerd. En dat zou betekenen dat iedereen hem vanaf dat moment kon terugvinden op Google omdat de link bij Google bekend is gemaakt. Niet via de site zelf, maar buitenom, via b.v. Twitter of een andere website.

    1. Ik hoorde dat Google ook het referer-veld in de header indexeert. Dus stel, je hebt een site waar geen enkele link naartoe gaat. Als op die site een link staat naar een pagina met Google advertenties, dan kunnen ze in de referer zien waar je vandaan kwam. Als ze die nog niet hadden, gaan ze daar ook kijken.

      Url-manipulatie heb ik bij Google ook nog niet van gehoord. Maar het gebeurt wel bij andere zoekmachines.

  28. Beste meneer Engelfriet,

    Op deze manier verbied u mensen een url zelfs perongeluk verkeerd in te toetsen. Stel dat ik de website van Microsoft wil bezoeken, maar perongeluk http://www.microsot.nl in type. Plotseling blijkt er achter microsot.nl een hele hoop prive-gegevens te liggen. Dat ik hier perongeluk al dan niet expres terechtkom, is wettelijk onjuist, dat klopt, maar menselijk gezien mogelijk. Uw conclusie “het mag niet” is te kort door de bocht als u het mij vraagt.

  29. Het opvragen van een artikel uit een database driven website gaat over het algemeen via hyperlinks die op de betreffende website worden aangeboden. Het komt vaak voor dat de beheerder een einddatum aan een artikelen heeft gekoppeld. Na het verstrijken van die datum wordt de hyperlink naar dat artikel meestal niet meer op de website aangeboden, waardoor dat artikel niet meer direct opvraagbaar is. Als het betreffende artikel echter niet werd verwijderd uit de database, of anderszins ontoegankelijk werd gemaakt, dan is de inhoud van dat artikel nog altijd beschikbaar. Als de betreffend URL nog beschikbaar is in de cache van mijn browser, dan kan ik dat artikel zonder problemen opvragen. Is dat dan ook strafbaar of onrechtmatig? Als de betreffende URL nog beschikbaar is in mijn geheugen, mag ik die URL dan intypen en het artikel opvragen? Als de betreffende URL nog bijna in zijn geheel beschikbaar is in mijn geheugen(artikelnummer weet ik niet meer precies), mag ik die URL dan intypen en het artikel opvragen, door het artikelnummer handmatig op te geven? Is dat dan ook strafbaar of onrechtmatig? Voorbeeld: Ik dacht dat de URL naar informatie over een medewerkster van en Belgisch ziekenhuis bijvoorbeeld luidde: http://www.czv.be/scr/staf/detail.php?sid=12 Na het intypen en opvragen van deze URL bleek mij dat dit niet de informatie was dat ik bedoelde. Ik wilde de informatie opvragen over ‘Antonia ARNAERT’. Ik heb het nummer vervolgens handmatig in de adresbalk van de browser gewijzigd in ‘sid=13’, waarna ik wel de gezochte gegevens kon bekijken. Is dat dan ook strafbaar of onrechtmatig? Naar mijn mening is het opvragen van openbaar toegankelijke gegevens die kennelijk voor publicatie bedoeld zijn of zijn geweest, en waarbij de beheerder geen maatregelen heeft genomen om te voorkomen dat die gegevens opgevraagd kunnen worden, geen onrechtmatige daad. Of die openbaar toegankelijke gegevens opgevraagd worden via een bestande hyperlink op de website, of via Google, of via Archive.org, of handmatig , of via een script, et cetera, doet eigenlijk niet ter zake.

  30. “tenzij de ontwikkelaar die de site heeft gebouwd een enorme onbenul is en de server software in C++ of C heeft ontwikkeld.”

    Ook in C is hetgoed mogelijk zo te programmeren dat bufferoverflow onmogelijk zijn. Maar dat de programmeur inderdaad wel zelf doen, met vakmanschap, dus daar zit een risico.

  31. Even een andere vergelijking; in plaats van de URL aan te passen, stuurt de boze hacker een e-mail naar een contactadres van de RVD met de vraag of hij de kersttoespraak van 2012 mag inzien. Een verwarde medewerker stuurt hem vervolgens de link.

    De boze hacker heeft gebruik gemaakt van een technisch systeem, en heeft dat gedaan met de intentie een document op te vragen waarvan hij wist of kon vermoeden dat het nog niet toegankelijk was. Strafbaar?

  32. Nog een leuke: veel bedrijven zijn overgestapt op betaalnummers. Het oude gratis (of veel goedkopere) nummer is dan niet meer te bereiken. Om het bedrijf toch goedkoop te bellen bel ik gewoon het oude nummer plus of min een klein getal, en vraag dan aan de nietsvermoedende medewerker die opneemt me even door te verbinden…

  33. Dit is dus echt een onzin discussie. Een HTTP webserver is een tafel voor het huis met daarop een groot bord GRATIS INFORMATIE. Er is een hoek van de “tafel” die NIET gratis is: de afgeschermde directorie. [ site.nl/afgeschermd vraagt om een gebruikersnaam en wachtwoord. De website meldt: “afgeschermd”]

  34. Mijn intuïtieve reactie op de strafbaarheid is argh…en mijn rechtsGEVOEL zegt in ieder geval dat op de blunder van de RVD een sanctie zou moeten staan en dat het veranderen van (een nummertje in) een URL normaal gebruik is dat zeker in dit geval geen sanctie verdient.

    Er is van een kant bekeken misschien niet zo veel verschil met ongewenst op iemands bosgrond komen als de eigenaar niet duidelijk maakt dat hij geen prijs stelt op toegang door onbevoegden (bijvoorbeeld door een hek te plaatsen en/of dat bordje “verboden voor onbevoegden” te plaatsen). Ik kan me in beide gevallen niet voorstellen dat zoiets in deze tijd nog tot een zaak zou komen.)

    Mocht de RVD dat wel willen, zouden ze dan zelf niet even strafbaar zijn wegens uitlokking? Op wikipedia – http://nl.wikipedia.org/wiki/Deelneming_(misdrijf) – las ik dat (volgens Titel V van Boek I van het Wetboek van Strafrecht, art. 47 lid 1 sub 2 Sr ) uitlokken net zo zwaar wordt gestraft als wanneer men de werkelijke dader van het strafbare feit zou zijn geweest. De intentie van uitlokking (meer aandacht voor die rede?) zal wel lastig te bewijzen zijn.

    Overigens lijkt het verder vervroegd openbaar maken van (delen van) de toespraak mij in theorie een (licht) ernstiger punt. Wellicht zijn daarmee auteursrechten geschonden; wat vind jij Arnoud?). Zelfs daarbij zou je misschien ook kunnen beargumenteren dat het hier gaat om uitlokken, want als het alleen gaat om het ophogen van een nummertje is dat toch wel meer dan een beetje dom … Zeker naar jaren lekken van miljoenen nota’s door de overheid.

    Het WWW is vooral bedoeld om handig gegevens te linken en te delen en dat is toch wel een groot verschil met bijvoorbeeld een huis of fiets die je niet op slot zet; als je iets beperkter wilt delen op het WWW vind ik dat de wetgever mag verwachten dat je daar ook iets aan beveiliging/afscherming voor doet. Zeker een voorlichtingsdienst moet zoiets begrijpen, maar eigenlijk ook ieder andere partij. Ik denk ook niet dat iemand zou willen beargumenteren dat het ophogen van een nummertje als beveiliging geldt. Datzelfde zou ik overigens ook niet kunnen beargumenteren voor alle SQL-injectie: niet voor een systeem zonder enige ‘beveiliging’ en zonder waarschuwingen (wel als je misbruik maakt van technische foutjes, beveiligingen/voorwaarden omzijlt, etc.: je komt dan wel ‘willens en wetens op onbevoegd terrein’). Daar komt nog bij dat dit ook door iemand in een ander land (dat ons rechtssysteem niet erkent) en/of anoniem zou kunnen worden gedaan en dat het gerefereerde verbod ook daarom niet effectief is.

    Toch zou ik niet graag willen dat als mijn vrouw of dochter of arts (zelf zou ik dat natuurlijk nooit doen 😉 gegevens, die duidelijk privé zijn, per ongeluk via een URL deelt, dat anderen die gegevens dan zomaar mogen bekijken (en verder verspreiden).

    Lijkt me dan toch dat je ‘willens en wetens op onbevoegd terrein’ bent en computervredebreuk pleegt, zelfs als de URL voor de hand ligt. Misschien niet bij de eerste pagina, maar toch wel als je dan verder blijft neuzen. Iets dergelijks geldt voor de admin pagina van dit blog (mocht je die kunnen vinden): er op komen zou niet illegaal moeten zijn; wijzigingen maken als de beveiliging per ongeluk is afgezet wel!

    @Arnoud: Of is het bekijken van privé gegevens ook via andere wetgeving al strafbaar? En belangrijker: is er ook nog wetgeving tegen het verspreiden van mijn privé gegevens? (Stel: iemand ontvangt per anonieme mail allerlei privé gegevens over mij)?

    Tot slot: ergens ligt het voor de hand misbruik van HTTP GET juridisch milder te behandelen dan HTTP POST: bij de eerste hoort de intentie om “alleen maar” iets op te halen; bij de tweede om iets te veranderen op server).

    Zou het problemen geven als je HTTP GET van iedere willekeurige URL zou toestaan zolang je geen aanwijzingen hebt dat je op onbevoegd terrein bent (en niet te veel verzoeken naar dezelfde stuurt)?

    Weer een reactie van mij die veel langer is geworden dan ik eigenlijk wilde: de reacties van de anderen hebben me laten zien dat het weer allemaal veel complexer is dan het in eerste instantie leek.

    1. Lijkt me dan toch dat je ‘willens en wetens op onbevoegd terrein’ bent en computervredebreuk pleegt, zelfs als de URL voor de hand ligt. Misschien niet bij de eerste pagina, maar toch wel als je dan verder blijft neuzen. Iets dergelijks geldt voor de admin pagina van dit blog (mocht je die kunnen vinden): er op komen zou niet illegaal moeten zijn; wijzigingen maken als de beveiliging per ongeluk is afgezet wel!

      Maar dan zeg je in feite, rondkijken is nooit strafbaar, pas het aanpassen/vernielen na binnendringen is dat. En dat is bewijstechnisch lastiger, zeker bij grote data. Plus, vind je dan niet dat het enkel lezen van gegevens strafbaar moet zijn na binnendringen? Is een insluiper pas strafbaar als hij iets meeneemt of stukmaakt?

      @Arnoud: Of is het bekijken van privé gegevens ook via andere wetgeving al strafbaar? En belangrijker: is er ook nog wetgeving tegen het verspreiden van mijn privé gegevens? (Stel: iemand ontvangt per anonieme mail allerlei privé gegevens over mij)?

      Er zijn wetten over vernielen van data, en natuurlijk heb je de privacywet waar je civielrechtelijk wat mee kunt doen. Maar an sich is het publiceren van privégegevens niet strafbaar.

      Tot slot: ergens ligt het voor de hand misbruik van HTTP GET juridisch milder te behandelen dan HTTP POST: bij de eerste hoort de intentie om “alleen maar” iets op te halen; bij de tweede om iets te veranderen op server).

      Nee, dat kun je zo stellig niet zeggen. Menig systeem gebruikt GET om commando’s door te geven. WordPress bijvoorbeeld hanteert deze GET URL als ik een comment wil weggooien: http://blog.iusmentis.com/wp-admin/comment.php?c=31337&&action=trashcomment&_wpnonce=d34db33f

      Er zit een beveiliging tussen natuurlijk maar als jij deze aan kon roepen dan was er daarna wel data weg. En gezien het “action=trashcomment” is de intentie daarvan duidelijk. Idem dus voor een SQL injectie met “drop database”, die kan ook met een GET URL.

      Zou het problemen geven als je HTTP GET van iedere willekeurige URL zou toestaan zolang je geen aanwijzingen hebt dat je op onbevoegd terrein bent (en niet te veel verzoeken naar dezelfde stuurt)?

      De wet komt precies daar al op neer. Zolang je geen aanwijzingen hebt dat je op onbevoegd terrein bent, is het prima. Echter, omgekeerd: zodra je wél weet dat je op onbevoegd terrein bent, ben je strafbaar. Of je nu GET of POST en of je nu een ID met drie ophoogt dan wel een complexe 256-karakter URL-encoded buffer overflow exploitstring toevoegt.

      1. De wet komt precies daar al op neer. Zolang je geen aanwijzingen hebt dat je op onbevoegd terrein bent, is het prima. Echter, omgekeerd: zodra je wél weet dat je op onbevoegd terrein bent, ben je strafbaar.

        Dan is de primaire vraag dus of deze man kon weten dat hij op onbevoegd terrein was en dat betwijfel ik toch. Door gewoon een pagina op te vragen en die geserveerd te krijgen, kan je toch niet opmaken dat je op onbevoegd terrein bent?

        1. Is het “gewoon” dat je een datum en een serienummer aanpast in een URL?

          Voor een gemiddelde internetter is het ‘gewoon’ dat je op die blauwe onderstreepte teksten klikt. Zelf getallen intypen zal voor deze maatman neerkomen op “apart hoor dat dat ook kan”.

          En tussencategorie: op mijn blog hebben URL’s een datum en leesbare tekst (de titel). Maar wie WordPress kent, weet dat ?p=123 ook werkt om bericht 123 te krijgen. Is dat ‘gewoon’ een URL intypen? Of is deze kennis van WordPress “ongewoon”? Maakt het uit of dit in de WP documentatie staat of dat een of andere vage pipo het op een hackersforum met blauwe letters op zwarte achtergrond meldt?

          1. Voor een gemiddelde internetter is het ‘gewoon’ dat je op die blauwe onderstreepte teksten klikt.
            Ja maar, ho eens even. Dat kan natuurlijk geen onderbouwing zijn. Wat gemiddeld is verandert namelijk in de loop der tijd. In 1996 kreeg ik van mijn faculteit een lijstje handige URLs die ik braaf intypte. Daarnaast kregen we uitleg over hoe het internet werkte inclusief het idee van URLs. Dat was denk ik normaal voor die tijd en de gemiddelde internetter snapte hoe dat werkte. Dat dat nu niet meer zo is maakt niet dat handelingen nu ineens strafbaar zijn die dat vroeger niet waren. Lijkt mij dan.

          2. Arnoud, voor degenen die in 1993 begonnen met Mosaic (Netscape bestond nog niet eens) is het aanpassen van URLs heel normaal.

            Veel URLs (die officieel nog niet eens bestonden tot ’94 zoals elders hier vermeld) bestonden uit www.(naam instituut).edu/(gebruikersnaam). Als wist welke bekende personen op een universiteit werkte en je wilde zien of ze een webpagina hadden, dan veranderde je gewoon het (gebruikersnaam) gedeelte. Aangezien dat per instelling gestandaardiseerd was had je slechts namen en een bekende pagina nodig om voor alle medewerkers uit te zoeken of ze een pagina hadden.

            Zo kom ik nog regelmatig op paginas door gewoon URLs in te typen inplaats van door links te volgen.

            Misschien dat het voor de gemiddelde internetter niet gewoon meer is. Maar het internet wordt inmiddels door zoveel mensen gebruikt, dat ‘niet gemiddelde internetgebruikers’ alsnog aanzienlijke groepen zijn. Je kan de gemiddelde internet gebruiker niet gebruiken voor iets wat gewoon is.

            Binnen de accountancy is er een manier van vastlegging die zeer specifiek is en die zeker zal afwijken van hoe een gemiddeld persoon administreert. De werkwijze van een accountant wordt toch ook niet afgekeurd omdat de gemiddelde persoon het anders doet? En zo hebben meer groepen hun eigenaardigheden, die desondanks binnen deze groepen gangbaar zijn.

            1. Het lastige is dat de standaard voor ‘binnendringen’ een intentie/kennisniveau (weten of moeten weten) criterium bevat. De vraag is dan hoe je dat invult, en dan kom je al snel bij de gemiddelde gebruiker uit.

              De gemiddelde burger weet dat een tuinhekje betekent “privéterrein, ga weg”. Dus wie willens en wetens over een hekje heen stapt, pleegt erfvredebreuk. Maar een postbezorger denkt daar anders over, die weet dat hij daar mag zijn want hij heeft post te bezorgen.

              Of ander voorbeeld: in menig boerendorp vind je nog sleutels onder de mat dan wel in klompen vlakbij aan de muur. Handig, maar je zou toch moeten weten dat je niet naar binnen mag met die sleutel ook al vind je ‘m toevallig. Tenzij je ziet hoe de melk overkookt of de kat in de problemen is.

              Zoiets zal ook het verschil zijn tussen een gemiddelde n00b en een gemiddelde hacker.

              1. Ja, alleen hierbij kom je op het tegenstrijdige uit dat de ‘hacker’ hier vaak ook degene zal zijn die URL handmatig aanpassen normaal vind als hij niet hackt. Juist de ‘noobs’ waar de grote meerderheid op het internet uit lijkt te bestaan zullen dit niet zo zien.

                Als je dus een hacker dan gaat aan houden tegen de gemiddelde internetter dan is hij schuldig omdat hij iets uit kennis normaal vindt omdat de meeste mensen die kennis niet hebben. Dat kan toch niet de bedoeling zijn.

      2. Nee, dat kun je zo stellig niet zeggen. Menig systeem gebruikt GET om commando’s door te geven.

        Ik weet het, niet alleen WordPress… Maar GET was daar toch niet voor bedoeld; daar was toch de POST voor uitgevonden? Als je systemen op een andere manier gaat gebruiken dan bedoeld geeft dat vaak veel problemen. Waarom niet de verantwoordelijkheid voor die problemen in eerste instantie leggen bij de degenen die de techniek verkeerd gebruiken (zeker als er alternatieven zijn)? Voor de GET weet ik niet zeker of dat nu nog reeel zou zijn (dat is wellicht te veel uit de hand gelopen), maar voor URL’s lijkt het me toch duidelijk dat die niet bedoeld zijn voor security en dat daar veel betere alternatieven voor zijn.

  35. Probleem is dat veel mensen slechts op linkjes klikken en niet weten wat er achter zit. En al helemaal niet hoe een Apache webserver werkt. Dat geld dus ook voor rechters en andere juristen…. Iedere standaard .html pagina wordt “gehaald” met het commando GET. Op het moment dat ik hier onder op “Publiceeer uw reactie” klik volgt er een POST commando. Iedere scriptkiddy van 11 weet dat elke williekeurige bestaande standaard URL gratis info oplevert. Iedere webmaster en iedere systeembeheerder weet dat ook. HTTP is vrij zoeken door op de server beschikbare informatie. Dat mijn moeder van 91 dat niet weet, tja. Als een rechter of jurist van 40 dat niet weet is of ongeinteresseerdheid of onwil. Zulke mensen horen niet thuis op ICT recht. Hetzelfde geldt voor ministers en staatssecretarissen. Webmasters die dus zaken open en bloot op een HTTP server zetten doen dat met hun volle verstand. Als dat niet de bedoeling is, dan is dat een fout van die webmaster. Als ik zijn baas was, was hij nog niet klaar me. Dan vloog hij de eerst volgend keer richting UWV.

    1. HTTP is vrij zoeken door op de server beschikbare informatie.

      Met die stelling win je natuurlijk het debat, maar de vraag is nu juist óf HTTP werkelijk “vrij zoeken” is. Waaróm moeten we de werking van een technisch protocol leidend laten zijn bij de vraag of de informatie die daaruit komt, vrij is?

      Let wel, ik zeg niet dat een GET altijd computervredebreuk is. Het gaat hier specifiek om zelf geconstrueerde GET commando’s waarvan je weet of moet weten dat deze niet als link gepubliceerd zijn door de webmaster.

      1. Ja mijns inziens is HTTP in principe bedoeld om openbaarmaking van documenten aan de rest van de wereld en dat is begonnen bij de grote universiteiten om informatie over onderzoeken met anderen te delen. Wil je info op een HTTP server zetten en niet delen dan is het toevoegen van een enkel .htacces filetje voldoende om de map af te sluiten. http://www.homepage-maken.nl/htaccess/directory-beveiligen.php Nogmaals iedere webmaster kent dit principe. Het niet toepassen ervan betekent pertinent volledig vrij toegankelijk gemaakte informatie.

  36. Ik trek even een parallel en ben benieuwd waarom deze volgens jou niet opgaat:

    “Wil je spullen in een tuin zetten en niet delen dan is het toevoegen van een enkel hek voldoende om de tuin af te sluiten. Nogmaals iedere huiseigenaar kent dit principe. Het niet toepassen ervan betekent pertinent volledig vrij toegankelijk gemaakte spullen.”

    1. Nee dat is een foute vergelijking. Je tuin is PRIVE terrein terwijl een HTTP server een soort openbaar prikbord is waar je alles op plakt dat je met de rest van de gemeenschap wilt delen. HTTP is delen tenzij… een tuin is afgesloten tenzij…

      1. Jamaar WAAROM is mijn tuin privé en mijn server niet?

        Beiden zijn mijn eigendom, juridisch gezien. En beiden kun je fysiek betreden met de juiste stappen (over hekje heen cq HTTP GET).

        Je kunt wel zeggen “HTTP is delen tenzij” maar welke juridische grondslag is er om te zeggen dát HTTP delen is. En welk fundamenteel verschil is er dan tussen jouw HTTP naar mijn webserver en jouw laarzen in mijn tuin. Je kunt dit niet zomaar poneren, er moet een achterliggende juridische grond zijn.

        1. Jamaar WAAROM is mijn tuin privé en mijn server niet?

          Het grote verschil is dat ik bij jouw tuin kan zien of er een hek om heen staan. Bij jouw server is de enige mogelijkheid om een vraag te stellen en dan te zien of er een hek om heen staat.

          Het is een beetje als stellen als er een rode vlag in m’n tuin hangt mag is het verboden naar m’n tuin te kijken. Door alleen maar te kijken of er een vlag hangt kan je dan al in overtreding zijn…

          1. Mijn voortuin heeft geen hek, het enige waaraan je het kunt zien is dat de tegels ophouden en het gras begint. Je moet dus ook daar heel goed opletten. En mijn buurman drie huizen verderop heeft ook zijn tuin betegeld, dan moet je ongeveer het Kadaster raadplegen om te weten waar je moet zijn.

            En ja klopt, de situatie wordt dan heel diffuus maar daar zou ik dan tegenover stellen dat als je gewoon alleen klikt op linkjes er geen risico is. Wie zelf gaat URL-aanpassen loopt de kans dat er iets stuk gaat.

            1. Uit de definitie van een webserver op de engelstalige wikipedia:

              The primary function of web server is to deliver web pages on the request to clients using the Hypertext Transfer Protocol (HTTP). This means delivery of HTML documents and any additional content that may be included by a document, such as images, style sheets and scripts.
              De primaire functie van een webserver is content serveren. Dus alsof je spullen in je tuin hebt staan met een groot bord erbij “Gratis mee te nemen”. Alleen werkt http hier via opt-out (alles is openbaar tenzij) en niet via opt-in (je mag geen spullen uit mijn tuin meenemen tenzij). Daarom is jouw tuin prive en de content op je webserver niet. Technisch gezien tenminste. Wat de wet hierover zegt weet ik niet.

              1. Ik blijf moeite houden met juridische consequenties verbinden aan wat apparaten doen. Bij een deur met codeslot mag je ook niet naar binnen als je de pincode weet te raden, hoewel het slot de deur wel opendoet.

                Het blijft terugkomen bij de intentie van de webmaster. En ook die van de opvrager vind ik. Want het blijft me wat geconstrueerd aandoen om een ID in te vullen en dan gek op te kijken dat je onverwachte content krijgt.

                1. Het gaat niet om het apparaat. Het gaat om de technische “wet” , oftewel het protocol, dat meer dan twintig jaar geleden is afgesproken.
                  Nogmaals, what the law says, wat wet zegt, weet ik niet. Het zou best kunnen dat je volkomen gelijk hebt wat de wet betreft. Maar elke technische persoon weet dat de content je plaatst op een webserver, public is tenzij je beveiligt het. The webserver zou dan moeten teruggeven een HTP-401, 403 or 404. Verder is een ID natuurlijk niet bedoeld als een beveiliging, het is enkel een verwijzing naar het volledige document/artikel/whatever.

                  1. Klopt, de wet is hier -denk ik- anders dan de techniek. Maar héél gek vind ik dat niet. Ook bij een injectie of buffer overflow krijg je vaak een 200 OK terug. Die code zegt alleen iets over het technisch stuk van het protocol, “Ok ik heb data, komt ‘ie” en absoluut niet over de juridische status.

                    Gevaarlijke analogie: een pistool functioneert perfect als jij de trekker overhaalt en het ding een kogel schiet. Toch zegt de wet dat je niet zomaar dat gewoon functionerend apparaat op mensen mag richten, laat staan de trekker overhalen. Het gevaar voor de maatschappij is hier doorslaggevend – hoewel het apparaat technisch gewoon doet waar het voor bedoeld is, namelijk schieten. Uit het feit dat iets doet wat het technisch moet doen, kun je niet afleiden dat het ook mág, of zelfs maar dat het móet mogen.

                    Iets minder gevaarlijke analogie is die van Pirate bay: die site werkt ook perfect, maar hun 200 OK’s slaan toch echt op data die juridisch niet oké zijn.

                    1. I don’t completely agree on that analogy of yours (and sorry to fall back to english, but my translating skills are in a meeting atm 🙂 ).

                      The correct analogy would be more like “it’s legal to point your gun at some people and then shoot to kill, and it’s illegal to point your gun at some other people and then shoot to kill”.

                      Because, as lots of others have stated before me, many if not most websites recognize that url-manipulation is widely used, and even one the oldest www-standards there is. And they actively make use of that. Like your blog does. Hence the saying “if you don’t want to publicize, don’t put it on the web”. The website of your rvd is one of the few who apparently doesn’t see this. This law of yours thusly created a situation online where it’s legal to do stuff at website A and the exact same thing is apparently illegal at website B. And it’s up to you to guess, and if you guess wrong, the DOJ knows where you are. That creates so much uncertainty that everybody stands up to it.

                      And now I have to really get some work done. Cheers!

                    2. Maar de Piratenbaaianalogie gaat niet op. De 200 OK is niet okee misschien, maar geen computervredebreuk. Volgens mij zitten er in dit gebied veel hiaten in de wet en/of zaken die niet kloppen met het maatschappelijk gevoel. Die wet moet dus aangescherpt worden zodat dit in de toekomst duidelijker is. Zou mooi zijn als de RVD gaat procederen, dan krijgen we precedent (toch?).

  37. Op dit blog, dit openbaar wereldwijd toegangkelijk prikbord, schrijf jij teksten die juridisch gezien jou eigendom zijn, maar je deelt ze met de rest van de wereld, daar kies je dus voor. Als je ze niet met de wereld wil delen, zet je ze er niet op! Niets juridisch aan. Precies zoals huisvuil aan de deur zetten, het is van jou maar als je het in de tuin laat staan neemt de vuilnisman het niet mee, pas als je het aan de straat zet gaat het de vuilnisauto in. De vraag die je stelt is eigenlijk net zoiets als wat is de juridische grondslag van een auto.

    1. Nee, wat ik vraag is de juridische grondslag van met een auto op de weg mogen rijden. En die grondslag staat keurig in de Wegenverkeerswet, namelijk je hebt toestemming op de openbare weg te rijden. En volgens de definitie daaruit mag je dus de weg op (mits je aan de voertuigeisen voldoet en een rijbewijs hebt), en zelfs mijn oprit, maar niet mijn met slagboom afgesloten bedrijfsparkeerterrein.

      Dat principe van de W3 is leuk maar geen wet. Als ik even doorgoogel kom ik nog veel meer principes tegen, zoals dat internet wetteloos is (Barlow’s Declaration of Independence) of dat auteursrecht niet bestaat. Daar kan ik juridisch niets mee.

      Juridisch gezien kom ik niet verder dan dat een server eigendom is (3:2 BW) en dat ik bepaal wat jij op mijn server mag doen (HR Ab.fab/Xs4All). Plus dat ‘computervredebreuk’ omvat ieder binnendringen, ook zonder beveiliging te kraken (138ab Sr), mits je weet of moest weten op verboden terrein te zijn (zie memorie van toelichting).

      De stelling “als ik het met HTTP kan opvragen is het dús vrij” past niet dat juridische kader.

      En los daarvan: ik weiger te accepteren dat het moedwillig invoeren van http://example.com/klant.php?id=12&naam=Robert%20′);DROP%20DATABASE;– op enigerlei wijze legaal kán zijn. Met die URL is mijn database weg. Hoewel dit toch gewoon een HTTP GET request is dat voldoet aan de URL RFC.

        1. Hoe weet ik dat die URL wél legaal en conform de bedoeling van het web is, en die URL van mij niet?

          Jij haalt er nu de kwade bedoeling van de URL-intyper bij, dus kennelijk is het toch niet zo eenvoudig als “via GET op te roepen = legaal”. Hoe meten we die intentie?

          En als we die intentie meten, waarom geeft ie dan wél de doorslag bij een GET met een SQL injectie en níet bij een GET met een zelfgeraden ID? Of bij grapjes als ../../../../../cmd.exe?format%20c:? Ook dat is een legale URL conform de specificaties, hij doet alleen iets vervelends. Maar ja, moet je het maar niet zonder .htaccess online zetten?

          1. Hoe weet je dat? In Piet zijn geval vraag je alleen informatie op, in jouw voorbeeld verander je code die op zijn server wordt uitgevoerd. Lijkt mij een duidelijk te onderscheiden verschil.

            De ‘bedoeling van het web’ is eenvoudig. alles wat op het net staat en niet achter een beveiliging zit of alleen via hacken te krijgen is is openbaar. Zo is het web vanaf dag 1 bedoeld, een wet verandert de bedoeling niet. Het maakt het alleen heel moeilijk als mensen niet begrijpen wat de bedoeling is.

            1. Oké, doe ik geen drop database maar “select *”. Of ik doe ../../../../../etc/shadow en krijg zo een lijstje van alle wachtwoorden.

              Juridisch gezien gaat het bij binnendringen niet om “vernielen/wijzigen”, sterker nog in de wet staat dat als je dat doet je éxtra straf krijgt. Dus ook binnendringen zonder één bit te wijzigen is al strafbaar.

              1. Bij een ../../../../../etc/shadow heb je kennis: * dat het webscript een bestand dat aanwezig is op een Unixsysteem retourneert * van de locatie van het webscript * dat het webscript rechten heeft de /etc/shadow te lezen … waarmee mij duidelijk is dat jouw intentie is om niet met het webscript te werken, maar veiligheidsgevoelige informatie uit het onderliggende Unix-systeem te verkrijgen.

                Intentie is erg belangrijk in het strafrecht: Als je op de Domtoren met iemand ruzie krijgt en hem ervan afduwt zonder de wens hem te doden is het doodslag, wilde je hem dood hebben, dan is het moord. Juridisch moet jouw intentie bewezen worden.

                Uit een toonfoto?naam=ninja.jpg kan geen intentie worden afgeleid veiligheidsgevoelige informatie uit het onderliggende Unix-systeem te verkrijgen, uit een toonfoto?naam=../../../../../etc/shadow wel.

      1. Arnoud ik zei dit in een andere post al id veranderen en SQL injectie zijn twee verschillende dingen: 1. Met het veranderen van een ID voer je een beschikbaar gestelde query uit. Het is aan de database beheerder of hij de query toestaat antwoord te geven bij een bepaalde ID. 2. Als je SQL code gaat injecten dan pas je de query aan. Je maakt dus niet meer gebruik van een beschikbaar gestelde query.

        Om te beginnen is de Query nooit onderdeel van de URL. De maker koppelt een query aan het aanroepen van een bepaalde URL, waarbij via http parameters worden doorgegeven voor die query. De maker van de website bepaald dus wat jij te zien krijgt en wel door de query die hij aan het aanroepen van de URL heeft gehangen. Een ID aanpassen is dus niets anders als vragen aan de server heb jij gegevens voor mij die aan deze voorwaarde voldoen. De eigenaar van de server bepaald wat het antwoord hierop is.

        Als je SQL injectie doet dan onttrek jij je aan de beperkingen die de serverbeheerder heeft opgelegd in de query. Immers je veranderd niet alleen de parameters van de query (waarvoor die query voor bedoeld is, zonder parameters kan je net zo goed een statische pagina maken), de code die wordt uitgevoerd wordt ook aangepast! Hier dring je dus duidelijk het systeem binnen.

        1. Verander ik de query als ik zeg dat ik “Robert’);drop database” heet? Dat is dan toch gewoon mijn naam?

          Of, heel triviaal, als ik zeg dat ik “%” heet? Dat is de SQL wildcard maar ik voeg geen commando’s toe, ik omzeil niets, ik typ gewoon een karakter in. Bij een zeer domme installatie krijg ik nu wél alle records.

          Maar goed ik snap je punt en ik ga er in principe in mee.

          Hoe zie je het dan bij bv. ../../../../../../../../etc/passwd? Is legaal maar doet niet wat de webmaster had verwacht.

          Of, en ja deze komt echt voor: een ID in de query die als je ‘m aanpast, de gegevens van een andere klant geeft. bestelling.php?id=123&order=2. Of de variant bestelling.php?product=pizza+margherita&prijs=995 en dan de prijs aanpassen. Bestel ik nu lekker handig met een commandline interface of ben ik aan het oplichten?

          1. Is het niet gewoon iets wat een webmaster redelijkerwijze had mogen verwachten. De pizza bestellen voor een andere prijs had de webmaster natuurlijk nooit verwacht, net zo min als DROP DATABASE. Bij een wildcard % is dat al lastiger omdat het soms wel de bedoeling is om alle records te zien.

            Op het moment dat de webmaster een document online zet en dit op geen enkele manier afschermt dan kan hij toch redelijkerwijze verwachten dat het opgevraagd wordt?

            Natuurlijk zijn er grijze gebieden maar volgens mij heb ik op dit blog geleerd dat recht nooit zwart wit is.

            1. Inderdaad, en daar zit exact de crux.

              Op het moment dat de webmaster een document online zet en dit op geen enkele manier afschermt dan kan hij toch redelijkerwijze verwachten dat het opgevraagd wordt?
              Hangt dat niet af van de URL? Hoe makkelijker probeerbaar deze is, hoe eerder ik dit argument op zie gaan. Met een patroon gebaseerd op datums wellicht ook, maar een arbitrair getal dat je maar moet gokken, hmm.

              Wat nu als de URL een hele lange GUID was en ik de site ga bruteforcen met alle mogelijke GUID’s? Oké ik ben lang bezig in theorie maar stel ik heb mazzel en gok het na een week goed. Is het dan binnendringen want dat mag je redelijkerwijs niet verwachten?

              1. Met een datum in de URL lijkt het me dat het gewoon de bedoeling is dat je die kan veranderen. Zelfde geldt voor een normaal nummer zoals jouw comments. Ik reageer op comment 77774 dus als ik nu de url verander in 77773 dan reageer ik op een eerdere reactie. Lijkt me allemaal nog de bedoeling, of kan de webmaster redelijkerwijze verwachten dat dit kan gebeuren.

                Als het om een lange GUID gaat, is het duidelijk niet de bedoeling van de webmaster dat deze aangepast wordt en kan je het vergelijk met een kantoorpand waarbij je aan elke deur gaat voelen of ie open is. Dit terwijl er ook gewoon een receptie is (homepage, sitemap) waar je kan vragen waar je moet zijn.

              2. In feite komt het neer op een vergelijking (sorry) als hierboven al is geschetst middels de deurbel. Het HTTP-GET protocol is een soort van colportage: ik bel aan met een vraag, en het is aan jou om wel of niet op de vraag in te gaan, gelijk een webserver die al dan niet de keuze heeft om een antwoord te geven.

                Omdat dit in de “echte wereld” voor nogal wat mensen problemen opleverde is de colportagewet ingevoerd. Voor mijn gevoel probeert computervredebreuk eenzelfde “virtuele” bescherming te bieden (voor zover dat kan uiteraard…)

          2. Verander ik de query als ik zeg dat ik “Robert’);drop database” heet? Dat is dan toch gewoon mijn naam?

            Sorry, maar je hebt zelf vaak genoeg de giecheltest aangehaald. Hier kom je niet mee weg 😀

          3. Buiten dat al je voorbeelden reden voor ontslag van de maker van de website danwel server beheerder zouden moeten zijn …?

            Uitgannde van intentie als belangrijkste criterium: De /../../.. etc… is een grens geval, waarbij ik al snel zou zeggen dat de intentie duidelijk is. etc/password is niet een bestand dat je oproept omdat je een webpagina om informatie will vragen.

            Invoeren van % als wildcard? Dat voert nog steeds een ongwijzigde beschikbaar gestelde query uit, ik zou zeggen legaal en aan de beheerder om te blokkeren als hij geen wildcards wil toestaan. Met andere woorden je voegt geen code toe aan een query die uitgevoerd wordt naast de beschikbaar gestelde.

            De bestelling dat is de twijfelaat hier. Het kan zijn dat iemand slim nog even dacht zijn besteling aan te passen en per ongeluk iets wijzigt. Ik zou zeggen dat je hier pas duidelijk iets kunt zeggen als iemand meerdere keren de prijs aan past of op andermans naam bestelt. Dan is het aannemelijk geen vergissing meer.

          4. Zodra een developer geen rekening houd om alles achter een ? te controleren wat een gebruiker er achter zet dan ben je wel heel erg dom bezig. Je kan redelijk aannemen dat iedereen dit op zijn website mee te maken krijg zou wat zijn als PHP niet goed ingesteld staat je heb de optie naar je shell open staan dat is vragen om problemen.

    1. Klopt, maar een jurist gaat vallen over wanneer je authorized bent. Voor degenen bekend met de ontwikkeling van het web is het evident dat je authorized bent als je het vrij op kan vragen en geen 403 of 404 foutmelding krijgt.

      Arnoud zijn interpretatie is blijkbaar dat als er een link naar is ben je authorized en als er geen link naar is niet. Waarbij die link ook nog eens op de eigen server moet staan natuurlijk, want die link op die andere server kan wel via URL manipulatie zijn verkregen. Met de interpretatie van Arnoud is het web verworden tot één groot mijnenveld. Pagina’s kunnen niet meer naar pagina’s op andere servers verwijzen, uit angst aangeklaagd te worden voor computervrede breuk. Enige mogelijke linken is naar de root van de webserver. En dan hoop ik maar dat je uit het bestaan van http://www.willekeurigeserver.nl mag afleiden dat dat openbaar is, want niemand heeft mij gezegd dat die server openbaar is, dat neem ik ook maar aan.

      Dus link alleen naar een pagina op het web als je ergens een verklaring van de server eigenaar kan vinden dat het de bedoeling is dat je überhaupt op zijn server komt.

      1. Nou nee, als er geen gepubliceerde link is dan ga je een grijs gebied binnen. Misschien was het de bedoeling (zoals bij mij dat je een maandoverzicht krijgt als je 2012/12 als local-path intypt) en misschien ook niet (zoals bij mij dat je een login krijgt bij wp-admin als local-path).

        Cruciaal is de kennis die jij had: wist je dat je heir niet in mocht? Of had je dat moeten weten gezien de omstandigheden.

        1. Heb je dan geen kip en ei probleem? Op het moment dat er met ID’s gewerkt wordt, kan je pas een vermoeden krijgen dat iets niet voor publicatie bedoeld was op het moment dat je het al geopend en bekeken hebt.

          Op dat moment is het m.i. echter nog steeds geen binnendringen van het systeem door jou, maar foutief openbaar maken van de beheerder.

    1. Lijkt me voor de overgrote meerderheid van de Internetters voor de hand te liggen, ook voor de niet-techneuten. Als de wet dit anders wil zien lijkt me dat erg onpraktisch… Nu sleep je per ongeluk je privé directory naar de openbare folder (even niet opgelet, je muis deed raar, of iemand flikt je een streek…). Als die informatie heel privé is en anderen gaan daar in neuzen wordt het volgens mij op een bepaald moment wel computervredebreuk (zelfs als je webserver automatisch de links zou aanmaken). De grens is alleen niet heel zwart wit: het zal altijd een beetje onduidelijk blijven op welk moment precies je moet weten dat de informatie niet voor jou bedoeld was en het computervredebreuk wordt. Dat lijkt me op zich ook niet erg; dat kan een rechter beslissen op het moment dat het echt een probleem is. Bij brute-forcen op lange GUIDs lijkt het me momenteel ook aannemelijk dat dit niet de bedoeling is (je kunt aannemen dat dit bij de publicerende partij tot onevenredige kosten of vertragingen van zijn site leidt). Maar individueel een “beperkt aantal nummertjes” proberen lijkt me persoonlijk volledig in overeenstemming met de bedoeling van het WWW.

      Hier speelt voor mij ook de publicerende partij een rol: van een bedrijf gespecialiseerd in digitale beveiliging zul je eerder verwachten dat als iets publiek staat dat dat ook zo bedoeld was, dan van een privé persoon (van de RVD kun je natuurlijk geen enkele beveiliging verwachten en moet je eerst in 3-voud schriftelijk vragen of je hun pagina’s wel echt mag bekijken 🙂 )

      1. Ik ben het met Arnoud, Alex en anderen eens dat een categorische benadering op grond van blinde technologische argumenten hier niet volstaat en dat je er voor een goede beoordeling niet aan ontkomt om van geval tot geval te kijken en de intenties van de betrokkenen mee te wegen, zoals in de juristerij standaard praktijk is. De originele computervredebreukwet maakte computervredebreuk alleen strafbaar als er enige vorm van inbraak (doorbreken van beveiliging) aan te pas kwam (zie bv. Prof. Franken over de wet in TOM#6); ik vond dat fundamenteel verkeerd en ben blij dat het in 2006 rechtgezet is.

        Ook in dit geval lijkt me het technische middel (handmatig wijzigen van een URL) niet zo erg relevant, maar juist wel de intenties van de betrokkenen, en hun wederzijdse en algemene verwachtingen op dat punt. Iemand die handmatig URLs opvraagt mag denk ik geacht worden te weten dat de meeste webgebruikers niet weten dat dat kan, inclusief veel van de mensen die inhoud op een website aanbieden. Je mag denk ik van een organisatie die een serieuze website aanbiedt verwachten dat die gepaste maatregelen neemt (door de technische inrichting van het publicatieproces en instructie van de betrokken medewerkers) om ongelukken hiermee te voorkomen, maar niet dat zulke ongelukken daarmee onmogelijk zijn. Je moet je dus als webgebruiker bij alle pagina’s die je onder ogen krijgt, op wat voor site dan ook, blijven afvragen of wat je te zien krijgt wel voor jouw ogen bestemd is, en het dienovereenkomstig behandelen, en je kunt er op worden aangesproken als je dat niet doet. Welke technologie daarbij wordt gebruikt hoort niet terzake te doen; een aparte wet computervredebreuk zou overbodig moeten zijn.

        1. Hoi Reinier. Een mooi betoog, en alleszins redelijk. Ik vind echter wat ‘de gemiddelde webgebruiker’ weet niet zo relevant. Dat is namelijk een zeer snel verschuivend begrip. 10 jaar geleden wist de gemiddelde webgebruiker dit namelijk wel. Maar voornamelijk de argumentatie dat de mensen die inhoud op een website aanbieden dit ook niet zouden weten klopt volgens mij niet, zeker niet in een professionele context. Als je dus als bovengemiddeld slimme webgebruiker (een power user, maar geen hacker) een slimme URL gebruikt om tot content te komen, mag je verwachten dat de gemiddelde contentaanbieder content die niet opgevraagd mag worden heeft afgeschermd.

          Even terug naar de oh zo leuke tuinanalogie. Als je een stuk grond in een bos koopt en daar een huis op zet, mag er van je verwacht worden, als grondeigenaar dat je die grond op een of andere manier markeert als jouw eigendom (een hek, een bord, een grasveld, whatever). En het feit dat dat stukje bos toevallig minder makkelijk te vinden is voor de gemiddelde boswandelaar, mag niet betekenen dat de bovengemiddelde boswandelaar, die daar specifiek op zoek is naar de gespikkelde zomerberk, zomaar een fout stuk bos inloopt en aangeklaagd wordt voor huisvredebreuk.

          Maar zoals je al zei, intentie moet de belangrijkste afweging zijn.

          1. Hallo Matthijs.

            Het gaat hier niet om gemiddelden in numerieke zin, maar om wat redelijkerwijs van jezelf en anderen verwacht mag worden. Dat is inderdaad heel veranderlijk door de tijd heen en tussen verschilllende soorten computergebruikers, maar dat maakt het nog niet verkeerd om er toch een beroep op te doen.

            Ik verwacht dat bij veel websites, inclusief overheidssites, de mensen die de inhoud aanleveren niet dezelfden zijn als de technici die de website operationeel maken en houden, en dat de eerstgenoemden in het algemeen weinig benul hebben van de rol van URLs in het publicatieproces, zelfs als ze (bijvoorbeeld middels een CMS) eigenhandig de inhoud van de website kunnen aanvullen of wijzigen. De organisatie als geheel heeft die kennis wel (namelijk, de technici) maar dat hoeft dus niet afdoende te zijn om onbedoelde openbaarmakingen te voorkomen.

            Als je je in een bos op verboden terrein bevindt hoor je daarvan in kennis gesteld te zijn. Het kan zo zijn dat je door een samenloop van omstandigheden op verboden terrein komt zonder dat je dat in de gaten hebt (ik heb zoiets eens meegemaakt). Het kan ook dat je doet alsof dat zo is terwijl je in werkelijkheid heel goed weet dat je op verboden terrein bent. En omgekeerd kan het gebeuren dat je geen waarschuwing hebt gezien maar toch aan je klompen zou moeten aanvoelen dat je op verboden terein bent. Dit alles geldt voor de URL-ruimte net zo goed als voor de oppervlakte van onze aardkloot.

            1. Het gaat hier niet om gemiddelden in numerieke zin, maar om wat redelijkerwijs van jezelf en anderen verwacht mag worden. Dat is inderdaad heel veranderlijk door de tijd heen en tussen verschilllende soorten computergebruikers, maar dat maakt het nog niet verkeerd om er toch een beroep op te doen.
              Het probleem dat ik daarmee heb is dat iets wat ik nu doe, en legaal is, ineens over een paar jaar niet meer legaal is zonder dat de wet gewijzigd is. Dat de mensen en de maatschappij om mij heen veranderd zijn, en daardoor iets wat vroeger als normaal beschouwd werd nu als malafide praktijk beschouwd wordt, dat kan gebeuren, maar dan moet dat op z’n minst gereflecteerd worden in de wetgeving. En de wet mag mijns inziens niet zeggen: “dat wat de gemiddelde mens okee vind op dit moment”. Sorry dat gaat er bij mij niet in. Wat is okee, en wat niet? Dát moet in de wet staan.

              Daarnaast vind ik dat de professionals wiens taak het is om content online te zetten, op z’n minst het systeem waarmee ze dat doen basaal kennen. Ik ben techneut, maar ik werk veel met klanten die met een door ons opgezet CMS werken. Al deze klanten kennen de publicatiemogelijkheden (tot op bepaald niveau) van het CMS dat ze gebruiken. Dat is immers hun werk, content publiceren. En content die niet gezien mag worden publiceer je nog niet. Als dan een hacker via SQL injectie of een andere vorm van manipulatie van de HTTP request (URL, HTTP headers of anderzijds) toch ongepubliceerde content naar boven weet te vissen, dan is dat een ander verhaal dan via een (nog) onbekende URL. De daad van het op ‘Publish’ drukken mag dan ook de intentie met zich meebrengen (juridisch is intentie belangrijk zoals vastgesteld) dat die content daadwerkelijk gevonden en gezien mag worden.

              1. Matthijs

                Het gaat hier niet om gemiddelden in numerieke zin, maar om wat redelijkerwijs van jezelf en anderen verwacht mag worden. Dat is inderdaad heel veranderlijk door de tijd heen en tussen verschilllende soorten computergebruikers, maar dat maakt het nog niet verkeerd om er toch een beroep op te doen.
                Het probleem dat ik daarmee heb is dat iets wat ik nu doe, en legaal is, ineens over een paar jaar niet meer legaal is zonder dat de wet gewijzigd is. Dat de mensen en de maatschappij om mij heen veranderd zijn, en daardoor iets wat vroeger als normaal beschouwd werd nu als malafide praktijk beschouwd wordt, dat kan gebeuren, maar dan moet dat op z’n minst gereflecteerd worden in de wetgeving. En de wet mag mijns inziens niet zeggen: “dat wat de gemiddelde mens okee vind op dit moment”. Sorry dat gaat er bij mij niet in. Wat is okee, en wat niet? Dát moet in de wet staan.
                Ik bedoelde niet dat die dingen strafbaar moeten zijn die de gemiddelde mens niet doet. Ik bedoelde dat als je dingen doet die de gemiddelde mens niet doet je extra gespitst moet zijn op de intentie van de ander. Wat dat is moet wel zo duidelijk mogelijk uit de wet af te leiden zijn maar juist zonder die wet heel specifiek te maken, want dan is de wet niet algemeen en zal snel verouderen. De wet moet zo algemeen mogelijke argumenten gebruiken.

                Alles wat je met een URL van een website kunt halen is openbaar toegankelijk, maar dat wil niet zeggen dat het ook de bedoeling is dat je er komt. In dat opzicht is het niet anders dan de fysieke wereld, waarin van privé-terrein niet altijd niet duidelijk in hoeverre het openbaar toegankelijk is: ik parkeer vaak ’s nachts op de een parkeerplaats van een supermarkt die alleen ‘voor klanten’ is: ik ben klant, ze treden er niet tegen op, er staat niet dat ik alleen voor een bezoek aan de supermarkt mag parkeren, ze willen waarschijnlijk klanten lokken met hun parkeerruimte, kortom het is een grijs gebied. Ik denk dat die analogie heel aardig opgaat voor webspace: ook daar is het niet altijd duidelijk wanneer een pagina of site bedoeld is voor de openbaarheid.

                De wet definieert computervredebreuk als ‘binnendringen’. Dat woord betekent volgens mij dat 1) je daarna ‘binnen’ bent, dwz. op een niet voor openbaarheid bedoeld terrein en 2) er ‘drang’ bij te pas komt, dwz. je a) weet dat die ruimte niet openbaar is en b) er bewust moeite voor doet om er te komen. Als ik bijvoorbeeld zeg: ‘het water drong het huis binnen’ zeg ik 1) dat dat water daar niet hoort en 2) dat het water dat weet en bewust een poging doet om toch binnen te komen (wat ik dus niet letterlijk bedoel).

                Wat Roelevelds actie rond de Kersttoespraak betreft kun je beide punten betwisten.

                Punt 1: drong Roeleveld ‘binnen’?

                Als die Kersttoespraak onbeschermd op de server staat, zelfs met een voorspelbare URL, kun je normaal gesproken aannemen dat hij is vrijgegeven voor publicatie. Maar veel mensen, ook mensen die spullen op websites zetten, denken er anders over en menen dat een pagina pas is gepubliceerd als ze er een link naartoe gemaakt hebben vanuit andere gepubliceerde pagina’s, of ze menen zelfs dat je alleen via zo’n link naar de pagina toe mag gaan – dat het niet alleen de pagina is die wordt gepubliceerd maar de pagina met het pad ernaartoe. Ik heb dit altijd een fundamentele misvatting gevonden, maar deze discussie is al zo oud als het web zelf, dus we mogen die opvatting niet zomaar als zonderling aan de kant schuiven, net zo min als de politie een supermarktmedewerker die voor mijn nachtelijk geparkeerde auto een bon wil met als argument dat ik er achterom naartoe ben gereden zondermeer kan zeggen dat dat een kulargument is. Roeleveld kon dus uit het feit dat de Kersttoespraak op de voor hem verwachte plek te lezen was m.i. niet zondermeer afleiden dat hij voor de openbaarheid bestemd was. Maar omgekeerd kun je zeker niet afleiden dat omdat Roeleveld een weg gebruikte die niet iedereen zou gebruiken hij dus op niet-openbaar terrein was.

                De wet computervredebreuk moet dit dus openlaten! Waar het hier om gaat is dat Roeleveld om een volkomen andere reden, namelijk het feit dat de toespraak nog niet was uitgesproken, kon aannemen dat de tekst nog niet voor de openbaarheid bedoeld was, en dat moet je bij de beoordeling gewoon als argument kunnen gebruiken.

                Punt 2: ‘drong’ Roeleveld binnen?

                Het veranderen van URLs is voor mij en veel anderen routinematige praktijk bij het websurfen. De ontsluiting van materiaal via weblinks en zoekmiddelen is vaak gewoon erg krakkemikkig. De website van mijn werkgever bijvoorbeeld benader ik vrijwel alleen via Google, omdat de dingen die ik er zoek meestal niet of moeilijk via navigatie vanaf de hoofdpagina te vinden zijn. Maar Google vindt ook lang niet alles, en hanmlatig wijzigen van URls is een ander middel dat ik gebruik. Het lijkt me weinig discutabel dat in het algemeen er veel materiaal op websites staat dat wel degelijk voor de openbaarheid bedoeld is maar niet of slecht via de door de websitemaker gegeven links of zoekfaciliteiten te vinden is.

                Je kunt het gebruik van handmatige URL-manipulatie dus zeker niet categorisch als ‘drang’ beschouwen, hooguit als ‘zachte aandrang’: het wordt vaak gebruikt om pagina’s te vinden die openbaar zijn of waarvan de manipuleerder in elk geval niet veronderstelt dat ze dat niet zijn, en er is in zulke gevallen ook geen sprake van extra moeite (het wordt juist gedaan om moeite te besparen). URL-manipulatie valt in elk geval niet onder de specifieke middelen die de wet (niet-uitputtend) als voorbeelden van zulke ‘drang’ geeft:

                a. het is geen doorbreken van een beveiliging, b. het is geen technische ingreep, want een ingreep is volgens mij een handeling die de werking van een systeem verandert, en van zo’n verandering is geen sprake; c. een geraden URL is niet vals, dus geen vals signaal of valse sleutel; d. het is geen aannemen van een valse hoedanigheid.

                Samenvattend geef ik Arnoud geen gelijk dat het ophalen van de Kersttoespraak strafbaar was: Roeleveld kwam daarmee weliswaar ‘binnen’ (niet omdat de wet dat aantoont, want dat doet de wet niet en dat is precies zoals het hoort) maar omdat hij niet zo’n sterke ‘drang’ gebruikte als de wet lijkt te bedoelen: ten eerste is het niet duidelijk of hij zich realiseerde dat de tekst nog niet voor openbaar gebryuik bedoeld was, en ten tweede is URL-manipulatie in het algemeen niet als ‘drang’ te beschouwen.

        2. Duidelijk is mij inmiddels dat intentie eigenlijk het doorslaggevende argument is. Het probleem is dat mensen blijkbaar in het handmatig aanpassen van URLs een intentie zien die je er niet uit kan afleiden. Vervolgens wordt gerefereerd aan doorsnee internet gebruikers – een nietszeggende groep.

          De doorsnee gebruiker van 10 jaar terug weet een hoop meer van het internet en de techniek af dan de doorsnee gebruiker nu. De doorsnee gebruiker van 10 jaar geleden kent een nettiquette die helees met de jaren verloren gegaan lijkt. De doorsnee gebruiker van 10 jaar terug is vandaag de dag nog steeds een gebruiker. Als je het doorsnee argument al zou willen gebruiken, moet je kijken naar wat doorsnee is in de periode dat men het internet heeft leren kennen; niet wat nu de doorsnee is. En dan zou je ook nog eens moeten kijken naar de omstandigheden. In 1993 op de universiteit hadden de meeste faculteiten vrije internet toegang. Economische wetenschappen had toegang, maar voornamelijk de Informatica studenten en exacte wetenschappen maakten er echt veel gebruik van. Die laatsten waren bij ons op de universiteit ver in de meerderheid en de doosnee gebruiker was erg technisch onderlegd en maakten gebruik van meer dan alleen e-mail en het www.

          Via het werk van mijn vader had ik zelf echter al internet toegang voordat het world wide web bestond. Het internet begon voor mij met E-mail, Usenet, Gopher en pas daarna het web. Mensen tegenwoordig denken dat internet hetzelfde is als het world wide web :/ Ik denk dat ik ver van de ‘gemiddelde’ internetter ben, moet ik nu bij alles wat ik doe gaan oppassen?.

  38. Er is een punt dat weinig aandacht krijgt: Technische ingreep. Het is duidelijk dat de wetgever bedoeld heeft om daarvoor de lat zeer laag te leggen, maar het gebruik van deze terminologie impliceert dat er een onderscheid is tussen technische ingreep en niet technische ingreep.

    Een, voor mij, redelijke scheidslijn is of er enige (zeer beperkte) technische kennis nodig is voor de mogelijke computervredebreuk (Giegeltest, web servers vallen onder computervredebreuk, ongeacht het protocol). SQL injectie, ?prijs=0.01, buffer overflows zijn technische ingrepen. Het raden van een GUID niet, maar zodra dit gebeurd op basis van technische kennis van bijvoorbeeld de generator (of een geautomatiseerd werk dat bruteforced) dan is daar meer dan minieme technische kennis voor nodig.

    Hoe zit het dan bij URL manipulatie. Het verwijderen van elementen uit een URL is waarschijnlijk geen technische ingreep, net als voor de hand liggende substituties (2012 voor 2011, december/dec voor november/nov). Een volgnummer, zeker in het geval van de url van de video is echter een technisch getal, dat zeker bij een niet continue sequentie (en een url die normaal gesproken geembed is) al snel enige technische kennis vereist.

    1. Dat is een hele creatieve insteek. Krijg je wel meteen de discussie “hoe technisch is technisch” maar dat is wel in te vullen. Als iedereen het kan, dan is het geen binnendringen. Hmm.

      Een niet-technische ingreep zou wellicht social engineering kunnen zijn: Goedemiddag, u spreekt met de afdeling kwaliteitscontrole, ik wilde even nagaan of die URL die we morgen gaan publiceren geen per ongeluk aanstootgevende lettercombinaties gebruiken. U begrijpt dat Hare Majesteit niet blij wordt van bijvoorbeeld de lettercode “pvv” in de URL. Dus leest u ‘m even voor?

  39. Blijft een interessante discussie, met dat intentie en zo.

    Resultaat is nu wel dat ik bang geworden ben om op de (voor mij) normale manier te surfen. Normaal is voor mij via url-manipulatie. Zo surf ik al meer dan vijftien jaar. Gewoon gokken op bedrijfsnaam, of datum ergens achter plakken of zo. En voor internet surfte ik ook op die manier over teletekst: gewoon bij 100 beginnen en iedere keer op de “volgende pagina”-knop op de afstandsbediening. Al heette dat toen natuurlijk nog geen surfen, het was eigenlijk wel hetzelfde. Maar wat moet ik als mijn IP in een log opduikt en ik ineens “brein-achtige” roofdieren achter me aan krijg? Hoe bewijs ik dan intentie? Stiekem geloof ik niet echt in deze mogelijkheid, maar als ik zo op jouw blog kijk, en op ars technica en techdirt, kan tegenwoordig echt alles.

    1. Jouw IP duikt ook in logs op als je links volgt. Voor de log niet makkelijk te onderscheiden of jij op een link geklikt hebt of gewoon de URL hebt ingetypt, dus maak je wat dat betreft geen zorgen. @Paul: Het raden van een GUID is niet zo makkelijk zonder technische kennis, en ook niet met. Dan is een volgnummer raden zonder technische kennis nog makkelijker te beargumenteren. Maar verder ben ik het wel eens met je verhaal.

      1. Jouw IP duikt ook in logs op als je links volgt. Voor de log niet makkelijk te onderscheiden of jij op een link geklikt hebt of gewoon de URL hebt ingetypt, dus maak je wat dat betreft geen zorgen.
        Mwoh. De meeste logs bevatten ook HTTPREFERER (sic). Nee, niet 100% betrouwbaar, dat klopt. Daarnaast bevatten een hoop links tegenwoordig al die analytics utmsource rommel en dergelijke, en die typt echt niemand in.

        De meeste URL manipulatie vindt juist niet plaats met de hand maar met tooltjes. En dat jij 10 URL’s per seconde kan typen, dat gelooft niemand.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.