|
|
 | JDBC - Skjule brugernavn og adgangskode
Fra : Ryan Dahl |
Dato : 07-07-04 11:59 |
|
Hej,
jeg vil gerne tilgå en database fra en java-applet, men er lidt
usikker på sikkerheden i en sådan løsning.
Databasen bruger et specifikt sæt brugernavn/adgangskode - som gerne
skal skjules for brugere, herunder de mere nysgerrige sjæle.
Hvor og hvordan opbevares brugernavn/adgangskode bedst - og hvad er
evt. sikkerhedsrisici?
På forhånd tak
Ryan
| |
 Anon (07-07-2004)
| Kommentar
Fra : Anon |
Dato : 07-07-04 13:32 |
|
Ryan Dahl wrote:
> Databasen bruger et specifikt sæt brugernavn/adgangskode - som gerne
> skal skjules for brugere, herunder de mere nysgerrige sjæle.
> Hvor og hvordan opbevares brugernavn/adgangskode bedst - og hvad er
> evt. sikkerhedsrisici?
Ikke at jeg kan bidrage med en løsning, men blot gøre opmærksom på, at
enhver med en pakkesniffer vil kunne fange brugernavn/password sendt fra
en applet. Du har ikke mulighed for at afvikle som en servlet i stedet?
Anon
| |
Filip Larsen (07-07-2004)
| Kommentar
Fra : Filip Larsen |
Dato : 07-07-04 16:24 |
|
Ryan Dahl skrev
> jeg vil gerne tilgå en database fra en java-applet, men er lidt
> usikker på sikkerheden i en sådan løsning.
>
> Databasen bruger et specifikt sæt brugernavn/adgangskode - som gerne
> skal skjules for brugere, herunder de mere nysgerrige sjæle.
Du skal først gøre dig klart hvem og hvilke handlinger du forsøger at
sikre dit system imod. Dernæst er det nemmere at se hvilke muligheder du
har.
Som grundprincip kan du dog gå ud fra, at usikrede dele af dit system
(dvs. dele du ikke har sikkerhedsmæssig kontrol over, såsom applets der
bruges på usikrede computere) kan aflæses og ændres fuldstændig af en
seriøs angriber og at disse deles kommunikation med sikrede dele (som
fx. din database) derfor kræver speciel sikring af, at protokollen
bliver overholdt.
I forbindelse med JDBC brugernavn og password i klienter (fx applets),
så er det generelt en god ide at oprette en speciel bruger i databasen
der kun har adgang til de tabeller og operationer der benyttes af
klienten. For komplicerede adgangs- og valideringforhold kan man som
regel komme langt med stored procedures. Hvis dine sikkerhedsinvarianter
(altså de "udsagn" der altid skal gælde for at dit system kan betegnes
som sikkert) er afhængige af klientens kommunikationshistorie, så kan
det bliver nødvendigt at vedligeholde sessionsdata på serveren.
Selvom det godt kan lade sig gøre at bygge et sikkert klient-server
system med en fed klient, så er det dog som regel en mere fleksibel
løsning i længden at benytte 3-delt arkitektur hvor klinterne snakker
med en eller flere kommunikationsservere der igen snakker med en
databaseserver (klienterne har altså ikke direkte adgang til databasen).
Databaseserveren bruges her til det den er god til, nemlig at håndtere
data, mens kommunikationsserveren håndterer sessionsdata og
forretningslogik.
Mvh,
--
Filip Larsen
| |
Ryan Dahl (09-07-2004)
| Kommentar
Fra : Ryan Dahl |
Dato : 09-07-04 22:40 |
|
Jeg takker for de gode tilbagemeldinger, og holder mig ihvertfald
foreløbig til server-side validering.
mvh
Ryan
| |
Martin Kofoed (08-07-2004)
| Kommentar
Fra : Martin Kofoed |
Dato : 08-07-04 06:42 |
|
On Wednesday 07 July 2004 12:58, Ryan Dahl wrote:
> jeg vil gerne tilgå en database fra en java-applet, men er lidt
> usikker på sikkerheden i en sådan løsning.
Det er generelt en dum ide at lave SQL direkte fra en applet. Den kommer jo
til at ligge på brugernes maskiner, og kan så let som ingen ting decompiles
og ændres.
SQL hører til på serversiden. En applet kan så eksempelvis bruges til at
kalde specifikke metoder på serveren, der laver validering og kalder ind i
db-laget. Entry point kunne eksempelvis være en servlet eller en web
service. Hvis man absolut VIL benytte en applet til præsentationen .. :)
På serversiden kan du så lave en connection pool i eksempelvis Tomcat,
således at user + password hænger på denne. Derefter kan du kalde
getConnection() uden at angive user + password nogen steder.
--
Martin Kofoed
| |
|
|