Ошибка вызова метабазы ​​IIS при возврате объекта 424 Требуется ошибка объекта 424 - PullRequest
Новая
       29

Ошибка вызова метабазы ​​IIS при возврате объекта 424 Требуется ошибка объекта 424

0 голосов
/ 25 февраля 2011

У нас есть веб-сайт ASP Classic, работающий на Windows Server 2003 и IIS6, который выбрасывает объект 424 с прерывистой ошибкой во время выполнения. Мы проследили это до строки, которая инициализирует ссылку на объект для метабазы, как показано ниже (вторая строка): 

MetaBasePath="IIS://" & ComputerName & "/" & StorageKey & "/" & DataAccessKey
Set ConfigKey=GetObject(MetaBasePath)
DataSource=ConfigKey.Get("ODBCDataSource")
UserName=ConfigKey.Get("ODBCUserName")
Password=ConfigKey.Get("ODBCPassword")

Я искал в stackoverflow (и в Интернете в целом) любые признаки того, что кто-то еще имеет эту проблему, но нарисовал пробел. У кого-нибудь есть идеи, что может быть причиной этого? Существуют ли какие-либо параметры, связанные с производительностью, которые контролируют частоту доступа к метабазе? Существуют ли какие-либо передовые методы, которые мы можем использовать для повышения эффективности доступа к метабазе? Правильны ли мы, полагая, что мы поступаем правильно, скрывая детали доступа к нашей базе данных в метабазе, или это излишнее из-за безопасности?

Эта проблема затрагивает нас примерно на 1% просмотров страниц.

Мы рассматриваем ряд действий, включая проверку уровня исправлений компонентов программного обеспечения сервера и, возможно, добавление цикла вокруг приведенного выше кода, чтобы продолжать попытки, пока объект Metabase не будет правильно инициализирован, но в лучшем случае это будет кратковременное исправление. по моему.

Советы приветствуются! Спасибо, Крейг.

Дополнительная информация: только что обнаружил, что режим изоляции IIS5.0 включен. Я пытаюсь выяснить, почему это было включено, но может ли это быть актуально?

1 Ответ

1 голос
/ 04 марта 2011

Метабазы ​​IIS НЕ предназначены для безопасности, а просто для удобства.

Это просто центральное хранилище данных, совместно используемых несколькими виртуальными серверами (приложения IIS / ASP).Так что если вы используете его только в целях безопасности, то метабаза вообще не нужна.

Потому что:

  • Кто вы? скрывая доступ к нашей базе данныхдетали"от?Программист?Но он уже имеет к нему доступ.После присвоения ConfigKey.Get("ODBCPassword") паролю, любой response.write откроет его.Даже если это сделано в global.asa, где-то вам придется преобразовать его в строку подключения (или сохранить в переменной Application), чтобы страницы .asp могли создавать объекты подключения к базе данных.В какой-то момент между метабазой и созданием объекта он будет иметь доступ к свойствам соединения.

  • Даже не думает о предотвращении этого путем создания объекта соединения в global.asa и сохранение самого объекта в переменной приложения.(таким образом скрывая создание из файлов, доступных программисту).Это не только убивает пул соединений, но и огромный отрицательный удар по производительности.

Если вы беспокоитесь о безопасности баз данных на страницах ASP, вот несколько подходов, которые я предлагаю:

  • Создайте другого пользователя базы данных для доступа к веб-сайту с очень ограниченными привилегиями.Значение SELECT, INSERT, UPDATE, DELETE и EXECUTE (хранимые процедуры) только .Нет DROP, CREATE, ALTER и т. Д. Таким образом, любая «утечка пароля» или «злоупотребление программистом» не нанесут серьезного ущерба базе данных.Пароль пользователя «admin» с полными привилегиями никогда не будет доступен (или не использован) где-либо на веб-сайте.

  • Создание библиотеки ActiveX (или COM, DCOM) для переноса соединениянастройки.Он может быть написан на C #, VB.NET или даже классическом VB6.Он будет считывать логин и пароль из другого (защищенного и недоступного через Интернет) файла сервера, создавать объект подключения и напрямую передавать его в ASP.

Поэтому вместо использования: 

set objConn = Server.CreateObject("ADODB.Connection")

Страницы ASP будут использовать: 

set objConn = Server.CreateObject("MYCLASS.Connection")

Сам файл конфигурации может быть даже зашифрован, поскольку алгоритм дешифрования будет храниться в скомпилированном коде, а НЕ в текстовом ASP-файле.

Тем не менее, я не имею в виду, что метабаза бесполезна.Это все еще хорошее, удобное место для хранения данных, потому что:

  • Данные могут быть изменены без изменения какой-либо строки кода

  • Несколько веб-сайтов могутобмениваться данными, даже если у каждого есть свое изолированное приложение

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

  • Пользовательские / NTFS-разрешения могут быть настроены таким образом, что только авторизованные пользователи могут изменять данные, но пользователи веб-сайта (и разработчики ASP) могут только читать их

Тем не менее,«Ограниченный пользователь базы данных» + «Оболочка соединения класса COM» - это подход, используемый в большинстве компаний, с которыми я работал.Те, кто обеспокоен безопасностью, конечно.Другие просто используют «строку подключения, жестко закодированную в global.asa, затем сохраненную в переменной приложения».

...