I am facing problem with cookies. We have our page hosted on weblogic which is accessible through load balancer to our client. Our Client accesses the page through URL and sets some auth information in cookies.
I read cookie on html through javascript and allow the access to page.
It was working fine until yesterday when after a apache server security patch deployment on our client's side. I am not able to read cookies. While in chrome dev tools in request I can see it.
anyone faced this problem ?
It sounds like you do authentication on the front end which is wrong in so many ways I don't know where to start.
They probably set the httpOnly flag on the cookie which restricts javascript access.
If you do security on the front end you have NO security though so this should be a call to action to migrate to performing security on the server.
Related
Context:
I'm developing a frontend app locally, calling APIs etc cross-domain (from localhost dev server to our server on another machine inside the local network). Since our local network is isolated, the backend server has CORS enabled which doesn't cause security problems; this is different in production (CORS is disabled).
We introduced WebSocket connections in our app and to secure it with authorization we added cookie check on handshake. (XHR requests are authorized via the Authorization header, cookies are not used there; but they actually can be used; WebSocket interface only allows a limited set of headers and if we don't authorize via WS messages, cookies seem to be the only sane option; well, in fact I failed to find if Basic HTTP auth can be implemented without broswer standart prompt, and how to do that)
The problem:
while this actually works for production (when frontend and backend are on the same domain), and cookies are sent in the handshake request inside the Cookie header (the code is trivial: I just set the cookie after getting the auth token), this doesn't work in development environment (localhost + backend on another domain): the Cookie header is just absent in the handshake. The link above shows that XHR needs the withCredentials option to try to pass cookie cross-domain; however, I haven't found a definitive answer whether there's something similar for WS or not. Here the author of a similar question just assumes that there's no such thing, but is it really so?
Double check that the cookies that you're working with are set with SameSite=None and are secure!
I was having the same issue, thinking that the cookies weren't being sent, because the chrome inspector doesn't show them on websocket connection request, but they seem to be once you mark them with same site none and secure.
Alternatively, to quickly check if that's the problem, you can disable the SameSite requirement in chrome://flags/
On another project I've learned a "correct" way to handle this. Usually a higher level protocols are used with WS, like STOMP protocol. It has specific implementation for auth, so no cookies are needed actually; it has no drawbacks regarding CORS.
I have a web application that serves only static contents - HTML, CSS and JavaScript. I have another application which is an ASP.NET Web API. Both applications are on same machine on different ports (for testing purpose and they could be on different machine or domain in production environment). When I browse the web application, it gets both cookie as well as form token of Anti CSRF on first ajax call from Web API. So I am setting the body token as header with setRequestHeader function of XMLHttpRequest. It doesn't seem there is any need to set the cookie token since cookies are restricted with HttpOnly Attribute for a security reason and as far as I know browser is responsible to send the cookie to whichever domain the cookie belongs to.
However, when I make consecutive ajax calls, instead of both these tokens being passed back to server, only the header token is being received by the server.
Currently the Web API is set with CORS restriction for the web application. But if the problem was related to cross origin then I guess, headers could not have been passed as well, correct me if I am mistaken.
So can anyone help me with this problem? I just want to be able to send cookies from one application to another without compromising in terms of security.
Take a look Cookies With My CORS and Set-Cookie in HTTP header is ignored with AngularJS
I'm developing a page/form for a campaign inside my company. However, the first step is to check if the person is logged in. This is easily checked against a cookie - CUSTOMER - that is set once they're logged in.
However:
1) I'm developing locally, not on the same domain, and, as a result can't see that cookie
2) The final campaign may or may not end up residing on the actual domain. They may end up using a vanity URL or something.
For purposes of this, let's assume I do NOT have access to the main domain where the cookie was set.
How can I read that cookie from off the domain? Oh, and since IT folks don't let us touch the back-end grumble, it has to be a JS solution.
Thanks!
You can't.
The only cookies you can read with client side JavaScript are those belonging to the host of the HTML document in which the <script> is embedded.
By setting withCredentials you can support cookies in cross-origin requests, but they are handled transparently by the browser and JS has no direct access to them (the XHR spec goes to far as to explicitly ban getAllResponseHeaders from reading cookie related headers). The only way for a cross-origin request to get access to cookies is for the server (which you say you don't have access to) to copy the data into the body or a different response header).
You can if you can install server side components.
You can use a dedicated domain to host your cookie and then share it using XSS technics
When dom1.foo.com logs in then you register a cookie on cookie.foo.com using an Ajax XSS call then when you go on dom2.foo.com you have to query cookie.foo.com with your XSS api
I' ve played with it some time ago
https://github.com/quazardous/mudoco/blob/master/mudoco/README.txt
It's just some sort of POC..
Regarding source maps, I came across a strange behavior in chromium (build 181620).
In my app I'm using minified jquery and after logging-in, I started seeing HTTP requests for "jquery.min.map" in server log file. Those requests were lacking cookie headers (all other requests were fine).
Those requests are not even exposed in net tab in Developer tools (which doesn't bug me that much).
The point is, js files in this app are only supposed to be available to logged-in clients, so in this setup, the source maps either won't work or I'd have to change the location of source map to a public directory.
My question is: is this a desired behavior (meaning - source map requests should not send cookies) or is it a bug in Chromium?
The String InspectorFrontendHost::loadResourceSynchronously(const String& url) implementation in InspectorFrontendHost.cpp, which is called for loading sourcemap resources, uses the DoNotAllowStoredCredentials flag, which I believe results in the behavior you are observing.
This method is potentially dangerous, so this flag is there for us (you) to be on the safe side and avoid leaking sensitive data.
As a side note, giving jquery.min.js out only to logged-in users (that is, not from a cookieless domain) is not a very good idea to deploy in the production environment. I;m not sure about your idea behind this, but if you definitely need to avoid giving the file to clients not visiting your site, you may resort to checking the Referer HTTP request header.
I encountered this problem and became curious as to why certain authentication cookies were not sent in requests for .js.map files to our application.
In my testing using Chrome 71.0.3578.98, if the SameSite cookie atttribute is set to either strict or lax for a cookie, Chrome will not send that cookie when requesting the .js.map file. When there is no sameSite restriction, the cookie will be sent.
I'm not aware of any specification of the intended behavior.
I am writing a Phonegap application that needs to be able to call remote webservices that are secured by CAS. The application will also be hosted on our webfarm (minus the hardware specific parts) as a mobile web site.
Our CAS server is hosted by server1 and our webservices are hosted on server2. The mobile web site is hosted on server2.
Any calls I make from Javascript get a cross-domain error. I realize this isn't an issue for the phone, but it would be nice to avoid it due to development being so much easier when running on the desktop.
Currently, I have a working setup that consists of the following:
Javascript calls a server-side script on server2 over https, including the username and password in the header.
The script calls CAS' RESTful api and gets a ticket granting cookie. The script creates a Set-Cookie header in the response or it reports back with a login error.
Javascript gets the response and creates the cookie (though this cookie is undetectable in Phonegap (nothing in document.cookie), even though it's getting passed around).
Javascript then calls a server-side script which calls a webservice for it, passing the cookie with the request (I had to manually insert the cookie into the request header, even though it automatically was passed in the request from javascript).
The server-side script sends the results to javascript.
Is there a better way to do this? I've seen mention of proxy tickets in CAS, but cannot find enough information to know whether it's what I need or how to use them.
Thank you.