Information Security Consultant Develop

웹 해킹 기본

LGMsecurity — Wed, 7 Jan 2026 22:38:40 +0900

1. 웹 통신 기초

1-1. 클라이언트 서버 구조

웹 클라이언트는 웹 서버에 페이지를 요청하고, 서버가 응답한 결과를 화면에 출력한다. 쉽게 말해서 요청하는 것이 클라이언트이다. 클라이언트는 브라우저(웹 애플리케이션)라고도 부른다. 웹 서버는 클라이언트로부터 요청을 받은 페이지를 찾아서 CGI를 해석하거나 수행하고, 그 결과를 html,javascript,css 등을 클라이언트에게 전송한다. 여기서도 쉽게 말해서 요청을 받아 응답을 클라이언트에게 보내는 걸 서버라고말한다.

❓ 웹에서 서버와 클라이언트 관계

- 웹에서 클라이언트는 서버에게 요청을 보내고, 서버는 그 요청을 받아 응답을 보낸다.

CGI(Common Gateway Interface: 공통 게이트웨이 인터페이스로 웹 서버와 프로그램을 연결해주는 규칙이다.

1-2. HTTP 프로토콜 이해

HTTP(Hyper Text Transfer Protocol)는 클라이언트와 서버 간에 데이터를 주고받기 위한 프로토콜로 기본적으로 데이터를 평문으로 전송하며, 이후 이미지·파일·JSON 등 다양한 데이터 형태를 주고받을 수 있도록 발전하였고, HTTP 프로토콜을 이용해 파일을 주고 받는 서버는 요청과 응답 구조로 동작하며, 서버와 클라이언트의 연결 상태를 유지하지 않는 stateless한 프로토콜이여서 서로의 연결 상태를 기억하지 않지만, 이를 보완하기 위해 쿠키와 세션을 사용해 상태를 유지한다.

❓ HTTP와 HTTPS의 차이점

- HTTP는 80번 포트를 사용하며, 데이터를 평문으로 전송하지만 HTTPS는 443번 포트를 사용하고 HTTP에 SSL을 적용해 암호화하여 전송한다.

하이퍼링크를 포함한 텍스트

JSON : HTTP 통신에서 요청과 응답 바디에 포함되어 데이터를 구조적으로 표현하는 데 사용되는 경량 데이터 포맷

1-3. HTTP 요청(Request)구조

✅ 요청 메소드 : 서버에 어떤 방식으로 자원을 처리할지 알려주는 역할(요청 방식)

✅ GET,POST,HEAD,OPTIONS,PUT 등이 있음

✅ 자원(Resource): URL로 식별 가능한 모든 대상으로 정적인 파일뿐만 아니라 사용자, 게시글과 같은 논리적인 데이터까지 포함

✅ ?직전까지나 파일 경로까지는 URL(자원 위치), 전체는 URI(자원 식별자)

✅ 요청 헤더: 키와 값 방식

✅ Host : 호스트 주소(IP 혹은 도메인)

✅ Accept: 클라이언트가 받을 수 있는 컨텐츠

✅ user-agent: 요청을 보낸 클라이언트의 브라우저 및 실행 환경 정보

✅ cookie: 쿠키

✅ 요청 바디(엔터티) : 기타 정보 전달

HTTP여도 포트번호가 다르면 도메인 뒤에 포트번호 붙여야됨(예:8080)

%20은 공백 - URL은 공백이 있으면 짤림

#(태그)은 현재 페이지에서의 특정 위치 - 목차가 있는 경우 보통 #이 붙음

&는 파라미터가 한개 이상

파라미터가 URL에 보이는 경우 GET 요청 방식

요청 메소드
GET	- 자원을 요청할 때 사용하는 메소드 - 서버의 자원을 조회(요청)하는 용도로 사용 - 요청 메시지에 Body가 없음 - 응답하는 Body가 존재하며 요청한 데이터를 전달 받음 - 요청 데이터가 URL 파라미터로 노출됨 - 서버의 데이터를 변경하지 않음 - 암호화 통신을 해도 GET 요청을 보임
POST	- 서버에 데이터를 전달하고 처리를 요청하는 메소드 - 요청 Body의 엔터티(Entity)를 자원으로 전달함 - 요청과 응답 모두 Body를 가질 수 있음 - 서버에 데이터 저장 또는 처리를 요청할 때 사용 - URL에 데이터가 노출되지 않고 Body에 포함 - 서버의 상태나 데이터를 변경할 수 있음 - 요청 바디에 데이터를 넣었을 때 파라미터 값이 안보임 - 파일 업로드할 때 사용
HEAD	- 서버의 응답 헤더 정보만 요청하는 메소드 - 요청과 응답 모두 Body가 없음 - 응답에서 Header만 전달 - 서버 측 데이터의 존재 여부 및 메타 정보를 확인 - 실제 데이터(Body)는 전송되지 않음 - 리소스 크기, 수정 여부 등을 사전 확인할 때 사용됨
OPTIONS	- 서버에서 지원하는 HTTP 메소드를 확인하는 메소드 - 서버가 어떤 HTTP 메소드를 지원하는지 확인 - 요청 Body는 선택사항 - 응답에는 Body가 포함될 수 있음 - Allow 헤더를 통해 허용된 메소드 목록을 제공
PUT	- 자원의 전체를 수정하는 메소드 - 서버의 자원을 전체 수정(덮어쓰기) 함 - 요청과 응답 모두 Body를 가질 수 있음 - 전달된 데이터로 자원을 완전히 대체 - 서버의 데이터를 직접 변경 - 잘못 사용될 경우 보안 취약점이 발생할 수 있음(제일 취약)

1-4 . HTTP 응답(Response) 구조

✅ Body는 데이터가 들어감

✅ 응답 헤더

- date: 통신한 날짜

- server : 서버 애플리이션

- content-type : 바디 데이터의 유형

- content-length : 바디 데이터의 크기

- 예) <html>

