웹 애플리케이션의 핵심 방어 메커니즘은 무엇인가?

악의적인 입력을 방지하기 위해 애플리케이션은 수많은 보안 메커니즘을 구현하며 이러한 보안 메커니즘은 개념상 모두 유사합니다.

이러한 보안 메커니즘은 다음과 같은 측면으로 구성됩니다.

1. 웹 애플리케이션에 액세스하는 사용자의 데이터 및 기능 처리(무단 액세스 방지)

2. 사용자가 웹 애플리케이션 기능에 입력한 데이터 처리(무단 액세스 방지) 악성 데이터 구축)

3. 공격 대응(예상치 못한 오류 처리, 명백한 공격 자동 차단, 관리자에게 자동 경고 전송, 프로그램 액세스 로그 유지)

4. 애플리케이션 관리 및 유지

액세스 처리

보통 일반 사용자, 로그인 확인 사용자, 관리자 등 애플리케이션에 대한 다양한 유형의 사용자. 서로 다른 사용자 웹 애플리케이션에는 서로 다른 데이터와 기능에만 액세스할 수 있도록 서로 다른 권한이 부여됩니다.

웹 애플리케이션은 세 가지 상호 연관된 보안 메커니즘을 통해 사용자 액세스를 처리합니다.

2. 세션 관리(Session Management)

3. 이 세 가지 메커니즘은 사용자를 처리합니다. 애플리케이션에 대한 액세스는 세 가지 공격 표면이기도 하며, 이 세 가지는 문제가 있는 곳에 관계없이 상호 의존적이고 필수적입니다(배럴 원칙).

인증

인증은 사용자 액세스를 처리하는 첫 번째 메커니즘입니다. 웹사이트에 한 가지 유형의 사용자만 있는 경우가 아니면 인증을 사용해야 합니다.

오늘날 대부분의 웹 애플리케이션은 사용자 이름과 비밀번호인 전통적인 인증 모델을 사용합니다.

은행, 기타 인증서, 이중 인증 등과 같이 보안이 높은 애플리케이션에서는 보안 요구 사항이 더 높은 애플리케이션에서 이 모델을 강화하는 데 사용되며 클라이언트 인증서, 스마트 카드 또는 시도 응답 메커니즘이 필요할 수 있습니다. . 기타 인증 모델.

인증 메커니즘에는 등록, 비밀번호 분실, 비밀번호 변경 등과 같은 일련의 기타 지원 기능이 필요한 경우가 많습니다.

사용자 이름 탐색, 취약한 비밀번호, 로그인을 피하기 위한 논리적 결함, 사회 공학 데이터베이스 쿼리 등과 같은 인증 메커니즘에는 몇 가지 일반적인 취약점이 있습니다.

세션 관리

인증을 통과했다면 이제 사용자의 세션을 관리할 차례입니다. 액세스 제어를 구현하려면 애플리케이션은 여러 사용자가 제출한 다양한 요청을 식별해야 하며, 이를 위해 애플리케이션은 각 사용자에 대한 세션을 설정하고 세션을 나타내는 토큰, 즉 세션 토큰을 보내야 합니다. 사용자. 세션 자체는 사용자와 애플리케이션 간의 상호 작용 상태를 추적하는 서버에 저장된 데이터 구조 세트입니다.

세션 토큰은 일반적으로 쿠키로 전달되며 때로는 숨겨진 양식 필드 또는 URL 쿼리 문자열에 표시됩니다. 세션 토큰은 요청을 중지한 후 일정 기간 내에 만료됩니다.

일부 애플리케이션은 세션 토큰을 사용하여 세션을 식별하지 않고 대신 사용자 인증서를 반복적으로 제출하여 세션을 식별합니다(이 경우는 base64로 암호화된 계정 비밀번호를 반복적으로 제출하여 세션을 식별하는 http의 내장 인증 메커니즘의 경우입니다). 어떤 경우에는 세션 정보가 서버에 저장되지 않고 클라이언트에 저장되는 경우가 있는데, 사용자가 이를 수정하는 것을 방지하기 위해 일반적으로 암호화됩니다.

세션 관리의 공격 표면은 세션 토큰 자체입니다. 세션 토큰의 생성 규칙을 유추하거나 다른 사용자의 세션 토큰을 가로채는 방식으로 승인되지 않은 기능 및 데이터에 다른 사람처럼 접근할 수 있습니다.

액세스 제어

