저미 보안공부

이번 글은 지금까지 점검·수정해온 Pay1oad 서비스를 실제 서버에 배포하고, 코드를 고친 뒤 재배포하는 과정을 정리한 기록입니다. 백엔드는 AWS EC2에 직접 올리고, 프론트는 Vercel로 배포했습니다. 1. 전체 구성- 백엔드: AWS EC2 (Ubuntu 24.04) + Nginx 리버스 프록시 + PostgreSQL - 프론트: Vercel- 도메인: 가비아 DNS → pay1oad.xyz- HTTPS: certbot 흐름은 "사용자 → pay1oad.xyz(Vercel) → API 요청 → api.pay1oad.xyz(EC2 Nginx → Spring Boot:8000)" 입니다. 2. 백엔드 배포 (EC2)2.1 인스턴스 준비리전을 기본값(시드니)에서 서울로 바꾸고 EC2를 생성했습니다..

오늘은 공격은 안 통했는데 코드를 손봐야 하는 사례입니다. 인증 우회는 재현되지 않았고 보호 데이터도 노출되지 않았습니다. 그런데도 보호 라우트가 비로그인 요청에 HTTP/2 200 + HTML shell을 반환하는 구조는 그대로 두기 어렵습니다. "공격이 성공하지 않았다"가 "안전하다"는 결론은 아니기 때문입니다. 1. 점검 개요- 대상: hxxps://www.pay1oad.xyz- 방식: 외부 관찰 기반 블랙박스 (Burp Suite, OWASP ZAP)- 계정: 비로그인, 일반 회원, 관리자- 범위: 게시글 상세, Content 라우트, 관리자 부원관리- 주요 점검: CVE-2025-29927 방식 헤더 조작, X-Forwarded-Host 조작, 보호 라우트 직접 접근, 관리자 API 재전송 외..

이번에는 React가 절반은 막아주지만 절반은 그대로 통과시키는 어드민 페이지의 입력 검증 결함 이야기입니다. javascript: 같은 위험한 스킴은 React가 자동으로 막아주지만, hxxps://evil.com 같은 형식상 정상인 외부 URL은 그대로 통과합니다. 백엔드에 URL 검증이 없으면 그게 곧 피싱 발판이 됩니다. Open Redirect란, 사이트가 받은 URL 입력을 검증 없이 그대로 이동에 사용해, 사용자를 임의의 외부 사이트로 보내버리는 결함입니다. 신뢰하는 도메인에서 시작한 클릭이 공격자가 정한 피싱 사이트로 이동하기 때문에, 흔히 피싱 공격의 발판으로 쓰입니다. URL 형식 검증과 도메인 화이트리스트로 막는 것이 일반적입니다. 1. 취약점 개요문제의 원인은 어드민 페이지의 지원..

