0

I have my Ionic/angular 2 app that is running on localhost:8000 The app will run eventually on browser platform. The app is calling a RESTFull api hosted on my local machine on https://adawy/api, where adawy is my hostname and defined in both hosts file and in apache virtual hosts. The server side is Slim 3.

The API upon authentication is returning a JWT to be used with all requests.

My goal is to protect the token from cross site request forgery and cross site scripting. Saving the token in a javascript variable or in any form of local storage would make the JWT accessible from javascript.

I found that the best way is to return the JWT to as an HTTPOnly cookie. So it won't be accessible from javascript and would be sent only by the browser with any upcoming requests to adawy domain.

I had returned the token successfully as a cookie but the problem is that the cookie is not sent with any next XHR requests. enter image description here

Also, I cannot see the cookie in the Cookies section in Devtools.

enter image description here

I know that angular can support in such matter by looking for XSRF-TOKEN cookie. It is not working either, as you can see I set the name of the cookie to XSRF-TOKEN but yet, with any other request, this cookie is not sent.

I wonder how this would be secured as if angular has access to this cookie, so would any other script?

Here is the next request, with no cookie sent. Please ignore the header Authorization as my angular code is setting it directly.

enter image description here

In my angular app, I am setting the withCredentials: true option while making the last get request.

Update I had used adawy.com and I still have the same issue.

Amr Eladawy
  • 4,193
  • 7
  • 34
  • 52

1 Answers1

1

The first response attempts to set the cookie explicitly on a top level domain Domain=.adawy; (see the Set-Cookie header) which is not allowed. Try setting it without the domain if you can and see if that works. Alternatively, try using a hostname that has a tld on it.

LinuxDisciple
  • 2,289
  • 16
  • 19
  • Thanks for your answer. I changed the domain to be `adawy,com` and I still have the same problem. – Amr Eladawy Apr 07 '17 at 03:14
  • [Chrome doesn't support CORS exceptions for requests originating from localhost](http://stackoverflow.com/questions/10883211/deadly-cors-when-http-localhost-is-the-origin). Looks like [this issue was closed in 2014 as won'tfix](https://bugs.chromium.org/p/chromium/issues/detail?id=67743). Apparently `Access-Control-Allow-Origin: *` will work for localhost so you can get testing done, but `localhost` is a no-go. – LinuxDisciple Apr 08 '17 at 00:08
  • I stumbled upon that question, that is the reason I am using `adawy.com` as the host name. I think I must have something wrong with my cookie setup itself. Yet, I am not able to figure out. – Amr Eladawy Apr 08 '17 at 05:45
  • The destination hostname isn't the issue. Chrome doesn't support CORS requests *from* `localhost`. See the `Origin: http://localhost:8000` header that Chrome is sending in the request. – LinuxDisciple Apr 12 '17 at 18:08
  • What about using `adawy.com` as hostname? why is it still not working? – Amr Eladawy Apr 12 '17 at 18:54
  • 1
    It depends on how you've set up the name. If Chrome can tell it's hosted on localhost, it will apply the more restrictive rules. You should still see `Origin: http://localhost:8000` in the request headers as long as Chrome can tell it's being hosted locally. You may need to ask another question about how to accomplish this using Slim 3 since that's not my area of expertise. When the name resolution issue is fixed, Chrome should stop claiming localhost as the Origin and the transaction should work. – LinuxDisciple Apr 12 '17 at 19:50