이전 인증 및 세션 관리가 정상적으로 실행되고 있는 경우 애플리케이션은 각 요청의 세션 토큰을 통해 각 사용자의 신원 및 상호 작용 상태를 확인한 후 사용자의 요청에 대한 동의 여부를 결정할 수 있습니다.

일반적인 액세스 제어 요구 사항은 상대적으로 복잡하고 각 역할에는 서로 다른 권한이 있으며 각 사용자는 애플리케이션의 일부 데이터 및 기능에만 액세스할 수 있으므로 일반적으로 여기에는 많은 허점이 있습니다. 무단 액세스를 유발할 수 있는 메커니즘입니다.

입력 처리

모든 사용자 입력은 신뢰할 수 없습니다. 웹 애플리케이션에 대한 대부분의 공격은 공격자가 특별히 구성한 입력과 관련되어 있으므로 사용자 입력을 안전하게 처리하는 것이 애플리케이션 보안을 보장하는 열쇠입니다.

입력의 다양성

웹 애플리케이션은 길이 제한, 문자 제한 등과 같은 일부 특수 입력에 대해 매우 엄격한 검사를 수행할 수 있으며 때로는 사용자가 제출한 입력을 수락하고 양식 필드와 쿠키를 숨겨야 할 수도 있습니다. 서버에서 생성되어 클라이언트로 다시 전송되고, 이 과정에서 공격자는 이를 확인하고 수정할 수 있습니다.

입력 처리 방법

상황에 따라 다양한 처리 방법을 사용하거나 조합하여 사용하세요.

1. 블랙리스트

블랙리스트에는 공격에 사용될 문자열이나 패턴이 포함되어 있습니다.

블랙리스트는 입력 확인에 가장 효과적인 방법입니다. 두 가지 이유가 있습니다.

1) 다양한 인코딩이나 다른 형태의 표현을 통해 사용자 입력을 우회할 수 있습니다. 예를 들어 동일한 효과를 갖는 일부 문자가 누락될 수 있습니다. 예를 들어, 경고('xss')가 차단되면 프롬프트('xss')도 사용할 수 있습니다. 예를 들어 웹 응용 프로그램 방화벽은 종종 문자열이 관리형에서 다르게 처리되기 때문입니다. 그리고 관리되지 않는 상황.

2) 기술의 급속한 발전으로 인해 취약점을 악용하는 몇 가지 새로운 방법이 등장했습니다.

2. 화이트리스트

화이트리스트에는 일련의 양성 문자열, 패턴 또는 표준 세트가 포함됩니다. 화이트리스트와 일치하지 않는 모든 데이터는 차단됩니다.

화이트리스트 지정 시 안전한 문자열만 남게 되고 공격자가 입력을 구성할 수 없기 때문에 화이트리스트는 입력 확인에 가장 효과적인 방법입니다.

하지만 화이트리스트에는 제한이 있습니다. 많은 경우 웹 애플리케이션은 보안 표준을 충족하지 않는 일부 문자를 허용해야 합니다. 예를 들어, 애플리케이션은 사용자가 실제 이름으로 등록하도록 요구하지만 이름에는 데이터베이스에 대한 공격을 일으킬 수 있는 일부 하이픈, 아포스트로피 및 기타 문자가 포함되어 있습니다. . 따라서 화이트리스트에는 제한이 있으며 안전하지 않은 입력에 대한 보편적인 솔루션이 아닙니다.

3. 정제

이 방법은 보안을 보장할 수 없는 일부 데이터 입력을 허용하지만 삭제, 이스케이프, 인코딩 등을 정제하는 문제를 해결합니다.

정화는 다음과 같이 사용할 수 있습니다. a 이는 일반적인 방법이지만, 입력 항목이 여러 가지 악성 데이터를 수용해야 하는 경우 효과적으로 진화할 수 있다는 점에 유의해야 한다. 이 경우 경계 확인이 필요합니다.

4. 안전한 데이터 처리

사용자가 제출한 데이터를 안전하지 않은 방식으로 처리하는 것은 많은 웹 애플리케이션 취약점의 근본 원인입니다.

안전한 데이터 처리 방법은 사용자가 입력한 데이터를 확인하는 것에 대해 걱정할 필요가 없으며 대신 처리 과정의 절대적인 보안을 보장합니다. 예를 들어 SQL 삽입을 방지하기 위한 매개변수화된 쿼리입니다.

그러나 이 방법은 웹 애플리케이션이 수행해야 하는 모든 작업에 적용되는 것은 아닙니다. 해당되는 경우 악성 입력을 처리하는 일반적인 방법입니다.