오늘은 sanitization 같지만 실제로는 sanitization이 아닌 코드가 어떻게 credentials: 'include'와 만나 계정 탈취로 이어지는지 살펴봅니다. (2)편에서는 서버가 이메일을 무방비로 받아들이는 Mass Assignment가 주제였다면, 이번 글은 같은 결과(ATO)에 도달하는 다른 출발점 — 프론트엔드의 불완전한 sanitization — 에 관한 이야기입니다. Sanitization 은 사용자가 입력한 데이터에서 위험한 부분을 제거하거나 무력화시키는 작업입니다. 예를 들어 누군가 같은 걸 본문에 적었다면, 이걸 그대로 다른 사용자의 브라우저에 띄우는 순간 onerror 안의 자바스크립트가 실행됩니다. Sanitizer는 이런 위험한 속성(onerror 등)이나 태그( ..

오늘은 단일 취약점으로는 작아 보이지만, Stored XSS와 결합했을 때 관리자 권한까지 통째로 넘어가는 위험천만한 시나리오와 이를 막기 위한 시큐어 코딩 방법을 알아봅니다. 1. 취약점 개요문제의 원인은 프로필 수정 API가 사용자 이메일을 아무런 추가 인증(현재 비밀번호 확인, 이메일 링크 인증 등) 없이 즉시 바꿔주기 때문에 발생합니다.- 취약점명: Mass Assignment via Email Field로 인한 계정 탈취 - 대상: PATCH /v1/users/me - 유형: CWE-915 (Mass Assignment) + CWE-79 (Stored XSS) 연계- 심각도: Critical 1.1 취약점 설명PATCH /v1/users/me는 프로필 수정 API인데, 클라이언트가 보낸 ema..

오늘은 웹 애플리케이션에서 가장 빈번하게 발생하면서도 치명적인 위협 중 하나인 '파일 제출/업로드 기능의 결함'을 분석하고, 이를 AWS EC2 환경에서 어떻게 성공적으로 패치하고 재검증했는지 그 과정을 공유하고자 합니다. 프로젝트나 실무에서 파일 업로드 기능을 구현할 때 "설마 파일 이름으로 공격하겠어?" 하고 방심하기 쉬운 부분들을 짚어보겠습니다. 1. 기존 코드의 취약점과 위험한 공격 시나리오 6가지 기존 코드는 클라이언트가 보낸 원본 파일명(file.getOriginalFilename())을 파일시스템 경로에 그대로 노출하고 있었고, 입력 검증 단계에서도 점(.)의 개수만 확인하는 한계가 있었습니다. 이로 인해 발생할 수 있는 치명적인 시나리오들은 다음과 같습니다. ① 경로 탈출 (Path T..

이번에는 외부 인프라 방어선과 별개로, 실제 백엔드 서비스 소스 코드(파일 업로드 기능) 내부에 숨겨져 있던 치명적인 논리적 결함을 추적해 보겠습니다. 이번 분석의 핵심은 코드에 명백한 설계 결함이 존재함에도 불구하고, 내부 로직의 부수적인 속성(UUID) 때문에 '우연히' 공격이 방어되는 메커니즘을 파헤치는 것입니다. 왜 이런 구조가 위험한지 실습 과정과 소스코드를 통해 자세히 살펴보겠습니다. 1. 모의해킹 실습 및 검증 공격자가 파일 업로드 요청 시 멀티파트(Multipart) 헤더의 filename 값을 변조하여 파일 저장 경로를 탈출하거나 다른 디렉터리에 파일을 생성할 수 있는지 검증을 진행했습니다. 1-1단계: 공격 시도 및 교차 검증 우선 테스트에 사용할 기본 파일인 test.txt를 생성한..

안녕하세요! 이번 글에서는 Spring Framework의 정적 리소스 경로 탐색 취약점인 CVE-2024-38816을 실습 환경에서 검증하던 중, 인프라 레벨의 방어 체계와 실무 소스 코드 내에서 발견한 흥미로운 논리적 결함에 대해 공유하고자 합니다. 취약점 대상 버전이 아님에도 불구하고 실제 서비스 코드에서 어떻게 '위험한 설계'가 방치될 수 있는지, 그리고 왜 이를 보안 검증 단계에서 잡아내야 하는지 상세히 분석해 보았습니다. 1. 실험 환경취약점 검증을 진행한 모의 인프라 환경은 다음과 같습니다.- 프록시 서버: Nginx 1.24.0 (Ubuntu)- 백엔드: Spring Boot 4.0.2 (Spring Framework 7.x 기반, 내장 Tomcat)- OS: Ubuntu (Linux 환..

1. 취약점 개요CVE-2024-38816은 Spring Framework의 경로 탈출(Path Traversal) 취약점이다. 아래 세 가지 조건이 동시에 충족될 때 공격이 가능하다. - RouterFunctions.resources() 사용- FileSystemResource 사용- 서버에 심볼릭 링크 존재 공격자는 URL에 %2e%2e(%로 인코딩된 ..)를 넣어 서버의 임의 파일을 읽을 수 있다. 공격 예시: curl hxxp://localhost:8080/static/link/%2e%2e/etc/passwd결과: /etc/passwd 내용이 그대로 출력됨 2. 패치 후 공격 재시도 - 버전 변경Spring Framework 6.1.13에서 이 취약점이 수정되었다. Spring Boot 기준으로는..

1. 익스플로잇 코드 분석curl http://localhost:8080/static/link/%2e%2e/etc/passwd 1) 취약점 발생 원인- /static/** : 모든 하위 경로를 허용- FileSystemResource : 로컬 파일 직접 접근 - 사용자 입력 경로에 대한 검증 부재 2) 요청 코드 분석- /static/ : 서버 라우팅 경로- link : 심볼릭 링크- %2e%2e : .. (상위 디렉터리 이동) - /etc/passwd : 탈취 대상 파일 3) 경로 해석- link : /static 디렉터리와 연결된 심볼릭 링크 - ../ : 상위 디렉터리로 이동- 최종적으로 /etc/passwd 에 도달 2. 패치 비교 분석1) 입력값 검증 강화 (commit: d86bf8b ..