<head>

...

✅ 서버가 응답하는 데이터를 추가적으로 설명하는 데이터를 헤더

✅ 데이터의 데이터를 메타데이터(대표적으로 헤더)

✅ 응답 라인: 버전, 상태 코드, 상태 메시지(예: http/1.1 200 ok - 응답 코드)

✍️1xx - Informational : 요청이 수신되어 처리중

✍️2xx - Success : 요청 성공, 요청을 받았는데 요청이 이상없고 잘 응답했다는 코드

- 200(OK) : 잘 응답한거면 200이 응답코드에 뜸

✍️3xx - Redirection(방향 바꿈) : 요청은 잘 받아서 해석했는데 너가 원하는 응답은 다른곳에 있어

- 301(Moved Permanently) : 요구한 데이터는 변경된 URL에서 찾음(서버에 요청을 했는데 요구한 응답이 다른 서버에 있음), 영구적으로 이동(영구 리다이렉션)

- 302(Found): 다른 URL이 있음, 웹 사이트에 잘 방문함, 일시 리다이렉션

✍️4xx - Client Error : 클라이언트 오류, 요청에 문제가 있음

- 403(Forbidden) : 요청 거부, 요청은 알아들었지만 응답은 안함(접근 권한이 불충분), 정상적인 페이지에 안 들어가지면 아이피 차단됨

- 404(Not Found) : 리소스가 없는 상태, 못 찾겠다!, 에러가 뜨는 가장 큰 이유는 오타일 수 있음, 요청은 잘 알아들었지만 내 서버에서 자원을 찾는 과정에서 자원이 없다(디렉터리가 없다)

✍️5xx - Server Error : 서버 오류, 응답에 오류가 있음

- 500(Internal Server Error) : 서버가 요청을 처리 못하고 서버안에서 에러가 난거임, 에러메시지가 뜨면 더 취약하고 에러가 나면 공격자 입장에선 너무 좋다.

- 503(Service Unavailable) : 서비스가 불가능한 상태이며 서비스 구축과정에서 일어남, 서버가 내려가거나 종료 또는 재시작할때 뜰 수 있음

1-5. Web Server와 Web Application Server의 차이점

웹 서버는 정적인 콘텐츠를 제공하고, 웹 애플리케이션 서버는 연산과 데이터베이스 연동을 통해 사용자 별로 다른 동적 콘텐츠를 제공한다. 웹 서버 같은 경우는 아파치나 엔진엑스등이 있고, 웹 애플리케이션 서버는 톰켓이 있다.

Web APPlication Server(Tomcat,WebLogic) : 정적,동적 다함, 연산을 해야됨, 데이터베이스랑 연동하고 동적은 누가 들어오는지에 따라서 페이지가 다르다. 또한 로그인 페이지나 회원가입이 있으면 무조건 데이터베이스랑 연동되어있다.

- 서버가 요청받고 계산해서 결과 생성 > 동적-예: board.php, 서버 입장에서 PHP를 실행하고 DB조회

Web Server(Apache,NGinx) : 정적인 콘텐츠, 누가 들어오든 똑같은 페이지, 서버가 그냥 파일 전달(정적-예: index.html)

