Django 개발 일기 - 1

서버 오픈 이후 보안패치

by HOON

Last updated on Feb. 2, 2024, 4:29 p.m.

개요

하지만 post delete 함수를 생성하는 과정에서, 보안 이슈가 발생하여 내 의지와는 상관없이 post들이 타인에 의해 삭제되기 시작했고,
그 이유를 찾는 과정을 써내려가려고 한다.

과정

1. 관리자페이지 노출
Admin은 Django에서 기본으로 제공되는 강력한 기능 중 하나인데, 문제는 해당 page가 그대로 노출이된다. (ex. 127.0.0.1:8000/admin)
이는 개발자에게 양날의검이 된다 생각한다. 19년도에 해킹공격 수업을 들을 때 당시 KISA의 취약점 가이드에 "관리자페이지 노출여부"가 있었기 때문에 항상 관리자페이지는 숨겨야 한다고 생각을 한다.

중간에 한번 이상한 닉네임으로 회원가입한 유저가 있었기도 했고, 그러면 안됐지만 관리자 비밀번호를 쉽게 설정한 내 잘못이 크다..
(실제로 만들어진지 3일도 안된 사이트에 해킹공격이 들어올거라 생각을 전혀 못했다.)

따라서 관리자 페이지의 노출을 아예 막아버렸다. 물론 개발시에는 필요하기때문에 소스 내 os.environ.get()를 이용하여 특정 환경에서만 admin 페이지로 접속을 허용했다.

2. 비정상적인 Access Log
현재 나는 docker에 서버를 올려서 운영하는중이다.
실제로 접속한 기록을 실시간으로 볼 수 있기에, post가 delete된 이후 로그를 분석 해 봤다.

분석결과, 단순 post가 삭제되는게 문제가 아닌, 당장 여러나라 ip에서 해킹 시도가 있었다.
심지어 shell script까지 작성되어 url로 날리고 있었지만, 다행히 Django의 기본적인 framework는 기본적인 방어가 잘 되어있는 상태라
아무런 피해는 입지 않았다.

비정상적인 접근을 막을 방법을 구글링 하던 중 fail2ban이라는 간단하지만 강력한 서버 보안프로그램을 찾았다.
기본적인 원리는 access log를 읽고, 사용자가 정의 해 둔 regex에 따라 비정상적인 접근에 해당되는 ip인 경우
특정기간(분 단위 부터 영구까지) 해당 ip에 ban처리를 하는것이다.

(해당 적용과정은 다음 post에서 상세하게 기록 할 예정이다.)

해결

바로 delete post function을 작성 할 때 사용자인증 코드를 넣지 않았던것..

처음 코드는 아래와 같았다.

    def delete_post(request, pk): 
        post=Post.objects.get(id=pk)
        post.delete()
        return redirect('/blog/')

해당 코드의 문제점은 delete_post 를 post로 누구나 보낼 수 있다는 점이다.

따라서 x.x.x.x POST hongjunghoon.com/blog/delete_post/5 와 같은 형식으로 서버에 요청을 보내게 된다면
서버 자체는 해당 요청이 누가 보낸것이고, 인증이 된 상태인지를 검증하지않고 바로 삭제해버린다.
굉장히 간단한 실수여서 더욱 허무했다.

해당 코드는 인증 과정을 추가 한 후 배포하였고, 테스트 결과 해당 블로그의 작성자가 아닐경우 서버에게 post로 요청해도 정상적으로 적용되지 않았다.

코드는 request.user.is_authenticated and request.user == post.author를 추가해서
요청자가 인증되었는지 그리고 해당 유저가 post의 author인지를 검증하여
모두 일치할경우에만 실제 delete_post를 진행 할 수 있도록 수정하였다.