Check HTTP Request Source

I have two systems that need to talk. The following functions are configured on the systems:

System A , launching Django (Python 2.5) on the Google App Engine (GAE)

System B , running Django (Python 2.6) on Ubuntu / Linux on top of Lighttpd (possibly nginx, later)

System A will periodically make requests ("applications") for System B using Url Fetch .

On system B, there is a Django application setup to listen for these requests using urls.py with something like:

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

And the corresponding views.py with something like:

 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 

This would be a valuable addition to system security if system B only responded to requests from system A.

I would like to know what options are available for System B to verify that requests come from System A. I reviewed the following:

  • Make sure the IP address is GAE (however, I don’t know the GAE IP addresses, they can change and they can be tampered with).
  • Make sure that the reverse DNS IP is from GAE (however, I don’t know which GAE DNS records, if they are changed, and they can be tampered with)
  • Use a TLS client certificate from System A, but I don’t know how to do it using GAE
  • Make a call / response based on something in common, like salt, with pycrypto

Ideally, I want to get views.py with something like:

 ... from django.http import HttpResponseForbidden def requisition(request): " do something " if not verify_request_origin(): return HttpResponseForbidden("Denied.") response = HttpResponse() ... 

Where verify_request_origin () returns true when the request made in System B was from System A to GAE.

Thank you and I look forward to hearing from you.

+4
source share
4 answers

You are in place, the first two bullets are not used.

A password like Andrew says that is good enough if you are not worried about problems in browser caches. If you are then you should still use SSL, but to authenticate one application to another, such as hmac , and use this to generate a shared secret for the session. The secret should be in the code, not the transmitted data.

+1
source

It seems that it would be enough to use SSL in the link and include the password in the query string.

SSL stores sniffers, and you are not going to disclose requests outside the systems under your control, so the shared secret will be (and will be more secure than IP snooping, as other GAE sites will use these addresses).

+2
source

System A can send HTTPS requests via urlfetch.fetch - just enter the URL parameter with https:// . However, this does not authenticate him to system B (this prevents sniffers and man-in-the-middle attacks); There is no way to use the TLS client certificate.

Verifying that the request comes from GAE (which would be feasible: just use Google’s own DNS server at 8.8.8.8 - if someone manages to set up Google’s own DNS, their ability to trick your system B will be least worrying; - ) does not help for any reason: it can be any GAE application (they all have a bunch of IP addresses, and this IP address can be used by any number of GAE applications in a short period of time).

Thus, encrypting the payload with a shared secret seems to be the easiest, given the limitations of GAE. PyCrypto - perhaps exPyCrypto up front - might be fine; or, you can try SlowAES (I, of course, have a weak spot for the latter, -).

+1
source

One option for bullet protection is to look at FOAF + SSL http://www.w3.org/wiki/Foaf%2Bssl/FAQ#What_is_FOAF.2BSSL

+1
source

Source: https://habr.com/ru/post/1301283/


All Articles