비즈니스 응용 프로그램을 빌드할 때 고객의 내부 사용이든 외부사용이든 모든 사용자가 모든 단일 기능을 수행하지 못하게 할 수 있습니다. 이렇게 하면 액세스 제어가 끊어질 수 있습니다.

액세스 제어가 깨진 것, 왜 그렇게 위험한지, 그리고 이를 해결하는 방법을 살펴보겠습니다.

깨진 액세스 제어 이해

응용 프로그램 코드에 적절한 보안 또는 액세스 검사가 없는 경우 액세스 제어가 끊어지면 발생합니다. 또한 응용 프로그램이 어떤 식으로든 잘못 구성되어 사용자가 액세스하지 않아야 하는 함수 또는 페이지에 액세스할 수 있는 경우에도 발생할 수 있습니다.

회사의 재정을 처리하는 경우 특정 계좌에 돈을 입금하거나 회사의 계좌 간에 송금할 수 있습니다. 그러나 해당 계정에서 현금을 인출하거나 다른 계좌로 송금할 수 없습니다. 적절한 액세스 검사가 없는 경우 직원이 필요 이상으로 더 많은 기능을 수행할 수 있습니다.

이러한 검사는 코드 내에서 또는 구성 파일에서 수행할 수 있습니다. 예를 들어 웹 응용 프로그램 프레임워크에 사용자가 어떤 페이지에 액세스할 수 있는지 알려주는 XML 구성 파일이 있을 수 있습니다. 이렇게 하면 사용자가 사용할 권한이 있는 함수에만 액세스할 수 있습니다.

깨진 액세스 제어가 위험한 이유

이 예제를 고려: 공격자가 사용자 계정 생성 코드를 조작할 수 있다는 것을 깨달았기 때문에 공격자가 간단한 게시물 요청으로 관리자 사용자를 만들 수 있습니다. 사용자 이름과 암호로 요청을 보낸 다음 URL에 관리자 역할을 매개 변수로 또는 요청 본문에 포함하도록 요청을 변경할 수 있습니다. 공격자는 응용 프로그램에 로그인하고 즉시 관리자 권한이 부여됩니다.

항상 시스템을 관통하는 악의적인 공격자가 될 필요는 없습니다. 적절한 액세스 제어가 없으면 부서 간에 공유해서는 안 되는 중요한 정보가 유출될 수 있습니다. 회사의 직원이 HR 급여 데이터 또는 재무 데이터를 볼 수 있다고 가정해 보십시오. 회사의 열악한 재정 상황으로 인해 해고가 오는 것을 볼 수 있다면 어떻게 될까요? 이것은 당신의 사기와 회사의 명성에 손상을 줄 수 있습니다.

고객의 민감한 정보도 손실될 수 있습니다. 회사는 종종 서비스를 사용하는 고객의 개인 정보를 저장합니다. 액세스 제어가 부족하여 실수로 노출하지 않도록 주의하십시오. 예를 들어, 시스템이 사용자에게 자신의 상태 기록을 요청할 수 있는 기능을 제공하는 경우 다른 사람의 건강 정보를 요청하고 볼 수 있습니까? URL에 고객 ID 번호가 포함된 경우 공격자는 다른 고객과 일치하는 ID를 찾을 때까지 고객 ID 번호를 반복해서 증분하여 개인 데이터를 공개할 수 있습니다.

깨진 액세스 제어 패배

역할 기반 액세스 제어(RBAC)는 사운드 액세스 제어를 구현하는 데 매우 효과적인 도구입니다. Active Directory를 사용하는 사람들은 그룹을 만들고 개인대신 그룹 전체의 특정 항목에 대한 액세스 권한을 부여하는 아이디어에 익숙할 수 있습니다. 응용 프로그램은 역할을 사용하여 누가 무엇을 볼 수 있는지 정의하는 것과 동일한 방식으로 작동합니다.

이것은 두 가지 장점이 있습니다. 첫째, 누군가가 관리자 역할을 떠날 때 함수를 변경할 필요가 없습니다. 이전에 관리자였던 사람이더 이상 없어야 하는 경우 새 사람을 관리자 역할에 배치하고 이전 사람을 역할에서 제거하기만 하면 됩니다. 코드는 각 개별 사용자가 특정 페이지 또는 기능에 액세스할 수 있는지 확인하는 대신 사용자가 관리자 역할이 있는지 확인합니다.

두 번째 이점은 유지 보수 악몽을 피하는 것입니다. 모든 사람이 가능한 모든 함수 또는 페이지와 연관이 있을 정도로 세분화된 액세스 제어는 시간이 지남에 따라 관리할 수 없습니다. 역할은 여러 사람을 역할에 추가할 수 있기 때문에 훨씬 쉽게 만듭니다. 한 가지 역할은 회사 전체를 포함할 수 있으며 다른 역할은 5명만 있을 수 있습니다. 이렇게 하면 관리할 역할이 줄어들기 때문에 역할 관리가 더욱 효율적입니다. 10,000명의 기업이 응용 프로그램의 함수 수의 10,000배 대신 100개의 역할만 가질 수 있습니다. 선택한 응용 프로그램 프레임워크를 조사하여 강력한 액세스 제어를 위해 어떤 옵션이 있는지 확인합니다.

기능 수준 액세스 제어를 사용하는 것도 중요합니다. 사용자가 특정 액세스 제어 검사를 통과하도록 요구하여 모든 기능에 대한 액세스를 보호합니다. 최소한 권한 원칙을 사용하여 기본적으로 액세스를 거부하고 필요에 따라 액세스를 열수 있습니다. 각 함수에 대한 액세스 제어를 구현하는 것을 기억하기 어려울 수 있습니다. 중앙 구성 요소를 사용하여 액세스 제어를 관리하고 적용합니다.

민감한 기능 보호

액세스 제어가 끊어지고 공격 및 악용을 위해 데이터와 응용 프로그램을 활짝 열어 둘 수 있습니다. 제대로 보호되지 않는 고객 데이터는 대규모 데이터 유출로 이어질 수 있으며 평판과 수익을 저하시킬 수 있습니다.

액세스 권한이 손상되면 공격자가 액세스하지 않아야 하는 기능에 액세스할 수 있는 경우에도 계정 인계가 발생할 수 있습니다. 적절한 기능 수준 액세스 제어를 사용하면 악의적인 공격자, 심지어 우발적인 내부자로부터 응용 프로그램을 안전하게 보호합니다.

기능 수준 액세스가 모두 끝났다고 생각하십니까? 지금 깨진 액세스 제어를 복구하도록 자신에게 도전할 수 있습니다: [여기에서 시작]

"느슨한 입술 싱크 선박"차 세계 대전 동안 미국에서 인기를 끌었다 문구였다. 영국에서는 "부주의한 이야기가 생명을 요하는 것"이라는 말을 들었습니다. 말의 요점은 민감한 정보에 대한 부주의한 말하기가 스파이에 의해 들리지 않고 심각한 결과를 초래할 수 있다는 것이었습니다.

