HTML Injection is a security issue which occurs when you let users enter "html" content. So, for example, if you have a text control on a form, and Allow xHTML is on, then you're allowing the user to enter HTML and content, and then you will display that content using their HTML markup.
Unfortunately HTML is not limited to visual markup though. It includes things like the <script> tag, which allow code to be embedded inside the content. When unwanted html appears in user content, that is called HTML Injection. If the code they inject is JavaScript then that is the start of a "Cross Site Scripting" (XSS) attack.
If this code runs on _another_ users browser (no code runs on the server), then the attacker may be able to get information from them, or their computer in a way that the programmer did not expect, or intend.
In short, "cosmetics good, code bad."
For builds of NetTalk before 6.40 it was the responsibility of the developer (you) to make sure that anywhere you ticked on "allow xHtml", you checked that the xHtml you were displaying was "safe". However that's hard to do.
Scrubbing html of code is tricky because there are a large number of vectors that can be used. the <script> tag is not hard to remove, but it's the tip of the iceberg. So, to make it a bit easier, and ultimately more secure, from build 6.40, NetTalk has automatic scrubbing built in.
NetTalk uses a whitelist approach, accepting html it specifically recognizes as valid, and rejecting unrecognized html. This makes it more secure (because "new attacks" generally fall into the "unrecognized" camp.) The alternative (searching for specific bad code) may require updating regularly as new attack vectors are discovered.
In other words, some perfectly legitimate html tags are "blanket excluded" simply because they allow the user too much power. The legal tags excluded in this way are;
Excluded (by design):
base, body, button, canvas, comments, command, datalist, embed, eventsource, frameset, frame, form, head, html, iframe, input, keygen, link, menu, meta, nav, object, optgroup, option, param, script, select, style & textarea
In other words, content stored in your database, which will be displayed via a browse or form or whatever, will not be allowed to contain these tags.
Let me be 100% clear here. This does not affect the xHTML tab (where you can enter your own custom xHtml). It does not affect the html being generated by the templates. It only applies to html which is being read from the database - ie those places where you have explicitly ticked on "Allow xHTML".
The downside with this approach is that some "legitimate" HTML is not allowed. For example, the Hyperlinks example has a browse (BrowseMedia) which included HTML (youtube videos) containing <iframe> and <object>. Since those are both on the "not allowed" list, they are (by default) no longer playable. This may affect your application if you currently have very rich HTML content stored in your database.
So an extra switch has been added to the template wherever an "Allow xHTML" option is located, there's now also an option to "Allow UNSAFE xHtml". This puts the onus back on you to scrub the HTML in an appropriate way.
But wait, there's more...
You may want to change the list of tags that are allowed, either by adding more allowable tags, or by disallowing some tags which are allowed by default. In this way you can adjust the level of safety, without having to go to a completely unsafe mode. To do this you can embed code in the .TagOk method in the WebServer procedure. for example;
case lower(p_tag)
of 'object'
return true
end
Embedding this before the parent call, would make the <object> tag allowable.
As always, security remains a process, not a destination, so remaining up to date (or reasonably up to date) with NetTalk builds is always recommended.
Topic: Security: HTML Injection / XSS attacks. (Read 10800 times)