#960 웹 취약점과 데이터 왜곡을 원천 차단하는 인코딩 파이프라인: ZeliBase의 XSS 엔티티 이스케이프와 RFC 3986 URL·Base64 양방향 변환 아키텍처

"선생님이 제작한 온라인 교안 속 수학 기호(<, >)가 브라우저에서 HTML 태그로 오작동하거나, 학교 홈페이지에 업로드한 학습지 파일명 '수학_1단원.pdf'가 서버로 전송되는 과정에서 %EC%88%98%ED%95%99 같은 퍼센트 인코딩 오류로 깨지는 현상은 개발자와 사용자 모두를 고통스럽게 합니다. 또한 테스트를 위해 민감한 텍스트를 정체불명의 온라인 Base64 사이트에 붙여넣는 순간 보안 사고가 발생합니다. ZeliBase는 완전 격리 오프라인 환경에서 웹 4대 핵심 코덱을 0.001초 만에 상호 변환합니다."

1. 웹 데이터 전송의 3대 지뢰: "XSS 인젝션, 한글 쿼리 깨짐, 바이너리 전송 오류"

웹 브라우저와 HTTP 프로토콜은 본질적으로 7비트 아스키(ASCII) 텍스트를 기반으로 설계되었습니다. 현대 공교육 포털과 국방 인트라넷이 다국어와 멀티미디어, 복잡한 인증 토큰을 주고받을 때 세 가지 치명적인 문제가 발생합니다:

크로스 사이트 스크립팅(XSS, Cross-Site Scripting): 사용자가 입력한 문자열에 <script>나 onload= 같은 HTML/JS 구문이 포함되어 있을 때, 이를 그대로 화면에 렌더링하면 관리자 세션 쿠키가 탈취됩니다.
URL 쿼리 스트링 왜곡(Query Corruption): URL에는 알파벳과 일부 기호만 허용되므로, 한글(UTF-8 3바이트)이나 공백, &, = 기호가 쿼리 파라미터 경계선을 무너뜨려 데이터가 유실됩니다.
바이너리 텍스트 전송 오류: 암호화 키, 이미지 데이터, 압축 파일 등 8비트 이진 데이터는 텍스트 프로토콜을 통과할 때 제어 문자(CRLF, EOF)로 오인되어 바이트가 손상됩니다.

2. XSS 공격의 원천 봉쇄: HTML 엔티티 이스케이프(HtmlEncode)와 DOM 텍스트 노드 격리

OWASP Top 10의 단골 취약점인 XSS를 방어하는 가장 근본적인 수단은 브라우저 렌더링 엔진(Blink, WebKit)이 입력 문자열을 HTML 엘리먼트가 아닌 순수 텍스트 노드(Text Node)로 인식하도록 만드는 것입니다.

ZeliBase의 WebUtility.HtmlEncode 엔진은 5대 위험 문자를 HTML 표준 엔티티(Entity)로 완벽 치환합니다:

원시 문자	이스케이프 엔티티	XSS 공격 위험 시나리오 및 방어 원리
`<`	`<`	태그 시작을 차단하여 `<script>` 태그 삽입 원천 무력화
`>`	`>`	태그 종료를 차단하여 기존 HTML 속성 탈출 방어
`&`	`&`	엔티티 치환자 자체를 이스케이프하여 2차 인젝션 방어
`"`	`"`	속성값 따옴표를 탈출하여 `onmouseover=` 이벤트 핸들러 주입 차단
`'`	`'`	작은따옴표 기반 SQL 및 JS 문자열 인젝션 차단

C# (ZeliBaseWindow.xaml.cs) HTML 엔티티 인코딩/디코딩 파이프라인

case 2: // HTML 엔티티 코덱
    // 인코딩: 위험 문자를 &lt;, &gt; 등으로 안전 격리
    TxtOutput.Text = WebUtility.HtmlEncode(input);
    TxtStatus.Text = Loc.Get("Base_HtmlEncodeSuccess");
    break;

// 디코딩: 브라우저가 해석하는 원본 기호로 복원
case 2:
    TxtOutput.Text = WebUtility.HtmlDecode(input);
    break;

3. 한글과 특수문자의 완전한 전송: RFC 3986 퍼센트 인코딩(UrlEncode) 수학

HTTP GET 요청에서 한글 쿼리는 각 바이트를 16진수로 표현하고 앞에 %를 붙이는 퍼센트 인코딩(Percent-Encoding)을 거쳐야 합니다.

예를 들어 한글 "수학"은 UTF-8 바이트로 0xEC, 0x88, 0x98, 0xED, 0x95, 0x99 (총 6바이트)이며, ZeliBase는 이를 즉각 %EC%88%98%ED%95%99로 변환합니다.

C# (ZeliBaseWindow.xaml.cs) RFC 3986 URL 퍼센트 인코딩/디코딩 엔진

case 1: // URL 퍼센트 코덱
    TxtOutput.Text = WebUtility.UrlEncode(input);
    TxtStatus.Text = Loc.Get("Base_UrlEncodeSuccess");
    break;

case 1: // 디코딩
    TxtOutput.Text = WebUtility.UrlDecode(input);
    break;

웹 개발자와 행정관은 링크가 깨지거나 서버에서 400 Bad Request가 발생할 때, URL 쿼리를 ZeliBase에 붙여넣어 단 1밀리초 만에 사람이 읽을 수 있는 한글과 파라미터로 디코딩하여 문제 지점을 찾아낼 수 있습니다.

4. 6비트 바이너리 직렬화: Base64 스트림과 패딩 보정 수식 (4 - len % 4) % 4

