Niet ongewoon dat er extra functies in een applicatie zitten. Toegang door code of vergelijkbaar is normaal.

Je zou als journalist die APK eens kunnen bekijken en de code eruit halen. Dan weet je wat erachter zit.

spijkers op laag water zoeken.

Een duidelijke hidden feature. Ik als ontwikkelaar heb deze ook ingebouwd, maar altijd uit de productie (de versie die je uitgeeft) versie gehaald. Misschien kan je de security afdeling van het IT bedrijf waar dit gebouwd is vinden, en die mailen/bellen. Vaak zijn zij hier heel blij mee om te weten dat dit erin zit.

Komt denk vaker voor dan mensen denken. Wenselijk is het niet, want kan een extra attack surface (manier om binnen te komen) zijn voor aanvallers, maar hoeft ook niet altijd te zijn.

Hoop je hiermee wat info te hebben gegeven waar je wat mee kunt.

- HackerJunkie.

Je raad het al, er zit niet voor niks een pincode op. Als je deze krijgt/kraakt, heb je onbedoelt toegang en wordt dat gezien als een hackpoging, net zo goed als het raden van een wachtwoord mail account ook een hackpoging is. Hoe intressant is het om als journalist (als je bewering klopt) hier informatie over te krijgen. Volgens mij is dit een terrein waar je verder niks mee moet doen.

En dan nog iets (bijna vergeten), het is niet aan de gebruiker van de app om te bepalen hoe wenselijk dit is als het verder geen schade aanbrengt. Je kan je afvragen of de gebruiker dan niet gewoon moet stoppen met de app als hij het er niet mee eens is. Ik denk dat je als journalist dit ook kan bedenken, toch ?

Al wordt dergelijke functionaliteit vaak uitgeschakeld in de public releases, meer iets voor in developer versie.

Als ze het een beetje slim aangepakt hebben kan je wel de pincode zien maar wordt de verbinding nog steeds geweigerd omdat het apparaat id en IP niet overeenkomen met de allow aan hun kant. Of ze het slim hebben ingesteld is de vraag.

Het risico is natuurlijk wel dat sommige mensen dan hun eigen pincode van hun mobiele telefooncomputer daar gaan invullen...

Welk risico levert het dan op, behalve kans van 1:9999 dat je het goed gokt (als het al een 4 cijferige code is) ? Beter is natuurlijk wel om in de public releases de functionaliteit simpelweg uit te schakelen.

Dat je pincode dan bekend wordt bij anderen die er misbruik van kunnen maken natuurlijk...
ZUCHT.

Dit lijkt een nogal onrealistisch risico. Het idee dat developers, enkel omdat je je pincode daar invoert, toegang zouden krijgen tot je bankrekening of bankpas is absoluut niet waarschijnlijk. Bovendien, waarom zou je in hemelsnaam je bankpincode daar invoeren? Misschien is het beter om iets realistischer te denken, in plaats van zo dramatisch te reageren.

Serieus? De kans dat iemand je pincode door deze functie achterhaalt is vrijwel nul.

Niet erg plausibel.

1 Je weet de bank niet
2 Je hebt de pas niet
3 Je slaat standaard nooit de inlog pogingen zelf op enkel de status of connectie wel of niet gelukt is. Je hebt voor het eerder genoemde raw webserver logs nodig.
4 Dit soort logs raken vermengt met andere requests en lopen in de miljoenen aan regels code.
5 log rotatie
6 Anderen in dit geval kan hooguit iemand zijn met toegang tot de specifieke server logs die bij efteling werkt of als die specifieke logs zouden lekken.
7 Dit alles is nog zonder salt, hash, encryptie mee te rekenen in de risisco analyse.

Is het slim om het daar in te vullen nee ofc not maar een risico op data lek daar weer van is minimaal.

Lijkt me een prima vraag van een nieuwsgierige medemens.

Volgens mij is er niks mis mee als je de .APK extract en alle code doorneemt om te zien waar die pincode je heenleidt, maar
let op dat je die weg alleen maar mag zien, en niet bewandelen. Vergelijk het maar dat ik als postbode zie dat je deur op een kiertje staat. Even hallo de gang inroepen is en ding, naar binnenlopen en het pakketje op je tafel zetten is iets anders.

Als je denkt dat die PIN-code je tot een afgeschermde server-omgeving of database toegang geeft, dan is er responsible disclosure, en een mooi artikel NADAT ze het gefixed hebben, of het te lang duurt. Geeft deze je toegang tot een leuke easter-egg op je eigen foon, dan hack je niks en is het vermoedelijk ook een minder interessant artikel. :-) Bij twijfel: Arnoud Engelfriet.

Also, als journalist met interesse in deze zaken: door het linken/verwijzen naar een reddit-artikel dat het bestaan van dat invulveld beschrijft, is je disclosure al meteen iets minder responsible (Vergelijk: door de straat roepen dat er een deur openstaat bij een huis). Beter is het dan om wat vager te beschrijven dat je een PIN-ding in een bekende app gevonden hebt van een pretpark.

"Bovendien, waarom zou je in hemelsnaam je bankpincode daar invoeren?"
Ik ken teveel mensen die dat mogelijk zouden doen.
Mensen die bijvoorbeeld ook niet weten dat je een pincode hebt voor je simkaart en je mobiele telefooncomputer...

Het gaat niet om de pincode van je bank, maar die van je mobiele telefooncomputer,
die bij sommige mensen identiek is aan die van hun gewone computer en mogelijk zelfs hun pinpas van de bank...

Halo, het is het hacken van je eigen telefoon. Daar bestaat gelukkig geen wet tegen.

