Thanks for the info. I have some responses inline. Now I am going to implement CSP as proposed by Felix's url. The good thing with websockets is that they don't rely on jsonp to send cross-origin data. So i can disable all scripts both inline and from any other source except 127.0.0.1 and still receive data from websockets.
2014-05-23 3:11 GMT+03:00 Tim Prepscius <[email protected]>: > You might also try posting to the guardian dev mailing list > > https://guardianproject.info > > They have a bunch of experience, possibly could give valuable information. > > -tim > > > On 5/22/14, Tim Prepscius <[email protected]> wrote: > > Interesting. > > > > I'm not sure if the approach you are describing is a good one or not. > > In some ways, you are opening yourself up to attacks > > that might not exist if everything was packaged together. > > > > > > > > Some things to think about: > > > > I do not need to compromise your client to get to the 127.0.0.1 web > > server. I can use any web page the user visits. > > > I use cookie authentication and have set socket.io to reject cross-origin requests. > > If I discover a bug in the 127.0.0.1 web server, I could use that to > > keep track of the client in the web browser. (I'm assuming that > > basically data is passing remote-server -> web-client -> > > localhost-server -> web-client) > > Yes this is the data path but only for important staff that require encryption . Well if there is a bug in the server, we are screwed anyway. > > The web browsers, I believe, do SHAs of plugins, packaged items, > > before running them. While this might not be "real security," it > > might be more secure than a web server resides on disk and is never > > fully sha'd. In theory, the security of let's say OSX, passes from > > the security chip to the operating system, which should, but doesn't, > > check the Chrome, which then checks the plugin. > > > > How are you going to update your 127.0.0.1 web server. How are you > > going to prevent your web server from being updated by a malicious > > actor. > > > I dont really know exactly. I would definitely sign my package. > > > > > > These came to me off the top of my head. Their worth is dubious! ;-) > > > > Good luck! > > > > -tim > > > > > > > > On 5/22/14, Apostolis Xekoukoulotakis <[email protected]> wrote: > >> So there will be 2 servers, one local per client and one global server > >> that > >> provides content(json). > >> > >> > >> 2014-05-23 2:44 GMT+03:00 Apostolis Xekoukoulotakis <[email protected] > >: > >> > >>> Yes!! actually I'll use socket.io. > >>> > >>> > >>> 2014-05-23 2:42 GMT+03:00 Tim Prepscius <[email protected]>: > >>> > >>> Can you describe what you mean by: > >>>> > >>>> the attacker will still not have the private key since all > >>>> cryptography happen in the nodejs of the user. > >>>> > >>>> It seems as though you are saying that there will be a web server > >>>> running client side, from which the web app will make ajax calls to. > >>>> Is this what you mean? > >>>> > >>>> On 5/22/14, Apostolis Xekoukoulotakis <[email protected]> wrote: > >>>> > Thanks Felix. Your advice is sound. I am going to look at your > >>>> references. > >>>> > > >>>> > So my app is indeed packaged but I don't use node-webkit. In my > case, > >>>> > if > >>>> > the client is compromised in the browser, the attacker will still > not > >>>> have > >>>> > the private key since all cryptography happen in the nodejs of the > >>>> > user. > >>>> > > >>>> > But he would be able to ask the server to sign arbitrary documents > >>>> which is > >>>> > still really bad. > >>>> > On May 22, 2014 11:33 AM, "Felix Hammerl" <[email protected]> > >>>> wrote: > >>>> > > >>>> >> Hi, > >>>> >> > >>>> >> you have to trust the server in a host-based security setting. If > >>>> >> you > >>>> >> want > >>>> >> to mitigate that, have you considered packaged (not hosted!) apps? > >>>> Check > >>>> >> out Chrome Apps, Firefox Apps, node-webkit, atom-shell, ... > >>>> >> It all boils down to what you threat model is. Also, you probably > >>>> >> don't > >>>> >> want to roll your own authentication mechanism. You also might want > >>>> >> to > >>>> >> avoid doing funky stuff with removing the script sources and > loading > >>>> them > >>>> >> from arbitrary locations... > >>>> >> Recommended read for js security and threat models (be sure to > check > >>>> out > >>>> >> the discussion, too!): > >>>> >> > http://tankredhase.com/2014/04/13/heartbleed-and-javascript-crypto/ > >>>> >> > >>>> >> > >>>> >> Cheers > >>>> >> Felix > >>>> >> > >>>> >> > >>>> >> On Wed, May 21, 2014 at 7:57 PM, Apostolis Xekoukoulotakis < > >>>> >> [email protected]> wrote: > >>>> >> > >>>> >>> Hello everyone. I am thinking of using openpgp as an > authentication > >>>> >>> mechanism form my site and more. Send a random number to the > >>>> >>> client, > >>>> the > >>>> >>> sessionId, which he then has to sign and send back. > >>>> >>> > >>>> >>> I was also worried that if someone could attack my server, he > could > >>>> send > >>>> >>> arbitrary js code to the client and thus all clients would be > >>>> >>> compromised. > >>>> >>> So I decided to create a nodejs app that users would have to > >>>> >>> install > >>>> >>> locally that would provide them those js scripts. > >>>> >>> > >>>> >>> They would only have to contact the server for content. So now I > am > >>>> >>> worried about someone injecting js code into the content. > >>>> >>> If I wrote a parser that removed script tags, I suppose this would > >>>> >>> be > >>>> >>> secure, right? > >>>> >>> > >>>> >>> The apps goal is to let users issue new currencies, that is why is > >>>> >>> security is very important. > >>>> >>> > >>>> >>> _______________________________________________ > >>>> >>> > >>>> >>> http://openpgpjs.org > >>>> >>> Subscribe/unsubscribe: http://list.openpgpjs.org > >>>> >>> > >>>> >> > >>>> >> > >>>> >> _______________________________________________ > >>>> >> > >>>> >> http://openpgpjs.org > >>>> >> Subscribe/unsubscribe: http://list.openpgpjs.org > >>>> >> > >>>> > > >>>> _______________________________________________ > >>>> > >>>> http://openpgpjs.org > >>>> Subscribe/unsubscribe: http://list.openpgpjs.org > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> > >>> Sincerely yours, > >>> > >>> Apostolis Xekoukoulotakis > >>> > >>> > >> > >> > >> -- > >> > >> > >> Sincerely yours, > >> > >> Apostolis Xekoukoulotakis > >> > > > _______________________________________________ > > http://openpgpjs.org > Subscribe/unsubscribe: http://list.openpgpjs.org > -- Sincerely yours, Apostolis Xekoukoulotakis
_______________________________________________ http://openpgpjs.org Subscribe/unsubscribe: http://list.openpgpjs.org
