misconfiguration
이 태그가 달린 문서 8건
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) 자기 검증 체크리스트. 방어 전용 — 공격 절차는 없다.
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) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라
웹루트의 모든 것은 누구나 URL로 가져갈 수 있습니다. 남겨진 토큰/자격증명 JSON, .env, 백업은 즉각 노출을 뜻하며 — 공유 템플릿에서 왔다면 모든 사이트가 같은 구멍을 갖습니다. 해법: 공개 디렉터리엔 공개해도 되는 것만, 시크릿은 웹루트 밖에 권한 600으로, 하나 찾으면 모든 사이트와 호스트를 점검하기.
X-Forwarded-For(XFF) 스푸핑이란 — 신뢰 프록시 설정의 함정
XFF는 클라이언트가 위조 가능한 헤더입니다. 무차별 스캐너가 인젝션 탐침을 위조된 XFF에 숨기고, '모든 프록시 신뢰(와일드카드)'가 통과시킵니다. 패치 = 경계에서 IP 헤더 정제; 근본 수정 = 올바른 프록시(또는 없음)만 신뢰. 영향 0이라도 고칠 설정이 남았습니다.
Laravel 앱의 .env가 온 세상에 읽혔다 — 가장 흔한 공유 호스팅 실수
원인: 앱 전체가 웹 루트 아래 있었다 — public/만 보여야 한다. 세 단계로 고친다 — .htaccess 응급 처치, 키 교체, 구조 재배치 — 그리고 프로세스로 재발을 막는다.