Проверьте источник Запроса HTTP

У меня есть две системы, которые должны говорить. Системы являются установкой likeso:

System A, выполнение Django (Python 2.5) на Google App Engine (GAE)

System B, выполнение Django (Python 2.6) на Ubuntu/Linux по Lighttpd (возможно, nginx, позже)

Система A будет периодически выполнять запросы ('реквизиции') Системы B использование Выборки URL.

Система B имеет установку приложения Django для прислушиваний к этим запросам с a urls.py с чем-то как:

urlpatterns = patterns('producer.views',
    url(r'^requisition$', 'requisition', name='requisition'),
)

И соответствие views.py с чем-то как:

import json
from django.http import HttpResponse

def requisition(request):
    " do something "
    response = HttpResponse()
    response['Content-type'] = 'application/json'
    response.write(json.dumps(...))
    return response

Это было бы ценное дополнение к безопасности системы, если бы Система B ответила на реквизиции только от Системы A.

Я хотел бы знать, какие опции доступны для Системы B, чтобы проверить, что запросы прибыли из Системы A. Я рассмотрел следующее:

  • Проверьте, что IP-адрес от GAE (однако, я не знаю IP-адресов GAE, они могут измениться, и они могут имитироваться),
  • Проверьте, что обратный DNS IP от GAE (однако, я не знаю, каковы записи DNS GAE, если они изменятся, и они могут имитироваться),
  • Используйте клиентский сертификат TLS от Системы - но я не знаю, как сделать это с GAE
  • Сделайте проблему/ответ на основе чего-то совместно использованного, как соль, с pycrypto

Идеально я хочу закончить с a views.py с чем-то likeso:

... 
from django.http import HttpResponseForbidden 

def requisition(request):
   " do something "
  if not verify_request_origin():
     return HttpResponseForbidden("Denied.")

  response = HttpResponse()
  ...

Где verify_request_origin () возвращает true, когда запрос сделал к System B был от System A на GAE.

Спасибо и я надеемся слышать Ваши мысли.

5
задан Brian M. Hunt 14 February 2010 в 21:26
поделиться

3 ответа

Как насчет

(defn add-unique-id [coll]
  (map #(assoc  %1 :id %2)  coll (range (count coll))))

Или

(defn add-unique-id [coll]
  (map #(assoc  %1 :id %2)  coll (iterate inc 0)))
-121--4594587-

Идея добавления атрибута InternaseVisibleTo является хорошей, но я думаю, что проблема заключается в том, что Xml-код сериализации ищет только открытые типы в сборке.
Насколько мне известно, нет пути сериализовать или десериализовать внутренние типы, и вам придется либо объявить типы общедоступными, либо написать свой собственный код сериализации.
Более того, в документации по классам StartSerializer явно указано, что сериализуются только общедоступные свойства объекта: «сериализация XML - это процесс преобразования общедоступных свойств и полей объекта в последовательный формат (в данном случае XML) для места хранения или транспорта», так что это действительно выглядит как проектное решение.

-121--4903816-

Первые два пункты не используются.

Пароль, как говорит Эндрю , достаточно хорош, если вы не беспокоитесь о проблемах в кэше браузера. В этом случае следует использовать SSL, но для аутентификации одного приложения с другим, например, hmac , и использовать его для создания общего секрета для сеанса. Секрет должен находиться в коде, а не в переданных данных.

1
ответ дан 14 December 2019 в 19:12
поделиться

Система A может отправлять HTTPS-запросы через urlfetch.fetch - просто задайте параметр URL, начинающийся с https: // . Однако это не аутентифицирует его для системы B (это предотвращает снифферы и атаки типа «злоумышленник в середине»); нет возможности использовать клиентский сертификат TLS.

Проверка того, что запрос действительно исходит от GAE (что было бы вполне осуществимо: просто используйте собственный DNS-сервер Google на 8.8.8.8 - если кому-то удалось взломать собственный DNS Google, его способность обмануть вашу систему B будет наименьшей беспокойства всего мира ;-) тоже не помогает по той же причине: это может быть любое приложение GAE (все они имеют кучу IP-адресов, и данный IP-адрес может использоваться любым числом приложений GAE за короткий период времени).

Таким образом, шифрование полезной нагрузки с помощью общего секрета кажется самым простым с учетом ограничений GAE. PyCrypto - возможно, с exPyCrypto впереди - может быть хорошим; или вы можете попробовать SlowAES (у меня, конечно, есть слабое место для последнего ;-).

1
ответ дан 14 December 2019 в 19:12
поделиться

Похоже, достаточно использовать SSL для ссылки и включить пароль в строку запроса.

SSL защищает от снифферов, и вы не собираетесь раскрывать запросы вне систем, находящихся под вашим контролем, поэтому подойдет общий секрет (и он будет более безопасным, чем отслеживание IP, поскольку другие сайты GAE будут использовать эти адреса).

2
ответ дан 14 December 2019 в 19:12
поделиться
Другие вопросы по тегам:

Похожие вопросы: