생일 축하해 SQL 인젝션, 절대 사라지지 않는 버그여

이 기사의 원문은 Help Net Security에 게재되었습니다. 본 콘텐츠는 업데이트를 거쳐 이곳에 신디케이션되었습니다.

‍

코드에 대한 이해가 필요한 실무 보안 업무를 담당하고 있다면, SQL 인젝션에 대해 수없이 고민해 보셨을 겁니다. 이는 발견된 지 몇 주 만에 간단한 해결책이 나왔음에도 불구하고, 여전히 우리 소프트웨어를 괴롭히며 배포 전 탐지되지 않을 경우 공격자들에게 작은 기회의 창을 제공하는 흔한 취약점입니다.

2020년 12월 13일은 SQL 인젝션의 22번째 생일이었습니다. 이제는 성인이 되어도 충분할 만큼 오래된 취약점이지만, 우리는 이를 완전히 근절하기는커녕 여전히 휘둘리고 있습니다. 올해 8월, Freepik Company는 SQL 인젝션 실수로 인한 피해를 입어 830만 명의 사용자 계정이 유출되었다고 밝혔습니다. 이들 중 상당수는 타사 로그인(Google, Facebook 등)을 이용했지만, 수백만 명의 사용자 이름과 암호화되지 않은 비밀번호가 노출되었습니다. 안타깝게도 이 사건으로 인한 후폭풍은 엄청난 골칫거리이며, 사용자들의 신뢰를 회복하는 것은 장기적인 과정이 될 것입니다.

이 고질적인 문제를 "기념"하는 김에 잠시 분석해 보겠습니다. 왜 이 문제는 계속 발생하는지, 왜 수년째 OWASP Top 10의 상위권을 차지할 만큼 위험한지, 그리고 왜 비교적 간단한 해결책이 소프트웨어 개발의 일반적인 표준으로 자리 잡지 못하는 것일까요?

2021년에도 SQL 인젝션이 여전히 중요한 이유는 무엇일까요?

최근 발생한 대규모 침해 사고인 FireEye에 대한 치명적인 사이버 공격을 살펴보면 놀라울 정도로 정교함을 알 수 있습니다. 이는 FireEye를 겨냥해 맞춤 제작된 듯한 다양한 고급 기술을 활용한 국가 차원의 고도로 조직된 공격이었습니다. FireEye의 CEO 케빈 만디아는 성명을 통해 다음과 같이 밝혔습니다.

“공격자들은 자신들의 세계적 수준의 역량을 FireEye를 표적으로 삼아 공격하는 데 맞춤화했습니다. 그들은 운영 보안에 대해 고도로 훈련받았으며, 규율과 집중력을 가지고 실행에 옮겼습니다. 그들은 우리나 파트너들이 과거에 본 적 없는 새로운 기술 조합을 사용했습니다.”

이는 모든 CISO에게 악몽과도 같은 일이며, FireEye와 같은 기업조차 이런 일을 겪을 수 있다는 사실은 많은 기업이 얼마나 취약한지를 여실히 보여줍니다.

…하지만 일반적인 조직에게는 상황이 훨씬 더 나쁩니다. FireEye는 세계에서 가장 유명한 사이버 보안 기업 중 하나이며, 그들을 성공적으로 공격하기 위해서는 조직적이고 대규모의 실행력을 갖춘 천재적인 범죄자들이 모든 역량을 쏟아부어야 했습니다. 반면 많은 기업의 경우, 천재적인 범죄자가 아니더라도 간단한 버그를 빠르게 악용하는 것만으로도 수익성 높은 데이터 침해를 일으킬 수 있습니다. SQL 인젝션은 후자의 대표적인 사례로, 다크 웹에서 돈을 벌려는 초보 해커들에 의해 여전히 악용되고 있습니다.

2020년 5월, 한 남성이 신용카드 도용 및 해킹 혐의로 기소되었습니다 당시 그는 수십만 개의 활성 신용카드 번호가 저장된 디지털 매체를 소지하고 있었습니다. 그는 SQL 인젝션 기술을 사용하여 이 모든 정보를 수집했으며, 이 과정에서 많은 기업과 수백만 명의 고객이 피해를 입었습니다.

