Preventing JavaScript Injection In my opinion the best thing to do is assume it's possible that your data has JavaScript code in it and make sure you're escaping this properly when writing it to the browser. As discussed during the session all Uniface widgets will do this for you, with the exception of the Raw HTML widget. If you did want to sanitise user input you can put checks in any web trigger or web operation that accepts string data. You could could check for strings like <script>alert(“Hello World”)</script> and remove the script tags or some such. However, take a look at this list of ways to inject JavaScript: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet. So really the best approach would be to take a whitelisting approach instead. Whitelisting would mean “You should only be able to enter the characters A-Z and a-z in this field” for example. That makes it nearly impossible to inject JavaScript. Uniface fields can do this sort of validation, you could also do it in your web triggers and web operations using Uniface syntax strings.

Secure Cookies During the session we looked at how an attacker might use JavaScript injection to steal a session ID from a victim. An attacker might also attempt to steal a session ID by reading the traffic between the server and the browser. Indeed, this is how the Firesheep Firefox extension worked (http://en.wikipedia.org/wiki/Firesheep). Because of this most sites now run over HTTPS to make this sort of man in the middle attack more difficult. When running over HTTPS it's a good idea to also set the "secure" flag on any cookies created, this signals to the browser that it should only send cookies over an HTTPS connection, preventing the session cookie from leaking out accidentally over a non-secure connection. In Uniface applications we have 2 basic flavours of cookies. Those created in Uniface and the session cookie created by Tomcat. There are many ways to configure Tomcat, but one way to force the session cookie to be flagged as secure is to add the following inside the webapp element of your application’s web.xml file: <session-config>     <cookie-config>         <secure>true</secure>     </cookie-config> </session-config> For cookies created in Uniface things are a little bit easier. Uniface will automatically detect whether the connection is secure or not and set the appropriate secure flag on the cookie. Note, this does mean you can’t share cookies between http and https connection by default.

I've had a few questions over the last couple of days which I'll write up here.