If a session token is stored in a cookie that has httponly set, is there any way that a XSS vulnerability could allow a malicious user to steal a users session token?
In general, if
httponly is set on its token then an XSS attack shouldn't be able to retrieve a session token. Modulo past bugs in browsers and plugins, and server misconfiguration (eg responding to HTTP TRACE).
But it's not worth much. You can stop XSS from getting hold of the token, but an XSS attack still has full control of the session on the user's machine: it can force the user to do pretty much anything on the site, or falsify the user's interface to the site (eg to phish for site credentials). See BeEF for an example of what an attacker can achieve with a compromised session: you've pretty much lost already.
httponly at best makes life slightly easier for the attacker in that they can access the session from their own machine in their own time, rather than being limited by the amount of time the user keeps their browser window open. It's worth having
httponly where possible, but it's a mild mitigation that does not magically protect you from the effects of XSS.
If done correctly, HttpOnly prevents an attacker stealing the cookie. However, they can still perform arbitrary web requests impersonating the victim users, and extract the responses. For example, BEEF has a module to do this.
In other words, HttpOnly makes things harder for an attacker, but does not stop a skilled attacker.
Also, as others have pointed out, there are various flaws that can allow an attacker to extract an HttpOnly cookie.
Bottom line - all XSS is potentially serious and you need to fix the XSS flaws.
XSS attacks are so flexible that they can still be executed if, for instance, the HttpOnly feature has been used to hide the cookie from JS and ETC .
Other possible scenarios include bypassing CSRF tokens, exploiting browser weaknesses, spoofing internal web pages, etc.
Yes. Mostly. The header prevents "Cookie Stealing" which is an easy way for a script to hijack your session.
It also depends if your browser supports the HTTPonly header. If not then it is ignored and the functionality that it creates never happens.
Here is a link explaining the header a bit more. It also contains a table showing which browsers support it: https://www.owasp.org/index.php/HttpOnly
if the HTTPOnly is not set in the header you will be vuln. to XSS, only as much as your browser supports this flag in the header. The big item to understand is this is primarily contingent on the web browsers ability to set this flag.