Naam's Hacking Log

2025년 회고록

cloudnaaam — Sat, 10 Jan 2026 13:24:10 +0900

들어가며

블로그를 공부용으로만 쓰기엔 왠지 모를 아까움이 들었다. 그래서 뭘 할까 고민하다가.. 한 해를 갈무리 할 겸 회고록을 써보기로 했다. 아 물론 2026년의 첫 해가 뜬 지 9일이나 지났지만 말이다. 그래도 더 늦기 전에 2025년을 회고해보고자 한다.

2025년은 토끼띠에게 들삼재였다는데, 그랬던 것 같기도 하고.. 아니었던 것 같기도 하다. 뭐 아무렴 어떠랴. 근성으로 이겨내면 그만이다.

1월

플랜카드 없었으면 훨씬 예뻤을텐데

나의 2025년 첫 1초는 DDP역 앞 세븐일레븐이었다. 알바와 함께하는 새해는 처음이라 감회가 새롭더라. 주 손님층이었던 외국인들이 종각으로 몰렸는지 그날따라 사람이 적었었다. 덕분에 알바의 마지막 날을 마무리했었지.

아 그리고 학점을 다 들어서 수료 상태가 되었다. 이에 따라 자취방도 빼고 본가로 돌아왔다. 참 즐거우면서도 탈도 많았던 자취 생활이었다. 한 가지 확실하게 말할 수 있는 건, 자취했던 동안은 내 대학 생활 중 가장 열심히 살았던 시기였다. KISIA 교육 프로젝트, 화이트햇 스쿨, 졸업 플젝, 그리고 알바까지. 대학 생활 중 가장 큰 발자국을 여기서 찍을 수 있었다.

1월의 서우봉

1월 중순에는 제주도 여행을 갔다왔다. 한 때 내 집과도 같았던 제주의 청취는 여전했다. 은은하고, 여유로웠다. 하늘은 쾌청하고, 1월치고는 춥지 않은 날씨와 적당히 부는 바람. 무엇 하나 부족하지 않았던 여행이었다. 또 가고 싶다 제주도..

2월 ~ 8월

본격적인 상반기 취준 시기.. SQLD, CPPG, 정처기, Opic 총 4개의 자격증에 호기롭게 도전. 결과적으로 성공한 건 정처기 필기 하나뿐..

상반기에는 나름 서류 열심히 넣었다. 잡코리아에서 이력서도 만들어보고, 자소서도 계속 써보고.. 결과적으로 CJ올리브네트웍스, 신한DS 이 두 개가 서류 통과했다. 아 물론 둘 다 떨어졌다. 각각 코테, 면접에서 말이다. 특히 면접은 힘겹더라.. 프리스타일로 말하려다가 된통 쓴 맛을 봐버렸다.

아 BOB도 지원..하려고 했으나, 취업에 대한 압박감 때문에 넣지 않았다. 물론 넣었어도 붙었을지는 모르겠지만.

니시하마 해수욕장, 에노시마

8월에는 도쿄로 여행을 갔다왔다. 8월의 일본은 정말.. 여름이었다. 최고 기온 34도, 체감 기온 38도를 곁들인.. 아 물론 찜통 더위에도 불구하고 재밌게 놀고 왔다. 신주쿠, 시부야, 아키하바라, 아사쿠사, 우에노, 가마쿠라, 에노시마.. 3박 4일동안 진짜 많이 다녔다.

특히 여름에 일본을 간다면 니시하마 해수욕장은 강력 추천한다. 모래가 곱고 물도 많이 안차서 물놀이 하기 딱이더라. 우리는 옷을 안가져가서 못했지만..

그리고 야끼니꾸 짱 맛있더라. 거짓말 안보태고 셋이서 우설만 10번은 넘게 시켜먹은 것 같다. (무한 리필집임). 갈비는 8번 정도. 생맥주도 같이 먹을까 했었는데, 우리의 주된 목적은 고기였기에. 맥주 먹을 배에 고기를 미친듯이 투입시켰다. 헌데, 사장님이 우리의 폭주를 막고자 하셨음일까? 마지막에 시켰던 돈설은 유난히 양이 많았다. 우리는 인생 첫 돈설을 도전하였고, 얼마 안가 돼지 잡내에 굴복하고 식당을 나섰다.

