Amerikaan krijgt 12.000 dollar onterechte boetes door kenteken met tekst 'null'

Een Amerikaanse beveiligingsonderzoeker vroeg eind 2016 een kenteken voor zijn auto aan met alleen de tekst 'null'. Dat leek hem een leuk idee dat wellicht boetes kon voorkomen, maar het tegendeel bleek het geval. Hij kreeg boetes van in totaal zo'n 12.000 dollar.

Joseph Tartaro maakte gebruik van de mogelijkheid om zelf een suggestie in te dienen voor het kenteken, en kwam na ideeën als 'segfault' en 'null pointer' uiteindelijk tot 'null', schrijft Wired op basis van zijn uiteenzetting op Defcon. Dat leek hem wel leuk, omdat zijn auto naast die van zijn vrouw kwam te staan en die auto kreeg een kenteken met alleen de tekst 'void'.

Door zijn achtergrond wist Tartaro dat 'null' in veel programmeertalen in feite staat voor een lege waarde en dus in feite overeenkomt met een leegte, ofwel 'void' in het Engels. De beveiligingsonderzoeker gaf aan dat hij in eerste instantie hoopte dat zijn kenteken zou voorkomen dat er boetes op zijn deurmat zouden belanden, omdat de overtreding wellicht in de database van de overheid niet zou worden herkend en verwerkt door de 'null'-aanduiding. Later gaf hij echter aan dat grappenmakerij niet zijn belangrijkste intentie was; naar eigen zeggen was hij verbaasd dat de staat Californië het toestond dat hij 'null' mocht registreren.

Na de registratie eind 2016 gebeurde er weinig in 2017, al bleek bij de herregistratie in 2017 dat de tekst 'null' niet langer werd geaccepteerd en dat de website erdoor plat ging. Zijn kenteken en voertuigidentificatienummer zouden ongeldig zijn, maar hij kon via een referentienummer alsnog zijn null-kenteken vernieuwen. Gaandeweg stroomden de boetes echter binnen, onder meer op basis van overtredingen op plekken waar Tartaro nog nooit geweest was. Er rolden zelfs boetes binnen uit 2014, ruim voordat hij zijn kentekenplaat met de tekst 'null' voerde.

Hij betaalde zijn eerste boete zonder erbij na te denken; dat betrof een boete voor het niet hebben van de juiste registratiesticker op het kenteken. Waarschijnlijk leidde die betaling ertoe dat de boetedatabase de tekst 'null' met zijn persoonlijke informatie associeerde. Dat had een ongewenst gevolg: elke keer dat een agent bij een boete vergat om het kenteken in te voeren, werd die boete automatisch naar Tartaro gestuurd.

Na pogingen om de fouten te herstellen, werd het boetebedrag teruggebracht tot 6000 dollar en inmiddels zouden alle boetes zijn verdwenen en resteert alleen nog de verplichting om zijn auto opnieuw te registreren voor een bedrag van 140 dollar. Tartaro zegt ondanks de boete-ellende toch vast te houden aan 'null' op zijn kenteken, omdat er volgens hem nog steeds boetes aan zijn naam zijn gekoppeld. Het wijzigen van het kenteken zou het oplossen van het probleem volgens hem alleen maar lastiger maken.

Lees meer

IT-banen

Reacties (133)

i7x
14 augustus 2019 14:48

Hij zou DROP TABLE moeten registreren, doet hij vast veel mensen een pleziertje mee

Emgeebee
@i7x • 14 augustus 2019 22:30

' AND 0 = 1 zou ook een leuke zijn. Nooit meer boetes voor iedereen, maar het systeem blijft werken.

HenkEisDS
14 augustus 2019 12:59

Toch wel gek dat er blijkbaar geen verschil zit in == null en == ‘null’ bij de politiesystemen. De laatste is namelijk een string, de eerste niet.

Iannis
@HenkEisDS • 14 augustus 2019 13:10

In de meeste programmeertalen Javascript geen enkele programmeertaal

geldt:

null == "null" is true
null === "null" is false

De == operator checkt alleen of de beide gegevens de zelfde waarde hebben en de === checkt ook of beide gegevens van de zelfde soort zijn: dus bijvoorbeeld beide een string.

Hun systeem gebruikt dus blijkbaar ergens == ipv ===, wat er dus voor heeft gezorgd dat deze meneer bergen aan boetes heeft ontvangen.

