변경 로그: OWASP 상위 10개 프로젝트

게시 됨: 2022-03-11

웹 애플리케이션은 지난 10년 동안 복잡성이 폭발적으로 증가했습니다. 그들은 연락처 양식 및 투표를 위한 단순한 컨테이너에서 본격적인 응용 프로그램으로 발전했습니다. 크기와 성능 면에서 무거운 데스크톱 응용 프로그램과 비교할 수 있습니다. 복잡성이 급격히 증가하고 기능이 풍부한 응용 프로그램의 수가 증가함에 따라 모든 응용 프로그램 구성 요소를 가능한 한 안전하게 만드는 데 많은 시간과 주의를 투자하는 것이 필수가 되었습니다. 인터넷 사용자의 엄청난 증가로 인해 데이터 및 응용 프로그램 사용자를 보호하는 문제를 해결하는 것이 더욱 중요해졌습니다. 침투하여 관련된 모든 사람에게 심각한 골칫거리를 야기하려는 방대한 위협 풀이 있습니다.

2001년에는 새로운 조직이 무대에 올랐다. 그 목표는 웹사이트와 애플리케이션에 영향을 미치는 보안 문제를 해결하는 것이었습니다. OWASP(Open Web Application Security Project)라는 적절한 이름이 붙었습니다. 요즘에는 리소스를 게시하고, 회의를 조직하고, 웹 및 애플리케이션 보안에 대한 표준을 제안합니다. 웹 애플리케이션 보안에 대한 사실상의 표준은 OWASP Top Ten Project입니다. 가장 널리 퍼진 10가지 보안 위협을 나열합니다. 무엇을 입력할지 결정하는 데 영향을 미친 요인은 방대한 양의 데이터와 커뮤니티 피드백이었습니다. 2017년 말에 프로젝트 업데이트가 있었습니다. 많은 최신 웹 응용 프로그램에 중요한 몇 가지 새로운 문제가 그 자리를 차지했지만 일부는 목록에서 벗어났습니다.

이 문서는 원래 목록을 보완하고 목록의 최신 변경 사항을 보여줍니다. 위협에 대해 설명하고 더 쉽게 이해할 수 있도록 명확한 예를 제공하며 보안 위협에 대처하는 방법을 제안합니다.

OWASP 상위 10개 목록에서 제거된 문제

2017년 업데이트 이전에는 2013년 목록이 가장 최근 목록이었습니다. 웹 애플리케이션이 구축되고 소비되는 방식의 변화를 고려할 때 철저한 개정을 하는 것이 합리적이었습니다. 마이크로서비스가 파이의 일부를 차지하고 있으며 새롭고 멋진 프레임워크가 바닐라 코드 전투 장비를 대체하고 있습니다. 이러한 사실은 이전에 나열된 위협 중 일부가 제거되고 일부 새로운 위협이 그 자리를 차지했음을 의미합니다.

우리는 이 기사에서 오랫동안 잊혀진 문제에 대한 기억을 새로고침하고 새로운 나쁜 늑대를 소개할 것입니다. 역사에 대해 배우는 것은 같은 실수를 반복하지 않는 유일한 확실한 방법입니다.

사이트 간 요청 위조

CSRF(교차 사이트 요청 위조)는 최근 프로젝트 반복에서 "패자" 중 하나입니다. 많은 현대 웹 프레임워크에 CSRF 방어 메커니즘이 포함되어 있기 때문에 사라졌습니다. 따라서 애플리케이션이 위협에 노출될 확률이 급격히 감소합니다.

CSRF가 목록을 종료하는 것과 관계없이 여전히 메모리를 새로 고치는 것이 좋습니다. 그 어느 때보다 강해지지 않도록 합시다.

본질적으로 CSRF는 연막탄을 느끼는 익스플로잇입니다. 공격자는 순진한 사용자가 웹 응용 프로그램 내에서 원치 않는 요청이나 작업을 실행하도록 속입니다. 간단히 말해서, 공격자는 피해자가 제3자 애플리케이션에 요청을 보내도록 강제하고 피해자는 요청이 전송된 사실을 알지 못합니다. 요청은 리소스를 검색하기 위한 HTTP GET 요청일 수 있으며, 더 나쁜 것은 피해자의 제어 하에 리소스를 변경하는 HTTP POST 요청일 수 있습니다. 공격하는 동안 피해자는 모든 것이 괜찮다고 생각하며, 대부분 백그라운드에서 어떤 일이 일어나고 있다는 사실조차 알지 못합니다. 공기가 맑아지면 피해가 발생하거나 무언가가 빠져 있으며 아무도 무슨 일이 일어 났는지 모릅니다.