사실 2월 ~ 8월은 심적으로 부담되던 시기였다. 취준도 처음이고, 동시에 '내가 취업을 할 수 있을까'라는 생각도 들었고 말이다. 아니, 더 정확히 말하자면 '내가 사장이라면 과연 나를 뽑을까?'라는 생각이였을까. 동시에 보안 공부를 일찍 시작했더라면.. 이라는 무용한 생각도 계속 들었지.

9월

9월에는 SK 쉴더스 루키즈 교육에 합격했다. 그래서 24일부터 교육 시작했다.

만리포 해수욕장, 태안

그리하여 교육 전 마지막 여행으로 태안에 갔다. 이게 취준생의 묘미지. 1박 2일로 첫 날은 천리포 해수욕장 쪽에서 놀고, 이튿 날은 만리포 해수욕장에서 놀았다. 특히 이튿 날은 다행히 날씨가 개서 물놀이를 즐겼다. 서해 바다는 수위가 낮아서 편하게 놀기 좋더라. 푸지게 놀고 올라가는데, 도저히 집 갈 여력이 없어 운전해준 친구 집에서 다같이 잤다.

10월 ~ 12월

이 때는 한창 교육 들었다. 관제, 컨설팅, 취약점 진단 등등.. 다 들어봤는데 역시 모의해킹이 제일 재밌더라.

12월 어느 날. 첫눈

12월에는 첫눈이 왔다. 근데 올해는 낭만이 아니라 재해더라. 갑자기 눈이 오는 터라 도로도, 차들도, 사람들도 모두 대비가 안되었었다. 날도 추워서 떨어진 눈이 얼어버렸는데, 사람도 차도 다 미끄러지더라. 오죽하면 마을 버스가 안굴러가서 사람들이랑 뒤에서 밀어줬었다. 이 와중에 건이는 산책 나가서 낭만을 즐기더라.

2025년의 마지막 날. 교육장 창문

2025년의 마지막 날도 역시 교육을 들었다. 노트북에 집중하다가 피로하면 창 밖을 보곤 한다. 그럴 때마다 보이는 학교 앞 술집 거리와 남산. 생각 없이 보다 보면, 대학 생활이 스쳐 지나가곤 한다. 그렇게 마주한 찰나의 추억이 다시 힘을 주더라. 졸업식 날에는 또 어떤 느낌이 들 지 문득 궁금하다.

마치며

2025년은.. 진짜 어른으로서의 첫 방황이 아니었을까 싶다. 수료와 동시에 취준, 그리고 연속되는 탈락.. 왜 취준이 다들 어렵다는 지 알 것 같던 시기였다. 이걸 1년 이상 한다고..?

이 시기를 버틸 수 있었던 건, 어려움 속에서도 방법을 찾는 내 성격 덕분이었다. 새로운 시작을 했고, 아직 현재 진행형이다. 마지막에는 어떻게 될 지 알 수 없지만, 잘 될꺼다. 변명도, 핑계도 불필요하다. 나를 믿는다.

2026년은 뭔가 목표가 있다면, 우선은 원하는 곳에 취업하는 것. 이건 무조건..! 그리고 해킹 실력좀 많이 늘었으면 좋겠다. 요즘 감이 아주 떡락해서 쉬운 것들도 자꾸 빙빙 돌아가는 느낌이다.

마지막으로는 내 스타일을 찾는 것. 옷좀 잘 입고 싶다. 유튜브, 인스타, 핀터레스트에서 다양하게 옷질 정보를 얻으면서 눈을 틔우려고는 하는데.. 이거이거 쉽지가 않다.

어.. 마지막 멘트는.. 로또 1등 당첨되면 좋겠다.

XS_leak

cloudnaaam — Tue, 2 Dec 2025 12:05:08 +0900

Background

XS leak에 대해 이해하려면 먼저 CORS와 SOP에 대해 알아야 한다.

동일 출처 정책 (Same Origin Policy)

SOP는 동일한 출처에서만 리소스를 공유하도록 유도한다. 동일한 출처란 "프로토콜|호스트|포트"가 모두 같은 곳을 말한다. 즉,

http://123.123.123.12:8000 = http://123.123.123.12:8000 
https://1.1.1.1:8000 != http://1.1.1.1:8000
http://search.naver.com != http://mail.naver.com

이렇게 하나만 달라도 다른 출처로 간주하는 것. 참고로 TLD나 subdomain이 달라도 다른 출처로 간주된다.

SOP는 다른 서버, API로 요청을 보내고 응답 받을 수는 있지만, 요청을 받는 것을 막는다. 이게 꽤나 중요한 게, SOP가 없다면 아마 side channel을 이용한 해커들의 공격이 마구잡이로 일어날꺼다.

