2

AppEngine은 작업의 특정 헤더에 대해 일부 보증합니다. 특히, X-AppEngine-QueueName과 같은 헤더 집합은 사용자가 설정할 수 없습니다.AppEngine 헤더에서 대소 문자를 구분하지 않는 것이 안전합니까?

이러한 헤더는 App Engine에서 내부적으로 설정합니다. 외부 사용자 요청이 이러한 헤더를 설정하려고 시도하면 해당 헤더가 제거됩니다. 따라서 요청 핸들러가 요청에서이 헤더 중 하나를 찾으면 해당 태스크 큐 요청이 유효 함을 보장합니다.

이 GAE (webappwebapp2)에서 제공하는 두 웹 프레임 워크가 webob.Request에서 상속 Request 개체가 나타납니다. 불행히도, 내가 알 수있는 한 webob.Requestcase-insensitive way의 헤더 만 노출합니다. AppEngine은 사용자가 대소 문자를 구분하지 않고 요청 헤더를 제공 할 수 없다고 보장합니까?

즉, 사용자가 요청에 X-AppEngine-Queuename 헤더를 설정하여 통과 시키면 (webob은 해당 헤더와 GAE가 제공 한 실제 메시지를 구분할 수 없나요?)

webapp2 프레임 워크에서 내 요청이 악의적 인 사용자의 결과가 아닌 작업으로 시작되도록 어떻게 보장합니까?

+0

아마도 HTTP 헤더가 [RFC2616 : 4.2] (http://stackoverflow.com/a/5259004/748858)에 따라 대소 문자를 구분하지 않기 때문에 이것이 정상이라고 가정 할 수 있습니까? – mgilson

+0

내 요청 중 하나와 함께'X-AppEngine-QueueName' 헤더를 설정하려고했습니다. 핸들러에서 자동으로 헤더 키 중 하나 인'X-Appengine-Queuename'으로 바뀝니다. –

+0

worker.yaml 파일에'admin : true'를 설정하여 worker 서비스 핸들러를 보호 할 수 있습니다. –

답변

1

일부 실험을 수행 했으므로 GAE가 대소 문자를 구분하지 않고 헤더를 실제로 위조하는 것으로 나타납니다 (RFC 7230 3.2을 기반으로 예상 됨).

내 테스트 방법에 관심있는 사람들을 위해, 나는 먼저 내 webapp2 요청 처리기에 다음 로깅 문을 추가 : 다음 열려있는 개발 도구와 크롬에서 내 사이트를 탐색

logging.info('request headers: %s', self.request.headers.items()) 
logging.info('request env: %s', list(self.request.headers.environ) 

. "네트워크"탭에서 수정 한 처리기에 대한 요청을 발견했습니다. Right clicking this gives the option to copy the request as cURL 그래서 나는 이것을 쉘 스크립트에 붙여 넣었다. 그런 다음 복사 된 요청을 수정하여 모든 쿠키를 제거하고 GAE에서 나를 나를 앱 관리자로 식별하지 않고 x-appengine-queuename: boom 헤더를 추가했습니다. 나는 컬 요청을 제출하고 내 기록을 살펴 봤다. x-appengine-queuename 헤더가 없습니다. 또한 x-appengine-mgilson: test 헤더를 추가하고 그 헤더가 전달되었습니다. 구현 측면에서

가, 환경이 모두 대문자 헤더가 있습니다 (예를 들어, self.request.headers.environ 모두가 wsgi. 시작 몇 가지 예외를 제외하고 모두 대문자 키가 - wsgi.run_once 등). 헤더는 모두 HTTP_ 접두어로 붙였습니다. 저는 이것이 어딘가 표준의 일부라고 추측합니다 ... webobself.request.headers의 값을 조회 할 때 HTTP_ 및 제목 - 경우 나머지 헤더 이름을 제거합니다 (아마도 준수 할 것입니다 이전에 언급 된 RFC와 함께, 그리고 더 나은 사람이 읽을 수있는 버전을 제공하기 위해).