Gå til innhold

Sikker kobling mot db via PHP?


Anbefalte innlegg

Lurer på om det er noen bedre måte å gjøre følgende på:

 

Sender for øyeblikket data til php for å hente ut/endre data fra/i databasen.

Denne metoden forhindrer jo at folk får tilgang på brukernavn/passord til databasen, men er den en "bedre"/tryggere måte å gjøre dette på?

 

Tenker da på å hindre at andre også kan sende data til php for å få ut/endre data

 

 

//EDIT:

post #4 har mer info!

Endret av stelar7
Lenke til kommentar
Videoannonse
Annonse

Lurer på om det er noen bedre måte å gjøre følgende på:

 

Sender for øyeblikket data til php for å hente ut/endre data fra/i databasen.

Denne metoden forhindrer jo at folk får tilgang på brukernavn/passord til databasen, men er den en "bedre"/tryggere måte å gjøre dette på?

 

Tenker da på å hindre at andre også kan sende data til php for å få ut/endre data

 

Sikkert mange måter å gjøre dette på, men så lenge du krypterer trafikken som går til og fra php-scriptet, så kan ikke andre få noe nytteverdig ut av det.

Endret av Untouchab1e
Lenke til kommentar

Sikkert lurt å spørre om dette i php-gruppa isteden. Tror også du bør forklare litt mer konkret hva du driver med, for å få fornuftig svar, men generelt kan du begrense tilgang til php-siden din ved bruk av

 

1) autentisering vha. brukernavn/passord, som f.eks. kan ligge lagret i databasen m. brukernavnet kryptert

2) filtrering på ip-adresse

3) plassere php-siden bak en brannmur

4) etc.

 

Det er også lurt å sette opp mysql slik at databasebrukeren som php-siden benytter kun får aksessere databasen fra den maskinen hvor php-kjører, og sørge for at denne brukeren ikke har flere rettigheter en nødvendig.

Lenke til kommentar

Mulig jeg ikke forklarte meg godt nok, beklager det!

 

Holder på å lage en applikasjon som krever innlogging mot en database, og skal deretter hente ut info med gjevne mellomrom. Databasen inneholder brukenavnet og passordhashen til brukeren, samt litt annet info (email, osv...).

For å hindre at uvedkommene tar påloggingsinformasjonen til databasen fra en decompilert versjon av applikasjonen så har jeg brukt PHP som et mellomlag der informasjon blir send til og fra databasen.(eksempel som sender data til og fra PHP)

PHP scriptet sender spørringer med PDO prepared statements, så anntar det gir beskyttelse mot SQL injections?

Databasebrukeren har 4 rettigheter, CREATE, DROP, UPDATE og SELECT (trenger disse av diverse grunner)

Har også noe kode som sender mail med JavaMail, der det kreves brukernavn/passord til en email konto. De ligger AES kryptert på en ekstærn server, henter det inn og decrypterer det, problemet her er at decrypteringsnøkkelen må ligge i JAR filen?

 

Det jeg ønsker å oppnå er:

 

1) KUN min applikasjon skal ha tilgang til PHP filen (tviler på at det er mulig)

2) Gjemme dekrypteringsnøkkelen slik at den ikke kan bli funnet ved hjelp av decompilering (har tenkt på en fil på en ekstærn server, men da kommer problem 1 inn igjen...)

3) En "bedre/lettere" måte å gjøre det på

Endret av stelar7
Lenke til kommentar

Det du har er altså en slags poor-mans-webservice på serveren implementert i PHP, fordi det ikke går an å kjøre java på serveren antar jeg.

 

Sånn jeg forstår det så logger brukeren din seg inn ved å oppgi brukernavn og passord til applikasjonen din, deretter sjekker applikasjonen dette mot php, og er det ok, så får applikasjonen fritt spillerom til å gjøre alt mulig annet som er tilgjengelig via php-scriptet, og dette frie spillerommet har også alle andre som kjenner api'et.

 

Her kan du jo først rydde opp litt og benytte webservice, REST eller noe annet fint. Men hovedpointet koker ned til at du må ha en autentisering i php/webservice/REST-tjenestene, klientsiden må altså autentiseres ved hvert eneste kall, evt. må applikasjonen din ha en autentisert http(s) sesjon og ha tilgang kun så lenge denne sesjonen lever.

 

Kikk litt rundt på stackoverflow så finner du helt sikkert svaret, ser ikke akkurat som som du er den eneste med slike spørsmål :)

Endret av quantum
Lenke til kommentar

Klikket rundt på stackowerflow før jeg postet her, men fant ikke noe særlig som var relevant til spørsmålene mine... Kan være at jeg bare er dårlig til å lete men...

 

ser at du nevner REST, hva er det for noe? er ikke POST en del av REST?

Endret av stelar7
Lenke til kommentar

Her sammenligner du epler og kaniner, se http://en.wikipedia.org/wiki/Representational_state_transfer

 

