Django crsf의 소스 프로세스 및 분석 중간부품이 CSRF 공격을 예방하는 방법

3185 단어 Django#crsf
중간부품django\middleware\csrf를 분석합니다.py의 processview 프로세스:
  • settings에 있습니다.py중'django.middleware.csrf.CsrfView Middleware'중간부품이 활성화되어야 위 파일로 갑니다
  • 요청한 쿠키의settings를 읽습니다.CSRF_COOKIE_NAME 즉 csrftoken, csrftoken
  • 요청한 csrfmiddlewaretoken의 값을 Request 에 읽기 시도csrf_token: request_csrf_token = request.POST.get ('csrfmiddlewaretoken', ') (처리할 수 있도록: 템플릿으로 렌더링된 폼을 통해POST 요청을 제출하는 경우) 읽지 못하면 요청 헤더의 HTTP 를 읽습니다.X_CSRFTOKEN (처리할 수 있도록: js 코드를 통해POST 요청을 보내는 경우) 주: Django 프레임워크는 원래 요청 헤더의 X-CSRFtoken을 HTTP 로 봉인합니다.X_CSRFTOKEN
  • 그리고 Request 비교csrf_token 및 csrftoken이 같은지, 같으면crsf검사를 통과할 수 있습니다.

  • 결론: 비교한 것은 바로 비교(cookie에서 csrftoken의 값)와 (순수한 폼 제출 중인 csrfmiddlewaretoken이나 JS가 보낸 요청 헤더의 X-CSRFtoken)의 값이 같은지 여부이다. 전체 과정은 데이터베이스에 있는 것과 비교되지 않았다.따라서 앞뒤가 분리된 후 백엔드에 템플릿 렌더링이 없습니다. 만약에 앞쪽에서 POST 요청을 보내려면 앞쪽 엔지니어가 수동으로 요청 헤더에 X-CSRFtoken을 추가해야 합니다. 대응하는 값은 js독쿠키를 통해 얻을 수 있습니다.
    상기 결론에 근거하여 당신은 코드 구조 요청을 통해 상술한 검사를 충족시킬 수 있으며, 요청 헤더의 쿠키의 csrftoken과 요청 헤더의 X-CSRFtoken의 값은 마음대로 기입할 수 있습니다.
    url = "http://192.168.56.101:8082/data/student_data/"
    input_dict = {'name':'cheng', 'age':23}
    res = requests.post(url, data=input_dict,
    					# headers={'X-CSRFToken':'F0S0sHIXOAF9pjwpn78EB5ZjxvOO4c7I','Cookie': 'csrftoken=F0S0sHIXOAF9pjwpn78EB5ZjxvOO4c7I'})
    					headers={'X-CSRFToken':'mycrsftokenabc','Cookie': 'csrftoken=mycrsftokenabc'})
    print 'type(res.headers) = {0}, res.headers = {1}'.format(type(res.headers), res.headers)
    print 'type(res.text) = {0}, res.text = {1}'.format(type(res.text), res.text)
    print 'res.status_code = {0}'.format(res.status_code)
    

    Django 프레임워크의 CSRF 인증 메커니즘을 이해한 후에 이 메커니즘이 CSRF 공격을 어떻게 회피하는지 이야기한다. CSRF 공격 공격 원리와 과정은 다음과 같다.
  • 사용자 C는 브라우저를 열고 신뢰받는 사이트 A를 방문하고 사용자 이름과 비밀번호를 입력하여 사이트 A에 로그인을 요청한다.
  • 사용자 정보가 검증을 통과한 후에 사이트 A는 쿠키 정보를 생성하여 브라우저에 되돌려준다. 이때 사용자가 사이트 A에 로그인하면 정상적으로 사이트 A에 요청을 보낼 수 있다.
  • 사용자가 사이트 A에서 탈퇴하기 전에 같은 브라우저에서 TAB 페이지를 열어 사이트 B를 방문한다.
  • 사이트 B는 사용자의 요청을 받은 후 일부 공격적인 코드를 되돌려주고 제3자 사이트 A를 방문할 것을 요청한다.
  • 브라우저는 이러한 공격적인 코드를 받은 뒤 사이트 B의 요청에 따라 사용자가 모르는 사이에 쿠키 정보를 가지고 사이트 A에 요청한다.사이트 A는 이 요청이 실제로 B에서 발동된 것인지 알지 못하기 때문에 사용자 C의 쿠키 정보에 따라 C의 권한으로 처리돼 사이트 B로부터 악성코드가 실행된다.

  • 주의 5단계: 공격 코드가 사이트 A의 쿠키 정보를 가지고 사이트 A에 요청(공격 코드는 브라우저에서 실행되기 때문에 사이트 A에 요청을 보낼 때 사이트 A의 쿠키를 휴대하고 sessionid와crsftoken을 휴대한다): 만약에 Django의 백엔드에서 django를 사용할 수 있다면.middleware.csrf.CsrfViewMiddleware 중간부품을 사용하면 요청이 종료됩니다.POST 요청에는 csrfmiddlewaretoken이 없고 요청 헤더의 쿠키에는 csrftoken이 있습니다.그래서 백엔드에서 csrfmiddlewaretoken을 얻을 수 없습니다.그리고 요청 헤더에서 HTTP 가져오기를 시도해 보세요X_CSRFTOKEN도 값을 얻지 못했기 때문에 자연스럽게 쿠키의crsftoken과 비교하면 실패하고 요청이 실패합니다!
    이 가능하다, ~할 수 있다, ~할 수 있다, ~할 수 있다, ~할 수 있다, ~할 수 있다,...middleware.csrf.CsrfView Middleware 중간부품의 검사입니다. 그러나 요청에sessionid가 없습니다. (코드가 로컬에서 실행되기 때문에 사이트 A의sessionid가 무엇인지 알 수 없습니다.) session 검증에 실패할 수 있습니다.
    아마도 당신은 js 코드로 사이트 A의 쿠키에 있는 내용을 사이트 B에 보낼 수 있는 방법이 없을까 생각했을 것입니다.사실은 없습니다. 이것은 브라우저 차원에서 격리가 있기 때문입니다.
    그래서 현재는 Django 프레임워크가 매우 엄격해 보입니다. 브라우저의 쿠키에crsftoken과sessionid 이중 인증을 써서 사이트의 안전을 확보합니다.

    좋은 웹페이지 즐겨찾기