Implementing Web Security Using Oracle JDeveloper[1]

Dr. Paul Dorsey, Dulcian, Inc.

With the widespread use of Internet and Intranet systems, computer security is an increasingly important consideration. Viruses must be guarded against and business transactions require sensitive information to be exchanged electronically. Unfortunately, security is often only thought of after a security breach occurs. It is important to consider security issues at the outset, when you are developing the requirements for your system. In addition, the security considerations for any system are not limited to potential fraud or mischief. Application design issues and security concerns may overlap.

Think about the purpose of security in your system:

1.       What specifically needs to be kept safe?

2.       How much money and what resources can be expended to implement security measures?

3.       What system design measures should be taken to ensure security?

4.       What potential risks are there to your software and hardware?

5.       Take into consideration both internal and external malicious manipulation of your data/systems?

6.       Who will be the final authority for providing and maintaining consistent security for your system?

This paper will discuss the issue of security and how to use JDeveloper to ensure the integrity of your system.

 

Security Issues to Consider

When thinking about system security, it is useful to identify the types of exposures that must be taken into consideration. Too often, the “solution” selected for handling these exposures is to do nothing. Many IT shops handle security by identifying possible exposures and designing a set of controls to protect against breaches of security.

In determining your security requirements, consider the potential impact of loss and the probability of that loss to your business. You should add sufficient security to your system to compensate for the possible loss of critical data at a cost commensurate with the value of the data being protected.

For example a costly cash register system was proposed for use in a 15-branch library network to track the account activity for fees collected over the counter. As good as the elaborate new cash register system was, the relatively few dollars in discrepancies that could be resolved by the expensive cash register system would never offset its cost.

If the cost of a security breach can be very large, then even a very expensive control that protects against that breach can be appropriate. For a bank processing wire transfers, the security measures required that each request be manually entered twice. Unfortunately, two data entry personnel coincidentally made the same error resulting in the loss of $1million. Subsequently, the bank modified its data entry procedure so that each wire transfer was independently input by three different data entry people. The monetary and political costs of these extra measures were justified by the potential risk of losing large amounts of money otherwise.

Exposures

With the widespread access to the Internet, there is a possibility that someone may attempt to interfere with business transactions. Larger enterprises may become targets for many types of security breaches.

Computer and manual controls can help prevent errors, fraud and sometimes help detect programming errors. Requiring a purchase order to be signed by a manager means that the orders were actually handled. Using approved lists for vendors purchase order items can help decrease data entry errors. Physically counting inventory may detect a purchasing system error. You should consider all controls and exposures together.

Database, application-level and accounting controls are not independent issues. A successful security strategy mandates integrates all three control types. The goal is to prevent exposures by reviewing all potential risk moderators to r assess whether or not the security measures taken are adequate.

Building a Security Matrix

One useful tool in assessing security requirements is to construct a matrix listing all exposures that have been identified along one axis. The other axis is used to list all of the plausible controls. The intersection of each control and exposure describes how effectively that control decreases the risk of that exposure. A sample matrix is shown below. Blank cells indicate that a specific control has no impact on the corresponding exposure. If the control decreases the risk of exposure, its effectiveness is assessed as low, medium, or high.

Exposures	Controls	Backup System	Double Entry System	Manager Approval	Passwords	Overall Risk
Hardware Failures		High				Low
Human Error			High			Medium
Fraud			Medium	Medium	Medium	Medium

Table 1: Control/Exposure Matrix

You can identify your exposures in broad terms or be specific to a level of detail appropriate for your organization.  In some cases, very general controls can support a wide range of exposures.  For example: “Have each piece of code be visually inspected by a code supervisor to guarantee no fraudulent code prior to implementation.”  However, this type of control can be prohibitively expensive.

Assessing the effectiveness of each control is a professional judgment and should reviewed by a systems auditor.  The matrix shown in Table 1 was intended to be illustrative.  A fragment of an actual control/exposure matrix is shown in Table 2.