근데 이렇게만 보면 개발자들에게 있어서 리소스가 너무나도 한정적이다. 특히 외부 API를 못가져오는 건 재앙이나 마찬가지일꺼다. 때문에 이를 완화시키기 위해 CORS라는 게 존재한다.

교차 출처 리소스 공유 (Cross Origin Resource Sharing)

CORS는 교차 출처 리소스 공유에 대한 정책이다. SOP에서 교차 출처를 모두 막지만, CORS를 통해 이를 완화하여 특정 출처의 리소스를 공유할 수 있다.

CORS 기본 동작

1. 브라우저가 헤더의 Origin 필드에 출처를 담아 보냄

2. 서버가 Access-Control-Allow-Origin: 출처 를 담아 클라이언트에게 전달

3. 클라이언트에서 Origin과 Access-Control-Allow-Origin을 비교

4. 유효하지 않으면 차단

위 CORS의 동작을 보면 알 수 있듯, 서버와 브라우저가 상호작용을 통해 리소스를 허용한다. 따라서 결론적으로 CORS를 통해 출처를 허용하려면, 서버가 Access-Control-Allow-Origin 헤더에 허용할 출처를 포함해서 응답하면 되는 것이다.

이 외에도 CORS의 동작 방식이 더 있는데, 본 글은 xs leak 설명이 중심이기에 배경 지식 설명은 이 정도면 충분할 것 같다. (Reference를 참조하시길..)

XS leak이란?

직역하면 교차 사이트 유출이다. 쉽게 말하면 타겟 사이트의 동작에 기반하여 사이드 채널을 통해 정보를 얻는 것인데, 대략 구조를 그려보자면

이런 느낌이지 싶다. 여기서 알아야 할 부분이, 앞서 말한 SOP/CORS 모두 브라우저 단에서 이뤄지는 정책들이기 때문에, 우리가 지금 보고 있는 XS leak은 브라우저 단에서 일어나는 취약점이라는 것이다. 이를 먼저 알면 이해하기 편하다. (브라우저 단 취약점이다? ==> JS/HTML을 반드시 공부해라!)

웹은 상호 작용할 수 있도록 설계되어 있다. 비단 사용자 뿐만 아니라 다른 사이트 또한 마찬가지이다. iframe, a href, img 등등.. 그리고 이를 안전하게 하도록 브라우저는 SOP를 사용한다. 하지만 SOP로도 해커들을 완벽하게 막을 수는 없었다. 사실 정확히 말하면 개발자들의 웹 설계 방식도 한 몫 하지만..

Scenario

XS leak을 유발하는 시나리오는 다양하다. 패턴이 꽤 많아서 XS leak wiki를 참고하는 것을 추천한다.

https://xsleaks.dev/

Introduction

XS-Leaks Wiki # Overview # Cross-site leaks (aka XS-Leaks, XSLeaks) are a class of vulnerabilities derived from side-channels 1 built into the web platform. They take advantage of the web’s core principle of composability, which allows websites to intera

xsleaks.dev

대표적으로 몇 개만 살펴보자면

1. Frame Counting

브라우저에서는 window.open() 이나 <iframe>을 사용할 경우 다른 출처의 페이지여도 다음과 같은 속성은 접근이 가능하다.

iframe.contentWindow.length
iframe.contentWindow.frames.length

해당 속성들은 자식 프레임의 개수 (정상 응답만) 를 반환한다. 만약 타겟 페이지에서 <iframe>을 이용해서 입력 결과를 반환한다면 해당 속성들을 이용해서 결과를 유추할 수 있지 않을까? 예를 들어

iframe.src = `타겟 서버/search?query=CLOUD`;

iframe.onload = () => {
  const frameCount = iframe.contentWindow.length;
  if(frameCount >= 1){
      console.log("HIT!!");
  }
};

이런 식으로 말이다.

2. Timing

Timing 기법의 경우 네트워크 환경에 따라 측정이 불안정 할 수 있다. 따라서 여러 번 측정하면서 패턴을 파악하고 측정 결과 간

비교해야 한다. 예를 들어 DB에서 결과를 가져오는 시간에 따른 패턴이라던가, 결과에 따른 브라우저 렌더링 및 동작 시간을 파악한다던가..

