Ontwikkelaar verkrijgt toegang tot NS-api voor treintijden

Een ontwikkelaar is er op relatief eenvoudige wijze in geslaagd om toegang te krijgen tot een api die de NS gebruikt voor zijn ReisPlanner Xtra. Normaliter is deze informatie alleen toegankelijk via een gebruikersnaam en wachtwoord.

Software-ontwikkelaar Jouke-Thiemo Waleson deed voor zijn Android-applicatie SnelTrein onderzoek naar het opvragen van NS-reisinformatie door verschillende apps. Hiervoor gebruikte hij een Desire Z-smartphone die via een wifi-router verbinding zocht met het internet. In Ubuntu kon Waleson met behulp van de netwerksniffer WireShark het dataverkeer bestuderen dat de Reisplanner Xtra en de servers van de NS onderling uitwisselen.

Uit het onderzoek van Waleson bleek dat de NS Reisplanner Xtra-applicatie gebruikmaakt van de url webservices.ns.nl. Om hiertoe toegang te krijgen zijn een gebruikersnaam en wachtwoord nodig, maar de ontwikkelaar kwam erachter dat deze door de applicatie onversleuteld over een http-verbinding worden verstuurd. Het bleek vervolgens relatief eenvoudig om met behulp van deze login en de juiste requests reisinformatie op te vragen die door de NS-api in xml-formaat wordt aangeboden.

Reacties (150)

[donny007]

Ik heb zojuist even mijn iPod touch besnuffelt, de iPhone versie van reisplanner Xtra maakt verbinding met reispocket.gos2m.nl in plaats van webservices.ns.nl, ook wordt er op de iPhone geen gebruik gemaakt van XML, beide lijken dus een andere api/verbinding te gebruiken.

reispocket.gos2m.nl is van www.service2media.com (maker van de app), [aanname]analyseert deze softwarebakker nou onze reisgegevens?[/aanname] Het lijkt me ongebruikelijk om zelf de gegevens door te sluizen en niet de al beschikbare XML api te gebruiken...

iPhone App -> http://www.gos2m.nl/ -> http://www.service2media.com/ -> http://www.service2media....ve_mobile_app_experiences

Since today, train travelers can experience Dutch Railways’ (NS) Travel Planner with a native mobile application on most devices, including J2ME, iPhone, Windows and BlackBerry. Service2Media has developed these applications, after the introduction of the J2ME version of last year and a redesigned mobile internet version early this year.
...
The J2ME version will appear in Nokia Ovi store soon.

Alles behalve de Android versie (hier besproken) lijkt gemaakt te zijn door service2media met waarschijnlijk de gos2m.nl doorsluis-site.

Ook van Service2media:

Rabobank pre-announces Mobile iDEAL with Service2Media proof

Klik
Ik mag hopen dat ze de iDeal gegevens niet doorsluizen.....

[Reactie gewijzigd door donny007 op 22 juli 2024 23:23]

[jurriaan]

is toch verstandig? Als de achterkant verandert (de api werkt niet meer omdat het een nieuw wachtwoord heeft gekregen bijv.) dan hoef je alleen het script op reispocket.gos2m.nl aan te passen en niet app updates uitbrengen met een fix, wat zeker in het geval van de iphone ook niet direct klaar staat.

Dat ze het kunnen loggen betekent niet direct dat ze het doen

[MBV]

XML is een nogal inefficient formaat. Kost veel bandbreedte om over te pompen, en veel tijd om te verwerken. Misschien is dit dus gedaan om de app sneller te maken?

[boyd91]

Misschien laat de NS het juist wel open staan en vullen ze hun serverpark aan met wat extra capaciteit.. lees dit maar eens voor toelichting: http://internetconsultatie.nl/reisinformatie

[Verwijderd]

Vanaf het begin zijn we ons bewust geweest van eenvoudige toegang. We zijn hier dan ook niet echt door verrast maar chique is anders. Er is een zorgvuldige overweging gemaakt om hier geen hoge beveilingsgraad op te zetten, maar om de applicatie zo snel mogelijk te laten werken.

