[My] 홈페이지 시큐어 코딩

1. SQL 인젝션

1-1. mypoint.php (포인트 조회 기능)

my page에서 포인트 조회 기능을 확인해보면 파라미터를 get방식으로 받아오고 있다.

mypoint.php

아래 소스코드는 mypoint로 id 값을 넘겨주는 코드이자, 이전 페이지 코드인 mypage.php 소스 코드 중 일부이다.

mypage.php

위 코드를 확인해보면, id = session id 이므로, 서버 단에서 검증된 id를 가져오는 것이 맞다. 하지만 아래 mypoint.php 로 넘어가는 코드를 확인해보면

mypage.php

포인트 내역을 클릭할 때, 넘겨주는 주소 태그로 mypoint.php?id = "세션 아이디" 를 주었다.

이를 넘길 땐 문제가 되지 않지만, mypoint.php 에서 값을 받을 때 get 방식으로 값이 전해지기 때문에 이를 공격자가 쉽게 변조할 수 있다.

주소창

변조 시, 아이디에 해당하는 point 내역이 조회된다.

 

POC 코드(공격 코드) : 

mypoint.php?id=0%27union%20select%201,2,id,pw,email%20from%20member%20%23

mypoint.php

다음과 같이 컬럼수와, DB이름을 하나씩 알아낸 후 공격 쿼리를 쓰면 DB서버 내부 정보를 탈취 & 악용 할 수 있다.

 

대응방안 : 

- session을 해당 소스(point.php)내에서 post방식으로 검증하기.

이전에 "mypage.php"에서 "mypoint.php" 로 id 값을 보냈지만 이를 위와 같이 수정함.

"mypoint.php" 소스코드에서 DB 쿼리를 조회 할 때 얻어오는 값인 $id 값을 session id로 바꾸어 검증한다.

 

: 사용자에 해당하는 point 만 조회가 가능해짐.

 

 

1-2. board.php (글 검색 기능)

자유게시판에서 검색 기능을 사용 시, "search_result.php" 페이지에서 search 라는 파라미터로 그 값이 넘어가게 된다.

board.php

그런데 이때, post 방식이 아닌, get 방식으로 이를 전송하기 때문에 검색 기능을 클릭 시 값이 search 파라미터 뒤에 노출된다.

"search_result.php"에서는 값을 검증하지 않고 "get 방식"으로 받아온 검색 내용을 그대로 쿼리에 적용한다.

 

때문에 이 값을 공격자 마음대로 조작하여, DB쿼리의 흐름을 바꾸어 원하지 않은 정보를 빼낼 수 있다.

 

POC 코드(공격 코드) : 

검색기능에 다음과 같은 쿼리를 입력하면, 원하는 정보를 출력할 수 있다.

0'union all select id,pw,name,4,5,6,7,8 from member where id ='admin' # 

 

 

대응방안 : 

- get 방식을 post방식으로 바꾸고, search 파라미터에 특수 문자를 필터링을 적용한다. (서버측)

php에서는 sql injection 방어 함수를 제공하고 있다.
"addslashes()"함수와 "mysql_real_escape_string()" 함수가 존재하지만, "mysql_real_escape_string" 함수가 좀더 확장 버전으로, 기능은 동일하지만 처리해주는 문자 수가 많으므로 이 함수를 사용하였다.

두 함수 모두 "데이터베이스 질의" 에서 처리할 필요가 있는 문자 앞에 백 슬래시를 붙인 문자열을 반환해준다.

** mysql_real_escape_string()함수가 에러가 나서 해결해봤다.
-> mysql 함수는 PHP7에서부터 사용이 불가하기 때문에 "mysqli"함수로 변경해서 사용해야 한다.
즉 "mysqli_real_escape_string()"함수를 사용해야 한다.

board.php

search_result.php

위와 같이 코드를 'post'방식으로 변경해준다. 

 

추가적으로 쿼리문에 들어가는 변수 값들을 "mysqli_real_escape_string"함수를 통해 검증 해준다.

search_result.php

함수는 위와 같은 형식으로, 첫번째 인자에는 꼭 $conn 즉 커넥터 부분을 연결 시켜 주어야 한다.

