for websockets I have to expose my sessionid from the cookie.
I have searched a bit and found that I should be able to access cookies by:
console.log(document.cookie);
unfortunatly this doesn't work or better document.cookie contains an empty string even chrome itself shows me the cookie also authentication works.
Can it be that chrome hides the cookie for javascript?
That can happen if the server is configured to send the session cookie with the HttpOnly flag. This way the cookie becomes invisible/inaccessible to client side scripting languages like JS.
To achieve your concrete functional requirement, either reconfigure the server to not do so, or look for alternate means, e.g. setting a custom cookie (without the HttpOnly flag, of course), or letting the server side view technology dynamically print the current session ID as a JS variable or as an attribute of some HTML element so that JS can access it by traversing the HTML DOM.
Related
I am a bit confused by the document.cookie property: why does this property exist at all, and under what scenario the DOM, when being rendered in a browser, want to access it?
The examples that I can find, such as https://www.w3schools.com/js/js_cookies.asp and https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie, only tell me how to read or write a cookie, but I wonder why the DOM need to access the cookie at all.
Consider an HTTP response, both the web document and the cookie are sent from the origin server, what is the reason that the web document wants to access the cookie only after it is loaded into the browser? Why can't such jobs be done at the server side and save client's effort and time? And based on my understanding, cookie is used for the server to identify session or user and will be attached by the browser when a request is sent to the server, which does not contain any meaningful content from human being's perspective, so what practical use of cookies in the DOM context?
It's meant to be accessed by JavaScript. As JS is built to interface with the page DOM, it uses that to set/read cookies. For example (and this is gonna sound very meta but bear with me), you can programmatically set a cookie for a user if they hit the "I agree" on a cookie consent notification. JS can then search for that cookie to see if the user has agreed, and then decide whether or not to display the notification, which itself is a process that interacts with DOM.
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..
I have a cookie that is NOT HttpOnly Can I set this cookie to HttpOnly via JavaScript?
An HttpOnly cookie means that it's not available to scripting languages like JavaScript. So in JavaScript, there's absolutely no API available to get/set the HttpOnly attribute of the cookie, as that would otherwise defeat the meaning of HttpOnly.
Just set it as such on the server side using whatever server side language the server side is using. If JavaScript is absolutely necessary for this, you could consider to just let it send some (ajax) request with e.g. some specific request parameter which triggers the server side language to create an HttpOnly cookie. But, that would still make it easy for hackers to change the HttpOnly by just XSS and still have access to the cookie via JS and thus make the HttpOnly on your cookie completely useless.
Is it possible that you disable setting cookies in javascript while stil being able to read them?
In my website i set cookies only in php, but it would be usefull that i can read them from Javascript.
I know there is a httpOnly flag while creating cookie but that restrict read and write access from Javascript.
The reason why i want to restrict write access is of course security as user can easily set cookie even from browser and i want to prevent that.
What you can do is create two cookies:
MY_COOKIE_HTTP_ONLY
MY_COOKIE
With the same values in the backend. One which is http only and the other which isn't. The MY_COOKIE_HTTP_ONLY cookie will be used in the backend and MY_COOKIE will be used in the browser. If attacker changes the value of MY_COOKIE in the browser side, well that basically is ok since if attacker has access to your browser, they can do all sorts of things but only in the browser side.
And on the other hand, you will be able to identify this situation by comparing the values.
Shortest answer: No. It's not possible.
you can prevetn the browser from setting javascript cookies by overriding the setter of document.cookie
document.__defineGetter__("cookie", document.__lookupGetter__("cookie") );
document.__defineSetter__("cookie", function() {} );
As others have stated, you can't stop users from editing files on their own computers, which is effectively what you would need to do to stop them from editing a cookie.
That doesn't mean you're out of options though. You could include an authentication code (like HMAC) in the cookie. The user will still be able to read and change that cookie, but at least you will be able to detect when they do and ignore the provided data.
When you are served a web page, who builds the DOM document? Is it strictly the server printing HTML? How is the browser involved? I am specifically interested in knowing how is the document.cookie property populated.
A) The server populates document.cookie
The browser stores a cookie for foobar.com in the users hard drive.
The next time foobar.com is visited, the browser presents all cookies for foobar.com to the server.
The server builds the DOM document.cookie property based on these cookies.
B) The browser populates document.cookie
The browser stores a cookie for foobar.com in the users hard drive.
The next time foobar.com is visited, the server goes on about constructing and serving the HTML.
Somewhere before or after the browser grabs all the cookies on the hard drive and populates document.cookie.
I am interested in this information because I'm studying how cookie stripping at proxy servers such as Varnish and Squid can affect cookies. If document.cookie was built by the server (option A above), then I would assume cookie stripping by proxies would affect the document.cookie property. I am however party inclined to think B is the case since I have a directive in a Varnish server to specifically strip a cookie, but the data of the cookie remains persistent in document.cookie even after stripping it from the request.
This question is especially important for people who have websites behind Varnish, since a request that comes attached with a cookie negates the use of cached data and generates a back-end hit.
The DOM is built and used by the browser based on the server's response. Part of the job of a browser's layout engine is to parse the HTML returned by the server into the DOM. Unfortunately, the different browsers use different layout engines, so the DOM tree sometimes has differences within it.
document.cookie specifically is a attribute of the DOM Level 1 spec. As was said, the correct answer is more or less (B). Cookies are packaged as part of the request that a client sends to the server, and although the server can set cookies in the response, in the end they all reside in the client side.
The Server sends data to the browser which interprets it and builds a DOM tree. the cookies are sent along with the data and are not built into the DOM, but instead stored on the local machine. basically B. The browser can manipulate cookies on the machine; the server can manipulate any cookies it's issued.