핀테크 회사에서 보안 QA가 필수인 이유 - 금융 데이터를 지키는 사람

핀테크 회사에서 보안 QA가 필수인 이유 - 금융 데이터를 지키는 사람

핀테크 회사에서 보안 QA가 필수인 이유 - 금융 데이터를 지키는 사람 아침 9시, 출근하면 제일 먼저 하는 일 출근했다. 커피 먼저. 그리고 뉴스. 일반 QA는 기능 동작 확인한다. 나는? CVE 목록부터 본다. Common Vulnerabilities and Exposures. 어젯밤 새로 발견된 취약점들. "Spring Framework 제로데이 취약점 발견. RCE 가능." 우리 회사 스택이다. 커피 식었다. CTO한테 슬랙 메시지 보냈다. "긴급. 미팅 필요합니다." 답장 3분 만에 왔다. "회의실 10분 후." 핀테크는 이렇다. 다른 회사는 "다음 주 패치하죠" 할 수 있다. 우리는? 당장 오늘. 고객 돈 다룬다. 실시간이다. 한 번 뚫리면 끝이다.핀테크 보안이 다른 이유 일반 서비스는 개인정보 유출이 최악이다. 핀테크는? 돈이 직접 나간다. 작년에 다른 핀테크 회사 사건 있었다. API 인증 우회 취약점. 3시간 만에 2억 인출됐다. 회사 망했다. 서비스 종료. 우리 회사 개발자 120명. 보안팀은 5명. 비율로 보면 적다. 근데 이게 맞다. 소수 정예여야 한다. 내 연봉 7000만원. 같은 연차 일반 QA는 5000 정도다. 2000만원 차이. 왜? 책임의 무게다. 내가 놓친 취약점 하나가 회사를 무너뜨린다. 고객 자산을 날린다. 금융위원회에서 제재 들어온다. 뉴스에 나온다. "○○페이, 보안 취약점으로 100억 피해" 헤드라인 상상만 해도 식은땀 난다. 매일 아침 CVE 체크하는 이유다. 매일 밤 침투 테스트하는 이유다. 주말에도 버그바운티 확인하는 이유다. 돈을 지키는 게 내 일이다. 한 번의 해킹이 회사에 미치는 영향 구체적으로 계산해봤다. 실제로. 우리 회사 일일 거래액 평균 50억. 서비스 1시간 다운되면? 약 2억 손실. 고객 이탈까지 계산하면 10억 넘는다. 보안 사고는 더 심각하다. 직접 피해:해킹으로 인한 금전 손실: 수십억 서비스 복구 비용: 5억~10억 법적 대응 비용: 3억~5억간접 피해:고객 이탈률 30~50% 신규 고객 유입 -70% 기업 가치 평가 -40% 투자 유치 불가능규제 제재:금융위 과징금: 수십억 영업정지 가능성 라이선스 취소 위험작년에 한 간편결제 업체가 당했다. XSS 취약점 통한 세션 하이재킹. 고객 계좌정보 3만 건 유출. 결과? 회사 매각. 창업자 물러남. 직원 절반 정리해고. 내가 그 회사 보안 담당자 알았다. 같이 CTF 대회 나갔던 형이다. 지금은 연락 안 된다. 무겁다. 이 일이.보안 QA의 실제 업무 오전 10시. 신규 기능 보안 테스트 시작했다. 이번 주에 출시되는 '간편 송금' 기능. 개발팀에서 QA 완료했다고 한다. 이제 내 차례. 체크리스트:인증/인가JWT 토큰 검증 우회 가능? 다른 사용자 계좌로 접근 가능? 토큰 만료 시간 적절?입력값 검증SQL Injection 가능? XSS 가능? 금액 음수 입력 막혔나? 금액 오버플로우 처리했나?API 보안Rate limiting 있나? 금액 변조 가능? 응답에 민감정보 노출되나?비즈니스 로직잔액보다 많이 송금 가능? 동시 요청 처리 문제없나? 취소/환불 로직 허점 없나?Burp Suite 켰다. 프록시 설정. 요청 하나씩 캡처한다. 30분 지났다. 찾았다. 송금 API에 금액 파라미터 음수 넣으니까 통과된다. -10000원 송금. 잔액이 늘어난다. "...이거 실화냐." 개발팀 단톡방에 올렸다. "@전체 긴급. 송금 API 음수 처리 안 됨. 악용 가능. 즉시 수정 필요." 답장이 쏟아진다. "헐 진짜요?" "테스트는 다 했는데..." "QA에서 통과 안 했나요?" 일반 QA는 정상 시나리오만 테스트한다. 10000원 넣으면 잘 되는지. 나는? 공격자처럼 생각한다. -10000원 넣으면 어떻게 되는지. 이게 보안 QA다. 침투 테스트의 스릴과 공포 오후 2시. 모의해킹 시간이다. 분기마다 한 번씩 한다. 회사 시스템을 실제로 해킹해보는 거다. 합법적으로. CTO 승인받고. 목표: 고객 계좌정보 접근하기. 공격 시나리오: 1단계: 정찰서브도메인 스캐닝 (Subfinder) 포트 스캐닝 (Nmap) 기술 스택 파악 (Wappalyzer)2단계: 취약점 발견숨겨진 관리자 페이지 찾기 API 엔드포인트 브루트포싱 구버전 라이브러리 취약점 검색3단계: 침투발견한 취약점 익스플로잇 권한 상승 시도 내부 네트워크 접근스캐닝 시작했다. Nmap 돌린다. PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 3000/tcp open ppp3000번 포트? 뭐지. 접속해봤다. 개발용 대시보드가 떴다. 인증도 없다. 실서버에 개발 포트가 열려있다. "아..." 여기서 DB 접속 정보 보인다. Redis 키도 보인다. 세션 토큰도 보인다. 게임 끝났다. 10분 만에 뚫렸다. 스릴 있다. 취약점 찾을 때 아드레날린 솟는다. 근데 동시에 공포스럽다. '만약 진짜 해커가 찾았으면?' 손 떨린다. 리포트 쓴다.개발팀과의 갈등과 협업 리포트 보냈다. 개발팀 반응은 두 가지다. 반응 1: 인정형 "와 이거 큰일 날 뻔했네요. 바로 고치겠습니다." 이런 개발자 최고다. 같이 일하기 좋다. 반응 2: 방어형 "이건 엣지 케이스예요. 실제로는 안 일어나요." "이거 고치려면 시간 많이 걸려요. 우선순위 낮춰주세요." "보안팀이 너무 빡빡하게 보는 거 아닌가요?" 이럴 때 힘들다. 작년에 있었던 일이다. 인증 우회 취약점 발견했다. Critical 등급. 개발팀에 보고했다. "다음 스프린트에 넣을게요." 2주 뒤다. 안 된다. 당장 고쳐야 한다. 다시 말했다. "보안팀이 일정 자꾸 바꾸면 곤란합니다." CTO 불렀다. 시연했다. 실제로 계좌 조회를 다른 사용자 토큰으로 했다. 5분 만에 수정 지시 나왔다. 보안 QA의 딜레마:너무 빡빡하면 → 개발 속도 저하, 관계 악화 너무 느슨하면 → 취약점 방치, 사고 위험균형이 중요하다. 근데 어렵다. 나는 이렇게 한다:위험도 명확히 설명 실제 공격 시나리오 시연 비즈니스 영향 계산 수정 방법까지 제안"이 취약점으로 하루 10억 피해 가능합니다. 코드 3줄 추가하면 막힙니다." 이렇게 말하면 대부분 수긍한다. 밤샘 작업과 긴급 패치 밤 11시. 퇴근하려는데 전화 왔다. CTO다. "지금 상황실 올 수 있어? 긴급이야." 심장 뛴다. 뭔가 터졌다. 상황실 도착했다. 개발자 10명 모여있다. 분위기 심각하다. "외부 보안 연구원이 제보했어. 우리 API에서 IDOR 취약점 발견했대." IDOR. Insecure Direct Object Reference. 다른 사용자 데이터 접근 가능한 취약점. 제보 내용 확인했다. 맞다. /api/user/{userId}/account 엔드포인트. userId만 바꾸면 다른 사람 계좌 조회된다. "몇 명이 접근했나요?" "로그 확인 중인데... 약 50건." 최악은 아니다. 근데 방치하면 확산된다. 긴급 대응 프로세스:즉시 해당 API 차단 (5분) 영향받은 고객 파악 (30분) 패치 개발 및 테스트 (2시간) 배포 및 모니터링 (1시간) 고객 공지 준비 (다음날)새벽 3시까지 일했다. 패치 완료. 배포 성공. 모니터링 정상. 집 가는 택시 안에서 생각했다. '만약 제보자가 악의적이었으면?' '만약 발견이 2주 늦었으면?' 등골이 서늘하다. 이게 핀테크 보안 QA의 현실이다. 24시간 대기조. 언제든 터질 수 있다. 집 도착. 새벽 4시. 씻고 침대 누웠다. 눈 감히지 않는다. '또 놓친 게 있을까?' 이 생각이 떠나지 않는다. 버그바운티와 화이트 해커 문화 주말이다. 카페 왔다. 노트북 켰다. 회사 일 아니다. 개인 프로젝트다. 버그바운티. 버그바운티 프로그램. 기업이 취약점 발견하면 포상금 주는 거다. 합법적으로 해킹하고 돈 받는다. 유명 플랫폼:HackerOne Bugcrowd 국내: 버그바운티 코리아지난 달 성과:XSS 취약점 발견: $500 API 권한 상승 취약점: $1500 정보 노출 취약점: $300총 $2300. 약 300만원. 용돈 치고는 괜찮다. 근데 돈이 전부는 아니다. 버그바운티 하는 이유:실력 향상다양한 서비스 구조 경험 최신 취약점 트렌드 파악 실전 감각 유지네트워킹다른 해커들과 교류 취약점 공유 및 토론 채용 기회 연결윤리적 만족인터넷을 더 안전하게 화이트 해커로서 기여 악용 전에 발견작년에 한 대기업 쇼핑몰에서 Critical 취약점 찾았다. SQL Injection. 전체 고객 DB 접근 가능한 수준. 제보했다. 포상금 $5000. 약 650만원. 그리고 감사 메일 받았다. "덕분에 큰 사고 막았습니다. 감사합니다." 이 한 줄이 좋았다. 돈보다. 화이트 해커 문화가 중요한 이유다. 발견한 취약점을 악용하지 않고 제보한다. 기업은 정당한 보상을 한다. 선순환이다. 블랙 해커와 화이트 해커. 기술은 같다. 선택이 다를 뿐. 나는 지키는 쪽을 선택했다. 보안 공부는 끝이 없다 월요일 아침. 출근 지하철에서 책 읽는다. "Web Application Hacker's Handbook" 3번째 정독이다. 볼 때마다 새롭다. 보안 분야는 변화가 빠르다. 어제의 안전이 오늘의 취약점이다. 최근 공부 목록:GraphQL 보안 이슈 JWT 취약점 패턴 클라우드 보안 (AWS, GCP) 컨테이너 보안 (Docker, K8s) AI/ML 모델 공격 기법매일 2시간은 공부한다. 퇴근 후 1시간, 주말 5시간. 공부 루틴: 월/수/금: 온라인 강의 (Udemy, Pluralsight) 화/목: CTF 문제 풀기 (HackTheBox) 주말: 기술 블로그 읽고 정리 월 1회: 보안 컨퍼런스 참석 작년에 DEFCON 다녀왔다. 라스베가스. 세계 최대 해킹 대회. 회사에서 지원해줬다. 거기서 본 게 충격이었다. 내가 아는 건 빙산의 일각이다. 세상엔 천재들이 많다. IoT 해킹, 차량 해킹, 위성 해킹. 상상도 못 한 것들. 동시에 생각했다. '우리 회사는 안전한가?' 돌아와서 IoT 결제 단말기 보안 점검 제안했다. 승인 받았다. 실제로 취약점 2개 찾았다. 공부가 회사를 지킨다. 책임감과 연봉의 관계 연말 평가 시즌이다. 연봉 인상 협상했다. 현재 7000만원. 요구 금액 8000만원. 1000만원 인상. 근거 제시했다: 올해 성과:Critical 취약점 12건 발견 및 수정 모의해킹 4회 실시, 평균 위험도 50% 감소 보안 사고 0건 (업계 평균 2.3건) 버그바운티 제보로 외부 이미지 개선 신입 보안 QA 교육 및 온보딩시장 가치:동급 경력 타사 연봉: 7500~9000만원 최근 스카웃 제안: 8500만원 보안 인력 수요 증가율: 연 15%CTO 반응: "고민해볼게요." 일주일 뒤 답 왔다. 7800만원. 800만원 인상. 요구보다 200만원 적다. 근데 만족한다. 연봉이 높은 이유:희소성보안 QA 인력 부족 실무 경험자 더 적음 양성 기간 최소 3년책임의 무게한 번의 실수가 회사 존망 24시간 긴장 상태 정신적 스트레스 높음지속적 학습끊임없는 기술 습득 개인 시간 투자 많음 평생 공부 필수대체 불가능성자동화 어려움 인간의 창의성 필요 공격자 마인드셋 필수일반 QA는 테스트 케이스 수행한다. 나는? 존재하지 않는 케이스를 찾는다. "이렇게 하면 뚫릴까?" "공격자라면 어떻게 할까?" "여기가 약점일까?" 이게 내 연봉의 근거다. 보안 사고 대응 매뉴얼 책상 서랍에 빨간 봉투가 있다. "보안사고 대응 매뉴얼". 열어본 적 없다. 근데 매달 업데이트한다. 언젠가 필요할 수 있다. 단계별 대응 절차: Phase 1: 탐지 (Detection)이상 징후 모니터링 알림 로그 분석 및 공격 패턴 확인 영향 범위 1차 파악 경영진 즉시 보고Phase 2: 격리 (Containment)공격 경로 차단 영향받은 서비스 분리 추가 피해 확산 방지 증거 보존Phase 3: 제거 (Eradication)악성 코드/백도어 제거 취약점 패치 시스템 무결성 검증 재침투 가능성 차단Phase 4: 복구 (Recovery)서비스 단계적 재개 데이터 복원 및 검증 모니터링 강화 정상화 확인Phase 5: 사후 분석 (Post-Incident)원인 분석 보고서 재발 방지 대책 프로세스 개선 교육 및 훈련실제로 쓸 일 없기를 바란다. 근데 준비는 해야 한다. 작년에 모의 훈련했다. 가상 랜섬웨어 공격 시나리오. 전 직원 참여. 혼란스러웠다. 누가 뭘 해야 하는지 애매했다. 의사결정 느렸다. 그 경험으로 매뉴얼 3번 수정했다. 더 구체적으로. 연락망 명확히. 역할 세분화. 다음 훈련 때는 30분 단축됐다. 발전이다. 퇴근길 생각들 저녁 7시. 퇴근한다. 오늘도 무사히. 지하철 타고 집 간다. 핸드폰 본다. 보안 뉴스 체크. "미국 대형 은행 해킹, 2000만 고객정보 유출" 한숨 나온다. 또. 얼마 만에. 보안은 끝이 없다. 100번 막아도 한 번 뚫리면 끝이다. 공격자는 한 번만 성공하면 된다. 방어자는 매번 성공해야 한다. 불공평하다. 근데 이게 현실이다. 이 일을 계속하는 이유:누군가는 해야 하는 일 고객 자산 지킨다는 자부심 기술적 도전이 재미있음 화이트 해커로서의 정체성 적절한 보상 (솔직히 중요)가끔 생각한다. '일반 개발자 할까?' 코드 짜고, 기능 만들고, 배포하고. 스트레스 덜할 것 같다. 근데 못 한다. 이미 보안으로 세상을 본다. API 보면 취약점이 보인다. 웹사이트 들어가면 공격 벡터가 보인다. 직업병이다. 고칠 수 없다. 집 도착했다. 문 열고 들어간다. 노트북 가방 내려놓는다. 여자친구한테 문자 왔다. "저녁 먹었어?" "아직. 같이 먹을까?" "응 나갈게." 씻는다. 편한 옷 입는다. 거울 본다. 피곤해 보인다. 근데 괜찮다. 오늘도 회사 지켰다. 고객 돈 지켰다. 그걸로 충분하다. 내일도 출근한다. CVE 체크한다. 취약점 찾는다. 리포트 쓴다. 반복이다. 근데 중요한 반복이다. 핀테크 보안, 선택이 아닌 필수 마지막으로 정리한다. 핀테크 회사에 보안 QA가 필수인 이유. 간단하다. 돈을 다루기 때문이다. 일반 서비스는 다시 시작할 수 있다. 데이터 복구하고, 사과하고, 보상하고. 핀테크는? 한 번 털리면 끝이다. 고객 신뢰 회복 불가능. 금융 라이선스 박탈. 회사 문 닫는다. 그래서 보안 QA가 존재한다. 그래서 높은 연봉 받는다. 그래서 24시간 긴장한다. 우리가 하는 일:공격자보다 먼저 취약점 찾기 개발팀이 놓친 보안 이슈 발견 실제 해킹 시나리오 테스트 최신 공격 기법 연구 및 대응 보안 사고 예방 및 대응무거운 책임이다. 근데 해야 할 일이다. 고객은 모른다. 내가 밤새 취약점 찾는다는 걸. 주말에도 모니터링한다는 걸. 긴급 패치로 사고 막았다는 걸. 몰라도 된다. 그게 내 일이다. 조용히 지킨다. 눈에 보이지 않게. 사고 나지 않게. 보안의 역설: 완벽하게 일하면 아무도 모른다. 실패하면 모두가 안다. 그래도 한다. 이게 프로다.오늘도 아무 일 없었다. 그게 성공이다.