동일한 쿼리문 입력 시, 이전과 다르게 ' 앞에 \(백슬래시)가 붙어서 출력된다.

따라서 해당 쿼리에서 "문자열"로 인식된다.

 

결과를 보여주는 페이지에서는

 

다음과 같이 "$search"를 그대로 보여주기 때문에, 아래와 같이 unescape 시켜준다.

: 그럼 결과로 보일 때는 이전과 동일하게 보이고, 내부에서 쿼리를 질의 할 때는 sql injection을 방어해준다.

 

 

2. 디렉터리 인덱싱

- files, admin ..등 디렉터리가 노출되고 있음.

 

대응방안 : 

- 웹 서버 혹은 웹 어플리케이션 서버에서 디렉토리 인덱싱 기능을 비활성화 시킨다.

 

"apache2"기준

etc/apache2에 존재하는 "apache2.conf" 파일을 확인해보면, "Indexes"기능이 활성화 되어 있음을 확인 할 수 있다.

아래와 같이 파일을 수정해준다.

저장 후, 아파치를 재실행 시켜준다.

명령어 : "service apache2 restart"

: 디렉터리를 url 에 입력 시 액세스 권한이 없다는 페이지가 뜸.

 

 

3. 정보 누출

3-1. 주요 정보 노출 (mypage.php)

mypage.php 페이지에서 2차 공격을 위한 중요한 정보를 제공하고 있다.

mypage를 확인해보면, 중요정보(비밀번호, 이메일 등)가 평문으로 노출되고 있다.

웹 상 소스 코드

또한 소스 코드를 확인해봐도, 노출이 되어있다.

mypage.php

코드는 아무런 필터링 혹은 마스킹 적용이 없이, 바로 출력되고 있으므로

이를 공격자가 확인한다면, 이로 인한 피해가 발생 할 수 있다.

 

3-2. 웹 서버 구성 정보 노출

페이지 에러 메세지(500,404,402..등) 로 인해 웹 페이지 서버 구성 정보 혹은 코멘트 등이 노출 될 수 있다.

공격자는 이를 통해 서버의 정보를 유출하여, 2차 공격으로 이어갈 수 있다.

 

대응방안 : 

- 중요정보는 마스킹을 적용하여 표시한다. 

소스코드를 다음과 같이 마스킹 처리하여 중요정보가 노출되지 않도록 대처한다.

 

- 에러 코드에 대해 별도의 에러 페이지로 Redirect 처리 시킨다.

apache2.conf 파일에 전역 설정에 다음과 같은 코드를 추가 시켜주어야 한다.

 

먼저 소스코드와 동일한 위치에 에러 코드 발생 시 이동할 페이지를 만들어 준다.

error.html

위와 같이 간단히 코드를 작성 후 apache2.conf파일로 이동한다

위치 : "etc/apache2 -> vi apache2.conf"

위와 같이 전역 설정에 추가한다. (어느 위치에 존재하여도 상관 없다.) 

현재 자신의 경로에서 error.html을 찾아주는 것이기 때문에 

403 에러와 같은 경우 -> 3.35.24.172/admin/으로 들어갈 경우 이 에러를 처리하지 못한다.

즉 디렉터리 같은 경우 해당 디렉터리 하위에도 error 코드를 적용 시켜주어야 한다.

 

최종적으로 아래와 같이 코드를 적용하였음:

apache2.conf 코드 & 403.html 

: 적용 후 페이지를 재시작 하여, 확인 후 아래와 같이 에러 페이지가 리다이렉트 됨

404 에러 페이지

403 에러 페이지

4. 악성 콘텐츠

- file upload 부분에서 확장자를 필터링 하지 않음. (f_write.php)

파일을 올리려고 하면 확장자를 검사하지 않는 것을 확인 할 수 있다.

f_write.php

위 서버 소스코드를 확인해보면, input type "file"은 아무런 필터를 거치지 않고 있다.

 

대응방안 : 

4-1. input file 타입 확장자 제한하기 (클라이언트 측)

f_write.php

input type "file"에 옵션 중 accept를 이용하여, 확장자를 1차로 제한한다.

