> > For encrypting use HTTPS, it doesn't require any special additional > works except configuring the web server. It doesn't protect however > from monitoring the traffic from the client machine.
Thats the whole point of HTTPS - it encrypts the traffic and hence anyone monitoring traffic from the client machine just sees encrypted traffic. And configuring a web server for https can be anywhere from simple to a nightmare depending on the requirements and setup. João's original requirement could be achieved by sending a username and password over https to authenticate calls to the service but I would strongly recommend NOT embedding these in the swf but rather make the user input them as it is fairly simple to get at them if embedded. On Dec 21, 2007 5:23 PM, Rákos Attila <[EMAIL PROTECTED]> wrote: > > JS> the client needs to make sure that the web-service is only > JS> accessible to our specific Flash client > > It's simply not possible, the client's requests are falsifiable and > it is very easy to do that. No decompiling is needed, a simple traffic > monitoring program (Fiddler, Charles, etc.) is enough to capture > requests and responses, modify them and send falsified requests. > > JS> Other clients should not be able to request data from the > JS> web-service, since it might compromise the business behind it. > > If calling the webservice with false or misformatted data can screw up > something, then that webservice was not written perfectly and not > secure. In a server-side program you cannot trust in the client and > rely on the hope that it will not send corrupt input data. Any input > should be checked, validated and verified at server-side (client-side > checking is also useful, but not enough). > > JS> there is a possibility to have something like a "key" hard-coded > JS> on the flash module, and a way to use encription to respond to a > JS> challenge made by the server - avoiding at least man on the middle > JS> attacks, i guess. > > For encrypting use HTTPS, it doesn't require any special additional > works except configuring the web server. It doesn't protect however > from monitoring the traffic from the client machine. > > If these options are not enough, then think of user authentication. > > Attila > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > From: João Saleiro <[EMAIL PROTECTED]> > To: Open Source Flash Mailing List <[email protected]> > Date: Friday, December 21, 2007, 5:17:50 PM > Subject: [osflash] Solutions to provide a secure access to a Web-Service > using Flex > > --====----====----====----====----====----====----====----====----====----===-- > Hi, > > we are building an enterprise application using Flex. One module of > the application will be accessible on the internet so users can access > some data from the main system, without requiring a login. > > This module communicates with a web-service. It is already finished > and working fine, but the client needs to make sure that the > web-service is only accessible to our specific Flash client. Other > clients should not be able to request data from the web-service, since > it might compromise the business behind it. > > If there isn't a "perfect" solution, our client is not worried with > the fact that SWF's can be decompiled, so there is a possibility to > have something like a "key" hard-coded on the flash module, and a way > to use encription to respond to a challenge made by the server - > avoiding at least man on the middle attacks, i guess. > Some years ago i have studied a bit of public key infrastructures, but > never applied it on a project. > > I am far from being expert on security, but this is really important, > since without a rather reasonable solution a big part of the project > will be useless. > > What solutions do you propose? Does Flex have some kind of tools to > solve this problems? > > Thanks, > > João Saleiro > > www.riapt.org > www.webfuel.pt > > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org >
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
