How to Restrict HTTP Method on Oracle HTTP Server (OHS) 12c R2 (Doc ID
2850003.1)
In this Document
APPLIES TO:
Oracle HTTP Server - Version 12.2.1.0.0 and later
Information in this document applies to any platform.
GOAL
How to restrict HTTP Method such as PUT, OPTION, DELETE and etc. to
OHS requests.
For example, Only GET and POST access want to be allowed.
SOLUTION
Require Directive can restrict HTTP method using "method" attribute as
follows.
Require method GET POST
This directive is for Apache 2.4.x (OHS 12.2.1.x).
Require Directive
https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#require
Require method http-method [http-method] ...
Access is allowed only for the given HTTP methods.
It can be set in <Directory>, <Location> and etc. as follows.
Example1:
The following example will only allow GET and POST requests for
DocumentRoot:
httpd.conf
DocumentRoot "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/
instances/${COMPONENT_NAME}/htdocs"
<Directory "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/
instances/${COMPONENT_NAME}/htdocs">
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.4/mod/core.html#options
# for more information.
#
Options Indexes FollowSymLinks
#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# AllowOverride FileInfo AuthConfig Limit
#
AllowOverride None
#
# Controls who can get stuff from this server.
#
# Require all granted
Require method GET POST
</Directory>
Example2:
The following example will only allow GET and POST requests for the
weblogic request path "/weblogic/*":
mod_wl_ohs.conf
<Location /weblogic>
SetHandler weblogic-handler
WebLogicHost <WLS_HOST>
WebLogicPort <WLS_PORT>
Require method GET POST
</Location>
OHS returns HTTP 403 Forbidden response for PUT request because
/weblogic access is restricted via GET and POST in above
mod_wl_ohs.conf.
$ curl http://<OHS_HOST>:<OHS_PORT>/weblogic/test.jsp -X PUT
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /weblogic/test.jsp
on this server.<br />
</p>
</body></html>
How to Disable HTTP TRACE or Other REQUEST_METHOD in Oracle To
HTTP Server (Doc ID 259404.1) Bottom
In this Document
Goal
How to Disable HTTP TRACE or Other REQUEST_METHOD
Solution
Disable TRACE Method
Rewrite TRACE and Other Methods to a Forbidden Page
Verify RewriteRule Works
Using Telnet to Verify the Configuration for a Non-SSL Listen Port
Using Curl to Verify the Configuration for a SSL Listen Port
References
APPLIES TO:
Oracle HTTP Server - Version 10.1.2.0.0 to 10.1.3.5.0 [Release AS10gR2 to AS10gR3]
Oracle HTTP Server - Version 11.1.1.2.0 to 11.1.1.9.0 [Release Oracle11g]
Oracle HTTP Server - Version 12.1.3.0.0 and later
Oracle Fusion Middleware - Version 10.1.2.0.0 and later
Information in this document applies to any platform.
GOAL
How to Disable HTTP TRACE or Other REQUEST_METHOD
This article describes a way to disable this HTTP TRACE method within the Oracle HTTP
Server (OHS) using a rewrite to a Forbidden page, which has been a popular configuration.
The same concept will apply to other methods, in case you decide to further limit request
methods to the server:
GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS, MOVE, INDEX, MKDIR,
RMDIR
Note: GET and POST are the most popular in any web page, and you likely do not want to disable
these.
Note:
TRACE was used for this article for the rewrite option because it has been a popular request. It is also
a recommendation in the 10.1.3.4 and 10.1.3.5 Patch Set readme files to restrict TRACE as a security
precaution. (It is still recommended on all versions, it was just that readme that announced that
recommendation). Note that some other methods may be used by Oracle components (and your
applications) in ways not explicitly expressed, and are valid HTTP request methods in use within the
Internet technologies. However, in some cases, an Administrator may wish to disable one or more by
using the rewrite method.
If there is a reason to "restrict" a method because of a security issue, please provide Oracle Support
with a testcase that reproduces and shows the security exploit. If its a third party recommendation,
please have the third party contact Oracle Security directly:
Reporting Security Vulnerabilities
https://www.oracle.com/technology/deploy/security/alerts.htm#ReportingVulnerabilities
To protect against all known, fixed and applicable vulnerabilities, Oracle recommends to applying the
latest Patch Set and then monitor for Critical Patch Updates on your new version:
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
SOLUTION
Disable TRACE Method
For Apache version 1.3.34 (or later), or Apache 2.0.55 (or later), there is a new directive if
the only REQUEST_METHOD you wish to restrict is TRACE. For Oracle HTTP Server, this
means versions 10.1.3.1 (or later) or 11.1.1.2 (or later). For these newer versions, configure
the httpd.conf file with the TraceEnable directive:
TraceEnable Off
Updated reference for OHS 12c based on Apache
2.4: https://httpd.apache.org/docs/2.4/mod/core.html#traceenable
Rewrite TRACE and Other Methods to a Forbidden Page
To include other methods in the restriction, the remainder of this article describes a way to
disable this HTTP TRACE method within the Oracle HTTP Server (OHS) using a rewrite to
a forbidden page, (which has been a popular configuration). The same concept will apply to
other methods, in case you decide to further limit request methods to the server:
GET, POST, HEAD, PUT, DELETE, TRACE, TRACK, OPTIONS, MOVE, INDEX,
MKDIR, RMDIR
Note: GET and POST are the most popular in any web page, and you likely do not want to disable
these.
The basic configuration for this is to add the following RewriteCond to the httpd.conf (or
other valid .conf file) file, normally placed at the end of the httpd.conf file:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
</IfModule>
Alternatively, this will reject any request which is using a method not specified in the
directive:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST|HEAD)
RewriteRule .* - [F]
</IfModule>
Notes:
If the installation is an Application Server within a Grid Control/OMS home, the file
$OH/sysman/config/http_em.conf will need the above entries in order to take effect.
There is a known issue with this configuration if applying a Patch Set in the future:
Note 560368.1 "Forbidden" Error After Configuration or Applying 10g Patch Set
RewriteRules from the main server configuration do not apply to VirtualHosts. If this is
specific to a VirtualHost, these rewrites should be with a VirtualHost container. If these rules
are specified in the main configuration, the following two lines are needed within the
VirtualHost container, including the ssl.conf:
RewriteEngine on
RewriteOptions inherit
More information about the scoping of mod_rewrite is available on it's documentation page:
AS 10g:
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
FMW 11g:
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html
FMW 12c:
https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html
Verify RewriteRule Works
Unless you have an application that sends a TRACE, this may be hard to test unless you have
a specific TRACE request (which is usually programmable from a script).
The easiest way to verify the rewrite directive is active is to temporarily change the ^TRACE
to ^GET, and make a request to your homepage, the request should fail, as a GET is a normal
request. (A form submit would be a POST method).
(You are actually just testing to see if the RewriteRule is generally active within the
configuration you placed it).
You can easily conclude that if a TRACE was sent the same reaction would occur if
configuring for TRACE.
Using Telnet to Verify the Configuration for a Non-SSL Listen Port
The telnet command provided with most operating systems can be used to verify that the
configuration changes to disable TRACE have been made. Note that telnet can only be used
to test non-SSL ports, since it does not have the capability to perform the SSL handshake or
to encrypt the data.
$ telnet 127.0.0.1 8080
Trying...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0
HTTP/1.1 403 Forbidden
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>403 Forbidden</TITLE>
</HEAD><BODY>
<H1>Forbidden</H1>
You don't have permission to access /
on this server.<P>
</BODY></HTML>
Connection closed.
The information sent by the client is no longer echoed, and the request fails with HTTP status
code 403 or 405. If the response to the TRACE request continues to result in a response with
status code 200, verify that the required directives were added to all <VirtualHost >
containers and the main scope of the configuration file, and also verify that the web server
has been restarted to activate the updated configuration.
Using Curl to Verify the Configuration for a SSL Listen Port
Below is a method to check for ssl and non-ssl ports:
1. Download curl package if it is not already installed. This is not an Oracle utility, but
available on the Internet, depending on your environment.
2. Run the following command from command prompt
curl -v -A cUrl -k -X TRACE https://hostname:ssl_port/
If TRACE is disabled, you will get "403 Forbidden Error"
REFERENCES
NOTE:560368.1 - "Forbidden" Error After Configuration or Applying 10g Patch Set
NOTE:1074055.1 - Security Vulnerability FAQ for Oracle Fusion Middleware Products
