Best way to implement authorization in Web 2

Targets Web
1

In this thread the best way to implement security was implicitly discussed, but it’s better to obviously discuss it in a separate thread.

It seems to be too late to tackle permissions you want to grant once a webpage has been called. You can’t stop via any event to reject the page if the framework is already “loading” it. The way I have so far implemented security is to check the permissions in the session opening event. The user has to login and according to his detected role I decide which page he is allowed to view and which one not. After authentication I therefor store the user’s role in a session property and react (hopefully) everywhere (menus, buttons, dialogs etc.) in my code accordingly.

Another approach would be that you can define per page in the IDE what the prerequisites are to access it. For the beginning a simple function like a checkbox “protected” per windows in the IDE would be sufficient to ensure that his page can’t be accessed (by mistake in your code) as long as a certain variable is not set (e.g. wpMain.protected = true would mean that the session.variable admin_access_granted needs to be set as well). This is obviously (not yet) possible and would be a feature request.

I’m fine for the time being dealing with the “session approach”. But I havestill a question in mind and haven’t found an answer yet: Is the framework ensuring that by no means a window could still be opened via a certain URL (even if it is very cryptical one) or through any other “hack”?

2

As far as I recall (without checking) pages aren’t sent unless you call .Show, so you’d need logic to show the page based on this. If they are able to bypass your authentication, that’d be a problem in your authentication method rather a Xojo problem. I wouldn’t want them spending time building an authentication and protection scheme, personally.

1 Like
3

I am fine with the session approach as well. Even in those python or whatsoever frameworks were you often have a protection scheme on the “routing layer”, you need to trust the framework. But in the non Xojo world, if you are paranoid you can often still protect these webpages on top via .htaccess or via your webserver etc., as their “pages” are native or dynamic html files on the server.

In Xojo we have to fully trust the framework - what I do. I have the same understanding than you, that a webpage (even if you changed the “behavior” to “implicit” instance) will NEVER create an instance, as long as you have not yet called the page via the show method. And I think that once the page is called it is not possible to call it with anything different than through the theoretical option to save the whole session somehow. The latter would even be ok, as it is still the right authenticated user who logged into that session.

But all this are my assumptions (and my understanding so far), I just want to double-check if my understanding is really how Xojo designed it.

I had during my “career” a few challenges with solutions which worked differently than I assumed they would. Like we have to pay attention in Web 2 in how we are using global modules. I’m not sure that everyone considers all (negative) implications by doing so. That’s my only argument for Xojo implementing a security layer.

Thinking less of myself but people new to developing for the web. With all the root kids around the block security on the internet is a complete different story than software for an OS. This said: I don’t want them to waste time on it either, as it would be a huge project probably. One approach could be a template from Xojo how to deal best with security, so basically extending the already existing login example for Web 2.

4

It is as simply as allways load a dummy page. In there call the login form and if it is a valid user, redirect him to the secure page acording with its role.

That makes no sense, xojo pages are not the same as web pages. You cant acces them by a URL, just load and unload them carefully. Even if this was not the case, the same mistake in your code could allow mark a webpage as protected = False. Also, making a property like this, will not alow you to have roles, or user levels.

You are thinking of pages as in files in a webserver BUT they are NOT, the key here is to think of The xojo web app as a SINGLE PAGE with dinamic content loading on it.

Well, all this in web 1, web 2 is still too buggy to use it, but I think it is the same.

5

The typical approach in php based web apps is to rely on the url to direct the user to the correct (possibly custom constructed on the fly) web page. While you could build a similar system in Xojo, by default, it doesn’t work that way. There is only one url and your app serves/displays the appropriate page based on your app’s logic. Think of it this way, there is only one page and you control the content.

6

One thing to consider is where data is located in the Web 2 system. For example, I have a messageDialog on a WebPage. Some of the commands are only allowed for admin users:

My first try was this:

MessageDialog1.ButtonPressed (button as WebMessageDialogButton)
select case button.Caption
case "Continue"
   DoNextTrial()
case "Close"
  DoClose()
case "Override"
  DoSecretAdministratorOverride()  // only admins can do this
end select

In other words, the security logic was being stored in the button caption.

Could this be a security hole? Is WebMessageDialogButton.caption stored in the sever or in the client? (or both?) If it’s stored client-side, then a malicious client could alter the caption via javascript and send back the “Override” keyword, bypassing security checks.

My solution was to instead store a “isAdministrator” boolean as part of the Session instead, and then my code looks like this:

function DoSecretAdministratorOverride()
  if not session.isAdministrator then
      // raise some sort of error here
    return
  end if

