A place to record the brightest version of myself.
요즘 회사 일이 꽤 바쁘기도 했고, 스스로도 많이 나태해져서 자기계발을 거의 놓다시피 하고 있었다. 정작 몸은 움직이지 않으면서 마음과 꿈만 커져서 이직, 학업, 결혼 같은 거창한 미래들을 동시에 꿈꾸는 중이다. 우선 대학원 진학은 2~3년 전부터 늘 마음속에만 담아두었던 목표였는데, 최근 여자친구의 따뜻한 조언과 응원 덕분에 용기를 내어 마침내 지원을 마치고 결과를 기다리고 있다. 대학원 진학에 따라 생활 지역도 바꿔야 하다 보니 자연스럽게 이직 준비도 병행해야 하고, 여기에 결혼 생각까지 합쳐지니 참 할 일도 많고 마음도 분주하다. 글을 적다 보니 생각이 옆으로 잠시 샜지만, 다시 본론으로 돌아와서...최근 PHP 관련 보안 취약점 이슈도 그렇고, 회사에서 여러 취약점 대응을 진행하면서 문득 들었던 ..
지금까지는 취약점을 재현하고 공격이 어떤 방식으로 동작하는지 확인하는 실습을 주로 진행했다. 이번에는 반대로 시스템에서 발생하는 로그를 모아 확인하는 환경을 만들어보려고 한다.이를 위해 Wazuh를 이용해 개인 실습용 SIEM 환경을 구성했다. 노트북에서 Wazuh 서버를 구동하고, Windows 데스크톱과 그 안에서 실행 중인 CentOS VM에 각각 Wazuh Agent를 설치했다.첫 번째 글에서는 Wazuh 서버 구성부터 두 에이전트의 연결, 실제 이벤트 수집 확인까지 정리한다. 탐지 규칙을 수정하거나 공격을 재현하는 부분은 이후 글에서 다룰 예정이다.세 줄 요약노트북의 Wazuh 서버 VM에서 Windows 데스크톱과 CentOS VM의 로그를 수집한다.서버와 두 에이전트의 버전은 4.14.9이며..
보안 공부를 하다 보면 개념을 이해하는 것과 실제 동작을 확인하는 것 사이에 간격이 생긴다. 방화벽 정책을 배워도 패킷이 어느 단계에서 차단됐는지 확인하기 어렵고, 웹 취약점을 읽어도 정상 요청과 달라진 응답을 직접 비교해 볼 환경이 필요하다.강의용 문제와 풀이를 만들면서도 같은 고민이 있었다. 학습자가 중간에 막혔을 때, 문제 화면에서 힌트를 보고 다시 시도한 뒤 필요한 경우 풀이와 정답까지 이어서 확인할 수 있으면 좋겠다고 생각했다. 그래서 개념 학습 → 직접 실습 → 결과 확인 → 풀이 복습을 한곳에서 할 수 있도록 ROK SECURITY LAB을 만들었다.이번 글에서는 사이트를 만든 이유와 현재 제공하는 인프라·웹해킹 과정을 소개한다.세 줄 요약ROK SECURITY LAB은 네트워크·보안 인프라..
지금까지는 SQL Injection이나 XSS 같은 취약점이 어떤 방식으로 동작하는지, 공격이 가능한 조건은 무엇인지 살펴봤다.그렇다면 반대 입장에서는 어떨까? 시스템에 의심스러운 요청이 들어오거나 누군가 로그인을 반복해서 시도했을 때, 관리자는 어떤 기록을 보고 상황을 파악할 수 있을까?이번에는 공격 구문 자체보다 공격과 시스템의 동작이 어떤 기록으로 남는지에 관심을 가져보려고 한다. 이를 위해 먼저 SIEM의 개념과 기본적인 처리 흐름을 정리하고, 다음 글부터 Wazuh를 이용해 직접 수집 환경을 구성할 예정이다.세 줄 요약SIEM은 여러 시스템의 보안 관련 로그와 이벤트를 모아 검색하고 분석하는 데 사용하는 체계다.중요한 것은 로그를 많이 저장하는 것만이 아니라, 관련 이벤트를 연결해 확인할 상황을..
이번 글에서는 SBOM을 처음 보는 사람도 이해할 수 있도록 개념부터 도구 설치, SBOM 생성, 취약점 스캔, 결과 집계, 서비스별 영향 분석까지 한 번에 정리한다.Docker 이미지로 SBOM을 만들고 Trivy로 스캔하면 Critical/High 취약점이 수백 건씩 쏟아진다. 문제는 이 숫자를 그대로 보고서에 넣을 수 없다는 점이다. 이번 글에서는 스캐너가 뽑아 준 후보 목록을 실제 실행 경로와 공격 재현 여부에 따라 패치 우선순위로 바꾸는 과정까지 다룬다.이번 실습 대상은 MySQL, TeamCity, Spring, Struts, Ollama 다섯 가지 서비스다.단, 이 글의 대상은 직접 구성한 실습 환경이다. 취약점 스캔과 검증은 본인 소유 시스템이나 명시적으로 허가받은 대상에서만 진행해야 한다..
이번 글에서는 Nuclei를 처음 보는 사람도 이해할 수 있도록 개념부터 설치, 템플릿 업데이트, 기본 실행, 파일 기반 점검, 결과 해석까지 한 번에 정리한다.Nuclei는 ProjectDiscovery에서 만든 템플릿 기반 취약점 스캐너다. 쉽게 말하면 “취약점을 찾는 규칙을 YAML 파일로 작성해두고, 그 규칙을 여러 대상에 자동으로 적용하는 도구”라고 보면 된다.수동 점검은 한 번에 하나씩 확인해야 하지만, Nuclei는 같은 점검 로직을 여러 URL, 여러 파일, 여러 서비스에 반복 적용할 수 있다. 그래서 버그바운티, 사내 보안 점검, 취약점 재현 자동화, 설정 노출 점검 등에 자주 사용된다.단, Nuclei는 반드시 본인 소유 시스템이나 명시적으로 허가받은 대상에서만 사용해야 한다.Nucle..
이번 글에서는 지금까지 실습한 Stored XSS, Reflected XSS, DOM XSS, Attribute XSS를 한 번에 정리한다.이전 글에서는 각 취약점을 직접 실행하는 흐름에 집중했다. 이번 글에서는 같은 페이로드가 취약한 페이지와 수정된 페이지에서 어떻게 다르게 동작하는지 비교하고, 실무에서 어떤 방식으로 방어해야 하는지 정리한다.이전 글Stored XSS 실습: https://94-rokstar.tistory.com/entry/XSS-Stored-XSS-%EC%B7%A8%EC%95%BD%EC%A0%90-%EB%B6%84%EC%84%9D%EA%B3%BC-%EC%8B%A4%EC%8A%B5Reflected XSS 실습: https://94-rokstar.tistory.com/entry/XSS-..
이번 글에서는 Edit Form에서 발생하는 Attribute XSS를 실습한다.Stored XSS는 게시글이나 댓글처럼 저장된 값이 다시 출력될 때 발생하고, Reflected XSS는 요청 값이 바로 응답에 반사될 때 발생한다. Attribute XSS는 그중에서도 입력값이 HTML 태그의 속성값 안에 들어갈 때 발생하는 케이스다.예를 들어 아래처럼 사용자 입력이 value 속성 안에 그대로 들어간다고 가정한다.이때 입력값으로 싱글쿼터를 닫고 이벤트 핸들러를 추가하면 브라우저가 새로운 HTML 속성으로 해석할 수 있다.' autofocus onfocus=alert(1) x='즉, 단순히 script 태그만 찾는 방식으로는 막기 어렵고, 출력 위치에 맞는 인코딩이 필요한 취약점이다.STEP 00. 서버..
이번 글은 Stored XSS와 Reflected XSS에 이어, JSR-Test-XSS의 DOM XSS 실습 페이지를 기준으로 클라이언트 측 JavaScript에서 발생하는 XSS를 정리한다. DOM XSS는 서버 응답에 공격 구문이 직접 포함되지 않아도, 브라우저에서 URL 파라미터나 해시 값을 읽어 위험한 방식으로 DOM에 삽입할 때 발생할 수 있다.실습은 로컬 테스트 환경에서만 진행한다.STEP 00. Python 서버 실행먼저 XSS 실습 서버를 실행한다.STEP 01. 실습 페이지 접속브라우저에서 http://127.0.0.1:8001/xss_lab.html로 접속한다. 이번 글에서는 DOM XSS 메뉴를 통해 클라이언트 측 JavaScript에서 발생하는 XSS를 확인한다.STEP 02. D..
이번 글은 Stored XSS에 이어 JSR-Test-XSS의 Search 기능에서 Reflected XSS가 발생하는 과정을 정리한다. Reflected XSS는 사용자가 입력한 값이 서버 응답에 바로 반사되고, 브라우저가 이를 HTML 또는 JavaScript로 해석하면서 발생한다.실습은 로컬 테스트 환경에서만 진행한다.STEP 01. 실습 페이지 접속브라우저에서 http://127.0.0.1:8001/xss_lab.html로 접속한다. 메인 페이지의 Lab Modules에서 Search 기능이 Reflected XSS 실습 포인트임을 확인할 수 있다.STEP 02. Search 페이지 확인Search 메뉴로 이동하면 q 파라미터를 입력받는 검색 폼이 출력된다. 이 기능은 사용자가 입력한 검색어를 응..
요즘 회사 일이 꽤 바쁘기도 했고, 스스로도 많이 나태해져서 자기계발을 거의 놓다시피 하고 있었다. 정작 몸은 움직이지 않으면서 마음과 꿈만 커져서 이직, 학업, 결혼 같은 거창한 미래들을 동시에 꿈꾸는 중이다. 우선 대학원 진학은 2~3년 전부터 늘 마음속에만 담아두었던 목표였는데, 최근 여자친구의 따뜻한 조언과 응원 덕분에 용기를 내어 마침내 지원을 마치고 결과를 기다리고 있다. 대학원 진학에 따라 생활 지역도 바꿔야 하다 보니 자연스럽게 이직 준비도 병행해야 하고, 여기에 결혼 생각까지 합쳐지니 참 할 일도 많고 마음도 분주하다. 글을 적다 보니 생각이 옆으로 잠시 샜지만, 다시 본론으로 돌아와서...최근 PHP 관련 보안 취약점 이슈도 그렇고, 회사에서 여러 취약점 대응을 진행하면서 문득 들었던 ..
지금까지는 취약점을 재현하고 공격이 어떤 방식으로 동작하는지 확인하는 실습을 주로 진행했다. 이번에는 반대로 시스템에서 발생하는 로그를 모아 확인하는 환경을 만들어보려고 한다.이를 위해 Wazuh를 이용해 개인 실습용 SIEM 환경을 구성했다. 노트북에서 Wazuh 서버를 구동하고, Windows 데스크톱과 그 안에서 실행 중인 CentOS VM에 각각 Wazuh Agent를 설치했다.첫 번째 글에서는 Wazuh 서버 구성부터 두 에이전트의 연결, 실제 이벤트 수집 확인까지 정리한다. 탐지 규칙을 수정하거나 공격을 재현하는 부분은 이후 글에서 다룰 예정이다.세 줄 요약노트북의 Wazuh 서버 VM에서 Windows 데스크톱과 CentOS VM의 로그를 수집한다.서버와 두 에이전트의 버전은 4.14.9이며..
보안 공부를 하다 보면 개념을 이해하는 것과 실제 동작을 확인하는 것 사이에 간격이 생긴다. 방화벽 정책을 배워도 패킷이 어느 단계에서 차단됐는지 확인하기 어렵고, 웹 취약점을 읽어도 정상 요청과 달라진 응답을 직접 비교해 볼 환경이 필요하다.강의용 문제와 풀이를 만들면서도 같은 고민이 있었다. 학습자가 중간에 막혔을 때, 문제 화면에서 힌트를 보고 다시 시도한 뒤 필요한 경우 풀이와 정답까지 이어서 확인할 수 있으면 좋겠다고 생각했다. 그래서 개념 학습 → 직접 실습 → 결과 확인 → 풀이 복습을 한곳에서 할 수 있도록 ROK SECURITY LAB을 만들었다.이번 글에서는 사이트를 만든 이유와 현재 제공하는 인프라·웹해킹 과정을 소개한다.세 줄 요약ROK SECURITY LAB은 네트워크·보안 인프라..
지금까지는 SQL Injection이나 XSS 같은 취약점이 어떤 방식으로 동작하는지, 공격이 가능한 조건은 무엇인지 살펴봤다.그렇다면 반대 입장에서는 어떨까? 시스템에 의심스러운 요청이 들어오거나 누군가 로그인을 반복해서 시도했을 때, 관리자는 어떤 기록을 보고 상황을 파악할 수 있을까?이번에는 공격 구문 자체보다 공격과 시스템의 동작이 어떤 기록으로 남는지에 관심을 가져보려고 한다. 이를 위해 먼저 SIEM의 개념과 기본적인 처리 흐름을 정리하고, 다음 글부터 Wazuh를 이용해 직접 수집 환경을 구성할 예정이다.세 줄 요약SIEM은 여러 시스템의 보안 관련 로그와 이벤트를 모아 검색하고 분석하는 데 사용하는 체계다.중요한 것은 로그를 많이 저장하는 것만이 아니라, 관련 이벤트를 연결해 확인할 상황을..
이번 글에서는 SBOM을 처음 보는 사람도 이해할 수 있도록 개념부터 도구 설치, SBOM 생성, 취약점 스캔, 결과 집계, 서비스별 영향 분석까지 한 번에 정리한다.Docker 이미지로 SBOM을 만들고 Trivy로 스캔하면 Critical/High 취약점이 수백 건씩 쏟아진다. 문제는 이 숫자를 그대로 보고서에 넣을 수 없다는 점이다. 이번 글에서는 스캐너가 뽑아 준 후보 목록을 실제 실행 경로와 공격 재현 여부에 따라 패치 우선순위로 바꾸는 과정까지 다룬다.이번 실습 대상은 MySQL, TeamCity, Spring, Struts, Ollama 다섯 가지 서비스다.단, 이 글의 대상은 직접 구성한 실습 환경이다. 취약점 스캔과 검증은 본인 소유 시스템이나 명시적으로 허가받은 대상에서만 진행해야 한다..
이번 글에서는 Nuclei를 처음 보는 사람도 이해할 수 있도록 개념부터 설치, 템플릿 업데이트, 기본 실행, 파일 기반 점검, 결과 해석까지 한 번에 정리한다.Nuclei는 ProjectDiscovery에서 만든 템플릿 기반 취약점 스캐너다. 쉽게 말하면 “취약점을 찾는 규칙을 YAML 파일로 작성해두고, 그 규칙을 여러 대상에 자동으로 적용하는 도구”라고 보면 된다.수동 점검은 한 번에 하나씩 확인해야 하지만, Nuclei는 같은 점검 로직을 여러 URL, 여러 파일, 여러 서비스에 반복 적용할 수 있다. 그래서 버그바운티, 사내 보안 점검, 취약점 재현 자동화, 설정 노출 점검 등에 자주 사용된다.단, Nuclei는 반드시 본인 소유 시스템이나 명시적으로 허가받은 대상에서만 사용해야 한다.Nucle..
이번 글에서는 지금까지 실습한 Stored XSS, Reflected XSS, DOM XSS, Attribute XSS를 한 번에 정리한다.이전 글에서는 각 취약점을 직접 실행하는 흐름에 집중했다. 이번 글에서는 같은 페이로드가 취약한 페이지와 수정된 페이지에서 어떻게 다르게 동작하는지 비교하고, 실무에서 어떤 방식으로 방어해야 하는지 정리한다.이전 글Stored XSS 실습: https://94-rokstar.tistory.com/entry/XSS-Stored-XSS-%EC%B7%A8%EC%95%BD%EC%A0%90-%EB%B6%84%EC%84%9D%EA%B3%BC-%EC%8B%A4%EC%8A%B5Reflected XSS 실습: https://94-rokstar.tistory.com/entry/XSS-..
이번 글에서는 Edit Form에서 발생하는 Attribute XSS를 실습한다.Stored XSS는 게시글이나 댓글처럼 저장된 값이 다시 출력될 때 발생하고, Reflected XSS는 요청 값이 바로 응답에 반사될 때 발생한다. Attribute XSS는 그중에서도 입력값이 HTML 태그의 속성값 안에 들어갈 때 발생하는 케이스다.예를 들어 아래처럼 사용자 입력이 value 속성 안에 그대로 들어간다고 가정한다.이때 입력값으로 싱글쿼터를 닫고 이벤트 핸들러를 추가하면 브라우저가 새로운 HTML 속성으로 해석할 수 있다.' autofocus onfocus=alert(1) x='즉, 단순히 script 태그만 찾는 방식으로는 막기 어렵고, 출력 위치에 맞는 인코딩이 필요한 취약점이다.STEP 00. 서버..
이번 글은 Stored XSS와 Reflected XSS에 이어, JSR-Test-XSS의 DOM XSS 실습 페이지를 기준으로 클라이언트 측 JavaScript에서 발생하는 XSS를 정리한다. DOM XSS는 서버 응답에 공격 구문이 직접 포함되지 않아도, 브라우저에서 URL 파라미터나 해시 값을 읽어 위험한 방식으로 DOM에 삽입할 때 발생할 수 있다.실습은 로컬 테스트 환경에서만 진행한다.STEP 00. Python 서버 실행먼저 XSS 실습 서버를 실행한다.STEP 01. 실습 페이지 접속브라우저에서 http://127.0.0.1:8001/xss_lab.html로 접속한다. 이번 글에서는 DOM XSS 메뉴를 통해 클라이언트 측 JavaScript에서 발생하는 XSS를 확인한다.STEP 02. D..
이번 글은 Stored XSS에 이어 JSR-Test-XSS의 Search 기능에서 Reflected XSS가 발생하는 과정을 정리한다. Reflected XSS는 사용자가 입력한 값이 서버 응답에 바로 반사되고, 브라우저가 이를 HTML 또는 JavaScript로 해석하면서 발생한다.실습은 로컬 테스트 환경에서만 진행한다.STEP 01. 실습 페이지 접속브라우저에서 http://127.0.0.1:8001/xss_lab.html로 접속한다. 메인 페이지의 Lab Modules에서 Search 기능이 Reflected XSS 실습 포인트임을 확인할 수 있다.STEP 02. Search 페이지 확인Search 메뉴로 이동하면 q 파라미터를 입력받는 검색 폼이 출력된다. 이 기능은 사용자가 입력한 검색어를 응..