백엔드 코어 데이터베이스 개편, 결제 파이프라인 연결 및 SQL Injection 심화·CSRF 다층 방어 정리

서론

"프론트엔드와 백엔드 연결 상태를 점검하고, 데이터 무결성을 위해 스키마를 크게 수정했습니다. Flyway 중복 마이그레이션 문제를 해결하고 PortOne 실결제 경로 연동을 이어갔으며, 인프런 보안 학습을 바탕으로 SQL Injection 심화 공격(UNION/BLIND)과 CSRF 토큰 교차 검증 방어 구조를 정리했습니다."

Flyway 스키마 개편과 PortOne 실결제 경로 연동을 이어가는 동시에, UNION/BLIND SQL Injection과 CSRF 토큰 교차 검증 방어 구조를 정리했습니다.

1. 프로젝트 데이터 무결성을 위한 백엔드 핵심 스키마 수정 및 LBS 보완

백엔드 전체 모듈을 통합한 뒤 생긴 세부 명세 차이를 해결하고, 데이터베이스와 공간 데이터의 정확도를 높이기 위해 구조를 수정했습니다.

① 핵심 도메인 스키마 수정 및 형상 관리 최적화

• 정산 및 객실 스펙 확장: 판매자 정산 및 계정 관리를 위해 seller_account 구조를 V1 테이블 초기 생성에 추가했습니다. 숙소 상세 옵션을 늘리기 위해 rooms 테이블에 새 비즈니스 컬럼을 추가하는 V5 마이그레이션 스크립트도 적용했습니다.
• Flyway 버전 파이프라인 충돌 해결: 개발팀 병렬 머지 과정에서 생긴 V9 중복 스키마 문제를 발견했습니다. 시스템 인스턴스를 중단하지 않고 정합성을 맞추기 위해 중복 구간을 나누고 V10 버전으로 마이그레이션을 분리했습니다.

② 지리 공간 데이터(LBS) 정밀화 및 프론트엔드 최적화

• 좌표 데이터 교체: 지도 탐색 화면(MapPage.tsx)의 핀 위치 오차를 줄이기 위해 데이터베이스에 저장된 숙소 위도와 경도 좌표값을 수정했습니다. 구글 드라이브로 공유된 최신 정제 합본 CSV 데이터를 기반으로 데이터베이스 마이그레이션을 마쳤습니다.
• 숙소 레이지 로딩(Lazy Loading) 적용: 대량의 지리 데이터 및 최신 숙소 리스트 로드 시 브라우저 오버헤드를 줄이기 위해 IntersectionObserver 기반의 숙소 카드 레이지 로딩을 추가해 렌더링 성능을 높였습니다.

2. 비즈니스 파이프라인 결합: PortOne 실결제 및 커뮤니티 개선

• 실결제 경로 연동: 가상 환경의 응답에 의존하던 결제 흐름에서 벗어나, 프론트엔드 포트원 결제창 요청과 백엔드 payments/prepare·validate 검증 계층을 이어서 PortOne 실결제 경로 연동을 이어갔습니다.
• 여행기(Community) 도메인 수정: 사용자 UX 피드백을 반영하여 여행기 피드 커뮤니티 작성 및 수정 폼의 데이터 바인딩 예외 처리를 정돈했습니다.

3. [보안 선행 학습] SQL Injection 심화 공격 메커니즘 분석

10일차에 학습한 단순 로그인 인증 우회를 넘어, 데이터베이스 내에 숨겨진 중요 마스터 정보를 통째로 탈취하고 시스템 권한을 얻는 심화 공격 기법의 원리를 체계적으로 정립했습니다.

① 취약점 발생 원인의 재확인

사용자 입력값(파라미터)이 숫자형이든 문자형이든 관계없이, 입력값에 대한 적절한 검증이나 필터링 없이 미완성 SQL 구문과 그대로 결합(Concatenation)되어 데이터베이스 엔진으로 전송될 때 발생합니다. 이로 인해 변조된 SQL 질의가 데이터베이스에서 그대로 실행되고, 결과에 따라 화면이 동적으로 구성되면서 공격이 성공하게 됩니다.

② UNION-Based SQL Injection (데이터 조회 공격)

하나의 쿼리 결과에 다른 쿼리 결과를 합쳐 반환하는 UNION 연산자의 특성을 악용해 데이터베이스의 민감 테이블을 조회하는 공격 기법입니다.

• 공격 성립의 2대 필수 조건:
  1. 원래의 쿼리가 조회하는 컬럼의 개수와 UNION SELECT 뒤에 붙일 쿼리의 컬럼 개수가 정확히 일치해야 합니다. (일치하지 않을 경우 Syntax/Column Mismatch 에러 발생)
  2. 각각 대조되는 컬럼의 데이터 타입이 상호 호환 가능해야 문법 오류 없이 데이터가 화면에 출력됩니다.
• 실전 공격 프로세스:
  1. ORDER BY 1, 2, 3... 연산이나 UNION SELECT 1, 2, 3... 대입을 통해 원본 쿼리의 출력 컬럼 개수를 먼저 알아냅니다.
  2. 원본 파라미터 값에 존재하지 않는 인덱스(예: idx = -1)를 주입하여 원래의 데이터 결과셋을 비워버립니다.
  3. UNION SELECT null, column, null FROM target_table 형태로 주입하여, 정상적인 화면의 텍스트 출력 칸에 공격자가 원하는 민감 테이블 데이터(주민번호, 비밀번호 등)가 다이내믹하게 강제 렌더링되도록 유도합니다.
