RESTful API eller direkte inn på database?

[stevehall]

Hei, jeg holder på å utvikle en app for behandling av biletter. Det er jo selvsagt en del database jobbing inn i bildet, og jeg lurte på om jeg burde bruke en RESTful API eller bare gå rett inn på databasen fra appen.

 

Nå hvis jeg ikke skulle ha tenkt på sikkerhet eller om jeg ikke skulle ha noe logikk imellom client og server hadde jeg selvagt gått for SQL løsningen, men det jeg er litt bekymret for er at noen ganske enkelt bare åpner kildekoden fra apk filen(tar 2 min fra å ha nedlastet apk'en til du sitter med lesbar kildekode på skjermen) og henter passord å brukernavn.

 

Så er det noen vits i a lage en RESTful api for database jobbing, eller finnes det andre bedre løsninger ?

 

Takk på forhånd

[Enthroner]

Det er flere positive sider med å lage et REST API hvis tiden kommer at du skal lage noe annet enn Android app av produktet ditt (iOS, Windows Phone, HTML...) så har du allerede en del av logikk og feilhåndtering gjort.

 

Det kan også være en god idé dersom du på sikt ser for deg å åpne noe av APIet for andre. Kanskje de som selger billetter vil ha en counter på siden sin etc etc.

 

Når det er sagt så kan du bruke obfuscation eller kryptering av passordet. Dersom Android ikke har feature for krypterte ressurser vil du ikke få til en 100% sikker løsning (de finnes vel strengt tatt ikke uansett...) men du kan komme nærme nok til at hobbyhackere gir opp. For eksempel som http://foo.jasonhudgins.com/2013/03/encrypting-string-resources-when-using.html

[vidor]

Bruk asymmetrisk krypto for sensitive ting. Best Practice.

[Enthroner]

Bruk asymmetrisk krypto for sensitive ting. Best Practice.

Det er riktig det, problemet som blir peket på her oppstår når man må lagre informasjon i kildekode på en trygg måte (hvor informasjon i værste fall er brukernavn og passord i klartekst, eller lagre hashen(e) i beste fall). Får man tilgang til koden så kan man også finne ut hva hashene representerer (særlig om man også ser hvilken hash-algoritme som er brukt).

[tingo]

Og hvorfor må man lagre sensitiv informasjon i kildekoden? Det er ikke sikkert, det kommer aldri til å bli sikkert - det er en dårlig løsning.

[stevehall]

Og hvorfor må man lagre sensitiv informasjon i kildekoden? Det er ikke sikkert, det kommer aldri til å bli sikkert - det er en dårlig løsning.

Hvor ellers skal man da lagre sensetiv data ?

[tingo]

I databasen selvfølgelig.

[Emancipate]

Ingen steder.

 

Du skal selvsagt ikke lagre brukernavn og passord som kan brukes til generell skriving/lesing i billettdatabasen noe sted på telefonen.

[Adrian E]

En kjekk regel, sensitiv informasjon hører kun hjemme på enheter du stoler på.

 

Så gå for et RESTful API, da skjer all skriving til og lesing fra databasen gjennom din egen server som du har kontroll på. For autentisering av brukeren finnes det flere løsninger som baserer seg nettopp på et REST API, bare å søke litt rundt så finner du nok noe som kan brukes. All kommunikasjon mellom klient og server må også foregå med asymmetrisk krypto.

 

Men alt om sikkerhet til side og til løsningen der klient kommuniserer direkte med databasen, hvis du endrer noe informasjon om databasepålogging, er du avhengig av at alle brukerne får en oppdatering. Skjer databasekontakt fra egen server med API, så trenger du kun å oppdatere informasjonen der og ingen oppdatering til brukerne.

[Enthroner]

Slik jeg forstod det så er dette en app uten login (altså man kan ikke generere tokens basert på en autentisert bruker for deretter å sjekke denne brukers rettigheter) så dersom man skal bruke et REST api vil man uansett lett kunne snappe opp:

a) hvordan appen selv autentiserer mot apiet ved å hente ut koden fra appen

