Комментарий Соломана Баргути : Методика отклонения мошеннических и нежелательных запросов к базе данных

Единообразие и строгость учета всех запросов в среде сервера приложений J2EE™ позволяет эффективно обрабатывать такие события, как мошеннические или нежелательные запросы к базе данных. В предлагаемой статье описывается простая методика для выявления и обработки мошеннических запросов в среде IBM® WebSphere® Application Server без необходимости перезапуска сервера приложений или базы данных. Из журнала IBM WebSphere Developer Technical Journal.

Соломан Баргути, старший инженер по программному обеспечению, IBM

Author photoСоломан Баргути (Soloman Barghouthi) – старший инженер по программному обеспечению в лаборатории IBM в Рочестере, где он работает архитектором и руководителем группы WebSphere Application Server EJBContainer. С. Баргхути является экспертом по базам данных и автором множества статей по взаимодействию баз данных и продукта WebSphere Application Server.



03.02.2012

Остановить нежелательный запрос!

Трехуровневая архитектура корпоративных приложений состоит из клиентского уровня, связующего уровня и уровня данных. Во многих J2EE-средах (Java™ 2 Platform, Enterprise Edition) связующий уровень обеспечивается сервером приложений IBM WebSphere Application Server. Сервер обрабатывает запросы от клиентского уровня и обращается к уровню данных (например, к СУБД IBM DB2®) с целью извлечения или обновления данных в соответствии с запросами клиентов и введенной ими информацией. Во многих случаях при взаимодействии с базой данных в клиентских запросах используется аутентификационный псевдоним данных. Это может привести к ослаблению строгости учета вследствие потери идентификационных сведений о вызывающей стороне. Строгость учета очень важна не только для слежения за тем, кто и что делает. Она позволяет администраторам платформы WebSphere Application Server и баз данных реагировать на такие непредвиденные события, как необходимость выявления и аннулирования нежелательных и мошеннических запросов к базе данных.

Рисунок 1. Трехуровневая архитектура
Figure 1. Three-tiered architecture

В этой статье объясняется, как использовать специальную функцию продукта WebSphere Application Server для тегирования соединений с базой данных с использованием клиентской информации, а также как применять эту функцию тегирования в таких интересующих нас ситуациях, как выявление и аннулирование мошеннических запросов.


Тегирование соединений с базой данных посредством клиентской информации

Функция, впервые появившаяся в выпуске WebSphere Application Server V6.0, позволяет тегировать соединения с базой данных посредством определенной информации. Затем эта информация передается сервером приложений на уровень базы данных (если база данных поддерживает передачу такой информации), где она может использоваться для идентификации клиента, работающего с этим соединением. Поддерживается задание следующей информации для соединения с базой данных:

  • CLIENT_ACCOUNTING_INFO: Спецификация учетной информации для соединения. Эта информация используется с целью учета клиентов, преимущественно с продуктом DB2 for z/OS®.
  • CLIENT_LOCATION: Спецификация местоположения клиента, инициировавшего запрос.
  • CLIENT_ID: Спецификация текущего пользовательского имени для клиента данного соединения. Это имя предназначено лишь для учета клиентов и не является именем пользователя JDBC-соединения; другими словами, это не аутентификационный псевдоним данных.
  • CLIENT_APPLICATION_NAME: Спецификация имени приложения, использующего соединение с базой данных.

Вышеуказанная информация для соединения может быть задана в приложении WebSphere Application Server V6.0 с помощью API-интерфейса com.ibm.websphere.rsadapter.WSConnection, показанного на рис. 2.

Рисунок 2. API-интерфейс WSConnection
Figure 2. WSConnection API

Начиная с выпуска WebSphere Application Server V7 значимость вышеупомянутого API-интерфейса ослабляется в пользу стандартного API-интерфейса JDBC 4.0, показанного на рис. 3.

Рисунок 3. API-интерфейс JDBC 4.0 Connection
Figure 3. JDBC 4.0 Connection API

Практическое применение функции тегирования

Предположим, ваше приложение занимается динамической компоновкой запросов к базе данных на основе пользовательских запросов, после чего направляет результирующие запросы в базу данных DB2 с помощью продукта WebSphere Application Server. В процессе тестирования вы осознаете, что для некоторых сценариев использования вам необходима возможность отклонения запросов, некорректно специфицированных клиентом. Каким образом вы могли бы сделать это?

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

Листинг 1
.....
javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("jdbc/myDS"); 
conn=ds.getConnection(); 
stmt=conn.createStatement(); 
rs=stmt.executeQuery("Select * from myEmpTable");  
while(rs.next()){ 
out.println(rs.getString(1));

Для использования функции тегирования в данной ситуации необходимо тегировать соединения с базой данных посредством информации о клиенте. В листинге 2 показано, как это можно сделать.

Листинг 2
import com.ibm.websphere.rsadapter.WSConnection
public void displayInfo()
{…..
Properties props = new properties();
 props.setProperty(WSConnection.CLIENT_APPLICATION_NAME,
	 "myspecialAppappname_displayInfo");

javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("jdbc/myDS"); 
conn=ds.getConnection(); 
((WSConnection)conn).setClientInformation(prop);
stmt=conn.createStatement(); 
rs=stmt.executeQuery("Select * from myEmpTable"); 
while(rs.next()){ 
out.println(rs.getString(1)); 
}

Теперь ваше приложение аннотирует используемое им соединение с помощью выражения myspecialAppappname_displayInfo. Теперь, когда соединение с базой данных тегировано информацией о клиенте, администратор базы данных сможет весьма просто выявить и отклонить работу, связанную с рассматриваемым приложением – ему достаточно отыскать соединения с указанным значением аннотации. К примеру, для выявления и отклонения такого запроса администратор базы данных DB2 может выполнить следующие действия:

  1. В командном окне DB2 задать следующую команду для отображения всей информации о соединениях с базой данных (рис. 4):

    db2 get snapshot for applications on sample

    Рисунок 4. Команда Get snapshot
    Figure 4. Get snapshot command
  2. Как показано на рис. 4, параметр «TP Monitor client application name» имеет значение myspecialAppappname_displayInfo, которое было установлено вашим приложением для идентификации соединения.
  3. 3. Вы можете уничтожить соединение, которое применяется для исполнения данного запроса, используя значение параметра Application handle (в данном случае 78) и выполнив соответствующую команду DB2 force application:

    db2 force application (78)

    . Эта команда прерывает соединение, исполняющее «плохой» запрос, и посылает в ваше приложение исключение типа StaleConnectionException. После этого ваше приложение должно обработать это исключение (точно так же, как и любое другое исключение типа StaleConnectionException).

Принудительное завершение «повисшего» или слишком долго исполняющегося запроса может показаться сложной задачей, однако функция тегирования WebSphere дает простой способ ее выполнения. Описанная в этой статье методика может быть применена к любой базе данных, если у этой базы данных имеются такие же, как у DB2, инструменты для отображения и отклонения определенного запроса.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, Information Management
ArticleID=791401
ArticleTitle=Комментарий Соломана Баргути : Методика отклонения мошеннических и нежелательных запросов к базе данных
publish-date=02032012