Kundedata lå åpent tilgjengelig i Rema 1000s Æ-app. – Jeg kunne lastet ned hele kundebasen

[tommyb]

 

Jeg vil komme med en morsom motpåstand; at jeg tror alle google-kyndige personer er i stand til å lære seg dette på en kveld

 

At man lærer seg dette på en kveld, tror jeg ikke noe særlig på.

 

Nå har ikke jeg sett på denne appen, men dersom man tar utgangspunkt i at den er installert på en iOS eller Android telefon, så skal man jo først sette opp noe for å overvåke trafikken og dekryptere TLS og den slags.

Nå er vel også denne handleappen tilgjengelig direkte på REMA sine nettsider, noe som gjør det lettere, men likevel.

 

Man skal altså først forstå hvordan det settes opp et lokalt nettverk som proxy for telefonen, hvordan programmer som Fiddler fungerer for å se dataene som sendes over nettverket, hvordan TLS fungerer, og hvordan man setter Android og Fiddler til å dekryptere slik at man kan se dataene som sendes.

 

Deretter skal man ha en grunnleggende forståelse for HTTP for å vite hvordan man endrer forespørslene og sender andre data til serveren, deretter skal man i det minste ha en grunnleggende forståelse for JavaScript for å lese JSON å forstå sammensetningen av dataene.

 

Når noen først har oppdaget feilen og dokumentert hvordan lenkene er bygget opp, så kan man nok sikkert lære seg på en kveld hvordan man gjør enkle forespørsler med wget, cURL, powershell eller lignende til api dot rema dot no.

 

Du er dog særs intelligent dersom du kan starte fra scratch, finne adressen til den api'en ved å overvåke nettverkstrafikken, finne ut hvordan forespørslene gjøres osv. og lære alt dette på en kveld, de fleste bruker betydelig lengre tid på å tilegne seg den kunnskapen.

 

 

Når selv det mest kompliserte leddet beskrives så enkelt som dette, så jo, da tror jeg fortsatt på at en kveld med info-uthenting er nok: 

 

 

 

I ran into the same issue. First - make sure you have it all set up correctly on Fiddler on your PC:

1. Goto Tools-->Fiddler Options-->HTTPS and make sure the first 3 check boxes are checked.
2. Click "Export Root Certificate to Desktop" and copy the cert file from your desktop to your device/SD card
3. In your device, goto setting-> security -> Credential Storage-> Install from SD Card , and install your certificate.

That's it. worked for me

 

Men jeg kan jo ta feil, det skjer stadig vekk.  

[abooAyoob]

Synes pressemeldingen til rema1000 er blant det værste her, ekstremt frekt. Synes også det er svært kjedelig med såpass dårlig journalistisk arbeid av digi.no, makan?

Nrk er mye flinkere på deres hjemmebane i denne saken:

https://www.nrk.no/norge/sjef-i-ikt-norge-_-bekymringsfull-handtering-av-rema-1.13355421

[Viandre]

Vi mennesker fokuserer alt for mye på det negative, og glemmer helt hva som er positivt. Jeg personlig kunne ikke ha brydd meg mindre om andre kunne se hva jeg handlet og det finnes jo allerede apper for det (mye mindre komplekst enn å kode seg til å få sett). Hadde dette vært en butikk med dyre ting som tv-er osv. Så ja, da ville det ha vært dumt med tanke på de som liker å bryte seg inn og ta eiendelene dine. Men dette er matvarer da folkens. Og mens vi sitter her og klager, så har Google, facebook og andre nettsteder både adresse og punktlig plassering på deg til enn hver tid.

[PgUp]

Vi mennesker fokuserer alt for mye på det negative, og glemmer helt hva som er positivt. Jeg personlig kunne ikke ha brydd meg mindre om andre kunne se hva jeg handlet og det finnes jo allerede apper for det (mye mindre komplekst enn å kode seg til å få sett). Hadde dette vært en butikk med dyre ting som tv-er osv. Så ja, da ville det ha vært dumt med tanke på de som liker å bryte seg inn og ta eiendelene dine. Men dette er matvarer da folkens. Og mens vi sitter her og klager, så har Google, facebook og andre nettsteder både adresse og punktlig plassering på deg til enn hver tid.

