Develop Reference

Javascript to exploit cookies with samesite attribute?

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

Protractor - Clear LocalStorage to Loss Connection on Spec

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

When is it appropriate to have non-HttpOnly cookies on your domain?

I have read the OWASP information and also a range of articles including Jeff Atwood's Protecting Your Cookies article and I still feel I need to understand HttpOnly cookies better.
This came about because I needed to add some Google Adword tracking code to a site. This javascript needed to set and read a cookie on the website's domain and I assumed that this was an issue. The website is a .Net application with httpOnlyCookies="true" in the web.config, so I assumed that the best approach would be to replace the javascript and write the cookie from the backend to ensure that the generated cookie was HttpOnly. I could then easily read the cookie in the server-side too.
I understand that setting the HttpOnly of a cookie property largely prevents a cookie from being read and manipulated by the client. But what I don't understand is:
Given the example above, would there have been a problem with me using the javascript implementation?
Would it still have been ok to write the cookie using javascript (but still read it using the server-side)? I'm thinking not as the cookie is then not a HttpOnly cookie
If I have done the right thing (moving everything to a server-side implementation), why are Google Analytic cookies always implemented as non-HttpOnly cookies? Surely they pose a security issue too?
So as the title says, I guess what I'm asking is - when (if ever) is it appropriate to have non-HttpOnly cookies on your domain?

So this is much more straightforward than I assumed. According to the comments left by #mah above, flagging a cookie as HttpOnly is redundant when the cookie contains non-sensitive information.

The httpOnly option was response to JavaScript tricks to steal user's session cookie. It was because the session cookie is a temporary credential that allows you access to user's logged-in session on the server.
In case of any other, non-session cookies it really depends on your own risk assessment. If you're not really concerned about slightly increased exposure without httpOnly or you just have a business need to access their values from JavaScript, just ignore this option.
Some security scanners or incompetent pentesting teams will report missing httpOnly flags for each cookie just because it's trivial to spot and allows them to easily inflate their report. But explaining the actual purpose and origin of httpOnly should be sufficient to counter that.

How to read a parent domain's cookie

How can I access a cookie on ".bar.com" from javascript in a webpage at "foo.bar.com"?
document.cookie (in Chrome) doesn't appear to contain this cookie even though I can see it on the Resources tab in Chrome and see that its send to the web server on a POST.

when setting the cookie you define the domain it can be read from, subdomains also work.
There also exist http-only cookies, they can't be read using javascript but you will see them in the http request.

How to read a HttpOnly cookie using JavaScript

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.