누가 봐도 설계 문제인 게 아니면 굉장히 어려운 기법이라고 생각한다. 다만, 공격자에게 어려운 만큼 방어하는 입장에서는 예방하기 더 어렵겠지만.

3. Etc.

단순하게 서버의 응답 코드만으로도 정보가 유출될 수 있다. 예를 들어 idx를 조회하는 페이지가 있다면

/my-idx?user=Cloud&idx=101 ==> 404
/my-idx?user=Cloud&idx=102 ==> 200
/my-idx?user=Cloud&idx=103 ==> 404
/my-idx?user=Cloud&idx=104 ==> 404

이런 식으로 user의 idx를 응답 코드를 통해 유추할 수 있다.

이를 이용해서 CTFd 라는 플랫폼에서 1-day 취약점이 발생했었는데, 자세한 부분은 해당 링크를 참고하는 게 좋겠다.

https://blog.hspace.io/posts/XS-Leak101-2/

XS-Leak101#2

Visited link XS-Leak라는 기법을 알아봅니다.

blog.hspace.io

Mitigation

SameSite Cookie, COOP(Cross-Origin-Opener-Policy), COEP(Cross-Origin-Embedded-Policy), CSP(Content-Security-Policy), X-Frame-Options, Origin-Agent-Cluster, CORP(Cross-Origin-Resource-Policy) 등 브라우저 단에서 막을 수 있는 여러 방법들이 있다. 물론 서버 측의 설계를 바꿀 수도 있겠지만, 웬만하면 개발자들의 인권을 존중하자..!

Practice

https://github.com/CloudNaaam/xs_leak

GitHub - CloudNaaam/xs_leak: for study

for study. Contribute to CloudNaaam/xs_leak development by creating an account on GitHub.

github.com

사실 이게 이 글을 쓴 진짜 이유다. 사이드 프로젝트로 xs leak을 간단하게 구현해봤다.

Reference

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

https://velog.io/@jesop/SOP%EC%99%80-CORS

https://xsleaks.dev/

https://www.hahwul.com/cullinan/attack/xs-leaks

https://blog.hspace.io/posts/XS-Leak101-2/

JWT (Json web token)

cloudnaaam — Wed, 20 Aug 2025 12:17:23 +0900

- 이 글은 아직 현업을 경험하지 못한 보안 공부생의 정리 글이니, 정확하지 않을 수도 있습니다.-

JWT란?

json 형식으로 이루어진 웹 토큰이라고 쉽게 생각하면 된다. jwt는 header, payload, signature세 부분으로 나뉜다.

보통 signature 부분은 해당 jwt 알고리즘에 따른 key를 이용해 생성되기 때문에 변조 불가능하고,

header, payload 부분을 변조한다.

보통 header 부분에는

alg : 해당 jwt 생성 시 사용한 알고리즘

typ : 토큰 타입, 보통 JWT 로 지정

cty : 페이로드의 타입

kid : 키의 id

jwk : 서명에 사용된 공개키를 직접 포함

jku : 공개키가 위치한 url

x5u, x5c : 공개키 인증서 위치한 url, 혹은 직접 포함

이렇게 올 수 있다.

header 부분을 조작해서 인증 우회를 하는건, 서버의 코드 설계 자체에서 오는 결함이 대부분일듯 하다.

내가 아는 한도는

1. key 검증에서 문제가 발생해 임의로 만든 jwt 토큰으로 검증 우회 (alg 이 none으로 설정되어 있는 경우가 대표적)

2. kid 를 이용한 directory traversal (리눅스에서 /dev/null 경로를 많이 사용한다고 함)

3. algorithm confusion. 보통 서버는 비대칭을 원하는데, 공격자가 대칭키로 조작했을 때 발생

https://portswigger.net/web-security/jwt/algorithm-confusion

Web Application Security, Testing, & Scanning - PortSwigger

PortSwigger offers tools for web application security, testing, & scanning. Choose from a range of security tools, & identify the very latest vulnerabilities.

portswigger.net

4. jwk 와 jku를 서버가 사용할 경우, 이들을 임의로 인젝션해서 서버가 jwt를 신뢰하도록

등이 있는데, 그 밖에도

5. cty 를 이용해 Content-type을 바꿔 XXE나 역직렬화 공격

6. x5c를 통해 인증서 주입 및 우회 (CVE-2017-2800, CVE-2018-2633)

가 있다고 한다.

payload는 서버에서 지정한 양식대로 가는데, 만약 header 조작으로 우회를 성공했다면?