Toch wel grappig dat het missen van één character in hun code er voor gezorgd heeft dat deze meneer onterecht zoveel boetes heeft gekregen

[Reactie gewijzigd door Iannis op 14 augustus 2019 13:35]

Echt niet.
@Iannis • 14 augustus 2019 13:16

In de meeste programmeertalen javascript geldt:

null == "null" is true
null === "null" is false

FTFY.

Edit: @:murb: heeft gelijk, zelfs in JS niet.

[Reactie gewijzigd door Echt niet. op 14 augustus 2019 13:53]

:murb:

@Echt niet. • 14 augustus 2019 13:35

Ook javascript geeft gewoon false op null == "null"

defixje
@Echt niet. • 14 augustus 2019 18:41

Ook in PHP is het gewoon false

Iannis
@Echt niet. • 14 augustus 2019 13:17

Ook in Java en C dacht ik
Edit: C dus blijkbaar niet

[Reactie gewijzigd door Iannis op 14 augustus 2019 13:17]

FreezeXJ
@Iannis • 14 augustus 2019 13:28

In java ook echt niet... "null" is een string van 4 tekens, en die is nooit gelijk aan null. Daarnaast bestaat === niet in Java, dat is een misbaksel om onder verkeerd gebouwde == uit te komen.

dfijma
@FreezeXJ • 14 augustus 2019 13:48

Inderdaad. Maar stel dat "ze" hun kenteken-objecten te snel naar strings omzetten, dan kan een slechte (Java-)programmeur toch wel in de situatie geraken dat "null" en null gelijk lijken:

String x = null;
assert("null".equals(String.format("%s", x)));

itcouldbeanyone
@dfijma • 14 augustus 2019 19:33

Of via het try{} catch verhaal,
Gewoon je stringt boetebetaller naar “null” zetten

Iannis
@FreezeXJ • 14 augustus 2019 13:31

Ik had het dus fout haha. Ik gebruik zelf bijna alleen maar javascript als programmeertaal dus vandaar...

bwerg
@Iannis • 14 augustus 2019 13:32

Ook niet in Java. Een string is een object en kan dus nooit een null-reference zijn. En nou heb ik geen javascript-ervaring maar als ik null=="null" in een online REPL gooi zegt die (gelukkig) ook 'false'.

Elke taal die dat wel vindt dient sowieso niet gebruikt te worden, als je enige waarde hecht aan correctheid van je programma's.

blorf

@bwerg • 15 augustus 2019 15:38

Het zou volgens mij een taal moeten zijn die niet aan verschillende types doet, wel verschil maakt tussen toewijzing en conditiestelling en dan weer niet moeilijk doet over een identifier-naam die eigenlijk gereserveerd zou moeten zijn als de term in de taal ook een betekenis heeft. Hm...

PierreDuc
@Iannis • 14 augustus 2019 13:34

null == 'null' is false, ook in javascript. Er is geen enkele taal waar dit true is. Alleen als je in javascript JSON.stringify(null) doet, krijg je 'null'.

Martinspire
@PierreDuc • 14 augustus 2019 14:11

Ergens een waarde inlezen of versturen en er quotes omheen plakken ook. Genoeg houtje-touwtje systemen waar dat gebeurt. Als het maar door genoeg systemen heen gaat en er inadequaat getest is, krijg je dit.

Stoney3K

Verenigde staten
Economie en maatschappij

@Martinspire • 14 augustus 2019 14:36

Dat is de andere richting op, dus een string maken van null levert inderdaad "null" op.

Maar als je vanuit een willlekeurige string naar iets anders wil, dan moet "null" als string gewoon de string "null" opleveren (een string met 4 letters dus) en niet het object <null> (niets). Dat gebeurt alleen als je expliciet aangeeft dat "null" een gereserveerde benaming is voor een <null>-object.

Een string is namelijk niets anders dan een verzameling aan bytes die niet spontaan in iets anders verandert als je er andere tekst in stopt, tenzij je hem ergens mee vergelijkt wat een bewust gereserveerd keyword is.

En als "null" een keyword was in hun database dan waren ze wel heel stom bezig om zijn kenteken te laten registreren.

Martinspire
@Stoney3K • 14 augustus 2019 14:56