OWASP Top 10을 외우는 것보다 중요한 것들

OWASP Top 10을 외우는 것보다 중요한 것들

OWASP Top 10을 외우는 것보다 중요한 것들 외워봤자 뭐하나 OWASP Top 10 외웠다. SQL Injection, XSS, CSRF, 다 안다. 그런데 실무에서 막상 마주하면 못 찾는다. 신입 때 착각했다. OWASP Top 10만 외우면 보안 QA 끝인 줄. 실전은 달랐다. 취약점이 그렇게 교과서처럼 나오지 않는다. 변형되어 있고, 숨어 있고, 조합되어 있다. 첫 프로젝트 생각난다. SQL Injection 찾으라고 했다. 당연히 'OR 1=1-- 입력하면 되겠지' 했다. 안 터졌다. WAF가 막았다. 그다음은? 몰랐다. 선배가 인코딩 우회 보여줬다. 'UNION SELECT 대신 %55NION %53ELECT' 이런 식. 그때 깨달았다. 리스트 외우는 건 시작일 뿐이다.OWASP Top 10은 가이드다. 지도가 아니다. 지도는 따라가면 목적지 도착한다. 가이드는 방향만 알려준다. 길은 직접 찾아야 한다. 보안 QA 4년 하면서 느낀 거. 진짜 중요한 건 따로 있다. 이론보다 먼저 알았어야 할 것들. 선배들이 알려주지 않았던 것들. 지금부터 적는다. HTTP를 진짜 이해하는가 보안 테스트의 90%는 HTTP다. 웹 애플리케이션 진단이니까. 그런데 HTTP를 제대로 아는 보안 QA가 많지 않다. Request와 Response 구조. Header와 Body. Cookie의 동작 원리. Session 관리 방식. 이게 기본이다. 근데 이것도 모르고 Burp Suite 돌리는 사람 많다. 예를 들어본다. XSS를 찾는다고 하자. <script>alert(1)</script> 입력한다. 안 된다. Content-Type이 application/json이라서다. JSON에선 HTML 태그가 안 먹힌다. 그럼 어떻게? Content-Type을 text/html로 바꿔보거나, JSON 구조 내에서 실행 가능한 페이로드를 만들어야 한다.작년에 있었던 일. 신입이 "SQL Injection 안 되는데요" 했다. 봤더니 GET 파라미터만 테스트했다. POST Body는? Cookie는? Header는? 다 확인해야 한다. 그런데 HTTP 구조를 모르면 어디를 봐야 할지 모른다. 또 있다. Authentication vs Authorization. 인증과 인가. 헷갈리는 사람 많다. 인증은 "너 누구야?" 확인하는 거다. 인가는 "너 이거 할 권한 있어?" 확인하는 거다. 둘은 다르다. 로그인했다고(인증) 다른 사람 정보 볼 수 있는 건(인가) 아니다. 실제로 IDOR(Insecure Direct Object Reference) 취약점 많다. /api/user/123 이런 식. 내 ID가 123인데, 124로 바꾸면 다른 사람 정보 나온다. 인증은 되어 있다. 근데 인가 체크가 없다. 이게 구분 안 되면 못 찾는다. HTTP 상태 코드도 중요하다. 200, 302, 401, 403, 500. 각각이 뭘 의미하는지. 보안 관점에서 뭘 시사하는지. 302 Redirect 많이 나오면? 인증 로직 우회 가능성 있다. 401 Unauthorized랑 403 Forbidden 차이는? 401은 인증 안 됨. 403은 인증은 됐는데 권한 없음. 에러 메시지 다르게 나오면 계정 탐색(Account Enumeration) 가능하다. 프로토콜 레벨에서 이해해야 한다. OSI 7계층까지는 아니어도, Application Layer는 확실히. TCP 핸드셰이크, TLS 동작, DNS 조회. 이런 거 모르면 Man-in-the-Middle 공격 이해 안 된다. Burp Suite 쓰는 이유가 뭔가? HTTP 트래픽을 가로채서 조작하기 위해서다. 근데 HTTP를 모르면 뭘 조작해야 할지 모른다. 도구는 도구일 뿐이다. 개발을 조금이라도 할 줄 아는가 보안 QA가 코딩 못 해도 되나? 아니다. 절대 아니다. 스크립트는 필수다. Python, Bash, 뭐든 하나는 해야 한다. 자동화 안 하면 시간 부족하다. 수동으로 일일이 하면 하루 종일 걸린다. 예를 들어본다. API 엔드포인트 100개 있다. 각각 IDOR 취약점 체크해야 한다. 수동으로? 미친 짓이다. 스크립트 짜서 돌린다. 10분이면 끝난다. for user_id in range(1, 1000): response = requests.get(f'/api/user/{user_id}') if response.status_code == 200: check_unauthorized_access(response)이런 거다. 간단하다. 근데 코딩 모르면 못 한다. 더 중요한 건 코드 리뷰다. 개발자가 짠 코드 봐야 한다. 설계 단계에서 취약점 찾는 게 제일 효율적이다. 배포 후 찾으면 고치는 데 비용 10배다. 코드 보면 보인다. "여기 입력값 검증 안 하네", "SQL 쿼리 하드코딩했네", "시크릿 키 평문으로 박았네". 근데 코드 못 읽으면? 블랙박스 테스트만 한다. 시간 오래 걸리고 놓치는 것도 많다. 프레임워크 지식도 필요하다. Spring, Django, Express. 각각 보안 메커니즘이 다르다. Spring Security 어떻게 동작하나? Django의 CSRF 토큰은? Express의 미들웨어 순서는? 작년에 Django 앱 진단했다. CSRF 토큰 있었다. 근데 검증 로직을 개발자가 직접 짰다. 틀렸다. Django 내장 기능 안 쓰고 자기가 만들었다. 당연히 우회됐다. 코드 봤기 때문에 찾았다. 정규표현식도 알아야 한다. ReDoS(Regular Expression Denial of Service) 취약점 있다. (a+)+$ 이런 패턴에 "aaaaaaaaaaaaaaaaaa!" 입력하면 서버 뻗는다. 백트래킹 때문이다. 코드에서 정규식 보면 체크한다. Git도 봐야 한다. 커밋 히스토리에 시크릿 키 있다. 지웠어도 히스토리엔 남는다. .git 폴더 노출되면 전체 소스 다운받는다. 이것도 개발 흐름 이해해야 찾는다. 물론 풀스택 개발자 될 필요는 없다. 그냥 읽을 줄 알면 된다. 그리고 간단한 스크립트 짤 줄 알면 된다. 근데 이게 생각보다 큰 차이 만든다. 비즈니스 로직을 이해하는가 기술적 취약점만 찾으면 되나? 아니다. 비즈니스 로직 취약점이 더 치명적이다. SQL Injection으로 DB 털어도, 비즈니스 로직 허점으로 돈 빼가는 게 더 무섭다. 실제로 그런 케이스 많다. 예를 들어본다. 쿠폰 중복 사용. 로직상으로 한 번만 써야 한다. 근데 동시에 두 번 요청하면? Race Condition 발생한다. 쿠폰이 두 번 적용된다. 기술적으로 취약점 아니다. 근데 비즈니스적으론 큰 문제다. 핀테크라서 결제 로직 많이 본다. 취약점 많다. 환불 로직: 금액 검증 안 함. 100원 결제하고 1000원 환불 요청. 포인트 충전: 음수 입력. -1000원 충전하면 포인트 늘어남. 할인 쿠폰: 쿠폰 코드 예측 가능. COUPON001, COUPON002... 추천인 보상: 자기 자신 추천인으로 등록.이런 거 OWASP Top 10에 없다. 근데 실제로 돈 나간다. 테스트할 때 시나리오 짠다. "사용자가 이걸 악용하려면 어떻게 할까?" 공격자 마인드로 생각한다.정상 플로우 이해 경계값 테스트 (음수, 0, 최댓값) 순서 바꾸기 (3단계를 1단계보다 먼저) 동시 요청 (Race Condition) 반복 실행 (Rate Limiting 체크)지난주에 있었던 일. 송금 기능 테스트했다. 정상 플로우는 문제없었다. 그런데 "송금 중" 상태에서 취소 누르면? 돈은 빠져나갔는데 취소 처리됐다. 이중 지불 문제다. 기술적 취약점 아니다. 상태 관리 로직 문제다. 또 있다. 권한 관리. 일반 사용자가 관리자 기능 호출하면? API 레벨에서 막아야 한다. 근데 프론트엔드에서만 숨겨놓은 경우 많다. URL 직접 치면 들어가진다. 비즈니스 로직 이해하려면 기획서 봐야 한다. 개발자랑 얘기해야 한다. "이 기능 왜 이렇게 만들었어요?" 물어본다. 맥락 이해해야 허점 보인다. OWASP Top 10은 기술 중심이다. 근데 실제 사고는 비즈니스 로직에서 많이 난다. 이거 놓치면 안 된다. 방어자 관점만 가지고 있지 않은가 보안 QA는 공격자처럼 생각해야 한다. 방어만 생각하면 못 뚫는다. 개발자는 기능 만든다. "이렇게 쓰면 되겠지" 생각한다. 근데 공격자는? "이거 어떻게 악용하지?" 생각한다. 우리도 그래야 한다. 예를 들어본다. 파일 업로드 기능. 개발자는 "이미지만 올리겠지" 생각한다. 확장자 체크만 한다. .jpg, .png만 허용. 끝. 근데 공격자는? shell.php.jpg 올린다. 또는 shell.jpg인데 내용은 PHP 코드. MIME Type 속인다. 더블 익스텐션, Null Byte Injection, Content-Type 조작. 방법 많다. 공격 기법 공부해야 한다. 실제로 해보는 게 제일 좋다. 집에 랩 환경 있다. VirtualBox에 Kali Linux, DVWA(Damn Vulnerable Web App), WebGoat 돌린다. 여기서 연습한다. SQL Injection 어떻게 하는지, XSS 페이로드 어떻게 만드는지, RCE(Remote Code Execution) 어떻게 달성하는지. 이론으로만 알면 안 된다. 직접 해봐야 한다. sqlmap 돌려보고, msfvenom으로 페이로드 만들어보고, Reverse Shell 따보고. 그래야 감이 온다. CTF(Capture The Flag) 대회 자주 나간다. 한 달에 두 번 정도. Hack The Box, TryHackMe에서도 문제 푼다. 실력 유지에 좋다. 새로운 기법도 배운다. 지난달 CTF에서 배운 거. XXE(XML External Entity) 취약점. XML 파서가 외부 엔티티 처리할 때 생긴다. 파일 읽기, SSRF(Server-Side Request Forgery) 가능하다. 이론으론 알았다. 근데 실제로 exploit 작성하니까 확실히 이해됐다. 공격 도구도 써봐야 한다. Burp Suite, OWASP ZAP, Nmap, Nikto, SQLMap, John the Ripper, Hashcat. 각각 언제 쓰는지, 어떻게 쓰는지 알아야 한다. 근데 조심해야 한다. 회사 시스템에 함부로 쓰면 안 된다. 허가받고 테스트한다. 모의해킹 계약서 쓴다. 범위 명확히 한다. 실수로 서비스 터뜨리면 큰일이다. 작년에 있었던 일. 취약점 스캐닝 돌렸다. 스레드 너무 많이 설정했다. 서버 부하 급증. 서비스 느려졌다. 다행히 새벽이라 사용자 적었다. 그 후로 항상 테스트 환경 먼저 확인한다. 공격자 마인드셋. 이게 핵심이다. "여기서 뭘 뽑아낼 수 있을까?", "이거 우회하려면?", "이 기능 연계하면 더 큰 공격 되나?" 이렇게 생각한다. 커뮤니케이션을 할 줄 아는가 기술만 잘해서 되나? 아니다. 말을 잘해야 한다. 취약점 찾았다. 끝? 아니다. 개발자한테 전달해야 한다. 그것도 제대로. "여기 취약점 있어요" 이렇게 말하면? "뭐가 문제인데요?" 돌아온다. 리포트 쓰는 게 중요하다. 구조는 이렇다.취약점 이름: SQL Injection 위치: /api/login, username 파라미터 심각도: Critical (CVSS 9.8) 재현 방법: 스텝바이스텝, 스크린샷 첨부 영향: DB 전체 조회 가능, 계정 탈취 가능 해결 방안: Prepared Statement 사용, 입력값 검증 강화구체적이어야 한다. "보안 취약점 있음" 이건 쓰레기다. "사용자 입력값이 SQL 쿼리에 직접 삽입되어 공격자가 임의의 SQL 명령 실행 가능" 이게 리포트다. 재현 방법이 제일 중요하다. 개발자가 똑같이 해봐야 한다. 안 되면? "재현 안 되는데요?" 하면서 안 고친다. 1. Burp Suite에서 /api/login POST 요청 캡처 2. username 파라미터 값을 admin' OR '1'='1 로 변경 3. 요청 전송 4. 200 OK 응답, 관리자 계정으로 로그인 성공이렇게 적는다. 따라 하기만 하면 되게. 심각도 평가도 중요하다. CVSS(Common Vulnerability Scoring System) 쓴다. 숫자로 표현한다. 9.0 이상이면 Critical. 7.0~8.9면 High. 개발자가 우선순위 정할 수 있다. 근데 가끔 싸운다. "이거 Critical 아닌데요?" 한다. "실제 환경에서 exploit 어렵잖아요?" 그럼 설명해야 한다. "WAF 없으면 바로 뚫립니다", "실제 사례 있습니다". 근거 있어야 한다. 말투도 중요하다. "여기 취약점 있는데 왜 이렇게 짰어요?" 이러면 적 만든다. "여기 보안 이슈가 있는데, 같이 해결 방법 찾아볼까요?" 이게 맞다. 개발자는 적이 아니다. 같은 팀이다. 서비스 안전하게 만드는 게 공동 목표다. 그거 잊으면 안 된다. 회의 때 발표도 한다. 경영진한테 보안 현황 보고한다. 기술 용어 쓰면 안 된다. "SQL Injection이..." 하면 졸린다. "공격자가 고객 개인정보 전부 빼갈 수 있습니다" 이래야 귀 기울인다. 숫자로 말한다. "취약점 50개 발견, 그중 Critical 5개, 2주 내 패치 필요" 이렇게. 구체적이고 액션 가능하게. 커뮤니케이션 못 하는 보안 QA? 아무리 실력 좋아도 쓸모없다. 찾아도 전달 못 하면 의미 없다. 최신 트렌드를 따라가고 있는가 보안은 계속 변한다. 작년 방어법이 올해 안 통한다. 매일 아침 루틴이 있다. 출근하면 제일 먼저 보안 뉴스 체크한다.The Hacker News Krebs on Security r/netsec (Reddit) Twitter에서 보안 전문가들 팔로우CVE(Common Vulnerabilities and Exposures) 업데이트 본다. 새로운 취약점 나왔나 확인한다. 우리 회사 쓰는 라이브러리에 해당되나 체크한다. 예를 들어본다. Log4j 취약점(CVE-2021-44228). Log4Shell이라고 불렸다. 전 세계 난리났다. 우리도 긴급 점검했다. Java 쓰는 모든 서비스 체크했다. 다행히 해당 버전 안 썼다. 근데 모니터링은 계속했다. 이런 거 놓치면? 당한다. 실제로 Log4j 취약점으로 털린 회사 많다. 패치 늦었기 때문이다. 기술 스택 변화도 따라가야 한다. 요즘 클라우드 많이 쓴다. AWS, GCP, Azure. 각각 보안 설정 다르다. S3 버킷 권한, IAM 정책, Security Group. 이거 제대로 설정 안 하면 데이터 유출된다. 컨테이너 보안도 있다. Docker, Kubernetes. 이미지 스캔, 런타임 보안, 네트워크 폴리시. 새로운 영역이다. 공부해야 한다. API 많아졌다. REST, GraphQL. GraphQL은 복잡하다. 쿼리 깊이 제한 안 하면 DoS 된다. Introspection 노출되면 스키마 전체 보인다. 이것도 새로 배웠다. AI/ML 서비스도 나온다. Prompt Injection, Model Inversion, Data Poisoning. 완전히 새로운 공격 벡터다. 아직 연구 단계지만 알아야 한다. 공부 방법은 여러 가지다.온라인 강의: Udemy, Coursera, Pluralsight 책: "The Web Application Hacker's Handbook" (좀 오래됐지만 클래식) 컨퍼런스: DEFCON, Black Hat (비싸서 유튜브로 본다) 웨비나: OWASP Chapter 미팅 참석 블로그: 보안 전문가들 글 읽기자격증도 있다. CEH(Certified Ethical Hacker), OSCP(Offensive Security Certified Professional), CISSP. 나는 CEH 있다. OSCP 준비 중이다. 실습 많아서 힘들다. 근데 배우는 거 많다. 시간 투자해야 한다. 퇴근 후 1시간, 주말에 3시간 정도. 안 하면 뒤처진다. 보안 분야는 특히 빠르다. 가끔 지친다. "또 새로운 거 나왔네" 싶다. 근데 어쩔 수 없다. 이게 이 일이다. 좋아하지 않으면 못 한다. 실무에서 부딪히는 진짜 문제들 이론은 깨끗하다. 실무는 지저분하다. 리포트 써서 올린다. "Critical 취약점 5개 발견" 한다. 개발팀 반응은? "다음 스프린트에 처리할게요". 다음 스프린트? 2주 뒤다. 그사이 뚫리면? 모른다. 우선순위 싸움 많다. 개발팀은 기능 개발이 우선이다. 보안은? 나중이다. "지금 당장 문제 없잖아요" 한다. 터져봐야 안다. 작년에 있었던 일. IDOR 취약점 찾았다. 다른 사람 주문 내역 볼 수 있었다. High 심각도로 리포트했다. 2달 뒤에 고쳤다. 왜? "다른 기능 개발 중이라서요". 이해는 한다. 근데 답답하다. 리소스 부족도 문제다. 보안팀이 나 포함 3명이다. 개발팀은 30명. 모든 기능 다 보기 힘들다. 샘플링한다. 중요한 거 위주로. 놓치는 거 있을 수밖에. False Positive 문제도 있다. 자동화 스캐닝 돌리면 취약점 수백 개 나온다. 근데 반은 오탐이다. 일일이 확인해야 한다. 시간 엄청 걸린다. 그래서 요즘은 SAST(Static Application Security Testing), DAST(Dynamic Application Security Testing) 도구 쓴다. SonarQube, Checkmarx, Veracode. 자동화한다. 근데 이것도 튜닝 필요하다. 룰 설정 안 하면 노이즈 많다. 개발자 교육도 해야 한다. 근본 해결은 처음부터 안전하게 짜는 거다. Secure Coding 교