• 로컬 파일 무단 열람 연계: DBMS의 시스템 권한 함수인 LOAD_FILE('/etc/passwd') 등을 UNION 구문에 병합 주입하여, 데이터베이스 서버 디스크 내부의 중요 환경 설정 파일까지 브라우저 화면으로 무단 탈취할 수 있습니다.

③ Blind-Based SQL Injection (데이터 추론 공격)

오류 메시지도 노출되지 않고, 화면에 UNION처럼 데이터 결과가 직접 뿌려지지도 않는 폐쇄적인 환경에서 사용되는 추론 기법입니다.

• 공격 원리: 데이터가 직접 출력되지는 않지만, 공격자가 던진 질의 조건의 참(True)과 거짓(False) 여부에 따라 웹 페이지의 응답 반응(성공 메시지 가시성, 혹은 응답 지연 시간)이 미세하게 달라지는 점을 이용합니다. 스무고개 방식으로 데이터베이스의 참 값을 한 글자씩 유추해 나갑니다.
• 핵심 추론 함수 활용:
  • SUBSTRING(문자열, 시작위치, 길이): 대상 데이터의 특정 자릿수 글자 하나만을 추출합니다.
  • ASCII(문자): 추출한 문자를 아스키 숫자 코드로 변환하여 부등호 비교 연산(>, <, =)이 가능하게 만듭니다.
  • 추론 메커니즘 예시:
    sql복사

    -- 관리자 비밀번호의 1번째 글자 아스키코드가 100보다 큰지 참/거짓 판별
    SELECT * FROM members WHERE id='admin' AND ASCII(SUBSTRING(password, 1, 1)) > 100#
    

    이 조건 결과에 따라 달라지는 웹 애플리케이션의 반응을 누적 계산하여, 툴이나 스크립트를 통해 최종 평문 데이터를 복원해 냅니다.

4. [보안 방어 대책] Prepared Statement 시큐어 코딩 및 CSRF 토큰 검증

① 차단 처방전: Prepared Statement 컴파일 엔진 적용

SQL Injection을 막는 대표적인 방법은 Prepared Statement(매개변수화 쿼리)를 쓰는 것입니다.

• 방어 원리: 문자열을 단순히 이어 붙이는 방식(Concatenation)과 달리, 데이터베이스 엔진이 SQL 쿼리의 뼈대와 구조를 먼저 컴파일합니다. 그 후 사용자의 입력값은 쿼리 구조에 영향을 주지 못하는 단순한 '데이터 리터럴(값)'으로만 매핑되어 처리됩니다.
• 개발 가이드: MyBatis 환경에서 스트링 치환 방식인 ${parameter} 방식의 가용을 배제하고, Prepared Statement 파라미터 바인딩 방식인 #{parameter} 구문 사용을 의무화해야 함을 명확히 정의했습니다.

② CSRF(사이트 간 요청 위조) Token 교차 검증 구조

사용자의 브라우저 권한을 악용해 원치 않는 변조 요청을 강제 송신하는 CSRF 공격을 방어하기 위한 Form Page와 Action Page 간 이원화 교차 검증 프로세스를 정립했습니다.

1. Form Page 계층 (토큰 발급 및 분배): 인증된 사용자가 안전한 입력/수정 화면에 진입하면, 백엔드 엔진은 즉시 유추 불가능한 암호학적 랜덤 난수 토큰을 발급합니다. 이 토큰은 웹 서버 메모리 내부인 **세션(Session) Token**에 바인딩됨과 동시에, HTML 문서 내의 파라미터(Parameter) Token 영역(<input type="hidden">)에 복사되어 클라이언트로 이원화 배분됩니다.
2. 네트워크 구간 (요청 발생): 사용자가 전송 버튼을 누르면, 브라우저는 HTML 폼 내부에 은닉되어 있던 파라미터 Token 값을 HTTP Request Body 파라미터에 실어 서버로 송신합니다.
3. Action Page 계층 (교차 유효성 검증): 요청을 수신한 백엔드 컨트롤러는 서버 메모리에 안전하게 보관 중이던 세션 Token과 클라이언트가 패킷 Body에 담아 보낸 파라미터 Token 값을 **일대일 동기화 대조 연산(=)**으로 비교합니다. 두 값이 일치할 때만 비즈니스 로직을 정상 수행하고, 토큰이 누락되었거나 일치하지 않는 위조 요청은 바로 차단합니다.

5. 기능 영역별 최종 상태 점검

6. 다음 단계: 메인 브랜치 머지 및 프로덕션 배포 관리 방식 정리

• 메인 브랜치 최종 통합 및 Lock-In: 프론트엔드와 백엔드 간 실시간 API 통신 테스트가 확인되면, 각 기능 브랜치 코드를 공통 원격 저장소의 main 브랜치에 병합(Merge)하고 업로드 처리.
• 통합 기술 명세서 작성: 코드가 메인에 반영하는 즉시 백엔드·프론트엔드 담당을 중심으로 전체 플랫폼 아키텍처 토폴로지와 실행 표준을 규정하는 공동 README.md 작성에 착수.
• 클라우드 실배포 타당성 확정: 인프라 파트와 협의하여 현재 작성이 완료된 Dockerfile 및 docker-compose.yml 패키지 설정을 기반으로 실제 AWS 인프라 환경 상용 배포 가동 여부를 최종 결정 및 가동.
• 실전 웹 취약점 진단 및 수동 모의해킹 가동: 플랫폼 '온데'의 전 구간 시스템 결합이 완료됨에 따라, 6월 8일부터 Burp Suite 프록시 툴을 활용하여 우리 시스템 내부의 파라미터 변조, 결제 가격 위변조, SQL Injection, BOLA 취약점을 도출하기 위한 본격적인 취약점 진단 시나리오 가동.