[WCF] Service security

[Phyxion]

Ik wil graag een WCF (data) service aanmaken echter wil ik niet dat elke willekeurige applicatie hier verbinding mee kan maken. Nu staan er op MSDN een aantal methodes om dit te blokkeren maar zover mij duidelijk werd hebben alle methodes SSL certificates nodig. Echter heb ik alleen FTP toegang tot het systeem en kan ik niet certficates genereren op de host. Een andere oplossing was om username en password in de headers mee te sturen maar aangezien alles dan static is kan dit eenvoudig gesniffed worden zodat andere applicaties hier met de gesnifte gegevens ook nog verbinding mee kunnen maken. Ik had al even op Google e.d. gezocht maar ik kon niet echt andere oplossingen vinden. Zijn er ook manieren om een service te limiten tot een enkele client met de bovengenoemde limitaties?

[RobIII]

Simpelste: gewoon in IIS (of de WCF service zelf) limiteren op 1 ip

[ Voor 21% gewijzigd door RobIII op 30-05-2011 13:33 ]

[Phyxion]

RobIII schreef op maandag 30 mei 2011 @ 13:33:
Simpelste: gewoon in IIS (of de WCF service zelf) limiteren op 1 ip

Nee, er moeten wel meerdere clients tegelijk verbinding mee kunnen maken, echter wil ik niet dat iemand anders een andere client gaat schrijven voor de service.

[CodeCaster]

Simpel zat: zolang je het verkeer niet versleutelt, zal elke methode gesniffed kunnen worden. Je kunt zelf een challenge/response-implementatie gaan schrijven, of gewoon even een certificaat (laten) genereren.

[Snake]

Bij het opzetten van de sessie een unique id laten meegeven, en die kunnen ze dan laten genereren op een van jouw pagina's. En dan kan jij mooi bijhouden hoeveel mensen er een key hebben.

[CodeCaster]

... en dan leest Jantje de key van Pietje uit het netwerkverkeer, en kan hij alsnog bij de service. Of, als het om Jantje gaat die een eigen client wil implementeren (want: geen reclame, of bruikbaar op een ander platform, of ...), dan snifft Jantje gewoon het verkeer van een legitieme client op z'n eigen PC en bouwt op basis van de gesniffte data (endpoint en credentials / ID) een eigen client.

[ Voor 60% gewijzigd door CodeCaster op 30-05-2011 13:45 ]

[RobIII]

Dan kun je nog eens gaan kijken naar een Challenge/Response systeem. Dat is denk ik as close as it gets.

[Phyxion]

CodeCaster schreef op maandag 30 mei 2011 @ 13:42:
... en dan leest Jantje de key van Pietje uit het netwerkverkeer, en kan hij alsnog bij de service.

Precies.

CodeCaster schreef op maandag 30 mei 2011 @ 13:40:
Simpel zat: zolang je het verkeer niet versleutelt, zal elke methode gesniffed kunnen worden. Je kunt zelf een challenge/response-implementatie gaan schrijven, of gewoon even een certificaat (laten) genereren.

Ik heb helaas geen mogelijkheid om een certficaat te (laten) genereren. Echter, zolang alles hetzelfde is wat overgestuurd wordt kan dat natuurlijk eenvoudig gesniffed worden en zit je met hetzelfde probleem.

[riezebosch]

Kan je niet een scriptje maken wat op de server een certificaat maakt + installeert?

[Phyxion]

riezebosch schreef op maandag 30 mei 2011 @ 13:52:
Kan je niet een scriptje maken wat op de server een certificaat maakt + installeert?

Zoals vermeld heb ik alleen maar FTP toegang en meer rechten heb ik helaas niet.

[Caelorum]

Een andere host zoeken dan?

[Phyxion]

Caelorum schreef op maandag 30 mei 2011 @ 14:09:
Een andere host zoeken dan?

Helaas is dat nog geen optie op dit moment

[Herko_ter_Horst]

Waterdicht ga je dit niet krijgen en als je het al oplost, krijg je een "wapenwedloop". Als dit makkelijk op te lossen was, hadden consolebouwers ook geen problemen met het uitsluiten van gehackte consoles.

De afweging is: hoe belangrijk is het nou echt en hoeveel effort (tijd/geld) wil je er in steken?

[Woy]

In principe moet het volgens mij ook best mogelijk zijn om een Certificaat uit een andere store te laden. Je kunt dan dus gewoon een certificaat maken, en die uploaden via FTP. Je moet dan alleen wat code schrijven om het juiste certificaat te laden.

Afhankelijk van hoe het systeem werkt kun je natuurlijk ook met Client certificaten gaan werken.

[Phyxion]

Herko_ter_Horst schreef op maandag 30 mei 2011 @ 14:24:
Waterdicht ga je dit niet krijgen en als je het al oplost, krijg je een "wapenwedloop". Als dit makkelijk op te lossen was, hadden consolebouwers ook geen problemen met het uitsluiten van gehackte consoles.

De afweging is: hoe belangrijk is het nou echt en hoeveel effort (tijd/geld) wil je er in steken?

Het is in principe belangrijk dat het niet zomaar beschikbaar is voor iedereen, echter bevat het geen persoonlijke data.

Woy schreef op maandag 30 mei 2011 @ 14:27:
In principe moet het volgens mij ook best mogelijk zijn om een Certificaat uit een andere store te laden. Je kunt dan dus gewoon een certificaat maken, en die uploaden via FTP. Je moet dan alleen wat code schrijven om het juiste certificaat te laden.

Afhankelijk van hoe het systeem werkt kun je natuurlijk ook met Client certificaten gaan werken.

Dat klinkt wel interessant als dat mogelijk is, dan moet het ook mogelijk zijn om de SSL encryptions e.d. te gebruiken op MSDN lijkt mij.

[Woy]

Phyxion schreef op maandag 30 mei 2011 @ 14:32:
[...]
Dat klinkt wel interessant als dat mogelijk is, dan moet het ook mogelijk zijn om de SSL encryptions e.d. te gebruiken op MSDN lijkt mij.

Het is wel een beetje afhankelijk van hoe het een en ander geconfigureerd is. Als het HTTPS activation is, dan word het certificaat compleet door IIS geregeld ( Maar daar heb jij blijkbaar geen toegang toe, want anders had je geen probleem gehad ). Bij net.tcp of http activation zou het wel mogelijk moeten zijn om zelf je certificaat te laden ( d.m.v. een behavior of een custom ServiceHostFactory ). Client Certificates is natuurlijk weer een ander verhaal.

[ Voor 24% gewijzigd door Woy op 30-05-2011 14:57 ]

[riezebosch]

The Code Project: http://www.codeproject.com/KB/WCF/wcfcertificates.aspx. Over het laden van certificaten vanaf schijf.