소개
Nikto 는 인기 있는 오픈 소스 웹 서버 스캐너로, 6,700 개 이상의 잠재적으로 위험한 파일/프로그램, 1,250 개 이상의 서버에 대한 최신 버전 확인, 270 개 이상의 서버에 대한 버전별 문제 등 다양한 항목에 대해 웹 서버를 포괄적으로 테스트합니다.
때때로 웹 애플리케이션은 요청에 특정 HTTP 헤더가 포함되어야 합니다. 이는 인증 (API 키 또는 세션 토큰과 같은), 특정 버전의 애플리케이션으로 라우팅 또는 디버그 모드 활성화와 같은 목적일 수 있습니다. 표준 Nikto 스캔은 필요한 헤더가 없기 때문에 이러한 시나리오에서 실패하거나 불완전할 수 있습니다.
이 랩에서는 Nikto 의 -addheaders 옵션을 사용하여 사용자 정의 헤더를 스캔에 포함하는 방법을 배우게 됩니다. 이를 통해 특정 헤더 요구 사항이 있는 애플리케이션을 테스트하여 보다 철저하고 정확한 보안 평가를 보장할 수 있습니다.
애플리케이션에서 요구하는 사용자 정의 HTTP 헤더 식별
이 단계에서는 간단한 웹 애플리케이션과 상호 작용하여 사용자 정의 헤더가 왜 필요한지 이해합니다. 저희는 8000 포트에서 실행되는 웹 서버를 가지고 있으며, 접근을 위해 X-LabEx-Auth라는 특정 헤더를 요구합니다.
먼저, curl 명령을 사용하여 사용자 정의 헤더 없이 웹 애플리케이션에 접근해 보겠습니다.
curl http://127.0.0.1:8000
필요한 헤더가 누락되었기 때문에 "Access Denied" 메시지를 받게 됩니다.
Access Denied
이제 요청을 다시 보내되, 이번에는 curl의 -H 옵션을 사용하여 필요한 사용자 정의 헤더를 포함하겠습니다. 헤더는 X-LabEx-Auth이며 값은 SecretToken입니다.
curl -H "X-LabEx-Auth: SecretToken" http://127.0.0.1:8000
이번에는 서버에서 접근을 허용하고 환영 메시지를 반환합니다. 이는 애플리케이션이 이 특정 헤더를 확인한다는 것을 확인시켜 줍니다.
Welcome, authorized user! The server is Apache/2.4.1 (Unix).
이 과정은 보안 스캔을 실행하기 전에 사용자 정의 헤더의 필요성을 식별하고 확인하는 방법을 보여줍니다.
-addheaders 옵션을 사용하여 헤더 및 값 지정
이 단계에서는 Nikto 옵션을 사용하여 스캔에 사용자 정의 헤더를 추가하는 방법을 배웁니다.
이제 사용자 정의 헤더가 필요하다는 것을 알았으므로 Nikto 에게 모든 HTTP 요청에 이를 포함하도록 알려야 합니다. Nikto 는 이 목적을 위해 -addheaders 옵션을 제공합니다.
구문은 간단합니다.
-addheaders "HeaderName:HeaderValue"
HeaderName을 헤더 이름 (예: X-LabEx-Auth) 으로, HeaderValue를 해당 값 (예: SecretToken) 으로 바꿉니다.
여러 사용자 정의 헤더를 추가해야 하는 경우 줄 바꿈 문자 (\n) 로 구분할 수 있습니다. 예를 들면 다음과 같습니다.
-addheaders "Header1:Value1\nHeader2:Value2"
현재 시나리오에서 대상 애플리케이션을 스캔하기 위한 완전한 Nikto 명령 구조는 다음과 같습니다. 이 단계에서는 명령을 실행하지 않고 구문을 이해하기 위해 구성만 한다는 점에 유의하십시오.
nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"
이 명령은 Nikto 에게 http://127.0.0.1:8000의 호스트를 대상으로 지정하고 스캔 중에 보내는 모든 요청에 X-LabEx-Auth: SecretToken 헤더를 추가하도록 지시합니다.
사용자 정의 헤더를 포함하여 스캔 실행
이 단계에서는 방금 배운 -addheaders 옵션을 사용하여 Nikto 스캔을 실행합니다.
올바른 명령을 구성했으므로 이제 스캔을 실행할 차례입니다. 이를 통해 Nikto 는 인증되지 않은 사용자에게는 보이지 않는 취약점을 잠재적으로 발견하면서 권한 있는 사용자로 애플리케이션과 상호 작용할 수 있습니다.
터미널에서 다음 명령을 실행하십시오.
nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"
이제 Nikto 가 스캔을 시작합니다. 모든 요청에 X-LabEx-Auth: SecretToken 헤더가 포함되어 있으므로 웹 애플리케이션은 이를 성공적으로 처리합니다. Nikto 의 출력을 관찰하십시오. 서버를 식별하고 다양한 취약점에 대한 테스트를 시작합니다.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 127.0.0.1
+ Target Hostname: 127.0.0.1
+ Target Port: 8000
+ Start Time: ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 Python/3.10.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI directories found (use '-C all' to force check all possible dirs)
+ "Allowed HTTP Methods: HEAD, OPTIONS, GET"
+ OSVDB-3233: /: Found a default page.
...
+ 15 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time: ...
---------------------------------------------------------------------------
+ 1 host(s) tested
핵심은 헤더가 없는 스캔은 애플리케이션에 의해 차단되는 반면, 이 스캔은 성공적으로 실행된다는 것입니다.
프록시 도구를 사용하여 헤더가 전송되는지 확인
이 단계에서는 Nikto 가 실제로 사용자 정의 헤더를 요청과 함께 보내고 있는지 확인합니다. 일반적으로 Burp Suite 또는 OWASP ZAP 와 같은 전문 도구가 사용되지만, 간단한 netcat (nc) 리스너로 프록시를 시뮬레이션할 수 있습니다.
먼저 두 번째 터미널을 열어야 합니다. 터미널 패널의 탭 바에서 "+" 아이콘을 클릭하여 이 작업을 수행할 수 있습니다.
새 터미널 탭에서 포트 (예: 8888) 에 netcat 리스너를 시작합니다. 이 리스너는 수신하는 데이터를 단순히 출력합니다.
nc -l -p 8888
이제 원본 터미널 탭으로 돌아갑니다. 이번에는 실제 웹 서버 대신 netcat 리스너를 가리키도록 Nikto 스캔을 다시 실행합니다. 이렇게 하면 Nikto 가 HTTP 요청을 netcat으로 보내게 되어 이를 검사할 수 있습니다.
nikto -h http://127.0.0.1:8888 -addheaders "X-LabEx-Auth: SecretToken"
명령을 실행한 후 netcat이 실행 중인 두 번째 터미널 탭으로 빠르게 전환합니다. Nikto 가 보낸 원시 HTTP 요청을 볼 수 있습니다. 출력에서 X-LabEx-Auth: SecretToken 헤더를 찾으십시오.
GET / HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.00 (Nikto/2.5.0) (Evasions:None) (Test:000001)
X-LabEx-Auth: SecretToken
Accept-Encoding: gzip,deflate
Connection: close
보시다시피 사용자 정의 헤더가 요청에 포함되어 있습니다. 이는 -addheaders 옵션이 예상대로 작동함을 확인합니다.
이제 두 번째 터미널 탭에서 Ctrl+C를 눌러 netcat 리스너를 중지한 다음 탭을 닫을 수 있습니다.
특정 헤더가 필요한 취약점 테스트
이 단계에서는 헤더 포함 및 미포함 스캔을 비교하여 사용자 정의 헤더 사용의 실제 보안 영향을 이해합니다.
부적절한 직접 객체 참조 (IDOR) 또는 권한 상승 결함과 같은 많은 취약점은 애플리케이션의 인증된 섹션에만 존재합니다. 올바른 인증 헤더를 제공하지 않는 스캔은 이러한 문제를 완전히 놓치게 됩니다.
이를 설명하기 위해 먼저 사용자 정의 헤더 없이 웹 서버에 대한 Nikto 스캔을 실행합니다. 이는 인증되지 않은 공격자가 수행하는 스캔을 시뮬레이션합니다.
nikto -h http://127.0.0.1:8000
Nikto 가 실행되지만 보내는 모든 요청은 "Access Denied" 응답을 받게 됩니다. 스캐너는 초기 권한 부여 검사를 통과할 수 없기 때문에 애플리케이션을 제대로 분석할 수 없습니다. 이러한 스캔의 결과는 제한적인 가치를 가집니다.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 127.0.0.1
+ Target Hostname: 127.0.0.1
+ Target Port: 8000
+ Start Time: ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 Python/3.10.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ "Allowed HTTP Methods: GET, HEAD, OPTIONS"
+ OSVDB-3233: /: The site returned a 403 Forbidden, this may indicate that it's a default file.
...
3 단계에서 실행한 성공적인 스캔 (헤더 사용) 과 비교하면 차이를 알 수 있습니다. 사용자 정의 헤더가 있는 스캔은 애플리케이션의 핵심 로직과 상호 작용할 수 있었고 (curl에서 본 "Welcome" 메시지로 표시됨) 의미 있는 테스트를 수행할 수 있었습니다. 헤더가 없는 스캔은 입구에서 차단되었습니다.
이는 취약점 스캔이 가능한 한 포괄적이도록 사용자 정의 헤더 사용의 중요성을 강조합니다.
요약
이 실습에서는 Nikto 를 사용하여 효과적인 웹 애플리케이션 보안 평가를 수행하는 중요한 기술을 배웠습니다.
다음 작업을 성공적으로 수행했습니다.
curl을 사용하여 애플리케이션의 사용자 정의 HTTP 헤더 요구 사항을 식별했습니다.- Nikto 의
-addheaders옵션 구문을 배웠습니다. - 사용자 정의 헤더를 포함한 Nikto 스캔을 수행하여 인증된 액세스를 얻었습니다.
netcat리스너를 사용하여 사용자 정의 헤더가 올바르게 전송되고 있는지 확인했습니다.- 사용자 정의 헤더를 사용한 스캔이 그렇지 않으면 놓칠 수 있는 취약점을 어떻게 발견할 수 있는지 이해했습니다.
이 기술은 인증, 상태 관리 및 기타 기능을 위해 헤더에 의존하는 현대적이고 복잡한 웹 애플리케이션에 대한 보다 철저한 테스트를 가능하게 하므로 모든 보안 전문가에게 필수적입니다.
