CSRF(Cross-Site Request Forgery) : 사이트 간 요청 위조
공격자가 피해자의 브라우저를 속여, 피해자가 로그인된 사이트에 원하지 않는 요청을 보내게 만드는 공격
발생하는 이유
브라우저의 기본 동작 때문에 발생
문제상황
성립조건
위험이 줄어드는 경우
Authorization: Bearer … 같은 헤더 기반 인증만 사용정상 요청
CSRF 요청
“사용자가 정말 클릭했는지”가 중요한게 아니라 “쿠키가 있는 요청”이 중요
고전적인 Form POST 기반 CSRF
가장 유명한 형태고, 악성 페이지에 숨겨진 form을 두고 자동 제출
예)
<!doctype html>
<html>
<body onload="document.forms[0].submit()">
<form action="http://localhost:3000/account/email" method="POST">
<input type="hidden" name="email" value="attacker@lab.local">
</form>
</body>
</html>
이게 먹히려면,
GET 요청 악용
상태 변경을 GET으로 처리하면 매우 위험
예)
<img src="http://localhost:3000/user/delete?id=10">
또는
<a href="http://localhost:3000/account/logout">클릭</a>
GET 은 원래 조회용
상태 변경을 GET 으로 두는 것은 최신 기준에서도 여전히 매우 나쁜 설계
최신 관점: SameSite 때문에 예전보다 달라진 점
요즘은 브라우저가 예전처럼 아무 쿠키나 다 보내주지 않음
현대 브라우저 기준 핵심
SameSite-=Lax 가 사실상 기본 동작인 경우가 많음SameSite=Strict 는 더 강하게 차단SameSite=None 을 쓰려면 Secure 가 필요SameSite 쿠키 속성 설명
쿠키의 SameSite 속성은 CSRF 요청 시 쿠키를 전송할지 여부를 제어해서 CSRF 공격을 방어
SameSite-=Lax : 기본값
| 요청 유형 | 쿠키 전송 여부 |
| — | — |
| 같은 사이트 요청 | 전송 O |
| 최상위 탐색 (링크 클릭, GET) | 전송 O |
| 크로스 사이트 POST/PUT/PATCH | 차단 X |
| <img>, <iframe> 등 서브리소스 | 차단 X |
SameSite=Strict : 가장 엄격한 설정
| 요청 유형 | 쿠키 전송 여부 | | — | — | | 같은 사이트 요청 | 전송 O | | 외부 사이트에서의 모든 요청 | 차단 X |
SameSite=None + Secure : 크로스 사이트 요청에서도 쿠키를 항상 전송
| 요청 유형 | 쿠키 전송 여부 | | — | — | | 같은 사이트 요청 | 전송 O | | 크로스 사이트 모든 요청 | 전송 O |
Secure 속성과 함께 사용해야 함 Set-Cookie: token=abc123; SameSite=None; Secure
Secure 없이 SameSite=None 만 설정하면 브라우저가 쿠키를 거부Secure 속성 자체는 HTTPS 연결에서만 쿠키를 전송하도록 강제서드파티 위젯: 내 사이트에 다른 회사의 기능을 붙여넣는 것
예) 내 블로그에 다른 사이트의 위젯(링크)을 걸어놓는 것
SameSite=None이 없으면 → 쿠키 전송 안됨 → 항상 로그아웃 상태로 보임
OAuth / SSO (소셜 로그인) : 네이버 로그인, 구글 로그인 버튼
예시
(1) 사용자가 coupang.com에서 "네이버로 로그인" 클릭
(2) naver.com 로그인 페이지로 이동
(3) 네이버에서 인증 완료
(4) coupang.com으로 돌아옴 + "이 사람 인증됐어요" 토큰 전달
(5) coupang.com이 그 토큰으로 로그인 처리
(4)번 단계에서 네이버 → coupang.com 으로 쿠키/토큰이 넘어오는 순간이 크로스 사이트 요청
SameSite=Strict면 이 순간 쿠키가 차단돼서 로그인이 실해할 수 있음
결제 모듈 : 내 쇼핑몰에서 토스/네이버페이 결제창을 띄우는 것
위 로그인과 비슷
임베드된 iframe : 내 페이지 안에 다른 사이트 페이지를 액자처럼 끼워 넣는 것
<!-- 내 사이트 (mysite.com) -->
<h1>강의 페이지</h1>
<iframe src="https://youtube.com/embed/영상ID">
<!-- 여기 안은 youtube.com 의 세계 -->
<!-- 유튜브 로그인 쿠키가 있어야 -->
<!-- 광고 없이 보기, 저장 등이 가능 -->
</iframe>
SameSite 속성 단독 사용
Set-Cookie: session=xyz; Secure; HttpOnly
HttpOnly 와 함께 쓰면 JS에서 쿠키 접근도 차단되어 XSS 방어까지 가능의미
위험이 남는 경우
SameSite=None; SecureGETstate 검증 부재예를 들어 프론트 코드가 URL 파라미터를 읽어서 내부 API 요청을 만들어버리면, 공격자는 그 입력값을 조작해서 브라우저가 정상 토큰과 쿠키까지 붙인 요청을 보내게 만들 수 있음
취약 예시)
const api = new URLSearchParams(location.search).get("api");
fetch(api, {
method: "POST",
credentials: "include",
headers: {
"X-CSRF-Token": window.csrfToken
}
});
위험한 이유
즉, “CSRF 토큰이 있어도 프론트가 공격자 입력으로 요청을 만들면 뚫릴 수 있다”는 점이 중요
사용자를 공격자 계정으로 로그인시키는 형태
예)
OAuth/OIDC에선 state 검증 부재가 대표적
쿠키 기반 (CSRF 취약)
로그인 시:
서버 → 브라우저: Set-Cookie: session=abc123
이후 모든 요청:
브라우저 → 서버: Cookie: session=abc123 ← 자동으로 붙음!
브라우저가 자동으로 쿠키를 보내기 때문에, 공격자가 만든 페이지에서 요청해도 쿠키가 딸려감 (전통적인 웹사이트 로그인 방식)
Authorization 헤더 기반 (CSRF 안전)
로그인 시:
서버 → 클라이언트: { token: "eyJhbG..." } ← JS가 직접 저장
이후 모든 요청:
JS 코드가 직접: Authorization: Bearer eyJhbG... ← 수동으로 붙여야 함
JS가 직접 헤더를 붙여야 하므로, 공격자 사이트의 HTML form은 헤더를 임의로 추가 못함 → CSRF 공격 자체가 불가능 (현대적인 SPA + JWT 방식)
GET 요청 → 공격이 매우 쉬움
<img src="https://......">
이미지, 링크, scipt src 등 태그 하나로 공격이 가능
피해자가 클릭을 안해도 페이지 로드만으로 실행
POST 요청 → 공격이 복잡하지만 그래도 가능
서버가 Origin / Referer 를 확인하는가
브라우저는 “어디에서 왔는지 정보”를 헤더에 자동으로 담는다
예)
피해자가 evil.com 에서 mybank.com 으로 요청 시:
Origin: https://evil.com
Referer: https://evil.com/hack.html
Sec-Fetch-Site를 확인하는가
브라우저가 자동으로 붙여주는 헤더로, “이 요청이 어디서 시작됐는지”를 명확하게 알려줌
Referer / Origin 보다 훨씬 정확하고 JS로 위조가 불가능
| 값 | 의미 | 예시 |
|---|---|---|
same-origin |
완전히 같은 도메인 | mybank.com → mybank.com/api |
same-site |
같은 최상위 도메인 | app.mybank.com → api.mybank.com |
cross-site |
완전히 다른 도메인 ← CSRF는 여기 | evil.com → mybank.com |
none |
주소창 직접 입력, 북마크 | - |
<!doctype html>
<html>
<body onload="document.forms[0].submit()">
<form action="http://localhost:3000/account/email" method="POST">
<input type="hidden" name="email" value="attacker@lab.local">
</form>
</body>
</html>
localhost:3000 에 이미 로그인되어 있음POST /account /email 요청에 대해 CSRF 토큰을 검사하지 않음서버는 “쿠키가 있으니 본인 요청이겠지”라고 잘못 판단
→ 로그인된 “요청” 인지 확인만 하고, 사용자가 직접 보낸 요청 인지 확인하지 않음
→ 취약점 : 자동 제출 form 자체가 아니라, 세션 쿠키만 보고 요청을 신뢰하는 서버 로직
<img src="http://localhost:3000/user/delete?id=10">
서버가 GET /user/delete?id=10 같은 요청으로 실제 상태 변경을 수행함
→ 상태를 바꾸는 기능을 GET 으로 만든 설계 실수
→ GET 은 원래 조회용이어야 하는데, 삭제/변경 같은 동작을 넣어버렸기 때문
<a href="http://localhost:3000/account/logout">클릭</a>
<img src="http://localhost:3000/settings/toggle?darkmode=off">
사용자가 해당 사이트에 로그인된 상태면 쿠키가 붙어서 정상 요청처럼 처리될 수 있음
→ 민감 기능이 너무 쉽게 호출되도록 설계
→ 서버가 “어디서 온 요청인지”, “사용자가 실제로 의도했는지” 확인하지 않음
<!doctype html>
<html>
<body onload="document.forms[0].submit()">
<form action="http://localhost:3000/login" method="POST">
<input type="hidden" name="username" vlaue="attacker_demo">
<input type="hidden" name="password" value="demo1234">
</form>
</body>
</html>
피해자는 자기 계정이 아니라 공격자 계정으로 로그인된 상태가 됨
→ 개발자가 “로그인 전이니깐 CSRF 필요 없다”고 오해한 것
→ 하지만 로그인도 인증 상태를 바꾸는 중요한 상태 변경 요청
const api = new URLSearchParams(location.search).get("api");
fetch(api, {
method: "POST",
credentials: "include",
headers: {
"X-CSRF-Token": window.csrfToken
}
});
credentials: “include” 때문에 쿠키를 포함서버 입장에서는 “정상 앱이 보낸 요청”처럼 보임
→ 서버보다 프론트엔드가 요청 대상을 안전하게 통제하지 못한 것
→ “요청 URL/동작은 앱 내부에서 고정되어야 하는데, 공격자 입력이 그 흐름에 끼어든 것”
예시 상황
서버가 /api/profile 같은 JSON API를 제공
인증은 여전히 세션 쿠키 기반
서버가 Origin 검사나 CSRF 토큰 검증을 안 함
가능한 이유
많은 개발자가 “JSON이면 폼이 아니니 안전하다”고 착각함
하지만 핵심은 요청 형식이 아니라 인증 방식
쿠키 기반이면 브라우저가 자동 전송할 가능성이 있어 CSRF 관점 검토가 필요
CSRF 방어의 핵심은 로그인된 요청인지 확인하는 것이 아니라, 사용자가 실제로 의도한 요청인지 검증하는 것
위 공격 페이로드에서도 언급했지만 한번 더 정리하자면,
POST, PUT, PATCH, DELETE 같은 요청에 적용SameSite=Lax 또는 엄격한 Strict를 적용Origin / Referer 검증
Origin이 없을 수 있어 Referer를 보조적으로 보는 경우도 많음Sec-Fetch-Site, Sec-Fetch-Mode 같은 헤더를 활용해 cross-site 상태 변경 요청을 차단GET 금지
GET 은 조회 전용으로만 사용SameSite만으로 끝났다고 생각하면 안됨
위의 깃허브 링크는 David Noel Ng라는 개인 연구자가 LLM 레이어 복제 실험에 관하여 블로그에 올린 내용이다.
짧게 요약 정리해보자면,
모델에게 Base64로 인코딩된 질문을 보내도 제대로 이해하고 Base64로 답한다는 것을 발견했다. 이것이 시사하는 바로는 초기 레이어가 번역기처럼 입력을 추상적 내부 표현으로 변환하고, 후기 레이어가 그걸 다시 출력 언어로 변환한다는 것이다. 그렇다면 중간 레이어는 순수하게 “사고”를 담당하는게 아닐까? 하는 것이 첫 번째 힌트였다.
두 번째 힌트는 Goliath-120B라는 모델이었는데, 두 개의 완전히 다른 70B 모델 레이어를 뒤섞어도 작동했다는 점이다.
레이어들이 생각보다 훨씬 유연하다는 증거였다.
RTX 4090두 장으로 80개 레이어짜리 Qwen2-72B 모델에 대해 가능한 모든 레이어 쌍 조합 3,241가지 테스트를 했다.
각 조합마다
두 가지 완전히 다른 능력을 측정해서, 특정 레이어 구간이 진짜 범용 추론을 담당하는지 찾았다.
단일 레이어를 n번 반복해도 효과가 없었고, 7개 레이어 블록 단위로 복제해야만 효과가 있었다.
이는 중간 레이어들이 독립적인 작업을 하는 것이 아니라, 레시피처럼 여러 레이어가 하나의 완결된 “회로”로 작동하기 때문이다.
45~51번 레이어(7개)를 한 번 더 통과시킨 것만으로 72B → 78B 모델이 됐고, 6개 벤치마크 중 5개에서 성능 향상 —MUST +17.72%, MATH +8.16% — 으로 HuggingFace 오픈 LLM 리더보드 1위를 달성했다.
2026년 초 기준 오픈 LLM 리더보드 상위 4개 모델이 모두 RYS-XLarge를 기반으로 만들어진 모델이다.
다른 연구자들이 RYS 위에 파인튜닝을 더 쌓아서 성능을 계속 올린 결과이다.
이 실험으로, 트랜스포머 안에 기능적 해부학이 실제로 존재한다는 걸 보여줬다.
초기 레이어(번역), 중간 레이어(추론 회로), 후기 레이어(출력 변환)로 역할이 나뉘어 있고, 더 큰 모델일수록 이 구분이 더 명확해진다는 가설을 실험으로 뒷받침했다는 내용이다.
그리고 이 모든 걸 수백억짜리 클러스터 없이 지하실에서 RTX-4090 두 장으로 해냈다는 점이 인상적인 부분이다.
LLM은 레이어(층)가 수십 개 쌓인 구조이다. 입력 텍스트가 맨 아래 레이어붙 들어가서, 위로 올라가며 처리되고, 맨 위에서 답이 나오는 구조다. 딥러닝에서 트랜스포머에 대해 배웠다면 쉽게 이해가 될 것이다.
일반 트랜스포머 구조
입력 텍스트
↓
[레이어 0] ← 초기 해석
[레이어 1]
[레이어 2]
...
[레이어 45] ← 중간: 추론/사고
[레이어 46]
...
[레이어 79] ← 후기: 출력 변환
↓
출력 텍스트
레이어 복제
입력
↓
[레이어 0 ~ 44]
[레이어 45 ~ 51] ← 1회차 통과
[레이어 45 ~ 51] ← 2회차 통과 (동일한 레이어를 다시!)
[레이어 52 ~ 79]
↓
출력
복제 레이어를 늘려서 원래 레이어 곧장 뒤에 붙이는지, 모든 레이어가 끝난 다음에 복제된 레이어를 마지막에 한번 더 돌리는건지 궁금했다. 찾아본 결과로는 원래 레이어의 바로 뒤에 복제 레이어가 붙는데,
[레이어 45] → [레이어 45] → [레이어 46] → …
이런 식이 아니라
[레이어 45] → [레이어 46] → ... -> [레이어 51]
-> [레이어 45] → [레이어 46] → ... [레이어 51]
다음과 같이 크게 두 바퀴를 돈다고 생각하면 될 것 같다.
]]>작년에 동아리 팀 프로젝트로 진행하다 중단 되었던 “LLM 기반 워드프레스 플러그인의 웹 취약점을 자동으로 분석하고 찾아내어 취약한 코드 부분과 취약한 수준, 시큐어 코딩 방법 등까지 보고서로 만들어주는 스캐너 에이전트 개발”을 이어서 해보려고 한다.
XSS(Cross-Site Scripting)
위험한 이유
성립 조건
3단계가 연결되면 생김
→ XSS는 “사용자 입력이 위험한 컨텍스트로 들어가는 문제”
HTML 본문 컨텍스트
<div>USER_INPUT</div>
HTML 속성 컨텍스트
<input value="USER_INPUT">
URL 컨텍스트
<a href="USER_INPUT">link</a>
JavaScript 컨텍스트
<script>
const data = "USER_INPUT";
</sciprt>
DOM sink 컨텍스트
element.innerHTML = userInput;
사용자 요청에 들어간 값이 바로 응답 HTML에 반사됨
예) 검색어, 에러 메시지, URL 파라미터
## 취약 예시 ##
<p>검색어: USER_INPUT<p/>
서버가 USER_INPUT을 그대로 넣으면 Reflected XSS
공격 문자열이 DB 등에 저장됐다가 나중에 다른 사용자에게 보여질 때 실행
예) 게시글, 댓글, 닉네임, 관리자 메모
## 취약 예시 ##
<div class="comment">SUER_COMMENT</div>
댓글 저장 시 필터링/정제가 부실하면 Stored XSS
서버 응답 자체보다, 브라우저의 JS 코드가 URL,입력값,postMessage 같은 값을 읽어서 DOM에 위험하게 넣을 때 발생합니다.
DOM : Document Object Model(문서 객체 모델)
웹페이지(HTML)를 컴퓨터가 이해하기 쉽게 구조로 바꿔놓은 것
<html>
<body>
<h1>안녕</h1>
<p>내용</p>
</body>
</html>
위 HTML을 브라우저는 아래 트리 구조와 같이 이해
html
└── body
├── h1 ("안녕")
└── p ("내용")
이 구조 전체가 DOM
DOM은 JS가 웹페이지를 조작할 수 있게 해줌
예) 글자 바꾸기, 버튼 클릭하면 내용 변경, 팝업
document.querySelector("h1").textContent = "바뀐 제목";
## 취약 예시 ##
const q = new URLSearchParams(location.search).get("q");
document.getElementById("result").innerHTML = q;
서버가 아니라 브라우저 JS가 직접 취약
HTML 삽입 여부 확인
<b>teset</b>
이벤트 핸들러 실행 여부 확인
<img src=x onerror=alert(1)>
DOM XSS 기본 확인
const payload = '<img src=x onerror=alert(1)>';
target.innerHTML = payload;
sink : 외부 입력값이 “실제로 실행되거나 반영되는 최종 지점”
[사용자 입력] -> (가공/처리) -> [sink]
sink는 위험이 실제로 터지는 지점
innerHTML : 요소 안쪽 HTML을 통째로 바꿔버림
div.innerHTML = userInput;
<script> 같은 것도 실행될 수 있음outerHTML : 요소 자기 자신까지 포함해서 바꿔버림
div.outerHTML = "<p>바뀜</p>";
insertAdjacentHTML : 특정 위치에 HTML 삽입
div.insertAdjacentHTML("beforeend", userInput);
innerHTML과 동일하게 위험document.write() : 페이지에 직접 HTML을 써버림
document.write(userInput);
eval() : 문자열을 JavaScript 코드로 실행
eval(userInput);
new Function() : 문자열로 함수 생성 후 실행
new Function(userInput);
문자열 기반 seTimeout(), setInterval()
setTimeout("alert(1)", 1000);
안전한 방식
setTimeout(() => alert(1), 1000);
예)
취약한 코드
box.innerHTML = userInpurt;
안전한 방식
box.textContent = userInput;
또는
const el = document.createElement("div"):
el.textContent = userInput;
box.appendChild(el);
→ 실무 감각으로
http, https)tesxtContentcreateElementsetAttributeappendChildHTML Sanitization
사용작 HTML 입력을 정말 허용해야 할 때만 sanitizer를 씀
OWASP는 대표적으로 DOMPurify 사용을 권장
단, sanitizer도 지속 업데이트가 중요
dangerouslySetInnerHTMLbypassSecurityTrustAs*unsafeHTMLCSP는 보조 수단
CSP는 좋지만 주 방어책이 아님 (OWASP도 언급)
최신 방어 포인트: Trusted Types
특히 DOM XSS 방어에 유용
Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy;
이렇게 두면 innerHTML 같은 위험 sink에 문자열을 바로 넣는 습관을 강하게 통제할 수 있음
<script> 차단 = XSS 방어 완료”가 아님#)postMessageinnerHTML 계열인지eval) 계열인지<script>...</script> 만 막는다고 끝나지 않음dangerouslySetInnerHTML, Angular의 bypassSecurityTrustAs*, Lit의 unsageHTML 같은 지점을 대표 위험 지점으로 봄OWASP는 CSP/WAF만으로 XSS를 막으려 하지 말고, 컨텍스트별 출력 인코딩 + 안전한 DOM API + HTML Sanitization을 기본으로 하라고 권장
CSP (Content Security Policy)
웹사이트에서 “어떤 코드만 실행해도 되는지” 정해놓는 보안 규칙
= 출입 가능한 코드만을 미리 정해놓는 출입통제 시스템
<script src="https://evil.com/hack.js"></script>
다음과 같은 XSS 스크립트 삽입 공격이 있을 때 CSP가 있으면 evil.com 을 차단한다.
Trusted Types
위험한 HTML/스크립트를 아무 문자열로 넣지 못하게 막는 규칙
element.innerHTML = userInput;
만약 이 JS 코드에서 userInput이 아래와 같으면
<script>alert(1)</script>
바로 XSS 발생!!
대규모 언어 모델(LLM)을 활용하여 AI 에이전트를 개발하는 것을 목표로 하고 있습니다.
최근 보안에도 관심이 생겨 해킹 연구 동아리 “KUality”에 속해있습니다.
웹해킹에 관심이 있어 공부 중입니다.
앞으로 공부한 내용과 진행 중인 프로젝트, 사소한 IT/보안 지식에 관한 정리들을 블로그에 올릴 예정입니다.
이 깃허브 블로그가 꽉 채워지는 그 날까지 열심히 공부하겠습니다.
감사합니다.
Hello, I’m Jewoo Yoo, a student in the Department of Computer Software at Korea University.
My goal is to develop AI agents using large language models (LLMs).
Recently, I’ve also become interested in security and I am a member of the hacking research club “KUality”.
I’m currently studying web hacking.
I plan to regularly share what I learn, ongoing projects and various insights related to IT and security on this blog.
I’ll keep studying and working hard until this GitHub blog is filled with meaningful content.
Thank you.
]]>