Lurer også litt på hva du har søkt etter hvis du ikke finner noe på stackoverflow ... prøv http://stackoverflow...+authentication

 

MEN, det kan godt hende du ønsker å gjøre ting enklest mulig, det er da ikke noe i veien for å bruke bare POST som du gjør nå, men du må likevel sørge for at du enten har en autentisert http(s)-sesjon eller sender med brukernavn/passord, eller et "token" som f.eks. checkLogin-metoden din kan motta fra serveren, med hvert kall, og som serversiden sjekker før den gjør noe som helst videre.

Endret av quantum
Lenke til kommentar
Gjest Slettet+9871234

Det gjør han jo allerede. Og akkurat hvordan skulle det avhjelpe autentiseringsproblemet?

 

Jeg var litt kjapp og leste bare første post.

 

Det jeg ønsker å oppnå er:

1) KUN min applikasjon skal ha tilgang til PHP filen (tviler på at det er mulig). Selvsagt er det mulig ved å bruke .htaccess om du er på en apache web server. Deny fra alle og allow kun fra egen Ip. Det er sikrere enn å begrense adgangen med et php skript.

2) Gjemme dekrypteringsnøkkelen slik at den ikke kan bli funnet ved hjelp av decompilering (har tenkt på en fil på en ekstærn server, men da kommer problem 1 inn igjen...) Å splitte nøkkelen i to og legge den på to ulike servere er sikrest, men der er du tilbake igjen.

3) En "bedre/lettere" måte å gjøre det på. Lage et profesjonelt authensierings program ved å studere hvordan det gjøres i for eksempel drupal.

Lenke til kommentar

Forsåvidt kan du bruke .htaccess, men ikke basert på IP, du må ha .htpasswd i tillegg, og det er kanskje litt primitivt å holde styr på brukerne på den måten i lengden.

 

Generelt mht. frykten for at sensitiv informasjon skal kunne dekompileres ut av applikasjonen:, enten det er url'er, nøkler eller noe annet, så kan det vel bare ligge i property-filer utenfor applikasjonen? Informasjonen kan oversendes bruker - i rekommandert brev om så skulle være nødvendig - og legges inn av bruker på lokal pc.

Endret av quantum
Lenke til kommentar

Generelt mht. frykten for at sensitiv informasjon skal kunne dekompileres ut av applikasjonen:, enten det er url'er, nøkler eller noe annet, så kan det vel bare ligge i property-filer utenfor applikasjonen? Informasjonen kan oversendes bruker - i rekommandert brev om så skulle være nødvendig - og legges inn av bruker på lokal pc.

Poenget er jo at applikasjonen skal kunne brukes av hvem som helst etter de har registrert en bruker(noe som tar 1min). MEN, de skal kun ha tilgang til de funksjonene som blir vist i applikasjonen, ikke alt som jobber i bakgrunnen(CREATE, DROP, ovs...)

Endret av stelar7
Lenke til kommentar
Gjest Slettet+9871234
KUN min applikasjon skal ha tilgang til PHP filen

 

Dersom brukerne ikke skal ha tilgang til den filen er der flere måter å begrense tilgangen for den generelle bruker. Legge filen i en mappe og

  1. sette ulike rettigheter på mappe og fil for bruker og administrator. Jeg gjør det ved å høyre klikke på mappe og / eller fil i remote (server) view i DW CS 6.
  2. Begrense tilgang ved å legge en .htaccess fil i den aktuelle mappe. Gjort med noen få linjer.
  3. Begrense tilgangen ved et php skript.

Personlig foretrekker jeg 1 og / eller 2 fremfor 3.

Endret av Slettet+9871234
Lenke til kommentar

Poenget er jo at applikasjonen skal kunne brukes av hvem som helst etter de har registrert en bruker(noe som tar 1min). MEN, de skal kun ha tilgang til de funksjonene som blir vist i applikasjonen, ikke alt som jobber i bakgrunnen(CREATE, DROP, ovs...)

 

ja? hvilken brikke er det egentlig du mener du mangler nå?

Lenke til kommentar

det er jo som du selv sier vanskelig å få til siden det skal være tilgjengelig hvorsomhelst fra, isteden må du autentisere hver request, altså få oversendt brukernavn og passord, enten med Authorization-headeren, eller på url'en eller noe annet, og la serversiden, enten i apache og v. bruk av .htaccess/.htpasswd, eller i php-kode, avgjøre om metoden som kalles skal få lov til å kjøre. Du kan holde styr på hvilke brukere som skal ha rett til å gjøre hva ved at du lagrer opplysninger om ulike rettigheter i databasen, eller som kgun foreslår, putte funksjoner som krever ulike rettigheter i ulike kataloger på tjeneren og bare gi brukerne tilgang til det det skal ha tilgang til vha .htaccess/.htpasswd. Evt. kan du ta en kikk til på stackoverflow for flere varianter, så det var nevnt et par autentiseringsrammeverk for php der.

Endret av quantum
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...