catseoul2

[Medium] Security Vulnerabilities in Autonomous AI Agents

범호야 — Mon, 17 Nov 2025 10:05:12 +0900

LLM 기반 어시스턴트, 작업 지향 봇, API기반 에이전트와 같은 자율 AI 에이전트는 브라우저, 클라우드 서비스, 모바일 앱 전반에 걸쳐 배포되고 있다.

외부 도구와 상호작용하고, 작업을 수행할 수 있다는 장점이 있는 반면에 동시에 새로운 보안 위협을 야기할 수 있다.

AI 에이전트는 입력이나 환경이 악의적으로 조작될 경우 의도치 않은 동작을 하도록 조작 가능

자율 AI 에이전트의 주요 취약점 AI에 특화된 가장 중요한 위협

프롬젝트 인젝션 : LLM 기반 시스템에서 가장 두드러지는 취약점

공격자는 모델이 개발자의 지시를 무시하고 공격자의 지시를 따르도록 하는 입력을 조작 - 공격자의 프롬포트는 모델이 합법적인 지시와 구별할 수 없는 방식으로 모델의 컨텍스트에 주입된다.

-> LLM이 의도치 않은 방식으로 동작이나 출력을 변경하여 안전 지침을 위반하거나 기밀 데이터 유출이나 무단 작업 수행 가능

ai 에이전트를 사용하여 프롬포트를 통해 데이터베이스를 덤프

화면 오른쪽에 사용자 인증되지 않았다는 오류가 표시되는 동안에도 절반 정도의 응답이 가능했다. 단순한 주입 공격이 아닌, 권한 부여 우회와 신속한 주입 공격을 병행하여 데이터 베이스를 탈취한 것이다.

연구원들은 Gmail API에 접근하는 이메일 요약 에이전트에 특수하게 조작된 이메일을 받은 편지함으로 전송하여 공격을 시연했다. 주입된 프롬프트는 에이전트에게 요약 작업을 무시하고 받은 편지함의 비밀을 공격자의 이메일 주소로 전달하도록 지시했고, 에이전트는 이를 실행했다. 더 심각한 것은 에이전트가 공격자의 지시에 따라 악성 이메일을 삭제하여 흔적을 감췄다는 것이다.

모델 조작 및 백도어

악의적인 모델 버전 또는 임의로 조작된 체크포인트를 주입하여 특정 입력을 받았을 때 공격자의 의도대로 행동하도록 만드는 공격- - 외부 오픈소스 모델을 그대로 사용할 때 특히 취약

"DarkMind" 공격은 모델이 특정 사고 연쇄 추론 시퀀스에 참여할 때까지 잠복하는 적대적 명령을 내장. 트리거는 초기 사용자 프롬프트에는 전혀 나타나지 않고, 모델의 내부 추론 단계에서 활성화되어 탐지를 피하면서 부정확하거나 유해한 출력을 생성.
이러한 은밀한 백도어는 AI 에이전트가 프롬프트 인터페이스보다 더 깊은 수준에서 조작 될 수 있음을 보여줌 .
훈련 또는 미세 조정 데이터를 제공할 수 있는 공격자(또는 모델 공급망을 침해하는 공격자)는 특정 조건에서만 모델이 따르도록 하는 명령어를 심어놓을 수 있습니다.
이는 모델 조작 취약점으로, 에이전트의 의사 결정 논리 자체가 "교활한" 공격자에 의해 적대적인 행동으로 왜곡되거나 강요 될 수 있다. 그 영향은 출력의 미묘한 편향부터 트리거가 활성화될 때의 완전히 잘못되거나 위험한 행동까지 다양. 누구나 런타임에 시도할 수 있는 즉각적인 주입과 달리, 백도어 공격은 일반적으로 업스트림 접근(훈련 또는 모델 파일)을 필요로 하지만, 백도어가 존재한다는 것은 에이전트가 생성될 때부터 잠재적인 취약점을 가지고 있을 수 있음을 의미.

데이터 포이즈닝

AI가 학습하거나 개선에 사용하는 데이터를 조작하여 모델의 판단을 왜곡하거나 특정 패턴에서 이상한 출력을 유도할 수 있다.

에이전트가 스스로 데이터를 수집하는 경우 위험도가 증가

- 초기학습 -> 미세 조정단계나 즉석 학습

- 데이터 공급망 취약점 -> 저장소에 공유된 모델이 트로이 목마에 감염될 수도

무단 API 접근 및 도구 오용

에이전트에게 과도한 권한이 있을 경우 외부 API, 데이터베이스, 파일 시스템 등을 공격자가 유도한 행동으로 오용할 수 있다.

예: API 키 노출, 파일 삭제, 비용 폭탄 유발 등

AI 에이전트를 통한 기타 SSRF 벡터

에이전트가 웹 요청을 직접 보내는 기능을 가질 경우, 공격자는 프롬프트를 이용해 내부 네트워크로 요청을 보내게 한다.

이를 통해 시스템 내부 자원 탐색, 민감한 엔드포인트 접근 등이 가능해짐

SSRF
공격자가 서버에게 ‘원래 의도하지 않은 곳’으로 요청을 보내도록 속이는 공격
- 클라이언트(공격자)가 직접 접근할 수 없는 내부 네트워크나 민감한 주소에 서버가 대신 요청을 보내도록 유도하는 것.

과도한 허가와 과도한 행위

에이전트가 필요 이상의 권한을 보유하면 작은 프롬프트 조작만으로도 과도하게 위험한 행동을 수행할 수 있다

권한 최소화 원칙(Principle of Least Privilege)을 위반할 때 발생.

악의적인 명령어 체이닝

에이전트는 작업을 여러 단계로 연결하는 경우가 많은데, 공격자는 이를 악용해 무해한 요청 속에 악의적인 행동 단계를 은밀히 삽입할 수 있음.

에이전트의 자체 계획(Planning) 기능이 오히려 공격 체인을 강화시키는 결과가 나올 수 있음

[출처]https://fdzdev.medium.com/security-vulnerabilities-in-autonomous-ai-agents-26f905b2dc36

[워게임 공부] XOR과 실습 코드

범호야 — Wed, 12 Nov 2025 13:13:09 +0900

XOR

입력이 서로 다른 경우에만 참인 논리 연산

암호화에서의 응용

메시지를 암복호화 하는데 사용될 수 있다. 메세지를 키와 XOR 연산하면 같은 키로 XOR 연산을 수행하여 원래 메세지를 복원할 수 있다.

혼돈과 확산을 구현할 수 있다.

활용 사례

- One Time Pad

- 스트림 암호

- 블록 암호 내부 구조

- 해시 함수 및 MAC

- 디지털 서명, 난수 생성기 내부

한계

단독으로는 매우 약한 암호화 방식 -> 같으 키 재사용 시 패턴이 노출되므로 난수 키 생성기, 블럭 암호 구조, 패딩 등과 함꼐 사용해아 한다.

실습코드

import sys
sys.stdout.reconfigure(encoding='utf-8')

def xor_byte(data, byte):
    return data ^ byte

def main():
    hex_string = "54586b6458754f7b215c7c75424f21634f744275517d6d"
    hex_list = [int(hex_string[i:i+2], 16) for i in range(0, len(hex_string), 2)]

    for xor_value in range(256):
        result_data = [xor_byte(h, xor_value) for h in hex_list]
        result_string = ''.join([format(x, '02X') for x in result_data])

        # ASCII로 변환하되, 출력 가능한 문자만 표시
        ascii_result = ''.join([chr(x) if 32 <= x <= 126 else '.' for x in result_data])

        print(f"XOR 0x{xor_value:02X} Result: {result_string}, ASCII: {ascii_result}")

if __name__ == "__main__":
    main()

1. 인코딩 설정

2. XOR 연산 함수

3. 메인 함수 - 복호화할 암호문 삽입

4. 16진수를 정수 리스트로 변환 - hex_string을 두 자리씩 잘라서 각 조각을 16진수에서 10진수로 변환

5. 모든 XOR 키에 대해 시도 - 바이트 단위이기 때문에 0~155 에 대해 모두 시도

6. 각 바이트에 XOR 적용 - 각 원소에 xor_value를 XOR

7. 결과를 16진수로 표시

8. 아스키로 변환 - 출력 가능한 문자만

9. 결과 출력

10. 프로그램 실행

[워게임]single byte xor

범호야 — Wed, 12 Nov 2025 13:04:59 +0900

54586b6458754f7b215c7c75424f21634f744275517d6d -> 이게 단일 바이트와 XOR해서 만들어진 암호라 하였으므로 얘를 이용하여 문제를 해결할 수 있다.

import sys
sys.stdout.reconfigure(encoding='utf-8')

def xor_byte(data, byte):
    return data ^ byte

def main():
    hex_string = "54586b6458754f7b215c7c75424f21634f744275517d6d"
    hex_list = [int(hex_string[i:i+2], 16) for i in range(0, len(hex_string), 2)]

    for xor_value in range(256):
        result_data = [xor_byte(h, xor_value) for h in hex_list]
        result_string = ''.join([format(x, '02X') for x in result_data])

        # ASCII로 변환하되, 출력 가능한 문자만 표시
        ascii_result = ''.join([chr(x) if 32 <= x <= 126 else '.' for x in result_data])

        print(f"XOR 0x{xor_value:02X} Result: {result_string}, ASCII: {ascii_result}")

if __name__ == "__main__":
    main()

DH{tHe_k1LleR_1s_dReAm}

[Medium]The Privacy Comeback: Web3 Identity After Cookies

범호야 — Tue, 11 Nov 2025 16:53:27 +0900

지금까지의 웹 마케팅은 제 3자 쿠키를 활용하여 사용자의 웹 활동을 추적하고, 여러 사이트에 걸쳐 프로파일을 만들고 이를 광고 등에 활용해왔다.

하지만 점차 post-cookie 시대가 다가오고 있다.

제 3자 쿠키를 대체하는 것이 웹 아이덴티티 개념이다.

- 분산 식별자 : 공개 키와 서비스 엔드포인트를 나열하는 문서(네트워크에 연결되거나 앵커링된 문서)로 해결된다. 키를 회전하고 동일한 DID를 유지하고, 중앙 레지스트리가 필요하지 않다.