모의해킹 중 실수로 서비스를 터뜨린 날 - 그 후 어떻게 했나?

모의해킹 중 실수로 서비스를 터뜨린 날 - 그 후 어떻게 했나?

모의해킹 중 실수로 서비스를 터뜨린 날 - 그 후 어떻게 했나? 화요일 오후 3시 42분 모의해킹 중이었다. 결제 API 침투 테스트. OWASP Top 10 체크리스트 따라가는 중. SQL Injection 테스트 페이로드 날렸다. ' OR '1'='1 같은 거. 기본 중의 기본. 근데 응답이 이상했다. 500 에러. 한 번 더. 또 500.슬랙에 알림 떴다. "결제 시스템 장애 발생" "고객 결제 불가" "긴급 점검 중" 심장이 멈췄다. 15초 후 손이 떨렸다. 진짜로. 내가 터뜨린 거다. 확신했다. 타임스탬프 확인했다. 내 테스트: 15:42:38 장애 시작: 15:42:39 1초 차이. 로그 봤다. 내 IP 주소. 내 테스트 페이로드. 데이터베이스 커넥션 풀이 다 죽어있었다. "씨발." 입 밖으로 나왔다. 즉시 보고 팀장한테 슬랙 날렸다. "제가 터뜨린 것 같습니다" "지금 즉시 복구 지원하겠습니다" 전화 왔다. 떨리는 목소리로 받았다. "뭐 했어?" "SQL Injection 테스트요. 근데..." "스테이징이야 프로덕션이야?" "..." 침묵. VPN 설정 확인했다. 프로덕션 DB 접속되어 있었다. "프로덕션입니다." 팀장 한숨 소리. 길게.상황 파악 10분 CTO 포함 긴급 회의. 개발팀장, 인프라팀장, 보안팀장, 나. 내가 설명했다. "SQL Injection 페이로드 날렸고요" "데이터베이스 커넥션이 과부하 걸렸습니다" "제가 스테이징인 줄 알고..." 변명 아니다. 사실 그대로. CTO가 물었다. "데이터 유실은?" "없습니다. 확인했습니다." "개인정보 유출은?" "없습니다. Read 쿼리만 실행됐습니다." 로그 파일 공유했다. 다 떨렸다. 인프라팀장이 DB 재시작 중. 커넥션 풀 리셋. 5분 뒤 복구 완료. 15:57. 15분간 장애. 피해 규모 고객 278명 결제 실패. 예상 매출 손실 약 1200만원. CS 문의 83건. 장애 공지 올라갔다. "일시적 시스템 점검" "불편을 드려 죄송합니다" 고객들은 몰랐다. 보안 테스터가 터뜨렸다는 걸. 근데 회사는 안다. 내가 터뜨렸다는 걸. 즉시 수습 작업 오후 4시부터 밤 11시까지. 내가 한 일:전체 로그 분석 리포트 작성 영향받은 트랜잭션 리스트 추출 재시도 필요 건 식별 (개발팀 전달) 근본 원인 분석 문서화 재발방지 대책 수립왜 터졌나. DB 커넥션 풀 설정이 약했다. 맞다. 근데 그건 핑계다. 진짜 문제는 내가 프로덕션에 접속했다는 것. 스테이징인 줄 착각했다. VPN 설정 확인 안 했다. 기본 중의 기본을 안 지켰다.보고서 작성 11시 반. 최종 보고서 완성. 사고 경위15:42 보안 테스터가 프로덕션 환경에서 침투 테스트 실시 SQL Injection 페이로드로 DB 커넥션 풀 소진 15분간 결제 서비스 장애직접 원인프로덕션/스테이징 환경 미확인 테스트 전 체크리스트 미준수근본 원인VPN 프로파일 네이밍이 불명확 프로덕션 접근 권한 통제 미흡 모의해킹 가이드라인 부재재발방지 대책프로덕션 DB 접근 시 2단계 승인 필요 VPN 프로파일명 명확화 (PROD-빨간색 표시) 침투 테스트 체크리스트 의무화 프로덕션 테스트 시 Read-Only 계정만 사용 부하 테스트 전 Rate Limiting 확인솔직하게 썼다. 내 실수 숨기지 않았다. 수요일 오전 회의 임원 회의실. 긴장됐다. CTO가 먼저 말했다. "보고서 봤어요. 솔직하네요." "네." "처벌은 당연히 있습니다." 각오했다. "이번 달 성과급 50% 삭감" "그리고..." 잘렸나 싶었다. "재발방지 대책 실행 책임자 맡으세요" "네?" "당신이 제일 잘 알잖아요. 어떻게 터지는지." 의외였다. 팀장이 말했다. "실수는 누구나 해. 근데 수습을 어떻게 하느냐가 중요해." "15분 만에 보고했고" "7시간 동안 수습했고" "솔직한 보고서 썼어" "이게 프로야" 눈물 날 뻔했다. 참았다. 그 후 2주 재발방지 대책 실행했다.프로덕션 DB 접근 권한 재설계보안팀도 기본은 Read-Only Write 권한은 Jira 티켓 + 팀장 승인VPN 프로파일 UI 개선PROD는 빨간색, 경고 팝업 STAGING은 노란색 DEV는 초록색침투 테스트 체크리스트 제작 [ ] 환경 확인 (STAGING임을 3번 체크) [ ] Read-Only 계정 사용 [ ] 테스트 범위 문서화 [ ] 부하 영향도 사전 검토 [ ] 팀장 승인모의해킹 가이드라인 문서화전사 공유 신규 입사자 필독주간 보안팀 회의에서 Near-Miss 공유"나 이번 주에 이런 실수 뻔했어" 서로 배우는 문화한 달 후 성과급 50% 깎였다. 150만원. 아팠다. 근데 마땅했다. 대신 얻은 것. 개발팀이 보안팀 보는 눈이 달라졌다. "보안팀도 실수하네. 우리만 그런 게 아니구나" "근데 수습 진짜 빠르더라" 예전엔 보안 이슈 리포트하면 "나중에요~" 했는데 이제는 "언제까지 고칠게요" 한다. 왜? 내가 터뜨렸을 때를 봤으니까. 수습하는 모습도 봤으니까. 신뢰가 생겼다. 3개월 후 회고 분기 회고 때 발표했다. "제가 3개월 전에 프로덕션 터뜨렸습니다" 웃음 나왔다. 다들 알던 사실. "그 후 바뀐 것들"프로덕션 장애 0건 (보안 테스트 관련) 침투 테스트 체크리스트 준수율 100% 타팀에서도 우리 가이드라인 참고 Near-Miss 공유 문화 정착"배운 것"실수는 시스템으로 막아야 한다 솔직한 보고가 신뢰를 만든다 수습 속도가 전문성이다CTO가 말했다. "이게 성숙한 조직이에요" "실수를 숨기는 게 아니라" "실수에서 배우는 거" 박수 나왔다. 부끄러웠다. 지금 여전히 모의해킹한다. 침투 테스트한다. 근데 체크리스트는 무조건 본다. 환경 확인. 세 번. STAGING 맞나. 또 확인. VPN 프로파일 색상. 노란색 맞나. 강박이 생겼다. 좋은 의미로. 후배가 입사했다. 보안 QA 신입. 첫날 내가 말했다. "내가 3개월 전에 프로덕션 터뜨렸어" "어떻게요?" "체크리스트 안 봐서" 그리고 가이드라인 줬다. "이거 만든 사람이 나야" "왜냐면 터뜨려봐서 알거든" 후배가 웃었다. "선배, 솔직하시네요" "보안 일 하려면 솔직해야 해" "취약점 찾는 것도" "내 실수 인정하는 것도" 교훈이랄 것도 없지만 실수는 한다. 보안 전문가도 사람이니까. 중요한 건 그 다음이다. 15초 만에 인정할 건가. 15분 만에 보고할 건가. 15시간 동안 수습할 건가. 아니면 숨길 건가. 나는 15초 만에 알았다. "내가 터뜨렸다" 그게 시작이었다.프로덕션 터뜨린 날. 최악의 날이었다. 근데 최고의 배움이었다. 체크리스트는 생명이다.

