Flash website, webservices beschermen hoe?

[pappavis]

Voor een website zijn wij bezig met een Flex applicatie (waar een Flash-file uit voortkomt) die verbinding maakt met een aantal ASP.NET webservices.

De Flash-file verbindt direct naar de webservices. Het probleem is dat onze webservices van buitenaf bereikbaar zijn. De webservices hebben dus geen bescherming. Deze webservices worden gebruikt vanaf een publieke website die redelijk wat bezoekers zal gaan krijgen, dus het is een vrij groot risico om de webservices vrij toegankelijk te hebben voor iedereen die weet waar 'ie ze moet zoeken.

Wij willen de webservices daarom dus gaan beschermen, maar de vraag is wat het meest efficiënt en snelst is om te implementeren, omdat we momenteel weinig tijd hebben om een zeer uitgebreide methode te implementeren. Na de eerste beveiligingsstappen (nu dus) zullen we verder aan de beveiliging gaan werken.

Huidige situatie
Flash website met flash pagina logt in op website, maakt extensief gebruik van webservices. Die webservices hebben géén beveiliging.

[list=1]Voorbeeld huidige (Login) procedure
• Gebruiker start browser, surft naar onze website, die de flashfile download/toont
• gebruiker typt in textbox zijn gebruikernaam + wachtwoord, gebruiker klikt op OK-knop.
• SWF pagina roept onze webservices aan.
• Webservices geven response terug naar SWF.
• SWF verwerkt die response en geeft zo bijvoorbeeld resultaten weer.

Wij denken tussen stap (3) en (4) "iets" te installeren, om het te beveiligen. Maar de vraag is wat? En hoe?

We hebben de volgende mogelijkheden gebrainstormed:
[list]• Webservices tunneling via VPN.
• IIS Basic Authentication
• Proxy server forwards request naar webservices
• Firewall met DMZ naar webserver
• elke webservice ASMX herbouwen, om per method een extra param "secureID"-param te accepteren.
• flash vraagt een session aan van IIS, en functioneert binnen een sessie
• HTTPS tripleDES/ PKI certificaten
• anders..???


Allen van bovenstaand duurt te lang, of levert veel testwerkzaamheden op (waar we momenteel geen tijd voor hebben), of eist ervaring die boven ons niveau zitten.

De oplossing hoeft niet bijzonder uitgebreid en/of sterk te zijn, zolang het maar niet zo lek als een mandje is want dat is het nu wel. Dus als iemand suggesties heeft om webservices te beschermen, dan horen wij dit graag.

Alvast bedankt!

[RaZ]

pappavis schreef op woensdag 31 maart 2010 @ 16:46:
[..]
Wij willen de webservices daarom dus gaan beschermen, maar de vraag is wat het meest efficiënt en snelst is om te implementeren, omdat we momenteel weinig tijd hebben om een zeer uitgebreide methode te implementeren. Na de eerste beveiligingsstappen (nu dus) zullen we verder aan de beveiliging gaan werken.
[..]

Enkel het IP van de server toelaten op de webservices.

[Hahn]

Dat hebben we (ik ben een collega van pappavis) dus gedaan, maar dat is dus een probleem in combinatie met flash. Want de flash-file wordt gedownload door de gebruiker (hij blijft het wel zien op de website, maar de .swf-file komt op de computer te staan) en vervolgens gaat Flash via het IP van de gebruiker verbinding proberen te maken met de webservices.

Maar als alleen het IP van de server toe wordt gelaten (zoals momenteel het geval is), dan gebeurt er dus gewoonweg niks, omdat het IP van de gebruiker niet is toegelaten.

[Japius]

RaZ schreef op woensdag 31 maart 2010 @ 16:49:
[...]
Enkel het IP van de server toelaten op de webservices.

Volgens mij doet de flash applicatie direct een request op de service en komt dat dus niet vanaf de webserver. Ergo: als je alleen het IP van de server toelaat, werkt er niets meer.

[ Voor 0% gewijzigd door Japius op 31-03-2010 16:54 . Reden: dat dus/ ]

[Orion84]

RaZ schreef op woensdag 31 maart 2010 @ 16:49:
[...]

Enkel het IP van de server toelaten op de webservices.

En op welke manier gaat dat helpen om een client-side Flash applicatie beveiligde toegang tot webservices te bieden?

* Orion84 heeft geen verstand van flash en de mogelijkheden die dat biedt om dit soort dingen te beveiligen. Maar is het niet handiger om die flash applicatie puur als user-interface te beschouwen en de beveiliging anders op te lossen? Dus geen aannames doen over hoe berichten bij de services aankomen, maar zorgen dat ze hoe dan ook correct worden afgehandeld? Dat de gebruiker dan in plaats van puur z'n browser een hippe flash interface voor zijn neus krijgt is dan mooi meegenomen

Het klinkt nu een beetje alsof je een stuk flash bij de client neer wilt zetten wat je vervolgens wilt vertrouwen om op een betrouwbare manier te communiceren met de webservices, waarbij je de webservices wilt afschermen van toegang buiten die flash client om. Als Flash daar mogelijkheden voor biedt (client authenticatie) dan kan dat misschien, maar anders zou ik niet willen vertrouwen op clientside code eerlijk gezegd...

Edit: Eens met de persoon hieronder dus.

[ Voor 6% gewijzigd door Orion84 op 31-03-2010 16:57 ]

[rvanlooijen]

Je geeft eigenlijk aan dat gebruikers de webservices mogen gebruiken, maar alleen via je Flash file. Waarom maakt het uberhaubt uit op welke manier je webservices worden gebruikt?

