OWASP Top 10

보안에서 막을 수 있는 구멍은 사실상 무한하고 팀의 시간은 유한합니다. 웹 서비스에 걸릴 수 있는 약점은 수백 가지로 정리되어 있는데, 보안 전담이 없는 마흔다섯 명 규모 팀이 그것을 순서 없이 훑으면 어디까지 봤는지도 남지 않습니다.

그래서 예전에는 점검이 사람에 따라 달랐습니다. 데이터베이스를 잘 아는 개발자가 있는 팀은 SQL 인젝션, 즉 입력창에 넣은 값이 질의문의 일부로 섞여 들어가는 공격을 꼼꼼히 막아 두고도 로그인 뒤의 권한 검사는 비워 두었습니다. 무엇을 빠뜨렸는지는 사고가 난 뒤에 알았습니다.

고객사와 이야기할 때도 같은 문제가 생겼습니다. 기업 고객이 도입 전에 보안을 어떻게 하고 있는지 물으면 답하는 쪽은 자기가 해 둔 것만 나열했고, 묻는 쪽은 빠진 항목이 무엇인지 알 방법이 없었습니다.

이 목록은 그 순서와 공통 언어를 만들려고 나온 문서입니다. 전부 막으라는 것이 아니라 가장 자주 터지는 열 가지를 먼저 보라고 순서를 정해 주고, 양쪽이 같은 이름으로 같은 것을 가리키게 만든 것입니다.

한 판은 항목 열 개로 이루어지고, 각 항목은 개별 버그 이름이 아니라 비슷한 약점을 묶은 범주입니다. 항목마다 이름과 순위, 그 범주에 묶인 세부 약점 목록, 실제 악용 시나리오, 예방 방법이 함께 붙습니다. 순위는 인상이 아니라 데이터로 정하는데, 수십만 개 애플리케이션 점검 결과에서 발견된 비율을 세고 자동 검사로 잡히지 않는 유형은 전문가 설문으로 보탭니다.

범주를 들여다보면 다루는 자리가 서로 다릅니다.

1. 접근 제어 붕괴 — 최근 판에서 1위입니다. 로그인은 통과했지만 그 사람이 그 일을 해도 되는지 확인하지 않은 경우, 즉 인가 검사가 빠진 상태입니다. 주소창의 문서 번호를 남의 것으로 바꾸면 열리는 사고가 여기입니다.
2. 암호 관련 실패 — 지켜야 할 값을 읽을 수 없게 만들어 두지 않은 경우입니다. 비밀번호를 그대로 저장한 상태가 대표적입니다.
3. 인젝션 — 들어온 값이 명령의 일부로 해석되는 경우입니다. 남이 심은 스크립트가 다른 사용자의 브라우저에서 실행되는 XSS도 최근 판에서는 여기 묶였습니다.
4. 설정 오류 — 코드가 아니라 설정 때문에 열리는 경우입니다. 관리자 화면의 기본 비밀번호를 그대로 둔 상태입니다.
5. 낡은 구성 요소 — 가져다 쓰는 외부 라이브러리에 이미 공개된 취약점이 남아 있는 경우입니다. 우리 코드는 멀쩡한데 버전이 옛것이라 열립니다.
6. 인증 실패 — 인증 절차 자체가 허술한 경우입니다. 로그아웃 뒤에도 예전 접속 정보가 통하는 상태가 여기 들어갑니다.
7. 기록과 감시 실패 — 뚫린 것을 알아채지 못하는 경우입니다. 침입 시도가 기록에 남지 않으면 다음 시도를 막을 수 없습니다.

쓰는 쪽은 웹 애플리케이션 보안을 공개적으로 다루는 국제 비영리 단체입니다. 특정 회사의 제품 문서가 아니라 자원해 참여하는 전문가들이 만들고, 순위의 근거가 되는 점검 데이터는 여러 보안 회사와 기관이 모아 냅니다. 개정은 몇 년에 한 번이고, 그때마다 항목이 합쳐지거나 새로 들어오기 때문에 인용할 때는 몇 년 판인지를 적습니다.