5. 논리 검사

일부 취약점에서는 공격자의 입력이 일반 사용자의 입력과 정확히 동일하지만 이 경우 위의 메커니즘은 거의 완전히 효과가 없습니다. 예를 들어, 다른 사용자 계정에 액세스하기 위해 숨겨진 양식 필드를 수정하여 제출된 계정을 공격합니다. 이 시점에서는 어떠한 입력 확인으로도 공격자의 데이터와 일반 사용자의 데이터를 구별할 수 없습니다. 무단 액세스를 방지하려면 애플리케이션은 제출된 계정이 이전에 계정을 제출한 사용자의 것인지 확인해야 합니다.

경계 확인

핵심 보안 문제(모든 사용자 입력을 신뢰할 수 없음)의 특성을 고려하여 인터넷(신뢰할 수 없음)과 서버 애플리케이션(신뢰할 수 있음) 사이에 경계를 설정한 다음, 경계에서 인터넷을 통해 정제된 데이터를 서버 애플리케이션에 전달합니다. 위 내용은 단순 경계 확인으로, 실제 취약점 분석 시 이러한 단순 입력 확인만으로는 부족함을 알 수 있었다.

애플리케이션이 수행하는 기능의 폭과 채택된 기술의 다양성을 기반으로 일반적인 애플리케이션은 각각 완전히 다른 유형의 특별히 설계된 데이터를 사용할 수 있는 수많은 다양한 입력 공격을 방어해야 합니다. 모든 공격을 방어하기 위해 외부 경계에 간단한 메커니즘을 구축하는 것은 어렵습니다.

다양한 애플리케이션 기능은 일련의 서로 다른 프로세스를 결합하도록 설계되었습니다. 사용자의 한 입력은 이전 작업의 출력이 후속 작업에 사용되는 여러 구성 요소에서 많은 작업을 수행할 수 있습니다. 데이터가 원래 입력과 완전히 다르게 변환됩니다. 그러나 숙련된 공격자는 이러한 차이점을 이용하여 중요한 단계에서 악성 데이터를 생성하고 데이터를 수신하는 구성 요소를 공격할 수 있습니다. 따라서 외부 경계에 모든 공격을 방어할 수 있는 간단한 메커니즘을 구축하는 것은 어렵습니다.

국경 확인이 더 효율적인 모델입니다. 여기서의 경계는 더 이상 인터넷과 웹 애플리케이션 간의 경계로 제한되지 않습니다. 웹 애플리케이션의 각 구성 요소 또는 기능 단위에는 경계가 있습니다. 이러한 방식으로 각 구성 요소는 수신하도록 특별히 설계된 특정 유형의 입력으로부터 자신을 방어할 수 있습니다. 데이터가 서로 다른 구성 요소를 통과할 때 이전에 생성된 데이터에 대해 유효성 검사를 수행할 수 있으며, 서로 다른 처리 단계에서 서로 다른 유효성 검사가 수행되므로 서로 충돌할 가능성이 없습니다.

예를 들어 아래 그림은 다음과 같습니다.

다단계 확인 및 정규화

확인 확인 프로세스 중에 사용자의 입력을 여러 단계로 처리해야 하는 경우 입력 메커니즘에서 자주 발생하는 문제가 발생합니다. . 이 문제는 애플리케이션이 특정 문자를 제거하거나 인코딩하여 사용자 입력을 삭제하려고 할 때 발생합니다. 이 문제를 주의 깊게 처리하지 않으면 공격자는 악성 데이터가 확인 메커니즘을 성공적으로 우회할 수 있도록 특수한 입력을 구성할 수 있습니다. 예를 들어 이중 쓰기 우회 및 단계 실행 시퀀스 우회가 있습니다.

데이터 정규화는 또 다른 문제를 야기합니다. 일반적이지 않은 일부 문자 및 바이너리 데이터를 http를 통해 전송하기 위해서는 일반적으로 인코딩을 통해 정규화됩니다. 그러나 필터링을 구현한 후 디코딩을 수행하면 공격자는 인코딩을 통해 확인 메커니즘을 피할 수 있습니다.

웹 응용 프로그램에서 사용하는 표준 인코딩 체계 외에도 응용 프로그램의 구성 요소가 데이터를 한 문자 집합에서 다른 문자 집합으로 변환하는 경우 정규화 문제가 발생할 수도 있습니다. 예를 들어 Ÿ와 Â는 Y와 A로 변환됩니다. 공격자는 차단된 문자와 키워드를 전송하기 위해 이 방법을 자주 사용합니다.