Hadde vært litt kjipt om noen stjal identiteten din og begynte å scamme folk på nettet dog i ditt navn.

[timeshift]

...

 

Her tror jeg at du kan ha misoppfattet hva saken handler om. Saken omhandler ikke overdreven datainnsamling (kanskje den likevel burde det?), men at de innsamlede dataene ikke var forsvarlig sikret mot innsyn i fra uvedkommende.

 

Dersom det eneste dataene kunne fortelle oss var at Maria kjøper melk og smør så ville det kanskje ikke ha vært så farlig dersom hele verden ville få kunnskap om det, men her er det snakk om ganske mange detaljopplysninger som når man kobler det sammen kan misbrukes. At opplysningene ikke var forsvarlig sikret mot innsyn i fra uvedkommende er alvorlig.

 

Blant de dataene varsleren hadde tilgang til så var det funnet opplysninger tilknyttet kjøp av graviditetstest som ved hjelp av telefonnummeret kunne kobles til kjøper, i mange tilfeller vil også kjøper være bruker. De fleste vil nok forstå at kjøp som graviditetstest er informasjon som krever fortrolighet. Du ønsker ikke at Olsen på hjørnet, Stiansen på jobben, vilkårlige foreninger og andre skal kjenne til at du kanskje er gravid før du engang har fått anledning til å fortelle det til partneren og familien din. Dette er åpenbart informasjondeling folk ønsker å styre selv.

 

Er enig med deg i at vi mennesker ofte fokuserer altfor mye på det negative i det daglige, men i denne saken så finnes det ikke mye positivt å hente. Folk har god grunn til å være både skuffet og sinte. Rema 1000 har ikke bare sviktet grovt med å ivareta sikkerheten, dem har også sviktet grovt i håndteringen av saken. Når håndteringen er så arrogant og tilslørt som den er så er det også vanskelig å stole på at eventuelle tiltak som er gjort er utført skikkelig denne gang.

[Børt-Erik]

Synes også det er svært kjedelig med såpass dårlig journalistisk arbeid av digi.no, makan?

 

Ja, det er utrolig at folk får lønn for å bedrive slik 'gutteromsjournalistikk'.

[Frode Bergeton Nilsen]

Har Rema bedriftskultur til å drive på med IKT ala "Æ"? Det virker ikke helt sånn. Ting har fort blitt rotete, komplisert, og vanskelig. Hvis det enkle ofte er det beste, så er ikke Rema best lenger. Ikke med det rotet de har dratt igang her.

[Paynster]

 

Er litt morsomt at Rema og utviklerne ikke ser forskjell på kryptert data og kryptert trafikk. Hadde de kryptert data, ville vedkommende "hacker" kun fått tilgang til sine egne opplysninger i ytterste tilfelle. Hadde de gjort det korrekt, ville ikke "hackeren" fått tilgang til egne data heller.

Men godt å vite at Shortcut lever opp til navnet

 

Sjeldent/aldri krypteres hele databaser, ytelsestapet er for stort og det er også mange praktiske utfordringer. Man krypterer bare data som man må.

 

Eller så finner jeg det spennende at du foreslår at data skal krypteres så brukeren ikke selv kan lese sine data, kanskje tenke gjennom det forslaget en gang til

 

Eller så tilbake til saken synes jeg det er litt overaskende at så mange ser ut til å ville gjøre Nygård til en helt i dette.

Han hentet ut data for 3400 kunder, så mye data er ikke nødvendig for å lage "proof of concept". Skal ikke spekulere for mye om hvorfor han valgte å hente ut så mye data, men det er ingen god grunn til at han skulle gjøre det.

 

Man trenger da ikke kryptere hele databasen, hvis man bygger opp systemet fornuftig. Muligens det er noe kostnad i å kryptere transaksjonene, men med en 20K transaksjoner i minuttet ca, så utgjør ikke denne krypteringen noe i det tilfellet jeg tenke på. Så kommer det også an på sikkerhet vs sensitivitet vs kostnad. Og at brukeren ikke kan lese egne data, eh, så lenge klienten til brukeren skal lese data, er ikke nødvendig at brukeren selv får tilgang til det via APIet med en nettleser eller et annet verktøy.