Mja maar als je dus met 1 of andere taal een JSON bericht bv stuurt naar een service en je gebruikt voor de waarde van het kenteken geforceerd ' " + value + " ' (of iets dergelijks) dan gaat het dus van waarde null naar "null" en zal je dus altijd die opslaan. Genoeg developers die hun eigen JSON string in elkaar zetten op een dergelijke manier. Als er nergens een check op null, undefined of '' zit, dan krijg je dit al snel.

Een JSON of XML bericht is in principe een lange string waar een service alle waardes uit haalt en als daar iets verkeerd in/uit wordt gehaald dan maakt het niet uit hoe een taal een null waarde opslaat.

[Reactie gewijzigd door Martinspire op 14 augustus 2019 14:58]

Stoney3K

Verenigde staten
Economie en maatschappij

@Martinspire • 14 augustus 2019 15:29

Als je uit een JSON bericht de string "null" haalt in plaats van bijvoorbeel de string "31-BX-HF" dan blijft het natuurlijk gewoon een string en wordt het nooit de identifier null.

De fout gebeurt niet bij de applicatie die het bericht uitpoept (want die poept correct de string "null" uit die op zijn kenteken staat) maar bij de applicatie die het weer inleest en blijkbaar vindt dat de tekst "null" een keyword is voor null als identifier. En dat gebeurt echt alleen als je in de code een regel bouwt die zegt dat als de tekst "null" er in wordt gestopt, er een null-value uit moet komen. Dat betekent dat de tekst "null" al gereserveerd zou moeten zijn als ongeldig.

Andersom zou het fout kunnen gaan als 'geen kenteken' verandert in null, en dan één of andere app inderdaad null gaat verzenden als de tekst "null". Maar het correcte gedrag zou daar moeten zijn: Geen kenteken is gewoon ook geen boete verzenden.

[Reactie gewijzigd door Stoney3K op 14 augustus 2019 15:33]

laibalion
@Iannis • 14 augustus 2019 13:22

Ik ben niet zeker wat jij als 'de meeste programmeertalen' beschouwd, maar zowel c#, c, c++, java,... Laten een === operator niet toe.
Javascript heeft wel een === operator, maar dat durf ik bezwaarlijk en programmeertaal noemen.

veltnet
@laibalion • 14 augustus 2019 15:26

Je hoeft het geen programmeertaal te noemen maar het is er wel één. Alle talen waarin je kunt programmeren zijn programmeertalen. Het maakt niet uit hoe lelijk ze zijn.

bwerg
@Iannis • 14 augustus 2019 13:15

In de meeste programmeertalen

Euh, niet in alle sterk getypeerde talen, en dat zijn de meeste programmeertalen wel. Ook in de meeste zwak getypeerde talen als C(++) is dit niet zo (en waarom zou het ook, want null == "null" slaat nergens op).

[Reactie gewijzigd door bwerg op 14 augustus 2019 13:20]

blorf

@bwerg • 15 augustus 2019 19:07

#include <stdio.h>
int main()
{
int null;

null = 'null';
printf ("null: %i\n", null);
if ( null == 'null' ) printf ("true\n");
}

casberrypi

@Iannis • 14 augustus 2019 13:20

Ik ken geen enkele programmeertaal waar "null" == null true oplevert. Zelfs PHP met al zijn gekke edgecases niet.

https://3v4l.org/UJpoR

COW_Koetje
@Iannis • 14 augustus 2019 13:48

Ben benieuwd hoe het werkt in cobol of assembly, de talen die meestal in hele oude programma's nog wordt gebruikt bij politie en andere overheids organisaties.
Kans is ook groot dat het gewoon een excel 95 macro is, die na een export vanuit een database wordt gerunt.
En ik zou nog gekkere dingen kunnen bedenken die ik in de praktijk gezien heb.

g4wx3
@Iannis • 14 augustus 2019 13:49

Lijkt me broodje aap, allemaal. Type conversie is ook helemaal niet zo want (indien ondersteund) zal 0, "",'',{},[], .. worden omgezet naar false en eender wat anders zal dus worden omgezet naar true, zoals 'null', 1,
Waar kan het dan misgaan? om te beginnen zal een beetje programmeur NULL niet toestaan in dit veld.
_{qeury voor ingeven boete:}
^{insert into overtredingen (..) value('$nummerplaat','$overtreding','$klasse','$tijdstip')}
_{quey listing voor opsturen boetes (alle van vorige dag)}
^{select * from overtredingen where CONVERT( $tijd, getdate()); = CONVERT(date, DATEADD( day,-1 , CURRENT_TIMESTAMP()) );}

Just my two cents \0

[Reactie gewijzigd door g4wx3 op 15 augustus 2019 05:14]

jhaan1979
@g4wx3 • 14 augustus 2019 17:52

In Python:

~ > str(None)
'None'

Tweaker
@g4wx3 • 14 augustus 2019 17:56

Een beetje in de geest van de SQL 'drop database' urban myth...

SuperDre
@Iannis • 14 augustus 2019 13:54

=== komt maar bij heel weinig programmeertalen voor, ik zag het pas vorige week voor het eerst toen ik eens naar javascript ging kijken (ja ja, altijd in andere talen gewerkt).

FlaffTweakr
@SuperDre • 14 augustus 2019 17:19

Offtopic: Tip indien je er professioneel in begint te werken: installeer nvm en gebruik 'es' ipv 'js' om recentere resultaten te verkrijgen.

Ontopic: Zo heb je in python ook een onderscheid tussen '==' en 'is'. Javascript is heus niet de enige die het verwarrend doet op dit gebied. In ruby evalueert een 0 integer naar true. Al die extra checks in m'n code waren plots niet meer nodig.. (maar had ze wel al geschreven)

[Reactie gewijzigd door FlaffTweakr op 14 augustus 2019 17:23]

SuperDre
@FlaffTweakr • 14 augustus 2019 22:48

een 0 integer naar true? dat is leip en slaat werkelijk helemaal nergens op..

jhaan1979
@Iannis • 14 augustus 2019 17:51

Wellicht dat het resultaat altijd naar een string gecast werd om geen type errors te krijgen tussen null en 'kenteken'.

n8n
@jhaan1979 • 14 augustus 2019 20:28

Dan is een lege string logischer.

Denni

@Iannis • 15 augustus 2019 17:28

De database zou wel als default value NULL kunnen hebben. Ik kan me voorstellen dat als je dat in veel talen parsed als string dat je wel iets dergelijks krijgt.

SBTweaker
@HenkEisDS • 14 augustus 2019 13:11

ligt volledig aan de programmeertaal die je gebruikt wat de uitkomst is.

[Reactie gewijzigd door SBTweaker op 14 augustus 2019 13:11]

freaxje
@SBTweaker • 14 augustus 2019 13:55

Let me fix that for you: Aan de programmeurs.

3raser

@HenkEisDS • 14 augustus 2019 13:47

Toch wel gek dat politieagenten bij het invoeren van een verkeersboete helemaal geen kenteken op hoeven geven.

hdullink
@3raser • 14 augustus 2019 14:49

In de VS rijden heel wat (vooral nieuwe) auto's rond zonder kentekenplaten. Die moeten nog gemaakt worden. Duurt daar wat langer.

WhiteDog
@hdullink • 14 augustus 2019 16:50

Steve Jobs had elke 6 maanden een nieuwe Mercedes omdat er na 6 maanden een nummerplaat op moest

Leesvoer

hdullink
@HenkEisDS • 14 augustus 2019 14:47

Het ligt vaker aan de manier van overdracht van gegevens. Bijv. XML, welke van de drie voorbeelden is de juiste manier om een lege (null-) waarde door te geven?

<data>
...
<kenteken>null</kenteken>
</data>

<data>
...
<kenteken></kenteken>
</data>

<data>
...
</data>

jrswgtr

@hdullink • 14 augustus 2019 18:35

De onderste twee zijn correct.

Er is nog een mogelijkheid om extra duidelijk te zijn:

<data>
...
<kenteken xsi:nil="true" />
</data>

Bron: https://www.w3.org/TR/xmlschema-1/#xsi_nil

[Reactie gewijzigd door jrswgtr op 14 augustus 2019 18:38]

hdullink
@jrswgtr • 14 augustus 2019 19:28

Ja, dat kan ook.
Mijn optie twee kan ook geïnterpreteerd worden als lege string, in sommige gevallen nét weer anders dan null of undefined.

johnkeates
@HenkEisDS • 14 augustus 2019 13:10

Helaas is dat niet iets wat de overheid in de SRS opschrijft dus gaat het na 10 lagen aan onderaannemers gewoon naar een offshoring software bedrijf in Bangladesh waar ze het niet zo nauw nemen met software engineering

mphilipp
@HenkEisDS • 14 augustus 2019 13:28

