SQL 인젝션

정보 시큐러티 > 취약성・공격 수법 > 인젝션 공격(영문판) > SQL 인젝션

SQL 인젝션(영: SQL Injection)이란, 어플리케이션의 시큐러티상의 미비를 의도적으로 이용해, 어플리케이션이 상정하지 않는 SQL문을 실행시키는 것으로, 데이터 베이스 시스템을 부정하게 조작하는 공격 방법.또, 그 공격을 가능하게 하는 취약성이다.

SQL에 다른 SQL문이 「주입(inject)」되는 것부터, 「다이렉트 SQL 커멘드 인젝션」혹은 「SQL 주입」이라고 불리기도 한다.

목차

원리

어플리케이션이 입력치를 적절히 이스케이프 하지 않는 채 SQL중에 전개하는 것으로 발생한다.

다음과 같은 SQL를 발행하는 것을 생각한다.

 SELECT * FROM users WHERE name = '(입력치)'; 

여기서 입력치에"t' OR 't' = 't"라고 하는 문자열을 주었을 경우를 생각하면, SQL문은 다음 같게 전개된다.

 SELECT * FROM users WHERE name = 't' OR 't' = 't'; 

이 SQL문으로는 조건이 항상 진이 되기 위해, name 컬럼의 값에 관계없이, 전레코드가 선택된다.이러한 공격은, 입력치가 1개만의 것에는 한정되지 않는다.

이것을 응용한 것에, SELECT의 조건식에 데이터 베이스내의 정보를 확인하는 서브 쿠에리-를 포함하게 해 그 추출의 성공 여부에 의해서 본래 참조할 수 없는 테이블명등의 데이터 베이스내의 정보를 안다고 한, 블라인드 SQL 인젝션으로 불리는 수법도 존재하는[¹].예를 들면, 「테이블명의 1 문자눈이 a의 테이블은 존재할까?」 「a로 시작되어 2 문자눈이 b의 테이블은 존재할까?」등의 정보를 확인하는 서브 쿠에리-를 포함해 그 추출의 성공 여부를 열심히 모아 가면, 테이블명이나 항목명을 확인할 수 있다.

또, 복수의 SQL문을 주입하는 것에 의한 데이터의 파괴나 개찬, 스트아드프로시쟈가 실행되는 것에 의한 정보의 누설이나 개찬, OS커멘드의 실행등을 일으킬 수도 있는 경우가 있다.

SQL 인젝션은, 입력치를 적절히 이스케이프 하는 것으로 막을 수 있다.상술의 문자열중에의 전개로는, 메타 캐릭터'를'' (단일 인용부호 2)에 이스케이프 하는 것으로써, 다음과 같은 SQL가 되어, 의도되었던 대로 name 컬럼이"t' OR 't' = 't"라고 하는 값을 가지는 레코드가 선택된다.