- 검증 가능한 자격증명 : 신뢰할 수 있는 사람(은행, 대학, 브랜드)이 발급한 디지털 서명 청구서이다.

- 제로지식 증명 : 기본 데이터를 공개하지 않고 진술을 증명한다.

간단한 post cookie 개인화 아키텍처

작동 패턴

1. 크리프 없는 충성심 -> 데이터 최소화 + 동의 기반 맞춤화

리테일러가 ‘골드 회원’에게 VC 형태의 디지털 회원증을 발급한다.
결제 시, 사용자는 “Gold tier = true”라는 ZK Proof만 제시한다.
사이트는 할인과 VIP 혜택을 적용하지만, 이메일·쿠키·픽셀 추적은 전혀 없다.
회원 등급이 바뀌면 VC가 폐기되어, 다음 접속 시 자동으로 반영된다.

2. 연령 제한 콘텐츠, 프라이버시 보호 -> 나이 증명, 신원 노출 없음

미디어 사이트가 성인 인증(18+)을 요구한다.
사용자는 정부 발급 ‘연령 VC’에서 나이 범위만 증명하는 ZK Range Proof를 생성한다.
사이트는 생년월일도, 신분증 번호도 보지 않는다.
오직 boolean(true/false) 값과 timestamp만 확인한다.

3. 연맹의 올바른 판단 -> 연동 가능 감시 자본주의 차단

여러 출판사가 하나의 구독 플랫폼에서 발급한 Reader-pass VC를 공동으로 수용한다.
각 출판사는 자체적으로 증명서를 검증하고,
분석은 “얼마나 많은 증명이 발생했는가”만 집계한다.

함정

1. 감사를 위해 원본 데이터 보관 금지

2. 긴 이용약관 속에 동의 숨기기 금지

3. 지갑 UX를 다크 패턴으로 만들지 말기

// 1) 서버가 세션용 challenge 생성
const challenge = base64url(randomBytes(32));
await kv.set(`nonce:${sessionId}`, challenge, { ttl: 300 });

// 2) 클라이언트가 DID 키로 서명하고 VC proof 첨부
const assertion = await wallet.sign({
  did: userDID,
  payload: { challenge, aud: "https://brand.example" }
});
const zkProof = await wallet.prove("isGoldTier"); // boolean proof, no PII

// 3) 서버가 서명 + 증명 검증 후 세션 토큰 발급
const didDoc = await resolveDID(userDID);
const ok = verifySignature(assertion, didDoc.publicKey);
const proofOk = verifyZK(zkProof, { circuit: "gold-tier" });

if (ok && proofOk) {
  const token = signJWT({
    sub: userDID,
    scope: ["offers:read", "support:priority"],
    consentExp: "2026-12-31"
  });
  reply.cookie("session", token, { httpOnly: true, sameSite: "Lax" });
}

DID Auth in Practice
실제 로그인 예시
서버는 토큰의 스코프와 동의 만료일만 저장하고 원본 VC는 저장하지 않는다.

Measuring What Matters (익명 분석 모델)

이벤트 단위 분석: “Gold proof → 구매” 같은 증명 기반 전환율만 집계.
증명 단위 증분 실험: proof 수준의 홀드아웃 그룹으로 성과 비교.
목적 제한 식별자: 1st-party 도메인 내 한정 ID 사용, 행(row) 단위 공유 금지.

Passkeys vs Web3 Identity

Passkeys는 인증(Authentication)만 해결한다.
→ 비밀번호 대체에는 좋지만 “무엇을 증명(prove)”해야 하는지는 해결하지 못한다.
Web3 Identity는 그 위층의 권한(Authorization) 문제를 해결한다.
→ 사용자가 필요한 사실만 휴대하고, 맥락 간 이동 가능한 이동형 신원(portable identity)을 만든다.

Governance — 신뢰의 비가시적 기둥

Trust Registry: 누가 어떤 VC를 발급할 수 있는지 투명한 목록 유지.
Revocation Check: VC 유효성은 암호학적 리스트/누산기(accumulator)로 검증.
Key Rotation: 키 교체 지원은 필수. 사용자는 기록을 잃지 않아야 함.
UX Standards:
- “할인 혜택용 Gold 등급 증명 공유할까요?”
- 목적과 만료일을 명확히 표시.

“Post-cookie identity isn’t the end of personalization; it’s the end of entitlement.”

[출처]https://medium.com/@Nexumo_/the-privacy-comeback-web3-identity-after-cookies-9beb3001e925

[IGLOO] 생성형 AI 기반 개발도구의 잠재적 보안위협과 대응방안

범호야 — Tue, 4 Nov 2025 23:17:47 +0900

1. 인공지능 기반 개발 환경의 등장과 새로운 보안 리스크

오늘날 인공지능(AI) 기술의 발전이 가속화되면서 소프트웨어 개발 환경 또한 무섭게 진화한다. AI 기반 개발 도구가 보편화되면서 개발 효율성이 비약적으로 향상되었지만, ‘신뢰할 수 없는 코드‘와 ‘의도치 않는 정보유출’ 관점에서 우리는 새로운 보안 리스크에 직면한다.

