My Code, My Kill. - Web 기술 스택

구현 전략

SSR 기반 + 부분 AJAX 통신

기술 스택

- Frontend(FE)

• HTML/CSS/JavaScript (Language, Vanila)
• Bootstrap5 (Optional)
• NGINX (Web Server)
• Docker (Container)

- FE ↔ BE 통신

• Axios (AJAX)
• EJS (View Engine)
• JSON

- Backend(BE)

• TypeScript (Language)
  (JS 동적언어 상태 그대로 서버를 구현하는 것은 실무 환경과 맞지 않다고 판단함.)
• Express (BE 프레임워크)
• Node.js (자바스크립트 런타임)
• Docker (Container)

- Database(DB)

• PostgresSQL
• Docker (Container)

- BE ↔ DB 통신

• Sequelize (ORM)
• JSON

- Orchestration

• Docker Compose

- VM (모의 개발/운영 환경 조성)

• Ubuntu LTS (x64 or ARM)
• VMWare Workstation or Fusion

- CI/CD & Cloud

• 로컬(취약점 실습 목적이라, 배포는 위험하다고 판단)

견적/구현 과정에서의 타협점

1. React, Vue.js 등 최신 FE 프레임워크 미사용

• 최신 FE 프레임워크(라이브러리) 대다수는 DOM 렌더링 과정에서 입력값에 대해 자동으로 Escape 처리가 이루어진다.
• 따라서 Stored/Reflected XSS 공격에 매우 강하며, 1달이라는 제한시간 내에 다양한 형태의 공격을 수행 및 재현하는 것에는 무리가 있다고 판단하였다.
• 물론 취약한 설계 패턴 적용, 위험한 Prop 사용 등 인위적으로 XSS를 유발하는 것이 가능은 하다.
  (e.g. ref 객체를 통해 innerHTML 삽입, dangerouslySetInnerHTML prop 사용 등)
• 혹은 CVE 사례를 인용하여, 취약점이 보고된 구버전의 FE 프레임워크를 사용하여 DOM XSS를 중점적으로 실습을 진행하는 것도 불가능한 것은 아니다.
• 다만 위에서 언급한 일련의 방법들이 일반적인 개발패턴과 어울리지 않는 인위적인 방식이라고 판단하여, 기술 스택에서 제외하였다.

견적/구현 과정에서의 고민점

1. ORM vs. Raw Query

• ORM을 이용하는 것은 현업의 DB 접근/호출 방식과 매우 유사한 방식이다. (Sequelize, MyBatis 등)
• 처음부터 ORM을 잘 설계하여 정의해놓으면, 수동으로 쿼리를 짜는 것보다 개발 시간이 유의미할 정도로 단축된다.
• 다만 ORM을 통해 자동으로 정의된 쿼리 소스를 수동으로 변조하지 않는 이상, 잘못된 PreparedStatement 처리와 쿼리 작성으로 인한 SQL Injection을 유발하기 힘들다.
• SQL 쿼리 수동변조가 불가하다면, ORM 버전 자체의 취약점을 공략하지 않는 이상 SQL Injection 유발이 힘들어질 수도 있다.

2. XML 실습 미흡

• XML를 이용한 데이터 교환 시나리오가 없음(Java 관련 스택 아님, 레거시 코드 미구현).
• 따라서 XML 관련 취약점 실습이 불가한 상황임(직렬화/역직렬화 과정에서의 원격 코드 삽입 등).
• XML -> Excel 변환 라이브러리 등 우회적인 방법이 있을 것으로 예상됨.

최초 작성일자: 2026-01-05
최근 수정일자: 2026-01-05