※ DB 연동은 이론적으로 웹 서버에서도 가능하지만(소규모일경우), 거의 WAS에서 담당함

구조 : [Client] [Web Server-정적파일, 프록시 서버역할] [WAS-비즈니스 로직, DB 연동] [DB]

1-6. 클라이언트 언어(HTML, Javascript, CSS)

- 사용자의 브라우저가 처리하는 언어

- 사용자와 서버 간의 인터페이스로 동작

- 사용자와 서버 사이 대화형 웹 페이지 제공

- 서버 요청을 보내고 데이터를 가져옴

- HTML : 브라우저에 의해 해석되어 구조를 만드는 언어

- Javascript : 연산이 없는 HTML을 대신 연산을 수행하는 동적 행위를 하는 언어

- CSS: 디자인용, HTML을 아름답게 표현하는데 사용
- 클라이언트 측 언어는 클라이언트에서 보임(브라우저)

- 서버측 언어의 결과가 브라우저에 보여짐
- 서버측 언어는 클라이언트에 안보임

- 브라우저가 해석하고 화면에 표시

1-7. 서버측 언어(PHP,ASP.net,JSP,Python)

- 서버에서 동작하는 언어
- 사용자의 입력(파라미터) 처리
- 요청한 페이지를 전달
- 데이터베이스와 상호작용
- 처리된 데이터를 사용자 측 언어로 변환(클라이언트 언어)
- 사용자에게 연산하는 과정은 보이지 않음

- 결과를 클라이언트 언어로 줌

2. 인코딩(Encoding)

정보의 형태나 형식을 변환하는 처리 방식이며, 암호화와는 다르다. 이유는 암호화는 보안을 위해 데이터를 숨기는 것이고, 인코딩은 데이터를 전송이나 저장하기 위한 형식으로 변환하는 과정이다. 데이터의 길이를 줄이는 용도로 사용되고 기본 인증에도 사용된다.

○ 문자형 인코딩

- 문자를 컴퓨터가 이해할 수 있는 0과 1형태로 변환

- EBCDIC, ASCII, Unicode

○ 오디오형 인코딩

- 음성이나 음악 데이터를 디지털 신호로 변환

- MP3, WAV

○ 웹 관련 인코딩

- 웹 환경에서 데이터를 안전하게 전달하기 위해 사용

- URL 인코딩, Base64 인코딩

3. URL 인코딩 - 웹만 있음

특정 문자나 구분자 기호인 % 뒤에 16진수 값을 붙여서 URL에 표현하는 방식이며 문자를 안전하게 웹 서버에 전달한다. 즉 특수한 기능을 가진 문자인 메타문자를 브라우저가 인코딩하여 전달한다.

예) 공백 > %20

& > %26

https://example.com/search?q=hello world

아래가 URL 인코딩 됨

https://example.com/search?q=hello%20world

4. Base64 인코딩

64개의 문자(A-Z, a-z, 0-9, +, /)로 데이터를 표현하며, 바이너리 데이터를 텍스트로 안전하게 전달한다.

예) Hello > Base64 인코딩 > SGVsbG8=

- =은 패딩이고 6비트 단위를 맞추기 위해 사용됨

※ 디코딩(Decoding) : 변환된 데이터를 원래 값으로 되돌려줌

5. 쿠키와 세션

우선 쿠키와 세션이 등장하게된 배경은 HTTP 서버와 클라이언트의 연결 상태를 유지하지 못하는 stateless 프로토콜이어서 로그인 등 상태 유지를 위해 쿠키가 등장했지만, 클라이언트에 데이터를 저장하는 보안 문제를 해결하기 위해 세션이 등장하여 서버에 데이터를 저장하고 클라이언트에는 세션 ID만 전달하도록 발전하였다.

쿠키

- 쿠키는 상태를 유지함(stateful) 서비스를 지원하기 위해서 고객에게 상태가 유지되게 보이게 함

- 상태를 유지함(stateful), 서버가 클라이언트의 상태를 보존

- 웹 서비스에 방문할 때 마다 수시로 정보가 변경될 수 있음

- 웹 서버가 클라이언트 컴퓨터에 저장하는 작은 기록 정보
- 요청을 보낼때마다 쿠키정보가 전송됨

- 단점 : 많은 트래픽 발생, 쿠키 유출에 따른 보안 문제

세션

- 쿠키의 문제와 보안적 이슈(쿠키가 클라이언트에 저장되기 떄문에)를 해결하기 위해 등장

- 서버 데이터베이스에 정보를 저장

- 클라이언트는 쿠키로 전달 받아 메모리에 저장

