it-swarm-korea.com

보안 검토 : "HTTP 헤더 사용자 에이전트가 (무언가)로 설정되었습니다"

우리는 PHP 코드에 대한 보안 검토를 받았으며 팀원들은 보고서에서 (다른 것들 중에서) 이것을 권고했습니다.

/appdir/ 

Details
The HTTP header user-agent has been set to \" . 

Request
GET /appdir/ HTTP/1.0 
Accept: */* 
User-Agent: \" 
Host: localhost 
Cookie: PHPSESSID=08rtvlq03bd9d57qor4abjg7q4 
Connection: Close 
Pragma: no-cache 

Response
HTTP/1.1 200 OK 
Date: Sat, 18 Dec 2010 09:35:40 GMT 
Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_Perl/2.0.4 Perl/v5.10.1 
X-Powered-By: PHP/5.3.1 
Expires: Thu, 19 Nov 1981 08:52:00 GMT 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Pragma: no-cache 
Connection: close 
Content-Type: text/html

HTTP 헤더 user-agent를\"로 설정할 수 있습니까?

11
siliconpi

user-agent (또는 그 문제에 대한 참조 자) 값으로의 주입은 여러 가지 방법으로 잠재적 위협이 될 수 있지만 현재 상황이 실제로 시스템의 더 큰 그림을 보지 않으면 취약점을 파악하기가 어렵습니다.

나는 종종 어떤 방식 으로든 사용자 에이전트를 사용하는 시스템을 본다. 종종 가장 많이 사용되는 브라우저 및 유사한 정보를 저장하는 데 사용됩니다. 봇으로 알려진 사용자 에이전트가 다르게 취급되는 경우가 있습니다. 많은 경우가 있습니다.

주사

User-agent 필드에서 XSS 공격이 시도되는 것은 드문 일이 아닙니다. 예를 들어, 얼마 전에 테스트했던 사이트는 나에 대한 정보를 조금 보여주었습니다.

흥미로운 점은 사용자 에이전트를 다시 출력했다는 것입니다. 사용자 에이전트 'FooBar"> <img src="javascript:alert('document.cookie')'을 (를) 주입했을 때 다시 경고했습니다.

이제이 공격을 다른 사용자에게 적용하기 위해이 사이트에는 하루에 평균 사용자 수, 가장 일반적인 브라우저 등을 보여주는 통계 페이지도있었습니다. 숫자는 요청 수를 기반으로 한 것 같습니다. 내 XSS로 충분한 요청을 한 빠른 스크립트를 작성하면 단순히 내 사용자 에이전트를 상위 100 개 목록에 올릴 수 있으며 벡터는 이제 영구적이며 다른 사용자에 대해 작동합니다.

SQL 인젝션에도 같은 일이 가능합니다. useragent Im Harmless";DROP TABLE users. 어쩌면 일부 시스템이 손상되었을 수 있습니다.

취약점 조사

예에서와 같이/"를 던져서 어떤 일이 발생하는지 확인하십시오. 오류 메시지가 표시되거나 사이트의 다른 곳에서 문제가 발생했을 수 있습니다.

아주 오래된 사용자 에이전트 나 검색 엔진 사용자 에이전트를 사용하는 경우 어떻게되는지 확인하는 것이 때로는 매우 유용 할 수 있습니다. 때때로 이것은 사이트의 일부 컨텐츠를 잠금 해제하고 해당 컨텐츠를 취약성으로 조사하는 유일한 방법입니다.

예를 들어 Burpsuite 를 사용하면 후자가 자동화하기가 매우 쉽고 차이점에 대한 모든 다른 요청을 빠르게 찾아 볼 수 있습니다.

EDIT : 특정 예에서 요청을하는 클라이언트가 사용자 에이전트를\"로 설정 한 것 같습니다. 의도적 인 경우 버그 또는 사용자 에이전트를 숨기는 사람은 말하기가 어렵지만이 사용자의 다른 요청을 확실히 살펴볼 것입니다.

9
Chris Dale

이스케이프 된 따옴표를 사용자 에이전트 문자열에 삽입하는 것이 어떻게 취약한 지 알 수 없습니다.

나는 이것이 사실인지 확신하지 못한다. 더 많은 정보가 필요하다고 생각한다. 내가 생각할 수있는 유일한 것은 세션 납치 가능성이 있다는 것입니다.

기본적으로 PHPSESSID = 08rtvlq03bd9d57qor4abjg7q4는 다른 사용자 세션에 속하며 쿠키를 통해이 세션 ID를 스푸핑하고 사용자 에이전트가 원래 사용자에서 변경된 경우에도 정상적인 응답을받습니다.

설명:

사용자 A는 다음 User-Agent 문자열을 사용하여 웹 사이트를 엽니 다.

Mozilla Compatible (MSIE)

그런 다음 사용자 A에게 다음 세션 ID가 할당됩니다.

08rtvlq03bd9d57qor4abjg7q4

그런 다음 사용자 B (bad guy)는 쿠키에 동일한 세션 ID를 가진 쿠키를 사용하여 서버에 요청을 보냅니다. 그러나 해당 User-Agent 문자열은 다음과 같습니다.

\"

응용 프로그램은이 사용자가 동일한 사용자가 아니라는 것을 인식하고 세션을 파괴해야합니다.

나는 이것이 결코 상황인지 확실하지 않으며 사용자 에이전트를 모니터링하면 세션 하이재킹을 막을 수 없습니다. 사용자 에이전트는 쉽게 스푸핑되므로 여기에서 볼 수있는 유일한 잠재력입니다.

10
Purge

그들은 당신에게 쓸모없는 것을 팔려고합니다.

HTTP 프로토콜은 이런 종류의 것들을 허용합니다. User-Agent (AKA, "어떤 종류의 브라우저를 사용하고 있습니까?")를 "User Agent: User Agent: User Agent: Trust no one"

소프트웨어 is n't 코드 삽입 (SQL, 스크립트 등 ...)을 현대적인 방식으로 고려하면 문제가 될 수 있습니다. 그러나 모범 사례를 사용하여 소프트웨어를 작성했으며 모든 입력을 올바르게 위생 처리했으며 데이터베이스 추상화 계층 인 right?

보안을 향상시키는 방법으로, 출처, 요청 빈도, 요청 프로파일 링, 사용자 에이전트 확인, 리퍼러 페이지 확인, 모든 것을 확인하는 등 모든 것을 강화하는 보안 모니터링 기능을 제공합니다. 나는 이것이 Alex가 당신에게 (Alex의 답변의 일부에 따라) 당신에게 말하려고 한 것이라고 믿지 않습니다. HTTP를 충분히 알고있는 사람에게는 총 "no-duh"입니다. 그러나 부가 가치 보풀을 두려워하는 방법 일 것입니다.

따라서 PHP 코드를 사용하여 사용자 에이전트 문자열을 포함한 모든 입력을 올바르게 위생 처리하지 않고 DB에 삽입하고 데이터베이스 추상화 계층을 사용할 수 있다면 정말 나쁜 하루 보내세요.

free 팁을 주겠습니다. 리퍼러 헤더를 다음과 같이 설정할 수 있습니다.

Referrer: \' -- TRUNCATE `Users`

문제는 이러한 헤더를 설정할 수 있다는 것이 아니라 주소 형식으로 해당 데이터를 "이름"으로 쉽게 제출할 수 있다는 것입니다.

여기 질문이 있습니다. 사용자 에이전트 사용자가 테이블에없는 사람이 웹 사이트를 사용하지 못하게 하시겠습니까? hacker는 어쨌든 올바른 아이디어로 설정할 수 있기 때문에 어리석은 아이디어 일 것입니다.

7
Incognito

대답은 간단합니다. 먼저 정리하지 않고 응답 내용에 요청에 전달 된 헤더 값을 포함시키지 마십시오. 이를 위해 먼저 사용자가 제공 한 데이터를 정리하지 않고는 어떤 식 으로든 사용하지 마십시오. 항상 입력을 소독하십시오.

콘텐츠에 클라이언트가 전달한 헤더 값을 포함시키지 않으면이 경고를 무시해도됩니다.

2
bahamat

귀하의 웹 사이트 보안을 테스트하기 위해 고용되어 있고 많은 시간을 할애 한 사람들이 사이트를 어떻게 취약하게 만드는지 설명 할 수는 없지만 보안 취약점이라고 주장 할 수 있습니다 귀하의 사이트에서 많은 시간과 노력을 낭비한 것처럼 들립니다. 펜 테스트를 위해 스크립트 학습을 고용 한 것 같습니다.

게시 한 세부 정보에는 조언이 없습니다. 분석이 없습니다.

또한 그들이 'localhost'에 대해 테스트를하고있는 것 같다는 사실은 그들이 무엇을하고 있는지 모른다는 것을 암시합니다.

Pragma: no-cache

헤더 응답에서 코드를 작성한 사람은 HTTP도 이해하지 못한다고 제안합니다. rfc 2616 에서 :

참고 : "Pragma : no-cache as a response header (응답 헤더 필드로서의 캐시 없음)"의 의미가 실제로 지정되어 있지 않으므로 응답에서 "Cache-Control : no-cache"를 안정적으로 대체 할 수 없습니다.

2
symcbean

헤더 필드의 유효성을 검사하도록 지시하는 경우 기능 사양을 확인해야합니다.

기능 사양은 허용 가능한 동작을 정의해야합니다. 허용되는 것으로 사용자 에이전트를 정의 할 수 있습니다. 모든 사용자가 제출 한 데이터와 마찬가지로 헤더 데이터는 잠재적으로 위험합니다.

1
Bradley Kreider