웹 응용 프로그램을 빌드할 때도 동일한 원칙이 적용됩니다. 웹 앱에 정보가 너무 많이 드러나면 공격자가 쉽게 침입할 수 있습니다.

이 게시물에서는 정보 노출이 무엇인지, 왜 위험한지, 이를 방지하는 방법을 다룰 것입니다.

정보 노출 이해

정보 노출은 내부 정보를 볼 수 없는 사람들에게 노출되는 웹 응용 프로그램을 말합니다. 또한 로그 파일이나 사용자 인터페이스를 통해 중요한 고객 정보를 노출하는 것을 참조할 수도 있습니다. 어느 쪽이든 공격자는 찾은 정보를 사용하여 시스템 이나 사용자를 공격할 수 있습니다.

공격자의 첫 번째 단계는 응용 프로그램 내에서 오류를 만드는 것입니다. 오류 처리가 잘못되고 웹 응용 프로그램 구성이 오류 메시지와 함께 정보 노출로 이어집니다. 공격자가 응용 프로그램 내에서 오류를 생성하면 어떻게 됩니까? 스택 추적과 같은 기술적 세부 정보를 포함하여 기술적 오류 메시지가 나타나면 너무 많은 정보가 공개되었습니다. 이러한 세부 정보에는 사용 중인 데이터베이스 또는 실행 중인 응용 프로그램 서버의 버전이 포함될 수 있습니다.

민감한 정보 공개는 다른 방법으로 발생할 수 있습니다. 중요한 정보를 포함하는 양식에 숨겨진 필드가 있습니까? 공격자는 페이지의 소스를 보고 값을 볼 수 있습니다.

간단히 말해서, 사용자와 알아야 할 정보를 너무 쉽게 액세스할 수 있게 되면 정보 노출이 발생합니다.

정보 노출이 위험한 이유 이해

공격자가 응용 프로그램에서 노출된 정보로 무엇을 할 수 있습니까? 정보가 본질적으로 중요한 경우 공격자는 ID 또는 사용자 자격 증명을 도용할 수 있습니다. 이로 인해 재정적 손해, 개인 정보 침해 및 규제 벌금이 부과될 수 있습니다.

공격자가 오류 메시지를 사용하여 응용 프로그램에 대한 정보를 얻는 경우 해당 정보는 향후 공격에 사용될 수 있습니다. 실제로 OWASP 테스트 가이드에는 정보 수집에대한 전체 섹션이 있습니다.

OWASP 테스트 가이드는 검색 엔진을 사용하여 의도하지 않을 수 있는 웹사이트에 대한 정보를 찾아보도록 권장합니다. 예를 들어 관리 페이지가 검색 엔진에 노출되어 있습니까? 로봇.txt 파일을 사용하여 검색 엔진에 특정 페이지를 색인하지 말라고 지시합니다. 동시에, 로봇.txt 파일뿐만 아니라 정보를 누설 할 수 있습니다. 민감한 URL은 때때로 로봇.txt 파일에 상주할 수 있습니다. 공격자는 파일을 아래로 끌어내어 사이트의 디렉터리 구조 중 일부를 배우기 시작합니다.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP 헤더, 웹 사이트 배너, HTML 및 JavaScript 코드 내의 의견도 정보 공격자가 볼 수 없습니다. HTTP 헤더는 응용 프로그램 서버와 버전 번호를 표시할 수 있습니다. 공격자는 이 정보를 사용하여 특정 버전에 대해 사용할 악용을 찾을 수 있습니다. 공격자가 귀하의 정보를 찾을 수 있는 모든 장소와 적절하게 숨기는 방법을 이해해야 합니다.

정보 노출 패배

정보 공개는 종종 웹 응용 프로그램 구성에 문제가 됩니다. 많은 응용 프로그램 서버가 기본적으로 오류 메시지에서 스택 추적을 반환합니다. 문제 해결을 위해 오류를 기록하는 동안 프로덕션 응용 프로그램이 일반 오류 페이지로 리디렉션되도록 이 설정을 변경해야 합니다. 자세한 오류 메시지는 사용자의 브라우저로 반환해서는 안 됩니다.

중요한 정보가 포함된 응용 프로그램에 필요한 파일이 있는 경우 적절한 액세스 제어를 통해 응용 프로그램 자체만 읽을 수 있는지 확인합니다. 서버의 디렉터리 목록을 사용하지 않도록 설정하고 이러한 파일을 웹 루트 디렉토리 외부로 이동합니다. 이렇게 하면 공격자가 디렉터리 트래버스 공격을사용하여 브라우저를 사용하여 파일로 탐색할 수 없습니다.

로그를 사용하여 올바르게 구성되지 않을 때 정보를 수집할 수 있습니다. 오류가 발생하면 암호, 세션 토큰 또는 개인 식별 정보(PII)와 같은 중요한 정보를 기록하지 마십시오. 공격자가 로그 파일에 액세스할 수 있다면 훔칠 중요한 정보의 보물을 찾을 수 있습니다. 일반적으로 계정 식별자, 자세한 오류 메시지, 오류가 발생하거나 수행 중인 작업 메서드인 필요 이상으로 기록하지 마십시오. 로그 파일이 비밀이 아니며 중요한 정보를 그 안에 배치하려는 유혹을 받지 않는다고 가정합니다.

웹 앱을 싱크하지 마십시오.

당신은 정말 친구에게 말하는 동안 정보를 유출 할 수, 직접 차 세계 대전에서 손실되는 전함으로 이어지는? 아마 아닐 거예요. 그런데 왜 위험을 감수해야 합니까? "느슨한 입술이 배를 가라 앉히는다"는 말의 교훈입니다.

마찬가지로 웹 응용 프로그램의 내부 작업을 외부 세계에 노출할 이유가 없습니다. 전체 신용 카드 번호 또는 암호를 볼 이유가 없습니다. 로그 파일에 PII 데이터를 가질 이유가 없습니다. 그래서 그것을하지 마십시오. 학습 리소스를 확인하여 정보 노출에 대해 자세히 알아보십시오.

응용 프로그램의 내부 작업을 해당 응용 프로그램의 속한 위치에 유지합니다. 웹 앱을 싱크하지 마십시오.

지금 정보 노출을 중단할 수 있다고 생각하십니까? 도전, 전사까지 단계 : [여기에서 시작]

모든 응용 프로그램이 가지고있는 한 가지는 무엇입니까? 종속성 또는 라이브러리라고도 하는 구성 요소입니다. 전 세계에는 어느 시점에서 다른 코드에 의존하지 않는 코드가 거의 없습니다. 당신은 당신이 응용 프로그램을 만들 때부터 종속성의 산으로 시작!