- 단점 사용자 방문이 많은 서버의 경우 데이터베이스를 이용하기에 많은 비용 발생

- 세션 ID(서버와 클라이언트를 연결하는 열쇠)는 브라우저에 쿠키형태로 저장됨 > 클라이언트가 요청할 때마다 세션ID를 보내야 서버가 클라이언트의 세션 데이터를 찾아서 응답하기 때문이다. 쉽게 말해 “클라이언트가 세션 ID를 보내야 서버가 해당 세션 데이터와 연결해서 응답을 줄 수 있다”

- 서버는 상태를 유지하지 않기때문에 요청마다 클라이언트가 자기 ID를 보내야됨

※ 쿠키는 클라이언트에 저장되고 세션은 서버에 저장된다.

Web 취약점 진단 - 취약한 패스워드 복구

LGMsecurity — Sun, 4 Jan 2026 16:43:04 +0900

1. 취약한 패스워드 복구(PR)

2. 취약점 개요

패스워드 복구(비밀번호 찾기/재설정) 기능의 설계 또는 구현이 취약할 경우, 공격자는 이를 악용해 다른 사용자의 패스워드를 불법적으로 획득하거나 임의로 변경할 수 있다. 특히 사용자 식별 검증이 불충분하거나, 예측 가능한 인증 정보만으로 패스워드 재설정이 가능한 경우 계정 탈취(Account Takeover)로 이어질 위험이 존재하는 취약점이다.

3. 점검 결과

1) 패스워드 재설정 시 현재 비밀번호가 입력되는지 확인

2) 재설정된 패스워드를 인증된 사용자 메일이나 SMS로 전송하는지 확인

재설정된 패스워드를 전송하지 않고 변경 가능

※ 패스워드 복구 및 재설정 과정이 안전하게 설계되었는지 확인하는 점검

✅ 패스워드를 평문으로 전송하는 경우, 중간 탈취 및 오발송 등의 위험이 존재

✅ 판단 기준은 변경된 패스워드가 평문으로 전송되면 취약하고, 사용자가 직접 새 패스워드를 설정, 전송이 없다면 양호

✅ 양호인 경우는 로그인된 사용자만 접근 가능, 현재 비밀번호 입력 요구, 세션 검증 정상으로 판단

4. 권고사항

1) 사용자의 개인정보(연락처, 주소, 메일 주소 등)를 이용하여 패스워드를 생성하지 말아야 하며, 난수를 이용한 불규칙적이고 패턴이 없는 패스워드를 최소 길이(6자 이상 권고) 이상으로 발급하도록 하여야 함

2) 사용자 패스워드를 발급하거나 확인할 경우 웹사이트 화면에 즉시 출력하지 말고, 인증된 사용자 이메일 또는 SMS로 전송하도록 하여야 함

3) 패스워드 재발급 검증 실패에 대한 임계값을 설정하여 일정 횟수 이상 실패한 경우에는 다른 방식의 패스워드 찾기 기능을 제공하도록 하고, 검증 후 기존 패스워드가 아닌 임시 패스워드를 발급하도록 설계하며, 사용자가 임시 패스워드를 발급받은 즉시 새로운 패스워드로 재설정하도록 구현하여야 함

Web 취약점 진단 - 불충분한 인증

LGMsecurity — Sun, 4 Jan 2026 16:03:18 +0900

1. 불충분한 인증(IA)

2. 취약점 개요

불충분한 인증은 중요정보(개인정보 변경, 계정 설정, 결제 정보 등)를 처리하는 페이지에 대해 인증 절차가 충분히 적용되지 않을 경우, 권한이 없는 사용자가 해당 페이지에 접근할 수 있는 취약점을 말하며, 이로 인해서 공격자는 정상적인 인증 과정 없이 중요정보 페이지에 직접 접근해 개인정보를 열람하거나 임의로 조작이 가능하다. 특히나 URL 직접 접근, 세션 검증 미흡, 추가 인증 절차 누락 등의 경우 해당 취약점이 쉽게 발생한다.

※ 이 취약점은 OWASP Top 10에 Broken Access control에 해당됨

3. 점검 결과

1) 중요정보(개인정보 변경 등) 페이지 접근 시 재인증 여부 확인

재인증을 하지 않는 페이지

4. 권고사항

1) 중요정보(예: 개인정보 변경 등)를 표시하거나 수정하는 페이지에서는 사용자의 본인 인증을 재확인하는 로직을 구현하여야 함

2) 사용자가 인증 후 접근 가능한 모든 페이지에 대해, 승인된 사용자인지를 페이지마다 검증하여야 함

