XSS - is it only possible by using JavaScript?

Question

I understand there are lots of questions concerning Cross-Site Scripting on the SO and tried to read the most voted ones. Having read some webpages too I'm still unsure about all possibilities that this attack type can use. I don't ask how to sanitianize input, rather what one can expect.

In most examples given on SO and other pages there are two methods, where the simplest (eg. this one on PHPMaster ) seams to be inserting some <script> code used for stealing cookies etc.

The other presented here by user Baba is to insert full <form> code structure, however it seems it should not work until user submits a form, however some JavaScript event like ... onmouseover='form.submit()'... might be used.

All network examples I've been able to check are only methods based on using some JavaScript code.

Is it possible to use other methods, say -- somehow -- changing the HTML, or even the server-side script?

I know one can obtaining this by SQL injection or just hacking on the server, but I mean only by manipulating (wrong handled) GET, POST requests -- or perhaps some other?

Answer 1

XSS is about javascript.

However to inject your malicious javascript code you have to use a vulnerability of the pages code which might be on the server or client side.

You can use CSP (content security policy) to prevent XSS in modern browses.

There is also a list of XSS tricks in the XSS Cheat Sheet . However most of those tricks won't work for modern browsers.

Webkit won't execute javascript if it is also part of the request. For example demo.php?x=<script>alert("xss")</script> won't display an alert box even if it the script tag gets injected into the dom. Instead the following error is thrown: "Refused to execute a JavaScript script. Source code of script found within request."

Answer 2

I know one can obtaining this by SQL injection or just hacking on the server, but I mean only by manipulating (wrong handled) GET, POST requests -- or perhaps some other?

GET parameters and POST bodies are the primary vector for attacking a web application via HTTP requests, but there are others. If you aren't careful about file uploads, then I might be able to upload a Trojan . If you naively host uploaded files in the same domain as your website, then I can upload JS or HTML and have it run with same-origin privileges . Request headers are also inputs that an attacker might manipulate, but I don't know of successful attacks that abuse them.

Code-injection is a class of attacks that includes XSS, SQL Injection, Shell injection, etc.

Any time a GET or POST parameter that is controlled by an attacker is turned into code or a programming language symbol, you risk a code-injection vulnerability.

If a GET or POST parameter is naively interpolated into a string of SQL, then you risk SQL injection.

If a GET or POST parameter (or header like the filename in a file upload) is passed to a shell, then you risk shell injection and file inclusion .

If your application uses your server-side language's equivalent of eval with an untrusted parameter, then you risk server-side script injection.

You need to be suspicious of all your inputs, treat them as plain text strings, and when composing a string in another language, convert the plain text string into a substring in that target language by escaping . Filtering can provide defense in depth here.

---

XSS - is it only possible by using JavaScript?

No. VBScript can be injected in IE. Javascript can be injected indirectly via URLs and via CSS. Injected images can leak secrets hidden in the referrer URL. Injected meta tags or iframes can redirect to a phishing version of your site.

Systems that are vulnerable to HTTP response header splitting can be subverted by HTML & scripts injected into response headers like redirect URLs or Set-Cookie directives.

HTML embeds so many languages that you need to be very careful about including snippets of HTML from untrusted sources. Use a white-listing sanitizer if you must include foreign HTML in your site.

Answer 3

Cross-Site Scripting is not just about inserting JavaScript code into a web page. It is rather a general term for any injection of code that gets interpreted by the browser in the context of the vulnerable web page, see CWE-79 :

During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.

An attacker could, for example, inject his own login form into an existing login page that redirects the credentials to his site. This would also be called XSS.

However, it is often easier and more promising to inject JavaScript as it can do both control the document and the victims browser. With JavaScript an attacker can read cookies and thus steal a victim's session cookie to hijack the victim's session. In certain cases, an attacker would even be able to execute arbitrary commands on the victim's machine.

The attack vector for XSS are diverse but they all have in common that they are possible due to some improperly handled input. This can be either by parameters provided via GET or POST but also by any other information contained in the HTTP request, eg cookies or any other HTTP header fields. Some use a single injection point, others are split up to multiple injection points; some are direct, some are indirect; some are triggered automatically, some require certain events; etc.