모든 응용 프로그램은 작성하지 않은 구성 요소를 사용하기 때문에 사용하는 구성 요소 내의 취약점은 부채가 될 수 있습니다. 알려진 취약점이 있는 구성 요소를 사용하는 것이 무엇을 의미하는지, 얼마나 위험한지, 어떻게 해결해야 하는지 에 대해 살펴보겠습니다.

알려진 취약점으로 구성 요소 사용 이해

모든 복잡한 소프트웨어에는 취약점이 있습니다. 그것은 짐승의 본질입니다. 따라서 구성 품은 100 % 안전하지 않습니다. 그러나 구성 요소에서 취약점이 발견되면 취약점에 대해 알고 있습니까? 당신은 그것을 위해 준비?

구성 요소가 유용한 수명을 지나거나 취약점이 발견된 후 사용되는 경우가 가장 많습니다. 대부분의 구성 요소와 라이브러리는 취약점이 발표되는 동시에 또는 그 이전에 보안 취약점에 대한 패치를 릴리스합니다. 따라서 구성 요소의 취약점이 발견되고 발표되면 가능한 한 빨리 구성 요소를 업데이트하는 것이 가장 중요합니다. 취약한 소프트웨어를 프로덕션상태로 두지 마십시오.

구성 요소는 여러 소스에서 올 수 있습니다. 경우에 따라 사용자 지정 코드와 직접 통합되는 타사 공급업체 제품을 구입할 수 있습니다. 이러한 구성 요소는 코드의 일부가 되며 동일한 권한 수준에서 작동합니다. 또 다른 소스는 GitHub와 같은 사이트에서 호스팅되는 오픈 소스 프로젝트입니다. 모든 오픈 소스 라이브러리가 취약점에 대해 신중하게 심사되거나 감사된 것은 아니기 때문에 오픈 소스가 위험할 수 있습니다.

공격자는 구성 요소 취약점 정보를 사용하여 활용합니다. 취약점이 공개적으로 발표되므로 공격자는 취약점에 대해 동시에 알고 있습니다. 공격자는 또한 사용 중어떤 구성 요소를 찾는 데 사용할 수 있는 기술도 있습니다. 이 정보를 알게 되면 패치되지 않으면 응용 프로그램을 공격하는 방법을 알 수 있습니다.

취약한 구성 요소가 위험한 이유 알고

알려진 취약점이 있는 구성 요소를 사용하는 것이 얼마나 위험한지 에 대한 증거를 찾고 있다면 2017년 Equifax 위반보다 더 자세히 살펴보세요.

2017년 7월, 미국 신용 국인 Equifax는1억 4,700만 명 이상의 개인 식별 정보를 유출한 대규모 데이터 유출을 발견했습니다. 이 데이터 유출의 범위와 영향은 전례가 없습니다. 최근, Equifax의 느슨한 보안 관행에대한 뉴스가 나왔다.

이러한 느슨한 관행 중 하나는 패치 관리였습니다. Equifax는 패치 관리 관행이 없었기 때문에 구성 요소가 패치되지 않고 꽤 많은 시간이 갈 것이라는 것을 의미했습니다. 이것은 위반의 직접적인 원인이었다.

Equifax의 웹 사이트는 아파치 스트럿웹 프레임워크를 사용했습니다. 공격자가 네트워크에 해킹하기 몇 달 전에, 취약점은 스트럿스 프레임 워크에서 발견되었다, 아파치 스트럿스 CVE-2017-5638. 그러나 Equifax는 취약점을 패치하지 않았습니다. 공격자는 이 취약점을 사용하여 Equifax의 네트워크에 액세스했습니다. 거기에서, 그들은 개인 정보의 보물 창고에 액세스 할 수 있었다.

많은 웹 사이트는 회사가 작성하지 않은 웹 프레임 워크를 기반으로합니다. 이것은 처음부터 필요한 모든 기능을 구축하는 것이 너무 커서 수행이 너무 커지므로 표준 관행입니다. 그러나 프레임워크에 크게 의존하면 취약점을 열 수 있습니다. 다음 Equifax가 되지 마십시오.

취약한 구성 요소로부터 보호하는 방법

취약한 구성 요소를 사용하지 않도록 보호할 실버 탄환은 없습니다. 그러나 취약한 구성 요소가 시스템을 손상시키는 데 사용될 위험을 완화하는 데 사용할 수 있는 정책 및 제어가 있습니다.

응용 프로그램을 빌드하기 위해 사용하는 구성 요소와 각 구성 요소의 버전을 알아야 합니다. OWASP의 종속성 검사와 같은 종속성 관리 도구를 사용하면 사용 중종속성에 대한 핸들을 얻을 수 있습니다. 종속성 검사에서 이러한 구성 요소 중 일부가 공개적으로 공개된 취약점이 있는지도 알 수 있습니다.

패치 관리 방법론도 필수적입니다. 취약점이 발견되면 패치를 다운로드, 테스트 및 프로덕션으로 원활하게 릴리스할 수 있는 시스템을 갖습니다. 소프트웨어를 패치상태로 유지하면 공격자가 수개월 동안 취약점을 사용할 수 없습니다.

마지막으로 오픈 소스 및 타사 구성 요소의 사용을 관리하는 정책을 시행합니다. 개발자는 빨간색 테이프를 가지고 싶지 않아, 그 이해할 수있다. 그러나 조직에서 작성하지 않은 코드에 대한 검사 프로세스가 있어야 합니다. 그것은 헤비 급 될 필요가 없습니다., 하지만 사용 되 고 알 수 없는 구성 요소를 방지 해야. 최소한 사용되는 구성 요소의 인벤토리는 최신 상태로 유지되어야 합니다.

타사 버그에 물린 하지 마십시오

구성 요소에 취약점이 있습니다. 비즈니스 응용 프로그램은 공급업체또는 오픈 소스 라이브러리에서 구성 요소를 사용합니다. 그렇다고 해서 조직이 공격에 취약해야 한다는 의미는 아닙니다.

공격자는 취약점이 동시에 존재하는지 알고 있지만 일반적으로 패치는 공개 공지와 동시에 사용할 수 있습니다. 따라서 응용 프로그램이 사용하는 용도에 대해 교육하십시오. 취약한 것을 알고 있습니다. 구성 요소를 패치 상태로 유지하십시오!

일부 취약한 구성 요소를 발견하고 물리 칠 준비가 되셨습니까? 전투에 참여하기 위해 경기장으로 향하십시오: [여기에서 시작]

원래 DevSecCon 블로그에게시.

울타리 의 양쪽에 있었던, 나는 보안 모범 사례를 유지하기에 올 때 개발 팀과 AppSec 전문가 사이에 발생할 수있는 긴장을 너무 잘 알고있다.