AI는 태생적인 한계로 인해 코드 생성 과정에서 고객사가 정한 보안 규칙을 준수하지 않거나, 의도치 않게 보안에 취약한 코드 패턴을 제시할 수 있다. 이로 인해 정보 유출의 가능성은 항상 존재한다.

주요 잠재적 위협 요소는

• 자동 생성 코드의 불확실성.

• 훈련 데이터 한계.

• 외부 데이터 및 플러그인 의존.

국내외 보안 전문 기관 및 단체(NIST, OWASP 등)는 AI 기반 개발 도구가 내포할 수 있는 잠재적 보안 위협을 정의하고 이에 대한 대응 방안을 제시한다.

2. AI 기반 개발 도구의 최근 보안 취약점 및 대응 현황 (Cursor AI 중심)

AI 기반 개발 도구의 활용이 점차 확대되고 의존도가 높아짐에 따라 관련 보안 취약점 또한 지속적으로 발견되며 이에 대한 개선 노력도 이어진다. 현재 널리 활용되는 AI 기반 개발 도구 중 하나는 'Cursor AI'이다. 이 도구는 Visual Studio Code를 기반으로 하며, 자연어 명령을 통해 코드 작성, 리팩토링, 디버깅 등을 지원해 개발자들의 생산성을 크게 향상시킨다.

최근 발견된 Cursor AI의 주요 보안 취약점과 이에 대한 조치 내용은 다음과 같다.

취약점 유형	설명	조치/해결 현황
터미널 명령어 주입 취약점 (CVE-2024-48919)	악의적인 웹 페이지를 호출할 경우, 공격자가 해당 웹 페이지를 통해 사용자의 터미널에서 임의의 명령어를 실행할 수 있다.	2024년 9월 27일 서버 측 패치가 적용되었으며, Cursor 0.42 버전에서는 클라이언트 측 완화 조치가 추가되었다.
Rules File Backdoor 공격	공급망 공격 벡터의 일환으로, 공격자가 Cursor의 규칙 파일에 악성 지침을 삽입하여 AI가 생성하는 코드에 보안 취약점을 유발한다.	Cursor AI 규칙 파일의 무결성 검증을 강화하고, 사용자에게 신뢰할 수 있는 규칙 파일만 사용하도록 권장한다.
파일 시스템 접근 권한 문제	사용자가 터미널에서 명령어를 실행할 때, AI가 현재 작업 공간 외부의 디렉토리까지 접근하여 민감한 파일에 접근할 수 있다.	Cursor AI의 파일 시스템 접근을 제한하고, 작업 공간 외부의 디렉토리 접근을 방지하기 위한 조치를 강화했다.
Mac OS 카메라 및 마이크 접근 취약점 (CVE-2024-45599)	Mac OS에서 Cursor AI가 카메라나 마이크에 접근할 수 있는 권한을 부여받은 경우, 악의적인 코드가 이를 무단으로 사용 가능했다.	Cursor 0.41.0 버전에서는 프로세스별 권한 분리를 통해 이 취약점을 해결했다.

3. 정보 유출 차단을 위한 실전 보안 설정 방안 (Cursor AI 중심)

생성형 AI 기반 서비스는 기본적으로 외부 클라우드 연결을 전제로 하므로, 개발 도구 환경 설정이 미흡할 경우 기밀 정보 유출, 소스 코드 노출 등의 보안 리스크가 발생할 수 있다. 따라서 개발 도구의 보안 설정을 정확히 이해하고 철저히 이행하는 것이 중요하다.

3.1. 1) Privacy Mode 활성화 및 API 키 값 설정

Cursor AI의 프라이버시 모드(Privacy Mode)는 코드와 데이터의 보안을 강화하기 위한 기능이다. 이 모드를 활성화하면 AI가 코드베이스를 인덱싱하거나 외부 서버로 데이터를 전송하지 않도록 설정되어 민감한 정보를 보호할 수 있다.

프라이버시 모드를 활성화하고 API 키를 사용하게 되면, Cursor AI의 개입 없이 직접 LLM에 요청을 전달할 수 있어 보안을 강화할 수 있다 (다만, 이용자 API 키 값이 유출되지 않도록 주의해야 한다).

3.2. 2) 데이터 인덱싱 비활성화

특정 디렉토리나 파일 접근을 제한하여 보안성을 높일 수 있다. 인덱싱 비활성화는 AI에게 인덱스를 통해 접근 제한을 하는 것일 뿐, 이용자가 수동적으로 코드를 실행하거나 열람하는 것을 막지는 못한다. 본질적으로 보안 수준을 높이기 위해서는 개발 코드를 자체적으로 암호화해야 한다.

• .cursorignore 파일 설정: Cursor AI가 자동 코드 추천, AI 분석, 인덱싱 시 무시해야 할 파일이나 디렉토리를 사전에 지정할 수 있다. .gitignore처럼 특정 경로나 파일을 지정해 AI의 컨텍스트 범위에서 제외하는 것이 가능하다.

• .cursorindexignore 파일 설정: Cursor AI가 코드베이스를 스캔(인덱싱)할 때, 어떤 파일이나 폴더는 무시하고 건너뛰게 만드는 설정 파일이다. .gitignore처럼 특정 경로나 파일을 지정해 AI의 컨텍스트 범위에서 제외한다.

3.3. 3) Rules for AI 설정

Cursor AI의 규칙 파일(Rules)을 통해 특정 코드 접근 제한, 민감한 데이터 보호, AI 응답 스타일 조정 등 다양한 설정을 할 수 있다.

• Project별 규칙(Rule) 설정: 프로젝트 루트 디렉토리에 .cursor/rules 폴더를 생성하고 규칙 파일을 만들어 적용한다.

• 전역 규칙 설정: Settings > General > Rules for AI로 이동하거나 ~/.cursor/rules.yaml 파일을 통해 적용하며, 이는 원천적으로 이용자 또는 AI의 접근을 통제할 수 있다.

• 규칙 설정 예시: 민감 파일 접근 제한, 특정 디렉토리 제한, 언어 및 응답 스타일 제한 등이 가능하다.

AI 기반 개발 도구는 효율성과 편의성을 제공하지만, 정보 유출이라는 리스크 역시 분명히 존재한다. 단순히 도구를 사용하는 데 그치지 않고, 보안 기능을 정확히 이해하고 적절한 설정을 적용하는 것이 무엇보다 중요하다. 제시된 보안 설정 방안들을 사전에 검토하고 적용한다면, 보다 안전한 개발 환경을 구축하고 정보 유출 가능성을 효과적으로 줄일 수 있다. 아울러, 기업의 AI 개발 도구 환경에 맞는 보안 설정 체크리스트를 마련하고, 정기적인 점검과 교육을 통해 보안 수준을 지속적으로 유지·강화해 나가기를 권장한다.

[출처]https://www.igloo.co.kr/security-information/%EC%83%9D%EC%84%B1%ED%98%95-ai-%EA%B8%B0%EB%B0%98-%EA%B0%9C%EB%B0%9C%EB%8F%84%EA%B5%AC%EC%9D%98-%EC%9E%A0%EC%9E%AC%EC%A0%81-%EB%B3%B4%EC%95%88%EC%9C%84%ED%98%91%EA%B3%BC-%EB%8C%80%EC%9D%91%EB%B0%A9/

[워게임 공부]CSP Bypass

범호야 — Tue, 28 Oct 2025 21:09:21 +0900

CSP란

Content Security Policy (CSP, 컨테츠 보안 정책)은 웹 페이지에서 검색하고 실행할 수 있는 리소스를 정의하는 보안 계층이다. XSS나 데이터를 삽입하는 공격이 발생하였을 때 피해를 줄이고 웹 관리자가 공격 시도를 보고 받을 수 있다.

형식

Content-Security-Policy: <policy-directive>; <policy-directive>

<policy-directive>는 <directive> <value> 형태로 구성된다. <directive>는 지시문으로 칸테츠 내에서 로드하는 리소스를 세분화해 어떤 리소스에 대한 출처를 제어할지 결정한다. <value> 부분에는 <directive>에서 정의한 리소스의 출처를 정의한다.

<directive>의 종류
default-src : -src로 끝나는 모든 리소스의 기본 동작을 제어함. 만약 CSP 구문 내에서 지정하지 않은 지시문이 존재하면 default-src 정의를 따름
img-src : 이미지를 로드할 수 있는 출처 제어
script-src : 스크립트 태그 관련 권한과 출처를 제어

<value>의 종류
self : 페이지의 현재 출처내에서 로드하는 리소스만 허용
none : 모든 출처를 허용하지 않음
unsafe-inline : 예외적으로 인라인 코드의 사용을 허용

CSP Bypass

웹 사이트가 파일 업로드, 다운로드 기능을 제공하는 경우, 공격자가 다운로드 받을 때 특정한 스크립트를 띄우도록 할 수 있다.

우회 방법

신뢰하는 도메인 업로드
1. 특정 도메인에 대한 출처가 혀용된 CSP를 우회하는 가장 쉬운 방법
2. 신뢰되는 출처에 파일 업로드
JSONP API
nonce 예측 가능
base uri 미지정

2,3,4는 1과 비슷?하다.

Content-type은 중요하지 않기 때문에 어떤 형태로도 파일이 올라가면 되고 이는 스크립트를 담은 response가 필요하다는 의미

2,3,4는 요청 url과 return 값에 callback function을 남긴다. 이는 callback 데이터가 들어갈 function을 지정한다는 것이다.

[워게임] Dreamhack - CSP Bypass

범호야 — Tue, 28 Oct 2025 20:38:51 +0900

vm을 실행해서 처음 본 화면이다.

flag 버튼을 클릭해서 들어가보면 위의 사진과 같은 화면이 뜨고 아마 param의 값을 구해야 하는 것 같다,

제출 버튼 누르면 아래와 같은 팝업창이 뜬다.

#!/usr/bin/python3
from flask import Flask, request, render_template
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
import urllib
import os

app = Flask(__name__)
app.secret_key = os.urandom(32)
nonce = os.urandom(16).hex()

try:
    FLAG = open("./flag.txt", "r").read()
except:
    FLAG = "[**FLAG**]"


def read_url(url, cookie={"name": "name", "value": "value"}):
    cookie.update({"domain": "127.0.0.1"})
    try:
        service = Service(executable_path="/chromedriver")
        options = webdriver.ChromeOptions()
        for _ in [
            "headless",
            "window-size=1920x1080",
            "disable-gpu",
            "no-sandbox",
            "disable-dev-shm-usage",
        ]:
            options.add_argument(_)
        driver = webdriver.Chrome(service=service, options=options)
        driver.implicitly_wait(3)
        driver.set_page_load_timeout(3)
        driver.get("http://127.0.0.1:8000/")
        driver.add_cookie(cookie)
        driver.get(url)
    except Exception as e:
        driver.quit()
        # return str(e)
        return False
    driver.quit()
    return True


def check_xss(param, cookie={"name": "name", "value": "value"}):
    url = f"http://127.0.0.1:8000/vuln?param={urllib.parse.quote(param)}"
    return read_url(url, cookie)


@app.after_request
def add_header(response):
    global nonce
    response.headers[
        "Content-Security-Policy"
    ] = f"default-src 'self'; img-src https://dreamhack.io; style-src 'self' 'unsafe-inline'; script-src 'self' 'nonce-{nonce}'"
    nonce = os.urandom(16).hex()
    return response


@app.route("/")
def index():
    return render_template("index.html", nonce=nonce)


@app.route("/vuln")
def vuln():
    param = request.args.get("param", "")
    return param


@app.route("/flag", methods=["GET", "POST"])
def flag():
    if request.method == "GET":
        return render_template("flag.html", nonce=nonce)
    elif request.method == "POST":
        param = request.form.get("param")
        if not check_xss(param, {"name": "flag", "value": FLAG.strip()}):
            return f'<script nonce={nonce}>alert("wrong??");history.go(-1);</script>'

        return f'<script nonce={nonce}>alert("good");history.go(-1);</script>'


memo_text = ""


@app.route("/memo")
def memo():
    global memo_text
    text = request.args.get("memo", "")
    memo_text += text + "\n"
    return render_template("memo.html", memo=memo_text, nonce=nonce)


app.run(host="0.0.0.0", port=8000)

문제의 코드이다.

vuln엔드포인트를 보게 되면 render_template으로 변환하는 방식이 아닌 전달된 파라미터를 저장하는 방식이다.

이는 xss 취약점이 될 수 있다,

after_request 부분을 확인해보자

위의 코드는 http요청이 끝나고 브라우저에 응답하기 전에 실행되는 코드이다. style-src에 self와 unsafe-inline이 있기 때문에 vuln페이지를 인라인으로 이용해서 보내면 xss 공격이 가능하고 flag를 획득할 수 있다.

이를 이용해서

<script src="/vuln?param=location='/memo?memo='%2bdocument.cookie"></script>

를 flag에 입력하게 되면 memo에서 flag를 획득할 수 있게 된다.

[Planbit] 구글 광고 스크립트 삽입 공격 사례

범호야 — Tue, 28 Oct 2025 15:19:33 +0900

한국인터넷증흥원에서 발표한 2024년 침해사고 유형 TOP5는 랜섬웨어, 아겅코드 C&C, 악성 사이트 유도, 정보 유출, 웹 페이지 변조이다.

Windows 기반 웹 서비스 환경에서는 공격자가 취약점이나 웹 관리자 크리덴셜 탈취, 악성 파일 업로드 등을 통해 웹 서비스 접근 권한을 획득한 뒤, 외부 광고 스크립트나 악성코드를 삽입하는 사례가 발견되고 있다.

무단으로 삽입된 스크립트는 광고 수익을 위한 외부 광고 유출, 가상화폐 마이닝, 피싱 페이지 리디렉션 등의 다양한 공격으로 이어질 수 있다.

PLAINBIT에서 식별한 광고 스크립트 삽입 공격에서 사용된 악성코드는

- 이전 공격들과 동일한 구조의 악성코드 사용

- 특정 경로에 악성 파일들을 생성

위와 같은 공통점이 존재하지만

- 분석 활용도구 비활성화

- 보안 설정 우회

- 악성 파일 시간 변조

같은 방어 회피 기능이 추가되었다.

악성코드 동작 개요도

악성 압축파일 해제
보안 우회 설정
1. 파일 접근 권한 수정

2. 악성 스크립트 실행

1. 분석 도구 무력화

2. 스크립트 동작 권한 설정

1. 악성 압축파일 해제

2. 파일 읽기

3. 해시 값 계산 및 쓰기 권한 확인

4. 악성 스크립트 실행

5. 웹 페이지 변조

악성코드 주요 기능

분석 도구 무력화
스크립트 동작 권한 설정
악성 압축파일 해제
파일 해시 값 비교 후 웹 페이지 변조
악성코드 종료
시간 변조
변조 파일 복원

대응 방안

- 웹 서비스 보안 강화

- 주기적인 소스코드 무결성 검사

- 주기적인 위협 모니터링

비슷한 사례

정상 사이트에 악성 스크립트를 삽입하여 네이버 계정정보를 탈취하는 공격

해당 악성 스크립트는 검색 엔진을 통해 검색하여 접속한 경우에만 동작 / 사용자가 직접 도메인 주소를 입력하여 접속한 경우에는 동작하지 않는다.

이후 네이버 로그인 피싱 페이지로 리디렉션된 이후 계정정보를 입력하면 공격자 서버로 계정정보가 전송되고 추가 리디렉션 없이 공격 종료

사용자 브라우저 쿠키 값을 체크하여 재접속을 제한하고 랜딩페이지와 유포 페이지, 그리고 개인정보를 저장하는 수집페이지까지 모두 다른 정상 사이트에 구성한 특이점이 존재

탈취한 로그인 정보 전달 페이지

과거 정상 사이트에 삽입된 악성 스크립트

정상 사이트 화면에 팝업되는 네이버 로그인 피싱페이지

일반적으로 정상 사이트의 URL의 차단을 진행하지 않는다는 허점을 노려 공격을 시도한 것으로 보인다.

[출처]https://blog.plainbit.co.kr/case-of-google-ad-script-injection-attacks/, https://blog.alyac.co.kr/5179

[CPPG] 자격증 공부 - 문제 (~ 개인정보보호 관련 법률 체계)

범호야 — Wed, 1 Oct 2025 16:27:43 +0900

1. OECD 프라이버시 8원칙 중 아닌 것은?

수집 제한의 원칙
정보 공개성의 원칙
목적 명확화의 원칙
안정성 확보의 원칙
책임의 원칙

2. 기업의 사회적 책임 단계를 모두 고른 것은?

ㄱ. 자선적 책임 ㄴ. 경제적 책임 ㄷ. 논리적 책임

1. ㄱ

2. ㄱ,ㄴ

3. ㄴ,ㄷ

4. ㄱ, ㄷ

3. 개인정보처리자와 개인정보취급자 중 옳은 것은?

1. 개인정보취급자는 업무를 목적으로 개인정보파일을 운용하기 위하여 스스로 또는 다른 사람을 통하여 개인정보를 처리하는 자

2. 개인정보처리자의 대상 중 개인은 포함되지 않는다.

3. 개인정보취급자는 고용관계가 있어야만 개인정보취급자에 해당한다.

4.업무 처리를 위하여 알바에게 고객 개인정보를 열람하게 허용한 경우, 알바는 개인정보취급자에 해당한다.

4. 개인정보의 가명, 익명처리 기술 종류 중 차분 프라이버시가 존재한다 (T / F)

5. 고유식별정보 처리제한 중 옳지 않은 것은?

1. 고유식별정보란 법령에 따라 개인을 고유하게 구별하기 위하여 부여된 식별정보로서 대통령령으로 정하는 정보를 말한다.

2. 시행령에서는 고유식별정보의 범위를 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호로 정하고 있다.

3. 기업, 학교 등이 소속 구성원에게 부여하는 사번,학번도 고유식별정보가 될 수 있다.

정답

1. 답 : 2번

    정보 공개성의 원칙은 없음. 처리방침 공개의 원칙이 존재

2. 답 : 2번
3. 답 : 4번

업무 처리는 업무상 필요한 것이기 때문에 이에 한하여, 알바는 개인정보취급자에 해당한다.

1. T

가명,익명처리를 위한 다양한 기술의 세부기술로 특정 개인에 대한 사전지식이 있는 상태에서 쿼리에 대한 응답 값으로 개인을 알 수 없도록 응답 값에 임의의 숫자 잡읍을 추가하여 특정 개인의 존재 여부를 알 수 없도록 하는 기법이다.

1. 답 :3번

고유식별정보는 법령에 의해서 개인에게 부여된 것이어야 하므로 기업,학교 뿐만 아니라 법인이나 사업자에게 부여되는 법인등록번호나 사업자등록번호도 고유식별정보가 될 수 없다.

[워게임 공부]BISC safe

범호야 — Tue, 30 Sep 2025 23:44:31 +0900

뭐 잘못했나..

그러면 위에서 확인한 크롬 확장 프로그램에서 opensafe()라는 함수에서 유저의 계정을 call하고 있다.

그리고 console창에서 내 계정이 나와야 하는데 안 나온다 .

GPT: ethereum 확장 프로그램 환경에 ethereum 객체가 없으니 생기는 오류라고 설명한다.

