내 실습 사이트 보안 점검(1)

나만의 실습 사이트 만들기 (1편) (tistory.com)

나만의 실습 사이트 만들기 (1편)

내가 만들게 된 실습 사이트를 대상으로 취약한 부분이 있는지 점검하고 있다면 이를 업데이트 하여 보안적 측면에서 안전하게 관리하는 실습을 해볼 것 이다.

기준은 owasp top10을 기준으로 점검한다.

---

1. injection

먼저 인젝션 관련 취약점 점검을 해 볼 것이다.

html 인젝션 , sql 인젝션 , os command 인젝션 등등

 

1-1. HTML 인젝션

기본적으로 html 인젝션 공격은 입력폼과 url로 매개변수가 전달되고 이를 동적으로 출력할 때 이루어질 수 있다.

 우선 내 페이지에서 입력폼은 로그인페이지, 회원가입 페이지, 게시글 작성 페이지가 있고

매개변수가 전달되는 부분은 사이트 내에서 이전 페이지와 다음페이지를 넘겨줄때 전달되는 page 매개변수가 있다.

여기서 동적으로 출력하는 부분은 게시글의 제목들이 나열되어 있는 게시판 페이지와 게시글 내용을 보여주는 게시글 페이지가 있다. 따라서 이 두부분을 점검 해볼 것 이다.

 

먼저 게시글의 제목들을 나열해주는 게시판 페이지이다.

 

이 부분은 사용자가 입력하여 저장된 내용들이 그대로 출력되는 부분들이다.

작성자와 작성일은 사용자의 의도대로 저장되는 것이 아닌 서버측에서 세션을 사용해 고정되어 저장되니 사용자의 의도대로 저장되고 출력 되지 않는다. 따라서 게시글을 올려 제목 부분에 악의적인 행동을 해보고 점검해보아야 한다.

 

  이런식으로 제목 부분에 html 코드를 적어놓고 저장한 다음 게시판 페이지에서 확인한다.

게시판 페이지에서 html 코드가 문자열로 출력되지 않고 실행된다면 취약하다는 것.

 

 

결과는 html코드를 실행시키는 것이 아닌 문자열 그대로 보여주게 된다.

따라서 안전 O

 

 

똑같이 제목뿐 아니라 글 내용에도 html 코드를 적고 확인해본 결과

안전 O

 

1-2. SQL 인젝션

SQL 인젝션은 사용자의 입력값이 서버의 데이터베이스에 저장될 때 sql 구문으로 저장하게 되면 이를 문자열로 저장되는 것이 아닌 sql 구문으로 받아들여 이를 실행하게 되는 공격이다.

 

예시를 들어 설명하자면

로그인 페이지에선 입력받은 아이디폼을 username으로 저장하고 이를 가져와서 서버에서 처리한다.

그리고 이 가져온 username을 데이터베이스에 저장할때 지정된 sql구문을 통해서 저장하게 되는데 이때 username의 입력값을 이 구문에 맞게끔 적어서 서버측의 의도대로가 아닌 사용자의 악의적인 의도대로 흘러 갈 수 있다.

 

따라서 내 사이트 내에서 데이터베이스를 사용하는 부분인 로그인 페이지 (사용자의 아이디와 비밀번호를 데이터베이스에 저장되어 있는 값과 비교할 때 사용함) , 회원가입 페이지 ( 사용자의 아이디, 비밀번호 등등 정보를 데이터베이스에 저장할 때 사용함 ) , 게시글 페이지 ( 사용자의 게시글을 데이터베이스에 저장할때 사용함 ) 를 점검한다.

 

아이디와 비밀번호 칸에 sql 인젝션 구문 삽입.

 

 

sql구문을 실행시키는것이 아닌 문자열로 인식해 로그인이 되지않는 모습

따라서 안전O

 

    게시글에도 똑같이 삽입.

 

안전 O

 

회원가입 페이지도 점검해본 결과

sql구문으로 인젝션이 되지는 않지만 'or 1=1-- 라는 아이디로 회원가입이 되는것을 확인.

따라서 적절한 이스케이핑은 되고있지만 예상한 범위로 회원가입이 되고있지 않은 상황

이는 나중에 다른부분에서 이 아이디를 사용하게 될 경우 sql 인젝션이 그대로 사용될 향후 공격 가능성이 있다.

따라서 입력검증 보안취약 , 인젝션 보안 O

 

1-3. 이 외의 인젝션

html과 sql 외의 os 인젝션이나 ldap 인젝션 등등 공격 방법은 많지만 내가 현재 만든 사이트에선 이와같은 시스템을 사용하고있지 않기 때문에 점검 예외 대상.

---

2. Broken Access Control 점검

권한이 없는 사용자가 다른 사용자의 계정이나 데이터에 접근하거나, 관리자 권한을 획득하는 등의 문제를 포함한다.

 

먼저 현재 내가 구현해놓은 사이트 내에서 이를 점검할 부분들은 아래와 같다.

 

2-1. 직접 URL 접근 차단 확인

 