"admin":true 이런 식으로 센스껏 조작해서 시도해보면 되겠다.

대부분의 인증 우회가 그렇듯, JWT를 이용한 인증도 우회가 되는 이유는 설계 상의 문제인 듯 하다.

서명 검증을 빡세게 하거나, jku 를 화이트리스트로 필터링하고, kid 파라미터를 필터링한다던가 여러 방법으로 완화할 수 있겠다.

Web cache deception

cloudnaaam — Sat, 19 Jul 2025 15:56:08 +0900

- 이 글은 아직 현업을 경험하지 못한 보안 공부생의 정리 글이니, 정확하지 않을 수도 있습니다.-

Web cache deception이란

웹은 정적 콘텐츠, 동적 콘텐츠로 구성된다. 정적 콘텐츠(Static Contents)의 경우 PNG, JPG 등 정보가 고정된 콘텐츠를 의미한다. 트래픽이 많아질 경우에 서버의 부담을 덜어주기 위해 Caching을 이용하기도 하는데, 이 때 발생할 수 있는 취약점이다.

먼저 알아야 할 것은

사용자 - 캐시 서버 - 백엔드 서버 간의 관계이다.

출처: 챗지피티

이런 식으로 있다고 생각하면 되는데, 캐시 서버에서 Caching을 하면 유저의 로컬 브라우저에 저장되게 된다. 즉, 백엔드 서버까지 굳이 가서 다시 콘텐츠를 불러올 필요가 없어진다는 것이고, 그러면 서버의 부담이 줄게 되는 것.

근데 만약 캐시 서버와 백엔드 서버의 URL 정규화 규칙이 다르다면? Web cache deception 취약점이 발생하게 되는 것.

예를 들어 /my-account 로 접근하면

이렇게 내 정보가 뜬다.