(단일 인용부호를 2회 연속해 기술하면, 하나의'라고 하는 문자 리터럴로서 인식된다.)

 SELECT * FROM users WHERE name = 't'' OR ''t'' = ''t'; 

다만, 데이터 베이스 시스템에 따라서는, 단일 인용부호 이외의 포위 문자를 이용해 문자열 리터럴을 나타낼 수 있는 것이 존재한다.예를 들면, MySQL로는 동작 모드에 따라서는 이중 인용부호를 문자열의 포위 문자로서 사용 가능한[²].이러한 환경하에서, 상기와 같은 SQL문의 생성을 실시하는 프로그램중에서 이중 인용부호를 둘러싸 문자를 이용하고 있다면, 이중 인용부호를 이스케이프 할 필요가 있다.

그 밖에, 문자열 리터럴중의 단일 인용부호를 표현하는 방법이 복수 존재하는 것도 있다.예를 들면 MySQL나 PostgreSQL의 버전이나 설정 하기에 따라 , 이스케이프 문자로서 backslash를 사용해 특수 문자를 표현하는 것이 가능하다.이 방법을 이용하면\'나\047 (주：047은 단일 인용부호의 8진표기)라고 하는 문자열이 문자열 리터럴중의 단일 인용부호를 나타내게 된다.이러한 데이터 베이스 시스템으로는, 단순하게 단일 인용부호를 이중화하는 것 만으로는 SQL 인젝션 대책으로서는 불충분하다.예를 들면 입력치에"\' OR 1=1 --"라고 하는 문자열을 주고 거기에 포함되는 단일 인용부호를 단순하게 이중화하면, 상술의 SQL는 이하와 같이 해석된다.

 SELECT * FROM users WHERE name = '\'' OR 1=1 --'; 

이중화 된 단일 인용부호 가운데, 전자는 전치 된 backslash와 합쳐져 문자열 리터럴중의 단일 인용부호를 의미하게 되어, 후자는 문자열 리터럴의 종단을 의미하게 된다.여기서—-이후가 코멘트라고 보여지면, 이 SQL의 조건은 항상 진이 되어, SQL 인젝션이 성립하게 된다.즉, backslash도 이스케이프를 필요로 한다.

더욱은, 문자 코드에 따라서는 2바이트째에 backslash가 포함되는 문자를 가지는 것이 존재해, 이스케이프 처리를 실시하는 라이브러리에 따라서는 일본어를 잘 취급할 수 없기 위해(때문에), 전술과 같은 escape sequence로서 backslash가 기능하는 일도 있을 수 있다.데이터 베이스에 SQL를 발행하는 언어측의 사정에 의해, 문자 코드 변환이 자동적으로 발생하는 것에 따르고, 전술과 같은 escape sequence로서 backslash가 기능하는 일도 있을 수 있는[³].

대책

전반적인 대책

언어마다 준비된 바인드 기구의 이용

SQL 인젝션을 막으려면 , 입력치를 적절히 이스케이프 할 수 있으면 좋다.그렇지만, 전절에 든 것처럼, 입력치를 적절히 이스케이프 하는 것은, 그만큼 단순하게 실시할 수 있는 것은 아니다.데이터 베이스 시스템이나 라이브러리에 따라서는, 바인드 기구로 불리는 구조를 이용해 이스케이프 처리 불필요하고 안전하게 SQL를 발행하는 방법이 설치되고 있는 것이 있어, 대책 누락을 막는데 있어서 유용하다.

실례

• 2005년 3월에 발생한, 클럽 투어리즘의 신용카드 정보를 포함한 개인정보 누설

  동년 6월에 클럽 투어리즘을 포함한 14사에의 부정 액세스의 혐의로 중국인 유학생이 체포되었다.

• 2005년 5월에 발생한, 가격. com의 Web 사이트 개찬

  수법은 공표되어 있지 않지만, SQL 인젝션에 의하는 것이다고 하는 설이 있다.클럽 투어리즘 사건의 범인은 가격. com에의 부정 액세스도 가고 있었다.

• 2005년 6월에 판명된, 아데코의 개인정보 누설-클럽 투어리즘 사건과 동일범
• 2005년 8월에 판명된, 시즈오카 신문사 앗트에스의 개인정보 누설-클럽 투어리즘 사건과 동일범
• 2005년 11월에 발생한, 와코르 온라인 숍의 신용카드 정보를 포함한 개인정보 누설
• 2005년 11월에 발생한, 키즈 온라인의 어카운트 정보 누설
• 2006년 1월에 판명된, 스카이 소프트의 신용카드 정보를 포함한 개인정보 누설

  스카이 소프트는 폐점으로 몰렸다.

• 2006년 4월에 발생한, 루루부의 어카운트 정보 누설
• 2006년 6월에 발생한, 일본 체육 협회의 Web 사이트 개찬
• 2007년 7월에 판명된, @SOLA 숍의 신용카드 정보를 포함한 개인정보 누설
• 2008년 3월에 발생한, 트랜드 마이크로, @nifty, 크리에이티브 미디어의 Web 사이트 개찬
• 2008년 3월에 발생한, 사운드 하우스의 신용카드 정보를 포함한 개인정보 누설

  과거에 설치된 부정 프로그램을 경유해 부정 액세스를 한 혐의가 있다.

• 2008년 4월에 발생한, 카뷰의 Web 사이트 개찬
• 2008년 5월에 발생한, 아이드랏그스트아, 아이뷰티스트아의 신용카드 정보를 포함한 개인정보 누설
• 2008년 5월에 발생한, 후지산 매거진 서비스의 Web 사이트 개찬
• 2008년 6월에 발생한, 아이리스 플라자의 신용카드 정보 누설
• 2008년 7월에 판명된, 나츄람의 신용카드 정보를 포함한 개인정보 누설

  과거에 설치된 부정 프로그램을 경유해 부정 액세스를 한 혐의가 있다.

• 2008년 7월에 발생한, 미국용 PlayStation의 Web 사이트 개찬
• 2008년 7월에 발생한, 독립 행정법인 석유 천연가스・금속광물 자원 기구의 Web 사이트 개찬
• 2008년 10월에 발생한, 골프 다이제스트・온라인의 Web 사이트 개찬
• 2010년 1월에 발생한, 몬벨의 신용카드 정보 누설
• 2010년 7월에 발생한, 코에이테크모호르딘그스의 GAMECITY 회원의 개인정보 누설[⁴]
• 2011년 4월부터 발생하고 있는, 소니의 PlayStation Network의 개인정보 누설에 시작하는, 소니 그룹의 개인정보 누설.
• 2013년 4월에 판명된, 액스 컴 글로벌의 신용카드 정보 누설

  10만 9112건의 카드 명의인명, 카드 번호, 카드 유효기간, security code, 신청자 주소가 외부에 유출한 것을 확인.

2008년 3월 무렵보다, SQL 인젝션에 의한 Web 사이트의 개찬이 다발하고 있는[⁵].

정보가 유출했을 경우에는 기업 존속의 위기로 연결될 수도 있다.정보처리 추진 기구(IPA)는 SQL 인젝션에 의한 피해로부터의 복구 코스트는 1억엔을 넘을 수 있는으로 하고 있어[⁶], 실제로 사운드 하우스의 사례로는 보상만에서도 122884명에 1000엔 상당한 기한부 크레디트를 부담하고 있다.보상 외에도 전문가에 의한 조사, 시스템의 교체, 고객 대응, 일시 폐쇄에 의한 영업 기회의 일실, 풍문 피해라고 하는 부담이 있어, SQL 인젝션도 포함 시큐러티 대책은 엄밀하게 실시해야 하는 것이다.

NRI 시큐어가 기업을 대상으로 2007년도에 간 시큐러티 진단의 통계로는,41%의 Web 사이트가 부정 액세스 가능하고, 그 중22%로 SQL 인젝션 공격에 대한 취약성이 있던[7]^.또, 이 통계로, SQL 인젝션의 취약성중84%가, 대책은 가고 있었지만 빠져 나갈 구멍이 존재했다.

각주

1. ^ "Blind SQL Injection white paper". 2011년 7월 6일 열람.
2. ^ "MySQL 5.1 Reference Manual - 9.1. 1 String Literals". 2014년 12월 8일 열람.
3. ^"다른 문자 집합에의 변환이 취약성으로 연결된다". 2011년 7월 6일 열람.
4. ^코에이테크모호르딘그스 주식회사-부정 액세스에 의한 손님 개인정보 누설의 사과와 보고, 2010년 7월 20일.
5. ^ JPCERT / CC에 의한 주의 환기.
6. ^ Internet Watch - SQL 인젝션의 복구 코스트, 1억엔 넘는 사례도〜IPA가 보고서, 2006년 11월 29일.
7. ^ NRI 시큐어- Web 사이트의 시큐러티 진단：경향분석 리포트 2008, 2008년 7월 28일.

관련 항목

• 개인정보 누설

외부 링크

• 독립 행정법 인정보처리 추진 기구 기술 본부 시큐러티 센터, 「시큐어・프로그래밍 강좌」 제6장 입력 대책 SQL 주입 2014년 8월 19일 열람
• @IT Security&Trust - Web 어플리케이션에 잠복하는 시큐러티 홀 제 2 회고객 데이터가 모두 도둑맞는다?!
• 시큐러티 대기업도 피해・본격화한 사이트 이용자 정보의 강탈 공격
• 독립 행정법 인정보처리 추진 기구 시큐러티 센터, 「안전한 SQL의 호출하는 방법」 「안전한 웹 사이트를 만드는 방법」별책(2010년 3월 발행 PDF)

「https://ja.wikipedia.org/w/index.php? title=SQL 인젝션&oldid=63387089」로부터 취득

This article is taken from the Japanese Wikipedia SQL 인젝션

This article is distributed by cc-by-sa or GFDL license in accordance with the provisions of Wikipedia.

Wikipedia and Tranpedia does not guarantee the accuracy of this document. See our disclaimer for more information.

In addition, Tranpedia is simply not responsible for any show is only by translating the writings of foreign licenses that are compatible with CC-BY-SA license information.