그것은 힘든; 하루가 끝나면 개발자의 최우선 순위는 소프트웨어 기능을 제공하는 것입니다. 그들은 아름답고 기능적이며 응용 프로그램의 힘을 선보일 수 있어야합니다. 민첩한 개발 관행은 일반적으로 요즘 에서 재생, 이러한 기능은 엄격한 마감일까지 완료해야합니다 ... 그리고 보안은 다른 많은 위험에 처한 우려 목록에서 거의 높지 않습니다.

보안은 AppSec 팀의 도메인으로 볼 수 있으며, 코드 검색(또는 더 나쁜: 수동으로 검토, 줄별) 코드가 안전하지 않거나 실제로 완전히 사용할 수 없다는 것을 개발 팀에 보고하는 부러운 작업입니다. 그들은 그들의 좋은 일을 따로 따로 따로 진흙에 막대기, 혁신을 중단 하 고 일반적으로 개발자에 대 한 두통을 만들. 하루의 끝에서, 많은 보안 문제는 매우 간단한 수정 " 아마도 하나의 코드 라인은 몇 분 안에 취약 한 백도어를 강화 할 수 있습니다.

하지만, 여기에 문제가 있습니다. "보안은 부정적인 경험과 동의어로, 개발자는 단순히 그들이해야만큼 밀접하게 그것에 종사하지 않습니다. 이러한 한 줄 수정은 일어나지 않습니다 : 결국 AppSec 사람들은 지속적으로 동일한 문제를 우연히 만날 수 있습니다. 우리가 처음 발견한 지 20년이 넘도록 SQL 주입 결함을 여전히 지적하는 것은 매우 매우 매심이 어야합니다(그리고 후속 수정 사항).

지금까지 우리가 한 일은 우리가 기대했던 만큼 효과적으로 작동하지 않습니다. 개발자와 AppSec 전문가 간의 교량 수리에 집중해야 하며, 개발자가 공간에 실질적인 영향을 미치기 위한 도구와 교육을 받는 긍정적인 보안 문화를 위해 노력해야 합니다.

누가 알아? 그들은 심지어 내가 그랬던 것처럼 그것에 사랑에 빠질 수 있습니다!

긍정적인 보안은 응용 프로그램 보안을 개선하는 가장 빠르고 쉬운 방법입니다.

"아니, 무형의 결과에 대해 우우가 아니에요. 그것은 성공의 안전한 코딩 조리법에 절대적으로 중요한 성분입니다.

개발자는 처음에 보안 코드를 작성하여 생산 초기부터 보안을 개선하는 열쇠를 쥐고 있습니다. 긍정적인 보안 문화를 만들고 개발자가 응용 프로그램 보안에 대해 흥분하도록 함으로써 AppSec land의 스캔 또는 수동 코드 검토에 앞서 일반적인 취약점을 전멸할 수 있습니다.

이미 커밋된 코드의 취약점을 해결하는 데 30배 더 비용이 많이 들기때문에 개발자의 강점에 맞는 교육을 찾고 관심을 유지하며 실제로 작동하는 교육을 찾는 것은 반복되는 취약점을 식별하고 해결하기 위한 향후 비용 절감의 큰 단계입니다.

긍정적이고 개발자중심적인 이니셔티브는 올바른 보안 문화를 조성합니다.

모든 사람이 보안 모범 사례를 가진 동일한 페이지에 있을 때, 긍정적인 보안 문화는 행복하고 중요한 부산물입니다.

긍정적이고 확장 가능한 개발자 중심이니셔티브는 올바른 보안 문화를 조성합니다. 개발자의 문제 해결, 창의적인 마음을 결합하는 것은 개발자를 이기는 데 필수적이며, 새로운 신병이 팀의 보안 기대치에 따라 신속하게 속도를 낼 수 있도록 하는 데 필수적입니다. 개발자 보안 관계가 어떻게 발전했는지에 대한 개요와 자체 조직에서 성공적인 보안 인식 프로그램을 출시하는 방법에 대한 아이디어를 확인하세요.

이 블로그에서는 웹 사이트를 실행하거나 직원이 원격으로 컴퓨터 리소스에 액세스할 수 있는 조직에서 직면한 가장 일반적인 문제 중 하나를 다룰 것입니다. 그리고 네, 당신은 아마 우리가 인증에 대해 이야기 할 거라고 짐작.

해커가 유효한 사용자 이름과 암호를 가진 관리자로 시스템에 로그인할 수 있는 경우 네트워크 방어를 위해 고급 기술을 배포할 필요가 없습니다. 시스템은 단순히 문을 열고 내부 공격자를 할 수 있습니다. 더 나쁜 것은 공격자가 너무 이상한 일을하지 않으면 대부분의 방어가 단순히 유효한 사용자 또는 관리자로 간주하기 때문에 그들의 존재를 감지하는 것은 거의 불가능합니다.

인증 취약점의 범주는 매우 크지만 실수로 사용자 로그인 프로세스에 구워지는 경향이있는 가장 일반적인 문제를 극복 할 것입니다. 이러한 구멍을 제거하면 조직에서 대부분의 인증 문제를 제거할 수 있습니다.

이 에피소드에서는 다음을 배우게 됩니다.

• 몇 가지 일반적인 인증 취약점이 악용되는 방법
• 왜 그렇게 위험합니까?
• 인증 취약점을 제거하는 데 사용할 수 있는 정책과 기술입니다.

공격자는 인증 취약점을 악용하는 방법은 무엇입니까?

인증 시스템에 들어갈 수 있는 인증 취약점이 꽤 많기 때문에 해커는 각 취약점을 조금 다르게 악용합니다. 먼저 가장 일반적인 취약점을 살펴보겠고 몇 가지 취약점이 어떻게 악용되는지 보여주는 예제를 제공해 보겠습니다.

가장 일반적인 인증 취약점은 다음과 같습니다.

• 암호 정책이 약하거나 부적절한 경우
• 무제한 로그인 시도 허용,
• 실패한 로그인시 공격자에게 정보를 다시 제공,
• 안전하지 않은 채널을 통해 자격 증명을 보내고,
• 약하게 해시 암호,
• 그리고 안전하지 않은 암호 복구 프로세스를 가지고.

암호 정책이 약한 것이 가장 일반적인 취약점일 수 있습니다. 사용자가 제한 없이 암호를 만들 수 있는 경우 너무 많은 암호를 쉽게 추측 할 수 있습니다. 매년 다양한 컴퓨터 뉴스 조직이 가장 많이 사용되는 암호 목록을 내놓고 "123456"과 "암호"는 항상 상위 5위 안에 들 수 있습니다. 다른 사람들이 있습니다. 관리자는 "하나님"을 꽤 많이 사용하는 것을 좋아합니다. 사실, 그들은 모두 유머 또는 기억하기 쉬운 중 하나, 뿐만 아니라 추측하기 매우 쉽습니다. 해커는 가장 일반적인 암호가 무엇인지 알고 시스템을 위반하려고 할 때 먼저 시도합니다. 조직에서 이러한 종류의 암호가 허용되는 경우 결국 위반됩니다.