3) 접근통제 정책을 구현하는 코드는 구조화·모듈화하여 관리되어야 함

4) 접근제어가 필요한 모든 페이지에 로그인 체크 및 권한 체크 등 통제 수단을 적용해야하며 특히, 하나의 프로세스가 여러 개의 페이지나 모듈로 구성되어 있는 경우, 권한 검증 누락을 방지하기 위해 공통 모듈을 사용하도록 권장함

5) 인증 및 접근제어 로직을 Client Side Script(Javascript, VBScript 등)를 사용하면 사용자가 임의로 수정할 수 있으므로, 반드시 Server Side Script(PHP,ASP,JSP 등)에서 인증 및 필터링 과정을 수행하도록 구현해야 함

Linux 서버 점검 - root 계정 원격접속 제한

LGMsecurity — Tue, 30 Dec 2025 19:09:26 +0900

1. root 계정 원격접속 제한(U-01)

2. 취약점 개요

root 계정은 시스템의 모든 자원과 기능을 관리할 수 있는 최고 권한 계정으로, root 계정의 원격 접속 제한이 미흡할 경우 무차별 대입 및 사전대입 공격에 의해 계정 탈취 위험이 증가하고, 시스템 장악 및 서비스 중단 등 심각한 보안 사고로 이어질 수 있다. 따라서 root 계정의 원격 접속을 제한하고, 일반 계정을 통한 접속 후 권한 상승(su,sudo) 방식으로 관리하도록 보안 설정을 적용하는 등 주주의가 필요하다.

3. 점검 스크립트

=========================================================

#!/bin/bash

SSH_CONFIG="/etc/ssh/sshd_config" SSH 데몬의 동작 방식을 정의하는 핵심 파일이며, root 계정 원격 접속 차단 여부를 확인하려면 파일 점검 필수

echo "[점검] SSH 설정 파일: $SSH_CONFIG"

if [ ! -f "$SSH_CONFIG" ]; then 설정 파일 존재 여부 확인

echo "[결과] [취약] SSH 설정 파일을 찾을 수 없습니다. 경로: $SSH_CONFIG" 점검 대상 파일이 없으면 취

else

LINE=$(grep-iE'^[[:space:]]*PermitRootLogin[[:space:]]+' "$SSH_CONFIG" 2>/dev/null | tail -n 1)

if [ -z "$LINE" ]; then

echo " [결과] [취약] PermitRootLogin 값이 명시되어 있지 않습니다." 명시되어 있지 않으면 root 원격 접속이 허용

echo " -보안을 위해 다음과 같이 설정하는 것을 권장합니다."

echo " PermitRootLogin no" root 계정의 직접 원격 로그인 차단

else

VALUE=$(echo "$LINE" | awk '{print tolower($2)}')

echo "[정보] 현재 설정 라인: $LINE"

case "$VALUE" in

no)

echo "[결과] [양호] SSH 원격 접속 시 root 계정의 직접 로그인이 차단되어 있습니다. (PermitRootLogin no)"

;;

yes|without-password|prohibit-password|forced-commands-only) root 접속 허용 또는 부분 허용이라 취약, 직접 로그인 자체를 차단해야됨

echo "[결과] [취약] SSH 원격 접속 시 root 계정의 직접 로그인이 허용 또는 부분 허용 상태입니다. (PermitRootLogin $VALUE)"

echo " -$SSH_CONFIG 파일에서 다음과 같이 설정하십시오."

echo " PermitRootLogin no"

;;

echo " [결과] [주의] 알 수 없는 PermitRootLogin 값입니다: $VALUE"

echo " -root 원격 로그인을 완전히 차단하려면 다음과 같이 설정하십시오."

echo " PermitRootLogin no"

;;

esac

echo "[U-01] 점검 완료"

echo

=========================================================

※ SSH 데몬이 root 계정의 로그인 요청을 허용하지 않도록 설정하는 것이 핵심

SSH 데몬이 root 계정의 로그인 요청을 받을지 말지 결정하는 정책이기 때문에 ssh_config 파일 점검이 필요함

/etc/ssh/ssh_config 파일을 점검하는 이유가 SSH 데몬(sshd)이 어떤 보안 정책으로 동작하는지 확인하기 위해 점검

root 계정이 존재하거나 비밀번호가 있어도 PermitRootLogin no 가 설정되어 있으면 sshd가 root 로그인 요청 자체를 거부

4. 점검 결과

점걸 결과====================================================

[점검] SSH 설정 파일: /etc/ssh/sshd_config