• 로그인하지 않고, 로그인 후 접근 가능한 페이지(예: 게시판 페이지)의 URL을 직접 입력하여 접근을 시도한다. 이 경우 접근이 차단되고 로그인 페이지로 리디렉션되는지 확인한다.
• 로그인된 상태에서만 접근 가능한 자원(예: 사용자 프로필 페이지)에 비로그인 상태에서 접근을 시도한다

 

 

 

먼저 로그인을 하지않고 사이트에 접속한다.

그후 url에 /login 페이지 부분을 /create 로 게시판을 작성하는 페이지로 직접 이동시켜본다.

 

로그인을 하지않고도 해당 페이지로 이동이 되는 모습.

게시글 작성까지도 된다. 따라서 직접 url 접근 차단 부분 취약

 

게시판, 게시글작성 페이지, 회원가입 페이지 등등 모두 url 직접 입력시 들어가지는것을 확인함. 

모든 페이지 취약함. 

 

 

 

2-2. 잘못된 세션ID로 접근 시도

로그인을 하지 않은 상태로 로그인 페이지에 접속후 세션을 직접 생성해 잘못된 세션ID를 생성해본다.

이후 메인페이지로 다시 들어왔을때 세션이 있는걸로 판단하여 로그인 페이지를 건너뛰고 게시판 페이지로 이동되었다면 취약점이 있는것.

 

하지만 로그인창에서 다시 막히는 모습. 따라서 잘못된 세션 ID로 접근 취약점 X

 

 

이 외에 Broken Access Control 점검은 게시글 수정이라던지 파일 업로드라던지 관리자 페이지라던지  기능이 들어갈때마다 확인해 주어야 한다. 지금 내 사이트에 있는 기능중에선 이밖에 확인해볼 것이 없다.

---

3. 암호화 점검 

민감한 데이터를 보호하기 위한 암호화 기법이 제대로 적용되지 않거나 약한 암호화 알고리즘을 점검한다.

 

3-1. 데이터 전송중 암호화 부족 

HTTPS 대신 HTTP를 사용하여 데이터가 평문으로 전송될 때 발생한다.

공격자는 네트워크 트래픽을 가로채어 민감한 정보를 쉽게 탈취할 수 있다.

 

 

HTTP 취약

 

 

3-2 약한 암호화 알고리즘 사용

MD5나 SHA-1과 같이 이미 취약점이 알려진 암호화 알고리즘을 사용하는 경우

비밀번호를 해시값으로 바꾸어 데이터베이스에 저장하게되는데 이때 방식은 pbkdf2:sha256을 사용하고 있다.

PBKDF2 (Password-Based Key Derivation Function 2)는 반복 횟수를 늘려 비밀번호 해시를 계산하는 알고리즘으로, 비밀번호 크래킹 공격(예: 브루트 포스 공격)에 대한 방어력을 높인다.

 

추가 보안 조치 방법으론 해시 알고리즘에 솔트(salt)를 추가하는 것인데 generate_password_hash 함수는 자동으로 솔트를 추가하고있어 이또한 적용이 되어 있는 상태이다.

 

따라서 취약 X

---

중간 보고서

점검된 항목

 

1. jnjection – HTML injection , SQL injection

2. Broken Access control – 직접 url 접근 차단 확인 , 잘못된 세션 ID

3. 암호화 – 데이터 전송 암호화 , 약한 암호화 알고리즘

 

 

발견된 취약점

 

injection : 안전 

입력 검증 : 로그인 페이지, 회원가입 페이지  - 취약

직접 url 접근 차단 : 게시판 페이지, 게시글 작성 페이지 , 회원가입 페이지 – 취약

잘못된 세션 ID : 안전

암호화 : HTTP 프로토콜 사용중 – 취약

약한 암호화 알고리즘 사용 : 안전

 

 

권장 사항

 

injection : 사용중인 flask 와 sqlarchemy 라이브러리가 injection을 막아주는 기본적인 기능이 탑재되어 있는 상태

하지만 직접적인 필터링 보안을 넣어 좀더 견고하게 만드는 것을 추천

입력 검증 : 로그인과 회원가입의 입력폼에 특수문자 제외와 값 길이 최소와 최대를 정해줘야함. 

직접 url 접근 차단 : 올바른 세션이 없을시 각 페이지에 접근 못하게 차단해야함.

암호화 : HTTP 프로토콜 사용중임. HTTPS 로 사용해야함.

 

 

 

보안 계획

 

injection : 화이트리스트 필터링 (Whitelist Filtering) 방법 사용

입력 검증 : 각 필드의 최소길이, 최대길이 설정 코드 추가와 아이디 부분에 특수문자를 못넣게 하는 코드 추가.

직접 url 접근 차단 : 로그인 확인 데코레이터 정의 후 각 페이지마다 데코레이터 사용 

암호화 : 무료 SSL 인증서 획득 ,   flask_sslify 패키지 사용으로 사이트를 https 로 전환

 

---

 

 

 

 

이번 글에선 여기까지만 작성하고 다음글에서 다른 점검 목록을 대상으로 이어 나가 점검을 해볼 것 이다.