Burp Suite 라이센스 비용이 아까워서 커뮤니티 버전으로 버티는 팁

Burp Suite 라이센스 비용이 아까워서 커뮤니티 버전으로 버티는 팁

라이센스 비용이 아깝다 Burp Suite Pro는 연 $449. 한화로 약 60만원. 회사에서 쓰는 건 회사 돈이니 상관없다. 그런데 주말에 개인 버그바운티 할 때는 내 돈이다. 60만원이면 원룸 월세 절반이다. 그래서 커뮤니티 버전으로 버틴다. 벌써 2년째다. Pro 쓰는 사람들은 "돈 벌려면 투자해야지"라고 한다. 맞는 말이다. 근데 아직은 아깝다. 커뮤니티 버전도 잘 쓰면 충분하다. 불편하긴 하다. 그래도 못할 건 없다. 오늘은 그 노하우를 정리한다.Pro와 Community의 차이 Pro 버전 주요 기능:자동 스캐너 (Active Scan) Intruder의 속도 제한 해제 Extension 추가 기능들 저장/로드 기능 강화 협업 기능Community 버전 제약:Active Scan 없음 (수동으로 해야 함) Intruder 속도 느림 (쓰레드 제한) 일부 Extension 제한 프로젝트 저장 안 됨솔직히 Active Scan 없는 게 제일 아프다. Pro는 버튼 하나면 취약점 찾아준다. Community는 내가 직접 찾아야 한다. 근데 생각해보면 수동 테스트가 실력이다. 자동 스캐너만 믿으면 놓치는 것도 많다. 그렇게 스스로 위로한다.Intruder 속도 제한 우회 Community 버전 Intruder는 느리다. 진짜 느리다. 한 번에 하나씩 요청 보낸다. 1000개 페이로드면 1000번 기다린다. Pro는 쓰레드 여러 개로 빠르게 보낸다. 해결책:Python으로 직접 만든다 ffuf 같은 외부 툴 쓴다 Turbo Intruder Extension 쓴다나는 Python을 주로 쓴다. import requests for payload in payloads: response = requests.post(url, data=payload)이런 식으로 간단하게 만든다. 멀티쓰레딩 추가하면 Pro보다 빠르다. ffuf도 좋다. 디렉토리 부르트포싱할 때 쓴다. ffuf -u https://target.com/FUZZ -w wordlist.txt속도는 ffuf가 제일 빠르다. Turbo Intruder는 Burp 안에서 쓸 수 있다. Python 스크립트 기반이다. 속도 제한 없다. 세 가지 다 익혀두면 Intruder 없어도 산다. Repeater가 진짜 핵심 Community 버전에서 가장 많이 쓰는 건 Repeater다. 요청 수정해서 다시 보내고, 응답 확인하고, 또 수정하고. SQL Injection 찾을 때:' OR '1'='1 넣어보고 admin' -- 시도하고 UNION SELECT 테스트하고XSS 찾을 때:<script>alert(1)</script> <img src=x onerror=alert(1)> javascript:alert(1)수동이지만 정확하다. 오탐이 없다. 자동 스캐너는 False Positive 많다. 일일이 확인해야 한다. Repeater는 내가 보낸 요청, 내가 본 응답이다. 확실하다.Extension 활용 Community에서도 쓸 수 있는 Extension이 많다. 내가 자주 쓰는 것:Logger++: 모든 요청 로깅 Autorize: 권한 테스트 자동화 Param Miner: 숨겨진 파라미터 찾기 Turbo Intruder: 속도 제한 우회 JS Link Finder: JS 파일에서 엔드포인트 추출Logger++는 필수다. Community는 프로젝트 저장이 안 되니까 로그라도 남겨야 한다. Autorize는 권한 테스트할 때 편하다. 일반 유저로 로그인해서 어드민 API 호출하는 걸 자동으로 해준다. JS Link Finder는 숨겨진 엔드포인트 찾을 때 좋다. React, Vue 같은 SPA는 API 주소가 JS에 다 있다. Extension만 잘 써도 Pro 부럽지 않다. 수동 테스트 체크리스트 자동 스캐너 없으니 체크리스트가 중요하다. 내 체크리스트: 인증/인가:토큰 없이 API 호출 가능한지 다른 유저 ID로 권한 탈취 가능한지 JWT 토큰 검증 제대로 하는지입력값 검증:SQL Injection (싱글쿼트 테스트) XSS (스크립트 태그 삽입) IDOR (숫자 ID 바꿔보기) Path Traversal (../../etc/passwd)비즈니스 로직:가격 조작 가능한지 수량 음수로 바꿔지는지 쿠폰 중복 사용 가능한지정보 노출:에러 메시지에 스택 트레이스 있는지 API 응답에 민감정보 있는지 주석에 비밀번호 있는지하나씩 체크하면서 Repeater로 테스트한다. 시간 걸린다. 근데 확실하다. 다른 툴과 병행 Burp만 쓰면 한계가 있다. 같이 쓰는 툴들: Nmap: 포트 스캔, 서비스 버전 확인 ffuf: 디렉토리/파일 브루트포싱 sqlmap: SQL Injection 자동화 nuclei: 알려진 취약점 스캔 httpx: 대량 URL 상태 확인 이것들 다 무료다. nuclei는 특히 좋다. YAML 템플릿으로 취약점 스캔한다. CVE 나오면 바로 템플릿 업데이트된다. nuclei -u https://target.com -t cves/이것만 해도 최신 취약점 찾을 수 있다. Burp는 프록시+Repeater로 쓰고, 나머지는 외부 툴로 보완한다. 실제 버그바운티 사례 지난달 버그바운티에서 $500 받았다. Community 버전으로만 찾았다. 타겟: 국내 이커머스 플랫폼 발견 과정:Burp Proxy로 트래픽 캡처 주문 API 발견: POST /api/order Repeater로 요청 확인 price 파라미터를 음수로 변경 요청 보냈더니 성공 주문하면서 돈 받는 버그리포트 제출하고 2주 뒤 $500 받았. 자동 스캐너 안 써도 찾을 수 있다. 로직 버그는 수동이 더 낫다. Pro 사야 하는 경우 솔직히 Pro가 필요한 경우도 있다. 대량 타겟 테스트: 스타트업 100개 테스트해야 하면 자동 스캐너 필요하다. 협업: 팀으로 일하면 프로젝트 공유 기능이 편하다. 시간이 돈: 시간당 수익이 높으면 자동화가 이득이다. 회사 돈: 회사 프로젝트면 당연히 Pro 써야 한다. 근데 개인 버그바운티, 공부 목적이면 Community로 충분하다. 실력 늘리기엔 수동이 더 좋다. 왜 취약점이 생기는지 이해하게 된다. 돈 모으는 중 올해 목표는 버그바운티로 1000만원 벌기다. 지금까지 300만원 정도 벌었다. 7개월 남았다. 1000만원 모으면 Pro 살 거다. 그래도 600만원 남는다. 그때까지는 Community로 버틴다. 불편하지만 불가능하진 않다. 오히려 제약이 실력을 키운다고 생각한다. 없으니까 더 머리 쓴다. Python 스크립트도 늘고, 체크리스트도 정교해진다. Pro 사는 날이 목표다. 근데 그 전까지의 과정도 배움이다. 커뮤니티의 힘 Burp Community Edition 유저들 커뮤니티가 있다. Reddit, Discord, 블로그에서 팁 공유한다. "이 Extension 좋더라", "이렇게 우회하더라" 같은 정보들. 혼자 쓰는 것보다 훨씬 강력하다. Pro 유저들은 돈으로 해결한다. Community 유저들은 지식으로 해결한다. 어떻게 보면 더 멋있다.Community 버전, 제약이지만 제한은 아니다. 방법은 항상 있다.

