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.
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.
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');
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):
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:
TextUtils.ConvertToString = (owner, value) =>
if (value == null)
else if (value is string)
else if (value is DateTime)
return ((DateTime)value).ToString("yyyy-MM-ddTHH:mm:ss.fff", CultureInfo.InvariantCulture);
If value Is 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)
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.
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 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.
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.
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.
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.
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.
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.