Het gaat er dus om dat iemand daar zijn pincode voor de mobiele-telefooncomputer invoert.
(Zou mij zelfs kunnen overkomen als ik net was afgeleid, aangezien ik dat vaak genoeg moet doen als ik mijn telefoon probeer te openen.) Als een applicatie jouw pincode van je toestel weet, kan die app daar vervolgens weer vervelende dingen mee gaan doen...
Als je deze website (Security.NL) volgt, zou je dat soort risico's toch niet meer zo onderschatten.
Ik reageer dan ook niet dramatisch op dit risico, maar dat mensen dat risico, hoe klein ook, hier onderkennen

Nee ik deel sterk de mening dat dit een niet plausibel nog realistisch scenario betreft. De risico groep is al minimaal door dat het een verborgen instelling is de gros ervan zal op CGNAT zitten *tenzij* er actief geluisterd wordt of andere fingerprinting data wordt opgeslagen is dit risico verwaarloosbaar. Mijn provider hun medewerkers kunnen ook afgeperst worden door criminelen en dan loopt mijn data ook mogelijk gevaar maar je moet zoveel gunstige voorwaarden daarvoor creeeren dat de kans dat je de jackpot van de loterij wint groter is dan dat iemand daar zijn gegevens invoer deze misbruikt worden en dat het niet herleidbaar is naar een medewerker bij de efteling als het al gebeurt.

sorry maar security betekend ook je resources goed verdelen voor mogelijke dreigingen afhankelijk van je infra en situatie en dit is niet iets dat op die lijst komt. En als je afgeleid bent bij data invoeren van nota bene inlog informatie dan doe je het niet goed en neem je je eigen veiligheid niet serieus genoeg op vlakken die *wel* verhoogd risico geven.Zoals typosquatin.

Ik denk best gebruikelijk, en - afhankelijk van wat er "extra" mee kan, varierend van erg onwenselijk tot 'prima' .

Het meest plausibel lijkt me dat extra logging/debug informatie aangezet wordt of zichtbaar wordt.

Ook in een serieuze 'in house' test is er een hoop wat je kunt missen.
Dan is testen met de "live" app in een 'friendly user populatie' - typisch personeel en aanhang het volgende wat je doet om bredere dekking (mensen, gebruik, soorten platformen) te hebben.
Misschien dat de logging op de app zichtbaar wordt, of dat het ingeven van de juiste pincode een vlag zet om serverzijdig meer te bewaren .

Een andere mogelijkheid zou zijn dat je op deze manier een "power user" / "personeelsmodus" aanzet, en de app dan een dubbelfunctie heeft (bv rapporteren van rommel, kapotte attracties ).
Niet uitgesloten, maar het brengt wel nadelen mee als zoiets 'slechts' aan een pincode hangt.

Ik gok op een debug functie - die "stoort" het normale gebruik het minste, en uiteindelijk wil je eventuele problemen zoveel mogelijk met "exact de normale" versie reproduceerbaar hebben.
Een speciale "debug build" maken en (selectief) beschikbaar maken wordt ook gedaan, maar het zal zeker niet de eerste keer zijn dat die zoveel afwijkt in code(paden) dat een probleem niet reproduceert. Of - een probleem gewoon vrij zeldzaam is, en zich dan een tijd niet laat zien in de achteraf geinstalelleerde debug versie.
Het 'selectief beschikbaar' maken is ook niet helemaal makkelijk onder een ietwat grotere groep min of meer 'ad hoc' friendly users.
(He Kees, dat nichtje van je dat soms problemen zag met de app , kan ze even ... ) .

Dan is 'live versie , zet in extra log stand en gewoon gebruiken totdat het weer gebeurd' de manier om de obscuurdere problemen te vinden.

Wie zegt dat de pincode niet in een backend systeem verwerkt is en daar dus gevalideerd moet worden?

Ik ken de efteling niet van binnen, ken wel mensen die er werken maar goed ga ik niet vragen. Maar zou me kunnen bedenken dat het iets van een werknemers access is waar mensen hun rooster enz kunnen zien of zoals al meer gezegd wat admin access maar met een vier cijferige code vraag ik het me af ik gok dat er niks gevaarlijks achter zit.

Beste slimmerik, we hebben het over een app voor een mobiele telefoon.
Kun je mij eens uitleggen hoe jij dat "slim zou instellen" - "mobiele telefoon" en dan "vast IP adres" ?

Het gaat er niet om dat er per se iets gevaarlijks achter zit, maar dat je dat niet kunt uitsluiten.
Zeker tegenwoordig waar je er geen idee van hebt wat zich allemaal afspeelt op je telefoon en die toch een belangrijk doelwit is geworden voor criminelen. Wie deze website een beetje volgt, leest daar voldoende over.

Nou nou, gewoon biertje doen en eens vragen.
Als ze het weten, ze hoeven je niet de code te geven, gewoon zeggen (of laten zien) waarvoor het dient.

Maar ik denk dat de meeste medewerkers ook geen idee hebben. Als mijn idee dat het een debug/extended logging switch is klopt zal de optie alleen bekend/gevraagd om te gebruiken bij 'friendly users' (typisch wel personeel) die ook een probleem gerapporteerd hebben en wat lastig reproduceerbaar is.

Als de functie veel breder zou zijn voor personeel (werkuren, of attractie defect-rapportage) verwacht je wel dat het ook breder bekend is .
Efteling heeft ca 3000 man personeel (seizoen, oproep) etc . Dat is een beetje veel om een pincode echt geheim te houden, dus dat verwacht ik niet.
Ik verwacht dus een functie die in elk geval geen probleem geeft als de (/een) pincode uitlekt , en waar geen sterke koppeling met de persoon/eigenaar van de telefoon nodig is .

Hear hear! Better safe then sorry.