No two applications are exactly alike. Thus, the security required to protect one application is likely different—either vastly or slightly—from that required for any other application. Determining to secure your application starts with a proper assessment of the risk posed and corresponding threats. The upcoming section on “Assessment” goes into detail on how to initiate your thinking about security.
As part of this assessment, it may help to classify threats into one of two categories: preventable and unpreventable. The difference between and details of these threats are detailed in the section “Types of Threats.”
Assessment
How much security is enough? There is only one correct answer to this question: it depends. Unfortunately, that answer doesn’t really answer the question.
Choosing how much security to apply to an application largely depends on a number of factors, including
- what you’re protecting,
- whom you are protecting it from,
- the likelihood that someone wants to steal your data or compromise your system, and
- the repercussions you would face in the case of a breach.
A helpful, easy-to-understand analogy to application security is home security. Most concepts in home security can easily be translated to application security, especially during the analysis and mitigation phase.
Home Security Assessment
Consider the example of choosing how to provide adequate security for your home. The answer to the first question is simple—you’re protecting your home, condominium, or apartment, a physical piece of property or real estate with defined boundaries.
Next question: whom are you protecting your home from? That’s where “it depends” comes into play. Before you can answer this question, you must ask yourself a number of others: How safe is the neighborhood? Is there a history of people breaking into homes in the area? If you’re in an apartment, do you have a doorman or other security personnel? If so, do you trust them? The answers to these additional questions will help guide you in answering the initial one.
The third question—what is the likelihood that someone will break into your home?—also needs to be thought through and relevant facts and opinions applied in order to arrive at an answer. If you live in a part of town that has a history of break-ins, obviously the likelihood will be greater. If your property is in a rural gated community in a part of town with less crime, then the likelihood will not be as great. When answering this question, it is important to also consider “crimes of opportunity.” Even in the best neighborhoods, an iPod or GPS unit sitting in an unlocked car presents an opportunity to otherwise honest people to make the wrong decision.
Lastly—and in many ways, most importantly—the repercussions of an actual breach need to be considered. If you don’t have anything expensive in your home, you might not be too bothered by the thought of someone breaking in, as there’s little for them to take. If you do have nice things, as well as good homeowners insurance, most stolen items can easily be replaced. However, the loss of family heirlooms and specific items that hold sentimental value could result in great emotional stress. There is also the concern that burglaries these days sometimes take a turn for the worse and end up with the burglar inflicting harm on the residents.
Once all of these questions are answered, it is a lot easier to answer the underlying “how much security is enough?” question. In some cases, simply locking the door when you’re not at home will suffice. In others, perhaps locking the door as well as purchasing and activating a home security system would be the best approach. In extreme cases, the best course might be to move into another house in a better neighborhood.
Whatever decision is made, it was greatly influenced by both the answers to the original four questions and the answers to the questions that arose from them. Different people who live in different parts of the world or on different streets within the same community will come to different conclusions.
One of the most easily recognized homes in the United States is located at 1600 Pennsylvania Avenue NW in Washington, DC. The White House is essentially a home with a larger-than-average home office attached to it. While it is perhaps one of the larger homes in its neighborhood, it nonetheless has a physical boundary and surrounding grounds, as evidenced by the tall perimeter fence.
Despite its location in a good neighborhood, the White House has been the scene of several break-in attempts. In fact, only authorized personnel are allowed inside, making the answer to the second question simple: everyone else. Given that there have been many attempts to break into the White House—either in a spectacular fashion via a small airplane or by simply trying to scale the fence and make a run for it—the likelihood that someone will try to break in again is extremely high. The repercussions of such a breach are extremely serious in all cases.
Given that the stakes are a lot higher at the White House, extreme precautions and countermeasures are employed there. The entire property is under constant video surveillance, a highly trained armed security force is present at all times, and many physical barriers are in place to prevent access to the grounds. And these are only the precautions we know about.
Even though, at its core, the White House is not essentially different from anyone else’s home, the level of perceived and actual threats to it is obviously much higher than for most homes. Thus, the additional layers of security are more extreme and thorough.
Application Security Assessment
Application security should be assessed and applied in much the same way as in home security. And, also like home security, one size does not necessarily fit all. Given unlimited resources, time, and money, all applications could have all sorts of security layers built into them, making each one as fortified as the next. Unfortunately, unlimited resources have never been nor ever will be available to any organization. Thus, we have to assess and determine what security needs to be applied on an application-by-application basis.
To start, let’s consider the same four criteria that were used in assessing the need for home security. What are you protecting? To elaborate on this, what does the application you’re protecting do? Is it a simple project management system where tasks are entered and reported on, or does it contain sensitive information, such as Social Security numbers or account numbers? Are there legislative regulations in place that dictate specific precautions to be taken? Is the application based on data that is freely available to anyone in your organization? As in the case of home security, the answers to these questions, as well as to the questions these questions lead to, will determine how much or how little security you should put in place.
The next question—whom are you protecting the application from?—is almost always answered incorrectly. Most organizations hold the view that if the application is within a firewall there is no way anyone from the outside can gain access to the system. While we all know that this has proven to be false in the past, let’s ignore that for a moment.
Much less spectacular, yet much more likely, culprits are your authorized users. These users have already gotten past the first hurdle—having a valid username and password—because one has already been given to them. Many applications allow any user to see any record by design. Thus, an authorized user who wanted to steal data would have little difficulty in doing so. In fact, most APEX reports contain a link that allows the user to easily export all of the data to a CSV file, which can easily be carried out of the office on a USB drive or sent as an e-mail attachment.
Consider, for example, how WikiLeaks works. It is not political to point out that WikiLeaks does not actively hack into systems and try to steal data. Rather, they are merely a purveyor of data. Authorized users can anonymously upload sensitive data to the WikiLeaks site, where it is verified and, if deemed legitimate, released to the public en masse. At some point, an authorized user had to have access to all of this data, typically by way of some sort of export function.
Therefore, it is important to consider trusted, authorized users as part of the set of people you want to protect your data from, as not only are they the ones most likely to steal it; they also are the ones who have the least difficulty doing so.
Next, consider the likelihood that someone wants to break into your system and steal data. Depending on what the system does, the likelihood will either increase or decrease accordingly. Obviously systems with more sensitive data or more escalated privileges will be more likely targets. Certain organizations are a target for hackers simply based on their name or business alone. To a hacker, government intelligence agencies and large corporations are much more attractive targets than smaller organizations or government agencies that don’t have a focus on national security.
You don’t have to be the CIA or Microsoft to take this question seriously, as your data is critical to your business and so requires adequate protection. When evaluating the likelihood that someone wants access to your systems, be sure not to compare your concern directly to that of other organizations. Likelihood does not translate well from one organization to another because it’s a relative concept that needs to be evaluated at the level at which it is applied. Regardless of your organization’s size and fame, your data is as important to you as the CIA’s data is important to them, and any precautions you take should be based on that.
Lastly, consider the repercussions of an actual breach or break-in to one of your systems. If a project management system was compromised, the repercussions would likely be limited, as the data contained therein may be of little interest or value. But if your application has sensitive financial or classified data, the repercussions could include financial loss, physical harm, even death.
Your applications likely fall somewhere in the middle of these two scenarios. For example: If a salesperson leaves to work for a competitor and takes all of his or her contract data, customers may soon start to do business with that competitor. Or if a student is able to break into the grading system at a college, everyone’s grades may be made available to the public, thus embarrassing the college and perhaps causing a reduction in enrollment or legal action.
Data and Privileges
In addition to the four factors mentioned earlier, two other key factors need to be considered when assessing the security required for your applications: data and privileges.
The data on which your application is based is a good place to start, as its level of sensitivity tends to dictate how much security is required. If your data is not very sensitive, then implementing data access controls may not be required, as any user can already see any record. But if the data is more sensitive, data access should immediately be brought to the forefront and a solid plan needs to be designed and implemented.
APEX itself does not provide much in the way of tools for securing data. Fortunately, the Oracle Database does. Depending on your needs, you can use something as simple as a secure read-only view to secure your data so that only authorized users can view it. Oracle also provides more robust tools—such as Virtual Private Database—that can assist in providing secure access to your data. Data security is discussed in greater detail in Chapters 11 and 12.
Smaller applications that don’t do much—say read-only reporting system or a simple data entry application—may require less attention than an application used to manage user roles or access to other systems, but this is not an excuse to ignore role-based security. APEX applications have a tendency to start very small and then quickly grow to something much larger—either in the sheer size of the application or the number of users. Initially, little access control is needed for many of these applications, but as they grow, access control becomes more and more critical and increasingly difficult to implement. Thus, no matter what the size or scope of an application, attention needs to be paid to basic user management and access control.
APEX does provide a basic user-to-role management utility called Access Control. Developers can easily add this capability to their applications via a wizard, instantly creating a view, edit, and administrator role. While this feature works for basic access control issues, it is somewhat limited in various ways. Chapter 9 addresses additional ways of managing access control in an APEX application.
Types of Threats
As noted before, threats can be grouped into two categories: preventable and unpreventable. The first group, as the name implies, can be prevented as long as secure best practices are adhered to, such as cross-site scripting, URL tampering, and SQL injection. The second group is an unfortunate necessity of doing business. At some point, users will need access to sensitive parts of the system. This requirement cannot be prevented and in fact is required for the system to function. Therefore, the only alternative is to provide solid auditing tools so that in the case of a breach, the perpetrator can easily and unequivocally be identified.
Preventable
Many threats in APEX applications can be prevented with just a little extra effort. Unfortunately, they often go unresolved due to the lack of time and not understanding how to locate and remedy them.
Preventable threats can be broken out into three different types:
- URL tampering,
- SQL injection, and
- cross-site scripting.
When building APEX applications, APEX typically selects the most secure options for page and shared components. However, for a number of reasons, those settings can be and often are changed to less secure settings. Assuming that a page was generated by a wizard and therefore is secure is a bad assumption to make.
URL Tampering
The URL of an APEX application is made up of a colon-delimited string of values that are passed to a parameter “p” of a procedure called “f”. This is often referred to as the “f and p” syntax. The string of characters passed in is fixed, and any APEX developer can likely recall the purpose for many, if not all, of the positions. The APEX URL syntax is defined in Listing 1-1 below.
Listing 1-1. The APEX URL Syntax
Application ID:Page ID:Session ID:Request:Debug:Clear Cache:Item Names:Item Values:Printer Friendly
Given that the definition of the APEX URL syntax is standard across all APEX applications, it doesn’t take a lot of skill to learn how to manipulate it. A malicious or simply curious user could easily change the values in the URL bar of a browser and resubmit the page. Listing 1-2 below illustrates a simple APEX URL that references page 1 of application 100:
Listing 1-2. A Simple APEX URL That Refers to Page 1 of Application 100
http://localhost/apex/f?p=100:1:12432087235079
URL tampering poses one of the most dangerous threats, as it takes zero programming skills to launch an attack. By changing portions of the URL, a malicious user might gain access to pages or to records that the user is not supposed to see. Fortunately, both APEX and the Oracle Database employ a number of techniques that can completely neutralize URL tampering attacks. These are addressed in later chapters of this book.
SQL Injection
SQL injection is much more sophisticated than URL tampering, as these attacks require at least a working knowledge of SQL. An SQL injection attack is designed to pass in actual SQL fragments that then get executed rather than inserted into the database as data. SQL Injection attacks can range in severity from minor to major, depending on a number of factors. Consider the SQL in Listing 1-3 below:
Listing 1-3. An SQL Statement with a Potential SQL Injection Risk
SELECT
customer_name,
cust_first_name,
cust_last_name
FROM
demo_customers
WHERE
customer_name = '&P1_SEARCH.'
By using the APEX &ITEM. substitution syntax, the developer has introduced an SQL injection risk, since APEX will replace the string &P1_SEARCH. with its corresponding value before it parses, binds, and executes the query. If the user entered something like ACME, no danger would be present and the query would execute as expected.
However, if the user was more malicious and entered ACME' OR 'x' ='x for the value of P1_SEARCH in an APEX form, the SQL would actually be modified before it was parsed and executed by the database. The actual SQL that would be passed to the database and run is illustrated in Listing 1-4 below.
Listing 1-4. The SQL That Will Be Executed if a Malicious Value Is Passed In
SELECT
customer_name,
cust_first_name,
cust_last_name
FROM
demo_customers
WHERE
customer_name = 'ACME' OR 'x' = 'x'
Notice that the WHERE clause now has an OR condition that will check for one or the other conditions to be true. If the customer_name is, in fact, ACME, then that record will be returned. If it is not ACME, then the second part of the OR will be evaluated, which will always be true. Thus, all records from the demo_customers table will be returned, which clearly was not the intent of the original SQL.
Fortunately, APEX applications typically don’t face a lot of SQL injection risk, largely due to the fact that when referencing APEX items in SQL or PL/SQL regions, most developers use bind variable syntax. When bind variable syntax is used in APEX, the values of items are not passed in until after the query executes, making it impossible for them to influence the SQL itself.
Simply using bind variable syntax everywhere does not make you one hundred percent immune from SQL injection attacks. If bind variable syntax is used in conjunction with dynamic SQL, take care to ensure that the actual SQL is evaluated before the APEX items are. Chapter 7 covers SQL injection in greater detail.
Cross-Site Scripting
Cross-site scripting occurs when a malicious user at a high level passes in a fragment of JavaScript that is later executed by the same or other users in the application. Think of it as a type of SQL injection for JavaScript. Somewhat advanced knowledge of JavaScript is required to execute a successful cross-site scripting attack, so most average end users will simply not be capable of implementing one. But that is not a reason to ignore this type of threat.
Depending on the original version of APEX an application was started with, the number of cross-site scripting vulnerabilities can be quite large. Versions prior to APEX 4.0 did not secure report columns from cross-site scripting attacks by default, resulting in a large number of improperly configured columns. Also, the use of &ITEM. syntax in static APEX components could introduce a potential risk of cross-site scripting.
Cross-site scripting vulnerabilities are far more common than SQL injection in APEX applications and can be just as dangerous. Fortunately, these types of attacks can be mitigated by ensuring that your application settings are properly configured. This also is discussed in more detail in Chapter 7.
Unpreventable
Unfortunately, not all threats are preventable. Some systems, due to the nature of their design, do not employ much security. Take a call center system, for example. Given that calls can be routed to any agent from any customer, that agent will have access to any customer information—orders, personal information, and in some cases, credit card numbers. It would be quite simple for a dishonest agent to capture some of this data and then turn around and exploit, sell, or use it maliciously elsewhere. This type of free-for-all access can become especially troublesome when industry regulations, such as the Health Insurance Portability and Accountability Act (HIPAA), are factored in.
During the 2008 presidential election, Verizon Wireless employees improperly accessed cellular phone records for then-candidate Barack Obama. These employees were not hackers, but authorized users of the system they used to access the records. It was relatively simple to identify the culprits because there was an auditing system in place that recorded who accessed which record. As a result, the employees at fault were either disciplined or terminated.
Consider how difficult it would be to conduct business if there were tighter restrictions on who could access which records in a call center–like environment. If customers were each designated as having their own personal, “trusted” agent, how much more difficult would it be to conduct a simple billing inquiry call? What if your trusted agent was on vacation or not in and you needed access to your information? Companies could never work in such a fashion, and their corresponding systems are designed around this, allowing any agent access to almost any customer’s records with no prior clearance.
When system design requires broad access to many users, it is essential that a comprehensive auditing policy be planned and implemented, as in many cases that will be your last and only line of defense against unauthorized data access. Some of the proactive measures that can be taken to reduce risk of unauthorized data access in an APEX application are discussed later in this book.
Auditing can be implemented at almost any level in an APEX application, ensuring that if unauthorized data is accessed, the administrators of the system will be notified immediately. Some controls—such as export to comma-separated values (CSV file)—can also be disabled, preventing users from downloading all records to a portable format. Lastly, and perhaps most importantly, design of these call center–type systems can incorporate controls that limit which records can be viewed. Requiring more than a single field for a query makes it more difficult for the agent to maliciously search the database.
Summary
So how much security is enough? It still depends. And what “it depends” means will change over time as requirements and conditions change. Using the examples outlined in this chapter, you should be able to create a set of guidelines that help determine which security measures to deploy in which circumstances and to clarify “it depends” on a per-application basis.
Your data is one of your organization’s most critical assets. Don’t get caught in the trap of comparing it to that of other, higher public profile organizations. Rather, look at your data in the context of itself. Use as a guideline what similar organizations do, as you will get a much more accurate picture of the typical security precautions you should be looking at implementing.