대상 응용 프로그램 내에서 성공적인 이전 사용자 인증은 트랩이 유효하도록 하는 것입니다. 사용자는 공격이 시작되기 전 어느 시점에서 애플리케이션에 로그인했습니다. 애플리케이션은 피해자에게 그들을 기억하기 위해 쿠키를 보냈습니다. 웹 브라우저가 악성 요청을 보내면 쿠키가 잠재적 페이로드와 함께 자동으로 전송되고 애플리케이션은 이미 알고 있는 사용자에게 요청을 제공하는 것을 거부하지 않습니다.

가장 유명한 예 중 하나는 사용자가 자신의 계정에서 공격자가 제어하는 ​​계정으로 돈을 이체하도록 속이는 것입니다. 사용자가 전자 뱅킹 시스템에 로그인하여 계정 잔액을 확인합니다. 그 후 온라인 포럼을 방문하여 새 휴대전화의 리뷰를 확인합니다. 다이너마이트로 낚시를 하는 공격자가 이미지 하이퍼링크가 깨진 것처럼 보이는 이미지가 포함된 리뷰를 게시합니다. 실제 하이퍼링크 대신 공격자는 전자 뱅킹 시스템이 내부적으로 사용하는 하이퍼링크를 사용하여 계정 A에서 계정 B로 돈을 이체합니다. https://payments.dummybank.com?receiver=attacker&amount=100 . 은행 시스템은 인증된 사용자를 송금인으로 만들고 "수취인" 매개변수의 값을 자금을 받는 사람으로 만듭니다. 물론 공격자는 해외 계정을 수신자로 지정합니다.

브라우저는 페이지를 렌더링할 때 이미지를 자동으로 로드하므로 요청은 백그라운드에서 발생합니다. 은행의 지불 시스템이 HTTP GET 요청을 사용하여 송금을 구현하면 재앙이 일어나는 것을 막을 수 없습니다. 예제는 간단하며 HTTP GET을 통해 전송이 처리되지 않을 가능성이 큽니다. 그러나 공격자는 포럼의 HTML 메시지 게시 양식에서 "action" 속성을 약간만 더 쉽게 변경할 수 있습니다. 그런 다음 브라우저는 포럼의 백엔드 대신 은행의 지불 시스템으로 요청을 보냅니다.

돈을 훔치는 것은 세상에 나온 많은 예 중 하나일 뿐입니다. 사용자의 이메일 주소를 변경하거나 의도하지 않은 구매도 이 범주에 속합니다. 종종 발생하는 것처럼 사회 공학 및 일부 기술 지식은 소프트웨어 공학 실수에 대한 효과적인 레버리지입니다.

시스템을 설계할 때 다음 사항에 유의하십시오.

  • 리소스를 수정하는 작업을 캡슐화하기 위해 HTTP GET 요청을 사용 하지 마십시오 . 이러한 요청은 정보 검색에만 사용해야 합니다. 경험 법칙은 GET 요청을 멱등원으로 만드는 것입니다.
  • Do , HTTP POST 요청을 사용하여 내부적으로 데이터를 전송할 때 매개변수를 쿼리 문자열로 인코딩하는 것 외에 JSON, XML 또는 다른 형식으로 데이터를 보내는 경향이 있습니다. 중요하지 않은 데이터 형식을 사용하면 누군가가 데이터를 서비스로 보낼 가짜 HTML 양식을 만들 위험이 줄어듭니다.
  • HTML 양식에 고유하고 예측할 수 없는 토큰을 만들어 포함 해야 합니다. 이러한 토큰은 또한 각 요청에 대해 고유해야 합니다. 이러한 토큰의 존재와 정확성을 확인하면 위협이 발생할 위험이 낮아집니다. 토큰을 찾아 가짜 요청에 사용하려면 공격자가 시스템에 액세스하여 토큰을 직접 가져와야 합니다. 토큰은 일회성이므로 악성 코드에서 재사용할 수 없습니다.

이 취약점은 XSS(교차 사이트 스크립팅)와 결합될 때 더 나쁜 영향을 미칩니다. 공격자가 즐겨찾는 웹사이트나 애플리케이션에 악성 코드를 삽입할 수 있다면 공격 범위는 훨씬 더 심각해지고 위험해집니다. 더욱 중요한 것은 공격자가 XSS 공격이 가능한 경우 CSRF에 대한 일부 보호 메커니즘을 우회할 수 있다는 것입니다.

CSRF는 사라지지 않았으며 예전만큼 흔하지 않다는 것을 명심하십시오.