취약점을 못 찾으면 '없는 건지, 못 찾은 건지' 자책하는 밤

취약점을 못 찾으면 '없는 건지, 못 찾은 건지' 자책하는 밤

취약점을 못 찾으면 '없는 건지, 못 찾은 건지' 자책하는 밤 오후 3시, 스캔 시작 신규 결제 API 테스트 들어갔다. 개발팀이 자신 있다고 했다. "이번엔 보안 완벽하게 했습니다." 그 말 들으면 더 의심스럽다. Burp Suite 켰다. Proxy 설정하고 트래픽 캡처 시작. 일단 자동 스캔 돌려놨다. 커피 한 잔 마시러 갔다. 돌아와서 결과 확인. Low 몇 개. Medium 하나. 다 거짓 양성이다. 수동 테스트 시작했다. Authorization 헤더 빼봤다. 정상 처리됐다. 이상하다. 토큰 변조해봤다. 401 에러 떴다. 정상이다. SQL Injection 시도. Single quote, double quote, comment. 다 필터링됐다.XSS 테스트 들어갔다. Script 태그, event handler, encoded payload. 전부 sanitize됐다. 깔끔하다. 너무 깔끔하다. 이게 맞나. 오후 5시 됐다. 취약점 없다. 하나도. 6시, 퇴근 시간 동료들 하나씩 퇴근한다. "오늘 뭐 찾았어?" 물어본다. "아직요." 대답했다. "괜찮아, 없으면 없는 거지." 웃으면서 말한다. 없으면 없는 거. 그게 그렇게 간단하지 않다. 보안 QA 6년 차다. 취약점 못 찾는 날이 제일 불안하다. 찾으면 보람 있다. 회사 지켰다는 기분. 못 찾으면 모르겠다. 정말 안전한 건지, 내가 못 찾은 건지. 개발자들은 취약점 없으면 좋아한다. 당연하다. 수정할 거 없으니까. 나는 불안하다. 뭔가 놓친 것 같다. 리포트에 뭐라고 쓸까. "취약점이 발견되지 않았습니다." 이 한 줄. 허전하다. 믿을 수 있을까. 나도 확신 없는데. 여자친구한테 문자 왔다. "저녁 먹자." 답장 보냈다. "조금만 더." 남았다. 혼자. 8시, 다시 시작 처음부터 다시 봤다. 놓친 엔드포인트 있을 수 있다. API 문서 다시 읽었다. 15개 엔드포인트. 다 테스트했다. Rate limiting 확인했다. 잘 걸려 있다. 1분에 100 요청. Brute force 막힌다. IDOR 테스트했다. user_id 변조. 403 에러. 정상이다.SSRF 시도했다. 내부 IP 호출. 막혔다. XXE 테스트. XML 파싱 안 쓴다. GraphQL injection. GraphQL 안 쓴다. NoSQL injection. MongoDB 쿼리 검증 됐다. 2시간 더 지났다. 여전히 없다. 동료한테 물어볼까 생각했다. "내가 놓친 거 있을까요?" 부끄럽다. 6년 차가 이런 질문. 10시, 자책 시작 컴퓨터 앞에 앉아 있다. 화면만 본다. 뭘 더 해야 할까. OWASP Top 10 다시 확인했다. Injection. 확인했다. Broken Authentication. 확인했다. Sensitive Data Exposure. 암호화 됐다. XML External Entities. 안 쓴다. Broken Access Control. 확인했다. Security Misconfiguration. 기본 설정 변경됐다. XSS. 확인했다. Insecure Deserialization. 안 쓴다. Using Components with Known Vulnerabilities. 버전 다 최신이다. Insufficient Logging. 로깅 잘 된다. 다 확인했다. 그래도 불안하다. 작년 생각났다. 3일 동안 못 찾았던 API. "안전합니다" 리포트 올렸다. 2주 후에 버그바운티 해커가 찾았다. JWT 알고리즘 혼동 취약점. 'none' 알고리즘 허용했었다. 나는 못 봤다. 팀장 불렀다. "이거 왜 못 찾았어?" 할 말 없었다. "죄송합니다." 그것뿐이었다. 기본적인 건데. 6년 차가 놓쳤다. 그 이후로 더 신경 쓴다. 그래도 여전히 놓칠까 봐 무섭다. 11시, 마지막 시도 JWT 다시 봤다. 알고리즘 확인. RS256. 고정됐다. 'none' 안 된다. 서명 검증 잘 된다. Expiration 확인. 1시간. 적절하다. Refresh token 로직. 정상이다. Race condition 테스트했다. 동시에 100개 요청. 처리 잘 된다. 중복 안 생긴다. Business logic 봤다. 포인트 적립 로직. 음수 입력. 거부됐다. 환불 로직. 금액 확인 잘 된다. 쿠폰 중복 사용. 막혔다.File upload 기능 없다. CSRF 토큰 잘 된다. Clickjacking X-Frame-Options 설정됐다. CORS 정책 엄격하다. 자정 됐다. 9시간 봤다. 없다. 진짜 없는 건가. 아니면 내가 못 보는 건가. 자정, 집으로 퇴근했다. 사무실 나왔다. 차가운 바람. 12월이다. 택시 탔다. 창밖 본다. 불 켜진 건물들. 저기도 누군가 일한다. 보안 QA만 이럴까. 아니겠지. 여자친구한테 전화 왔다. "아직도 일해?" 목소리 졸리다. "퇴근했어. 미안." 걱정한다. "너무 늦게까지 하지 마." 설명 못 한다. 이 불안감. 취약점 찾으면 일 잘했다는 거다. 못 찾으면 모른다. 일을 잘한 건지, 못한 건지. 개발자는 다르다. 기능 만들면 된다. 동작하면 성공이다. 보안 QA는 애매하다. 안전하다는 걸 어떻게 증명하나. '취약점이 없다'는 증명은 없다. '찾지 못했다'는 것뿐이다. 새벽 1시, 침대에서 누웠다. 잠 안 온다. 핸드폰 켰다. 보안 뉴스 본다. 새로운 CVE 나왔다. npm 패키지 취약점. 우리 프로젝트에 있나 확인해야겠다. 생각이 꼬리를 문다. 오늘 테스트한 API. 진짜 안전할까. JWT 서명 검증 로직 직접 봤나. 소스 코드 확인 안 했다. 블랙박스로만 봤다. 내일 개발팀한테 물어봐야겠다. "JWT 라이브러리 뭐 쓰세요?" 혹시 오래된 버전. 알려진 취약점 있을 수 있다. 근데 그것도 찾으면 찾는 거고. 못 찾으면 모른다. 버그바운티 해커들 생각난다. 걔네는 어떻게 찾을까. 나보다 잘 찾는다. 돈도 번다. 나는 월급 받으면서 못 찾는다. 작년 그 해커. LinkedIn 찾아봤다. 19살이었다. 나보다 어리다. 실력은 훨씬 좋다. 질투 나는 건 아니다. 그냥 자괴감. 이 일 6년 했는데. 19살한테 진다. 새벽 2시, 검색 일어나서 노트북 켰다. JWT 취약점 검색했다. Algorithm confusion, Key confusion, KID injection, JKU/X5U claim abuse. 다 아는 거다. 다 테스트했다. 그래도 뭔가 놓친 것 같다. Stack Overflow 봤다. "How to test JWT properly." 답변 읽었다. 내가 하는 거랑 똑같다. YouTube 켰다. "Advanced JWT attacks." 40분짜리 영상. 봤다. 새로운 거 없다. 다 아는 내용이다. 그래도 불안하다. 문제는 이거다. 내가 아는 방법으로만 테스트한다. 모르는 취약점은 못 찾는다. 당연한 거다. 근데 받아들이기 힘들다. 보안팀장이 말했다. "완벽한 보안은 없어. 최선을 다하면 돼." 위로가 안 된다. 최선이 뭔데. 어디까지가 최선인가. 9시간 테스트했다. 최선이다. 근데 충분한가. 새벽 3시, 포기 노트북 껐다. 누웠다. 천장 본다. 어둡다. 내일 리포트 써야 한다. "신규 결제 API 보안 테스트 결과, 주요 취약점이 발견되지 않았습니다. 인증, 인가, 입력 검증, 에러 처리 등 전반적인 보안 구현이 양호합니다." 이렇게 쓸 거다. 사실이다. 발견되지 않았다. 없다고 안 했다. 발견되지 않았다. 개발팀은 좋아할 거다. "보안 테스트 통과했습니다!" 뿌듯해할 거다. 나는 불안할 거다. 배포되고 나서도. 실 서비스 올라가고 나서도. 해커가 찾을까 봐. 뉴스 뜰까 봐. "○○ 핀테크 결제 API 해킹." 댓글 달릴까 봐. "보안팀 뭐했냐." 팀장 부를까 봐. "이거 테스트 안 했어?" 했다. 9시간 했다. 최선을 다했다. 근데 못 찾았다. 이게 제일 무섭다. 열심히 했는데 결과가 없는 것. 아니다. 결과가 있는데 믿을 수 없는 것. 새벽 4시, 마음 정리 생각을 바꿔야 한다. 이건 알고 있다. 취약점을 못 찾는 게 실패가 아니다. 찾을 수 있는 걸 놓친 게 실패다. 찾을 수 없는 건 어쩔 수 없다. 내가 할 수 있는 건 했다. OWASP Top 10 확인했다. 알려진 공격 다 시도했다. Business logic 검토했다. 소스 코드 리뷰 요청할 거다. 9시간 집중했다. 더 할 수 있는 게 있나. 있다. 항상 있다. 무한정 시간 쓸 수는 없다. 선을 그어야 한다. 여기까지가 내 책임이다. 나머지는 운이다. 아니다. 나머지는 배포 후 모니터링이다. 침입 탐지 시스템이다. 버그바운티 프로그램이다. 혼자 다 막을 수 없다. 팀으로 한다. 회사 전체가 한다. 조금 마음이 편해진다. 조금. 새벽 5시, 잠 눈 감는다. 여전히 불안하다. 근데 받아들인다. 내일 출근하면 리포트 쓸 거다. "취약점 발견되지 않음." 자신 있게 쓸 거다. 최선을 다했으니까. 그리고 다음 테스트 들어갈 거다. 또 찾을 거다. 또 못 찾을 수도 있다. 또 불안할 거다. 이게 보안 QA다. 찾으면 보람 있고, 못 찾으면 불안하다. 끝이 없다. 근데 누군가는 해야 한다. 회사 지키는 일. 사용자 지키는 일. 내일도 한다. 모레도 한다. 잠든다.9시간 테스트하고 못 찾았다. 내일 또 한다.