화면의 로그인만 믿을 수 없었던 내부 웹앱 보안 검토

한 내부 인사 문의 웹앱에는 로그인 화면과 관리자용 답변 기능이 있었다. 겉으로는 사용자를 구분하는 서비스처럼 보였지만, 실제 접근 제한도 서버에서 작동하는지는 별개였다. 내가 맡은 문제는 소스 코드 없이 공개된 배포 화면만 보고 인증과 권한 통제가 어디에서 이뤄지는지 확인하는 일이었다.

점검 결과, 로그인하지 않은 요청에도 별도의 인증 화면으로 이동하지 않고 앱 전체가 내려왔다. 브라우저가 받은 코드 안에는 로그인 상태와 관리자 여부를 판별하는 로직뿐 아니라 메시지 저장과 관리자 답변에 연결되는 서버 함수 이름도 포함돼 있었다.

실제로 맡은 문제

이 웹앱은 인사 관련 문의와 관리자 답변을 다루고 있었다. 화면에 로그인 절차가 있다는 사실만으로는 민감한 내용을 보호한다고 판단할 수 없었다. 익명 사용자가 배포 주소에 도달할 수 있는지, 일반 사용자와 관리자를 나누는 판단이 서버에서도 다시 확인되는지가 핵심이었다.

확인한 사실과 제약

쿠키와 로그인 정보가 없는 상태에서도 앱의 HTML 전체가 응답됐다. 그 안에서 로그인, 역할, 관리자 여부를 다루는 브라우저 코드와 여러 서버 호출 지점을 확인했다. 인사 정보와 관련된 문구도 반복해서 포함돼 있어 단순한 공개 화면으로 보기 어려웠다.

다만 이번 점검은 소스가 없는 외부 관찰 방식이었다. 서버 함수를 익명으로 직접 실행해 데이터가 반환되는지 시험하지 않았고, 실제 데이터도 추출하지 않았다. 실행 주체와 소유 계정 역시 배포 설정을 보지 못해 확정할 수 없었다.

내가 한 선택

확인 범위를 익명 응답과 브라우저에 전달된 코드 분석까지로 제한했다. 실제 데이터에 접근하는 방식으로 위험을 입증하지 않고, 이미 확인된 사실과 구조상 우려를 나눠 기록했다.

그래서 익명 접근과 브라우저 측 역할 판별은 확인된 문제로 남겼지만, 서버 함수가 어떤 권한으로 실행되는지와 실제 데이터 반환 여부는 추가 확인 항목으로 분리했다.

실제로 한 일

로그인 정보가 없는 요청의 응답을 확인하고, 앱이 인증 전에 어느 범위까지 전달되는지 살폈다. 내려온 코드에서는 로그인 상태와 관리자 여부를 판별하는 부분, 일반 메시지와 관리자 답변을 저장하는 호출 지점을 찾아 정리했다.

이 결과를 바탕으로 배포 접근 범위를 조직 내 로그인 사용자로 제한하고, 서버에서도 사용자와 관리자 권한을 판별하도록 바꾸는 조치안을 제시했다. 스크립트와 데이터의 소유 주체를 조직이 관리하는 계정으로 옮길 필요도 별도 과제로 남겼다.

확인된 결과와 남은 일

익명 사용자에게 앱 전체가 전달되고, 화면의 로그인과 관리자 구분이 브라우저 코드에 의존한다는 사실은 확인했다. 따라서 현재 화면만으로 접근 통제가 보장된다고 볼 수 없었다.

아직 배포 설정이 실제로 변경됐다는 근거는 없다. 서버 함수의 익명 실행 가능 여부, 인사 관련 문구가 실제 데이터 조회와 연결되는지, 앱과 데이터의 소유 주체도 미확인 상태다. 다음 점검에서는 소스나 배포 설정을 열어 실행 주체와 접근 권한을 확인해야 한다.