En aangezien een kenteken altijd een string is, wordt het dus nog gekker. Ik ben benieuwd wat voor vaag programma daar zo van over zijn nek gaat.

Maar goed, het is komkommertijd, dus de redactionele controleurs zijn ook op vakantie, dus dan krijg je vaak berichten waarvan je wenkbrouwen fronsen en je met je klomp kunt aanvoelen dat er eea ontbreekt of fout is.

KopjeThee
@HenkEisDS • 14 augustus 2019 18:26

Hij zit natuurlijk bewust een beetje op de grens. Maar het zou de overheid wel sieren als ze toegeven dat het om een (kleine) bug gaat, dat ze die gaan herstellen, dat ze deze meneer niet nodeloos meer gaan lastigvallen met boetes en dat ze deze meneer excuses aanbieden voor het ongemak (beter nog een schadevergoeding voor de verloren tijd).

Ze moeten hem in feite bedanken voor het opsporen van de bug, voordat iemand het kenteken "drop database" registreert.

[Reactie gewijzigd door KopjeThee op 14 augustus 2019 18:28]

jj71
14 augustus 2019 13:00

Er zijn in de VS ook mensen met de achternaam Null, en dat kan heel lastig zijn of juist niet...

kozue
@jj71 • 14 augustus 2019 13:37

Ik blijf het vreemde vergezochte verhalen vinden.

Ik weet niet in welke taal die systemen geschreven zijn maar in mysql zou het nooit kunnen. Als je daar geen quotes om je input heen zet, wordt het behandeld als naam van een veld uit de tabel en krijg je een syntax error. Je móet dus quotes gebruiken voor een string als input. En dan werkt “null” ineens prima want het is gewoon een string als alle anderen, geen speciale waarde.

Net als invoervelden in zowat iedere programmeertaal. Een invoerveld is altijd een string (tenzij je dit expliciet omzet naar iets anders), en dan werkt “null” ook prima. Ik denk dat als ik de string “null” als null-waarde zou willen behandelen in m’n code, dat ik heel goed m’n best moet doen om het te verpesten (of er expliciet een bug voor inbouwen a la: input == “null” ? null : input).

Woy
@kozue • 14 augustus 2019 14:40

Een van de punten waarop het wel mis kan gaan is als bij de invoer ergens een NULL waarde omgezet wordt naar een string als "null" ( probeer bij javascript maar eens var x = null + ''; ), op die manier wordt de waarde dus daadwerkelijk als string "null" behandeld. Natuurlijk is dat een fout, maar wel een die regelmatig voor komt.

djwice

@Woy • 14 augustus 2019 17:03

Export naar tekst file, escape string niet nodig voor kenteken, en dan weer importeren, systeem ziet null dan niet als string...

Bedrijven en overheden die 20 jaar of langer IT doen, hebben vaak dit soort data export/import tussen (oude en nieiwere) systemen.

[Reactie gewijzigd door djwice op 14 augustus 2019 17:06]

diyoo
@kozue • 14 augustus 2019 15:26

Ik kan me zo voorstellen dat de agenten een app hebben draaien op hun apparaten die ze in het veld gebruiken, waarbij deze app de data pas bij de eerstvolgende gelegenheid upload naar de servers van waaruit de boetes worden uitgedeeld. Stel deze app wordt geschreven door partij A. De systemen die de boete afhandeling doet wordt geschreven door partij B. Stel nu dat de overheid tegen partij A heeft gezegd: "kentekens hoeven niet te worden ingevuld omdat de agent ook een boete uit kan delen aan een persoon". Door een slordigheid stuurt app van partij A in plaats van een lege kentekenstring een string door met de waarde "null" omdat de taal/programmeur een null referentie wegschrijft als "null" string. Partij B is zich nergens van bewust als men een "null" string ontvangt, aangezien dit een geldig kenteken is en maakt vrolijk een boete aan voor de eigenaar van het kenteken. Enige wat je dan nog vreemd kunt vinden is dat bekeuringen met zowel persoonsgegevens en kenteken op boetes niet overeenkomen. Wellicht dat daarom de boete in eerste instantie van 12K terug werd gebracht naar 6K. Ik probeer hiermee niet goed te praten dat deze situatie is ontstaan, maar wil wel aangeven dat iets vergezocht lijkt in de praktijk door samenloop van omstandigheden (verschillende partijen, onduidelijke of incomplete requirements, etc..) toch voor kan komen.

