У меня немного сложный сценарий. Я попытаюсь объяснить проблему, объяснить, что я делаю, и посмотрю, думает ли кто-нибудь еще, что это возможно.
Во-первых, мы совместимы с PCI. Таким образом, любое решение, которое я внедряю, должно учитывать соответствие. Вот сценарий.
Наш сервер - это сервер A. Сервер A безопасен (https), совместим с PCI и содержит веб-приложение. (Windows Server 2003, IIS 6)
Сервер B - это веб-сервер внешнего объекта. У них есть сайт, написанный в любом вкусе. Этот сервер защищен (https), но не совместим с PCI.
Клиент извлекает страницу с сервера B. Существует плагин jquery, который захватывает форму на странице, обслуживаемой сервером B. Это заставляет форму отправлять jsonp http получить запрос прямо на сервер A. Мое предположение, верное или нет, заключается в том, что сервер B никогда не получает сообщение из формы, даже если форма обслуживается клиентом с сервера B. Этот запрос содержит конфиденциальную информацию (кредитную карту) в строке запроса. Опять же, предполагается, что поскольку соединение установлено по протоколу https, эти данные защищены как часть зашифрованной полезной нагрузки.
Итак, сервер A получает запрос и отправляет ответ клиенту (принят, отклонен, ошибка и т. Д.).
Мои вопросы таковы: как я могу быть абсолютно уверен, что сервер A (мой сервер) не сохраняет какие-либо из этих данных. Я уже удалил строку запроса из журналов, но есть ли что-нибудь еще, что мне нужно отключить? Регистрируется ли когда-либо строка запроса в событиях Windows? Как насчет клиентской машины? Будут ли там регистрироваться какие-либо из этих данных (строка запроса)? Кроме того, как я могу продемонстрировать (доказать) кому-либо (моему боссу), что строка запроса является частью зашифрованной полезной нагрузки?
РЕДАКТИРОВАТЬ:
Уточнение: сервер A и сервер B не находятся в одном домене. Я должен заставить этот http-запрос работать в перекрестном домене через вызов ajax. Я не могу использовать прокси на сервере B.
Трассировка пакета покажет, что строка запроса не отправлена в виде открытого текста (и с помощью wirehark's Возможность дешифрования SSL, вы можете показать, что он представлен в зашифрованном виде)
Что касается регистрации, то на стороне клиента ответ однозначный: «может быть». Например, кто-то может находиться за корпоративным прокси-сервером, который заменяет свой собственный SSL-сертификат (выданный центром сертификации, которому доверяют все компьютеры компании) и регистрирует все запросы, и, вероятно, отправляет этот запрос в HR, чтобы они могли написать человеку для тратить на это время компании.
Не знаю, есть ли какие-либо другие журналы, в которых может отображаться запрос на стороне сервера. В зависимости от вашего приложения (JSP?) Он может даже иметь свои собственные журналы, полностью отделенные от IIS.