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.
Related
Can we delete HttpOnly and Secured Cookies using javascript ,jsp or java or html?
Is it possible to write some code and clear out all the cookies from browser? Does not matter if it is a secured or an HttpOnly, I want to delete it anyway. Is this possible?
No, it is not possible. A cookie with the HttpOnly attribute is inaccessible to JavaScript. HttpOnly cookie helps to mitigate cross-site scripting (XSS) attacks.
Refer: MDN docs
How to read a HttpOnly cookie using JavaScript
To clear all the cookies (without httpOnly attribute) from the browser refer: Clearing all cookies with JavaScript
If a cookie is set with samesite strict, is it possible to be sent with a javascript to another site, like using javascript to get the cookie and send it to another user?
Yes, samesite cookies can be read using javascript. So they are vulnerable to XSS attacks same as any other cookie.
You can test this out yourself, by opening chrome inspector on any website and typing the following:
// Set cookie
document.cookie = 'auth=lol;samesite=strict';
// Read cookie
console.log(document.cookie); // "auth=lol"
You may be thinking of httpOnly? Setting httpOnly will prevent reading in javascript, and will therefore prevent XSS. https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Security
Yes. You refer to a state where you run a script on a client's browser. A samesite cookie indicates the behavior of a browser's request when it handles a site's cookies, but it is still accessible locally by the scripts.
Like #jameslol said, you may refer to HttpOnly flagged cookies.
A server can set the HttpOnly flag for a Set-Cookie response header. If your target's browser supports the HttpOnly flag, then local scripts cannot access the cookie.
However, if the browser doesn't support this flag, it will set a regular cookie instead, yielding the cookie(s) accessible by the client scripts.
Additional reading :
HttpOnly flag
List of HttpOnly flag browser support table
samesite flag and CSRF attacks
I have an application where I send the auth token to the server with every request as a cookie in the header request. Also, I force the app to run over HTTPS, so cookie headers are encrypted. However, I know that's not enough keep the cookie inaccessible to (XSS) attacks. I thought of the HttpOnly option, but that won't help since it can't be accessible by Javascript.
Is there any other options that I can do to better secure the cookie that I send in the header request?
When using cookie-based authentication, the HttpOnly flag is the one you're looking for: when the user logs in, the server sends the HttpOnly cookie to the browser, which is not accessible by JavaScript and shouldn't be accessible by JavaScript, the only important part is that the browser will automatically send the cookie to the server for every request matching the domain of the cookie.
What you need to keep in mind is that cookie-based authentication needs an additional mechanism to protect against CSRF.
If, on the other hand, you're using OpenID Connect or OAuth2 authentication and want to store the access token in a cookie, then yes, you can't use HttpOnly flag. But it also doesn't make sense to encrypt that cookie with some magic, because if someone can steal the cookie, they'd steal the correctly encrypted cookie which remains valid. The key thing here is, you should protect every input on your website against XSS: if you have text-inputs, you'll have to filter the input against XSS attacks, for PHP you could take a look at the AntiXSS library. Also don't link to client-side libraries, images or other resources from CDN's you don't trust as scripts could be injected from there too.
For access tokens, no matter what method you're using to store or encrypt it, the access token is always prone to XSS, because your own JavaScript application needs access to it. That's the main reason why an access token is, and should always be, short living (max 1 hour f.e.).
I want to get cookie value which http mode is true using js.
var x = document.cookie;
Using that I only that value which http mode is false (example:Nopcommerce.RecentlyViewedProducts).
In this picture I want get value Nop.customer. How to get that?
You can't do this. The whole point of the HttpOnly flag on a cookie is that it cannot be accessed by client-side scripts. It's just sent by the browser to the server. From OWASP:
If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.
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.