실행 중인 CSRF 다이어그램 — OWASP 상위 10개에서 제거됨

검증되지 않은 리디렉션 및 전달

많은 응용 프로그램은 작업을 마친 후 사용자를 동일한 응용 프로그램의 다른 부분 또는 다른 응용 프로그램으로 리디렉션하거나 전달합니다. 예를 들어, 애플리케이션에 성공적으로 로그인하면 홈 페이지 또는 사용자가 처음 방문한 페이지로 리디렉션됩니다. 매우 자주 대상은 양식의 작업 또는 링크 주소의 일부입니다. 리디렉션 또는 전달을 처리하는 구성 요소가 대상 주소가 실제로 응용 프로그램에서 생성한 주소인지 확인하지 않으면 잠재적인 위협이 발생합니다. 이것은 "검증되지 않은 리디렉션 및 전달"이라는 보안 취약점입니다.

검증되지 않은 리디렉션 및 전달이 위험한 것으로 간주되는 두 가지 주요 이유는 피싱과 자격 증명 도용입니다. 공격자는 리디렉션/전달 대상 위치를 변경하고 사용자를 원래 애플리케이션과 거의 구별할 수 없는 악성 애플리케이션으로 보낼 수 있습니다. 순진한 사용자가 자신의 자격 증명과 기밀 정보를 악의적인 제3자에게 공개합니다. 무슨 일이 일어났는지 깨닫기도 전에 이미 늦었습니다.

예를 들어 웹 애플리케이션은 마지막으로 방문한 페이지로의 리디렉션을 지원하는 로그인을 구현하는 경우가 많습니다. 이를 쉽게 수행할 수 있도록 HTML 양식의 action 속성은 http://myapp.example.com/signin?url=http://myapp.example.com/puppies 와 같이 보일 수 있습니다. 당신은 강아지의 열렬한 팬이므로 웹사이트 파비콘을 좋아하는 강아지의 썸네일로 대체하는 브라우저 확장 프로그램을 설치하는 것이 합리적입니다. 불행히도, 그것은 개를 먹는 개 세계입니다. 브라우저 확장 프로그램의 작성자는 귀하의 무조건적인 사랑에 보답하고 추가 "기능"을 도입하기로 결정했습니다. 좋아하는 강아지 팬 사이트를 방문할 때마다 양식의 action 속성에 있는 "url" 매개변수가 자신의 사이트에 대한 링크로 바뀝니다. 사이트가 완전히 똑같아 보이기 때문에 강아지 카드 놀이를 사기 위해 신용 카드 정보를 제공하면 실제로 취미가 아니라 악의적인 공격자에게 자금을 조달하는 것입니다.

취약점을 해결하려면 대상 위치가 의도한 위치인지 확인하여 대상 위치를 확인해야 합니다. 프레임워크 또는 라이브러리가 전체 리디렉션 또는 전달 논리를 수행하는 경우 구현을 확인하고 필요한 경우 코드를 업데이트하는 것이 좋습니다. 그렇지 않으면 공격으로부터 보호하기 위해 수동 검사를 수행해야 합니다.

몇 가지 유형의 검사를 수행할 수 있습니다. 최상의 보호를 위해 한 가지 방법을 고수하는 대신 여러 가지 방법을 조합하여 사용하십시오.

  • 제어하는 도메인을 가리키는지 확인하는 발신 URL의 유효성을 검사하십시오.
  • 명시적 주소를 사용하는 대신 프런트 엔드에서 인코딩한 다음 백 엔드에서 디코딩하고 유효성을 검사합니다.
  • 신뢰할 수 있는 URL의 허용 목록을 준비합니다. 허용 목록에 있는 위치로만 전달 및 리디렉션을 허용합니다. 블랙리스트를 유지 관리하는 데 이 접근 방식을 선호합니다. 블랙리스트는 일반적으로 나쁜 일이 발생할 때만 새 항목으로 채워집니다. 화이트리스트는 더 제한적입니다.
  • LinkedIn 및 일부 다른 애플리케이션에서 사용하는 접근 방식 사용: 리디렉션/전달 확인을 요청하는 페이지를 사용자에게 표시하여 애플리케이션을 떠나고 있음을 분명히 합니다.

병합된 문제

목록에 있는 대부분의 문제는 지식이 부족하거나 잠재적 위협에 대한 심층 조사가 불충분하여 구현의 결함으로 분류될 수 있습니다. 이 두 가지 이유는 모두 경험 부족에 기인할 수 있으며 미래에 고려하기 위한 솔루션은 쉽기 때문에 더 많이 배우고 더 철저하게 해야 합니다. 특히 까다로운 것은 복잡한 컴퓨터 시스템을 개발하고 유지 관리하는 어려움과 함께 너무 많은 가정을 하는 위험한(그러나 매우 인간적인) 특성의 조합에 의존합니다. 이 범주에 해당하는 취약점은 "깨진 액세스 제어"입니다.