Exposures	Controls	Each transaction entered by three different people	Transactions are randomly assigned to data entry	Passwords	Overall risk
Manual Error on data entry		High	-	-	Low
Two-person fraud collusion on data entry		High	High	Low	Low
Three-person fraud collusion on data entry		Low	High	Low	Low
Duplicate entry of data		High	High	-	Low

Table 2: Control/Exposure Matrix Fragment

When the matrix is filled in, the quality of your internal control system can be assessed by the ability of your security measures to protect the system from each exposure. There may be redundant controls that can be eliminated. When the internal control system is complete, a report should be prepared explaining the level of security in place for the system. The information contained in this report can be used to determine whether or not the existing level of protection is adequate.

JDeveloper projects require the same strategies for handling exposures. However, deploying in a web environment, adds new exposures to handle that do not need to be considered for client/server systems. There are four main exposure categories specific to the web environment.

Data Interception

The most obvious security exposure is theft of information. When you buy something over the Internet and provide your credit card number, you do not want anyone to see the information being transmitted.

This exposure requires some type of secure encryption so that, as the information moves from place to place, the bytes cannot be decoded if they are intercepted.

Hacking

Because some users accessing your system can do so through the Internet, the same Internet portal could be used to enter your system with malicious intent.

To prevent system hacking, you access to your site must be limited. This may be a complex problem to solve. You may need some applications accessible to everyone but only with limited capability. A visitor to a commercial website should be able to place an order for a product by entering the relevant information.  You may want to allow customers to access their own account information. At the other end of the spectrum, your web administrator may need to access the entire system remotely and make substantial modifications remotely. Obviously, this capability should not be publicly accessible.

The Oracle server should not be visible outside of your firewall. If the server needs to be visible outside of the firewall (for remote DBA access), you will need to change all of Oracle’s default passwords. Don’t forget about SCOTT/TIGER since the SCOTT schema has resource privileges.

Keeping an audit trail is another good security measure. Employees wishing to inappropriately access company information might do so by gaining access from a remote site (such as an Internet café) to minimize the risk of being caught. You need to plan for security controls not only to prevent outsiders from damaging your system but also insiders who may have intimate knowledge of your system.

Intercepting or Altering a Business transaction

In some systems, the interception or alteration of a business event may not be a major concern. If you are a retailer, you probably have little risk that anyone would go to the trouble of intercepting and altering orders. However, credit card information or other sensitive data must be transmitted securely. If the transaction is of significant size or involves the transfer of large sums of money, the motivation to alter such a transaction is high. You must pay special attention to security measures to prevent this type of fraud.

The solution to this exposure is essentially the same as for the interception of data. Data that is encrypted to prevent interception also cannot be altered. The key to a good security plan is to have more than one control for any type of exposure. If the first control fails, there should be additional control measures for all exposures.  

Overloading Attacks

This exposure involves generating of large numbers of fraudulent transactions that crash a site. This may appear to be a difficult exposure to guard against but the only web sites damaged by this type of attack are those that do not anticipate it.

Most overloading attacks come from the same Internet Provider (IP) address. You can detect and count transactions from any one IP address. If the transactions from any one IP address exceed a certain number, access from that address can be cut off.

Keeping your system safe

There are two important ideas to keep in mind regarding exposures. First, any control can be circumvented by a determined person. Second, the more secret you keep your controls, the more effective they are likely to be. As few people as possible within any organization should know what type of security measures are being used and how they are implemented. In addition to security breaches from the outside, you also need to protect against fraud and malicious attacks from disgruntled employees or other insiders.

 

Access Control

Understanding the logical and physical architecture of your system is necessary in order to determine the appropriate security solution. A stricter set of requirements will be needed if you are going to allow users to access your system via the Internet. Less stringent measures would be needed if you were implementing an isolated LAN for trusted employees. Natural security boundaries such as routers and firewalls can help facilitate a secure environment for your system. If you are using the Internet, you should have at least one firewall. In addition, systems using web and application servers should have at least two firewalls: one between the Internet and the servers, and a second between the servers and the database. In critical applications, use a third firewall between the database and the internal network. This third firewall is helpful in preventing hackers who may have reached your database via direct access to your network.