만약 캐시 서버는 경로를 그대로 해석하고, 백엔드 서버는 /my-account/* 는 모두 동일하게 처리할 때,

/my-account/asd.js로 접근하면

이렇게 caching 하는 것을 확인할 수 있다.

두 번째 접근에서는 cache가 hit 되었고, 30초 동안은 /my-account/asd.js에 접근하면 내 정보가 그대로 보이게 되는 것.

그리고 만일 이걸 다른 사람이 접근하게 된다면? 누군가에게 리다이렉션을 강제로 시켜서 접근시켜버린다면?

그 사람의 정보가 다시 caching 되어 캐시 서버에 저장되고, 이를 내가 빠르게 접근하면 정보 탈취가 가능한 것.

중요한 점은, 캐시 서버와 백엔드 서버 간 정규화 불일치 여부를 찾아내는 것. 그리고 캐싱 규칙을 찾아내는 것.

주로 robot.txt favicon.ico index.html 등 수정이 거의 없는 파일에서 캐싱 규칙을 찾아낼 수 있다.

CDN 기능이나, Cache-Control 헤더, 그리고 서버들 간의 정규화 통일을 통해 취약점을 방어할 수 있겠다.

pugjs 취약점

cloudnaaam — Thu, 26 Jun 2025 14:59:01 +0900

- 이 글은 아직 현업을 경험하지 못한 보안 공부생의 정리 글이니, 정확하지 않을 수도 있습니다.-

워게임 풀다가 관련 개념이 나와서 간단히 정리해 보려 한다.

pug는 html을 더 효과적으로 보여주는 렌더링 엔진이다. pretty option을 통해 입력 값을 들여쓰기 해서 보여줄 수 있는데, 여기서 RCE가 발생할 수 있다고 한다.

 visitMixin: function(mixin) { 
   var name = 'pug_mixins['; 
   var args = mixin.args || ''; 
   var block = mixin.block; 
   var attrs = mixin.attrs; 
   var attrsBlocks = this.attributeBlocks(mixin.attributeBlocks); 
   var pp = this.pp; 
   var dynamic = mixin.name[0] === '#'; 
   var key = mixin.name; 
   if (dynamic) this.dynamicMixins = true; 
   name += 
     (dynamic 
       ? mixin.name.substr(2, mixin.name.length - 3) 
       : '"' + mixin.name + '"') + ']'; 
  
   this.mixins[key] = this.mixins[key] || {used: false, instances: []}; 
   if (mixin.call) { 
     this.mixins[key].used = true; 
     if (pp) 
       this.buf.push( 
         "pug_indent.push('" + Array(this.indents + 1).join(pp) + "');" 
       );

내부 코드를 보면 pp에 pretty의 입력값을 넣게 된다.

마지막 부분을 보면 버퍼에 push 하는 부분이 있는데, 문법에 맞춰서

')console.log('hello');// 를 넣으면

 if (pp) 
   this.buf.push( 
     "pug_indent.push('')console.log('hello');//');" 
   );

이렇게 넣을 수 있다.

이후 버퍼에 흘러들어간 코드가 내부 로직을 통해 실행된다는 것 같다.

3.0.0 이후 버전부터는 조치되었다고 하니, 알아만 놓자.

Reference

https://github.com/pugjs/pug/issues/3312

https://www.piolink.com/kr/service/Security-Analysis.php?bbsCode=security&vType=view&idx=67&page=4

Unicode case mapping collision

cloudnaaam — Thu, 26 Jun 2025 12:07:08 +0900

- 이 글은 아직 현업을 경험하지 못한 보안 공부생의 정리 글이니, 정확하지 않을 수도 있습니다.-

어제 드림핵에서 워게임 문제 풀다가 관련 개념이 나와서 정리해보려고 한다.

생각치도 못했는데, 알고 나니까 신기하더라..

Unicode case mapping collision이란?

유니코드가 lowercasing, uppercasing 할 때 서로 충돌하여 동일하게 처리되는 현상..이라고 하는데,

쉽게 이해하기 위해 예시를 들어보면

print('ß'.lower() == 'SS') // False
print('ß'.upper() == 'SS') // True
print(ord('S')) // 83

python으로 독일어 'ß' 를 대문자화하면 'SS' 와 같다고 인식하는 것을 볼 수 있다. 그리고 저기 있는 'S'는 10진수로 83, 즉 영문자 'S'이다.

console.log('ß'.toLowerCase() == 'SS'); // false
console.log('ß'.toUpperCase() == 'SS'); // true

Javascript 또한 마찬가지이다. 듣기로는 다른 언어들도 매핑 충돌이 일어난다고 한다.

admin_id = 'admin' 
my_permission = False

if not my_permission and user_input == 'admin':
	print('no permission')

if user_input.upper() == 'ADMIN':
	print('login')

대략 이런 식으로 서버 코드가 짜여져 있다면?

user_input 에 'ADMıN' 을 넣는다면 login이 출력되는 것을 확인 할 수 있다.

깃허브에서도 이와 비슷한 사례가 있었다고 한다.

https://dev.to/jagracey/hacking-github-s-auth-with-unicode-s-turkish-dotless-i-460n

Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

From combining emoji marks and astral planes, Unicode is under appreciated and poorly understood. The...

dev.to

cheatsheet 도 있으니 참고하면 좋을 것 같다.

https://gosecure.github.io/unicode-pentester-cheatsheet/

Characters that byͥte

gosecure.github.io

Prototype Pollution

cloudnaaam — Wed, 25 Jun 2025 18:38:46 +0900

- 이 글은 아직 현업을 경험하지 못한 보안 공부생의 정리 글이니, 정확하지 않을 수도 있습니다.-

Prototype Pollution이란?

Javascript는 객체 지향 언어이다. python, java는 class 라는 개념으로 상속을 구현하지만, javascript는 prototype을 이용하여 상속을 구현한다. (물론 class도 사용하지만, 본질은 prototype이긴 함)

모든 객체는 최상위 객체를 원형(prototype)으로 삼고 이를 참조하는 방식으로 상속과 비슷하게 구현되는 것.

쉽게 말해 어떤 객체의 프로퍼티를 찾을 때, 자바스크립트는

1. 해당 객체 확인

2. __proto__로 연결된 부모 객체 확인

3. 계속 거슬러 올라가다가 마지막에 전역 객체인 Object.prototype까지 확인

4. 없으면 undefined

이런 식으로 계속 부모 객체로 거슬러 올라가면서 프로퍼티를 찾는다. 이 과정을 prototype chain이라고 부르고.

Prototype Pollution은 이러한 prototype을 공격자가 임의로 수정하여 원하는 동작을 유발시키는 공격 방식이다. XSS에서 심하면 RCE까지도 가능하다.

let a = {};

a['__proto__']['hello'] = 'bello';
console.log(a.hello); // 'bello'

let b = {};

console.log(b.hello); // 'bello'
console.log(b['__proto__']); // [Object: null prototype] { hello: 'bello' }
console.log(Object.prototype['hello']); // bello
console.log(Object.constructor.prototype['hello']); // bello
console.log(Object.__proto__['hello']); // bello

이처럼 하나의 객체의 prototype을 수정하면 전역 객체인 Object까지 영향을 미치는 것을 확인할 수 있다.

병합, 복제 등의 코드가 입력값이나 외부 데이터를 안전하게 검증하지 않을 때 사용자 조작으로 일어날 수 있는데,

portswigger에 예시 문제를 하나 뜯어보며 알아보자.

https://portswigger.net/web-security/prototype-pollution/client-side/lab-prototype-pollution-dom-xss-via-client-side-prototype-pollution

Lab: DOM XSS via client-side prototype pollution | Web Security Academy

This lab is vulnerable to DOM XSS via client-side prototype pollution. To solve the lab: Find a source that you can use to add arbitrary properties to the ...

portswigger.net

해당 문제는 prototype pollution을 연계하여 XSS 공격을 유발하게 되어 있다.

/resources/js/deparam.js

/resources/js/searchLogger.js

프론트엔드 코드를 뜯어보면 이 두 라이브러리를 가져와서 사용하는 것을 볼 수 있다.

deparam의 경우 파라미터의 병합을, searchLogger에서는 스크립트의 동적 삽입을 담당한다.

특히 transport_url 라는 속성을 가져와 script.src에 넣어 동적 삽입하기 때문에 해당 속성을 오염 타겟으로 삼아

/?__proto__[transport_url]=data:,alert(1); 
// {__proto__ : "data:,alert(1);"} //

이렇게 data: scheme을 사용하여 XSS를 유도할 수 있다.

서버 측의 경우..는 클라이언트 측보다 발생하기 어렵다.

애초에 블랙박스 방식으로는 거의 못찾을 것 같고, 찾는다고 해도 결국 시스템의 환경변수나 전역 객체를 건드려야 하기 때문에

시스템 자체가 다운될 수도 있으니까.

관련해서 자세한 글이 있으니 읽어보면 크게 도움될 것 같다.

https://portswigger.net/research/server-side-prototype-pollution

Server-side prototype pollution: Black-box detection without the DoS

Server-side prototype pollution is hard to detect black-box without causing a DoS. In this post, we introduce a range of safe detection techniques, which we've also implemented in an open source Burp

portswigger.net

Reference

https://www.hahwul.com/cullinan/attack/prototype-pollution/

https://www.igloo.co.kr/security-information/prototype-pollution-

%EC%B7%A8%EC%95%BD%EC%A0%90%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EA%B3%B5%EA%B2%A9%EC%82%AC%EB%A1%80-%EB%B6%84%EC%84%9D-%EB%B0%8F-%EB%8C%80%EC%9D%91%EB%B0%A9%EC%95%88/

https://portswigger.net/web-security/prototype-pollution

CSP

cloudnaaam — Tue, 24 Jun 2025 11:18:25 +0900

- 이 글은 아직 현업을 경험하지 못한 보안 공부생의 정리 글이니, 정확하지 않을 수도 있습니다.-

CTF 풀 때 CSP를 포함한 문제가 나왔었다.

중간에 계속 헷갈렸었으니 다시 한번 정리해보는 시간을 가져보도록 해보자.

CSP란?

Contents Security Policy. 콘텐츠 보안 정책이라고 한다.

주요 목표는 XSS 공격을 완화하고 보고하는 것이다. 브라우저는 콘텐츠의 출처를 신뢰하기 때문에 공격자가 주입한 악성 스크립트를 실행한다. 때문에 XSS 공격이 발생하는 것이고.

하지만 CSP를 통해서 신뢰할 수 있는 출처나 소스를 지정하면 XSS 공격을 완화할 수 있게 되는 것.

사용 방법은 두 가지가 있는데,

HTTP 헤더

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data: https://*.example.com;

HTML Meta 태그

<meta http-equiv="Content-Security-Policy" content="default-src 'self' 'unsafe-eval' 'unsafe-inline' https:; img-src 'self' data: blob: https:; font-src 'self' data: https:;">

이처럼 HTTP 헤더에 넣거나 Meta 태그에 포함시켜서 CSP를 적용시킬 수 있다.

또한 다양한 지시어가 존재하는데,

default-src	기본적으로 허용되는 리소스 출처를 지정한다.
script-src	스크립트의 출처를 지정한다.
style-src	스타일 시트의 출처를 지정한다.
img-src	이미지의 출처를 지정한다.
media-src	오디오, 비디오와 같은 미디어 파일의 출처를 지정한다.
connect-src	fetch, XMLHttpRequest, Navigator.sendBeacon, WebSocket 등의 HTTP 연결 요청의 출처를 제한한다.
frame-src	iframe의 출처를 지정한다.
object-src	object의 출처를 지정한다.
report-uri	CSP 위반이 발생했을 경우 보고할 URL를 지정한다.
plugin-types	허용할 플러그인의 MIME 타입을 지정한다.
reflected-xss	Reflected XSS 공격을 방지하기 위한 정책 지정.

등이 있다.

이에 매치되는 값들은

self	현재 페이지의 도메인만 허용한다.
none	모든 리소스나 스타일을 차단한다.
unsafe-inline	인라인 스타일이나 스크립트를 허용한다. -- 취약할 수 있음
unsafe-eval	eval() 함수를 사용하여 실행되는 스크립트를 허용한다. -- 취약함
nonce-<value>	nonce 값을 사용하는 스크립트 허용. 보통 nonce값은 예측 불가능하고 계속 바뀌게 설계한다.
hash-<value>	hash 값을 사용하는 스크립트 허용. 보통 sha-256 사용한다.
strict-dynamic	신뢰된 스크립트가 로드하는 스크립트도 허용. 단, nonce나 hash를 사용할 때만 사용 가능.

등이 있다.

사용 예시를 들어보면

Content-Security-Policy: script-src 'nonce-랜덤값' 'strict-dynamic'; object-src 'none'; base-uri 'none';

--> <script nonce='nonce 값'> 이런 식으로 설정된 스크립트와 이 놈이 불러오는 스크립트만 허용

이런 식으로 작동하는 것.

Bypass 하는 방법은 여러 가지가 있다.

와일드 카드를 잘못 썼을 경우, 그러니까

Content-Security-Policy: script-src 'self' http://safesite data: http://*

이런 경우에는

이런 식으로 페이로드 짜면 바로 실행된다. 신뢰 리소스가 http:// 포함한 모든 도메인으로 설정되어 있기 때문에..

혹은 nonce값을 충분히 랜덤한 값으로 설정하지 않는 경우 등이 있는데,

이번 MaltaCTF 롸업 보니까 특이한 케이스도 있더라.

'Content-Security-Policy', "script-src 'sha256-1ltlTOtatSNq5nY+DSYtbldahmQSfsXkeBYmBH5i9dQ=' 'strict-dynamic'; object-src 'none'

CSP는 이렇게 되어 있어서, 초기 신뢰 스크립트 중 스크립트 내용을 해시화한 값이 명시한 값과 같은 스크립트 및 해당 스크립트가 로드한 스크립트 까지만 실행이 가능하다.

여기서 초기 신뢰 스크립트 중 pace.js를 가져오는 스크립트가 존재했는데,

pace.js는 웹 페이지의 로딩 상황을 렌더링해주는 라이브러리인데, 내부에 객체 병합 코드가 존재한다.

defaultOptions window.paceOptions data-pace-options 이 DOM 내부 요소를 병합하는 과정에서 prototype pollution을 통해 취약점이 발생할 수 있다.

때문에 초기에 로드하는 라이브러리 내부의 취약점을 통해서도 CSP를 bypass 할 수도 있다는 것도 알아두면 좋을 것 같다.

Reference

https://velog.io/@gth1123/meta%ED%83%9C%EA%B7%B8-Content-Security-Policy

https://hg2lee.tistory.com/entry/Content-Security-PolicyCSP-Bypass#JSONP%20Callback-1-12

https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/CSP

https://github.com/CodeByZach/pace/issues/546

Webhacking.kr old-42

cloudnaaam — Wed, 28 May 2025 17:58:51 +0900

개발자 모드를 들어가보면

text.txt 다운로드 링크가 있는데, 저 파라미터를 base64 디코딩하면 text.txt가 나온다.

따라서 flag.docx를 base64인코딩 한 후 ?down= 를 통해 들어가주자.

풀었다!

Webhacking.kr g00gle1

cloudnaaam — Tue, 27 May 2025 16:53:18 +0900

구글 폼이 나온다.

근데 둘 중 하나를 누르고 제출하면 0개만 선택하라고 한다.

그래서 처음에는 개발자도구에서 js부분 건드려서 바꾸는 줄 알았다.

근데 개발자도구 뜯어보다가

설마 했는데 이왜진?