access control
이 태그가 달린 문서 16건
Toypo 앱 무단 접근(Toypo 발표 기준 이용자 697,209명 해당): 전화번호·이름·주소 유출, 매장 앱 이용자가 해야 할 일
Toypo Inc.는 고객 관리 앱 Toypo 앱에 대한 제3자의 무단 접근을 2026년 10월 4일 확인했다고 밝히고, 10월 14일자 공지에서 697,209명의 이용자가 해당되며 정보가 유출되었을 수 있다고 발표했습니다. 날짜와 인원이 없는 두 번째 공지 페이지는 정보가 유출되었다고 적고 있습니다. 회사는 10월 13일부터 앱 내 푸시 알림 등으로 해당자에게 개별 연락을 하고 있습니다. 회사에 따르면 시스템 일부에 접근 제어 결함이 있어 인증된 이용자가 열람 권한이 없는 다른 이용자의 정보를 얻을 수 있었고, 로그상 제3자가 이를 이용해 이용자 정보를 취득했습니다. 결함은 수정되었습니다. 유출되었을 수 있는 정보는 전화번호와 사용자 ID 등의 식별자, 그리고 등록된 경우 이름, 이름의 가나 표기, 이메일 주소, 생년월일, 성별, 주소입니다. 비밀번호 등의 로그인 정보, 신용카드 번호 등의 결제 정보, 포인트, 매장 방문 이력, 구매·이용 이력은 포함되지 않았고 앱에서 비밀번호 변경 등의 조치는 필요 없다고 합니다. 구체적인 2차 피해는 확인되지 않았습니다. 개인정보보호위원회에 보고했으며 제3자 보안 진단을 준비 중입니다. 이 앱을 쓰는 매장의 공지에서 JR Kyushu Food Service는 등록 회원 약 61,500명 중 약 26,900명, Mannoya는 Kineya Mannoya 공식 앱 회원 212명 중 12명이 해당된다고 밝혔습니다. Toypo의 문의처는 0120-546-030(평일 9:00–18:00 일본 시간, 콜센터는 10월 30일 18:00까지 전화를 받고 이후는 앱 내 문의)입니다. 이 사이트의 결론: 전화번호와 이름이 정확히 맞는 메시지라고 해서 진짜라는 보장은 없습니다. 그 링크나 번호는 쓰지 말고 앱 내 문의나 공지에 적힌 연락처로 확인하세요.
Commune 무단 접근(커뮤니티별 집계 회원 기록 166,505건): 기업 커뮤니티 회원 데이터 유출 — 회원과 운영자가 해야 할 일
2026년 10월 9일 Commune Inc.는 기업용 커뮤니티 서비스인 Commune과 Commune for Work가 외부 제3자에 의해 무단 접근을 받았고, 일부 커뮤니티에서 회원 데이터가 유출되었다고 발표했습니다. 유출은 10월 5일 18시경부터 10월 6일 21시경까지, 그리고 10월 7일 13시 17분부터 14시 36분까지(일본 시간) 발생했습니다. 최초 공지는 최대 약 30만 7천 명(고유 인원 기준 추정)이 영향을 받았을 수 있다고 밝혔습니다. 10월 21일 후속 공지에서 상세 조사 후 166,505명의 회원이 영향을 받았다고 확인했고(회원 ID를 커뮤니티별로 합산한 수치이므로 여러 커뮤니티에 속한 사람은 커뮤니티마다 한 번씩 계산됨. 회사가 운영하는 커뮤니티와 테스트·데모 커뮤니티를 포함하며 공격자가 만든 계정은 제외), 그중 125,601명은 이메일 주소를 포함한 데이터가 유출되었다고 밝혔습니다. 나머지의 경우 유출 데이터에는 표시 이름, 프로필, 비공개 그룹 가입 정보가 포함됩니다. 144명의 회원은 본인 조작 없이 비밀번호가 임시 비밀번호로 변경되었습니다. 비밀번호 자체나 다이렉트 메시지의 유출은 확인되지 않았으며, 회사는 결제 정보를 보유하지 않는다고 밝혔습니다. 회사는 비공개 커뮤니티의 초대 링크를 부정한 방법으로 입수한 것과 관리자 사칭을 원인으로 설명합니다. 이 서비스를 이용해 커뮤니티를 운영하는 고객 기업들도 공지를 게시했으며, JMAM은 자사 Toki Labo 커뮤니티의 프로필 회원 정보에 포함된 이름, 주소, 나이, 전화번호도 유출되었다고 밝혔습니다. 유출된 이메일 주소의 악용을 막기 위해 Commune Inc.는 10월 10일 00시 50분부터 긴급 점검으로 모든 커뮤니티를 중단했고, 관리자 계정에 2단계 인증 의무화 등의 조치를 취했습니다. 10월 16일에는 요청한 고객사의 커뮤니티부터 단계적으로 재개한다고 발표했습니다. 재개는 웹 브라우저 버전에서만, 일부 기능을 제한한 상태로 진행됩니다(앱, 이메일 주소를 이용한 신규 등록, '비밀번호를 잊으셨나요' 재설정은 여전히 이용할 수 없음). 회사는 점검 및 테스트 과정에서 새로운 무단 접근이나 유출은 발견되지 않았다고 밝혔습니다. 10월 21일 후속 공지에서 회사는 10월 9일 총무성(간토종합통신국)에 예비 보고서를 제출했고, 경찰과 상담을 시작했으며, 모든 로그를 분석한 결과 공격자가 남긴 프로그램, 계정, 설정은 발견되지 않았다고 밝혔고, 제3자 기관의 포렌식 조사를 준비 중이라고 설명했습니다. 이 사이트의 견해: 자신의 커뮤니티를 운영하는 회사의 공지를 확인해 영향 여부를 살펴보고, 커뮤니티에서 보낸 것처럼 보이는 이메일의 링크는 열지 마십시오.
NewsPicks 데이터 유출 (카드 소지자 이름과 끝자리, 최대 362,000건): 내부 관리 도구를 통해 무엇이 유출됐는지와 이용자가 해야 할 일
2026년 10월 8일 Uzabase, Inc.는 뉴스 서비스 NewsPicks 운영에 사용되는 관리 도구에 제3자가 권한 없이 접근했고, 일부 이용자의 개인정보가 유출됐을 가능성이 있다고 발표했다. 10월 9일 발표한 두 번째 안내에서 회사는 이번 침입이 해당 관리 도구의 취약점을 악용한 것이라고 밝혔고, 항목별 최대 추정 건수를 공개했다. 웹 결제에 사용된 카드 데이터 일부(카드 소지자 이름과 카드번호 끝 3자리 또는 4자리 등) 362,000건, 이메일 주소 323,000건, 직무 수준 범주 273,000건, 소속 65,000건, 이름 59,000건 등이다. 회사는 카드번호 전체와 보안 코드는 회사 시스템에 저장된 적이 없어 유출되지 않았다고 밝혔으며, 비밀번호 유출은 확인되지 않았다고 한다. 2차 피해는 확인되지 않았다. 이 사이트의 견해: 카드 끝자리나 직장명이 적힌 메시지가 진짜라는 증거는 아니다. 링크를 열지 말고, 공식 앱이나 직접 연 공식 사이트에서 확인하며, 카드 명세서를 주시하라.
스카이티켓(Adventure Inc.) 정보 유출 사고(약 1,464만 건): 비밀번호, 환불 계좌 정보 및 일부 이용자 카드 정보 노출 — 이용자가 오늘 해야 할 일
2026년 10월 9일 Adventure Inc.는 여행 비교·예약 사이트 스카이티켓에서 서로 다른 경로로 발생한 세 건의 불법 접근 사고를 발표했습니다. 첫 번째 사고에서는 관리 기능이 악용되어 이를 출발점으로 다른 서버와 클라우드에 저장된 데이터에 접근했고, 약 1,464만 건의 정보가 유출되었습니다. 여기에는 여권상 표기 이름을 포함한 이름, 생년월일, 이메일 주소, 전화번호, 주소, 계좌 이체 시 사용된 송금인명이 포함되며, 그중 약 413만 건에는 해시 처리된 회원 비밀번호가 포함되어 있었습니다. 두 번째 사고에서는 업무 관리 시스템의 취약점이 악용되어 환불 계좌 정보가 포함된 17,780건(중복 포함, 집계 중인 건수 있음)이 유출되었거나 유출되었을 가능성이 있습니다. 세 번째 사고에서는 로그인하지 않고도 버스 예약 완료 페이지가 표시될 수 있었으며, 약 12,000건의 예약이 열람되었거나 열람되었을 가능성이 있습니다. 회사는 처음에 카드 번호가 유출된 정보에 포함되지 않았다고 밝혔으나, 10월 16일 두 번째 공지에서 이를 정정했습니다. 2017년 2월부터 2018년 6월까지 '스카이티켓 프리미엄' 회원비를 신용카드로 등록하거나 결제한 최대 6,140명의 카드 번호, 카드 명의자 이름, 유효기간(일부는 카드 번호만)이 첫 번째 사고에서 유출되었으며, 프리미엄 혜택으로 제공된 복지 서비스의 회원 ID, 이름, 비밀번호도 함께 유출되었습니다. 여권 이미지는 노출되지 않았고, 10월 9일 공지 시점에 확인된 2차 피해는 회원 계정에 대한 무단 로그인 1건뿐이었습니다(두 번째 공지에서는 유출된 카드 정보가 악용되었는지 언급하지 않았습니다). 이 사이트의 견해: 회원은 오늘 공식 사이트나 앱에서 비밀번호를 변경하고, 같은 비밀번호를 다른 곳에서도 썼다면 그곳도 변경해야 합니다. 해당 기간에 프리미엄 회원비를 위해 카드를 등록하거나 사용했다면 10월 이후 카드 명세서를 확인하고, 환불·보상·예약 변경과 관련된 메시지는 무시하며, 누구에게도 은행 PIN이나 일회용 인증번호를 알려주지 마십시오.
클라우드 스토리지 공개 노출: 퍼블릭 액세스 차단을 켜도 데이터가 샐 수 있는 이유
버킷 유출은 공격이 아니라 설정에서 생긴다. 문서에서 중요한 한 줄: 퍼블릭 액세스 차단 설정은 기존 정책이나 ACL을 바꾸지 않는다. 공개 설정은 차단 아래에 남아 있고, 차단을 풀면 다시 공개된다. 그래서 목표는 '차단이 켜져 있다'가 아니라 '차단을 꺼도 공개된 것이 없다'이다. 버킷 정책으로 버킷 단위 차단을 끄는 권한을 줄 수 있으므로 계정 단위로 적용한다. 그리고 '공개'의 정의는 생각보다 넓다.
파일 업로드 취약점 — 웹 셸과 RCE를 설계로 막는 법
업로드 취약점의 문제는 '파일을 받는 것'이 아니라 어디에 두느냐, 그리고 실행될 수 있느냐다. 인증 없는 엔드포인트 + 형식 검증 없음 + 웹 루트 아래 저장 + 그곳에서 스크립트 실행 = 웹 셸 → RCE. 여러 겹으로 막는다. (1) 엔드포인트에 인증·권한 확인과 CSRF 대책, (2) 서버 측 허용 목록과 내용 검사, (3) 웹 루트 밖에 저장(또는 실행 금지), (4) 파일 이름 무작위화, 사용자 경로를 믿지 않기. 하나의 통제에 기대지 말고, 모든 단계에 공격을 멈출 수단을 둔다.
OWASP Top 10이란: 웹 앱에서 가장 중대한 10대 리스크의 표준 목록
OWASP Top 10은 비영리 단체 OWASP가 몇 년마다 공개하는 '웹 앱에서 가장 중대한 리스크' 목록으로, 개발자와 운영자의 공통 언어다. 최신 2025년판(2025년 11월 발표)도 1위는 접근 제어 미흡(Broken Access Control)이며, 보안 설정 오류가 2위로 올라섰고, 소프트웨어 공급망 실패와 예외 상황 처리 미흡이라는 두 카테고리가 새로 추가되었다. SSRF는 접근 제어 미흡에 통합되었다. 개별 공격 기법이 아니라 리스크의 카테고리이므로, 자신의 앱을 점검하는 관점으로 쓴다.
PCI DSS란: 신용카드 정보를 다루기 위한 보안 기준
PCI DSS(Payment Card Industry Data Security Standard)는 카드 정보를 저장·처리·전송하는 사업자를 위한 국제 기준이다. 카드 브랜드가 정하며, 네트워크 보호, 저장 데이터 암호화, 최소 권한의 접근 제어, 모니터링·로그, 취약점 관리를 요구한다. 실무에서 가장 안전한 방법은 카드 번호를 직접 보유하지 않고, 기준을 준수하는 결제 대행사에 처리를 맡겨(토큰화) 적용 범위를 줄이는 것이다.
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) 자기 검증 체크. 방어 전용 — 공격 절차는 다루지 않습니다.
Express(Node.js) 보안 — 프로덕션 하드닝 실무 레퍼런스
Express는 최소주의라 기본으로 거의 아무것도 지키지 않으므로 방어는 직접 더한다. 본 페이지는 실무 레퍼런스다: (1) 우선순위 순의 하드닝 체크리스트(P0~P2), (2) 영역별 지침 — 보안 헤더(helmet) + x-powered-by 비활성화·npm 의존성 CVE·입력 검증과 인젝션(SQL/NoSQL 연산자)·인증과 소유자 스코프 인가·속도 제한과 크기 상한·세션/쿠키/CSRF·SSRF·프로덕션 에러 처리(스택 미노출)·NODE_ENV, (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) 자기 검증 체크리스트. 방어 전용 — 공격 절차 없음.
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는 해결책이 아닙니다.