업계 전체가 계속해서 발전하고 있지만, SQL 인젝션은 여전히 심각한 위협이며 단순히 오래되거나 패치되지 않은 시스템을 넘어 훨씬 더 많은 곳에 영향을 미치고 있습니다.

개발자들이 SQL 인젝션을 방치하는 이유 (그리고 그것이 개발자만의 잘못이 아닌 이유)

우리는 SQL 인젝션을 수정하는 것은 간단하며, 애초에 발생하지 않도록 코드를 작성해야 한다고 계속 말합니다. 하지만 대부분의 일이 그렇듯, 제대로 배우기 전까지는 쉬운 일이 없습니다.

소프트웨어 개발 과정에서 바로 이 지점이 삐걱거리기 시작합니다. 개발자들은 같은 실수를 반복하고, 이로 인해 SQL 인젝션과 같은 취약점이 코드베이스에 침투하게 됩니다. 하지만 이는 놀라운 일이 아닙니다. 대부분의 엔지니어는 학위 과정에서 보안 코딩에 대해 거의 배우지 못합니다. 직무 교육 또한 보안을 비즈니스 우선순위로 보지 않는 환경에서는 매우 불충분합니다.

우리는 개발자들에게 보안에 관심을 가져야 할 이유를 제공하지도, 보안 인식을 높일 수 있는 강력한 플랫폼을 제공하지도 않고 있습니다. 잘못된 코딩 패턴이 SQL 인젝션과 같은 버그를 유지시키고 있습니다. 우리는 개발자의 보안 인식에 더 많은 비중을 두어야 하며, 더 높은 수준의 안전하고 품질 높은 코드를 작성할 시간을 주어야 합니다. 보안 코딩 패턴을 작성하는 데는 시간이 더 걸릴 수 있지만, 그 과정에서 쏟은 시간은 나중에 프로세스 전반에서 엄청난 효율성을 창출합니다.

SQL 인젝션의 장례식을 치를 날이 올까요?

장례식이라는 비유가 다소 섬뜩할 수 있지만, SQL 인젝션이 완전히 사라진다면 우리의 민감한 데이터는 훨씬 더 안전해질 것입니다. 하지만 예방적 보안 문화와 보안 코딩에 대한 강조가 아직 관을 닫을 만큼 충분히 성숙하지 않았기 때문에, 그날이 오기 전까지 우리는 몇 번의 생일을 더 기념하게 될 것이라 확신합니다.

Rust와 같이 더 새롭고 보안성이 뛰어난 언어들은 더 안전한 함수를 활용하여 오랫동안 우리를 괴롭혀온 버그들을 근절하는 데 도움을 주고 있습니다. 하지만 여전히 방대한 양의 레거시 소프트웨어, 구형 시스템 및 라이브러리가 계속 사용되고 있으며, 이들은 잠재적인 취약점을 안고 있습니다.

개발 과정에서 보안에 대한 공동의 책임(DevSecOps를 떠올려 보세요)은 '쉬운' 공격을 영구적으로 차단하는 데 매우 중요합니다. 개발자는 초기 단계부터 이 여정에 동참해야 하며, 더 안전하고 우수한 코드를 작성하는 데 필요한 역할을 다할 수 있도록 지원받아야 합니다.

개발자는 코드 내 SQL 인젝션 버그를 어떻게 해결해야 할까요?

저희는 포괄적인 가이드를 마련했습니다. 이 가이드는 SQL 인젝션을 식별하고 수정하는 방법을 배우고자 하는 개발자를 위한 것입니다. 원하는 프로그래밍 언어(COBOL까지 포함!)로 즐길 수 있는 게임화된 챌린지가 포함되어 있어, 모든 개발자가 더 안전하고 높은 품질의 코드를 작성하는 데 필요한 기초 지식을 탄탄하게 다질 수 있습니다.