Chapter 1: Access Control

The Problem

The Solution




Chapter 2: Cross-Site Scripting

The Problem

The Solution


Understanding Context


Direct Output


Chapter 3: SQL Injection

The Problem

The Solution


Dynamic SQL – Execute Immediate

Dynamic SQL – Cursors

Dynamic SQL – APEX API

Function Returning SQL Query

Substitution Variables


Chapter 4: Item Protection

The Problem

The Solution


Value Protected

Page Access Protection

Session State Protection



Appendix A: Using Apexsec to Locate Security Risks

Appendix B: Updating Item Protection

Appendix C: Untrusted Data Processing



Carol Long


Adaobi Obi Tulton


Greg Jarmiolowski


Kathleen Wisor


Kim Cofer


Mary Beth Wakefield


Rosemarie Graham


David Mayhew


Ashley Zurcher


Richard Swadley


Neil Edde


Jim Minatel


James Saturino


Ryan Sneed

Recx would like to dedicate this book to Samantha Booker, for her ever-hilarious insight and fiery temper.


RECX LTD. is small, agile, British company, formed in 2009 by cyber security experts who have worked in the fields of system and network attacks, exploitation, and applied security research since the turn of the century.

Offering a blend of skills based on the real-world experience of compromising and defending networks, Recx provides valuable capability, insight, intelligence, and creativity to the security challenges faced by system designers.

In addition to hands-on experience of building and breaking systems, Recx also has a strong pedigree in applied security research. This stems from individuals who have worked for a range of UK companies performing research into both offensive and defensive techniques.

Recx has created a range of cutting-edge tools and techniques that assist in the exploitation and defense of computer systems and networks.

TIM AUSTWICK has worked in both research and consulting roles for government departments and commercial organizations within the UK. By monitoring the developments of the growing computer security community, he helped enhance capability through development of attack tools and techniques within the security arena.

After graduating from Edinburgh University in 2000 with a joint honors degree in Artificial Intelligence and Computer Science, Tim went on to conduct advanced security research within a highly specialized cyber security testing team.

Tim has devised and presented a number of training sessions throughout his career on a variety of cyber security topics. His interests focus on the diverse range of security risks that has emerged through the rapid rise and constant evolution of Internet technologies.

While engaged as a security consultant by a client, Tim was exposed to the Oracle APEX platform and started devising an attack and audit methodology. Working alongside a great team of APEX developers helped Tim rapidly learn about the structure of APEX applications and the common security vulnerabilities that could be introduced.

Working at Recx, Tim’s time is split between vulnerability research and client-facing consultancy. Tim has presented security risks and mitigation strategies across a range of technologies at a number of conferences within the UK.

NATHAN CATLOW, after starting out developing commercial-grade applications more than 20 years ago, has worked exclusively within the computer security arena for the past decade in various technical roles with government and commercial organizations.

Nathan has performed incident response, computer forensics, and countless penetration tests for a wide range of top UK and U.S. businesses. This has given him a deep understanding not only of the technical challenges faced by organizations, but also the impact that cyber attacks can have on business operations.

In recent years, Nathan has been concentrating on security within Oracle APEX, researching the structure and operation of the platform to discover security vulnerabilities and common vulnerable code patterns. This knowledge has been imparted into the Recx ApexSec product that performs automated security vulnerability assessments of any application written in APEX.

Throughout his career, Nathan has presented at a number of conferences and recently demonstrated the effect of simple attacks against APEX applications at the UK Oracle User Group conference.


GREG JARMIOLOWSKI has been developing Oracle database applications since 2000. He used to build ASP and ColdFusion applications with Oracle databases until he discovered HTML DB. After successfully sneaking Application Express into several federal agencies as a contractor, he struck out on his own in 2007. He focuses on Application Express development projects, but loves a good SQL challenge.


THANKS to the team of contractors who opened our eyes to Oracle’s Application Express, and thanks to the Oracle APEX development team for being on-board with our research and our product.


AT RECX we’ve been involved in the world of IT Security for more than a decade. We were involved in some of the first penetration tests performed in the UK, where large organizations and government departments allowed ethical hackers into their networks to determine the risk they faced from what are now known as cyber attacks.

As web applications rose in popularity around the turn of the century, we worked to develop tools and tactics to assist in attacking sites for customers. As more content was placed within web-based systems, this area of research grew almost in tandem with the number of real-world attacks that were happening against Internet-facing websites.

In recent years, we became exposed to Oracle Application Express (APEX) and realized that there was no single resource for developers on securing their APEX applications. We were able to break into APEX applications in a myriad of ways after learning about the unique structure of the APEX environment. But we had to learn from scratch why the security flaws existed and how to explain to developers the steps required to resolve the risks. We’ve collated this experience and advice into this book to help any APEX developer create secure APEX applications.

Oracle APEX use is booming, and we’re seeing more Oracle customers choosing APEX for presentation of their business data from the database. Some customers have hundreds of APEX applications, ranging in complexity from simple data presentation and reporting through to complex business process management and geospatial analysis. Many have serious security requirements and need to ensure that their data is protected both from unknown parties operating on their networks, and also their “trusted” users acting with malicious intent.

