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)
Dit is mijn inziens geen SOAP, maar normale XML. SOAP voegt namelijk meer informatie toe zoals het type variabele dat gegeven wordt. Ik vraag me nu wel af wat de NS gaat doen: in principe is het niet heel erg gevoelige informatie dit en het wordt lastig om iedereen een nieuwe (veiligere) applicatie te laten installeren die gebruikt maakt van SSL.
Krijg ik te zien als ik inlog op de genoemde website. Dus lijkt me wel SOAP. Raar trouwens, want ik logte in met de gegevens van deze 'softwareontwikkelaar'. Gebruikersnaam al aangepast ofzo? Of werkt zoiets niet in een browser?<soap:Envelope soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header/>
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>001:Request doesn't contain an indication for the webservice to be called</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
@ onder, Aha, zo. Dankje!
[Reactie gewijzigd door Torrentus op dinsdag 29 maart 2011 17:01]
Nee, je hebt alleen geen request ingediend, dus de webservice weet niet wat hij er mee moet, en komt met een 001 terug.
Fout al gelezen? Je vraagt geen webservice op, heeft niks met de inloggegevens te maken. 
Als het geen gevoelige info was (voor de NS) Hadden ze vast ook wel meegedaan aan het OpenData project.
Maar dat doen ze niet. Want dan kan iemand alle treintijden gaan bijhouden in een systeem en eventueel berekenen hoe vaak ze echt op tijd zijn en wanneer niet. (even simpel geredeneerd)
Maar dat doen ze niet. Want dan kan iemand alle treintijden gaan bijhouden in een systeem en eventueel berekenen hoe vaak ze echt op tijd zijn en wanneer niet. (even simpel geredeneerd)
Offtopic, maar toch ook weer niet:
Vandaag was er weer eens wat aan de hand rond de avondspits, en mijn trein had 45 minuten vertraging vanaf mijn opstaplocatie. Bijna bij mijn uitstaphalte is het opeens nog maar een kwartier... slimmerds. Volgens het spoorboekje gesproken is er 1 trein uitgevallen, en heeft de ander 45 minuten vertraging... wat het gemiddelde lekker omlaagtrekt. Maar nee, wat doen ze? Ze doen alsof die 45 minuten maar 15 minuten zijn (en een die er uitvalt). Effect is hetzelfde voor de reiziger, maar voor de statistieken is dat toch echt onjuist. Zo, even wat statistisch gezeur gespuid.
Vandaag was er weer eens wat aan de hand rond de avondspits, en mijn trein had 45 minuten vertraging vanaf mijn opstaplocatie. Bijna bij mijn uitstaphalte is het opeens nog maar een kwartier... slimmerds. Volgens het spoorboekje gesproken is er 1 trein uitgevallen, en heeft de ander 45 minuten vertraging... wat het gemiddelde lekker omlaagtrekt. Maar nee, wat doen ze? Ze doen alsof die 45 minuten maar 15 minuten zijn (en een die er uitvalt). Effect is hetzelfde voor de reiziger, maar voor de statistieken is dat toch echt onjuist. Zo, even wat statistisch gezeur gespuid.
Het lijkt er op dat er wel een 'echte' web service draait en dat er een http proxy server voor is gezet. Het request van de client (jouw browser) is een gewoon http request wat waarschijnlijk door een HttpServlet (draaiend op een JBoss AS) wordt vertaald naar de de aanroep van de 'echte' web service (i.e. envelopje er om heen, authenticatie gegevens erbij, etc.).
Op de terugweg wordt de response van de web service weer aan de servlet kant vertaald naar een XML bericht, zonder de envelop met toeters en bellen, wat door je browser wordt gepresenteerd. Soms lijkt er echter een SOAP (fout)bericht gemist te worden, bijvoorbeeld bij een niet succesvolle authenticatie, die dan met envelop en al doorkomt.
Jouke-Thiemo Waleson lijkt echter niet de 'ontdekker' van de openheid van NS services. Hier vind je een stukje code van iemand die kennelijk al begin februari met deze 'publieke?' api zat te spelen.
Ik vraag me af of de ontdekking van dit 'lek' nou wel zo enorm ernstig is. Tenzij de vertrektijden en sporen een enorm geheim zijn?
Op de terugweg wordt de response van de web service weer aan de servlet kant vertaald naar een XML bericht, zonder de envelop met toeters en bellen, wat door je browser wordt gepresenteerd. Soms lijkt er echter een SOAP (fout)bericht gemist te worden, bijvoorbeeld bij een niet succesvolle authenticatie, die dan met envelop en al doorkomt.
Jouke-Thiemo Waleson lijkt echter niet de 'ontdekker' van de openheid van NS services. Hier vind je een stukje code van iemand die kennelijk al begin februari met deze 'publieke?' api zat te spelen.
Ik vraag me af of de ontdekking van dit 'lek' nou wel zo enorm ernstig is. Tenzij de vertrektijden en sporen een enorm geheim zijn?
Dat is-ie nog steeds, maar ja...als je de login/pass te pakken krijgt...Normaliter is deze informatie alleen toegankelijk via een gebruikersnaam en wachtwoord.
En dan nog, hoe boeiend is het dat deze API open ligt. Het is immers een API om data op te kunnen vragen.
Grote bedrijven zijn vaak te panisch als het gaat om openstellen van APIs voor ontwikkelaars. Als dit niet via de normale paden gaat dan kan altijd nog met een bot (google?
) de HTML worden gescraped.
Als het lijdt tot performance issues dan kun je altijd nog anonymous user bandwidth throttlen.
Als ze hun klantgegevens zo beschermen doen ze het dan weer wat minder fraai ;-)
Grote bedrijven zijn vaak te panisch als het gaat om openstellen van APIs voor ontwikkelaars. Als dit niet via de normale paden gaat dan kan altijd nog met een bot (google?
) de HTML worden gescraped.Als het lijdt tot performance issues dan kun je altijd nog anonymous user bandwidth throttlen.
Als ze hun klantgegevens zo beschermen doen ze het dan weer wat minder fraai ;-)
Misschien had de service nog meer aanroepen dan alleen het opvragen van reisinformatie. Het melden van omroepberichten bijvoorbeeld.
Maarja, een gebruikersnaam en wachtwoord die onderversleuteld over de lijn gaan (en waarschijnlijk ook onversleuteld in de binary van het programma staan) zijn dan ook zo goed als waardeloos.
Maar uiteindelijk blijft het altijd mogelijk blijven om dit soort beveiligingen te kraken, kijk maar naar CSS of AACS. Het apparaat/de user zal uiteindelijk toegang moeten krijgen tot de informatie.
Maar uiteindelijk blijft het altijd mogelijk blijven om dit soort beveiligingen te kraken, kijk maar naar CSS of AACS. Het apparaat/de user zal uiteindelijk toegang moeten krijgen tot de informatie.
He? Hij verkrijgt dus niet met medeweten van de NS toegang, maar 'illegaal'.
Beetje onduidelijk in dit artikel.
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'?... 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.
Beetje onduidelijk in dit artikel.
[Reactie gewijzigd door Neus op dinsdag 29 maart 2011 16:38]
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 dinsdag 29 maart 2011 16:38]
ja dus, als het onversleuteld verzonden wordt, kan je met wireshark enorm veel... HTTPS gebruiken!
Het gebruik van https zou alleen het point of attack verplaatsen naar een punt in de applicatie zelf.
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.
Voor het publiek wel, maar het protocol bestaat al langer.
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.
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.
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.
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.
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?
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.
Welnee. Gewoon een capturing proxy (burp) ertussen en hopen dat de app het ssl certificaat van de server niet controleert.
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.
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.
Nu kan iedere applicatie zich voordoen als de NS eigen applicatie.
Correct, en dit is een tekstboek voorbeeld van toegang verschaffen tot een geautomatiseerd systeem met een valse sleutel, i.e. computervredebreuk.He? Hij verkrijgt dus niet met medeweten van de NS toegang, maar 'illegaal'.
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.
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 woensdag 30 maart 2011 12:13]
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.
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.
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.
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...
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...
Ik denk dat dat al gebeurd is
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?
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?
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.
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.
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?
Laat je wel even weten wat je conclusies zijn?
Waarom zou ik een keurmerk of certificaat vertrouwen? Chemie-Pack had ook alle keurmerken en certificaten die nodig waren.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.
Hoe zit dat met die Tweakers.net (iphone/android app)? Worden daarin je username/pwd wel via een beveiligde verbinding gestuurd? Ook niet toch?
Het gaat niet om de eigen username, maar de login gegevens die de NS intern gebruikt voor het opvragen van info.
met deze informatie zou iedereen een app kunnen maken die de actuele vertrektijden aanbiedt aan gebruikers, aangezien de informatie met de juiste login gegevens van de NS server kan worden gehaald.
met deze informatie zou iedereen een app kunnen maken die de actuele vertrektijden aanbiedt aan gebruikers, aangezien de informatie met de juiste login gegevens van de NS server kan worden gehaald.
[Reactie gewijzigd door bazooka op dinsdag 29 maart 2011 16:48]
Derice vraagt of de T.net app via een beveiligde verbinding de informatie verstuurd, niet zoals deze app, onbeveiligd en versleutelt. Principe is dus hetzelfde.Het gaat niet om de eigen username, maar de login gegevens die de NS intern gebruikt voor het opvragen van info.
Gebeurt toch ook? Zie bijvoorbeeld Trein en 9292ov pro op iOS.met deze informatie zou iedereen een app kunnen maken die de actuele vertrektijden aanbiedt aan gebruikers, aangezien de informatie met de juiste login gegevens van de NS server kan worden gehaald.
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?
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")...
Misschien wil NS zelf die diensten implementeren in de toekomst. Waarom zou NS toegang geven tot haar diensten aan concurrenten (app-ontwikkelaars)?
Omdat NS een publiek bedrijf is. 100% eigendom van de overheid.
Dat sluit niet uit dat ze BV geld mogen vragen voor hun diensten (zie bv het treinkaartje).
Ik dacht dat dat anders was na de privatisering van de OV bedrijven. Die 100% kan je wel vergeten.
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.
Zowel de NS als ProRail zijn 100% eigendom van de Nederlandse staat. Op termijn is het wel de bedoeling dat de NS geprivatieseerd wordt.
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.
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.
In het geval van Trein op iOS heeft de NS aangegeven het eigenlijk niet te willen, maar dergelijke apps (iig Trein) te gedogen.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")...
En waarom is het bekrompen? Apps van derden gebruiken daardoor wel bandbreedte en recourses van een ander, zonder ervoor te (hoeven) betalen.
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
Als door andere (oneigenlijke) applicaties meer mensen met de trein gaan, heeft de NS alsnog haar doel bereikt
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.
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
Totdat NS natuurlijk de login veranderd en het voortaan versleuteld opstuurt. Met een update zou dat snel gedaan moeten zijn
Een gevolg daarvan is wel dat het wachtwoord in de huidige app niet meer werkt en de app dus moet worden geupdate...
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.
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.
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
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.
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.
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...
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..
Dat was niet NS, maar de Belgische variant.
Ik weet het niet zeker. Mss dat NS ook iets vergelijkbaars heeft geflikt.
Ik weet het niet zeker. Mss dat NS ook iets vergelijkbaars heeft geflikt.
[Reactie gewijzigd door Relief2009 op dinsdag 29 maart 2011 16:54]
Was idd de Belgische variant, stond hier toen ook op Tweakers, vreemd dat die niet bij gerelateerde content staat.Dat was niet NS, maar de Belgische variant.
De NS wil het liever ook niet hebben, maar gedoogd (iig) de applicatie Trein.Ik weet het niet zeker. Mss dat NS ook iets vergelijkbaars heeft geflikt.
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
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.
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.
Zoek maar op de NDOV-database.
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...
Maar goed het is de overheid dus moet waarschijnlijk langs 100 commissies of zo...
Bron.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.
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!
De NS heeft zelf al een topapplicatie (op Android en de iPhone), dus dat imago hebben ze zelf al een stuk verbeterd.
Topapplicatie is overdreven, er is nog genoeg ruimte voor verbetering. De betaalde third party app Trein vind ik vele malen beter...
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.
Misschien wel niet, misschien was het een overweging:Interessant, en weer een mooi voorbeeld van het onderschatten van de veiligheid.
- '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.
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.
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.
Rare titel van het artikel, ik dacht even dat de NS de API officieel ter beschikking had gesteld aan de developer. Maar het blijkt een soort clandestiene toegang te zijn? Betere titel is dan:Ontwikkelaar krijgt toegang tot NS-api voor treintijden
Ontwikkelaar verschaft zich toegang tot NS-api voor treintijden
Dat was dus ook mijn eerste gedachte. Best wel jammer, want bu kun je er alsnog weinig mee.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