다단계 확인과 표준화로 인해 발생하는 문제를 피하기 어려울 때가 있으며 이러한 문제에 대한 단일 솔루션은 없습니다. 일반적으로 잘못된 입력을 삭제하는 것을 피하고 대신 그러한 입력을 모두 거부하는 것이 어떻게 가능합니까?

공격에 대한 대응

공격자의 침입을 막기 위해 최선을 다했지만 절대적으로 안전한 시스템은 없습니다. 보안 사고가 발생하면 웹 애플리케이션은 일반적으로 공격에 어떻게 대응해야 할까요?

1. 예상치 못한 오류 처리

2. 명백한 공격을 자동으로 차단

4. 프로그램 액세스 로그 유지

응용 프로그램의 핵심 메커니즘은 다음과 같습니다. 예상치 못한 오류를 처리하는 방법. 일반적으로 프로덕션 환경에서 애플리케이션은 시스템 생성 정보나 기타 디버깅 정보를 사용자에게 반환해서는 안 됩니다. 이 정보는 공격자에게 다음 공격에 대한 좋은 참조 정보를 제공합니다. 그리고 예상치 못한 오류는 종종 프로그램 방어 메커니즘의 결함을 지적합니다. 오류 처리 메커니즘은 종종 로깅 메커니즘과 통합됩니다.

공격에 대응

많은 공격은 다수의 일반적인 악성 문자를 전송합니다. 이러한 경우 애플리케이션은 공격자가 감지하지 못하도록 자동 대응 조치를 취해야 합니다. 예를 들어 세션 종료, 재로그인 요구, IP 차단 등을 수행할 수 있습니다.

로그 유지

로그는 침입을 기록하며, 침입 후에도 침입 프로세스를 복원할 수 있습니다.

중요한 애플리케이션 로그에는 모든 요청이 기록되어야 합니다. 일반적으로 다음 항목을 포함해야 합니다.

1. 로그인 성공 또는 실패, 비밀번호 변경 등 모든 인증 관련 이벤트

2. 전송 등 주요 작업

3. 액세스 제어 요청

4. 알려진 공격 문자열 포함

로그에는 각 이벤트의 시간, IP 및 사용자 계정이 기록됩니다. 로그는 무단 읽기로부터 엄격하게 보호되어야 합니다. 쓰기, 수정 등

로그는 공격 표면이 될 수도 있습니다. 예를 들어 승인 없이 액세스할 수 있는 로그는 공격자에게 세션 토큰 및 요청 매개변수와 같은 민감한 정보를 제공합니다.

관리자에게 경고

핵심 문제는 긍정 오류와 부정 오류이며, 이는 경고 메커니즘과 확인 메커니즘 및 기타 제어 방법을 결합하여 개선할 수 있습니다.

일반적으로 모니터링되는 비정상적인 이벤트는 다음과 같습니다.

1. IP에서 대량의 요청을 받는 등의 애플리케이션 이상

2. 은행 계좌 입출금과 같은 거래 이상 숫자가 비정상입니다

3. 알려진 공격 문자열이 포함되어 있습니다

4. 일반 사용자가 볼 수 없는 요청의 데이터가 수정되었습니다

관리 애플리케이션

관리 프로그램을 통해 관리자가 사용자 계정 및 역할, 애플리케이션을 관리할 수 있습니다. 모니터링 및 감사 기능을 수행하고, 진단 작업을 수행하고, 애플리케이션의 다양한 기능을 구성합니다.

관리 메커니즘은 애플리케이션의 주요 공격 표면 중 하나이며 관리 메커니즘은 종종 매우 높은 권한을 갖습니다. 관리 메커니즘을 제어하는 ​​것은 애플리케이션을 제어하는 ​​것입니다. 게다가 관리 메커니즘에는 명백한 허점과 민감한 기능이 있는 경우가 많습니다. 관리자 권한을 얻는 취약점은 일반적으로 무단 액세스, 취약한 비밀번호 등 사용자 액세스 메커니즘에서 발생합니다. 관리 백그라운드에서 일반 사용자가 보낸 요청을 처리할 수 있는 경우 백그라운드에서 맹목적으로 XSS 취약점을 입력하려고 시도할 수 있습니다.

위 내용은 웹 애플리케이션의 핵심 방어 메커니즘은 무엇인가?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!