[0laf]

Man trenger da ikke kryptere hele databasen, hvis man bygger opp systemet fornuftig. Muligens det er noe kostnad i å kryptere transaksjonene, men med en 20K transaksjoner i minuttet ca, så utgjør ikke denne krypteringen noe i det tilfellet jeg tenke på.

Transaksjonene er allerede kryptert med TLS, det som mangler er verifikasjon av den som forespør dataene.

 

Og at brukeren ikke kan lese egne data, eh, så lenge klienten til brukeren skal lese data, er ikke nødvendig at brukeren selv får tilgang til det via APIet med en nettleser eller et annet verktøy.

Det benyttes http til å gjøre forespørsler. Å benytte andre protokoller vil generelt være lite hensiktsmessig og vanskelig å implementere. 

 

Så lenge app'en sender forespørsler i http, og API'en svarer på slike forespørsler, så vil det alltid være mulig å sende akkurat den samme forespørselen med en nettleser eller et annet verktøy, å få akkurat de samme dataene tilbake.

 

Det vil selvfølgelig være mulig å implementere en eller annen ende til ende krypteringen på klientsiden i app'en, men selv da vil nøkkelen allerede være hos klienten, og det vil fremdeles være mulig å spoofe forespørselen.

 

Poenget er uansett ikke å gjøre dataene utilgjengelige for den brukeren som skal ha tilgang til de, det vil være svært upraktisk, poenget er å gjøre dataene utilgjengelige for andre brukere som ikke bør ha tilgang til de.

[_dundun_]

Så lenge app'en sender forespørsler i http, og API'en svarer på slike forespørsler, så vil det alltid være mulig å sende akkurat den samme forespørselen med en nettleser eller et annet verktøy, å få akkurat de samme dataene tilbake.

Det er trivielt å implementere beskyttelse mot replay-angrep i et API. Jeg har gjort det selv flere ganger. Om man bruker http eller https har fint lite å si i den sammenhengen. 

 

Det er flott at Rema brukte TLS på transporten, men det er på ingen måte et forsvar for å "glemme" hele sikkerheten på APIet.

Endret 8. februar 2017 av Audun_K

[0laf]

Det er trivielt å implementere beskyttelse mot replay-angrep i et API. Jeg har gjort det selv flere ganger. Om man bruker http eller https har fint lite å si i den sammenhengen. 

 

Replay-angrep sikrer man enkelt mot ved å bruke TLS over nettverket, og sende en nonce med hver forespørsel.

 

Det virker dog lite hensiktsmessig med nonce her, poenget er vel heller ikke å sikre mot replay-angrep, men fremdeles kun å verifisere den brukeren som gjør forespørselen etter data.

[_dundun_]

Ja, så jeg forstår ikke helt hvorfor du snakka om replay - den gigantiske (og virkelig utilgivelige) feilen til Rema var å ikke verifisere brukeren. Det er en så stor feil at jeg ikke fatter hvordan Shortcut kan få en eneste kunde til. Hvis ikke det var et krav fra Rema sin side såklart, men det kan jeg ikke tro det var.

Endret 8. februar 2017 av Audun_K

[0laf]

Ja, så jeg forstår ikke helt hvorfor du snakka om replay - den gigantiske (og virkelig utilgivelige) feilen til Rema var å ikke verifisere brukeren. 

 

For ordens skyld, så var det deg som snakket om replay-angrep, ikke meg.

 

Jeg kommenterte kun et innlegg som hevdet at brukeren ikke burde få tilgang til API'en med en nettleser eller et annet verktøy i det hele tatt, noe som er helt umulig så lenge forespørslene går over http-protokollen som alle nettlesere støtter.

 

Det er selvfølgelig mulig å implementere ting som gjør det langt vanskeligere å bruke en nettleser til å få tilbake de samme dataene som app'en, men det spiller jo egentlig liten rolle her, med en proxy og litt fiksfakseri så kan man uansett se forespørslene app'en gjør.

 