[정보] 현재 설정 라인: PermitRootLogin yes

[결과] [취약] SSH 원격 접속 시 root 계정의 직접 로그인이 허용 또는 부분 허용 상태입니다. (PermitRootLogin yes)

-/etc/ssh/sshd_config 파일에서 다음과 같이 설정하십시오.

PermitRootLogin no

[U-01] 점검 완료

==========================================================

Web 취약점 진단 - 크로스사이트 스크립팅

LGMsecurity — Tue, 30 Dec 2025 19:05:36 +0900

1. 크로스사이트 스크립팅(XS)

2. 취약점 개요

크로스사이트 스크립팅은 악성 스크립트를 웹 페이지에 삽입하여, 사용자가 해당 페이지를 열람할 경우 브라우저에서 실행되는 취약점을 말한다. 이를 이용해 공격자는 세션이나 쿠키 탈취나 악성 사이트로 리다이렉트가 발생할 수 있다.

3. 진단 결과

1) 사용자 입력 값을 전달받는 애플리케이션(회원정보 변경, 게시판, 댓글, 자료실 등)에 스크립트 입력 후 실행되는지 확인

First name : <script>alert(document.cookie)</script>

Last name : <h1>hacked is leegyumin</h1>

※ document.cookie는 브라우저에 저장 쿠키정보를 말함 - 악성 스크립트로 쿠키정보를 탈취하기 위한 시나리오

스크립트 삽입

2) 게시판 페이지를 포함한 웹 인터페이스에서 사용자 의도와 무관하게 악성 프로그램이 강제 다운로드되거나 자동 실행되거나, 사용자를 악성 사이트로 리다이렉트하는 행위가 발생하는지 확인

XSS 공격 성공

악성 사이트로 리다이렉트된 결과

4. 권고사항

1) 웹 사이트 내 사용자 입력값이 저장 및 출력되는 모든 페이지에서 스크립트 실행에 악용될 수 있는 태그 및 특수문자 사용을 사전에 차단해야 함

2) 게시판, 댓글, 검색, 회원정보 변경, URL 파라미터 등 모든 사용자 입력 폼과 파라미터에 대해 신뢰하지 않고 필터링 로직을 일관되게 적용해야 함

3) 입력값 검증 시 서버 측에서 반드시 공백 제거(trim), 문자열 치환(replace) 함수를 사용해 불필요한 공백 및 위험 문자를 제거

4) URL 인코딩 우회 공격을 방지하기 위해, 서버 측에서 URLDecoder 클래스의 decode 메소드를 활용해 인코딩된 입력값을 정상적으로 디코딩한 후 필터링을 수행해야 됨

5) 웹 방화벽 룰셋어 모든 사용자 입력 폼을 대상으로 스크립트 태그 및 특수문자에 대한 필터링 규칙을 적용해 자동 차단 및 탐지를 강화 함

6) 상세 오류 정보의 일반화 및 외부 노출을 차단해야 함

◎ 필터링 조치 대상 입력 값

스크립터 정의어 : <SCRIPT>, <OBJECT>, <APPLET>, <EMBED>, <FORM>, <IFRAME>등

특수문자 : <, >, ", ', &, %, %00 (null 문자) 등

Web 취약점 진단 - 약한 문자열 강도

LGMsecurity — Tue, 30 Dec 2025 19:03:09 +0900

1. 약한 문자열 강도(BF)

2. 취약점 개요

약한 문자열(패스워드) 강도 취약점은 웹 사이트에서 복잡도 검증이 미흡한 패스워드를 허용할 경우 발생하는 취약점을 말하며, 공격자는 추측 가능하거나 주변 정보를 기반으로 생성한 사전 파일을 이용해 무차별 대입(Brute Force)나 사전 공격(Dictionary Attack)을 수행하여 사용자 계정을 탈취할 수 있는 취약점이다. 탈취한 계정을 통해서 개인정보 유출, 권한 오남용, 추가적인 내부 시스템 공격 등으로 2차 피해로 확산될 수 있다.

※ 사전 공격(Dictionary Attack) : 사전 공격은 가능성 높은 문자열을 파일로 만들어 아이디나 패스워드를 대입 시도하는 공격 기법

무차별 대입 공격은 가능한 모든 문자열 조합을 순차적으로 생성하여 대입하는 방식이고 사전 공격은 사용 가능성이 높은 문자열을 미리 만들어 대입한다.

무차별 대입	사전 공격
공격 중	공격 전
모든 조합	가능성 높은 값
현실성 낮음	현실성 높음

