Oracle fusion middleware 12c (12.1.2)

Domain Restrictions

In designing your domain configuration, note the following restrictions:

• Each domain requires its own Administration Server for performing management activities. When you use the Administration Console to perform management and monitoring tasks, you can switch back and forth between domains, but in doing so, you are connecting to different Administration Servers.

• All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains.

• All Managed Servers in a domain must run the same version of the Oracle WebLogic Server software. The Administration Server may run either the same version as the Managed Servers in the domain, or a later patch set.

Enterprise Applications

An enterprise application consists of one or more Web application modules, EJB modules, and resource adapters. It might also include a client application.

An enterprise application can be optionally defined by an file, which was the standard Java EE deployment descriptor for enterprise applications.

Java EE Programming Model

An important aspect of the Java EE programming model is the introduction of metadata annotations. Annotations simplify the application development process by allowing a developer to specify within the Java class itself how the application behaves in the container, requests for dependency injection, and so on. Annotations are an alternative to deployment descriptors that were required by older versions of enterprise applications (1.4 and earlier).

With Java EE annotations, the standard and deployment descriptors are optional. The Java EE programming model uses the JDK annotations feature (see ) for Web containers, such as EJBs, servlets, Web applications, and JSPs. See .

If the application includes WebLogic Server-specific extensions, the application is further defined by a file. Enterprise applications that include a client module will also have a deployment descriptor and a WebLogic run-time client application deployment descriptor. See .

Начало пути. Обход авторизации. CVE-2018-8733

В состав Nagios входит NagiosQL — это веб-интерфейс для конфигурирования системы. По дефолту он располагается по адресу . Авторизоваться можно, используя ту же связку логин-пароль, которую мы указывали на этапе начальной настройки.

Веб-интерфейс NagiosQL

В разделе есть подраздел , где можно настроить сам . Среди переменных здесь есть раздел , в котором находятся параметры подключения к базе данных.

Конфигурация параметров подключения к базе данных

Они записываются в конфигурационный файл settings.php. По умолчанию он выглядит примерно так.

/var/www/html/nagiosql/config/settings.php

Разумеется, все перечисленные возможности доступны только для авторизованного админа. Или нет? Заглянем в исходник скрипта, который отвечает за изменения конфига, а именно в его начало.

/var/www/html/nagiosql/admin/settings.php

На 35-й строке подгружается файл prepend_adm.php, который в том числе выполняет ряд проверок авторизации.

/var/www/html/nagiosql/functions/prepend_adm.php

Чего-то не хватает, не правда ли? А именно завершения работы скрипта после редиректа

Благодаря такой неосторожности разработчиков выполнение кода продолжится, даже если пользователь не авторизован, и мы можем вносить изменения в конфигурационный файл

/var/www/html/nagiosql/admin/settings.php

Все, что требуется, — это передать локаль и нужные переменные в соответствующих параметрах POST-запроса. Он будет выглядеть следующим образом:

Обход авторизации и редактирование конфига NagiosQL

Хоть сервер и вернул код 302, но скрипт продолжил свое выполнение и перезаписал конфиг.

Тут уже открывается некий простор для творчества. Можно указать в качестве адреса базы данных свой сервак с Rogue MySQL Server и получить читалку файлов. Также изменение некоторых параметров дает возможность вызвать отказ в обслуживании. Но это не особенно интересно. Гораздо полезнее поменять юзера, под которым происходит соединение с базой данных. Это поможет нам продвинуться к нашей цели — полной компрометации системы. Благо по умолчанию пароль пользователя root устанавливается в не только для входа в систему, но и для авторизации в БД.

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Стенд

Я буду поднимать сервер WebLogic версии 12.2.1.3.0 на системе Windows. Скачиваем инсталлятор с официального сайта Oracle из раздела Downloads. Для корректной установки и работы WebLogic потребуется JDK выше 1.8.0.130.

Если хочешь использовать версию ниже, то можешь отключить эту проверку, добавив ключ .

Установка WebLogic 12.2.1.3.0 в Windows

Теперь нужно создать домен WebLogic. Для этого запускаем конфигуратор из домашней директории сервера:

Создание домена в WebLogic

На первом этапе нужно указать, куда будут сохранены всевозможные конфиги и прочие причиндалы для новоиспеченного домена

Рекомендую оставить по дефолту, для теста это абсолютно неважно

На втором этапе выбираем все возможные шаблоны.

Выбор шаблонов при создании домена

Затем указываем связку логин-пароль для админа, режим работы домена — «разработка» или production. А также можно дополнительно настроить порты и сетевые устройства, на которых будет висеть сервер. Для этого отмечай галкой Administration Server в разделе Advanced Configuration.

Дополнительные настройки при создании домена WebLogic

После этого жмем на кнопку Create, откидываемся на спинку кресла и ждем создания нового домена. Это быстро, так что далеко откинуться не успеешь.

Прогресс создания нового домена в WebLogic

Теперь жмем на Next и попадаем на последнее окно, где можно отметить галочкой пункт Start Admin Server для немедленного запуска того, что мы наконфигурировали. Жмем на Finish. Если галочкой ты не воспользовался, то запустить сервер можно также через командную строку. Для этого заходим в домашнюю директорию WebLogic и выполняем

Разумеется, путь актуален, если ты не менял дефолтные настройки при создании домена.

Готовый стенд WebLogic

Те, кто не любит сложности, могут использовать Docker и готовый образ с VulHub. Готовый стенд поднимается одной командой:

Это версия 12.2.1.3, а если нужна 10.3.6.0, то выполняй

Contents of a Domain

shows a production environment that contains an Administration Server, three stand-alone Managed Servers, and a cluster of three Managed Servers.

Figure 2-2 Content of a Domain

Description of «Figure 2-2 Content of a Domain»

Although the scope and purpose of a domain can vary significantly, most Oracle WebLogic Server domains contain the components described in this section.

Administration Server

The Administration Server operates as the central control entity for the configuration of the entire domain. It maintains the domain’s configuration documents and distributes changes in the configuration documents to Managed Servers. You can also use the Administration Server as a central location from which to monitor all resources in a domain.

To interact with the Administration Server, you can use the Administration Console, WLST, or create your own JMX client. See in Understanding Oracle WebLogic Server for information about modifying the domain’s configuration.

Each Oracle WebLogic Server domain must have one server instance that acts as the Administration Server.

For more information about the Administration Server and its role in the Oracle WebLogic Server JMX management system, see in Understanding Oracle WebLogic Server.

What Happens if the Administration Server Fails?

The failure of an Administration Server does not affect the operation of Managed Servers in the domain but it does prevent you from changing the domain’s configuration. If an Administration Server fails because of a hardware or software failure on its host machine, other server instances on the same machine may be similarly affected. However, the failure of an Administration Server itself does not interrupt the operation of Managed Servers in the domain.

If an Administration Server for a domain becomes unavailable while the server instances it manages—clustered or otherwise—are up and running, those Managed Servers continue to run. Periodically, the Managed Servers attempt to reconnect to the Administration Server. If the domain contains clustered server instances, the load balancing and failover capabilities supported by the domain configuration remain available, even if the Administration Server fails.

You can start a Managed Server even if the Administration Server is not running. In this case, the Managed Server uses a local copy of the domain’s configuration files for its starting configuration and then periodically attempts to connect with the Administration Server. When it does connect, it synchronizes its configuration state with that of the Administration Server.

For information on starting a Managed Server without a running Administration Server, see in Administering Server Startup and Shutdown for Oracle WebLogic Server. For information on re-starting an Administration Server, see » in Administering Server Startup and Shutdown for Oracle WebLogic Server.

Managed Servers and Managed Server Clusters

Managed Servers host business applications, application components, Web services, and their associated resources. To optimize performance, Managed Servers maintain a read-only copy of the domain’s configuration document. When a Managed Server starts up, it connects to the domain’s Administration Server to synchronize its configuration document with the document that the Administration Server maintains.

For production environments that require increased application performance, throughput, or high availability, you can configure two or more Managed Servers to operate as a cluster. A cluster is a collection of multiple Oracle WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability. In a cluster, most resources and services are deployed identically to each Managed Server (as opposed to a single Managed Server), enabling failover and load balancing. A single domain can contain multiple Oracle WebLogic Server clusters, as well as multiple Managed Servers that are not configured as clusters. The key difference between clustered and non-clustered Managed Servers is support for failover and load balancing. These features are available only in a cluster of Managed Servers. For more information about the benefits and capabilities of an Oracle WebLogic Server cluster, see in Administering Clusters for Oracle WebLogic Server.

charset-params

The element is used to define code set behavior for non-unicode operations. For example:

