This article by Marcelo Parisi examines basic concepts of web application security using Oracle API Gateway, using an XSS Injection issue and an SQL Injection issue to demonstrate how Oracle API Gateway can bring value to these scenarios.
The topic of Web application security never gets old. Some of the main associated challenges are related to detection and prevention of XSS Injection and SQL Injection. Such vulnerabilities are usually exploited through web application url parameters or user input fields in HTML forms.
While Oracle API Gateway has been used mainly to protect Web Services, RESTFul APIs and other kinds of services, its filtering and hardening mechanisms make it a powerful tool in a web application protection scenario.
In this article we’ll examine some basic concepts of web application security using Oracle API Gateway. We’ll work on an XSS Injection issue and on a SQL Injection issue to demonstrate how Oracle API Gateway can bring value to these scenarios.
The applications used here to demonstrate the issues were custom made for this article and are deployed in an Oracle WebLogic Server 12c environment with no clustering. The SQL Injection demonstration application uses a datasource connected to an Oracle Database 11gR2. The application reads data from the database’s simple three-column table and prints in the screen. The XSS Injection application prints only the user form input field value in the screen. These applications have no real-life use and are only some code samples for demonstration purposes.
We’ll not be covering infrastructure installation in this article. We’ll be using two servers, one with Oracle API Gateway installed on it, and the other one with the application running on Oracle WebLogic Server 12c.
Infrastructure
As mentioned before, building the infrastructure is out of this document’s scope. In this section we’ll just see what the infrastructure used to demonstrate the concepts looks like.
The infrastructure is built on top of two virtual machines (VMs), as in Figure 1 below:
Figure 1
The Oracle API Gateway VM runs Oracle Enterprise Linux 5.6, and the Oracle WebLogic Server 12c VM runs Oracle Enterprise Linux 6.4. The network will use fully qualified domain names, so the names and ports will be:
Figure 2
To demonstrate the problems, we’ll acess the application directly on WebLogic Server 12c Managed Server running on vmwls01. After that, we’ll secure the application on Oracle API Gateway, and will access it through the vmoag01 public port.
XSS Injection
The first demonstration we’ll see is XSS Injection. The application used for this demonstration is called XSSTest, and the context-root for it is /XSSTest. When we open it, it presents a form like the one shown in Figure 3:
Figure 3
If we enter our name, we’ll get a result as shown in Figure 4, below:
Figure 4
If we click on the link, we’ll go to the Oracle website:
Figure 5
As we can see, the application is pretty straightforward. Here’s the code snippet that interests us:
Figure 6
As we can see in Figure 6, the submitted form data is not processed at all. The application simply prints information on the screen. To demonstrate that this is dangerous, let’s go back to the application form, and input the following string on the form: Marcelo<script>alert('GOT YOU!')</script>
Figure 7 shows the form that is going to be submitted:
Figure 7
Click submit to get the result shown in Figure 8, below:
Figure 8
A JavaScript alert window—which can be harmless, but is also the first sign that the application may have security problems. Printing an alert window may not be dangerous, but what if we input something like: Marcelo<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="[http://www.google.com/](http://www.google.com/)";}</script>in the form?
As we can see in Figure 9 below, everything seems normal:
Figure 9
Now, pay attention to the status of the window in Figure 9. The link is not directing to the Oracle website anymore. If we try to click on the link that was supposed to take us to the Oracle website, we´ll get to a different website, as in Figure 10, below:
Figure 10
In other words, if this were an input form to a database or a url parameter, we could trick it very easily to steal user or admin data, or point someone to a malicious file, because users would be acessing a trusted site and would trust the links and information presented there.
Oracle API Gateway can help us protect our application from these kinds of injections with the Threatening Content filter. To demonstrate it, we’ll connect to our Oracle API Gateway Node Manager with OAG Policy Studio.
Now we’ll create a Policy Container for our policies, as in Figure 11:
Figure 11
After that, we’ll create a new policy (“XSS Policy”) inside our container:
Figure 12
Now we’ll drag a Threatening Content filter to our policy. Because we are trying to avoid a JavaScript injection, we’ll need to make sure we select the filter’s “JavaScript Insertion Attack” option, as shown in Figure 13 below:
Figure 13
The created filter must be set as a start point for our policy. Now we’ll drag a Set Message filter to our policy. Its configuration should resemble Figure 14, below:
Figure 14
After creating the filter, we need to create a Failure Path going from the Threatening Content filter to the Set Message filter. So far, our policy looks like Figure 15:
Figure 15
Now we’ll drag a Reflect Message filter to our policy, configured like this:
Figure 16
We’ll now create a success path from our Set Message filter to this Reflect Message filter. So far, our policy looks like Figure 17 below:
Figure 17
Now we’ll drag the last filter on our error path: a Set Response Status filter.
Figure 18
And to finish our error path in this policy, we’ll create a success path going from our Reflect Message filter to the Set Response Status filter so that our policy looks like Figure 19:
Figure 19
After that, we’ll start building the success path of our policy. To do it, we’ll start by dragging a Static Router filter to our policy, and we’ll set it up to connect to our Oracle WebLogic Server 12c managed server, as in Figure 20:
Figure 20
Now we’ll drag a Connection filter to our policy and accept its defaults:
Figure 21
After that, we’ll need to create a Success Path going from Threatening Content to Static Router and another Success Path going from Static Router to Connection. Our policy will resemble Figure 22 below:
Figure 22
The last step before deploying the configuration is creating the path. In order to do it, we’ll go to Paths on the Oracle API Gateway tree, inside Default Services, and click Add, as in Figure 23, below:
Figure 23
The path that we’re going to create is a Relative Path, and its configuration should resemble Figure 24, below:
Figure 24
Note that in Path Specific Policy we need to select the policy we’ve just created. After that, we just need to deploy the configuration.
Now, using Oracle API Gateway url, let’s try again, as shown in Figure 25, below:
Figure 25
And after hitting submit, the result we get is just like the one in Figure 26:
Figure 26
Now using the script that changes the link, as in Figure 27 below:
Figure 27
And again, as we can see in Figure 28 below, the attack was blocked:
Figure 28
Now, if we try a normal input, as in Figure 29, below…
Figure 29
It’ll succeed!
Figure 30
SQL Injection
The next demonstration we’ll see is SQL Injection. In this section, we’ll see how information can be leaked from the database when the application is not correctly coded. The application used for this demonstration is called a SQLTest, and the context-root for it is /SQLTest. This application has a form used to input the username and it will return the full name and SSN of that user. This information comes from a table in the database, just like in Figure 31, below:
Figure 31
When we open the application, we see this form:
Figure 32
If we enter user1in the form, we’ll get the information just like Figure 33 below:
Figure 33
As we can see, the application returns all the three fields from the table. The code snippet that interests us in this case, is the one in Figure 34 below:
Figure 34
The problem here is that the username variable is not being processed at all. So if we input user1' or '1'='1 in the form, we’ll get a result similar to Figure 35, below:
Figure 35
As seen in Figure 35, we have the first sign of information leakage because of bad coding on our application. But it doesn’t stop here. We know that we are getting three fields as result of the query, so we can, for example, play with some unions like user1' union select owner,table_name,tablespace_name from all_tables where table_name like '%; as we can see in Figure 36, we can get a lot of table information from the database:
Figure 36
Another example, is getting database software, operating system version information and patchset using user1' union select banner,'','' from v$version where banner like '%. Again, we get all database information as in Figure 37:
Figure 37
Now we know that the database is running in a Linux environment, on a 64bit platform, and it is an Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 in Production mode. This is some serious information leakage and should not happen. Depending on the user privileges that the datasource uses to connect to the database, a malicious user could see even more information, like session information, database users, etc.
To prevent this kind of leakage, we’re going to create a policy just like the one we created for XSS Injection. This policy, called SQL Policy, will be put inside the policy container (WEB-APP Policies) that we created in the last example. We’ll create it just like the one we’ve created for XSS Test.
Figure 38
Our Threatening Content filter should have the options highlighted in Figure 39, below:
Figure 39
After that, we need to create the Path for our SQLTest application, just like we did for the XSSTest application. First we need to click Add, then select Relative Path:
Figure 40
The new path configuration should resemble Figure 41, below:
Figure 41
Next, we need to deploy and test our configuration.
The first test we’ll execute is using user1’ or ‘1’=’1as a input string. As we can see in Figure 42, below, the policy is working and has prevented information leakage.
Figure 42
However, if we try user1' union select banner,'','' from v$version where banner like '% the policy won’t work, as Figure 43 below resembles:
Figure 43
This is happening because the default expressions for SQL Attacks on our Threatening Content filter matches only specific cases of ORs, INSERTs, UPDATEs, DELETEs and DROPs. Our case here is a little bit different, and we’ll need to customize the filter a little bit, by adding another expression to it. To do so, we’ll click Add, as in Figure 44, below:
Figure 44
Now we’ll add an expression that matches a ‘ + any number of blank spaces + the word “union” + any number of blank spaces + the word “select”. This way, we’ll be able to match expressions like ' union select or 'union select, for example. The expression should look like Figure 45 below:
Figure 45
We now need to make sure we select the expression we’ve just created, as in Figure 46:
Figure 46
Now, after we deploy and retry with the same expression again, the result should be like Figure 47, below:
Figure 47
Our new expression is now matching the input we’re using on the form. If we try with a normal input, it should work fine, as Figure 48 shows:
**
**
Figure 48
Conclusion
Injection issues in Web Applications are among the most exploited security issues. In this article we saw how Oracle API Gateway can bring value to these kind of scenarios by using the Threating Content filter. Oracle API Gateway can also bring value to file upload scenarios by using Antivirus filters, as explained, for example, in another article entitled: Virus-Proofing Oracle WebCenter Content 11g with Oracle API Gateway 11g.
It is important that Threatening Content expressions be created with a lot of care. An incorrect expression can break a web application’s functionality, so it is important to test with multiple scenarios to make sure no functionality has been broken in the application.
The policies created in this article are specific policies for the examples that we’ve seen here, and are not for general use.
Note: This document is not an Oracle official documentation and is not intended to replace any of product’s official documentation. This document is intended to be a simple guideline on Web Application security practices. Offical product documentation should always be reviewed.
About the Author
Marcelo Parisi is an Oracle IT Architecture Certified Specialist working as a Senior Consultant for Oracle Consulting Services in Brazil, where he is a member of the Tech Infrastructure team, with a focus on Oracle Fusion Middleware. His work includes includes architecture design, and implementation and performance tuning of FMW infrastructure. Marcelo's fields of expertise include Oracle Reference Architecture, Oracle WebLogic Server, Oracle SOA Suite and Oracle WebCenter.
Twitter: @feitnomore
LinkedIn: https://www.linkedin.com/in/marceloparisi
Facebook: Marcelo F. Parisi