b) hvilke kall som gjøres mot APIet (og headers query params etc) ved å sniffe trafikk mens man bruker app (proxy med wireshark f.eks)

 

Ellers kommer Adrian med et godt poeng over.

 

Jeg tror (hvis jeg har rett om at appen ikke har login) at du bør lage et API og deretter tenke at alt som skjer mot APIet like gjerne kunne vært dokumentert. Sålenge du sjekker at det APIet blir spurt om å gjøre er logisk så bør det være trygt nok.

[quantum]

vil man uansett lett kunne snappe opp:

a) hvordan appen selv autentiserer mot apiet ved å hente ut koden fra appen

b) hvilke kall som gjøres mot APIet (og headers query params etc) ved å sniffe trafikk mens man bruker app (proxy med wireshark f.eks)

 

 

Jepp, det spiller ingen rolle om man kompromitterer sensitive data over jdbc, rest, soap eller noe annet.

 

Når det er sagt, dersom klienten har SQL-tilgang gir man jo eventuelle inntrengere full aksess til å kjøre SQL (medmindre man ikke velger å implementere fin-inndelt tilgangskontroll i databasen, noe som er tungvint), dersom de skulle tilsnike seg tilgang, og det er enda værre enn om de kun fikk tilgang til et begrenset rest-api hvor muligheten til å gjøre skade kan være noe mindre. Det blir altså å velge mellom værre og værst...

 

Kjør rest og google litt om client-server architecture.

Endret 23. januar 2015 av quantum

[etse]

Essensen er at du ikke må gi klienten din mer tilgang enn hva du kan tillate et bruker å få også utenfor appen, altså må du forvente at enkelte brukere vill sette seg ned å reverse engineere autentiseringen og APIet. Dette gjelder uansett hvilket arkitektur du velger.

 

Den ene løsningen er selvfølgelig å bare la klienten koble rett til SQL-databasen, og dette er fullt mulig om du setter opp rettighetene på databasen helt korrekt. Men det er veldig lett å gjøre noe galt her, og konsekvensene av å gjøre noe galt kan være stort.

 

Om du setter opp et REST api, sperrer du hele databasen by default, for så å implementere støtte kun for de tingene du ønsker at brukeren skal ha tilgang til. Dette er mye lettere å gjøre sikkert, og det skal litt mer til å gjøre like store feil (selv om det selvfølgelig er fullt mulig). Og når du implementerer APIet må du bare ha i tankene at du aldri vet om et kall kommer fra din app, eller noen som utgir seg for å være appen din. Og implementert riktig så skal det ikke ha noe å si.

[j0achim]

Vi vet at kode enn så lenge man har tilgang til den vil aldri være 100% sikker.

 

Det du kan gjøre er dog at en som eventuelt prøver å hente ut nødvendig informasjon må igjennom andre verktøy for å få tak i informasjon som du prøver å skjule, eventuelt verktøy som obfuskerer kode, en tenker sikkert "security through obscurity" og strengt tatt så er det akkurat det, men ett godt verktøy som gjør denne jobben godt gjør det såpass bra at tid brukt på å prøve å oppnå målet som i dette tilfellet tilgang til back-end tilganger, blir mer nyttig ved hjelp av andre metoder f.eks., analysere pakker mellom klient og server, eventuelt prøve å finne nyttige verdier i minne. Verktøy som dette kommer følgelig i alle prisklasser fra freeware til entreprise som koster skjorten og litt til.

 

Dermed kan du lage ett nytt lag med sikkerhet mellom klient og tjener som kan utveksle API-nøkler basert på en hvilken som helst algoritme du måtte ønske, så selv om noen skulle klare å initiere kontakt med tjener vet man ikke den nøyaktige svar nøkkelen som klient eventuelt må bruke for gjøre ett nytt kall.

Endret 28. januar 2015 av j0achim