Sikkerhed på webservices

Tags:    diverse

Jeg har i den senere tid spekuleret over hvordan man kan sikre sine webservices mod at blive kaldt ude af kontekst ved at nogle ondsindede scripts laver kald med dummy data til den, og enten fylder min database med sludder eller henter data ud, de ikke har lov til at læse.

Hvordan sikrer I jeres webservices, samtidig med at de bliver så dynamiske som muligt så så meget logik som muligt kan være på klientsiden?

Password-beskyttelse er næppe en holdbar løsning, da Java-klienter let kan dekompileres og at JavaScript i forvejen er klar tekst. IP-låse er heller ikke vejen at gå, medmindre det er meget få personer der har fx skriverettigheder - men det duer ikke i fx et blogging community.



6 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 6 karma
Sorter efter stemmer Sorter efter dato
Hvad med hashkey der er låst til et domæne, og så en sandkasse til udvikling og test?

Det er den vej jeg har tænkt at hoppe, når jeg når til den del af det igangværende projekt.





Lad väre med at gå for meget i detaljer omkring client-side sikkerhed, Per.

Undgå at en given brugen kan postere data uden at väre logged in.

Du kan anvende CAPTCHA som "human-verification" når der skal posteres data, logges, oprettes en given bruger, osv.

CAPTCHA er ikke mere omständigt end al' anden form for sikkerhed imod bots...

Det er ikke så meget den almene bruger som er et "problem", snare bots, spiders, crawlers og hvad ellers al djävelskabet hedder.

IP-ADDR... tja... hvis verden var sådan så at vi alle havde fast IP adresse, så ja -- udentvivl det stärkeste redskab der findes, men så heldige er vi desväre ikke, så lige udmidbart: nej, fordi du har ingen garanti for at näste gang at en IP adresse (f.eks. 213.62.45.106)forsöger at besöge dit website at det så igen er en bot.

Hvis du endelig skal noget med IP-addr så skal du... så skal du lave noget IP verifikation... hvor du laver et whois-lookup, gemmer denne whois-lookup record og tester for et match nästegang IP-Addr'en(213.62.45.106) tilgård dit website IANN tilbyder IP whois-lookup.

Men det virker endnu mere omständigt på mig frem for CAPTCHA. Jeg hved at den nye version af PHPBB, version 3.x.x anvender sådan et whois-lookup system.



Clientside sikkerhed virker ikke.

Sikkerheden skal ligge på serversiden. Captchas på klientsiden virker til dels, specielt hvis selve svaret ikke står i captcha'en. F.eks. "Navnet på USA's 37. præsident" eller "Resultatet af 2856 * 1436".



Clientside sikkerhed virker ikke.

Sikkerheden skal ligge på serversiden. Captchas på klientsiden virker til dels, specielt hvis selve svaret ikke står i captcha'en. F.eks. "Navnet på USA's 37. præsident" eller "Resultatet af 2856 * 1436".

Det virker bare lidt omstændigt at have en captcha til alle operationer. Specielt operationer såsom en flytning af et element der helst skulle foregå onchange.

Hvad med hashkey der er låst til et domæne, og så en sandkasse til udvikling og test?

Hvordan vil du implementere det i praksis? hvis jeg fx har en chatklient, der sender requests til en webservice med en tekststreng der skal indsættes i bufferen, og returnerer den aktive buffers indhold - hvordan vil jeg kunne undgå at en anden laver bogus kald til den service og får indholdet af bufferen selvom den måske er privat, eller fylder den med reklamer om viagra? Giv gerne et eksempel på din idé med hashkey låst til et domæne.




Det virker bare lidt omstændigt at have en captcha til alle operationer. Specielt operationer såsom en flytning af et element der helst skulle foregå onchange.


Så bare en captcha ved login. De fleste orme er ikke målrettet et enkelt site, så de vil blive stoppet ved første login.




Det virker bare lidt omstændigt at have en captcha til alle operationer. Specielt operationer såsom en flytning af et element der helst skulle foregå onchange.


Så bare en captcha ved login. De fleste orme er ikke målrettet et enkelt site, så de vil blive stoppet ved første login.

Tjo, det vil jo nok holde størstedelen af de ondsindede scripts væk. Men det skulle jo helst være sådan at enkeltpersoner heller ikke kan sidde og høste info de ikke skal have, ved at gætte parameternavnene til de forskellige services, og så sende forkert info.

Derudover er det jo ikke nødvendigvis alle services der har login-funktionalitet.



Lad väre med at gå for meget i detaljer omkring client-side sikkerhed, Per.

Undgå at en given brugen kan postere data uden at väre logged in.

Du kan anvende CAPTCHA som "human-verification" når der skal posteres data, logges, oprettes en given bruger, osv.

CAPTCHA er ikke mere omständigt end al' anden form for sikkerhed imod bots...

Det er ikke så meget den almene bruger som er et "problem", snare bots, spiders, crawlers og hvad ellers al djävelskabet hedder.

IP-ADDR... tja... hvis verden var sådan så at vi alle havde fast IP adresse, så ja -- udentvivl det stärkeste redskab der findes, men så heldige er vi desväre ikke, så lige udmidbart: nej, fordi du har ingen garanti for at näste gang at en IP adresse (f.eks. 213.62.45.106)forsöger at besöge dit website at det så igen er en bot.

Hvis du endelig skal noget med IP-addr så skal du... så skal du lave noget IP verifikation... hvor du laver et whois-lookup, gemmer denne whois-lookup record og tester for et match nästegang IP-Addr'en(213.62.45.106) tilgård dit website IANN tilbyder IP whois-lookup.

Men det virker endnu mere omständigt på mig frem for CAPTCHA. Jeg hved at den nye version af PHPBB, version 3.x.x anvender sådan et whois-lookup system.

I min allerførste post redegør jeg for at jeg ikke synes clientside sikkerhed er en god idé. Jeg siger også at IP-låsning er en uholdbar løsning.

Alligevel bruger du hele din post på at fortælle mig det jeg allerede har sagt. Jeg værdsætter råd, men de må gerne være nogle jeg ikke allerede selv er kommet med :)

--- --- --- ---

Jeg tænker noget i stil med at ved starten af hver session lave en md5 af tidspunktet, og så gemme den hash i databasen med et brugerid som foreign key - hvis det er et brugerløst system eller at brugeren ikke er verificeret, vil det id så bare være 0 - gæst. Derefter vil den hash skulle sendes som et parameter til alle services, der så tjekker om den er gyldig, og derefter tjekker om dens relaterede ID har lov til at udføre den valgte operation. Er det en fornuftig vej at gå? Jeg har en fornemmelse af at det vil afhjælpe de fleste problemer med målrettede angreb på services med brugerverificering - men jeg ved stadig ikke hvor effektivt det er på brugerløse systemer.



Indlæg senest redigeret d. 23.06.2009 11:52 af Bruger #8223
t