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.
Related
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'm using window.localStorage.removeItem("name of localStorage variable you want to remove"); to delete two different localStorage Keys in a spec, they're successfully deleted.
The next step is to enter another page of my application to display a dialog that ask you to log in again due to session lost, but doing this with protractor doesn't not work even that the localStorage keys are cleared correctly, but doing it manually (deleting them giving right click and Delete), it works and dialog pops up.
What could be the problem?
Consider wiping cookies, local and session storage fully, instead of wiping only 2 keys.
browser.manage().deleteAllCookies();
browser.executeScript('window.sessionStorage.clear(); window.localStorage.clear();')
It looks like your site stores cookies for different domain, or httponly cookies.
Webdriver can delete only cookies for the same domain where are you currently located. So if your API gives you some authtoken - it won't be deleted, since it is stored for different domain. The same for HTTPonly cookies.
HttpOnly cookie
An HttpOnly cookie cannot be accessed by client-side APIs, such as JavaScript. This restriction eliminates the threat of cookie theft via cross-site scripting (XSS). However, the cookie remains vulnerable to cross-site tracing (XST) and cross-site request forgery (XSRF) attacks. A cookie is given this characteristic by adding the HttpOnly flag to the cookie.
I would suggest you to navigate to API url, and call browser.manage().deleteAllCookies(); method there or call manually logout on your site
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.
EDIT
What one means by "a secure cookie" is ambiguous. To clarify:
Secure as in sent over the https:// protocol — ie. cookie is not sent in plaintext. Known as the "secure flag"
Secure as in the cookie cannot be read by Javascript running in the
browser — ie.
document.cookie will not work. Known as the "HttpOnly" flag.
This edit is to clarify that the original question is asking about the 2nd case.
Original Question
Is there any way to read a secure cookie with JavaScript?
I tried to do it using document.cookie and as far as I can see on this article about secure cookies and HttpOnly flag, I cannot access a secure cookie this way.
Can anyone suggest a workaround?
Different Browsers enable different security measures when the HTTPOnly flag is set. For instance Opera and Safari do not prevent javascript from writing to the cookie. However, reading is always forbidden on the latest version of all major browsers.
But more importantly why do you want to read an HTTPOnly cookie? If you are a developer, just disable the flag and make sure you test your code for xss. I recommend that you avoid disabling this flag if at all possible. The HTTPOnly flag and "secure flag" (which forces the cookie to be sent over https) should always be set.
If you are an attacker, then you want to hijack a session. But there is an easy way to hijack a session despite the HTTPOnly flag. You can still ride on the session without knowing the session id. The MySpace Samy worm did just that. It used an XHR to read a CSRF token and then perform an authorized task. Therefore, the attacker could do almost anything that the logged user could do.
People have too much faith in the HTTPOnly flag, XSS can still be exploitable. You should setup barriers around sensitive features. Such as the change password filed should require the current password. An admin's ability to create a new account should require a captcha, which is a CSRF prevention technique that cannot be easily bypassed with an XHR.
The whole point of HttpOnly cookies is that they can't be accessed by JavaScript.
The only way (except for exploiting browser bugs) for your script to read them is to have a cooperating script on the server that will read the cookie value and echo it back as part of the response content. But if you can and would do that, why use HttpOnly cookies in the first place?
You can not. Httponly cookies' purpose is being inaccessible by script.
Say there is a site foo.com which loads JavaScript from site bar.com. Now, say the JavaScript from site bar.com tries to read cookies using document.cookies. I was under the impression that using JavaScript, you can read all the cookies set in the browser irrespective of their source. But it turns out that the JavaScript from the site bar.com can only access cookies set by bar.com and not any other. If this is the case, how are script injection attacks which steal cookies carried out?
But it turns out that the JavaScript from the site bar.com can only access cookies set by bar.com and not any other.
That isn't true. What matters is where the HTML document containing the <script> element is, not the URL of the JS file that said <script> mentions in the src attribute.
I suspect your problem is that you are accessing document.cookies when the property is called document.cookie (Singular!)
They load scripts inside the attacked page.
For instance, when comments in a blog system get compromised, they contain a script element that is executed when the page is rendered. This script can get the cookies and send it to the attacker's server.
That's why you should never trust user input and disallow at least certain tags in comments (or translate every < to <). But don't do this on the client side, as this prevention technique can easily be circumvented; test for (and change) malicious input on the server side.
You can only access cookies which have been set for the given domain name. From the Wikipedia article on cookies:
Beside the name/value pair, a cookie
may also contain an expiration date, a
path, a domain name, and whether the
cookie is intended only for encrypted
connections. RFC 2965 mandates cookies
have a version number, but this is
usually omitted. These pieces of data
follow the name=newvalue pair and are
separated by semicolons. For example,
a cookie can be created by the server
by sending a line Set-Cookie:
name=newvalue; expires=date; path=/;
domain=.example.org.
The domain and
path tell the browser that the cookie
has to be sent back to the server when
requesting URLs of a given domain and
path. If not specified, they default
to the domain and path of the object
that was requested. As a result, the
domain and path strings may tell the
browser to send the cookie when it
normally would not. For security
reasons, the cookie is accepted only
if the server is a member of the
domain specified by the domain string.
If foo.com sent a cookie which had the domain name of bar.com, or even .com, then JavaSCript code on bar.com could read that cookie. However most browsers are configured to only accept cookies when the domain name matches, and would reject such a cookie.