CSV를 내보낼 때 모든 필드를 큰따옴표로 감쌌다면 스프레드시트의 수식 해석도 막힌 것일까? CSV의 따옴표는 필드 경계를 표현하는 문법이다. 가져온 값을 텍스트로 둘지 수식으로 해석할지는 소비 프로그램의 다른 판단이다. 외부 입력을 CSV로 전달한다면 두 경계를 각각 확인해야 한다.
이 글은 설문·문서 AI·업무 시스템의 결과를 스프레드시트로 넘기는 담당자를 위한 설명이다. 예시는 실제 사용자 데이터가 아닌 =1+1 문자열이다. 로컬 CSV 파서가 반환한 문자만 확인했으며, 스프레드시트에서 수식 계산·매크로·외부 네트워크 동작을 실행하지 않았다.
바깥따옴표가 사라진 뒤에도 값은 남는다
합성 자료를 모든 필드 인용 옵션으로 내보내면 다음과 같은 레코드를 만들 수 있다.
"ticket","=1+1"Python CSV 파서가 반환한 두 값은 ticket과 =1+1이었다. 바깥따옴표는 CSV 문법으로 처리되고 두 번째 문자열의 등호는 그대로 남았다. 이 결과가 곧 ‘어느 앱에서도 계산된다’는 뜻은 아니다. CSV 파싱만으로 그 문자열에 수식 금지 속성이 붙지는 않는다는 것을 보여 주는 로컬 예다.
쉼표나 줄바꿈이 값 안에 있을 때의 올바른 인용은 CSV 레코드·필드 파싱에서 확인할 수 있다. 경계를 잘못 쓰면 새로운 셀이 생길 수 있으므로 올바른 직렬화 역시 필요하다. 다만 그것과 셀의 해석 정책은 같은 검사가 아니다.
공식 가져오기 옵션에서 두 경계를 확인한다
LibreOffice의 Text Import 도움말은 구분자·문자열 구분자와 별도로 Evaluate formulas를 설명한다. 이 옵션은 등호로 시작하는 표현을 수식으로 평가할지 텍스트로 가져올지를 정한다. 같은 도움말에는 인용된 필드를 텍스트로 처리하는 옵션과 열의 Text 타입도 있다. 메뉴 이름과 동작은 실제 사용하는 버전·가져오기 경로에서 확인해야 한다.
| 판단 | 확인할 설정·자료 | 그 확인만으로 알 수 없는 것 |
|---|---|---|
| 필드가 제대로 나뉘는가 | 구분자, 인용 문자, 내부 따옴표 처리 | 가져온 셀이 텍스트인지 수식인지 |
| 입력을 문자 그대로 보존하는가 | 열 타입·수식 평가 옵션과 실제 가져오기 결과 | 다른 앱·버전·열기 경로의 동일 동작 |
| 계산을 의도했는가 | 수식 허용 열·작성 주체·허용한 목적 | 외부 입력의 임의 수식을 모두 신뢰해도 되는지 |
| 다시 저장해도 계약이 유지되는가 | 출력된 값과 재가져오기 때의 실제 셀 타입 | 첫 화면이 같다는 이유만으로 이후도 같은지 |
이 표는 작성자의 업무 구분이다. 외부 자유입력 열을 문자로 읽는 업무와, 내부에서 작성한 계산식을 의도적으로 쓰는 업무를 섞지 않는다. 숫자나 날짜처럼 보이는 문자열의 자동 변환도 별도 문제다. 예를 들어 번호를 보존하려면 식별자의 타입·정밀도 경로까지 맞춰야 한다.
접두문자 하나를 모든 소비자에 대한 보장으로 쓰지 않는다
OWASP의 CSV Injection 설명은 외부 입력이 스프레드시트의 수식으로 해석되는 문제를 다룬다. 등호뿐 아니라 다른 시작 문자·제어 문자와 필드 경계도 고려하며, 모든 스프레드시트와 후속 소비자에 안전한 보편적 CSV 정화 전략은 없다고 명시한다.
따라서 ‘작은따옴표나 탭을 앞에 붙였으니 어디서 열어도 안전하다’고 결론내리지 않는다. 접두문자를 넣는 방식은 실제 값 자체를 바꿀 수 있고, 다른 프로그램이 그 문자를 남기거나 다르게 처리할 수 있다. 허용 문자를 검사하는 규칙도 실제 숫자·식별자·메모의 계약과 충돌하지 않는지 봐야 한다. 특정 앱에 맞춘 조치를 범용 표준으로 제시하지 않는다.
의심되는 값이 있으면 자동으로 열어 계산해 보는 대신, 우선 문자 데이터로 분리해 어떤 값과 열이 문제인지 확인할 수 있다. 배포 대상과 가져오기 방법을 통제할 수 없다면 그 상태에서 검증된 텍스트 보존을 보장할 수 없음을 남긴다. 이것은 위험 수식을 실행해 확인하라는 제안이 아니다.
재저장과 재가져오기까지 확인 범위를 잇는다
OWASP는 Excel에서 저장·재열기 과정이 따옴표나 이스케이프를 제거해 기존 조치가 무효가 될 수 있음을 경고한다. Microsoft의 파일 형식 안내도 CSV가 셀에 표시된 텍스트·값을 저장하며 셀 서식 등은 유지하지 않는다고 설명한다. 처음 텍스트로 가져왔다는 사실만으로 내보낸 CSV에도 같은 셀 타입 정책이 실려 있다고 가정할 수 없다.
작성자는 정상 문자열과 무해한 수식 모양 문자열을 구별해 원문→CSV 파싱 결과→가져온 셀 타입/표시→재출력·재가져오기 결과를 비교할 것을 제안한다. 허용된 대상 버전과 경로에서 필요한 범위를 확인하고, 확인하지 못한 다른 소비자는 미검증으로 남긴다. 이 글에서 수행한 것은 앞 단계의 로컬 문자열 파싱뿐이다.
문자 자체가 달라졌다면 수식 정책을 바꾸기 전에 CSV 인코딩·BOM 문제를 구별한다. 또 이 문제는 외부 문장이 LLM의 지시로 승격되는 문제와 다르다. 여기서는 언어 모델의 판단 없이도 소비 프로그램의 셀 해석이 경계가 된다.
자주 묻는 질문
모든 등호를 지우면 되나요?
문자 그대로 보존해야 할 값이나 의도한 계산식까지 바뀔 수 있다. 외부 입력의 어느 열을 텍스트로 받고 어떤 계산만 허용할지 먼저 정한다. 변환이 필요하다면 원래 값과 변환 이유를 필요한 범위에서 추적할 수 있어야 한다.
인용된 필드를 텍스트로 가져오는 옵션이면 충분한가요?
그 옵션의 적용 범위와 실제 결과를 해당 제품·버전에서 확인해야 한다. 수식 평가 설정, 인용되지 않은 필드와 다른 열의 타입도 함께 봐야 한다. 그 결과를 다른 앱이나 재저장 이후에 자동으로 확대하지 않는다.
CSV 파서가 수식 문자열을 돌려준 것만으로 취약하다고 판정하나요?
아니다. 파서는 문자열을 반환할 수 있고, 후속 프로그램은 이를 텍스트로 유지할 수도 있다. 실제 소비 경로에서 어떤 셀 타입과 행동이 생기는지 확인해야 한다. 이 글의 파싱 결과는 특정 앱의 취약성·방어 성공을 시험한 증거가 아니다.