손상된 액세스 제어

취약점은 애플리케이션의 특정 부분에 대한 권한 부여 및 액세스 제어가 부적절하거나 완전히 부족하여 발생합니다. OWASP Top Ten Project의 이전 반복에서는 두 가지 문제가 있었습니다. 안전하지 않은 직접 개체 참조와 기능 수준 액세스 제어 누락입니다. 이제 유사성으로 인해 하나로 병합됩니다.

직접 개체 참조

직접 개체 참조는 작업 중인 리소스를 식별하기 위해 URL에서 자주 사용됩니다. 예를 들어 사용자가 로그인할 때 프로필 식별자가 포함된 링크를 클릭하여 프로필을 방문할 수 있습니다. 동일한 식별자가 데이터베이스에 저장되고 프로필 정보를 검색하는 데 사용되며 애플리케이션이 사람들이 로그인 페이지를 통해서만 프로필 페이지에 액세스할 수 있다고 가정하는 경우 URL의 프로필 식별자를 변경하면 다른 사용자의 프로필 정보가 노출됩니다.

프로필 삭제 양식의 URL을 설정하는 애플리케이션 http://myapp.example.com/users/15/delete 는 애플리케이션 내에 14명 이상의 다른 사용자가 있음을 분명히 합니다. 다른 사용자의 삭제 형식에 도달하는 방법을 알아내는 것은 이 경우 로켓 과학이 아닙니다.

이 문제에 대한 해결책은 특정 경로만 애플리케이션의 일부에 도달할 수 있다고 가정하지 않고 각 리소스에 대한 권한 부여 검사를 수행하는 것입니다. 또한 직접 참조를 제거하고 간접 참조를 사용하는 것은 악의적인 사용자가 참조가 생성되는 방법을 파악하기 어렵게 만들기 때문에 또 다른 단계입니다.

개발 중에 예방책으로 간단한 상태 기계 다이어그램을 작성하십시오. 상태가 애플리케이션 내의 다른 페이지를 나타내도록 하고 사용자가 취할 수 있는 작업을 전환합니다. 이렇게 하면 특별한 주의가 필요한 모든 전환과 페이지를 더 쉽게 나열할 수 있습니다.

상태 머신 다이어그램의 그림

기능 수준 액세스 제어 누락

누락된 기능 수준 액세스 제어는 안전하지 않은 직접 개체 참조와 매우 유사합니다. 이 경우 사용자는 URL 또는 기타 매개변수를 수정하여 애플리케이션의 보호된 부분에 액세스하려고 합니다. 액세스 수준을 검사하는 적절한 액세스 제어가 없는 경우 사용자는 응용 프로그램 리소스에 대한 권한 있는 액세스 권한을 얻거나 해당 리소스의 존재에 대한 최소한의 지식을 얻을 수 있습니다.

직접 개체 참조에 대한 예에서 차용하여, 수퍼유저가 추가 권한 부여 없이 삭제 양식에 대한 링크를 볼 수 있기 때문에 삭제 양식을 방문하는 사용자가 수퍼유저라고 가정하면 큰 보안 결함이 발생합니다. 일부 UI 요소의 가용성에 의존하는 것은 적절한 액세스 제어가 아닙니다.

문제는 항상 애플리케이션의 모든 계층에서 확인을 수행하여 해결됩니다. 프런트 엔드 인터페이스는 악의적인 사용자가 도메인 계층에 액세스할 수 있는 유일한 방법이 아닐 수 있습니다. 또한 액세스 수준에 대해 사용자가 전달한 정보에 의존하지 마십시오. 적절한 세션 제어를 수행하고 수신된 데이터를 항상 다시 확인하십시오. 요청 본문에 사용자가 관리자라고 표시되어 있다고 해서 실제로 관리자인 것은 아닙니다.

손상된 액세스 제어는 이제 파일 시스템의 잘못된 구성과 같이 애플리케이션 수준 또는 시스템 수준에서 불충분한 액세스 제어와 관련된 모든 문제를 결합합니다.

깨진 액세스 제어 다이어그램

OWASP Top 10 목록의 새로운 문제