덜 분명하지만 여전히 위험한 취약점은 실패한 로그인과 관련하여 사용자에게 정보를 다시 제공하는 것입니다. 사용자 이름이 존재하지 않고 암호가 잘못될 때 하나의 메시지를 반환하면 공격자가 시스템에 유효한 사용자를 매핑하고 해당 사용자 이름에 대해 암호를 추측하는 데 집중할 수 있기 때문입니다. 무제한 암호 추측을 허용하는 인증 취약점과 결합된 경우 공격자가 발견한 유효한 사용자에 대한 사전 공격을 실행할 수 있으므로 암호를 추측하기 쉬운 경우 시스템에 상당히 빠르게 들어갈 수 있습니다.

인증 취약점이 왜 그렇게 위험합니까?

미국 올드 웨스트에서 그의 현관문에 트리플 잠금 장치를 설치하고 창문을 열고 쉽게 도달 할 수있는 많은 총으로 잤던 편집증 적 집에 대한 고전 이야기가 있습니다. 아침에 그는 죽은 채로 발견되었습니다. 그의 공격자는 그가 뒷문을 잠그는 것을 잊고 있기 때문에 그에게 도착했다. 인증 취약점은 다음과 같습니다. 공격자가 유효한 사용자 이름과 암호를 사용하여 네트워크에 들어갈 수 있는 경우 어떤 종류의 모니터링 도구 또는 사전 제어 기능을 사용할지 또는 얼마나 많은 전문 분석가가 고용하는지는 중요하지 않습니다.

일단 내부에, 그 공격자가 할 수있는 일에 거의 제한이 있다. 관리자 계정을 손상한 경우 매우 광범위할 수 있는 사용자 권한 내에서 행동하는 한 심각한 문제를 예방하기 위해 제 시간에 잡힐 가능성은 거의 없습니다. 따라서 취약점의 인증 클래스는 모든 시스템에서 가장 위험합니다.

인증 취약점 제거

네트워크에서 인증 취약점을 제거하는 가장 좋은 방법 중 하나는 전 세계적으로 시행되는 좋은 암호 정책을 갖는 것입니다. 사용자, 심지어 관리자도 "암호"와 같은 암호를 사용하는 것을 제한해야 할 뿐만 아니라 공격자가 사전 또는 일반적인 구 유형의 공격 유형을 적용하는 것이 불가능할 수 있도록 복잡성 수준에 추가해야 합니다. 보호되는 시스템의 중요성에 따라 암호 만들기에 대한 고유한 규칙을 생각해 볼 수 있습니다. 이렇게 하면 공격자가 암호를 추측하거나 무차별 암호로 추측하기가 훨씬 어려워집니다.

또한 잘못된 암호를 세 번 이상 입력하면 사용자가 잠겨 있도록 실패한 로그인 시도 횟수를 제한해야 합니다. 몇 분 지연으로 인해 자동화된 사전 공격이 계속되지 않도록 잠금이 일시적일 수 있습니다. 또는 관리자가 계정을 잠금 해제하지 않는 한 영구적일 수 있습니다. 두 경우 모두 이러한 잠금이 발생할 때마다 보안 담당자에게 경고를 하여 상황을 모니터링할 수 있습니다.

공격자가 정보를 수집하지 못하도록 하는 또 다른 좋은 방법은 잘못된 사용자 이름이나 암호를 입력할 때마다 일반 메시지를 만드는 것입니다. 해커가 사용자가 존재하지 않거나 잘못된 암호를 가지고 있기 때문에 거부되었는지 알 수 있도록 두 경우 모두 동일해야 합니다.

인증 취약점은 대부분의 시스템에서 가장 일반적이고 위험한 취약점 중 하나입니다. 그러나 그들은 또한 찾아서 제거하는 것이 매우 쉽습니다.

인증 취약점에 대한 자세한 정보

자세한 내용은 OWASP 인증 치트 시트를살펴볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

단계및 인증 취약점에 정면으로 직면 Secure Code Warrior 플랫폼: [여기에서 시작]

오래된 말하기 쉬운 또는 지하 클럽의 문에 가는 것을 상상해보십시오. 도어의 작은 구멍이 열리고 버리 바운서가 암호를 요청합니다. 잠재적인 방문자는 암호를 모르고 추측을합니다. 그것은 잘못, 그래서 바운서 안에 그들을 못하게.

그것은 일반적으로 일어날 것입니다. 이제 잘못된 암호를 추측 한 방문자가 즉시 다시 시도하고 잘못되고 다시 액세스가 거부된다고 상상해보십시오. 그런 다음 잠재적 인 방문자가 사전을 열고 aardvark 같은 것을 시작하고 가능한 모든 단어를 시도하기 시작, 단어를 읽기 시작합니다 상상해보십시오.

대부분의 경우, 바운서가 그런 종류의 활동을 허용하지 는 않지만 자동화 가 부족한 웹 사이트및 응용 프로그램은 그렇게합니다. 그들은 사용자가 암호를 계속 시도 할 수 있습니다, 심지어 자동화 기술을 사용하여, 그들은 마침내 적절한 캐치 프레이즈를 우연히 발견 할 때까지.

이 에피소드에서는 다음을 배우게 됩니다.

• 공격자가 자동화가 부족한 방법을 악용하는 방법
• 자동화가 부족한 응용 프로그램이 위험한 이유
• 이 취약점을 해결할 수 있는 기술입니다.

공격자는 자동화가 부족한 방법을 악용합니까?

우리의 상상의 말하기 쉬운 방문자와 같은 자동화 또는 사전 스타일의 공격을 사용하는 것은 사이버 보안에 새로운 것이 아닙니다. 사실, 그 무차별 힘 스타일 공격은 지금까지 배포 된 최초의 해커 기술 중 일부였다. 컴퓨터가 더 빠르게 성장함에 따라 점점 더 효율적이되었습니다. 빠른 컴퓨터는 공격 컴퓨터와 대상 시스템 간의 연결 속도에 따라 단 몇 분 만에 전체 단어 사전을 실행할 수 있습니다.

이러한 종류의 자동화 된 공격은 자동화 방지 소프트웨어와 기술이 만들어지는 이유였습니다. 응용 프로그램에서 사용자가 취하는 작업이 일반적인 인간의 행동의 규범 을 벗어난지 확인할 수 있습니다.

응용 프로그램에 자동화 방지 검사가 부족한 경우 공격자는 일치하는 경우 암호를 계속 추측할 수 있습니다. 또는 자동화 소프트웨어를 사용하여 웹 사이트 포럼에 스팸 댓글과 같은 다른 작업을 수행할 수 있습니다.

자동화 가 부족한 경우 위험합니까?

