1

I am no security expert, but do know some concepts.

We have a web application which currently uses Java Applets to do some operations on files in Client's File system (Browse, create, upload and download). Since Java applet support is being removed. We are planning to go for client side websocket server. Which will be installed on client side when first time such operation is being attempted.

I am concerned about the security of such system. Basically we will have 3 entities involved.

  1. WebServer
  2. Browser
  3. Client Websocket server (aka LocalServer)

Some points I am considering:

  1. Plugin should only accept connections from localhost
  2. Authentication Logic
    1. WebServer will send some Unique Identification Key to Browser
    2. Browser will send the same to LocalServer
    3. LocalServer will forward the same to WebServer for authentication.
    4. It will accept connection from browser only if authenticated by WebServer.

An important point is that data theft should not happen when the Browser visits a Malicious page. Basically LocalServer should only connect to WebServer's page's websockets.

What Additional points do I have to consider for hardening this?

If possible inform other points of consideration for this system.

Update 1: LocalServer: Can upload, download files from the specific WebServer only.

  • 1
    If the available JavaScript API's for prompting a user to select files and choose where to save them is not enough, and you need direct filesystem access via a desktop application, then your web app was never really a web app. Make it a desktop app instead, perhaps using something like NW.js. – Alexander O'Mara Jun 26 '16 at 16:10
  • We already have a desktop Client. But the web client is the lightweight alternate which currently uses Java applets to access the local filesystem. Since it already exist we can't just convert it to another desktop app. We are currently trying to find an alternate to java applets. – AEonAX Jun 26 '16 at 16:15
  • I see. Well, the JavaScript API is the only alternative going forward, and it is a better alternative for virtually everything. The only other option is browser extensions. I don't know about other people, but I certainly would not install a service or extension just to avoid installing a desktop app though. – Alexander O'Mara Jun 26 '16 at 16:22
  • I agree with your point. But If a user wants to do some local file operations through our web application. They will have to install/run some kind of client side application after Java applet support is gone. Initially they were installing JRE now they would be installing our own client application. BTW thanks for introducing me to NW.js – AEonAX Jun 26 '16 at 16:28
  • Also their are size considerations to consider. Full fledged Client is around 500MB. while for the plugin we are targetting around 10MB. – AEonAX Jun 26 '16 at 16:30
2

You're trying to do the impossible here. You're having the localhost server authenticate the client application running in the browser. This is impossible to do securely.

What you would want is to write a browser plugin/add-on. The browser plugin/add-on should only activate itself when visiting authorized sites.

  • Can you please suggest some points as to why it is impossible? – AEonAX Jun 26 '16 at 8:27
  • @AEonAX: how are you going to authenticate the application running in the Browser? A malicious application can pass along unique identification key, just like a legitimate application do. The identification key does not prove that what's running in the Browser is a legitimate application. – Lie Ryan Jun 26 '16 at 8:35
  • This key has to be verified by the WebServer – AEonAX Jun 26 '16 at 8:36
  • @AEonAX: the localhost server cannot distinguish whether it receives the key from legitimate application running in the browser or a malicious application running in the browser. Sending a piece of string around proves nothing about whether or not the Browser is on the right application. – Lie Ryan Jun 26 '16 at 8:41
  • My idea is that the server will generate some key using some user details + time component + salt. Browser will then use it will while trying to connect to LocalServer. This will be forwarded by the LocalServer (Plugin) to WebServer. Once the WebServer Authenticates. Then only requests from the browser will considered. – AEonAX Jun 26 '16 at 8:43
0

@AEonAX : you can use the double handshake token method to use authorize and take care of security. Encryption of token can also be done.

Sheldon

  • Can you please elaborate? – AEonAX Jul 21 '16 at 3:46
  • Client sends a token to server after authentication. Server receives the token and sends a ticket to client. also server stores the token, ticket and session information. Everytime the transaction is initiated, the client will send the ticket, token and session info to validate. – Sheldon Cooper Aug 10 '16 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.