Types of Users

In solving security problems, there are two classes of users to consider:

·         Internal users These include customer service representatives on the road, managers, and other employees requiring remote access to information.

·         General access users These are members of the general public using the Internet.

There are more tools available to protect systems internally than there are for external access to a system. Users may have tokens or secret steps, as in the old days of dial-up modems that connected with no visible cues. Users needed to know what to enter in order to access the system. Other methods of keeping the system secure can include displaying only certain pieces of information based upon individual roles and security levels.

Implementing Controls

Controlling access to critical assets is based on the sound implementation of four key concepts: identification, authorization, verification, and encryption.

Identification

The process for determining who is attempting to communicate with your system is known as identification. This is typically accomplished through user IDs and passwords. In newer systems you will find biometrics (fingerprints, eye scans), digital media (smart-cards), and digital signatures being introduced.

Authorization

Authorization is the process that determines which applications, files, and data users will be allowed to access. Some of your web applications may be open to everyone in a read-only mode to promote your products or services, while the ability to edit, update, and delete files will certainly be limited to individuals or groups within a predetermined set of trusted users.

Verification

Any time you transfer information, it is important to know if the data sent was actually received exactly as it was sent. In the past, this process was generally performed using parity checks on the local hardware. When your critical data is exposed to open environments such as the Internet, other techniques such as digital signatures and hash-codes can be employed to ensure that the data has not been tampered with.

Encryption

In today’s Internet commerce environment, applications must be secure in many ways. As data travels across the Internet, it travels in packets across multiple servers, allowing others access to your data packets. When you are transferring sensitive data (such as bank account number, pin, or SSN), it is imperative to use some sort of encryption to reduce the risk of others being able to view the contents of your transfers. Encryption techniques backed up by digitally signed certificates can give your remote clients the ability to interact with your systems with complete confidence. Public and private keys can be certified through trusted agencies, giving your remote clients the ability to interact securely with your systems.

Application Security

Application security revolves around issues that center on your hardware and on the communications that occur between your application and other resources. When evaluating the overall integrity of your application, you must explore how memory is utilized in your box, what happens when buffers overflow, and what privileges have been granted to applications that may be running on, or interacting with, your machine. Also, you should consider what happens to the data after your application receives it. The Secure Sockets Layer (SSL) protocol developed by Netscape provides a software layer in between your browser application and the TCP/IP layers. However, implementing a Secure Sockets Layer transfer from your client machines while using an open email link across the Internet to communicate the results is a wasted effort. Like a chain, a security system is only as strong as its weakest link. The strength of each link in the entire chain of your data flow must be considered in order to ensure full security.

Operating system and peripheral application selections can also have a significant impact on overall security. Older-style file transfer programs (FTP) can leave big holes in your security if they are based on the older FTP protocol. Newer extensions of HTTP such as HTTPS that can be protected with SSL can often replace these older programs. Periodically reviewing your user accounts and the privileges that you have granted them should also be part of your security plan. It is important to limit the system-level privileges that you grant to reduce the chance that you will compromise the entire system. The prudent use of routers and firewalls can also help to isolate data paths in your network, thus giving you better protection for your critical assets.

Don’t forget to evaluate the physical environment that surrounds your system. Leaky roofs, water lines, chemical exposure, dust, temperature controls, humidity, earthquake, flooding, lighting, and electrical surge should all be considered in your security plan.  If anyone can walk up and gain access to your servers or if you locate your critical machines in an environment where they can be easily compromised, even the most sophisticated security system can be rendered useless.

Security in Java

The Java language has taken security issues into account from its inception. Pointers used in many other languages were eliminated to prevent Java routines from accessing other parts of memory. Permission levels, digital certificates, cryptographic keys, and signed files were added to increase security options. These mechanisms are used to control code and machine access, identify users, hide data, and provide additional privileges to trusted sources.

Using a client browser to display a Java applet is a common Java deployment option. Unless they are given special permissions, applets are very secure and cannot interact with other system resources (such as reading or writing files). Tracking and controlling security preferences in Java is accomplished using a combination of policy, security, and certification files. You may find several sets of these files on your system, as each Java-related product might have its own set. The Sun Microsystems default security files are listed below:

·         java.policy Basic policy file that stores your default permissions to access specified properties, allow thread stopping, and grant socket listening privileges.

·         java.security Master security properties file that stores information about your registered Cryptography Package Providers, system-wide policy files, IdentityScope use, keystore type, and package access definitions.

·         cacerts System-wide repository for trusted certificates. This file currently ships with a limited number of trusted certificates from certification authority providers, such as VeriSign.

You can find these Java security-related files in directories such as:

·         JDeveloper JDEV_HOME\java1.2\jre\lib\security

·         Oracle8i ORACLE_HOME\javavm\lib\security

·         Oracle run time D:\Program Files\Oracle\jre\x.x.x\lib\security

Depending upon which client tools and applications you need to support, other security files may also exist on your system. Microsoft has its own set of security utilities designed for Internet Explorer. Microsoft uses a slightly different format called a cabinet (CAB) whereas Sun and Netscape use .jar and .zip files to store their Java code. Microsoft also stores its public and private keys in a different way, requiring the use of additional tools to provide security across the contending technologies.

Java class files are vulnerable to decompilation.  It is very easy to produce source code from Java classes or jars.  Most IDEs now have code obfuscators that remove all the things developers do to make source code readable (e.g. descriptive variable naming, indentation, etc.).  Unfortunately, JDeveloper does not yet include a code obfuscator.  If you want your Java code to be proprietary and remain proprietary, you will need to take specific actions to protect it. 

Applet Permissions in Java

Java programs can be deployed as Java applications, applets, servlets, and Java Server Pages (JSPs). It is useful to review the security tools that are used with applets and Java applications to determine whether they should be deployed as Java applications, applets, or JSPs.

Traditional Java applications are designed to run in a standalone mode on a client machine and have few security restrictions or requirements. Applets are designed to run on a client browser after being downloaded from the Internet. Since the Internet is essentially an open environment, applets have significantly higher security requirements. The default security level for applets prevents them from having any potentially damaging interaction with your operating system by limiting their ability to see or modify other assets on your system. For instance, they cannot read or write to the file system, or have access to system memory outside of a well-defined area.

You can change this default security behavior by using the Java security APIs or other third-party toolsets. For example, you can modify the permissions for a specific applet, giving it the ability to interact with the operating system and perform file-handling commands that are generally limited to applications. On the other hand, by packaging an application in a .jar file and specifying the appropriate permissions, you can modify the security requirements for an application until it is constrained just like an applet. Each browser has minor variations in how it handles these modified security requirements.

Note: It is important for novice Java programmers and designers to understand how database connectivity affects applets. Applets can only communicate (via TCP/IP) with the web server from which they are invoked. Therefore, you either need to put the database on the web server (this is not recommended) or delegate all database access to a servlet, JSP, Remote Method Invocation (RMI) Service, or CORBA service that is used by the applet (this is recommended).

Conclusions

Deploying applications over the web poses additional challenges and creates exposures that are not present in a client/server environment. However, with some careful planning and analysis, these risks and exposures can be effectively controlled, allowing developers to build secure applications for internal use and e-commerce applications that can be deployed relatively safely over the World Wide Web. Building security into web applications is a specialized skill requiring knowledge of operating systems, firewalls and Internet security. System architects should not underestimate the need for careful attention to security considerations but neither should they fear that this is an insoluble problem.

About the Author

Dr. Paul Dorsey is the founder and President of Dulcian, Inc. (www.dulcian.com), an Oracle consulting firm specializing in client/server and web custom application development. Paul is co-author with Peter Koletzke of The JDeveloper3 Handbook (2001), Oracle Developer: Advanced Forms & Reports (2000), and The Oracle Designer Handbook (1999), and with Joseph R. Hudicka of Oracle8 Design Using UML Object Modeling (1999), all from Oracle Press. Paul is the Executive Editor of SELECT Magazine. He is the President of the New York Oracle Users’ Group.