악의적인 사용자가 자동화를 사용하여 보안을 우회하도록 허용하는 것은 위험할 수 있습니다. 자동화 유형 공격이 컴퓨팅 초기부터 지금까지 지속된 이유는 매우 효과적일 수 있기 때문입니다. 자동화 프로그램에 잘못된 추측에 대한 결과없이 암호를 제출하는 데 무제한의 시간을 제공하면 결국 올바른 암호를 찾을 수 있습니다.

포럼과 같은 경우에, 명백하게 스크립트 된 댓글의 물결을 갖는 것은 유효한 사용자를 좌절 시킬 수 있습니다, 또는 시스템 리소스를 낭비에 의해 서비스 거부 공격의 일종처럼 행동. 자동 게시는 피싱 이나 다른 공격의 도구로 사용 될 수 있습니다 가능한 한 많은 사람들에게 미끼를 노출.

자동화 방지 문제 해결

자동화 가 부족한 문제를 해결하기 위해 모든 응용 프로그램에는 사람이나 자동화 소프트웨어에 의해 수행되는 작업이 구현되는지 여부를 확인할 수 있어야 합니다. 가장 인기 있고 널리 사용되는 기술 중 하나는 컴퓨터와 인간을 구별하는 완전 자동화 된 공개 튜링 테스트입니다.

CAPTCHA는 기본적으로 1950년 컴퓨터 과학자 앨런 튜링(Alan Turing)이 처음 제안한 튜링 테스트로,인간과 컴퓨터의 행동을 분리하고 식별할 수 있습니다. 현대 CAPTCHA는 인간이 쉽게 해결할 수있는 문제를 제시하지만, 어떤 컴퓨터가 어려움을 겪고, 또는 단순히 알아낼 수 없습니다. 인기있는 하나는 그리드로 분리 된 사진을 제시하고 꽃이나 얼굴과 같은 특정 항목으로 모든 섹터를 식별하도록 사용자에게 요청합니다. 컴퓨터는 요구되는 것을 이해할 수 없으므로 이미지를 스캔하려고 시도조차 할 수 없습니다. 비록 할 수 있더라도 이미지 인식은 특별히 제작되지 않은 대부분의 프로그램을 넘어섭습니다.

CAPTCHA의 다른 예로는 흐릿한 텍스트를 표시하거나 간단한 논리 질문을 하거나 질문을 큰 소리로 재생하는 것이 있습니다. 암호를 묻는 메시지가 표시될 때와 같이 응용 프로그램의 중요한 지점에서 CAPTCHA 문제를 구현하면 트랙에서 자동화 프로그램을 중지할 수 있습니다.

또한 동일한 소스에서 잘못된 추측 수를 제한하여 자동화 프로그램을 중지할 수도 있습니다. 잘못된 추측이 너무 많으면 계정을 일시적으로 잠글 수 있으므로 유용성 지점을 지나 자동화 프로그램이 지연되거나 휴먼 관리자가 잠금을 해제해야 할 수도 있습니다. 이러한 작업을 수행하면 응용 프로그램 내에서 자동화 방지 취약점을 방지해야 합니다.

자동화 부족에 대한 자세한 정보

추가 읽기를 위해 OWASP가 자동화가 부족한것에 대해 말하는 것을 살펴 볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

지금 당장 자동화가 부족한 안티 오토메이션을 찾고 수정할 준비가 되셨습니까? 우리의 게임 경기장에서 당신의 능력을 테스트 : [여기에서 시작]

이 공유 및 학습 시리즈에서 다루고 있는 다른 대부분의 취약점과 달리 비즈니스 논리 문제는 코딩 오류와 직접 적으로 연관되지 않습니다. 코딩 문제가 문제의 일부일 수 있지만 비즈니스 논리 오류는 앱이 처음 생성될 때 디자인 결함이나 잘못된 논리적 가정의 결과입니다.

사용자가 응용 프로그램을 사용할 때 예기치 않은 작업을 수행하면 비즈니스 논리 문제가 발생할 수 있습니다. 예기치 않게 주문을 취소하거나, 쿠폰 코드를 너무 여러 번 적용하거나, 예상 단계를 건너뛰고 응용 프로그램이 처리하는 방법을 모르는 작업을 수행함으로써 거의 모든 것이 될 수 있습니다. 비즈니스 논리 결함을 악용하는 것은 심지어 어떤 교육을 필요로하지 않습니다, 상자 밖에서 생각하는 호기심 마음을 가진 단지 악의적 인 사용자.

이 에피소드에서는 다음을 배우게 됩니다.

• 공격자가 비즈니스 논리의 결함을 악용하는 방법
• 비즈니스 논리 결함이 있는 응용 프로그램이 위험한 이유
• 비즈니스 논리 오류를 방지할 수 있는 기술입니다.

공격자는 비즈니스 논리 문제를 어떻게 악용합니까?

대부분의 악용과 달리 이 취약점을 일으킬 수 있는 특정 코드 문자열을 가리킬 수 없습니다. 대신, 그것은 예상 되지 않은 작업을 복용 하는 사용자에 게 온다, 어떤 프로그램은 처리 하는 방법을 모른다. 예를 들어 은행 응용 프로그램을 통해 사용자가 다른 계좌로 송금할 수 있다고 가정해 보겠습니다. 그러나 악의적인 사용자가 돈을 보내는 대신 다른 계정으로 음수를 보내려고 합니다. 은행 응용 프로그램은 어떻게 반응합니까? 충돌할 까요? 전송을 거부할 것인가? 아니면 실제로 그 음수의 균형을 위해 전송을 시작한 사용자에게 돈을 다시 보낼 수 있습니까?

전자 상거래 사이트는 특히 독특하지는 않지만 많은 사용자가 상호 작용하도록 설계되어 많은 구성 요소가 있기 때문에 비즈니스 논리 결함에 취약합니다. 예기치 않게 주문을 취소, 여러 번 단일 쿠폰을 적용하거나 심지어 자신의 장바구니를 과부하는 예상되지 않은 조건으로 응용 프로그램을 제시 할 수 있습니다. 알 수없는 상황에 직면 했을 때 프로그램이 어떻게 반응할지 알 수있는 방법은 없습니다. 최상의 시나리오는 오류 메시지를 생성할 수 있지만 앱이 무료로 상품을 제공하는 것과 같은 더 나쁜 조치를 취하지 않는다는 보장은 없습니다.

비즈니스 로직 문제가 위험한 이유는 무엇입니까?

비즈니스 논리 문제는 프로그래밍이나 해커 교육이 없는 사람조차도 누구나 악용할 수 있기 때문에 매우 위험할 수 있습니다. 실제로 는 실험과 시간만 필요하며, 주위를 클릭하고 응용 프로그램이 응답하도록 설계된 방식의 결함을 찾으려고 시도합니다. 악의적인 사용자가 사이트의 비즈니스 논리에 결함을 발견하면 가능한 한 악용할 수 있습니다.