I’m relying on the assumption that session variables are not sent to the client, and therefore could not be altered by a malicious client.

These sorts of designs depend on us (the programmer) knowing where data is being kept, and with Xojo Web that is not always obvious.

1 Like
7

Thanks Mike, I’m finally understood.

Safety is often not taken seriously, especially by beginners. One example: “SQL Injection”? Yes, one has read it once, but the app doesn’t ask any data from the user, so everything seems to be fine (we’ll look at it “later”) … and then the same developers are surprised when their tables are suddenly empty (because they allowed to upload user data and didn’t consider this to be a “user interaction” too, with potential SQL injection risks later in their code … or they simply forgot that their login dialog can already inject SQL in the worst case :frowning: .

Questions like yours are also concerning me, and (even though I do know that a Xojo WebApp is just “one” page) I’m interested what possibilities there could theoretically be for someone to access via JavaScript, DOM manipulations or whatever “illegal approach” a specific WebPage (Xojo speak here not HTML) and thus bypassing my “brilliant” code. Security can only be implemented if you exactly know and understand the facts. We could for instance store the session and keep the access “alive”.

Of course, my comparison with other frameworks lags because they are different concepts (with pros and cons), and my statements probably also suffer from my imprecise English. What I wanted to say is that you often have other, additional security options in other concepts. The good thing is that you don’t need those in Xojo Web. As in Xojo Web 2, a Xojo “WebPage” is generated and runs in a “bubble” from and within the Xojo Framework there is not much we can likely implement “on top”. The good news: it seems not to be necessary, but like you I’m not yet convinced that I have not overlooked “something”.
The few things we can of course do (and probably should do), are all “outside” the framework: monitor our database activities, checking if our linux executes might got compromised, storing more information then needed for own monitoring measures (for instance not only checking user credentials, but storing every try of a user to login, etc.) plus the minimal security prerequisites like SSL certs, firewall settings, thoroughly securing the database, server and filesystem, running the app with an own user with limited rights (only to mention a few). And of course (for completeness), we can always use Xojo Cloud and putting all those potential IaaS & PaaS risks contractually on the vendor.

Like you, I currently rely on the fact that everything within a session, i.e. parameters and methods, cannot and won’t leave this context. So far I haven’t found anything that makes me doubt it.
We know that we have to be extremely careful with global methods and parameters, as they are not session specific and I do avoid them in Xojo Web Apps, definitely for sensitive content. My “authorization” concept is completely session-centric. The question that remains is how safe “our” approach really is, or if there is anything more we need to consider. Or if there are any best practises what should be monitored on top or how we could further tighten the security (either within Xojo, or on server level).

Side note: I don’t want Xojo to implement a full-blown authorization / role concept. I’m fine that was programmers we have the possibility and the freedom to implicitly define our own concept. However I do like the concept of other languages to endorse minimal security by an explicit security “layer”. That’s what I tried to describe with a flag for a “Xojo WebPage” in the IDE. Of course this does not add any gain of security if a developer forgets to set that variable. But if that variable would be set (i.e. this is a “protected” page), the framework will ensure that such a page will never be shown, unless the developer read the documentation and learned which settings in the session context he has to set to enable access to such “protected” pages). You could as well think of the project analysis telling you that you app contains “protected” pages, but your code doesn’t yet take care of those etc.
This is more a theoretical discussion how to ensure Xojo’s success on the web. Leaving security to the developer is fine, but for beginners there might be the risk to just “forget” what they have to consider and what they need to care about. - it is “funny” for instance to see how many accesses we have on all our Web Apps from all regions of the world, including people / root kids / bots trying to log in. That’s the area where I think Xojo could help beginners at least with a template for a more secure login (for instance using captchas etc), or even better: deploying secure login control capabilities embedded into the framework. (an argument against such an approach is, that the best security concept often is to implement it a bit different for each application, but none of us will likely share his concept as this will be a security issue on its own :wink: ).

8

I really feel two things here:

  1. Authentication and Authorization are being mixed, and,
  2. This is being over-thought

In terms of Authorizationb(to view a particul ar ‘page’) I created Roles and Groups that can be granted accesd to any particular ‘page’ or not. Upon request for any ‘page’ the permissions are checjed. That’s it.

1 Like
9

Ok, let’s take a new BMW car.

You can say the car works perfectly fine for you and you are done. Of course you can’t understand everything in your car’s “framework” and it should not be something you have to be concerned about. Same applies to Xojo Web’s security pattern.

Even if your are a motor mechanic or a car tuner, you have to trust your APS system, you have to trust your airbags etc. You might be able to exchange such systems but you have to trust that the manufacturer of those devices have done their homework. The devices are sealed, you can’t do anything else then building them in and that’s fine (actually it is part of the security).