Xirt
@jj71 • 14 augustus 2019 13:21

Het eerste is wel een gevalletje slecht programmeerwerk in mijn ogen: het gaat hier om de invoer van een String (vier letters) en dat is iets anders dan een nullwaarde (lijkt meer op een lege String en minder op vier letters). Het tweede geval eigenlijk ook, maar hierbij wordt er wel heel erg misbruik gemaakt van de situatie. Is het bedreigen / misbruiken op deze manier niet strafbaar (e.g. een baliemedewerker bedreigen terwijl hij / zij niets aan de situatie kan doen; en dat kan zelfs ook nog bewezen worden)?

[Reactie gewijzigd door Xirt op 14 augustus 2019 13:23]

SuperDre
@jj71 • 14 augustus 2019 13:56

Die laatste is gewoon strafbaar, en zou de man gewoon voor vervolgt moeten worden.

nst6ldr
@jj71 • 14 augustus 2019 13:10

Dat tweede verhaal vind ik echt niet om aan te zien, wat een krenterige lul met vingers is die vent. Die naamsverandering moet je zelf weten, maar dat als hulpmiddel gebruiken om bewust receptionisten en telefonisten onder druk zetten om zo gratis diensten los te peuteren. Bah

Ventieldopje
14 augustus 2019 12:59

What's next, SQL injectie via je kenteken?

Johan9711

@Ventieldopje • 14 augustus 2019 13:07

En dan op zo'n manier dat je een database uitdraai krijgt op je boete formulier zeker?

Ventieldopje
@Johan9711 • 14 augustus 2019 13:12

Mwa stiekem dat ik geld terug krijg

trogdor
@Ventieldopje • 14 augustus 2019 13:10

' and false; --

Q
@Ventieldopje • 14 augustus 2019 14:22

Ik vind SQL injectie via barcodes en QR-codes wel erg leuk eigenlijk.

https://www.youtube.com/watch?v=Wy79TLkqArg

DigitalExorcist

@Ventieldopje • 14 augustus 2019 13:02

SELECT Fine from *
DROP_TABLE

Youri219
@Ventieldopje • 14 augustus 2019 13:11

Je bedoelt zoals hier?

https://www.slideshare.ne...k-sql-injection-exploited

Afbeelding nummer 7.

Jism

Auto

@Ventieldopje • 14 augustus 2019 16:38

Dat probeerde ze al zonder echt succes.

Thirler
14 augustus 2019 12:56

XKCD heeft dit al voorspeld: https://xkcd.com/1105/

Niet met Bobby tables maar onverwachte nadelen bij 'hacks' in kentekens

.oisyn
@Thirler • 14 augustus 2019 13:21

Dit dus

faraga
@Thirler • 14 augustus 2019 15:42

Ik ben een dergelijk kenteken een keer in Melbourne tegengekomen.

hendrik_v
@Thirler • 14 augustus 2019 13:36

https://xkcd.com/327/ deze

DeArmeStudent
14 augustus 2019 13:01

Toch verbazingwekkend om te lezen dat een hele website platgaat als er iets vreemds ingevuld wordt. Wel is bekend dat de Amerikaanse overheid nog met hele oude ict software werkt.

Moosenl
@DeArmeStudent • 14 augustus 2019 13:05

Heeft alles te maken met de programmeur van die site en niet het land.

NullCrayfish
@Moosenl • 14 augustus 2019 13:10

Die zal raar hebben staan kijken toen hij deze feature in het FO tegenkwam. Maar ja, klant is koning

SuperDre
@Moosenl • 14 augustus 2019 14:02

tja, en met het systeem natuurlijk... Je hebt geen idee wat er precies bedoelt wordt met 'de site plat gaat', en je hebt geen idee hoe oud het systeem is dat achterliggend ligt. Veel achterliggende systemen zijn nog heel oud maar met een connectie naar een nieuw systeem, hoop programmeurs van nu weten niet wat de 'problemen' (ofwel wat toen gewoon normaal was) kunnen zijn van die oude systemen. En wat NU bekend is als domme fouten/not done (bv SQL injection) moet je niet vergeten dat dat vroeger niet bekend was. Moet je namelijk eerlijk bekennen dat begin jaren 90 op mijn opleiding (HI) SQL injection niet aan de orde was bij de SQL lessen, dus tekst ging gewoon rechtstreeks de database in... En vergeet niet, security is een vak apart.. Wat vandaag nog onbekend is als probleem, kan over enkele jaren als een domme fout gezien worden..