새로운 프론트엔드 프레임워크의 출현과 새로운 소프트웨어 개발 관행의 채택으로 보안 문제는 완전히 새로운 주제로 옮겨졌습니다. 새로운 기술은 이전에 수동으로 처리했던 몇 가지 일반적인 문제도 해결했습니다. 따라서 목록을 수정하고 현대적인 경향에 맞게 조정하는 것이 유리했습니다.

XML 외부 엔터티

XML 표준은 문서의 DTD(데이터 유형 정의)의 일부인 외부 엔터티라고 하는 잘 알려지지 않은 아이디어를 제공합니다. 이를 통해 문서 작성자는 외부 엔터티에 대한 링크를 지정할 수 있으며 이 링크는 기본 문서에서 참조되고 포함될 수 있습니다. 매우 간단한 예는 다음과 같습니다.

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

구문 분석하는 동안 참조 &bar; 정의된 엔터티의 콘텐츠로 대체되어 <foo>baz</foo> 가 생성됩니다.

응용 프로그램이 외부 입력을 받아 확인 없이 XML 문서 정의에 직접 포함시키면 광범위한 데이터 유출 및 공격이 가능해집니다.

놀라운 점은 엔터티가 단순한 문자열일 필요가 없다는 것입니다. 이는 파일 시스템의 파일에 대한 참조가 될 수 있습니다. XML 파서는 지정된 파일의 내용을 기꺼이 가져와 생성된 응답에 포함시켜 잠재적으로 민감한 시스템 정보를 드러냅니다. OWASP에서 설명하는 것처럼 엔터티를 다음과 같이 정의하면 시스템 사용자에 대한 정보를 쉽게 얻을 수 있습니다.

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

이 취약점의 특히 문제가 되는 "기능"은 서비스 거부 공격을 쉽게 실행할 수 있다는 것입니다. 이를 수행하는 한 가지 쉬운 방법은 /dev/random 과 같은 끝없는 파일의 내용을 나열하는 것입니다. 다른 하나는 각각 이전 항목을 여러 번 참조하는 엔터티 시퀀스를 만드는 것입니다. 이것은 파싱이 시스템 메모리를 고갈시킬 수 있는 잠재적으로 매우 넓고 깊은 트리의 루트로 최종 참조를 바꿉니다. 이 공격은 Billion Laughs로도 알려져 있습니다. Wikipedia에 표시된 대로 일련의 더미 엔터티가 정의되어 공격자가 최종 문서에 10억 롤을 포함할 수 있는 기회를 제공합니다.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

덜 복잡한 데이터 형식을 사용하여 XML 외부 엔터티 악용을 방지할 수 있습니다. JSON에 대한 공격 가능성으로 인해 몇 가지 예방 조치가 취해지면 JSON은 좋은 대체품입니다. XML 라이브러리 업데이트는 외부 엔터티 처리 및 DTD 비활성화와 함께 필수입니다. 항상 그렇듯이 신뢰할 수 없는 출처에서 가져온 데이터를 사용하거나 문서에 포함하기 전에 유효성을 검사하고 삭제하십시오.

안전하지 않은 역직렬화

코드를 작성할 때 개발자는 작성한 코드를 사용하여 개발 중인 시스템을 제어할 수 있는 권한이 있습니다. 코드를 거의 또는 전혀 작성하지 않는 타사 시스템의 동작을 제어할 수 있다면 얼마나 좋을까요? 사람들이 완벽하지 않고 라이브러리에 결함이 있다는 사실 덕분에 이것은 확실히 가능합니다.

애플리케이션 상태 및 구성은 종종 직렬화되어 저장됩니다. 직렬화된 데이터가 현재 사용자와 밀접하게 연결된 경우 브라우저가 스토리지 엔진 역할을 하는 경우가 있습니다. 영리하고 처리 시간을 절약하려는 응용 프로그램은 쿠키를 사용하여 사용자가 로그인했음을 표시할 수 있습니다. 쿠키는 로그인이 성공한 후에만 생성될 수 있으므로 사용자 이름을 쿠키에 저장하는 것이 좋습니다. 그런 다음 쿠키의 존재와 내용을 기반으로 사용자가 인증되고 권한이 부여됩니다. 사람들이 악의가 없다면 아무 일도 일어나지 않을 것입니다. 솔직히 그들도 호기심이 없어야 합니다.

호기심 많은 사용자가 자신의 컴퓨터에서 쿠키를 찾은 경우 다음과 같은 내용을 볼 수 있습니다.

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