APEX is a great tool for rapidly getting raw data out of the database and into a familiar browser environment for users. Whereas there is a gain in terms of functionality in this Rapid Application Development (RAD) model, what we often see is a detrimental effect on security. That’s where Recx comes in — we hope this book is useful for all levels of APEX developers to understand the common risks faced by web applications, how they occur within APEX, and the simple steps required to ensure applications are robust against attack.


The book is structured into four main sections:

We believe in the learn-by-example approach to teaching security, and have structured this book so you can follow the discussions in a practical manner by creating pages within an APEX application that have specific security flaws. We demonstrate how attackers exploit the vulnerabilities so you are familiar with the mechanisms used against systems. By showing how to fix the issues, we can demonstrate they are no longer exploitable, and hopefully help clarify the real root cause of the problem and the simplicity of protecting against the threats.

If you prefer, you can read this book without actually trying the examples, and use them as illustrations of the threats against APEX applications.

All of the examples in this book are actually from real-world customer applications, sanitized and simplified to communicate the core issue in an understandable form. Some will look so simple that they may appear to have been specifically manufactured — trust us, they existed in some form within real applications, and are less obviously vulnerable when embedded within a hundred-page, highly complex APEX application!

The examples, when followed, result in a world’s-most-vulnerable APEX application that you can keep in your tool bag and use to experiment on with the real issues you face in your own code. The complete example application is also provided for download for you to directly import into your test environment and start hacking.


This book takes a hands-on approach, demonstrating security risks to APEX applications by building vulnerable pages, exploiting them, and then changing things so they are secure. As such, to get the most out of this book you should be familiar with building APEX applications; pretty much any APEX developer should be able to follow the examples.

Two other areas are worth getting up to speed with: the APEX URL format and the JavaScript console.


The URLs within APEX applications have a unique structure, and differ from normal web applications:

Most direct requests go via the f procedure with a single parameter, p. This parameter is a colon-separated list that breaks down as follows:

Application ID
Page ID
Session ID
A request string
The debug flag (YES or NO)
A list of pages for which the cache will be cleared
A comma-separated list of item names
A comma-separated list of item values
The printer-friendly output flag (YES or blank)

When using (and attacking) APEX applications, the main parts that we get involved with are the list of item names and values.

Most web application technologies pass parameters on the URL in the following form:

You see two parameters here, name and show. The equivalent within APEX would be,P1_SHOW:recx,all

Usually, parameters can be URL-encoded to allow any character to be contained in a value (for example, name=recx%26friends would embed an ampersand). This works in APEX with two exceptions: the comma, and the colon characters can’t be encoded in a value. To set an item value so that it contains a comma, surround the list of item values with backslash characters:,P1_SHOW:\recx,and,friends\,all

This sets the P1_NAME value to recx,and,friends. When attacking APEX applications, this is useful because commas can arise in some exploits, such as SQL Injection and Cross-Site Scripting.

The colon character can also be passed in an item value, but not via the f procedure. To set an item value to contain a colon, you have to call directly:

The p_flow_id is the application ID, the p_flow_step_id parameter is the page ID, and p_instance represents the session. You can then pass p_arg_name and p_arg_value pairs to specify item name/values, using standard URL encoding to set any character. This is unsupported, and the wwv_flow package and show procedure may at some point change, so APEX applications shouldn’t make use of this feature for normal operations. But, if attacking an APEX application, you can use this to get a colon into a value and into your exploit string.

JavaScript Console

All major browsers now have a very handy JavaScript console. In this book we use Chrome, but Firefox and Internet Explorer have the same feature and the same JavaScript commands will work.

As security researchers investigating an APEX application’s exploitability, we use the JavaScript console for a number of tasks:

To make an Ajax call, you use the htmldb_Get function within the JavaScript console:

var ajax = new htmldb_Get(null,
            1); // Page number

You can use this same code to set an item value, by specifying an empty process name:

var ajax = new htmldb_Get(null,
            1); // Page number

You will see how this particular Ajax call can be very useful mechanism for modifying items that are protected by checksums in Chapter 4, “Item Protection.”

To modify a hidden item on a page so it is editable, you can use the following JavaScript, which uses jQuery to duplicate a form element:


A text field, with the same ID, name, and value as the hidden field, is placed after the submit button. The contents can then be changed in the browser and submitted to the APEX application.


This book presents a number of security risks faced by web applications and investigates specifically how these emerge within the APEX environment. From our consulting experience we know these vulnerabilities are common in APEX applications, but they are not unique to the APEX world. Similar issues exist in any web application framework.

To further your understanding of generic attacks against web applications, we highly recommend the Web Application Hackers Handbook (Stuttard and Pinto, 2007).

It is also worth considering the security applied at the database layer, and we would also point out the Database Hackers Handbook (Litchfield et al., 2005) as an invaluable resource when testing a security your environment.

Chapter 1

Access Control

One of the most basic forms of protection that any web application must utilize is the enforcement of an authentication and authorization policy.

Authentication deals with identifying users to the application; in APEX this is provided by a number of default authentication schemes and can be extended using a custom authentication scheme. Authorization is the process of assessing whether the authenticated user is privileged to access certain data or perform a particular action.

The term access control