(https://juchan-story.tistory.com/45 : 여길 참고해서 MetaMask 확장프로그램을 설치했다. )

이제 콘솔 창에 log는 나오는데 입력을 하려고 하면 오류가 뜬다.

문제를 보니 sepolia로 변경하고 하라고 한다.

변경하는 것도 어렵다...

꼭 "크롬확장프로그램"의 MetaMask에 들어가서 https://support.metamask.io/configure/networks/how-to-view-testnets-in-metamask/ 해당 링크에서 하라는데로 하면 된다. 꼭꼭 크롬확장프로그램으로 들어가야 한다...꼭! 꼬끼오~

이로써 문제 풀면서 생긴 오류는 다 수정했다!

공부

코드 분석

// SPDX-License-Identifier: MIT
pragma solidity >= 0.7.0 < 0.9.0;

contract Safe {
    address public owner;
    string private flag =  "bisc2023{FAKE_FLAG}";

    constructor() {
        owner = msg.sender;
    }

    function opensafe() public view returns (string memory) {
        if(owner == msg.sender){
            return flag;
        }
        else {
            return "Your not owner!!";
        }
    }

    function changeOwner(address _owner) public {
        require(owner == msg.sender, "Your not owner!!");
        owner = _owner;
    }
}

다운로드 한 문제파일이다.

배포 시점의 배포자 주소를 owner로 저장.
opensafe()는 호출자(msg.sender) 가 owner와 같을 때만 flag 문자열을 반환.
changeOwner()는 현재 owner만 다음 소유자를 지정 가능.

이런 기능을 담고 있는 코드이다. .sol 확장자는 Solidity 언어로 작성된 스마트컨트랙트 소스 코드 파일

.sol 파일은 이더리움 네트워크 위에서 실행되는 "코드(프로그램)"를 담고 있는 문서라고 보면 된다.

크롬확장프로그램 분석

const start = async () => {
    if(window.ethereum !== "undefined") {
            const accounts = await ethereum.request({method: "eth_requestAccounts"});
            account = accounts[0];
            console.log(`my contract: ${account}`);
    }
      const ABI = [
	{
		"inputs": [
			{
				"internalType": "address",
				"name": "_owner",
				"type": "address"
			}
		],
		"name": "changeOwner",
		"outputs": [],
		"stateMutability": "nonpayable",
		"type": "function"
	},
	{
		"inputs": [],
		"stateMutability": "nonpayable",
		"type": "constructor"
	},
	{
		"inputs": [],
		"name": "opensafe",
		"outputs": [
			{
				"internalType": "string",
				"name": "",
				"type": "string"
			}
		],
		"stateMutability": "view",
		"type": "function"
	},
	{
		"inputs": [],
		"name": "owner",
		"outputs": [
			{
				"internalType": "address",
				"name": "",
				"type": "address"
			}
		],
		"stateMutability": "view",
		"type": "function"
	}
];
      const ADDRESS = "0x5e992854Bd912ae170b7b5b8a64323e4e5E0feAF";
      window.web3 = await new Web3(window.ethereum);
      window.contract = new web3.eth.Contract(ABI, ADDRESS);
      console.log(`safe contract: ${window.contract.options.address}`);
  }
  start();
  async function openSafe() {
    try {
      const result = await window.contract.methods.opensafe().call({from: account});
  
      if (result === "Your not owner!!") {
        document.getElementById('result').innerText = result;
      } else {
        document.getElementById('result').innerText = result;
        var door = document.getElementById('door');
        door.style.transform = 'rotateY(-90deg)';
      }
    } catch (error) {
      console.error(error);
    }
  }

메타마스크 같은 지갑을 통해 Sepolia testnet에 배포된 Safe 컨트랙트와 연결하고, 버튼 클릭 시 opensafe()를 호출해서 결과를 화면에 보여주는 흐름

window.ethereum: 브라우저에 설치된 메타마스크가 제공하는 객체.

eth_requestAccounts: 사용자에게 지갑 연결을 요청 → 계정 주소(들) 반환

ABI: 컨트랙트의 함수 정의(JSON).

new Web3(window.ethereum): Web3 인스턴스를 메타마스크 provider와 연결

window.contract.methods.opensafe() : Solidity의 opensafe() 함수에 접근.

중요한 요소들에 대해 정리했다.

흐름은

메타마스크 연결
- 사용자의 지갑 주소(account) 확보.
컨트랙트 인스턴스 생성
- ABI + 컨트랙트 주소로 Safe 컨트랙트 객체 생성.
금고 열기 버튼 클릭 → openSafe() 실행
- opensafe() 함수 호출 (msg.sender = account).
- 컨트랙트 내부에서 if (owner == msg.sender) 검사.
  - true → flag 문자열 반환.
  - false → "Your not owner!!" 반환.
프론트엔드 결과 반영
- flag를 얻으면 문(door) CSS 회전 → 금고 열림 애니메이션.
- 아니면 에러 메시지 출력

위와 같이 진행된다.

web3란?

Web2 (네이버, 구글, 인스타 같은 중앙 서버 기반 인터넷)와 달리 Web3는 블록체인 같은 탈중앙화(decentralized) 기술을 기반으로 한 새로운 인터넷 패러다임

데이터 소유권: 데이터는 기업 서버에 있지 않고 블록체인에 기록됨
지갑 주소가 인터넷 아이디처럼 쓰임
스마트컨트랙트로 자동 실행되는 앱 (DApp, 탈중앙 앱)

web3.js는 자바스크립트에서 이더리움 블록체인과 상호작용할 수 있게 해주는 라이브러리
메타마스크 같은 지갑이 제공하는 provider(window.ethereum) 를 연결해서 사용
할 수 있는 일:
- 계정 가져오기: web3.eth.getAccounts()
- 잔액 조회: web3.eth.getBalance(address)
- 트랜잭션 보내기: contract.methods.transfer(...).send({from: account})
- 컨트랙트 읽기: contract.methods.myData().call()