읽는 쪽은 넷입니다.

1. 개발자 — 기능을 만들면서 점검표로 씁니다. 화면 하나를 붙일 때 권한 검사가 들어갔는지, 입력값을 그대로 질의문에 넣지 않았는지를 항목 이름으로 확인합니다.
2. 코드를 검토하는 사람 — 무엇을 볼지 정해 둔 목록으로 씁니다. 보안 전담이 없는 팀에서도 기준이 사람마다 달라지지 않습니다.
3. 고객사의 보안 검토 담당자 — 도입 전에 보내는 확인 문서에 이 항목들을 그대로 옮겨 적습니다. 양쪽이 같은 이름을 쓰니 답변이 짧아집니다.
4. 교육 담당자 — 신입에게 보안을 가르칠 때 순서로 씁니다. 수백 가지를 다 가르치는 대신 열 가지부터 시작합니다.

쓰임이 다르니 기대도 어긋납니다. 고객사 담당자는 우리가 안전한지에 대한 답을 찾는데, 그것은 이 문서가 해 줄 수 없는 일입니다. 항목별로 답을 적어 보내는 것과 그 항목이 실제로 막혀 있는 것은 다르고, 그 간극은 모의 침투 테스트처럼 실제로 두드려 보는 점검이 맡습니다.

"이번 기업 고객 보안 검토 문서에 OWASP Top 10 항목별로 답하라는 칸이 있어요."

고객사가 이 목록을 심사 기준으로 쓰니 항목마다 대응 상태를 정리해야 한다는 말입니다.

"접근 제어 붕괴가 몇 판째 1위니까 화면마다 권한 검사가 있는지부터 봅시다."

목록의 순위를 점검 순서로 쓰자는 제안입니다.

"이건 목록에 없는 우리 쪽 고유 위험이라 따로 적어 둘게요."

목록이 다루는 범위 밖의 문제라서 별도로 관리하겠다는 뜻입니다.

페이지덱에서는 기업 고객 계약이 들어올 때 이 목록이 먼저 등장합니다. 수아가 받아 온 보안 검토 문서에 항목 열 개가 그대로 들어 있고, 태오가 항목별로 상태와 남은 일을 적어 보냅니다. 지난 분기에는 기록과 감시 항목에서 막혔습니다. 로그인 실패가 반복될 때 남는 기록이 없어 답을 적을 수 없었고, 그 칸 하나가 계약을 3주 늦췄습니다.

그 뒤로는 목록을 계약 때만 꺼내지 않습니다. 태오는 새 화면을 만들 때 권한 검사와 입력값 처리를 검토 기준에 넣어 두었습니다.

열 가지를 막으면 안전해진다고 읽는 경우가 가장 많습니다. 목록이 열 개로 끝나 있으니 점검표를 다 채우면 끝인 것처럼 보입니다. 하지만 이 목록은 자주 발견되는 순서로 고른 것이라 우리 서비스에만 있는 위험은 들어 있지 않습니다. 문서 협업 도구라면 공유 링크의 유효 기간이나 퇴사자 계정 처리처럼 우리 구조에서만 생기는 자리가 있습니다. 목록만 보고 통과했다고 판단하면 열 항목은 채워 둔 채 고유의 구멍은 열어 둔 상태가 됩니다.

이 문서를 준수 인증으로 오해하는 일도 자주 있습니다. 항목이 번호까지 붙어 있고 고객사가 심사에 쓰다 보니 규격처럼 읽힙니다. 하지만 이것은 무엇을 먼저 보라고 알려 주는 인식용 문서이고, 몇 점을 넘겨야 통과라는 기준이 붙어 있지 않습니다. 이 차이를 모르고 준수한다고 적으면, 상대가 그 문장을 인증으로 받아들인 뒤 점검 결과가 다르게 나왔을 때 신뢰 문제로 번집니다.