가장 큰 위험은 일반적으로 금융, 사용자가 구입 하는 데 20 그들을 위해 지불 하지 않고 큰 화면 텔레비전, 또는 그런 것. 그러나 비즈니스 논리 결함으로 인해 다른 문제가 발생할 수도 있습니다. 예를 들어 사이트를 보호하는 암호 함수가 사용자가 지속적으로 취소할 경우 어떻게 해야 할지 모르는 경우 로그인 프로세스를 모두 우회할 수 있습니다.

비즈니스 논리 문제가 발생할 수 있는 피해가 얼마나 발생할 지 예측할 수 있는 방법은 없습니다. 종종 문제의 첫 번째 표시는 사용자가 그들을 악용 한 후 오래 온다.

비즈니스 논리 문제 해결

안타깝게도 취약점 스캐너와 같은 일반적인 도구를 사용하면 비즈니스 논리 문제에 대한 테스트를 쉽게 자동화할 수 없으므로 비즈니스 논리 문제를 식별하거나 해결하는 데 도움이 되지 않습니다. 이를 방지하는 가장 좋은 방법은 응용 프로그램이 개발되는 동안 부정적인 테스트 사례에 대한 좋은 계획, 오류 처리 및 테스트를 구현하는 것입니다. 먼저 응용 프로그램이 수행하도록 설계된 모든 가능하고 원하는 작업을 포함하는 명확하게 정의된 비즈니스 규칙 집합이 필요합니다.

비즈니스 규칙 계획으로 무장한 비즈니스 논리 결함이 들어오는 것을 방지하는 가장 좋은 방법 중 하나는 데이터 및 트랜잭션이 응용 프로그램 내에서 흐르는 가능한 모든 방법을 보여주는 흐름 차트를 만드는 것입니다. 여기에는 사용자가 선택하거나 입력 데이터를 만들 수 있는 모든 인스턴스에 대한 모델링 동작이 포함됩니다. 흐름 다이어그램의 가능한 작업이 비즈니스 규칙 계획의 함수와 일치하는지 지속적으로 확인합니다.

마지막으로 위협 모델링을 사용하여 설계, 구현 및 테스트 단계에서 비즈니스 논리의 결함을 식별합니다. 페일세이프로 특별히 예상되지 않는 상황이 발생하면 프로그램이 취해야 할 작업을 만듭니다. 이는 작업을 거부하고 관리자에게 발생한 문제에 대해 경고하는 것만큼 간단할 수 있습니다.

비즈니스 논리 문제에 대한 자세한 정보

추가 읽기를 위해 비즈니스 논리 문제에대한 OWASP 페이지를 살펴볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

지금 비즈니스 논리 취약점을 찾고 파괴할 준비가 되셨습니까? 플랫폼으로 가서 기술을 테스트하십시오: [여기에서 시작]

사용자가 이메일을 사용하여 응용 프로그램을 통해 피드백, 약속 미리 알림 및 기타 다양한 정보를 보낼 수 있도록 웹 사이트 및 응용 프로그램이 요즘 일반적입니다. 일반적으로 이 프로세스는 상당히 양호하며 대부분의 사람들은 잠재적인 보안 위험 측면에서 그것에 대해 생각하지 않습니다.

그러나 사용자 입력을 허용하는 다른 디자인 요소와 마찬가지로 제대로 구성되지 않으면 악의적인 사용자가 악의적인 방식으로 조작할 수 있습니다. 사용자에게 서버에서 실수로 처리되는 입력 필드에 코드를 입력할 수 있는 기능을 제공하는 데만 필요한 것입니다. 갑자기 이메일 응용 프로그램이 무기화 될 수 있습니다.

이 에피소드에서 우리는 배울 것입니다 :

• 공격자가 전자 메일 헤더 주입을 트리거하는 방법
• 이메일 헤더 주사가 위험한 이유
• 이 취약점을 해결할 수 있는 기술입니다.

공격자는 이메일 헤더 주입을 트리거하는 방법은 무엇입니까?

프로그래밍 가능한 것으로 생각되는 경우가 많지는 않지만 대부분의 이메일 연락처 응용 프로그램 이나 응용 프로그램에 넣은 기능은 쿼리의 특성을 변경하는 입력을 수락할 수 있습니다. 사용자가 전자 메일 주소와 같은 정보를 계약 필드에 입력한 후 서버에서 자동으로 수행됩니다. 그런 다음 프로그램은 메시지를 구성하고 적절한 받는 사람을 추가하고 기본 전자 메일 서버를 사용하여 메시지를 보냅니다.

일반적인 이메일 POST 요청은 다음과 같이 보일 수 있습니다.

포스트/연락처.php HTTP/1.1
호스트: www.example.com

그리고 사용자가 자신의 정보를 입력 한 후 다음과 같은 다음과 같은 코드를 생성 :

이름=리얼네임&답장=RealName@ValidServer.com&메시지=귀하의약속 알림

문제는 해커가 자신의 연락처 정보 대신 프로세스에 코드를 삽입하기 시작할 때 발생합니다. 이는 SQL 주입 유형 공격과 는 달리 전자 메일 응용 프로그램에 대해 수행됩니다. 대신 대상 사용자에게 응용 프로그램에서 스팸을 보내는 조작 된 쿼리의 예는 다음과 같습니다.

이름=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=스팸 메시지

이메일 헤더 주입이 위험한 이유는 무엇입니까?

악의적인 사용자의 기술과 의도에 따라 이메일 헤더 주입 공격은 단순히 성가신 것에서 심각도 면에서 매우 위험할 수 있습니다. 심각도 척도의 로우 엔드에서 회사 내 비밀 또는 공개되지 않은 사서함으로 전송된 나가는 메시지의 BCC 필드에 연락처 정보를 삽입하여 해커에게 공개할 수 있습니다.

더 많은 관련, 그것은 완전히 귀하의 이메일 서버를 제어 하 여 스팸 을 보낼 수 있습니다., 피싱 또는 조직에서 다른 공격 이메일. 그들은 시도하고 이메일이 실제로 거기에서 유래 될 것이기 때문에, 내부 서버에서 오는 사실을 가짜 필요가 없습니다. 또한 해당 활동을 모니터링하지 않으면 프로세스를 자동화하고 조직의 서버를 사용하여 수백 또는 수천 개의 전자 메일을 발송할 수 있으며 실제로 해당 활동을 선동하는 것처럼 보입니다.

이메일 헤더 주입 문제 제거

SQL 주입 및 이러한 특성의 다른 공격과 마찬가지로 악의적인 사용자가 전자 메일 헤더 취약점을 악용할 가능성을 제거하는 열쇠는 사용자 입력을 신뢰하지 않습니다. 사용자가 정보를 입력할 수 있는 경우 이메일 주소 입력과 같은 사소한 프로세스처럼 보이지만 최악의 경우 를 가정해야 합니다. 또는 적어도 최악의 경우 가능하다고 가정하십시오.

