Cross Site Scripting (XSS)

Cross site scripting is a technique to implement malicious script (into a server), which is then sent to unsuspecting users accessing the same server. The attacked user's browser then has no way to know that the script should not be trusted. It originates from the "infected" server. The browser will execute it.

Because the browser "thinks" the script comes from a trusted source, the script will have access to any cookie or any other sensitive information retained by the browser and used with your site. The script can even rewrite the html page(s).

XSS attacks basically can be generalized into two categories:

• stored XSS attack
• reflected XSS attack

Stored attacks are those where the the injected code is permanently stored on the target server (database, file system, ...). The victim receives this code when viewing any of the "infected" web pages from this server. Might be a comment field, a message forum, ...

Reflected attacks are those where the injected code is reflected off the webserver. This happens f.i. when unvalidated input is included into a dynamically generated page (search result pages, error messages, ...). Note that the assumption that this threat is not serious because the server only reflects the user's input is wrong. An attacker just needs to convince your user to follow a malicious URL and this can be obfuscated by means of many techniques (Phishing).

---

The best way to protect a web application from XSS attacks is ensure that your application performs proper validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed.

---

Libraries for regular expressions such as those found in mgBoost∞ project tailored for usage in eDeveloper will be of significant help when validating input or encoding output.

Significant protection from java script based attacks you can also gain by converting the characters in following table to the appropriate html encoding entity whenever you output any data to dynamically generated html. Source of this table is OWASP∞.

The column "HtmlEncode" states if this is an encoding ASP or PHP's HtmlEncode() would do as well (Yes) or if these functions would leave this character unencoded (No).
mgBoost∞ Version 0.0.3.1 comes with a function mgstrutl.mgstrutl_htmlencode which does either all these encodings (level 1) or only those HtmlEncode() does either (level 0).
If you do NOT do below encodings before outputting data your user's might get victims of a XSS attack to your web application.

character	encoding	HtmlEncode
<	&lt; or &#60;	Yes
>	&gt; or &#62;	Yes
&	&amp; or &#38;	Yes
"	&quot; or &#34;	Yes
'	&#39;	No
(	&#40;	No
)	&#41;	No
#	&#35;	No
%	&#37;	No
;	&#59;	No
+	&#43;	No
-	&#45;	No

eDeveloper does not do any encoding like above automatically. When you output (merge) data to a dynamically generated html page you need to do the required encodings yourself by applying a series of RepStr() function calls. There would be a property "XML output" on html merge forms which is supposed to do _some_ encoding of characters when merging to a XML file. The behaviour of this flag, which characters it encodes and if it is of any help for html output is however unclear and undocumented.

To successfully protect against XSS attacks against your web application (or sensitive data of your users, there's more things to consider. These (and explanation how to acoid them particular then if it relates to eDeveloper on server side) will be added to these site soon.

It is e.g. considered a very bad idea to allow HTTP GET. Servers can mount a defense against JavaScript Hijacking by only responding to HTTP POST. This is a defensive technique because the <script> tag always uses GET to load JavaScript from external sources. This defense is however error-prone. You might have to decide for a HTTP GET due to performance reasons or other things.

Another, way to prevent direct execution of the response to a request is prefixing (and potentially) suffix the response in a way which makes it impossible to execute the JavaScript using a <script> tag. The legitimate client application can remove this extraneous data before running the JavaScript.

---

Wikipedia on Cross Site Scripting (XSS)∞
Cross Site Scripting on OWASP∞
mgBoost eDeveloper libraries∞