Det er jo en gang slik at man ikke kan gjemme data fra brukeren som brukeren skal se, det sier seg litt selv.

[Paynster]

 

Man trenger da ikke kryptere hele databasen, hvis man bygger opp systemet fornuftig. Muligens det er noe kostnad i å kryptere transaksjonene, men med en 20K transaksjoner i minuttet ca, så utgjør ikke denne krypteringen noe i det tilfellet jeg tenke på.

Transaksjonene er allerede kryptert med TLS, det som mangler er verifikasjon av den som forespør dataene.

 

Og at brukeren ikke kan lese egne data, eh, så lenge klienten til brukeren skal lese data, er ikke nødvendig at brukeren selv får tilgang til det via APIet med en nettleser eller et annet verktøy.

Det benyttes http til å gjøre forespørsler. Å benytte andre protokoller vil generelt være lite hensiktsmessig og vanskelig å implementere. 

 

Så lenge app'en sender forespørsler i http, og API'en svarer på slike forespørsler, så vil det alltid være mulig å sende akkurat den samme forespørselen med en nettleser eller et annet verktøy, å få akkurat de samme dataene tilbake.

 

Det vil selvfølgelig være mulig å implementere en eller annen ende til ende krypteringen på klientsiden i app'en, men selv da vil nøkkelen allerede være hos klienten, og det vil fremdeles være mulig å spoofe forespørselen.

 

Poenget er uansett ikke å gjøre dataene utilgjengelige for den brukeren som skal ha tilgang til de, det vil være svært upraktisk, poenget er å gjøre dataene utilgjengelige for andre brukere som ikke bør ha tilgang til de.

 

 

Bruker != klient && JSON/AJAX != http.

 

Det finnes gode alternativ til både dataserialisering og protokoller, alt fra klartekst til ende til ende kryptert binær og komprimert data. Jeg tolker det du kaller "forespørsler over http" som "human-readable data-serialization", som for lenge siden skulle gjøre utvikling "enklere" og såkalt "rapid". Men med dagens verktøy er dette en passé doktrine, og fokuset nå heller mer og mer over på type-sikker, maskin-vennlig komprimert og kryptert data.

 

Man skal utvikle et system som er sikkert ovenfor klienten, og hvis man ikke har en sikker måte til å håndtere feks et private/public nøkkelpar og få total sikker kommunikasjon mellom klient/tjener, så bør man ikke utvikle tjenester.

 

Dette er tema som er enda viktigere nå fremover, nå som myndigheter og politikere velger å selge vår alles personvern og retten til privatliv, for en tynn illusjon av trygghet, aka Digitalt Grensevern.

 

De argumentene du hadde kunne sikkert vært passende for to til fem år siden, men det har skjedd rasende mye siden den tiden. Get up to speed, oldtimer!

[0laf]

Bruker != klient && JSON/AJAX != http.

 

Det finnes gode alternativ til både dataserialisering og protokoller, alt fra klartekst til ende til ende kryptert binær og komprimert data. Jeg tolker det du kaller "forespørsler over http" som "human-readable data-serialization", som for lenge siden skulle gjøre utvikling "enklere" og såkalt "rapid". Men med dagens verktøy er dette en passé doktrine, og fokuset nå heller mer og mer over på type-sikker, maskin-vennlig komprimert og kryptert data.

 

 Klienten er selvfølgelig applikasjonen som gjør forespørslene, brukeren er personen som bruker applikasjonen.

Det er jo derfor jeg skiller mellom å bruke "klienten" og "brukeren" i mine innlegg?

 

Normalt henviser man til klientsiden og serversiden når man omtaler sending av data på denne måten.

 

JSON er et dataformat for tekst, punktum. Det har ingenting med hverken Ajax, protokoller eller programmeringsspråket å gjøre.

 

Ajax står for "Asynchronous Javascript And Xml", og i de fleste tilfeller vil det bety bruk av XMLHttpRequest, som igjen kun støtter protokollene http, file og ftp, og det er i grunn førstnevnte som er interessant for å sende data på den måten det gjøres her.

 

Når jeg skriver "http" så mener jeg altså protokollen, og her benyttes http protokollen sammen med TLS, altså "https", som fremdeles er "http" protokollen, men kryptert.

 