확장자가 제한되지만, 이를 "burp suite"와 같은 porxy툴로 우회 할 수 있기 때문에, 서버 측에서도 필터링을 적용해주어야 한다.

 

 

4-2. Apache 환경설정에서 mine type 필터링을 설정한다.(서버측 대응)
: 원래 centos 와 같은 경우 apache를 사용하고 "httpd.conf" 파일에 아래와 같이 적용해 줄 수 있다고 한다.

하지만 ubuntu 의 경우 "httpd.conf" 파일이 아닌, "apache2.conf" 파일이 존재하며 위 옵션이 존재하지 않는다.

때문에 -> "etc -> mime.types" 파일에서 직접 수정하였다.

 

 게시판의 글 등록 및 파일 업로드 기능에 Flash 파일이나 avi 동영상파일, exe 실행파일 등 악성코드가 포함될 수 있는 콘텐츠를 업로드 하지 못하게 해당하는 확장자를 모두 지워준다.

mime.types파일에 avi 주석 처리

exe, bat 확장자 삭제

 

"MIME Type이란?"
MIME으로 인코딩한 파일은 Content-Type 정보를 가지고 있다.
MIME Type은 “파일종류/파일포맷” 형태를 가지고 파일 형식에 따라 구동 할 프로그램을 구분지을 수 있도록 해준다.

 

4-3. 최종적으로 파일을 검사하는 로직에 확장자 필터링을 추가한다.

 

파일을 업로드하는 페이지의 소스코드를 확인해보면 다음과 같다.

f_write_ok.php

파일의 이름과 파일의 시간을 받아온 후, 이중 확장자 " . ?? "부분을 "insert1" 을 통해 분리한다.

분리 후 해당 파일의 날짜 + 이름(확장자 제외) 을 md5로 해시화 해준 후 다시 확장자를 붙여서

업로드 하는 형식이다.

 

즉 , 시간 "20210524175153" 과 파일 이름"jvmopt.txt"가 있다고 가정한다면, .txt 를 제외한 나머지 "20210524175501jvmopt" 부분을 해시화 한 후, 

확장자를 붙여주고 최종적으로 아래와 같은 이름에 파일을 files 라는 디렉터리에 넣어주는 형식이다.

현재는 파일을 올리는 경우, 확장자를 검사하지 않고 있으므로 위 서버 소스 단에서 확장자를 "화이트 리스트 기반"으로 필터링 해준다

 

간단하게 다음과 같이 적용해주면 된다. (if 절 안에 정상적으로 파일을 업로드 하는 코드를 넣으면 됨)

해당 코드는 확장자를 "pdf, txt, word, docx, png, jpeg, jpg" 만 허용가능 하도록 제한하는 "화이트 리스트 방식 필터링"을 적용한 것이다.

코드를 적용하면 허용 확장자에 포함되지 않은 확장자를 올릴 시, 검증하여 이를 차단한다.

 

아래와 같이 정상적으로 허용된 확장자 파일을 올리면, 업로드가 성공한다.

 

전체 코드 : 빨간 네모 박스는 아래 기존 코드를 조건문 안에 넣어준 것이다.

 

: 위 대응방안은 "파일 업로드" 취약점에 대한 대응 방안이 되기도 한다.

 

 

 

5.  크로스사이트 스크립팅

5-1. write.php (글쓰기)

아래와 같이 게시판에서 글을 작성 시, 스크립트에 대한 필터를 거치지 않고 있다. 

때문에, 위와 같이 스크립트를 입력하면 적용되어 "alert"가 실행된다.

서버 코드 중 write.php 에서 form에 값을 write_ok.php 로 보내고 있다.

"write_ok.php" 소스코드를 확인해보면 다음과 같이 받아온 값을 그대로 DB에 insert하고 있다.

"stored xss"가 가능한 이유는 해당 스크립트가 일시적이 아니라, 데이터 베이스 안에 저장되어, 그 스크립트가 있는 글을 확인 할 때마다 발생하기 때문에 저장형인것이다. -> 즉 데이터 베이스에 들어가기 전 검증이 필요함.

 

 

 

5-2. read.php (댓글 쓰기) -> reply.php

