Yes, Oracle API Gateway Can Protect Your Web Application, Too

Version 5

    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:

    image001.png

    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:

    image002.png

    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:

    image003.jpg

    Figure 3

     

    If we enter our name, we’ll get a result as shown in Figure 4, below:

    image004.jpg

    Figure 4

     

    If we click on the link, we’ll go to the Oracle website:

    image005.jpg

    Figure 5

     

    As we can see, the application is pretty straightforward. Here’s the code snippet that interests us:

    image006.jpg

    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:

    image007.jpg

    Figure 7

     

    Click submit to get the result shown in Figure 8, below:

    image008.jpg

    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/";}</script>in the form?

     

    As we can see in Figure 9 below, everything seems normal:

    image009.jpg

    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:

    image010.jpg

    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:

    image012.jpg

    Figure 11

     

    After that, we’ll create a new policy (“XSS Policy”) inside our container:

    image012.jpg

    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:

    image013.jpg

    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:

    image014.jpg

    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:

    image015.png

    Figure 15

     

    Now we’ll drag a Reflect Message filter to our policy, configured like this:

    image016.jpg

    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:

    image017.png

    Figure 17

     

    Now we’ll drag the last filter on our error path: a Set Response Status filter.

    image018.jpg

    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:

    image019.png

    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:

    image020.jpg

    Figure 20

     

    Now we’ll drag a Connection filter to our policy and accept its defaults:

    image021.jpg

    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:

    image022.png

    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:

    image023.jpg

    Figure 23

     

    The path that we’re going to create is a Relative Path, and its configuration should resemble Figure 24, below:

    image024.jpg

    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:

    image025.jpg

    Figure 25

     

    And after hitting submit, the result we get is just like the one in Figure 26:

    image026.jpg

    Figure 26

     

    Now using the script that changes the link, as in Figure 27 below:

    image027.jpg

    Figure 27

     

    And again, as we can see in Figure 28 below, the attack was blocked:

    image028.jpg

    Figure 28

     

    Now, if we try a normal input, as in Figure 29, below…

    image029.jpg

    Figure 29

     

    It’ll succeed!

    image030.jpg

    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:

    image031.jpg

    Figure 31

     

    When we open the application, we see this form:

    image032.jpg

    Figure 32

     

    If we enter user1in the form, we’ll get the information just like Figure 33 below:

    image033.jpg

    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:

    image034.jpg

    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:

    image035.jpg

    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:

    image036.jpg

    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:

    image037.jpg

    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.

    image022.png

    Figure 38

     

    Our Threatening Content filter should have the options highlighted in Figure 39, below:

    image038.jpg

    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:

    image039.jpg

    Figure 40

     

    The new path configuration should resemble Figure 41, below:

    image040.jpg

    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.

    image041.jpg

    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:

    image042.jpg

    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:

    image043.jpg

    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:

    image044.png

    Figure 45

     

    We now need to make sure we select the expression we’ve just created, as in Figure 46:

    image045.jpg

    Figure 46

     

    Now, after we deploy and retry with the same expression again, the result should be like Figure 47, below:

    image046.jpg

    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:

     

    image047.jpg

    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