Bigger picture questions about wisej:
Thanks,
Mark
Thanks for the detailed answers Luca… excited about this product. In my view it might be a game-changer for the asp.net mvc world, which sorely lacks ui design capability.
Mark
Hi Mark,
I will answer in two separate posts.
Security is a very important topic especially when dealing with web apps. I’ll cover the most common vulnerabilities, but please send me anything you can think off that may be a threat.
HTML/Script injection
One of the biggest difference between a traditional ASP.NET/MVC app and a Single Page App (SPA) is that there isn’t any HTML built on the server and sent back to the client. Everything happens on the single page manipulating the DOM. This is true for all (most actually – VWG was recreating the DOM in most cases instead of manipulating it) SPAs. This removes any risk on code injection since scripts are not executed when using the DOM (innerHTML to be specific).
Session Hijacking
This is a common problem for all web apps – especially with ASP.NET/MVC, PHP, JSP – that maintain a session which requires either a session cookie or an id in the URL. If someone gets hold of a live session id they can add it to the URL or set it in a cookie and access a live session. Wisej supports both cookies and cookieless sessions. In order to prevent session hijacking Wisej checks the clien fingerprint on every request. If it doesn’t match it will assume it’s a new client and it will create a new session. This avoids also the potential problem of stale sessions. You can see the client fingerprint using Application.ClientFingerprint. The best way to also protect against a potential session hijacking is to enable SLL. Wisej can force the app to use SSL by setting “forceSecureConnection”: true in the application’s json configuration file.
DoS Attacks
We didn’t include code to protect against denial of service attacks 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. If using the async IHttpHandler you can block the request without using a thread but then all the DoS requests would still bring down the legitimate requests. DoS 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 I don’t think they are effective at all against a DoS attack.
Authentication
Wisej can authenticate users however your app wants to. Since nothing is shown to the user or it’s even present on the browser unless your app has created and shown the page, form, control, etc. You can authenticate, disable, hide, show anything depending on the roles, permissions, etc.
Sensitive Data, Keys, Code, Tokens
Traditional HTML assemblage systems always end up with a mix of javascript on the client, callbacks, postbacks, services, api keys, and so on. A potential intruder can simply look at the code and page and may be able to acquire sensitive info. The same vulnerability is actually much bigger on SPAs systems like ExtJS, or even standalone qooxdoo, dojo, or any javascript only framework. Since you are forced to put some code on the client and some on the server mostly as services and open end points.
With Wisej there is absolutely nothing by design from you app on the client (unless you put it there). It only runs the widget library with the only task to display information received by the server and send events back. Everything coming from the server is a simple, readable, JSON set of properties that describe the state of each widget (i.e. {“id”: “id_45”, “width”:34, “text”:”Hello”}). Nothing can be gained by looking at the communication since it’s all data used to update the screen anyway.
This will be a topic in the docs as well.
/Luca
Hi Tiago,
All settings in Web.config work as always. Wisej doesn’t change the standard web pages (html, aspx, cshtml, …) – unlike VWG where the handler took over the page request completely. Wisej’s .wx handler serves one script and processes ajax (http or websocket) requests thereafter.
Look in the Default.html (could be Default.aspx or cshtml, or MyApp.html, makes no difference) and you will find just an empty html page and a <script src=”wisej.wx”/>. How that page is served or authenticated is entirely up to the server (IIS for now).
If the user is authenticated you will find the information in Wisej: Application.IsAuthenticated and Application.UserIdentity.
HTH
Best,
Luca
What about the authentication and authorization keys in <system.web>? Are they useless?
Here is the second answer.
Wisej can use ASP.NET/MVC pages using the AspPanel. The ASP.NET/MVC code behind or code in the page once loaded by the AspPanel can use any component in the Wisej session.
The other way around is also possible by using the WisejPanel in ASP.NET/MVC, which is not available yet. The reason is that originally we developed a set of markup properties like this <div data-wisej=”MyApp.CoolPage”/> and Wisej would instantiate that specific control or form and put it inside the div. We removed this since it was a basically a completely different approach to developing the app and inconsistent with the core architecture. It was basically trying to be too many things at once…
The best and easier approach is a simple ASP.NET/MVC control WisejPanel. This panel can include any Wisej individual control or entire form inside a div in the ASP.NET/MVC page. It uses qooxdoo’s inline root. In Wisej the root is the base container. When you run a wisej app there is a main root div in the body tag that includes all widgets, that’s the application root. In addition to this qooxdoo supports inline roots, which are light multiple containers that can be placed inside other divs.
HTH
Best,
Luca