<charset-params> 
    <input-charset> 
        <resource-path>/*</resource-path> 
        <java-charset-name>UTF-8</java-charset-name> 
    </input-charset> 
</charset-params>

charset-mapping

Use the element to map an IANA character set name to a Java character set name. For example:

<charset-mapping>
    <iana-charset-name>Shift-JIS</iana-charset-name>
    <java-charset-name>SJIS</java-charset-name>
</charset-mapping>

For more information, see .

The following table describes the elements you can define within a element.

4.4 Configuring JDeveloper’s Default Domain

You can configure JDeveloper’s default domain by launching the Integrated WebLogic Server.

4.4.1 Launching the Integrated WebLogic Server

To launch the integrated WebLogic server:

1. Launch JDeveloper.

   If you have set the environment variable to your Oracle home, you can enter commands similar to the following examples:

   As Oracle JDeveloper launches, you will get three prompts.

   When prompted, select Studio Developer as your role and click OK.

   Description of the illustration GUID-341B14BF-BE05-487E-9CC5-8876DD2EF21D-default.gif

   When prompted, click No to import preferences from a previous JDeveloper installation.

   Description of the illustration GUID-8EBEE87D-04B6-41DD-B381-B8DDDC659AA5-default.gif

   When prompted about Oracle Usage Tracking, check whether or not you want Oracle JDeveloper to send automated usage reports to Oracle and click OK.

   JDeveloper has fully launched at this point.

2. Launch the Integrated WebLogic Server by choosing Run from top menu bar. Select Start Server Instance from the drop-down menu.

   Figure 4-2 Starting the Integrated WebLogic Server

   Description of «Figure 4-2 Starting the Integrated WebLogic Server»

3. The first time you launch the server instance, you will be prompted to enter a password for your default domain.

   Figure 4-3 Specifying a Password for Default Domain

   Description of «Figure 4-3 Specifying a Password for Default Domain»

   The Administrator ID, Listen Address, Listen Port, and SSL Listen Port should already have values. Review them and make any appropriate changes.

4. Launching the integrated server will take several minutes.

   You can track the server’s launch in the Messages window pane. This window should automatically open at the bottom of the JDeveloper screen. If it is not there, you can open it by selecting Window from the top bar menu and Log from the drop-down menu. You can also activate it with the keyboard shortcut .

   Note:

   If the creation of the Integrated WebLogic Server domain fails with the following error:

   Make sure to shut down all running servers, even if they are not using Java DB, and try the domain creation again.

   Note:

   If your machine is connected through a VPN, Coherence may be confusing the local and VPN IP addresses. Change the Coherence cluster to multicast.

5. When you see the following messages appear in the log, the Integrated WebLogic Server has launched successfully.

4.4.2 Verifying Your Domain

Your default domain is already configured with Oracle SOA Suite and Oracle Service Bus runtime components. To verify your domain installation:

1. Access the Enterprise Manager Fusion Middleware Control, which is located at a URL following this format:

   http://hostname.domain:7101/em
   

   Note:

   The default port for the Integrated WebLogic Server should always be unless you changed it during configuration.

   Log in using the username and password that you specified when launching the Integrated Weblogic Server.

   For more information on using Fusion Middleware Control, see in Administering Oracle Fusion Middleware.

2. Alternatively, if you plan to develop projects using the Oracle Service Bus console, you can check to see if Oracle Service Bus is running.

   The Oracle Service Bus console is located at an URL with the following format:

   http://hostname.domain:7101/servicebus
   

   Log in using the username and password that you specified when creating your standalone domain.

   For more information on using the Oracle Service Bus console, see Getting Started with the Oracle Service Bus Console in Developing Services with Oracle Service Bus.

4.4.3 Disabling Secure Sockets Layer (SSL)

This is an optional task. SSL is enabled by default in the Integrated WebLogic Server. If you do not have stringent design time requirements, you can disable SSL as follows:

1. Go to the Administrator Console at
2. Log in with your credentials.
3. Select Environments, then Servers, then Admin Server.
4. Uncheck SSL Listen Port Enabled.
5. Restart the Integrated WebLogic Server.

Web Application Modules

A Web application on WebLogic Server includes some required and typically, some optional files.

• At least one servlet or JSP, along with any helper classes.

• Optionally, a deployment descriptor, a Java EE standard XML document that describes the contents of a WAR file.

• Optionally, a deployment descriptor, an XML document containing WebLogic Server-specific elements for Web applications.

• A Web application can also include HTML and XML pages with supporting files such as images and multimedia files.

Servlets

Servlets are Java classes that execute in WebLogic Server, accept a request from a client, process it, and optionally return a response to the client. An is most often used to generate dynamic Web pages in response to Web browser requests.

JavaServer Pages

JavaServer Pages (JSPs) are Web pages coded with an extended HTML that makes it possible to embed Java code in a Web page. JSPs can call custom Java classes, known as tag libraries, using HTML-like tags. The compiler compiles JSPs and translates them into servlets. WebLogic Server automatically compiles JSPs if the servlet class file is not present or is older than the JSP source file. See .

You can also precompile JSPs and package the servlet class in a Web application (WAR) file to avoid compiling in the server. Servlets and JSPs may require additional helper classes that must also be deployed with the Web application.

WebLogic Server Default Domain Extension Template

Using the Configuration Wizard or WLST, you can easily extend a base WebLogic Server domain to include resources required for a default WebLogic Server domain. You accomplish this by adding the resources and services provided in the WebLogic Server Default Domain extension template to a base WebLogic Server domain.

For more information about the samples that are supported in the WebLogic Server Examples domain, see in Understanding Oracle WebLogic Server.

Template Details

The following table provides basic information about the WebLogic Server Default Domain Extension template.

Template Dependencies lists all templates that provide resources required by the WebLogic Server Default Domain extension template.

Creating a Managed Server Domain on a Remote Machine

If your WebLogic domain contains multiple Managed Servers, and each Managed Server domain directory is located on a remote machine on which the Administration Server does not reside, you can use the WLST command in online mode. When you execute the command while connected to the Administration Server from a remote machine, it dynamically packs the domain on the Administration Server into a template JAR file and transfers the template JAR to the specified directory.

The following sample WLST script demonstrates how to use to create or update a Managed Server domain on a remote machine. Run the script on each remote machine in the domain.

import os
 
wlsHome = os.getenv('WL_HOME')
mwHome = os.path.join(wlsHome, '..')
 
#Substitute the administrator user name and password values below as needed
connect('adminusername','adminpassword','localhost:7001')
 
#The path on the local machine where the template will be created, 
#it should not already exist.
templatePath = 'user_templates/myTemplate.jar'
 
#get the packed template from the Administration Server
writeTemplate(templatePath)
 
#disconnect from online WLST connection to the Administration Server
disconnect()
 
#select and load the template that was downloaded from the Administration 
#Server. 
selectCustomTemplate('templatepath')
loadTemplates()
 
#specify the domain directory where the domain needs to be created
domainPath = 'domains/myRemoteDomain')
 
#create the domain
writeDomain(domainPath)

WebLogic Server Examples Extension Template

Using the Configuration Wizard or WLST, you can easily extend a base WebLogic Server domain to create a WebLogic Server Examples domain. You accomplish this by adding the resources and services provided in WebLogic Server Examples extension template to a base WebLogic Server domain.

For more information about the samples that are supported in the WebLogic Server Examples domain, see in Understanding Oracle WebLogic Server.

Template Details

The following table provides basic information about the WebLogic Server Default Domain Extension template.

Template Dependencies lists all templates that provide resources required by the WebLogic Server Examples extension template, in the order in which they must be configured in the domain.

Resources and Services Configured

In addition to the resources configured by the WebLogic Server Default Domain extension template (see ), the WebLogic Server Examples extension template configures the resources and services listed in the following table.

XML Deployment Descriptors

A deployment configuration refers to the process of defining the deployment descriptor values required to deploy an enterprise application to a particular WebLogic Server domain. The deployment configuration for an application or module is stored in three types of XML document: Java EE deployment descriptors, WebLogic Server descriptors, and WebLogic Server deployment plans.

This section describes the Java EE and WebLogic-specific deployment descriptors. See for information on deployment plans.

The Java EE programming model uses the JDK annotations feature for Web containers, such as EJBs, servlets, Web applications, and JSPs. Annotations simplify the application development process by allowing a developer to specify within the Java class itself how the component behaves in the container, requests for dependency injection, and so on. Annotations are an alternative to deployment descriptors that were required by older versions of Web applications (2.4 and earlier), enterprise applications (1.4 and earlier), and Enterprise JavaBeans (2.x and earlier). See .

However, enterprise applications fully support the use of deployment descriptors, even though the standard Java EE ones are not required. For example, you may prefer to use the old EJB 2.x programming model, or might want to allow further customizing of the EJB at a later development or deployment stage; in these cases you can create the standard deployment descriptors in addition to, or instead of, the metadata annotations.

Modules and applications have deployment descriptors—XML documents—that describe the contents of the directory or JAR file. Deployment descriptors are text documents formatted with XML tags. The Java EE specifications define standard, portable deployment descriptors for Java EE modules and applications. Oracle defines additional WebLogic-specific deployment descriptors for deploying a module or application in the WebLogic Server environment.

lists the types of modules and applications and their Java EE-standard and WebLogic-specific deployment descriptors.

Note:

The XML schemas for the WebLogic deployment descriptors listed in the following table include elements from the schema, which describes common elements shared among all WebLogic-specific deployment descriptors.

For the most current schema information, see: .

When you package a module or application, you create a directory to hold the deployment descriptors— or —and then create the XML deployment descriptors in that directory.

Automatically Generating Deployment Descriptors

WebLogic Server provides a variety of tools for automatically generating deployment descriptors. These are discussed in the sections that follow.

EJBGen

EJBGen is an Enterprise JavaBeans 2.x code generator or command-line tool that uses Javadoc markup to generate EJB deployment descriptor files. You annotate your Bean class file with Javadoc tags and then use EJBGen to generate the Remote and Home classes and the deployment descriptor files for an EJB application, reducing to a single file you need to edit and maintain your EJB and descriptor files. See in Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.

Note:

EJBGen, an Enterprise JavaBeans 2.x code generator utility, is deprecated as of Oracle WebLogic Server 12.2.1.3.0, and will be removed in a future release.

Java-based Command-line Utilities

WebLogic Server includes a set of Java-based command-line utilities that automatically generate both standard Java EE and WebLogic-specific deployment descriptors for Web applications and enterprise applications.

These command-line utilities examine the classes you have assembled in a staging directory and build the appropriate deployment descriptors based on the servlet classes, and so on. These utilities include:

• — automatically generates the deployment descriptors for enterprise applications.

• — automatically generates the deployment descriptors for Web applications.

For an example of , assume that you have created a directory called that contains the JSP files and other objects that make up a Web application but you have not yet created the and deployment descriptors. To automatically generate them, execute the following command:

   prompt> java weblogic.marathon.ddinit.WebInit c:\stage

The utility generates the and deployment descriptors and places them in the directory, which will create if it does not already exist.

Using the weblogic.Server Command Line to Create a Domain

You can use to create a domain that contains a single server instance. You cannot use to add Managed Server instances to a domain, nor can you use to modify an existing domain.

As described in if is unable to find a file, it offers to create the file. Any command option that you specify and that corresponds to an attribute that is persisted in the file will be persisted. For example, the and options specify the name of a server configuration and the name of a domain. If is unable to find a file, both of these values are persisted in . However, the option, which specifies a file that contains user credentials for starting a server instance, is not an attribute that the file persists.

To create and instantiate a simple example domain and server, do the following:

1. In a command shell, set up the required environment variables by running the following script:

   (on Windows)

   (on UNIX)

   where is the directory in which you installed the WebLogic Server software.

2. In the command shell, create an empty directory.

3. In the empty directory, enter the following command:

   java -Dweblogic.Domain=SimpleDomain -Dweblogic.Name=SimpleServer
   -Dweblogic.management.username=weblogic  -Dweblogic.management.password=password
   -Dweblogic.ListenPort=7001 weblogic.Server
   

After you enter this command, WebLogic Server asks if you want to create a new file. If you enter , it then instantiates a domain named SimpleDomain. The domain’s Administration Server is configured as follows:

• The name of the Administration Server is SimpleServer.

• The domain’s security realm defines one administrative user, , with a password of password.

• For the listen address of the Administration Server, you can use , the IP address of the host computer, or the DNS name of the host computer. For more information about setting the listen address, see «Configure listen addresses» in the Oracle WebLogic Server Administration Console Online Help.

• The Administration Server listens on port 7001.

Entering the command as described in this section creates the following files:

Considerations for Clusters, JDBC, and JMS Resources

When using WLST offline to create or extend a clustered WebLogic domain with a template that has applications containing application-scoped JDBC and/or JMS resources, you may need to perform additional steps (after the domain is created or extended) to make sure that the application and its application-scoped resources are targeted and deployed properly in a clustered environment. For more information on the targeting and deployment of application-scoped modules, see in Deploying Applications to Oracle WebLogic Server.

If you want to use JDBC resources to connect to a database, modify the environment as the database vendor requires. Usually this entails adding driver classes to the variable and vendor-specific directories to the variable. To set the environment that the sample Derby database requires as well as add an SDK to the variable and the WebLogic Server classes to the variable, invoke the following script:

(on Windows)

WebLogic Advanced Web Services for JAX-WS Extension Template

The WebLogic Advanced Web Services for JAX-WS extension template automatically configures the resources required to support the following advanced Web services features:

• Web services atomic transactions

• Security using WS-SecureConversation

Note:

Each of the two Advanced Web Services templates can be used individually or together in a domain. If, however, you apply this template to the same domain to which you applied the WebLogic Advanced Web Services extension template, you must apply the Advanced Web Services template before applying the Advanced Web Services for JAX-WS template.

For more information, see in Developing JAX-WS Web Services for Oracle WebLogic Server.

Template Details

The following table provides basic information about the WebLogic Advanced Web Services for JAX-WS extension template.