Base64는 8비트 바이트 3개(총 24비트)를 6비트 단위 4개로 쪼개어, 64개의 안전한 아스키 문자(A-Z, a-z, 0-9, +, /)에 매핑하는 알고리즘입니다.

데이터 길이가 3의 배수가 아닐 때 끝자리에 = 패딩을 붙이는 것이 표준 규격이지만, 웹 전송 및 JWT에서는 끝자리 패딩이 생략된 Unpadded Base64Url 문자열이 자주 유입됩니다.

ZeliBase는 수학적 패딩 보정 공식 (4 - length % 4) % 4를 적용하여 어떤 불완전한 문자열이 들어와도 파싱 예외 없이 패딩을 자동 복원합니다:

C# (ZeliBaseWindow.xaml.cs) 수학적 패딩 복원 및 Base64Url 디코딩 수식

private string DecodeBase64Url(string base64Url)
{
    // 🛡️ 핵심 보정 수식: 길이가 4의 배수가 되도록 부족한 바이트 수만큼 '=' 패딩 자동 추가
    // len % 4 == 2 ➔ 2개 추가, len % 4 == 3 ➔ 1개 추가, len % 4 == 0 ➔ 0개 추가
    string padded = base64Url.PadRight(base64Url.Length + (4 - base64Url.Length % 4) % 4, '=');
    padded = padded.Replace('-', '+').Replace('_', '/');

    return Encoding.UTF8.GetString(Convert.FromBase64String(padded));
}

flowchart TD subgraph RawData["입력 데이터 (문자열 또는 바이너리)"] In["Input Text / Token"] end subgraph CodecSelect["4대 코덱 스위칭 엔진"] In -->|"Case 0"| B64["Base64 (6비트 스트림 직렬화)"] In -->|"Case 1"| URL["RFC 3986 URL 퍼센트 코덱"] In -->|"Case 2"| HTML["XSS 엔티티 이스케이프 (<, >)"] In -->|"Case 3"| JWT["JWT 인라인 3단 분해"] end subgraph OutputView["결과 뷰 및 양방향 스왑(Swap)"] B64 --> Out["TxtOutput 렌더링"] URL --> Out HTML --> Out JWT --> Out Out -->|"BtnSwap_Click (원클릭 반전)"| In end classDef raw fill:#1e293b,stroke:#14b8a6,stroke-width:2px,color:#99f6e4; classDef codec fill:#0f172a,stroke:#38bdf8,stroke-width:2px,color:#f8fafc; classDef out fill:#1a103c,stroke:#a855f7,stroke-width:2px,color:#e9d5ff; class RawData,In raw; class CodecSelect,B64,URL,HTML,JWT codec; class OutputView,Out out;

5. JWT 인라인 분해와 서명 키 없는 인코딩의 보안 가드레일

ZeliBase는 콤보박스에서 JWT 모드를 선택했을 때, 토큰의 온점(.) 3개 파트를 즉각 감지하여 HEADER, PAYLOAD, SIGNATURE로 분리해 보여줍니다.

특히 주목할 엔지니어링 디테일은 JWT 인코딩 버튼을 누를 때 임의의 가짜 서명으로 위조 토큰을 생성하는 것을 거부하고 친절한 안내 메시지(Base_JwtEncodeNotSupported)를 띄운다는 점입니다:

"암호학적 서명 키(Secret Key)가 없는 상태에서 사용자가 입력한 JSON을 JWT 형태로 조립해 주는 기능은, 개발자에게 서명이 검증되지 않은 가짜 토큰을 운영 환경에 투입하게 만드는 치명적인 보안 착시를 유발합니다. ZeliBase는 보안 원칙에 따라 서명 키 없는 임의 인코딩을 엄격히 차단하고 정식 ZeliJWT 검증기를 사용하도록 유도합니다."

6. 기존 인코딩 도구(온라인 변환기 vs 브라우저 콘솔 vs ZeliBase) 심층 비교

비교 항목	공개 웹 온라인 변환기	브라우저 개발자 콘솔 (JS)	ZeliDesk ZeliBase
데이터 누출 위험	매우 높음 (서버 전송 및 로그 저장)	낮음 (로컬 브라우저)	완전 제로 (0바이트 완전 격리)
XSS 엔티티 변환	일부 사이트 광고 도배	수동 함수 작성 필요	원클릭 5대 엔티티 완벽 이스케이프
URL 한글 처리	EUC-KR / UTF-8 혼선 빈번	encodeURIComponent() 한정	RFC 3986 UTF-8 표준 엄격 준수
Base64 패딩 결함 보정	패딩 누락 시 파싱 에러	atob() 실행 시 DOMException 발생	(4 - len % 4) % 4 수식 자동 보정
양방향 스왑(Swap)	수동 복사 & 붙여넣기	변수 재할당 필요	[⇄ 스왑] 버튼 하나로 즉각 반전

7. 결론: "안전하고 무결한 디지털 교육·국방 웹 생태계의 초석"

웹 인코딩은 단순한 텍스트 변환 작업이 아니라, 시스템의 보안 경계선을 수호하고 데이터의 왜곡을 방지하는 웹 아키텍처의 1차 방어선입니다.

ZeliBase는 가장 널리 쓰이는 4대 웹 인코딩 프로토콜을 하나의 유려하고 가벼운 인터페이스로 통합하여, 교사와 시스템 엔지니어들이 외부 유출 걱정 없이 안전하고 정확하게 텍스트를 정제할 수 있는 최고의 생산성 환경을 제공합니다.