댓글 또한 스크립트에 대한 필터링을 거치지 않고 있어서, 아래와 같이 쿼리문 입력 시 스크립트가 발생한다.

<img src=#  onerror =alert(1); />

소스코드를 확인해보면, read.php 에서 include를 통해 'reply.php'를 불러오고 있다.

'reply.php' 코드를 확인해보면, 아래와 같이 form 태그를 통해 'post'방식으로 reply_write.php로 댓글에 대한 비밀번호와, 내용을 보내준다. 즉 "reply_write.php"페이지에서 결국 데이터베이스로 값을 집어넣는 것이기 때문에

"reply_write.php" 소스에 XSS 대응 로직을 추가해주면 된다.

reply.php

 

해당 소스 코드를 보면 pw, content는 값을 저장하며, 아무런 필터링이 되어있지 않은 상태로 값을 데이터 베이스에 넣어,

화면에 출력해주기 때문에 "Stored Xss" 공격에 노출된다.

reply_write.php

 

 

5-3. join.php (회원 가입)

join.php 웹 페이지 소스 코드

해당 코드를 보면, maxlength의 값이 가장 긴 것이 Pw이다. 검증 로직이 없는 것으로 보아, xss 에 취약할 듯 하다.

저장된 pw 값은 회원정보 즉 "mypage.php"에 노출되기 때문에 'stored Xss' 이 발생한다.

위와 같이 아이디와 이름 , 이메일은 정상적인 상태로 적용하고 비밀번호를 <script>구문을 넣어 회원가입을 하면

mypage에 스크립트가 적용되어 alert 창이 뜨게 된다.

mypage.php

서버 소스코드를 확인하기 전, 데이터베이스에 저장되는 시점을 생각해보면 가입 후 join이라는 버튼을 누르는 동시에 값이 저장되는 것이다. 즉 "joinAction.php" 페이지에서 값을 검증하지 않기에 일어나는 취약점이다.

따라서 다음 중, id 와 pw, name  모두에서 입력 받는 값에 대한 검증이 필요하다.

 

 

5-4. search (검색) 

 

 

대응방안 : 

게시물의 본문뿐만 아니라 제목, 댓글, 검색어 입력 창, 그 외 사용자 측에서 넘어오는 값을 신뢰하는 모든 form과 

파라미터 값에 대해서 필터링을 수행해야 함.(서버 검증 필요)

특히 특수문자 혹은 스크립트 정의어 등을 "php 정의 함수"를 통해 공백 혹은 다른 문자로 치환한다.

:정의 함수

문자열을 다른 문자열로 교체할 때 쓰이는 함수로 str_replace()와 substr_replace()가 있다.
보통 단순히 문자열을 다른 문자열로 치환할 때는 str_replace()를 사용하고, 일정 규칙에 따라 교체하고 싶다면 substr_replace()를 사용한다.

따라서 str_replace()를 통해서 특정 문자 혹은 특수 문자 등을 필터링 해주면 된다.

"str_replace" -> (치환될 문자열, 치환할 문자열, 문자열, 몇개 치환 했는지 입력받음)

"substr_replace"(문자열,  치환할 문자열, 치환 시작 index, 규칙확인해야함)

5-1. 게시판 시큐어 코딩

다음 서버 소스와 같이 하나씩 일일이 필터를 걸어주었다.

write_ok.php

5-2. 댓글 시큐어 코딩

reply_write.php

pw에 대한 대응은 필요가 없다. 값을 삭제하는 로직에서만 필요하기 때문에 영향이 없으므로, content에 대한 필터만 걸어준다.

필터링 적용 이후, 같은 스크립트 문을 댓글로 작성해보면, 정상적으로 값이 막히는 것을 확인할 수 있다.

또한 시큐어 코딩 전 데이터베이스에 저장된 내용과 이후, 저장된 내용을 비교해보면 값이 다르게 저장된 것을 확인 할 수 있다.

5-3. 회원가입 시큐어 코딩

pw_ck는 DB에 저장되는 값이 아니므로 검증하지 않았다. id 와 email 같은 경우 DB 에 저장시 글자 수를 제한하고 있기 때문에, 공격코드가 들어오면 이를 거부한다. -> 길이제한 필터링.