Voor alle duidelijkheid er kan op deze manier alleen toegang worden verkregen tot de door NS vrijgegeven informatie, de daadwerkelijk API.

De informatie die via deze API beschikbaar is, wordt deze week zoals gepland ook via een publiek toegankelijke API beschikbaar gesteld. Maar de ‘primeur’ is naar deze software-ontwikkelaar gegaan. Bottom line is dat er aandacht is voor de beschikbaarheid van de API.

Enige tijd geleden is met de redactie van Tweakers contact geweest om de API te testen, echter kon hier jammer genoeg vanuit beide kanten geen gehoor aan worden wegens capaciteitsgebrek. De reisinformatie-api is enige tijd geleden ontwikkeld. (http://www.emerce.nl/nieuws/de-ns-geeft-reisdata-vrij)

[Pogostokje]

Helemaal geen primeur ...

http://rijdendetreinen.com/
http://www.traphic.nl/trein.aspx
http://websvn.chozo.nl/fi...path=%2FPython%2Fnsdat.py

enz...

[Runner15]

Ik snap niet (als leek op het gebied van dit soort dingen) waarom dit zo erg is. Die Android App van de NS is toch gratis! Het is wel slordig natuurlijk, maar geen ernstig beveiligingslek toch?

[HyperBart]

Neen, maar het is wel een beetje een faal van de NS, want als ik het zo begrijp dan wil de NS niet dat andere mensen een app maken die nota bene rechtstreeks de servers gebruikt van de NS om informatie op te vragen... (wat ik trouwens heel bekrompen vind, ik kan me goed inbeelden dat mensen nu denken van "hmmm, nu kan ik gecombineerd met die taxi-app en die carpool-app een mooi geheel er van maken voor mensen die geen privaat vervoersmiddel ter beschikking hebben")...

[Relief2009]

Misschien wil NS zelf die diensten implementeren in de toekomst. Waarom zou NS toegang geven tot haar diensten aan concurrenten (app-ontwikkelaars)?

[ATS]

Omdat NS een publiek bedrijf is. 100% eigendom van de overheid.

[Verwijderd]

Ik dacht dat dat anders was na de privatisering van de OV bedrijven. Die 100% kan je wel vergeten.

[TheGhost]

De NS is nog wel 100% staatseigendom. Maar ProRail, wat een afsplitsing van de NS is, is dat 100% NIET! De minister is echter nog wel verantwoordelijk voor het handelen van ProRail, dat zelf niks aan het spoor doet. Dit wordt gedaan door (spoor)aannemers.

[Verwijderd]

Zowel de NS als ProRail zijn 100% eigendom van de Nederlandse staat. Op termijn is het wel de bedoeling dat de NS geprivatieseerd wordt.

[de.professor]

Offtopic:
Eventjes een kleine aanvulling. De aandelen van de NS is 100% eigendom van de Nederlandse staat. Hier kunnen ze echter helemaal niets mee. Tijdens de algemene aandeelhoudersvergadering zou je het bestuur weg kunnen sturen, maar daarvoor is wel wanbeleid nodig. Verder besteed de overheid het vervoeren van reizigers uit aan de NS, waarvoor deze een prestatiecontract aangaan.
Verder zal er in het contract wel iets staan opgenomen dat de NS de informatie over internet gratis ter beschikking moet stellen aan consumenten.
Ik weet dat dit in elk geval wel het geval is met de contracten van de busmaatschappijen en de provincie.
Het zal me echter niet verbazen als daarin staat opgenomen dat deze direct en "anoniem" beschikbaar is, zonder inloggen dus.
Verder mogen deze organisaties de data wel verkopen aan bedrijven als ov9292 en deze mogen het dan wel op commerciële basis aanbieden.

[Dreamvoid]

Dat sluit niet uit dat ze BV geld mogen vragen voor hun diensten (zie bv het treinkaartje).

[CH4OS]

Neen, maar het is wel een beetje een faal van de NS, want als ik het zo begrijp dan wil de NS niet dat andere mensen een app maken die nota bene rechtstreeks de servers gebruikt van de NS om informatie op te vragen... (wat ik trouwens heel bekrompen vind, ik kan me goed inbeelden dat mensen nu denken van "hmmm, nu kan ik gecombineerd met die taxi-app en die carpool-app een mooi geheel er van maken voor mensen die geen privaat vervoersmiddel ter beschikking hebben")...

In het geval van Trein op iOS heeft de NS aangegeven het eigenlijk niet te willen, maar dergelijke apps (iig Trein) te gedogen.

En waarom is het bekrompen? Apps van derden gebruiken daardoor wel bandbreedte en recourses van een ander, zonder ervoor te (hoeven) betalen.

[SPee]

Maar het voornamelijke doel is niet die dienst te leveren, maar ervoor te zorgen dat meer mensen met de trein gaan.
Als door andere (oneigenlijke) applicaties meer mensen met de trein gaan, heeft de NS alsnog haar doel bereikt

[YopY]

En toch lijkt Twitter juist andersom te gaan, die hadden een publieke, vrij te gebruiken API, maar trekken nu steeds meer terug achter vereisten voor de applicaties om een of andere reden.

[Relief2009]

Het gaat erom dat nu elk willekeurige ontwikkelaar een app kan maken aan de hand van NS's eigen server.

Totdat NS natuurlijk de login veranderd en het voortaan versleuteld opstuurt. Met een update zou dat snel gedaan moeten zijn

[t-x-m]

Een gevolg daarvan is wel dat het wachtwoord in de huidige app niet meer werkt en de app dus moet worden geupdate...

[Verwijderd]

Dus?

Sturen ze eventjes een berichtje dat je je app moet updaten. Kwestie van die XML even vervangen...
Daarna stuur je de nieuwe door naar een ander adres, zodat die er geen last van heeft.

Overigens kan je natuurlijk ook gewoon een eigen API maken, door even PHP (bijvoorbeeld) een webpagina te laten parsen.

[Verwijderd]

Wel wanneer je de app zo hebt gemaakt dat die ook andere data accepteert. Wanneer dit niet het geval is en er andere data(geen reisinfo) wordt gestuurd kan die goed hard op zijn bek gaan

[OddesE]

En dan hangt Jouke-Thiemo een debugger aan de updated app, peutert de login gegevens uit het geheugen op het punt voordat deze het HTTPS protocol ingaan (en dus nog niet versleuteld zijn) en voila. Een dure API wijziging en update verder en toch geen steek opgeschoten.

Je kunt niet een gebruikersnaam en wachtwoord hardcoded in een applicatie stoppen, die applicatie aan de aanvaller geven en dan verwachten dat het wel goed zal komen. Of je maakt de dienst publiek toegankelijk zodat iedereen er bij kan, of je laat klanten/gebruikers een eigen account aanmaken en zelf hun gebruikersnaam en wachtwoord kiezen (die dan dus op elk toestel anders is).

Of je doet wat de NS doet en blijft tot aan het einde der tijden zogenaamde security updates verspreiden die dan binnen een paar dagen weer 'gekraakt' zijn.

[amas]

OK, leuk, maar wat heeft hij hier nu aan. Die treintijden zijn toch openbaar te zien? Is er geen openbare database waar ontwikkelaard mee mogen werken? Want om nou op deze manier aan je informatie voor je app te komen...

[Bananenspin]

Nee die is er niet, kan me nog een artikel herinneren dat een tweaker een boze brief kreeg van de NS omdat hij de tijden haalde van m.ns.nl en ze dit niet leuk vonden en dat hij maar moest stoppen..

[Relief2009]

Dat was niet NS, maar de Belgische variant.

Ik weet het niet zeker. Mss dat NS ook iets vergelijkbaars heeft geflikt.

[Reactie gewijzigd door Relief2009 op 22 juli 2024 23:23]

[Kerberos84]

http://tweakers.net/nieuw...-met-mobiele-ov-site.html

[Verwijderd]

http://tweakers.net/nieuw...-met-mobiele-ov-site.html

Terzijde. Dat Belgische probleem is later wel geregeld omdat er geen copyright op die (belgische) gegevens rust.
http://irail.be/

nieuws: Mobiele ov-site iRail komt weer online
Leuk om te lezen en misschien ook hier toepasbaar wanneer nodig

[CH4OS]

Dat was niet NS, maar de Belgische variant.

Was idd de Belgische variant, stond hier toen ook op Tweakers, vreemd dat die niet bij gerelateerde content staat.

Ik weet het niet zeker. Mss dat NS ook iets vergelijkbaars heeft geflikt.

De NS wil het liever ook niet hebben, maar gedoogd (iig) de applicatie Trein.

[Verwijderd]

Volgens mij zijn actuele treintijden niet in een gemakkelijke API beschikbaar voor ontwikkelaars en wordt het binnenhalen van dergelijke data meestal gedaan door de HTML van de NS website te parsen, aangezien de gegevens op de website wel zichtbaar zijn. Het is natuurlijk veel makkelijker (en betrouwbaarder) om een dergelijke XML gebaseerde datasource/API te gebruiken, waardoor het wel degelijk interessant zou zijn voor ontwikkelaars als de NS deze API zou openbaren.

[Relief2009]

Nee die is er niet echt (de open vorm dan). Er is een plan om een centrale database op te richten voor het openbaar vervoer door de overheid die toegang moet verlenen tot derde partijen, maar het gaat helaas niet zo snel als men gewild zou hebben.

Zoek maar op de NDOV-database.

[OddesE]

Lol als ze nou gewoon eens de authenticatie op deze API niet gebouwd zouden hebben (!) dan was het 'werk' (ehm gebrek aan werk) al klaar.

Maar goed het is de overheid dus moet waarschijnlijk langs 100 commissies of zo...

[frickY]

Mooi gevonden.

Gebeurd helaas nog heel vaak dat een bedrijf meent data te beveiligen, maar dat dit verkeerd geïmplementeerd wordt. Dit keer gelukkig met publiekelijke informatie zoals vertrek tijden, maar ook regelmatig met meer privacy gevoelige data.

Er zijn wel bedrijven die audits op dergelijke beveiliging doen, maar er is niet echt een herkenbaar keurmerk of certificaat waaraan een consument kan herkennen of die ook ondergaan is. Dat is jammer.

[Elmo_nl]

Dit keer gelukkig met publiekelijke informatie zoals vertrek tijden, maar ook regelmatig met meer privacy gevoelige data.

Waarom zou het met het versturen van (niet anonieme) OV kaarten data anders gaan dan bij de NS? Zet wireshark maar eens een paar uur naast zo'n OV paal, ik denk dat we dan nog een nieuwsartikel krijgen...

[DiLDoG]

Waarom zou het het zelfde gaan? de OV paal en deze android app zijn door 2 verschillende bedrijven ontwikkeld. Bovendien hebben ze uberhaubt vrij weinig met elkaar te maken.
Ik geef toe dat de OV chip nou niet bepaald geweldig is geimplementeerd, maar zon opmerking is ook wel heel makkelijk. Of hap ik nu?

[Elmo_nl]

Of hap ik nu?

Ik bedoelde het echt serieus, ik zou wel eens willen weten of dat beter beveiligd is of dat het daar net zo makkelijk gaat. Mede omdat ik laatst in iemands commentaar hier op Tweakers las dat er (wellicht) een wet in de maak is die bedrijven verplicht te melden aan hun gebruikers/klanten als hun prive data is gelekt. Dat zou dan een probleem kunnen zijn/worden voor de NS.

[blissard]

Als je dat echt wilt weten, dan probeer je het toch even. Zoveel moeite is dat niet.
Laat je wel even weten wat je conclusies zijn?

[Relief2009]

Ik denk dat dat al gebeurd is

[elmuerte]

Er zijn wel bedrijven die audits op dergelijke beveiliging doen, maar er is niet echt een herkenbaar keurmerk of certificaat waaraan een consument kan herkennen of die ook ondergaan is. Dat is jammer.

Waarom zou ik een keurmerk of certificaat vertrouwen? Chemie-Pack had ook alle keurmerken en certificaten die nodig waren.

[Neus]

He? Hij verkrijgt dus niet met medeweten van de NS toegang, maar 'illegaal'.

... zijn een gebruikersnaam en wachtwoord nodig, maar de ontwikkelaar kwam erachter dat deze door de applicatie onversleuteld over een http-verbinding worden verstuurd. Het bleek vervolgens relatief eenvoudig om met behulp van deze login en de juiste requests reisinformatie op te vragen die door de NS-api in xml-formaat wordt aangeboden.

Welke 'deze' ? Kan hij andermans login en wachtwoorden zien? Of is het een standaard login die de Reisplanner Extra gebruikt en hij heeft dit kunnen 'sniffen'?

Beetje onduidelijk in dit artikel.

[Reactie gewijzigd door Neus op 22 juli 2024 23:23]

[maartenv]

ja dus, als het onversleuteld verzonden wordt, kan je met wireshark enorm veel... HTTPS gebruiken!

[miw]

Het gebruik van https zou alleen het point of attack verplaatsen naar een punt in de applicatie zelf.

[TheGhost]

Misschien wel, maar het is wel weer een stapje moeilijker. Wachtwoorden via HTTP meesturen is nogal 1980. Iedere drempel die je legt in het omzeilen van "beveiliging" is een stap dichter bij een veiligere omgeving.

[OddesE]

Nee. Dat is dus de fout. Dit is zo gewoon niet te beveiligen. Nu is het wireshark, anders wordt het een debugger en peuteren we de username en het password uit het geheugen. De fout die ze gemaakt hebben was niet het onversleuteld versturen van de login gegevens, maar het hardcoden van deze gegevens in de applicatie.

In plaats daarvan zouden ze de gebruiker bij download / aankoop van de applicatie een account moeten laten aanmaken. Dan heeft elke gebruiker zijn eigen login gegevens en dan had Jouke-Thiemo alleen zijn eigen account gegevens zien langskomen. Als dan misbruik wordt gemaakt van een account blokkeer je gewoon die ene account. Nu de gegevens hardcoded in de app zitten is blokkeren ook geen optie want dan blokkeren ze ook alle legitieme gebruikers.

[Dutch_Razor]

Dus je wilt alle x miljoen gebruikers van de applicatie onnodige handelingen laten verrichten omdat je zo graag die API wilt beveiligen.

Als het hier om gevoelige data ging was ik het met je eens, maar wanneer ze het redelijk verborgen in de applicatie opslaan is het in dit geval "veilig" genoeg. Een andere applicatie hiermee maken zal waarschijnlijk toch wel verboden zijn omdat er een inlog nodig is.

[Verwijderd]

Het is niet onnodig (in ieder geval niet omdat jij het zegt). En het is slechts 1 handeling per gebruiker. Er moeten ook dagelijks miljoenen mensen hun paspoort laten zien. Wil je dat ook afschaffen?

[dtech]

Ze kunnen natuurlijk wel relatief simpel een update van de applicatie uitbrengen die gebruik maakt van een andere authenticatiemethode en de webservice updaten om alleen nog de nieuwe methode te ondersteunen.

[Verwijderd]

Voor het publiek wel, maar het protocol bestaat al langer.

[RichieB]

Welnee. Gewoon een capturing proxy (burp) ertussen en hopen dat de app het ssl certificaat van de server niet controleert.

[Verwijderd]

Met bepaalde programma's zoals sslstrip kun je tijdens een mitm-aanval de https 'handshake' vanaf de aanvallende computer doen, de persoon erachter ziet gewoon http aankomen terwijl de server denkt dat het beveiligd internet verkeer verzend/ontvangt.

[elmuerte]

He? Hij verkrijgt dus niet met medeweten van de NS toegang, maar 'illegaal'.

Correct, en dit is een tekstboek voorbeeld van toegang verschaffen tot een geautomatiseerd systeem met een valse sleutel, i.e. computervredebreuk.

[thegve]

Nee hoor. Dit is een sleutel die ze zelf uitdelen in de applicatie. Reverse engineering is in Nederland toegestaan. Ik zie hier echt geen 'juridisch' probleem.

Computervredebreuk is inbreken op een systeem. Je breekt hier absoluut niet in op het NS systeem. Je verkrijgt alleen exact dezelfde informatie die de NS gewoon aanbied via hun app, via je eigen app.

edit @gebruiker_nr_1:
Analogieën@tweakers, dan ga ik ook maar even meedoen:

Jij geeft mij de sleutel van jouw huis, maar je spreekt af dat ik wel even mijn schoenen uit moet doen als ik daar gebruik van maak. Hufter dat ik ben, doe ik dat dus niet, en ik wandel gewoon zo naar binnen.
Zo'n subtiel verschil is het, het is natuurlijk niet aardig tegenover de NS want de bedoeling van die sleutel is dat je hem alleen met hun eigen app gebruikt, maar het blijft nog altijd gewoon een legaal verkregen sleutel.

Overigens, ik ga er vanuit dat (de ontwikkelaar/bedrijf dat de NS heeft ingehuurd) wel op de hoogte was van de sterkte van de beveiliging. Zoals hierboven al aangegeven, soms is het voldoende om het even een beetje lastig te maken, het is niet alsof het om gevoelige info gaat.
Deze app is (ik heb geen smartphone, maar ik lees wel eens wat) nu zo'n 2-3 jaar oud. Ze weten dus nu precies hoeveel interesse er voor is, en ze hebben de beveiliging nu heel goedkoop kunnen regelen. Nu kunnen ze dus, mocht het ze 'boeien', met een goede business case bij de NS intern zo geld krijgen om dit te verbeteren.

[Reactie gewijzigd door thegve op 22 juli 2024 23:23]

[Verwijderd]

Daar gaat het niet om. Of ik nu op jouw PC inbreek en vervolgens slechts enkele plaatjes van Google download, en een aflevering van uitzendinggemist kijk, het blijft computervredebreuk.

[rlKoekie]

de login die NS ingeprogrammeerd heeft in hun reisplanner app, waardoor alleen hun eigen applicatie die gegevens normaal gesproken kan opvragen.

[Reactie gewijzigd door rlKoekie op 22 juli 2024 23:23]

[ajakkes]

Om de data terug te krijgen van webservices.ns.nl moet je een aanvraag doen bij de server. Het wachtwoord dat de NS zelf gebruikt voor zijn applicatie om ervoor te zorgen dat alleen NS applicaties deze gegevens terugkrijgen wordt onversleuteld over over het internet verzonden.

Nu kan iedere applicatie zich voordoen als de NS eigen applicatie.

[donny007]

Ik vindt dat een API met zulke gegevens gewoon standaard open moet staan voor ontwikkelaars, waarom treintijden (of überhaupt OV-tijden) afschermen?

Als een ontwikkelaar een betere reisplanner als de NS zelf kan maken moeten ze dat vooral doen, de NS zou daar dan de ruimte voor moeten geven, mischien leren ze nog wel wat van andere developpers....

Ik denk dat de NS er gewoon HTTPS in knalt, het wachtwoord aanpast en de app update...

Al met al een slordige fout, maarja, waarom zou je treintijden willen beveiligen?

Zo heb ik ook een keer de Sqlite database van de voormalige Bus app van mijn gejailbreakte iPod touch gehaald en er een PHP applicatie omheen gebouwd, jammer dat de DB niet meer geupdate wordt en de app weg is vond het wel handig....

[Reactie gewijzigd door donny007 op 22 juli 2024 23:23]

[BasieP]

Ns wil ook gewoon winst maken. Door te zorgen dat gebruikers alleen jouw ap gebruiken, kun je ze in die app nog andere dingen aanbieden.

Als een derde een app bouwt op jouw API en daardoor mis jij inkomsten is het een hele dure API geweest

[donny007]

Het product van de NS is je van A naar B brengen (op een bepaalde tijd*), als dat toegankelijker wordt door het openstellen van dit soort API's maakt de NS juist meer winst omdat meer mensen de weg van A naar B vinden. Neem nou mijn oma, die snapt de NS reisplanner amper, laat een ontwikkelaar een applicatie maken met grote letters en alleen VAN:, NAAR: en klaar, weer een OV-klant erbij.

[Verwijderd]

Dan doet de NS dit liever zelf; derden zouden in hun app informatie kunnen verkopen (locatie e.d.) aan derden en op die manier geld verdienen, ondanks dat ze bijna niks hoeften te doen (sniffen) terwijl de NS een hele API moest bouwen...

[Hiub]

Maar het rare is dus dat ze het helemaal niet erg vinden dat derden zo'n app bouwen. Ik gebruik bijvoorbeeld al een hele tijd "Treintijden" op android, die was er al een tijd voor de app van NS zelf er was. Maar die app werkt nog steeds prima.

[MaffeMaarten]

Idd, deze gebruik ik ook al "tijden",

Wat trouwens mooi was, toen ik nog geen databundel had, kon je deze app wel gewoon gebruiken op NS-stations, omdat het ns.nl-domein wel gratis toegankelijk is via de kpn-hotspots op het station.

Maar als ik het goed begrijp kan de officiële app dat ook, en zou die theoretisch ook nog een stuk sneller moeten zijn, omdat ie de informatie meteen krijgt, zonder dat ie de html eromheen hoeft weg te filteren.

[orthello]

Https biedt in deze geen oplossing omdat het nog steeds je eigen data verkeer is die je kan bekijken. Daar https overheen halen is totaal zinloos.

[deathz0rz]

Niet geheel onverwacht. De informatie komt op de één of andere manier van de NS op je scherm, dus de informatie moet door iedereen met zo'n programmatje op te vragen zijn. Hoe goed je dat ook meent te beveiligen blijkt het in de praktijk altijd onmogelijk. We zitten hier namelijk met het aloude DRM-verhaal dat je mensen een slot aanbiedt maar dat je ze de sleutel er (al dan niet op een vreemde, verborgen manier) bij geeft.

[MittaM]

niet geheel waar natuurlijk had een SSL verbinding al een hoop geholpen

[Pogostokje]

Ja. Maar je kunt dan bijvoorbeeld weer een app reverse engineeren. De verbinding is met SSL een sterker punt, maar de apps op alle platformen moeten nog altijd ergens het wachtwoord hebben staan.

In de praktijk kunnen ze dit vrijwel niet tegenhouden. De NS zou er niet zo'n probleem van moeten maken, in goed overleg een goed informatie systeem opzetten voor reizigers is meer waard dan tijd en geld steken in een kat en muis spelletje. Ze moeten de data als dienst zien, niet hun eigen app.

[Elmo_nl]

Maar dit is zo knullig beveiligd anno 2011 (plaintext un/ww? komop zeg) dat je het kunt vergelijken met twee poortwachters bij het paleis op de dam die om een wachtwoord vragen aan bezoeker X terwijl jij als voorbijganger Y hem hoort zeggen "appelflap".
"Ja, komt u rustig verder hoor..." Met de software reverse engineren of SSL verbindingen decrypten kun je niet stellen dat je 'het toevallig' te weten bent gekomen zoals in het eerdere voorbeeld wel.

[OddesE]

Zo knullig is het niet beveiligd. Als je met wireshark overweg kunt kun je vast ook wel een hex editor gebruiken of een debugger. Of je het wachtwoord nou vanaf plek A plukt of vanaf plek B maakt niks uit. Dat hele 'onversleuteld' verhaal is een 'red herring' en totaal irrelevant.

deathz0rz heeft 100 procent gelijk, dit is net als bij DRM gewoon niet te beveiligen, zeker niet op een open platform als Android. Ze geven namelijk de sleutel er bij.
Zou het nou een PS3 achtig platform zijn waar je totaal niks op kan zonder te hacken dan kon men het nog wat langer volhouden wellicht maar op Android? Onmogelijk.

[orthello]

Je Wireshark vs hexedit stelling vind ik wel erg kort door de bocht. Zo moeilijk is wireshark niet en zo makkelijk is hex lezen ook niet.

[orthello]

Met ssl bedoel je https?
https verkeer is bijna net zo makkelijk te monitoren als http verkeer.
als je maar zorgt dat je eigen proxy er tussen staat. Man in the middle noemen ze dat.
Op deze manier zijn tal van apis te bekijken.

Xml is inderdaad lomp. Er kan beter met json worden gewerkt. of gewoon lekker klein in base64. kost het ook weer meer moeite om de api te analyseren.

Ach jongens het kan altijd beter.
Daarbij geeft de Ns aan dat het een bewuste keus is. Dan lijkt me dat ook meteen einde discussie.
Dit is misschien wrel een van de eenvoudigst vormen van 'hacken'.
zo eenvoudig dat ik zelfs weiger om het hacken te normen.
Chique? Nee.
Gevaarlijk? Niet direct. Afhankelijk van wat er nog meer op die server staat en gebeurd.
Ongewenst? Misschien.
Strafbaar? Naar mijn weten niet.
Er zijn bergen andere aps die ook gevoelig zijn voor deze methode.

[orthello]

Neen. Want het is je eigen dataverkeer. En die is zo te routen als jij wilt. En dus heel eenvoudig te bekijken. Ssl of niet.

[Torrentus]

Als u nu naar http://webservices.ns.nl/ gaat dient u een wachtwoord in te voeren. Helaas voor de NS gebruikt hun applicatie geen https, waardoor het wachtwoord dat de Android applicatie gebruikt ook af te luisteren is. De gebruikersnaam "android" en wachtwoord "mvdzig" worden open en bloot verstuurd en zijn ook gewoon bruikbaar vanuit uw browser.

Bron.

Voor mensen die dit willen uitproberen
Interessant, en weer een mooi voorbeeld van het onderschatten van de veiligheid.
Al vind ik het belachelijk dat die API gesloten is, mensen toch, laat die ontwikkelaars toch mooie apps maken! Misschien helpt het om het negatieve imago van de NS wat te verbloemen!

[HerrPino]

Interessant, en weer een mooi voorbeeld van het onderschatten van de veiligheid.

Misschien wel niet, misschien was het een overweging:
- 'zullen we er meer tijd en geld in stoppen'
- of 'zullen we er gewoon een simpel wachtwoord op zetten aangezien er toch geen geheime data op staat'.

De NS heeft verder geen echte concurenten en veel valt er niet te verliezen. Er zijn hooguit een paar mensen die een tooltje schrijven die er gebruik van maakt. En of men nu tool A of B gebruikt het data verbruik zal waarschijnlijk niet drastisch verschillen... en als het wel misbruikt wordt kunnen ze er nog altijd encryptie op zetten.

[OddesE]

Ik denk dat de afweging eerder was:

Zullen we de gebuiker er mee lastig vallen door hem te dwingen een account aan te maken of zullen we gewoon een voorgebakken account hardcoded in de applicatie stoppen?

Of hij wel of niet encrypted over de lijn gaat boeit niet.

Encryptie beschermt alleen tegen buitenstaanders die afluisteren. Op de twee machines die informatie uitwisselen zelf biedt het geen enkele bescherming want deze hebben zelf de sleutels in handen om de gegevens weer te ontcijferen.

[Relief2009]

De NS heeft zelf al een topapplicatie (op Android en de iPhone), dus dat imago hebben ze zelf al een stuk verbeterd.

[MarcoC]

Topapplicatie is overdreven, er is nog genoeg ruimte voor verbetering. De betaalde third party app Trein vind ik vele malen beter...

[doltishDuke]

Denk bijvoorbeeld ook aan het toepassen van trein informatie in andere apps. Zo beheer ik een evenementen service waarbij ik graag OV mogelijkheden geef aan de reiziger. Zo'n API is dan ideaal.