무차별 대입 공격은 모든 문자열 조합을 실시간으로 생성, 사전 공격은 공격 전에 미리 준비해 대

크리덴셜 스터핑(Credential Stuffing) : 크리덴셜 스터핑은 과거에 유출된 정보를 이용해, 동일한 자격 증명을 여러 웹 사이트나 서비스에 자동으로 대입하여 계정 탈취를 시도하는 공격

3. 진단 결과

1) 웹 사이트 로그인 페이지의 로그인 창에 추측 가능한 계정이나 패스워드를 입력하여 정상적으로 로그인되는지 확인

취약한 계정: admin, administrator, manager, guest, test, scott, tomcat, root, user, operator, anonymous 등• 취약한 패스워드: Abcd, aaaa, 1234, 1111, test, password, public, blank 패스워드, ID와 동일한 패스워드 등

2) 일정 횟수(3~5회) 이상 인증 실패 시 로그인을 제한하는지 확인

로그인 제한이 없음

4. 권고사항

1) 시스템 내 존재하는 취약 계정 및 약한 비밀번호를 식별·삭제하고, 사용자가 취약한 비밀번호를 신규로 등록하지 못하도록 비밀번호 정책을 강화하여야 함

2) 강화된 비밀번호 규칙이 반영된 검증 로직을 회원가입, 정보변경, 비밀번호 변경 등 관련 기능 페이지에 모두 적용하여야 함

Web 취약점 진단 - 악성 콘텐츠

LGMsecurity — Tue, 30 Dec 2025 19:00:40 +0900

1. 악성 콘텐츠(CS)

2. 취약점 개요

악성 콘텐츠 취약점은 사용자 입력이 허용되는 게시판이나 댓글 등의 기능에서 입력값 및 업로드 검증 미흡으로 악성 스크립트나 파일이 삽입되거나 실행되어, 페이지 열람만으로도 악성코드 감염, 세션 탈취, 피싱, 웹 변조 등 심각한 보안 위협을 유발시키는 취약점이다.

3. 진단 결과

시나리오 : XSS(악성 콘텐츠 삽입)를 이용한 CSRF 연계 공격 점검

※ XSS는 브라우저에서 실행되어 페이지나 콘텐츠가 변경되는 취약점이고 CSRF는 서버에서 사용자 권한으로 상태(데이터)가 변경되는 취약점이다.

- 콘텐츠(Content) : 웹 페이지에서 사용자에게 보여지거나 브라우저가 해석 또는 실행하는 모든 요소를 말함

- XSS를 이용한 CSRF 공격으로 서버도 변조할 수 있음

- 쉽게 말해 XSS은 화면에서 사고가 나고 CSRF는 서버에서 사고남

1) 비밀번호 변경에 필요한 변수명 확인

사용되는 변수명 확인

2) GET 방식 파라미터 노출 확인

3) 데이터 수정 페이지에 비밀번호 변경용 악성 스크립트를 삽입한 뒤 다른 사용자가 해당 게시글을 열람하면 스크립트가 실행되는지 확인

삽입한 악성 스크립트

악성 스크립트 삽입

게시글 열람 시 비밀번호 변조 확인

4. 권고사항

1) 악성 콘텐츠가 삽입된 페이지에 대해 화면 캡처, 소스 코드 등 증거 자료를 확보하고 보존해야 함

2) 삽입된 악성 콘텐츠를 즉시 삭제하거나, 해당 페이지 전체를 삭제 또는 접근 불가 상태로 전환해야 함

3) 확보된 증거 자료를 기반으로 악성 콘텐츠의 삽입 원인을 철저히 분석하고, 근본적인 취약점을 파악하여 원인을 제거할 것을 권고함

4) 게시판의 글 등록 및 파일 업로드 기능 이용 시 Flash, AVI, EXE 등 악성코드가 포함될 수 있는 특정 확장자의 콘텐츠 삽입 및 업로드를 금지하는 필터링을 적용해야함

5) 주기적으로 웹 서버에 업로드된 파일을 대상으로 바이러스 검사를 실시하여 잠재적인 악성 콘텐츠를 탐지하고 제거함

Web 취약점 진단 - 정보 누출

LGMsecurity — Tue, 30 Dec 2025 18:57:34 +0900

1. 정보 누출(IL)

2. 취약점 개요