RoestVrijStaal
@Moosenl • 14 augustus 2019 14:21

Heeft alles te maken met de programmeur van die site en niet het land.

Nou, het land moet de programmeur betalen èn geeft de opdracht aan de programmeur.

Als er te weinig is gebudgetteerd voor te testen of als het niet in de opdracht stond, dan zit het land meer fout dan de programmeur.

monkel
14 augustus 2019 13:01

Als hij een cursus testen had gevolgd, had hij misschien geleerd dat je niet in productie moet testen (of experimenteren) En al helemaal niet aan een systeem waar je zelf geen invloed op hebt

The Zep Man

Verenigde staten

@monkel • 14 augustus 2019 13:17

Als zij een cursus slimme keuzes maken had gevolgd, had zij misschien geleerd dat ze niet in het donker door steegjes moet lopen, en al helemaal niet in een kort rokje.

De schuld hiervan ligt niet bij Bobby Tables als slachtoffer, maar bij de partij die verantwoordelijk is voor het systeem dat in- en uitvoervalidatie mist.

In dit geval heeft de eigenaar van het kenteken geen misbruik gemaakt van het systeem. Hem valt niets te verwijten. Daarom zijn alle boetes ook ingetrokken en mag hij alsnog het kenteken blijven gebruiken.

Kan je niet tegen mensen die processen verstoren? Geef dan geen ruimte om processen te verstoren.

[Reactie gewijzigd door The Zep Man op 14 augustus 2019 13:21]

monkel
@The Zep Man • 14 augustus 2019 13:24

Hij heeft dit moedwillig aangepast om te kijken hoe het systeem er op zou reageren (oftewel, hij was aan het testen). Als je dat perse wil doen, dan doe je dat in een test-omgeving of je doet eerst onderzoek hoe het systeem omgaat met de waarde null

Niosus
@monkel • 14 augustus 2019 17:26

Hij heeft een custom nummerplaat aangemaakt. Als die net goed ondersteund wordt, hadden ze die nooit mogen uitgeven. Dit kan je echt niet op de gebruiker steken. Regel nummer 1 van security is dat je nooit input van de gebruiker mag vertrouwen.

Verder is het ook helemaal niet oké dat agenten een boete kunnen ingeven zonder nummerplaat. Dat is weer een teken dat de input van de gebruiker niet goed gecontroleerd wordt. In een degelijk systeem zou de agent ofwel verplicht zijn van een geldige nummerplaat in te geven, ofwel expliciet moeten aanduiden dat er geen nummerplaat zichtbaar is. Zomaar NULL in je database steken zonder goed over de gevolgen na te denken is ook gewoon dom.

Alex3
@Niosus • 14 augustus 2019 18:14

Je moet ook mensen zonder auto kunnen beboeten.

MicGlou
@The Zep Man • 14 augustus 2019 13:40

Dat de systemen klaarblijkelijk niet op orde zijn is uiteraard een probleem, maar dat er hier bewust een poging tot misbruik is gedaan kan niet worden ontkent... sterker nog, het is toegegeven. De gehele intentie van die eigenaar was om zo proberen het systeem te manipuleren en juist geen boetes te krijgen... het had alleen het omgekeerde effect. Daar valt dus echt wel wat over te zeggen, ik zou het geen 'slachtoffer' willen noemen.

-weenie-
14 augustus 2019 12:58

Ik vind het een vreemd bericht, een kenteken zou worden herkent als string "null" niet null/NULL. Het is natuurlijk niet uit te sluiten in case of bad programming...

Cartman!

@-weenie- • 14 augustus 2019 13:06

Dat is dus precies wat hij heeft aangetoond.

Martinspire
@-weenie- • 14 augustus 2019 14:00

Ik gok dat zijn kenteken is opgeslagen als "" en dus altijd als er geen kenteken geregistreerd wordt, deze gekoppeld wordt. Ik gok dat het ergens mis gaat met het opsturen van gegevens van 1 van de formulieren. Vaak ontstaat dit als je bv een JSON of text gaat inlezen mis. Stel er staat ergens null in een formulier, dan wordt dit mogelijk geconverteert van de ene taal naar de andere. Soms hardcoded quotes ergens omheen zetten. Dat er ergens dus iets staat als " + value + " waar de value dan null is...

