A place to record the brightest version of myself.
지금까지는 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 파라미터를 입력받는 검색 폼이 출력된다. 이 기능은 사용자가 입력한 검색어를 응..
이번 글은 JSR-Test-XSS 실습 서버를 실행한 뒤, 게시판 기능에서 Stored XSS가 발생하는 과정을 단계별로 정리한다. 사용자가 입력한 값이 서버에 저장되고, 이후 페이지에 다시 출력될 때 스크립트가 실행되는 흐름을 확인한다.실습은 로컬 테스트 환경에서만 진행한다.STEP 00. Python 서버 실행먼저 XSS 실습 서버를 실행한다.python3 xss_jsr.pySTEP 01. 실습 페이지 접속 및 Board 확인브라우저에서 http://127.0.0.1:8001/xss_lab.html로 접속한 뒤 Stored XSS 실습을 위해 Board 메뉴로 이동한다. 화면 상단에는 실습용 쿠키가 함께 출력되며, 이후 document.cookie 페이로드로 이 값이 노출되는지 확인한다.STEP 02..
이번 글은 Oracle 스타일의 SQL Injection 실습 서버에서 화면에 데이터가 직접 출력되지 않는 상황을 가정하고, 응답 시간이 지연되는지 여부로 조건의 참/거짓을 판단하는 과정을 정리한다.실습은 로컬 테스트 환경에서만 진행한다.STEP 01. 기본 지연 함수 확인먼저 DBMS_PIPE.RECEIVE_MESSAGE를 직접 호출해 서버 응답이 의도적으로 지연되는지 확인한다. 이 요청은 조건과 관계없이 3초 지연을 발생시키는 기본 동작 확인용이다.STEP 02. 참 조건에서 지연 확인CASE WHEN 조건이 참일 때만 DBMS_PIPE.RECEIVE_MESSAGE가 실행되도록 구성한다. 1=1은 참이므로 응답이 약 3초 지연된다.STEP 03. 거짓 조건에서 지연 없음 확인1=2는 거짓이므로 정상적..
이번 글은 Oracle 스타일의 SQL Injection 실습 서버에서 화면에 직접 데이터가 출력되지 않지만 Blind SQL Injection으로 데이터를 추출하는 과정을 정리했다.실습은 로컬 테스트 환경에서만 진행한다.STEP 01. 참 조건 확인Blind SQL Injection에서는 조건이 참일 때와 거짓일 때의 응답 차이를 먼저 확인한다. 1=1 조건이 참이면 기존 검색 결과가 출력된다.STEP 02. 거짓 조건 확인1=2 조건은 거짓이므로 검색 결과가 출력되지 않는다. 이후에는 이 차이를 이용해 길이와 문자를 하나씩 확인한다.STEP 03. DB 이름 길이 범위 확인먼저 DB 이름 길이를 찾기 위해 너무 큰 조건을 넣어 거짓 응답을 확인한다.STEP 04. DB 이름이 존재하는지 확인길이가 0..
지금까지는 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 파라미터를 입력받는 검색 폼이 출력된다. 이 기능은 사용자가 입력한 검색어를 응..
이번 글은 JSR-Test-XSS 실습 서버를 실행한 뒤, 게시판 기능에서 Stored XSS가 발생하는 과정을 단계별로 정리한다. 사용자가 입력한 값이 서버에 저장되고, 이후 페이지에 다시 출력될 때 스크립트가 실행되는 흐름을 확인한다.실습은 로컬 테스트 환경에서만 진행한다.STEP 00. Python 서버 실행먼저 XSS 실습 서버를 실행한다.python3 xss_jsr.pySTEP 01. 실습 페이지 접속 및 Board 확인브라우저에서 http://127.0.0.1:8001/xss_lab.html로 접속한 뒤 Stored XSS 실습을 위해 Board 메뉴로 이동한다. 화면 상단에는 실습용 쿠키가 함께 출력되며, 이후 document.cookie 페이로드로 이 값이 노출되는지 확인한다.STEP 02..
이번 글은 Oracle 스타일의 SQL Injection 실습 서버에서 화면에 데이터가 직접 출력되지 않는 상황을 가정하고, 응답 시간이 지연되는지 여부로 조건의 참/거짓을 판단하는 과정을 정리한다.실습은 로컬 테스트 환경에서만 진행한다.STEP 01. 기본 지연 함수 확인먼저 DBMS_PIPE.RECEIVE_MESSAGE를 직접 호출해 서버 응답이 의도적으로 지연되는지 확인한다. 이 요청은 조건과 관계없이 3초 지연을 발생시키는 기본 동작 확인용이다.STEP 02. 참 조건에서 지연 확인CASE WHEN 조건이 참일 때만 DBMS_PIPE.RECEIVE_MESSAGE가 실행되도록 구성한다. 1=1은 참이므로 응답이 약 3초 지연된다.STEP 03. 거짓 조건에서 지연 없음 확인1=2는 거짓이므로 정상적..
이번 글은 Oracle 스타일의 SQL Injection 실습 서버에서 화면에 직접 데이터가 출력되지 않지만 Blind SQL Injection으로 데이터를 추출하는 과정을 정리했다.실습은 로컬 테스트 환경에서만 진행한다.STEP 01. 참 조건 확인Blind SQL Injection에서는 조건이 참일 때와 거짓일 때의 응답 차이를 먼저 확인한다. 1=1 조건이 참이면 기존 검색 결과가 출력된다.STEP 02. 거짓 조건 확인1=2 조건은 거짓이므로 검색 결과가 출력되지 않는다. 이후에는 이 차이를 이용해 길이와 문자를 하나씩 확인한다.STEP 03. DB 이름 길이 범위 확인먼저 DB 이름 길이를 찾기 위해 너무 큰 조건을 넣어 거짓 응답을 확인한다.STEP 04. DB 이름이 존재하는지 확인길이가 0..