...Je controleert toch niet stiekem dingen als rechten alleen in je client-side Flash he?...

[Woy]

pappavis schreef op woensdag 31 maart 2010 @ 16:46:
Huidige situatie
Flash website met flash pagina logt in op website, maakt extensief gebruik van webservices. Die webservices hebben géén beveiliging.

[list=1]Voorbeeld huidige (Login) procedure
• Gebruiker start browser, surft naar onze website, die de flashfile download/toont
• gebruiker typt in textbox zijn gebruikernaam + wachtwoord, gebruiker klikt op OK-knop.
• SWF pagina roept onze webservices aan.
• Webservices geven response terug naar SWF.
• SWF verwerkt die response en geeft zo bijvoorbeeld resultaten weer.

Wij denken tussen stap (3) en (4) "iets" te installeren, om het te beveiligen. Maar de vraag is wat? En hoe?

Maar wat wil je nou precies beveiligen. Je hebt een webservice die je beschikbaar wil stellen aan een gebruiker ( Via een flash interface ), dus die kan je natuurlijk niet afschermen, want je wil hem juist beschikbaar maken.

[Hahn]

De webservices moeten beschikbaar zijn voor de gebruiker, die dus ingelogd is, maar verder voor niemand. Het hele punt nu is dus dat je de webservices zelfs kan benaderen ook al ben je niet ingelogd, simpelweg door te weten hoe de webservice heet.

[Janoz]

Je denkt in de verkeerde richting. Er is eigenlijk niks te installeren dat er voor zorgt dat de communicatie betrouwbaar wordt. Je flex applicatie draait in een untrusted omgeving (de client zijn computer) en of het request nu van je flex applicatie komt of van een evil hacking tool is niet te achterhalen.

Wat je wel moet doen is het volgende:
- Het daadwerkelijk afdwingen van authenticatie en authorizatie mag nimmer in flex gebeuren! NOOIT moet het wel of niet kunnen doen van een actie door de gebruiker af moeten hangen van een rol of authenticatie variabele op de client. (Ik heb het over actie. Dit geldt natuurlijk in mindere mate voor het wel of niet tonen van bv een menu item, maar ook daar geldt: het daadwerkelijk uitvoeren van dat menu item moet ten allle tijden via de server verlopen)

- Elke webservice call die afhankelijk is van authorizatie zal credentials of een token (sessieID) mee moeten krijgen om zo serverside te controleren of die gebruiker die actie wel uit mag voeren.


Security is nu eenmaal niet iets wat je achteraf nog eventjes ergens tussen zet. Jullie hebben aan het begin van het traject blijkbaar wat stukjes af willen snijden, en daar plukken jullie nu de (zure) vruchten van. Accepteer dat je applicatie zo lek als een mandje is, of accepteer dat je dit niet even in een middagje of 2 weet te fixen.

Caesartje schreef op woensdag 31 maart 2010 @ 16:55:
...Je controleert toch niet stiekem dingen als rechten alleen in je client-side Flash he?...

Ik denk dat we hier inderdaad met deze nogal cruciale en enorm kostbare ontwerpfout te maken hebben

[ Voor 10% gewijzigd door Janoz op 31-03-2010 17:06 ]

[Woy]

Dan moet je dus authenticatie en authorizatie opnemen in je webservice.

[Verwijderd]

Je kan een heleboel obscuren (bv hashes gaan meesturen met je data die dan elke request gevalideerd worden.) Maar als ik je Flash decompile en er wat tijd in stop kan ik alsnog achterhalen wat je aan het doen bent.

Als je "waterdichte" security wil moet je zoals anderen al zeiden zorgen dat je security logica op de webservice zit en je Flash louter een interface is. Bijvoorbeeld: je logt in via de webservice en krijgt een session key terug. Je webservices kunnen die session dan gebruiken om te controleren of je gebruiker rechten heeft op een bepaalde service.

edit: te laat

[ Voor 4% gewijzigd door Verwijderd op 31-03-2010 17:10 ]

[Hahn]

De Flex-applicatie is gebouwd voordat wij op deze zaak zijn gezet (en voor we überhaupt werkzaam waren bij dit bedrijf), dus het gaan wijzen naar wie de schuldigen zijn kan achterwege gelaten worden

We zijn er ons ook van bewust dat er flink wat steken zijn laten vallen in de ontwikkeling van dit programma, niet alleen op gebied van beveiliging, maar aangezien het zeer binnenkort in werking moet worden genomen en we niet het volledige programma opnieuw kunnen gaan schrijven in een paar dagen tijd zullen we nu even gebruik moeten maken van een houwtje-touwtje oplossing.

Dus elke suggestie hoe we de huidige situatie kunnen verbeteren is welkom, want het zal allicht een verbetering zijn.

[matthijsln]

Het makkelijkst lijkt me om HTTP Basic authentication gebruiken voor je webservice, want Flex heeft daar standaard ondersteuning voor. Indien voor de swf download ook HTTP Basic authentication wordt gebruikt en de webservices gebruiken dezelfde domeinnaam hoeft de gebruiker zelfs niet opnieuw z'n logingegevens in te typen.

Zie het artikel van Adobe: Understanding Service Authentication

Wil je het secure, dan gebruiken icm SSL.

[Woy]

Idd, de makkelijkste manier om het dan "veilig" te krijgen is basic authentication over https. Je moet dan wel zorgen dat de username/password niet in de Flash applicatie staat, anders kan die nog uitgelezen worden. Je zult dus moeten zorgen dat de username/password die ingetypt word ook gebruikt word om te authenticeren.