정보 누출(Information Disclosure) 취약점은 웹 애플리케이션 또는 서버 환경 설정의 미비로 인해, 인가되지 않는 사용자에게 불필요하거나 민감한 정보가 노출되는 보안 결함이다. 정보로는 소스 코드 일부, 설정 파일, 에러 메시지, 계정 정보, 내부 IP 주소 등 다양한 내부 정보가 포함된다. 이 정보들은 공격자에게 시스템 구조를 파악할 수 있는 정보를 제공하며, 이후 권한 상승이나 내부 시스템 침투 등 2차 공격의 핵심 자료로 악용될 수 있다.

3. 진단 결과

1) 웹 사이트에 중요정보가 평문으로 노출되고 있는지 확인

중요정보 평문 노출

2) 웹페이지에 마스킹 된 중요정보가 웹페이지 소스에 평문으로 노출되고 있는지 확인

중요정보가 소스에 평문으로 노출되고 있는지 확인

3) 에러 메시지에 내부 경로 및 데이터베이스 오류 코드가 노출되는지 확인

에러 메시지에 내부 경로 오류 코드 노출

4. 권고사항

1) 개인정보 조회, 출력, 입력 시 정보를 일부 마스킹하여 비인가자의 정보 탈취 위험 및 주변 노출 위험을 최소화 함

◎ 개인정보에 마스킹 적용 예시

1-1) 성명 중 이름의 가운데 글자(이*민)

1-2) 생년월일(****년 **월 **일)

1-3) 전화번호 또는 휴대전화번호(010-****-1234)

1-4) 주소의 읍/면/동(서울시 강남구 **동)

1-5) IPv4 주소의 경우 17~24bit, IPv6 주소의 경우 113~128bit

2) 중요정보는 HTML 소스에 포함하지 않고 서버 측에서 안전하게 처리

3) 웹페이지 운영 서버 이관 시 주석을 모두 제거

4) 모든 에러 코드에 대해 별도의 에러 페이지로 Redirect 하거나 적절한 에러 처리 루틴을 설정하여 처리되도록 함

5) 특정 정보를 식별할 수 없는 통합된 메시지를 반환

Web 취약점 진단 - 디렉터리 인덱싱

LGMsecurity — Fri, 26 Dec 2025 19:51:23 +0900

1. 디렉터리 인덱싱(DI)

2. 취약점 개요

디렉터리 인덱싱 취약점은 웹 서버에서 특정 디렉터리에 기본 페이지 파일(index.html, index.php, default.asp 등)이 존재하지 않을 경우, 해당 디렉터리 안에 있는 파일 목록이 웹 브라우저에 그대로 표시되는 취약점이다. 이로 인해서 외부 사용자가 서버 내부 파일 구조를 쉽게 확인할 수 있으며, 이는 보안 사고로 이어질 수 있다.

↓ 위험

- 디렉터리에 기본 페이지 파일이 존재하지 않을 경우 ▶ 보통 웹 서버 사용자는 디렉터리 경로로 접속했을 때 기본 페이지 파일을 찾는데 기본 페이지 파일이 없으면 웹 서버는 디렉터리 안에 파일 목록을 대신 보여줌

- 웹 서버의 디렉터리 인덱싱 기능이 활성화 되어 있을 경우

- 접근 제어 설정이 미흡할 경우

- 디렉터리 인덱싱 기능을 비활성화하면 기본 페이지 파일이 없어도 파일 목록은 노출되지 않지만, 설정 변경이나 운영 실수를 대비한 이중 보호를 위해서 기본 페이지 파일 설정을 권고함

- 서버 설정이 변경되거나 다른 서버로 배포할 때 인덱싱이 켜질 수 있기 때문에 기본 페이지 파일이 있다면 인덱싱이 켜져도 파일 목록을 노출하지 않는다.

※ 디렉터리 인덱싱 기능 : 웹 서버가 특정 디렉터리에 접속했을 때 기본 페이지 파일이 없으면 자동으로 디렉터리 안의 파일 목록을 보여주는 기능

3. 점검 결과

1) URL 경로 중 확인하고자 하는 디렉터리까지만 주소창에 입력하여 인덱싱 여부 확인

내부 파일 인덱싱 결과

4. 권고사항

1) 디렉터리 인덱싱 비활성화

2) 기본 인덱스 문서 설정(index.html.index.php등)

3) 파일 시스템 권한 최소화

4) 업로드 파일은 공개 웹루트가 아닌 별도 저장소로 분리(직접 실행/노출 금지)

5) 커스텀 에러 페이지 적용

리눅스 서버 및 웹 취약점 진단 보고서 - 팀 프로젝트(개인 결과물)

LGMsecurity — Fri, 26 Dec 2025 19:36:42 +0900

리눅스 서버 및 웹 취약점 진단.pdf

4.17MB