OWASP Top10은 OWASP 보안에 대해 오랫동안 알고 있었다면 의심의 여지는 없었을 것입니다.
OWASP Top 10은 2010년에 시작되어 2013년과 2017년에 업데이트 되었습니다.
오늘날 어플리케이션 개발자와 웹 어플리케이션 보안 전문가들이 알아야 할 가장 일반적인 취약성 타입의 실제 표준 목록으로 널리 알려져 있습니다.
사실 그것은 아주 표준이 되고 현재는 API와 IOT를 구체적으로 다루는 OWASP Top10 목록이 있습니다.
이 정기 블로그 시리즈에서는 OWASPTOP10의 가장 보편적인 취약성에 대해 살펴보겠습니다.
이 기사에서는 OWASP TOP10의 취약성의 가장 일반적인 유형인 SQL 인젝션(SQL Injection)에 대해 살펴보겠습니다.
또 효과적인 애플리케이션 보안 프로그램을 통해서 이런 위협을 해결할 수 있는 방법도 검토해 나가겠습니다.
SQL Injection Defined OWASP에 따르면 “SQL, NoSQL, OS 및 LDAP 인젝션 결함은 신뢰할 수 없는 데이터가 명령어 또는 쿼리의 일부로서 인터프리터로 전송될 때 발생합니다.
공격자의 적대적 데이터는 통역자를 속여 의도하지 않은 명령을 실행하거나 적절한 권한 없이 데이터에 접근할 수 있게 합니다.
” 인젝션은 실제로 데이터의 흐름을 이용하여 의도하지 않은 작업을 하는 것입니다.
우리가 잘 들은 예의 하나는 Web페이지의 필드에 작은 따옴표를 사용하고 SQL쿼리를 이용하려는 것과 같은 것입니다.
SQL Injection’s Impact 최근의 Ponemon Institute “Application Security in the DevOps Environment” 연구에서 응답 기업의 비즈니스 치명타 애플리케이션의 67%가 취약성을 지속적으로 테스트하지 않는 것으로 나타났습니다.
따라서 SQL 인젝션과 같은 취약성의 잠재적인 영향은 매우 큽니다.
이와 같이 저자인 PallaviDutta의 최근 SecurityBoulevard.com 기사는 주요 SQL 인젝션 공격이 영국의 통신 회사, 수많은 대학, 정부기관, 심지어 전자상거래 회사와 같은 광범위한 산업 조직에 영향을 미쳤다고 밝히고 있습니다.
But Why IS SQL Injection Still A Thing?? 실제로는 SQL 인젝션이 말 그대로 수십 년간 공개 논의되어 왔음에도, 왜 아직도 이 문제가 많은 조직에 문제가 되는 것일까요? 현실적으로 SQL 인젝션을 막는 것은 그리 어렵지 않지만 소프트웨어가 데이터베이스와 통신하고 사용자가 제공한 입력을 사용해 이를 실행하는 장소의 수가 엄청납니다.
“Application Paranoia” 팟캐스트 시리즈의 시즌 1 에피소드 10에서 애플리케이션 보안 전문가나 인플루언서 Tanya Janca에게 다시는 누구도 작성해서는 안 되는 취약점에 대해 질문했을 때, 이 문제의 중요성을 깨달았습니다.
타냐는 이렇게 말했어요.
좋아요. 그래서 제가 제일 좋아하는 약점을 고치려고 해요. 저는 이 질문을 머릿속으로 돌려보겠습니다.
저는 사람들이 완전히 검증되고 제대로 검증된 프로그램에만 입력 정보를 쓰도록 합니다.
모든 프로그래머가 입력검증을 원래 위치에 두고 입력검증을 잘 수행하면 이렇게 방대한 양의 취약성을 해결할 수 있기 때문입니다.
”Addressing Injection Attacks HCL AppScan은 잠재적인 영향을 고려한 경우 인젝션을 찾아 어떻게 해결합니까?” 애플리케이션 검색 시 가능한 모든 종류의 구성을 시도하고 인젝션 공격이 가능하다는 것을 보여주는 항목을 찾아 출력을 검사합니다.
예를 들어, 어떤 종류의 에러 메시지가 표시되는지, 이러한 메시지가 애플리케이션 동작 방법에 대한 통찰력을 제공하고 있는지 확인합니다.
우리는 양성 인젝션을 통해 이들이 “작동”하는지 확인하고, 개발팀이 그들의 존재를 인식할 수 있도록 그러한 시도의 성공을 보고합니다.
우리는 발견된 취약성의 종류와 이해를 높이는 것이 왜 문제인지에 대한 정보를 제공합니다.
.png?type=w800 "가정폭력 고소 이혼 소송의 필요 절차는")
Figure1: AppScan Scan Configuration Panel 이곳에서 사용자는 테스트할 문제의 종류를 정확하게 사용자 정의할 수 있습니다.
이 예시는 개발자가 잠재적인 문제에 대한 신속한 피드백을 얻을 수 있도록 성공 확률이 높은 일반적인 테스트로 구성된 ‘개발자 필수 사항’ 프로파일을 선택하는 것에서 시작되었습니다.
다음으로 선택되지 않았을 수도 있는 다른 관련 테스트를 찾아서 포함할 수 있도록 “Injection” 이라는 단어를 검색했습니다.
이러한 유연성으로 인해 우리는 테스트를 연마할 수 있습니다.
일단 인젝션의 문제가 발견이 되면, 이 문제를 어떻게 해결해야 할까요. Application Paranoia 팟캐스트 시리즈 시즌1 에피소드 9에서 크리스에게 물어보세요 코너에서 크리스 듀어는 엄청난 통찰력을 제공했다.
다음은 그의 강력한 조언입니다.
모범사례 1: 준비된 진술을 사용하세요. 쿼리 실행 중지…쿼리 실행이나 명령문 실행을 볼 때마다 내 영혼 일부가 죽습니다.
매개변수가 없어도 괜찮습니다.
항상 준비된 진술을 사용하세요. 언제나 준비된 쿼리를 사용하세요. 말 그대로 문자열을 연결하는 쿼리 작성을 중지하는 것입니다.
이는 SQL 주입 문제의 99.9%입니다.
동적 SQL 사용을 중지하고 동적이어야 할 경우 준비된 문을 사용합니다.
”
요약하면 일단 취약성을 식별한 경우입니다.
이러한 문제를 해결하는 방법은 보통 다음 두 가지 범주 중 하나입니다.
사용자제공입력을 활용한 동적 쿼리의 작성을 제거합니다.
사용자제공입력을 사용할 경우 “불량(bad)” SQL이 나머지 쿼리에 영향을 미치지 않도록 합니다.
이러한 두 가지 카테고리를 해결하기 위해서는 매개변수화된 쿼리, 저장 프로시저, 허용 가능한 입력 목록의 정의, 사용자 제공의 입력이탈 등이 포함됩니다.
그림 2와 같이 HCL AppScan은 발견된 취약성에 관한 특정 정보를 제공하고 그 전략을 잠재적인 교정 제안에 이용합니다.
또한 OWASP는 이러한 다양한 방법을 예시하는 훌륭한 자원을 제공합니다.
Figure 2 : Vulnerability and r emediation information
잠재적인 SQL 인젝션 공격을 지원하는 가장 좋은 방법은 효과적인 Application Security Testing 프로그램을 사용하는 것입니다.
HCL AppScan의 Application Security를 직접 테스트해 보기 위해서는 데모를 신청하거나 평가판을 체험해 보십시오.HCL AppScan에 대한 문의는 소프트와이드 보안으로 부탁드립니다.