입력 유효성 검사는 모든 매개 변수에 대해 수행해야 하며 앱 또는 웹 사이트에 이메일 연락처 기능을 추가할 때 포함됩니다. 화이트리스팅은 다른 모든 것을 부인하면서 유효하다고 판단되는 프로세스와 필드를 구체적으로 사용하도록 설정하는 데 사용할 수 있습니다. 실제로 대부분의 프레임워크에는 필요한 프레임워크에 만 함수를 잠그는 데 사용할 수 있는 라이브러리가 있습니다. 이렇게 하면 악의적인 사용자가 입력한 코드 나 명령이 서버에서 인식하고 처리되지 않습니다.

이메일 헤더 주입에 대한 자세한 정보

추가 읽기를 위해, 당신은 OWASP 이메일 헤더 주사에대해 말하는 것을 살펴 볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

지금 이메일 주입을 찾아 고칠 준비가 되었다고 생각하십니까? 플랫폼으로 가서 기술을 테스트하십시오: [여기에서 시작]

URL은 우리가 알고 사랑하는 모든 웹 사이트와 웹 응용 프로그램을 탐색하는 데 필수적입니다. 그들의 기본 기능은 리소스가 있는 위치와 리소스를 검색하는 방법을 식별하는 것입니다. 월드 와이드 웹이 작동하려면 URL이 필요하지만 제대로 보호되지 않으면 보안 위험이 발생할 수도 있습니다.

이 게시물에서는 다음을 배우게 됩니다.

• IDOR가 무엇이며 공격자가 IDOR를 사용하는 방법
• IDOR가 위험한 이유
• 이 취약점을 해결할 수 있는 기술

IDOR 이해

직접 개체 참조는 응용 프로그램 내에서 특정 레코드("개체")가 참조되는 경우입니다. 일반적으로 고유 식별자의 형태를 취하고 URL에 나타날 수 있습니다.

예를 들어 URL 끝에 "?id=12345"와 같은 것을 알 수 있습니다. 숫자, 12345, 특정 레코드에 대 한 참조. 개별 레코드에 대한 액세스 제어가 없을 때 보안 취약점이 들어옵니다. 이를 통해 사용자는 볼 수 없는 레코드와 데이터에 액세스할 수 있습니다. 이것은 상대적으로 낮은 기술 수준을 필요로 하는 공격입니다.

이 경우 공격자가 URL의 ID를 12344로 변경한다고 가정해 보겠습니다. IDOR에 취약한 응용 프로그램에서 공격자는 해당 레코드와 관련된 데이터를 볼 수 있습니다.

이러한 유형의 취약점이 실제로 발생할 수 있는 피해는 얼마입니까?

IDOR가 위험한 이유 알기

개발자가 주의하지 않으면 다양한 장소에서 응용 프로그램 레코드를 표시하고 누수하는 시스템을 설계할 수 있습니다. 특히 중요한 데이터 또는 PII가 관련된 경우 이 크기의 위반이 심각할 수 있습니다.

호주 세무국은 기업이 새로운 세금을 징수할 수 있도록 웹 사이트를 설정했습니다. 불행히도 IDOR 취약점의 원치 않는 기능으로 포장되었습니다. 호기심 많은 사용자는 사이트 내의 URL에 호주 비즈니스 번호 또는 ABN이 포함되어 있음을 깨달았습니다. 등록된 비즈니스에서 쉽게 검색할 수 있는 수치입니다. 이 사용자는 다른 회사의 번호를 URL에 넣기로 결정했습니다. 그는 자신의 은행 계좌 정보와 개인 정보와 재능이 있었다!

애플은 최근 IDOR 취약점의 희생자가 되었다. iPad가 처음 출시되었을 때 114,000개의 고객 이메일 주소가 유출되었습니다. (공정하게, 그것은 AT&T의 부분에 더실수했다).

AT&T는 iPad에 대한 3G 연결을 지원하는 서비스를 구축했습니다. iPad는 SIM 카드에 저장된 식별자를 AT&T의 서비스에 보냈습니다. 그런 다음 서비스가 사용자의 이메일 주소를 반환했습니다.

불행히도 이러한 식별자는 단순히 순차적 정수이므로 쉽게 추측 할 수 있었습니다. 공격자는 식별자를 통해 반복하고 이메일 주소를 훔쳤습니다.

또 다른 실수는 AT&T의 서비스가 요청의 사용자 에이전트 헤더가 iPad에서 온 것으로 나타난 경우에만 이메일 주소를 반환하여 서비스를 "보안"하려고 했다는 것입니다. 사용자 에이전트는 쉽게 조작할 수 있는 문자열 값일 뿐입니다.

IDOR 취약점은 미묘하고 비열할 수 있습니다. 그들을 물리 칠 하는 방법을 논의 하자.

IDOR 패배

액세스 제어는 IDOR를 해결하는 열쇠입니다. 사용자가 특정 레코드를 요청하면 요청된 레코드를 볼 수 있는 권한이 있는지 확인합니다.

중앙 집중식 권한 부여 모듈을 사용하는 것이 이 작업을 수행하는 가장 좋은 방법입니다. 스프링 시큐리티와 같은 도구는 응용 프로그램에 대한 강력하고 사용자 정의 가능한 인증 및 권한을 제공합니다.

결론: 다른 모든 코드가 권한 부여 검사를 수행하는 데 의존하는 하나의 모듈이 있습니다.

또 다른 일반적인 완화는 대리 참조를 사용하는 것입니다. URL에서 실제 데이터베이스 레코드 식별자를 사용하는 대신 실제 레코드로 다시 매핑되는 난수를 만들 수 있습니다.

대리 참조를 사용하면 공격자가 다음 유효한 식별자를 추측하는 것만으로는 레코드에 도착할 수 없습니다.

마지막으로 사용자가 조작하여 권한을 제공할 수 있는 것은 아무것도 의존하지 마십시오. AT&T는 사용자 에이전트 헤더를 사용하여 서비스를 승인하려고 했습니다. HTTP 헤더, 쿠키 또는 GET 및 POST 매개 변수에 의존하지 마십시오.

이러한 완화를 통해 IDOR는 과거의 일이 될 것입니다.

참조 보안

안전하지 않은 직접 개체 참조는 악용하기 가장 쉬운 취약점 중 하나입니다. 당신이 적어도 그것을 기대할 때 그들이 당신에 몰래하지 마십시오. 항상 사용자가 권한이 있는지 확인합니다. 실제 데이터베이스 식별자를 사용하지 마십시오. 권한 부여를 위해 사용자 제어 데이터에 의존하지 마십시오.

학습 리소스를확인하여 숙달을 구축할 수 있습니다. 원하는 언어로 IDOR 취약점을 완화하는 방법을 연습하면 프로덕션 코드베이스에서 이 문제를 찾아 해결하는 데 아무런 문제가 없습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

지금 IDOR 공격을 방어할 준비가 되셨습니까? 플랫폼으로 가서 무료로 도전하십시오: [여기에서 시작]