[Reactie gewijzigd door Martinspire op 14 augustus 2019 14:08]

MrMonkE
@Martinspire • 14 augustus 2019 14:04

Ik zeg dat er keihard NULL in textvelden staat.
Ik hou niet van gokken.

Martinspire
@MrMonkE • 14 augustus 2019 14:09

De default zal wel null zijn die nooit ergens overschreven wordt waarna het vervolgens wordt opgestuurd en er even quotes aan de input of output van de betreffende service worden toegevoegd. Niet zo heel raar maar gewoon slecht getest

MrMonkE
@Martinspire • 14 augustus 2019 14:13

Mwah.. messagebrokers en import/export code is vaak de boosdoener omdat ze NULL niet snappen.
Dan vergeet iemand iets en staat er opeens "null" in databases aan de andere kant in plaats van null.

well0549
@MrMonkE • 14 augustus 2019 18:04

Nou ik zit midden in de message brokers en we snappen null echt wel, meestal zijn het zolderkamer artiesten die b.v. null in een csv Zetten, maar laat ik je vertellen dat middleware prima met een minoccurs 0 kan omgaan

Youri219
14 augustus 2019 13:08

Kwestie van hele slechte software. Deze zou correct onderscheid moeten kunnen maken tussen de tekst "null" en de waarde null (geen waarde).

Echter, bij het aan elkaar plakken van teksten gaat het in de meeste talen eigenlijk fout. In plaats van een fout te rapporteren wordt de lege waarde null vervangen door de tekst "null". Andersom eigenlijk niet. Ik heb nog nooit gezien dat de tekst "null" weer wordt omgezet naar de lege waarde null waar deze man nu stieken op hoopte.

Hoe vrijwel alle programmeertalen hiermee omgaan had deze beveiligingsonderzoeker gewoon moeten weten. Dat de boete software buggy is, dat wist hij natuurlijk niet, maar heeft hij wel op komische wijze aangetoond.

[Reactie gewijzigd door Youri219 op 14 augustus 2019 13:09]

SuperDre
@Youri219 • 14 augustus 2019 14:07

En laat ik het dus wel al vaker gezien hebben, zeker bij imports van CSV data waarbij dus NULL als NULL tekst wordt geexporteerd, en bij import de tekst NULL ook geimporteerd wordt als NULL.
En zeggen dat het slechte software is, is wel erg makkelijk, fouten worden nu eenmaal gemaakt, en soms zijn er zaken waar gewoonweg niet aan gedacht wordt immers heeft niet iedereen de fantasy om elke situatie te kunnen bedenken. EN zoals ik hierboven ook al een keertje gezegd heb, wat wij nu weten dat domme fouten zijn, was op het moment van ontwikkelen van die oude systemen mogelijk helemaal niet bekend.
Niet iedereen heeft de beschikking over de uitgebreidste testsuites etc.. Makkelijk om allemaal zo commentaar te geven, maar 'we' maken allemaal wel foutjes, maar dankzij de nieuwste IDE's en testsuites etc worden gelukkig de meeste wel opgevangen..

well0549
@SuperDre • 14 augustus 2019 17:59

En csv waar null in staat is ook heel erg fout. Hoort gewoon niets te staan

SuperDre
@well0549 • 14 augustus 2019 22:48

fout, want niets is een lege string, niet null

well0549
@SuperDre • 14 augustus 2019 22:52

Hangt er natuurlijk helemaal vanaf welke text qualifier je gebruikt

SuperDre
@well0549 • 14 augustus 2019 22:54

En tja, de ene csv is de andere niet, nergens ligt officieel vast hoe een csv opgebouwd moet zijn. Niet alle csv's met tekst hebben strings gequote oid..

ViperXL
14 augustus 2019 13:01

Hoe vet is dit, het pakte anders uit dan dat hij verwachte toen hij het doordacht ivm programmeertalen en "null".
Aan de andere kant ook erg slecht van het kentekensoftware dat deze "waarde" wordt verwerkt.
Ik hoop dat ze het snel oplossen voor hem.

1 2 3 Volgende

Op dit item kan niet meer gereageerd worden.

Amerikaan krijgt 12.000 dollar onterechte boetes door kenteken met tekst 'null'

Lees meer

IT-banen

Reacties (133)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden