access control
이 태그가 달린 문서 10건
OWASP Top 10이란 — 웹 앱에서 가장 중대한 10대 리스크의 표준 목록
OWASP Top 10은 비영리 단체 OWASP가 몇 년마다 공개하는 '웹 앱에서 가장 중대한 10대 리스크' 목록. 개발자·운영자의 공통 언어로 널리 쓰인다. 최신판(2021)의 선두는 '접근 제어 미비(Broken Access Control)'이며, 이하 인젝션·설정 실수·취약하고 오래된 컴포넌트·인증 미비 등이 이어진다. 개별 공격 기법이 아니라 '리스크의 카테고리'이므로, 자신의 앱을 점검하는 관점으로 쓰는 것이 옳다.
PCI DSS란 — 신용카드 정보를 다루기 위한 보안 기준
PCI DSS(Payment Card Industry Data Security Standard)는 카드 정보를 저장·처리·전송하는 사업자가 충족해야 하는 국제적인 보안 기준. 카드 국제 브랜드가 책정하며, 네트워크 보호·저장 데이터의 암호화·접근 제어(최소 권한)·모니터링/로그·취약점 관리 등을 요구한다. 실무에서 가장 안전한 것은 '직접 카드 번호를 보유하지 않고, 준수된 결제 대행(토큰화)에 맡겨 적용 범위를 최소화한다'는 것.
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) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
Laravel 보안 — 프로덕션 하드닝 레퍼런스
Laravel의 기본값은 견고합니다. 프로덕션 사고는 설정과 운영에서 나옵니다. 이 문서는 실무용 레퍼런스입니다: (1) 우선순위순 하드닝 체크리스트(P0–P2), (2) 위험한 기본값 표, (3) 영역별 지침 — 시크릿/APP_KEY, 프로덕션 설정(APP_DEBUG/캐시), 인가(Policy/Gate, Mass Assignment), 인젝션/출력(Eloquent 바인딩, Blade), 세션/CSRF/쿠키, 업로드, HTTPS/헤더/속도 제한, Composer 의존성 CVE, 그리고 (4) 자기 점검 체크리스트. 방어 전용이며 공격 절차는 없습니다.
Next.js 보안 대책 — 프로덕션 하드닝 실무 레퍼런스
Next.js의 기본값은 비교적 안전하지만, 사고는 서버/클라이언트 경계에서 일어납니다. 이 페이지는 실무 레퍼런스입니다: (1) 우선순위별 하드닝 체크리스트(P0–P2), (2) 영역별 지침 — 경계와 환경 변수(NEXT_PUBLIC_), 의존성 CVE(본체 RCE 포함), Server Actions / Route Handlers 인가 + 입력 검증, 서버 측 fetch의 SSRF, 보안 헤더/CSP, 인증/세션/쿠키, 레이트 제한, (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) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
Express(Node.js) 보안 — 프로덕션 하드닝 실무 레퍼런스
Express는 최소주의라 기본으로 거의 아무것도 지키지 않으므로 방어는 직접 더한다. 본 페이지는 실무 레퍼런스다: (1) 우선순위 순의 하드닝 체크리스트(P0~P2), (2) 영역별 지침 — 보안 헤더(helmet) + x-powered-by 비활성화·npm 의존성 CVE·입력 검증과 인젝션(SQL/NoSQL 연산자)·인증과 소유자 스코프 인가·속도 제한과 크기 상한·세션/쿠키/CSRF·SSRF·프로덕션 에러 처리(스택 미노출)·NODE_ENV, (3) 자기 검증 체크리스트. 방어 전용 — 공격 절차는 없다.
Ruby on Rails 보안 — 프로덕션 하드닝 실무 레퍼런스
Rails는 규약과 안전한 기본값(CSRF 보호·Strong Parameters·ORM)을 갖추지만, 프로덕션 사고는 운영에서 일어납니다. 본 페이지는 실무 레퍼런스입니다: (1) 우선순위 하드닝 체크리스트(P0~P2), (2) 영역별 구체 대책 — 비밀과 credentials(master key/secret_key_base)·프로덕션 설정(force_ssl·예외 비노출)·gem CVE·Strong Parameters/Mass Assignment·인가(Pundit 등·소유자 스코프)·인젝션과 위험한 메서드(where 결합/send/constantize)·세션/Cookie/CSRF·SSRF/업로드, (3) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
로그인만 붙이고 안심하고 있지 않은가 — 인증과 인가의 차이
인증＝'누구인가'를 확인하는 것, 인가＝'그 사람이 무엇을 해도 되는가'를 정하는 것. 둘은 별개이며, 로그인을 붙인 것만으로는 인가가 되지 않는다. 데이터에 소유자(user_id) 스코프가 없으면 '로그인＝전체 데이터 열람'이 된다(OWASP 최상위의 Broken Access Control). 게다가 인증 스캐폴드의 등록 개방이 겹치면 제3자가 등록해 안으로 들어올 수 있다. 방어는, 모든 쿼리를 소유자로 좁히기／불필요한 등록 닫기／다층 방어／감사·접근 로그를 사고 나기 전에／신규 등록 탐지.
IDOR이란 — ID만 바꿔서 남의 데이터를 보게 되는 것
IDOR은 사용자가 ?id=124를 125로 바꿔 남의 청구서나 개인 데이터를 읽게 만드는 — 취약한 접근 제어입니다. 진짜 방어: 매 접근마다 서버 측에서 로그인된 사용자가 이 객체에 권한이 있는지 검사하기. 추측하기 어려운 ID는 해결책이 아닙니다.