또한 input type 에서 email을 입력 시  javascript로 클라이언트 단에서 처리해주기 때문에 따로 검증하지 않았다. (서버에서 검증해주는 것이 가장 좋은 방법임, 길이에 대한 제한이 걸려있어서 따로 검증하지 않은 것)

 

시큐어 코딩 후, 데이터베이스에 저장된 회원 값을 비교해보면 다음과 같이 필터가 적용되는 것을 알 수 있다.

 

결과 :

필터링 전 & 후

특수 문자 및 스크립트를 실행 시킬 수 있는 위험 요소가 있는 태그 등 모두 문자를 치환해주거나 엔티티코드로 바꾸어 준다

: 결과는 스크립트문을 입력하여도 실행되지 않고 문자열 자체로 인식함._

 

 

5-4. 검색창 시큐어 코딩

 

검색창은 위에서 sql injection 을 시큐어 코딩 하였기 때문에 기초적인 특수문자 등은 방지하고 있다.

하지만 이외에 이벤트 함수나 코드를 우회한 공격이 가능할 수 있기 때문에 다음과 같이 추가로 필터링 한다.

결과 :



수정 전 코드에선 발생하던 XSS가 실행되지 않는다.

즉, 스크립트를 실행시키지 않고 문자열 자체로 받아들인다.

 

해당 취약점은 

Reflected(반사형) XSS는 URL, URL 파라미터, Cookie 파라미터등 사용자가 입력한 내용에 대해서 응답 페이지에 실행되는 취약점을 의미한다.

결국 사용자가 입력한 특정 내용에 대해서 해당 웹 페이지 화면에 출력 되는 형태의 취약점이다. 

 

이전 5-1 ~ 5.3 까지는 Stored XSS형태로 DB 안에 저장된 값을 확인 할 수 있었지만, 반사형 취약점(Reflected XSS)는 저장되지 않고

해당 url을 통해 실행된다.

 

 

XSS의 방안은 이외에도 다양하게 존재한다.

1. http only 속성 이용하기
: 보통 XSS의 목적은 쿠키를 스니핑 하여, 다른 사람의 권한을 획득하거나 탈취하는 등의 목적성을 가진다. 때문에 header 옵션 중 httponly 속성을 활성화 시켜 다음과 같이 xss를 방지한다.
(해당 속성을 적용하면 쿠키 값을 하이재킹 할 수 없게 된다.)

출처 : http://i-bada.blogspot.com/2013/01/9.html

2. cookie.setsecure이용하기
SSL 통신 채널 연결 시에만 쿠키를 전송하도록 설정해주는 쿠키의 속성이다.
이 설정 역시 Set-Cookie 응답 헤더에서 설정한다. 
클라이언트의 환경(웹 브라우저)에서 HTTPS(SSL/TLS) 통신일 때만 쿠키를 전송하는 방식이다.
HTTP를 이용한다면 쿠키를 전송하지 않는다.
즉, 평문으로 쿠키를 전송하지 않기 때문에 기밀성이 보장되는 방법이다.

3. 안티 라이브러리 (AntiXSS) 사용

4. CSP (콘텐트 보안 정책) 사용
이외에도 아래 주소를 통해 자세히 살펴보면 좋을 것 같다.
1. https://www.kisa.or.kr/uploadfile/201312/201312161355109566.pdf -> XSS대응방안 및 공격개요
2. CSP 란? SOP(Same-Origin Policy)와 CORS(Cross-Origin Resource Sharing)
->
https://core-research-team.github.io/2021-05-01/Easy-to-understand-Web-security-model-stroy-2(CSP)#3-set-cookie-httponly

위 사이트 둘다 너무 정리가 잘되있어서 꼭 참고해보세요

6.  약한 문자열 강도 

login.php 페이지에는 임계치가 설정되지 않아서, 횟수에 대한 제한이 없다.

 

또한 admin과 같은 관리자 계정에 대한 보안이 매우 취약하기 때문에, 이를 깨기가 간단하다.

- 무차별 대입 공격 (Brute-force attack)