At du mener dette er passé og at jeg er gammeldags, får du selv stå for, i min verden er dette fremdeles måten man gjør slikt på.

 

Man skal utvikle et system som er sikkert ovenfor klienten, og hvis man ikke har en sikker måte til å håndtere feks et private/public nøkkelpar og få total sikker kommunikasjon mellom klient/tjener, så bør man ikke utvikle tjenester.

 

Ingenting er sikkert, men at denne appen kunne vært sikrere er det lite tvil om. Likevel er asymmetrisk kryptering ala Difffie-Hellman helt unødvendig for en slik app, det er ikke kryptering det står på, det er, igjen, verifisering. 

Endret 8. februar 2017 av adeneo

[_dundun_]

Ja, kryptering er underordnet her. En god regel er som jeg har sagt tidligere i tråden å anse enhver klient som forsøker å koble seg til API som en fiende og kun gi tilgang til akkurat det som trengs, og å ha aksesskontroll på flere steder i systemet. Det er enkle greier dette her.

[Paynster]

 

Bruker != klient && JSON/AJAX != http.

 

Det finnes gode alternativ til både dataserialisering og protokoller, alt fra klartekst til ende til ende kryptert binær og komprimert data. Jeg tolker det du kaller "forespørsler over http" som "human-readable data-serialization", som for lenge siden skulle gjøre utvikling "enklere" og såkalt "rapid". Men med dagens verktøy er dette en passé doktrine, og fokuset nå heller mer og mer over på type-sikker, maskin-vennlig komprimert og kryptert data.

 

 Klienten er selvfølgelig applikasjonen som gjør forespørslene, brukeren er personen som bruker applikasjonen.

Det er jo derfor jeg skiller mellom å bruke "klienten" og "brukeren" i mine innlegg?

 

Normalt henviser man til klientsiden og serversiden når man omtaler sending av data på denne måten.

 

JSON er et dataformat for tekst, punktum. Det har ingenting med hverken Ajax, protokoller eller programmeringsspråket å gjøre.

 

Ajax står for "Asynchronous Javascript And Xml", og i de fleste tilfeller vil det bety bruk av XMLHttpRequest, som igjen kun støtter protokollene http, file og ftp, og det er i grunn førstnevnte som er interessant for å sende data på den måten det gjøres her.

 

Når jeg skriver "http" så mener jeg altså protokollen, og her benyttes http protokollen sammen med TLS, altså "https", som fremdeles er "http" protokollen, men kryptert.

 

At du mener dette er passé og at jeg er gammeldags, får du selv stå for, i min verden er dette fremdeles måten man gjør slikt på.

 

Man skal utvikle et system som er sikkert ovenfor klienten, og hvis man ikke har en sikker måte til å håndtere feks et private/public nøkkelpar og få total sikker kommunikasjon mellom klient/tjener, så bør man ikke utvikle tjenester.

 

Ingenting er sikkert, men at denne appen kunne vært sikrere er det lite tvil om. Likevel er asymmetrisk kryptering ala Difffie-Hellman helt unødvendig for en slik app, det er ikke kryptering det står på, det er, igjen, verifisering. 

 

 

Som sagt, det var inntrykket jeg satt igjen med. Greit nok at ikke Æ er statshemmeligheter, men like vel er innholdet av sensitiv art, alt etter hva man handler. En fyr som er samboer med ei som har sterilisert seg, blir ganske avslørt hvis han handler gummi, så for han vil det kunne være ganske så sensitivt. Derfor er det ikke opp til hverken brukerene som gruppe, utviklerne eller eieren av tjenesten som skal definere sensitiviteten, men den individuelle brukeren som kan oppleve sine data som svært sensitive. Derfor er det ikke annet enn å vise kundene sine respekt å alltid ta høyde for den høyeste grad av sensitivitet. Nøkken og glid kan i ytterste tilfelle føre til selvmord, og jeg, som avgjørende innflytelse og lederansvar i et av de mer seriøse utviklingshusene her i landet, er ganske så nazi på dette.

Endret 8. februar 2017 av Paynster