JSON으로 직렬화된 완벽하게 유효한 Python 사전, 특별한 것은 없습니다. 호기심이 많은 사용자는 응용 프로그램이 강제로 로그아웃되지 않도록 만료 날짜를 변경할 수 있습니다. 더 궁금한 사용자는 사용자 이름을 "jane.doe" 로 수정하려고 할 수 있습니다. 이 사용자 이름이 존재한다면 이제 개인 데이터에 액세스할 수 있는 순진한 사용자에게 완전히 새로운 세상이 열릴 것입니다.

데이터를 JSON으로 직렬화하고 모든 것을 투명하게 유지하는 간단한 예는 당신에게 일어날 수 있는 최악의 상황과는 거리가 멉니다. 공격자가 직렬화된 일부 데이터를 수정하는 경우 시스템이 임의 코드를 실행하도록 하는 방식으로 수정할 수 있습니다.

사람들이 Python으로 자신의 기계 학습 모델을 작성하고 서비스에 업로드할 수 있도록 하는 REST API를 빌드한다고 가정해 보겠습니다. 이 서비스는 업로드된 모델을 평가하고 데이터 세트를 사용하여 교육합니다. 이를 통해 사람들은 빠르고 쉬운 모델 구축을 위해 컴퓨팅 리소스와 사용 가능한 방대한 데이터 세트를 사용할 수 있습니다.

서비스는 코드를 일반 텍스트 형식으로 저장하지 않습니다. 사용자는 자신의 코드를 피클하고 개인 키를 사용하여 암호화하고 교육을 위해 API로 보냅니다. 서비스가 모델을 실행해야 하는 경우 코드를 해독하고 피클을 해제한 다음 실행합니다. 까다로운 부분은 피클 프로토콜이 안전하지 않다는 것입니다. 역직렬화 중에 임의의 악성 코드를 실행할 수 있는 방식으로 코드를 구성할 수 있습니다.

Python의 피클 프로토콜을 사용하면 클래스에서 __reduce__ 메서드를 정의할 수 있습니다. 이 메서드는 사용자 지정 개체를 역직렬화하는 방법에 대한 정보를 반환합니다. 지원되는 반환 값 중 하나는 두 개의 인수로 구성된 튜플입니다. 하나는 콜러블이고 다른 하나는 콜러블에 전달할 인수 튜플입니다. ML 모델 교육 시스템이 코드 구조의 최대 유연성을 제공하는 것을 목표로 한다는 점을 고려하면 다음 코드를 작성할 수 있습니다.

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

객체를 역직렬화(피클 해제)해야 하는 경우 하나의 인수만 사용하여 함수 list 이 호출됩니다. 함수 list 은 Python의 목록 생성자이며 itertools.count 함수는 전달된 매개변수로 시작하여 값의 무한 반복자를 생성합니다. 무한 반복자를 유한 목록으로 바꾸면 시스템의 성능과 안정성에 치명적인 결과를 초래할 수 있습니다.

이러한 유형의 취약점에 대한 유일한 진정한 치료법은 외부 소스에서 오는 데이터를 역직렬화하지 않도록 선택하는 것입니다. 이것이 불가능한 경우 악의적인 사용자에 의해 잠재적으로 수정된 데이터의 역직렬화를 방지하기 위해 체크섬 또는 디지털 서명을 사용하는 것이 좋습니다. 또한 발생할 수 있는 문제의 영향을 제한하기 위해 기본 시스템에서 분리된 샌드박스 환경을 설정하십시오.

데이터 역직렬화를 위해 외부 라이브러리(예: XML 또는 JSON)를 사용하는 경우 실제 역직렬화 절차가 실행되기 전에 개체 유형 검사를 수행할 수 있는 라이브러리를 선택하십시오. 이것은 시스템에 해를 끼치는 것이 유일한 목적인 예기치 않은 개체 유형을 포착할 수 있습니다.

애플리케이션이 수행하는 다른 모든 작업과 마찬가지로 광범위한 로깅 및 모니터링을 시행합니다. 역직렬화가 자주 발생하거나 평소보다 더 많이 실패하는 것은 나쁜 일이 일어나고 있다는 신호입니다. 문제를 조기에 파악하십시오.

불충분한 로깅 및 모니터링

애플리케이션에서 발생하는 모든 경고 및 오류를 기록하는 데 얼마나 많은 시간을 할애합니까? 코드에서 발생한 오류만 저장합니까, 아니면 유효성 검사 오류도 기록합니까? 도메인의 비즈니스 규칙이 충족되지 않으면 어떻게 됩니까? 애플리케이션에서 모든 오류 및 의심스러운 활동을 지속하지 못하면 보안 및 데이터 손상이 발생합니다.

