misconfiguration
이 태그가 달린 문서 10건
클라우드 스토리지 공개 노출: 퍼블릭 액세스 차단을 켜도 데이터가 샐 수 있는 이유
버킷 유출은 공격이 아니라 설정에서 생긴다. 문서에서 중요한 한 줄: 퍼블릭 액세스 차단 설정은 기존 정책이나 ACL을 바꾸지 않는다. 공개 설정은 차단 아래에 남아 있고, 차단을 풀면 다시 공개된다. 그래서 목표는 '차단이 켜져 있다'가 아니라 '차단을 꺼도 공개된 것이 없다'이다. 버킷 정책으로 버킷 단위 차단을 끄는 권한을 줄 수 있으므로 계정 단위로 적용한다. 그리고 '공개'의 정의는 생각보다 넓다.
흔한 보안 실수 4가지: 기본 설정, 잊힌 서비스, 모니터링 부재, 입력 검증에 대한 과신
사고는 몇 가지 반복되는 패턴에서 나오며, 그 패턴은 기술보다 믿음으로 분류할 때 더 분명해진다. 네 가지다. 기본값은 안전할 것이다(아무것도 설정하지 않았다), 쓰지 않는 것은 해가 없을 것이다(아무것도 닫지 않았다), 무슨 일이 있으면 알아차릴 것이다(아무것도 관찰할 수 없다), 검증한 입력은 안전할 것이다(입력에 너무 많은 것을 맡겼다). 어느 것도 고치는 데 깊은 기술 지식이 필요하지 않다. 필요한 것은 확인하는 습관이다. 각각 무엇을 보면 되는지 정리한다.
ASP.NET Core 보안 — 프로덕션 하드닝 실무 레퍼런스
ASP.NET Core는 성숙하고 안정된 프레임워크이지만, 사고는 설정에서 일어납니다. 본 페이지는 실무 레퍼런스입니다: (1) 우선순위 하드닝 체크리스트(P0~P2), (2) 영역별 구체 대책 — 프로덕션에서 상세 오류/Developer Exception Page를 노출하지 않기·시크릿의 외부화(User Secrets/환경/Key Vault)·NuGet 의존성 CVE·인가([Authorize]·폴백으로 기본 거부·리소스 기반/소유자)·over-posting(DTO/[Bind])·안전하지 않은 역직렬화(BinaryFormatter 회피)·HTTPS/헤더/antiforgery·SSRF, (3) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
Django 보안 — 프로덕션 하드닝 실무 레퍼런스
Django는 많은 안전한 기본값(ORM·CSRF·자동 이스케이프·인증)을 갖추지만, 사고는 설정에서 일어납니다. 본 페이지는 실무 레퍼런스입니다: (1) 우선순위 하드닝 체크리스트(P0~P2), (2) 영역별 구체 대책 — DEBUG=False＋ALLOWED_HOSTS·SECRET_KEY의 외부화·pip 의존성 CVE·프로덕션 보안 설정(SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE 등)·인가(소유자 스코프)·인젝션과 출력(raw/extra·mark_safe)·CSRF/세션/admin·SSRF/업로드, (3) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
프레임워크별 보안 대책 — 사용하는 기술에 맞는 방어법
프레임워크가 달라져도 공격자가 노리는 약점의 '유형'(접근 제어·시크릿 관리·인젝션·의존성 CVE·설정 오류)은 거의 공통입니다. 다른 것은 '위험한 기본 설정'과 '그 기술에서 자주 노려지는 지점'뿐. 본 사이트는 각 프레임워크의 '기본값의 함정'과 '하드닝 절차'를 하나씩 준비합니다. 우선 자신이 실제로 쓰는 프레임워크 장부터.
Laravel 보안 — 프로덕션 하드닝 레퍼런스
Laravel의 기본값은 견고합니다. 프로덕션 사고는 설정과 운영에서 나옵니다. 이 문서는 실무용 레퍼런스입니다: (1) 우선순위순 하드닝 체크리스트(P0–P2), (2) 위험한 기본값 표, (3) 영역별 지침 — 시크릿/APP_KEY, 프로덕션 설정(APP_DEBUG/캐시), 인가(Policy/Gate, Mass Assignment), 인젝션/출력(Eloquent 바인딩, Blade), 세션/CSRF/쿠키, 업로드, HTTPS/헤더/속도 제한, Composer 의존성 CVE, 그리고 (4) 자기 점검 체크리스트. 방어 전용이며 공격 절차는 없습니다.
Spring Boot 보안 — 프로덕션 하드닝 실무 레퍼런스
Spring Boot는 안정된 프레임워크지만, 사고는 의존성·설정·인가에서 일어난다. 본 페이지는 실무 레퍼런스다: (1) 우선순위 순의 하드닝 체크리스트(P0~P2), (2) 영역별 지침 — 의존성 CVE(Log4Shell급, 가동 중인 버전으로 판단)·프로덕션 설정과 시크릿 외부화·Spring Security 인가(기본 거부/메서드 인가/소유자 검사)·Actuator/관리 노출 축소·안전하지 않은 역직렬화·인젝션·헤더/CSRF/세션·SSRF, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차는 없다.
공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라
웹루트의 모든 것은 누구나 URL로 가져갈 수 있습니다. 남겨진 토큰/자격증명 JSON, .env, 백업은 즉각 노출을 뜻하며 — 공유 템플릿에서 왔다면 모든 사이트가 같은 파일을 갖습니다. 해법: 공개 디렉터리엔 공개해도 되는 것만, 시크릿은 웹루트 밖에 권한 600으로, 하나 찾으면 모든 사이트와 호스트를 점검하기.
X-Forwarded-For(XFF) 스푸핑이란: 신뢰 프록시 설정 오류와 방어
XFF는 클라이언트가 위조 가능한 헤더입니다. 무차별 스캐너가 인젝션 탐침을 위조된 XFF에 넣고, '모든 프록시 신뢰(와일드카드)' 설정이 그것을 통과시킵니다. 단기 수정: 경계에서 IP 헤더 정제. 근본 원인 수정: 올바른 프록시(또는 없음)만 신뢰. 영향 0이라도 고칠 설정이 남았습니다.
Laravel의 .env가 공개적으로 읽힌 사례: 공유 호스팅의 배치 실수와 고치는 법
원인: 앱 전체가 웹 루트 아래 있었다 — public/만 보여야 한다. 세 단계로 고친다 — .htaccess로 임시 차단, 키 교체, 구조 재배치 — 그리고 프로세스로 재발을 막는다.