Getting Started
Concepts
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.
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
https://owasp.org/www-community/attacks/Session_fixation
owasp.org
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.
Last modified 2mo ago