다음 시나리오를 상상해 보십시오. 귀하의 애플리케이션에는 대부분의 로그인 페이지가 포함되어 있습니다. 이 양식에는 두 개의 필드가 있습니다. 하나는 이메일을 입력하고 다른 하나는 비밀번호를 입력하는 것입니다. 사용자가 로그인을 시도하고 잘못된 암호를 제공하면 다시 시도할 수 있습니다. 불행히도 잘못된 시도 횟수에는 제한이 없으므로 N번의 실패 시도 후에도 로그인 페이지가 잠기지 않습니다. 공격자는 이 기회를 활용할 수 있으며 하나의 올바른 이메일이 주어지면 하나의 조합이 마침내 성공할 때까지 레인보우 테이블의 비밀번호를 계속 입력할 수 있습니다. 애플리케이션이 충분히 안전하고 암호를 데이터베이스에 입력하기 전에 해시하면 이 특정 공격은 작동하지 않습니다. 그러나 침입을 식별하는 메커니즘이 있습니까?

이 한 번의 시도로 로그인 페이지를 여는 데 실패했다고 해서 다른 시도에서도 열리지 않는 것은 아닙니다. 로그인 페이지만이 잠재적인 백도어가 아닐 수도 있습니다. 다른 목적이 아닌 경우 누군가가 귀하에 대해 잘못된 액세스 제어를 사용하려고 할 수 있습니다. 완벽하게 제작된 애플리케이션이라 할지라도 누군가가 공격을 시도하고 있음을 알고 있어야 합니다. 이는 불가능할 수도 있습니다. 그래도 항상 그렇습니다.

이러한 공격으로부터 자신을 보호하기 위해 최선을 다하려면 다음 단계를 수행하십시오.

  • 코드 또는 액세스 제어, 유효성 검사 및 데이터 조작 오류에서 예외가 발생하더라도 애플리케이션에서 발생하는 모든 실패 및 경고를 기록합니다. 저장된 모든 정보는 소급 검사 및 분석이 가능하도록 충분히 오랫동안 복제 및 유지되어야 합니다.
  • 형식 및 지속성 계층을 결정하는 것이 중요합니다. 임의의 텍스트 형식으로 된 거대한 파일을 갖는 것은 쉽게 달성할 수 있습니다. 나중에 처리하지 않습니다. 데이터를 쉽게 저장하고 읽을 수 있는 스토리지 옵션과 쉽고 빠른 (역)직렬화를 허용하는 형식을 선택하십시오. 빠른 액세스가 가능한 데이터베이스에 JSON을 저장하면 사용이 간편해집니다. 정기적으로 백업하여 데이터베이스를 작게 유지하십시오.
  • 중요하고 가치 있는 데이터를 다루는 경우 최종 상태를 감사하기 위해 따를 수 있는 조치를 추적하십시오. 데이터 변조를 방지하기 위한 메커니즘을 구현합니다.
  • 백그라운드 시스템이 로그를 분석하고 문제가 발생하면 알려줍니다. 사용자가 애플리케이션의 보호된 부분에 반복적으로 액세스를 시도하는 경우 테스트만큼 간단한 검사가 도움이 됩니다. 그러나 더미 검사로 시스템에 과부하를 주지 마십시오. 모니터링 시스템은 별도의 서비스로 실행되어야 하며 주 시스템의 성능에 영향을 미치지 않아야 합니다.

문제 해결 시 오류 로그가 외부 사용자에게 누출되지 않도록 각별히 주의하십시오. 그렇게 하지 않으면 민감한 정보에 노출되기 쉽습니다. 공격자가 작업을 보다 효율적으로 수행하는 것이 아니라 로깅 및 모니터링이 문제 해결에 도움이 되어야 합니다.

로깅 및 모니터링 다이어그램

다음 단계

웹 애플리케이션의 잠재적인 위협과 취약성을 인식하는 것이 중요합니다. 애플리케이션에서 식별을 시작하고 패치를 적용하여 제거하는 것이 훨씬 더 중요합니다.

애플리케이션 보안에 대한 관심은 소프트웨어 개발 프로젝트의 모든 단계에서 중요한 부분입니다. 소프트웨어 설계자, 개발자 및 테스터는 모두 소프트웨어 테스트 절차를 워크플로에 통합해야 합니다. 보안 위험을 줄이기 위해 소프트웨어 개발 프로세스의 적절한 단계에 보안 체크리스트와 자동화된 테스트를 활용하는 것이 좋습니다.

