OTG-AUTHN-004 (인증 스키마를 우회하기 위한 테스트)


개요

대부분의 응용 프로그램은 개인 정보에 액세스하거나 작업을 실행하기 위해 인증을 요구하지만 모든 인증 방법이 적절한 보안을 제공 할 수있는 것은 아닙니다. 보안 위협에 대한 과실, 무지 또는 단순한 과소 평가는 종종 로그인 페이지를 건너 뛰고 인증이 수행 된 후에 만 ​​액세스해야하는 내부 페이지를 직접 호출하여 우회 할 수있는 인증 체계를 초래합니다.

또한 요청을 변조하고 사용자가 이미 인증되었다고 생각하도록 응용 프로그램을 속여서 인증 조치를 무시할 수도 있습니다. 이는 주어진 URL 매개 변수를 수정하거나 양식을 조작하거나 세션을 위조하여 수행 할 수 있습니다.

인증 스키마와 관련된 문제는 설계, 개발 및 배포 단계와 같이 소프트웨어 개발 라이프 사이클 (SDLC)의 여러 단계에서 확인할 수 있습니다. 설계 단계에서 오류는 보호해야 할 응용 프로그램 섹션의 잘못된 정의, 자격 증명의 전송을 보호하기위한 강력한 암호화 프로토콜을 적용하지 않는 선택 등을 포함 할 수 있습니다. 개발 단계에서 오류는 입력 유효성 검사 기능의 잘못된 구현을 포함하거나 특정 언어에 대한 보안 모범 사례를 따르지 않을 수 있습니다. 응용 프로그램 배포 단계에서 필요한 기술 기술이 부족하거나 좋은 설명서가 없기 때문에 응용 프로그램 설치 중 (설치 및 구성 작업)에 문제가 있을 수 있습니다.


테스트 방법


Black Box testing

웹 어플리케이션에서 사용되는 인증 스키마를 우회하는 방법은 여러가지 있습니다.

  • 직접 페이지 요청 (강제 브라우징)
  • 파라미터 수정
  • 세션 ID 예측
  • SQL 인젝션

직접 페이지 요청 (강제 브라우징)

만약 웹 어플리케이션이 페이지에서의 로그인만 접근 제어를 구현해두었다면, 인증 스키마는 우회될 것입니다. 예를 들어, 사용자가 직접 강제 브라우징을 통해 다른 페이지를 요청하면, 해당 페이지는 접속 권한을 부여하기 전에 사용자의 자격 증명을 확인하지 않을 수 있습니다. 이 방법을 사용한 테스트는 브라우저에 주소 창을 통해 보호된 페이지를 직접 접근하는 시도입니다.


파라미터 수정

인증 설계와 관련된 또 다른 문제점은 응용 프로그램이 고정 값 매개 변수를 기반으로 성공적인 로그인을 검증 할 때입니다. 사용자는 유효한 자격 증명을 제공하지 않고 보호 된 영역에 액세스하기 위해 이러한 매개 변수를 수정할 수 있습니다. 아래 예제에서는 "인증 된"매개 변수가 "예"값으로 변경되어 사용자가 액세스 할 수 있습니다. 이 예에서 매개 변수는 URL에 있지만 프록시가 매개 변수를 수정하는 데 사용될 수도 있습니다. (특히 매개 변수가 POST 요청의 양식 요소로 전송되거나 매개 변수가 쿠키에 저장되는 경우)

http://www.site.com/page.asp?authenticated=no
raven@blackbox /home $nc www.site.com 80
GET /page.asp?authenticated=yes HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 10:22:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>

세션 ID 예측

많은 웹 응용 프로그램은 세션 식별자 (세션 ID)를 사용하여 인증을 관리합니다. 따라서 세션 ID 생성이 예측 가능한 경우 악의적 인 사용자는 유효한 세션 ID를 찾고 해당 응용 프로그램에 대한 무단 액세스를 획득하여 이전에 인증 된 사용자를 가장 할 수 있습니다.

다음 그림에서 쿠키 내 값은 선형 적으로 증가하므로 공격자가 유효한 세션 ID를 쉽게 추측 할 수 있습니다.

다음 그림에서 쿠키 내의 값은 부분적으로 만 변경되므로 총계 공격을 아래 표시된 정의 된 필드로 제한 할 수 있습니다.

SQL 인젝션

SQL 인젝션은 널리 알려진 공격 기술입니다. 이 섹션에서는이 섹션의 범위를 벗어나는 사출 기술에 대해 설명하는 몇 가지 섹션이 있으므로이 기술을 자세히 설명하지는 않습니다.

다음 그림은 간단한 SQL 인젝션 공격으로 인증 양식을 무시할 수 있음을 보여줍니다.


Gray Box Testing

공격자가 이전에 발견 된 취약점 (예 : 디렉토리 통과)을 이용하거나 웹 저장소(오픈 소스 응용 프로그램)를 이용하여 응용 프로그램 소스 코드를 검색 할 수있는 경우 인증 구현에 대해 세련된 공격을 수행 할 수 있습니다 방법.

다음 예제 (PHPBB 2.0.13 - 인증 우회 취약점)의 5 행에서 unserialize () 함수는 사용자가 제공 한 쿠키를 파싱하고 $ row 배열 내에 값을 설정합니다. 10 행에서 백 엔드 데이터베이스에 저장된 사용자의 MD5 암호 해시가 제공된 암호 해시와 비교됩니다.

if ( isset($HTTP_COOKIE_VARS[$cookiename . ‘_sid’]) ||
{
    $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename. ‘_data’] ) ?

    unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename. ‘_data’])) : array();
    $sessionmethod = SESSION_METHOD_COOKIE;
}

if( md5($password) == $row[‘user_password’] && $row[‘user_active’] )
{
    $autologin = ( isset($HTTP_POST_VARS[‘autologin’]) ) ?
    TRUE : 0;
}

PHP에서 문자열 값과 부울 값 (1 - "TRUE") 간의 비교는 항상 "TRUE"이므로 unserialize() 함수에 다음 문자열(중요한 부분은 "b:1"임) 인증 제어를 우회 할 수 있습니다.

a:2:{s:11:”autologinid”;b:1;s:6:”userid”;s:1:”2”;}

도구

  • WebScarab
  • WebGoat
  • OWASP Zed Attack Proxy (ZAP)

참고 문헌

Whitepapers

  • Mark Roxberry: “PHPBB 2.0.13 vulnerability”
  • David Endler: “Session ID Brute Force Exploitation and Prediction”