According to the BMW’s recommendation (until today) you can as well trust their keyless-go feature. But a considerable amount of cars in Germany are meanwhile stolen via devices you can buy online for a few EURs which capture the signal of your key. Once captured, the tool is manipulating this caught signal to open your car, deactivate your immobilizer and the thieve is ready to go in less than a minute. If he is fast enough to cross the border of the European Union, chances are very high that you will never see your car back again. You still have your key to reminisce …

Now I would not conclude that BMW engineers are stupid people. Every system can be hacked, or has perhaps backdoors which can be mis-used. But you can trust the system or you can take precautions when you were made aware of some risks. In the case of keyless-go systems it is apparently relatively easy to protect yourself: don’t leave your key on a window bench close to your car, put it into a drawer somewhere inside the house, leave it in your pocket or, if you are paranoid, put it into a metal box or wrap it into aluminium foil.

In coding for Web your Achilles heel is the login logic. If you do it wrong, people can inject SQL and even without authentication they can cause severe harm for your data. That’s not Xojo’s fault, it is our accountability to avoid it. Same applies to authorizations, so we should know all possible traps and trip hazards.

I am lucky that i don’t own a car, but I have a (legal) accountability towards my customer to protect their data. Now Xojo will not explain us in detail how their APS system is working but they shared already many best practises on this forum how to secure your compiled product.

All I want to ensure is if my understanding is right and if anyone has found some “broken” keyless-Go features, means if a Webpage could in theory be accessed via JavaScript injections or whatsoever, bypassing all my good intentions to protect the data in my code. This won’t happen out-of-the-box of course (that would imply a security patch from Xojo and is a different story), but I want to better understand what we developers have to ensure for not living on the edge and compromising the built-in security and to clarify what Xojo recommends to ensure max. security.

For instance we have seen many JavaScripts hacks on the forum (though not recommended by Xojo) to achieve whatsoever goals. Could such a JavaScript “injection” weaken the built-in security? I just don’t know, that’s why I’m asking.

And with Xojo Web we all depend mainly (at my current understanding) on the built-in functionality, which seems to be excellent, but only if we are using it in the right way.

In other non-xojo concepts, I can mistrust the vendor or mistrust my own coding capabilities and add some additional security layers, not so much with Xojo, so we need clarity how to use the tool in exactly the right way Xojo has designed it.

I am implementing my authorizations the same way you do. But this concept is proned for security leaks if not implemented everywhere. As you can’t yet check in the opening event if a webpage can be opened (or what should be shown on this page), you have to do it (like you do) BEFORE you are even calling a page. The risk is however, if you are later adding a webmenu item or a button on that page to open some other pages, then you have to ensure again to check against our defined roles before showing this page. This is where an approach to protect your page within itself regardless from where it is called has many benefits.

That’s the reason why I opened this thread, as I unfortunately jeopardized this thread. If the opening event would work like I expect it to work, I would be fine. Then we could implement our authorization checks into a sensitive page and won’t need to take care if in 5 months time we might by mistake forget to check our authorizations before(!) calling that page somewhere in our code. Your app won’t work the way you designed it and you have a bug, but at least you would not breach your security concept.

10

The short version of this is that you must check whether a user is authorized before showing options on the page and when a response is sent to the server. Xojo apps are no different than any web application written in any other language in that a crafty user could use JavaScript to send a malicious command to the back end.

So in Mike’s example, you would want to check if the user has the super secret admin privileges before actually taking that action.

1 Like
11

Thank you for confirming @Greg_O_Lone and the honest answer - that was my suspicion too and for me it is yet another reason why not to use any checks in the opening event of a webpage (even if this might work in future) as the sole fact that the page has already been called would be a (theoretical) unnecessary vector for crafty “users”.

For secret pages I’m logging such accesses. It’s a quick insert into a log table, and helpful for periodic manual health and sanity checks.

Anyways, most “attacks” I’m seeing are silly DoS attempts and SQL injections and far too many devs don’t pay much attention on the latter. Especially when using common IaaS Services like digitalocean, beginners should know that they might have obtained an IP address from a former server which was already successfully under attacks. The root kids don’t know that you are the now the new owner and might try to continue doing the security checks, you forgot to implement :frowning: .

I’m seeing this all the time with new servers: heavy accesses the first few days / weeks, and then the situation “cools down” when they probably realize that they can’t access it any longer. For sensitive data I would always recommend Xojo Cloud and putting big parts of that security work on you/Xojo :wink: . Sadly I have in majority tightfisted customers like NPOs which can’t justify these recurring monthly fees.