기존 애플리케이션을 분석하든 새로운 애플리케이션을 개발하든 OWASP ASVS(Application Security Verification Standard Project)를 살펴봐야 합니다. 프로젝트의 목표는 애플리케이션 보안 검증을 위한 표준을 개발하는 것입니다. 이 표준은 보안 웹 애플리케이션 개발을 위한 테스트 및 요구 사항을 열거합니다. 테스트에는 1에서 3까지의 수준이 지정되며, 여기서 1은 가장 적은 위험 수준을 의미하고 3은 가장 높은 잠재적 위협을 의미합니다. 분류를 통해 응용 프로그램 관리자는 어떤 위협이 더 가능성 있고 중요한지 결정할 수 있습니다. 각 애플리케이션에 각 테스트를 포함할 필요는 없습니다.

신규 및 기존 웹 애플리케이션 프로젝트, 특히 애자일 원칙을 따르는 프로젝트 모두 애플리케이션 보안을 위한 구조화된 계획 계획의 이점을 얻습니다. OWASP Security Knowledge Framework를 사용하기로 결정하면 OWASP ASVS 테스트 계획이 더 쉽습니다. 일반적인 보안 문제를 해결하는 방법에 대한 일련의 예와 OWASP ASVS를 기반으로 하는 따르기 쉬운 체크리스트와 함께 제공되는 보안 테스트 지향 스프린트를 관리하기 위한 애플리케이션입니다.

웹 애플리케이션 보안 탐색을 막 시작했고 안전한 샌드박스 플레이그라운드가 필요하다면 OWASP의 웹 애플리케이션 구현인 WebGoat를 사용하십시오. 웹 애플리케이션의 의도적으로 안전하지 않은 구현입니다. 응용 프로그램은 하나의 보안 위협에 집중된 각 수업을 통해 수업을 안내합니다.

애플리케이션 개발 중에 다음을 확인하십시오.

  • 위협을 식별하고 우선 순위를 지정합니다. 실제로 발생하고 애플리케이션에 위험을 초래할 수 있는 위협을 정의합니다. 위협의 우선 순위를 지정하고 가장 개발 및 테스트 노력을 기울일 가치가 있는 위협을 결정하십시오. 정적인 블로그를 운영한다면 부족한 로깅과 모니터링을 해결하기 위해 많은 노력을 기울일 필요가 없습니다.
  • 애플리케이션의 아키텍처와 디자인을 평가합니다. 일부 취약점은 애플리케이션 개발의 후반 단계에서 해결하기가 매우 어렵습니다. 예를 들어, 타사 코드를 실행하려고 하고 샌드박스 환경을 사용할 계획이 없다면 불안정한 역직렬화 및 주입 공격으로부터 방어하기가 매우 어려울 것입니다.
  • 소프트웨어 개발 프로세스를 업데이트합니다. 웹 애플리케이션 위협에 대한 테스트는 가능한 한 자동화된 프로세스여야 합니다. 보안 허점을 찾으려는 자동화된 테스트로 CI/CD 워크플로를 보강하는 것이 좋습니다. 기존 단위 테스트 시스템을 활용하여 보안 테스트를 개발하고 주기적으로 실행할 수도 있습니다.
  • 배우고 개선하십시오. 문제 및 취약점 목록은 고정되어 있지 않으며 확실히 10개 또는 15개의 위협으로 제한되지 않습니다. 새로운 기능과 아이디어는 새로운 유형의 공격을 가능하게 합니다. 최신 정보를 유지하려면 웹 애플리케이션 보안 세계의 현재 동향을 읽는 것이 중요합니다. 배운 것을 적용하십시오. 그렇지 않으면 시간을 낭비하고 있습니다.

결론

이름에서 알 수 있듯이 OWASP Top 10 프로젝트에는 10개의 보안 취약점만 나열되어 있지만 애플리케이션, 가장 중요한 것은 사용자와 해당 데이터를 위협하는 수천 가지의 가능한 트랩과 백도어가 있습니다. 기술의 변화와 개선에는 장점과 단점이 모두 있기 때문에 경계를 늦추지 않고 지속적으로 지식을 새로 고칩니다.

아, 그리고 잊지 마세요. 세상은 흑백이 아닙니다. 보안 취약점은 혼자 오지 않습니다. 그들은 종종 얽혀 있습니다. 하나에 노출된다는 것은 종종 다른 무리가 모퉁이를 돌면서 못생긴 머리를 뒤로 젖히기를 기다리고 있다는 것을 의미하며 언젠가는 그것이 당신의 잘못이 아니더라도 시스템 보안 개발자로서 여전히 허점을 패치하여 억제해야 합니다. 사이버 범죄. 예를 들어 해킹된 신용 카드 번호는 여전히 Google에서 사용할 수 있음 을 참조하십시오.