2

I am having a hard time coming up with the best title for this question, but let me explain my situation:

I have a chat-room-as-a-service app similar to Intercom. Anyone can load the chat in an iframe and display it in their site. I want to make it so that site creators can request a 'namespace' i.e. acme inc and then pass that as a parameter in the iframe src URL.

The problem is that anyone could join the company's chat by simply typing the name as a param into their own iframe URL. I need a way to verify that when a host connects to my app with a "name" param, that it is the correct host and not a spoofer.

This is all in JavaScript, by the way, but since this is security and not Stack Overflow, I don't expect someone to give me correct code, just important concepts. Thanks.

  • While not sufficient, a start would be to only allow your site to be IFramed in a domain corresponding to the namespace. (Via JavaScript), which can be worked around by anyone attacking your service, but prevents users of a website which is stealing a namespace from loading the IFrame. – Οurous May 5 '17 at 23:19
  • @Οurous thanks, I figured that out in the meantime since posting the question. Now I'm mulling over: Can I require incoming connections be done over HTTPS then reliably use the host header to identify them? – max pleaner May 5 '17 at 23:24
  • 1
    Host header? Do you mean referrer? The host header only tells your server which 'host' to respond to the request with. – Οurous May 6 '17 at 0:09
  • @Ourous basically yeah. What I mean is that If I check the request.protocol and it's https then I can assume the provided host/referrer correct? Or do I have to validate the https connection further? – max pleaner May 6 '17 at 0:36
  • 3
    Anything the client sends you is potentially wrong. A quick demonstration in this case would be to open up the Dev console on this question page, reload it, find the request for the security.se logo, and resend it with pant.legs in the referrer field. It will be a HTTPS request, and the referrer will be wrong. – Οurous May 6 '17 at 0:42
2

Have you seen Macaroon Tokens? I've always wanted to use them for authorization processes but haven't had the chance, however they seem like a potential match for your use case.

Here's the research paper and here's a very simple demo tool.

You could for example add several caveats such as client's IP or other similar fingerprint so that a stolen macaroon can't be used elsewhere. Or maybe you can restrict the expiry time to 1 minute or even require a macaroon per request (i.e. chat message or something perhaps?).

Unfortunately for some reason there doesn't seem to be wide adoption of this very cool concept, so a lot of the stuff is old and not sure how maintained the different libraries are, so the usefulness might be limited for you, depending on your case.

However the most common technique I've seen is basically just using cookies (with short expiration times, depending on your use case) to keep server-side session identifiers, which you can use to control access. Just make sure you use HTTPS to send them.

Edit to address the comment:

Here's a javascript library for Macaroons.

What I meant by fingerprinting was getting some kind of info from the user (when they login) and adding them as a Macaroon caveat. e.g.

  • Add a valid email for that "namespace" such that user X in namespace N can't just jump in to namespace M.

  • Build a whitelist with the known range of IPs for each client that have authorization to access their chat. You can try to determine the IP via WebRTC leak but that requires a browser that supports WebRTC, and the leak might be fixed later on, depending on the browser.

The answer to determining the client's IP will depend on your particular use case. There's lots of different solutions there that have a variable amount of cost/benefit ratio that only you can evaluate.

For example, you could use a Node server, but if you don't have one already, this might be costly in terms of new infrastructure, code, etc. Maybe you have a Tomcat server that you can already use to find the IP and can plug into that, etc. But they all have different security implications and associated costs, so this would be a broad question.

Edit:

I've also read some comments regarding how insecure JWT's are if you are using them for client-side sessions. So I might add this just in case someone recommends it.

This article: JSON Web Tokens should be avoided spurred some discussion by people that work in the field, for example this comment by Thomas Ptacek.

Small extract:

The issue with JWT in particular is that it doesn't bring anything to the table, but comes with a whole lot of terrifying complexity. Worse, you as a developer won't see that complexity: JWT looks like a simple token with a magic cryptographically-protected bag-of-attributes interface. The problems are all behind the scenes.

  • I'm not sure if I'll be using macaroons since this is a javascript app, but if i see the request protocol is https, then can i trust the host header? – max pleaner May 5 '17 at 23:32
  • Ok, apparently i cannot trust the host/referrer header even with HTTPS. I'm kind of stuck still. You mention "client's IP or other similar fingerprint". How could I fetch these, and how dependable is it? – max pleaner May 6 '17 at 0:48

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.