|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
Security, or even IT systems security is an incredibly broad subject. With the world's millions of organizations with their hundreds of millions of computer systems, all of which are increasingly connected to each other, agreeing even on what we mean by security can be hard. For the purposes of this discussion we will use the following definition of security:
A system is secure when you can rely on it to behave as you expect.
The advantage of this definition is that it is founded on system behavior relative to expectations. This completely avoids binding the definition to anything technological, which is good because a technologically founded definition is bound to become obsolete sooner or later. The definition we use here should last a long time.
When you build Web Applications, the set of users that is technically able to use your application becomes very large; namely the number of people who have access to a Web Browser. Of particular interest, in this context, is that - unlike most other kinds of applications operated by organizations - Web Applications are easy to deploy beyond the boundaries of the organizations: The users of a Web Application do not necessarily belong to the organization that runs it.
This fact points to the reason why the issue of security is always one of the first things to be brought up when discussing the possibility of deploying Internet applications: The measures traditionally put in place to ensure an acceptable level of system security assumes that the organization has some power over the users. The power is used to regulate user behavior by other means or mechanisms than those built into the system itself. The threat of sanctions ensures a low rate of incidences.
Most organizations operate quite well on this basis, maintaining a fine balance between checks enforced by the system itself, socially enforced regulation of behavior, and the economics of the whole thing.
Deploying Internet-accessible applications completely destroys this carefully maintained balance by breaking the assumption of the possibility of imposing effective sanctions on users who misbehave. The loss of this option changes the likelihood of misbehavior.
If you decide to deploy an Internet-accessible Web Application then you will clearly have to consider the security aspects before you go ahead. Despite the hype surrounding all things related to IT system security, it really is not as bad as it has been made out to be.
Of course it is impossible to cover this subject in this Introduction; it doesn't even make sense as there are quite a few excellent books on the subject. Consult the Further Reading section for a few titles on the subject. Simson Garfinkel & Gene Spafford's book "Web Security and Commerce" (published by O'Reilly and Associates, www.ora.com) is an excellent place to start. It takes a broad view on the subject, and introduces the central concepts quickly and clearly.
Basically what needs to be done to deploy a Web Application on the Internet is to put in place a mechanism that will restrict access to corporate computers to a few, carefully configured and monitored hosts. Typically these hosts will act as the corporate web servers for external access to corporate IT resources. The mechanism used to restrict access is typically referred to as a Firewall or a Filtering Router. Firewalls are typically more sophisticated than the Filtering Routers, but the pace of change in this market is very fast, so it may have changed from the time this was written (Q2 1998) to when it is being read (now).
Firewalls and Routers perform what might be called network-based security screening. That is, they use the properties of the network traffic (e.g., source and destination of data packets, and for sophisticated Firewalls sometimes even their contents) to decide to let the traffic through, or filter it out.
The advantage of these types of devices is that they are generic, which means that they can work in any network. Thus they can be sold in large numbers, which means that they are relatively inexpensive compared to their relative sophistication.
Being network-based, however, imposes severe limitations on the kinds of security checks that can be performed. The reason, basically, is that network-based security systems can not within reasonable limits interpret the content of the traffic. So if you e.g. want to only permit access to customers who are not behind on the payment of their bills, network-based security systems come up short, because they do not operate at that level of abstraction - they don't know about customers and bills, only about hosts, addresses, ports and other network-related concepts.
Application-level security - or what might be termed business logic-level security - must be provided by some part of the application, because that is exactly where the data is available to make decisions based on the business policies laid out for that particular Web Application.
In any realistic Web Application scenario you will need security policies enforced that are formulated in terms of your business policies. You will, in other words, need application-level security in all your Web Applications.
The need for application-level security does not mean that there is no need for network-level security. The reason for this is simply that it is much cheaper to achieve a given level of security if you take advantage of the relatively inexpensive network-based security mechanisms, than if you try to achieve it using the application level only.
There are a number of security-related Websydian features. We'll discuss them in order of importance.
Websydian happens to be an excellent tool for enforcing business-logic level security. The reason is that all Web Requests made to Web Applications developed with Websydian are routed through the same gateway; and that the security checks are made at the gateway.
This approach is in stark contrast to most Web Application development tools, that distribute code bits across dozens and sometimes hundreds of files. Enforcing a security policy in such an environment means tracking each bit code to ensure that it does indeed make the checks required by the policy. In practice this is an almost impossible - and certainly expensive - task.
With Websydian the implementation of the security policies occur in one place. This makes it a lot easier to implement in the first place, and to maintain enforcement of the security policy during the life-time of the Web Application.
Almost all Web Application development environments rely on SQL as the interface between the Web Application and the database. That is, the systems running on the Web Server Host submit SQL statements to the database for it to execute. This means that the set of database operations that may potentially be executed from the Web Server Host is only limited by the DBMS user profile used to execute the submitted SQL code. Should the Web Server ever be compromised, intruders with malicious intent could modify the SQL code to be executed by the Web Application, and - perhaps - delete all the tables in the database, or something similarly disastrous.
When you develop Web Applications with Websydian, the application running of the Web Server is a - somewhat unusual - AllFusion Plex client. As you may know, AllFusion Plex client functions communicate with the database through AllFusion Plex server functions. That is, the set of operations that may be performed by a Websydian Web Application is limited to the set of server functions available to it. The damage a intruder might perform using the server functions is severely limited compared to that he might do with the power of SQL.
Many Web Application development environments rely on scripts that are executed by interpreters at the time the Web Request is made. Because interpreted scripts merely consist of text, a compromised Web Server Host would give an intruder the opportunity to change the scripts (including, possibly, the SQL statement embedded within them) to performed operation not intended by the organization which deployed the Web Application.
Websydian Web Applications are - like all systems produced with AllFusion Plex - based on binary executables. This makes it a lot harder for intruders to change the way Web Application works - you cannot easily change a binary executable. And, as mentioned above, the executable is limited in its scope anyway by the server functions available to it.
To conclude, Websydian-developed Web Applications yield better application-level - or business logic-level - security than most Web Application development environment alternatives.
Proceed with next section Further Reading on Internet and Web
technology.
Online documentation - Websydian v6.0