Htacess Helicon APE 거짓 긍정 403 실패

Htacess Helicon APE 거짓 긍정 403 실패

web.config재작성 규칙을 사용하는 대신헬리콘 에이프Apache의 .htaccess기능을 에뮬레이트하기 위한 것입니다.

.htaccess통합, 삭제 등과 같은 명령 전달에 대한 액세스를 제한하는 기능의 일부로 서버 전체에 적용되는 큰 범용 파일이 있습니다 .

그러나 코드 줄이 거짓 긍정을 생성하고 다른 경우에는 적절한 URL에 대한 액세스를 차단하는 문제에 직면했습니다.

실패한 URL은 다음과 같습니다.http://example.com/union-contracts

에서 아래 명령을 사용하면 web.config누락된 모든 URL이 로 푸시됩니다 index.php.

   <httpErrors errorMode="Custom" existingResponse="Replace">
        <remove statusCode="404" subStatusCode="-1" />
        <error statusCode="404" path="/index.php" responseMode="ExecuteURL" />
    </httpErrors>

403을 반환하는 htaccess 규칙

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC]
RewriteRule . - [F,L]

궁극적으로, 예를 들어 결합을 계속 차단하고 싶습니다. 오탐에 대한 줄을 수정하면 됩니다. 나는 내 규칙 -contracts에 하드 코딩되는 것을 원하지 않는다는 점에 유의하십시오 ..htaccess

처음에 URL이 어떻게 생성되는지 기억한 후 XAMPP의 htaccess에서 문제를 복제할 수 있었습니다.

웹사이트 방문자 측에서 URL에 액세스하면 서버에서 404 오류가 발생합니다. URL을 마지막 부분까지 필터링하고 해당 문자열에 대해 데이터베이스를 확인하여 저장된 URL과 일치하는지 확인합니다. 그렇다면 해당 404를 브라우저에 전달하지 않고 URL이 '할 수 있는 경우에만 전달됩니다. 찾을 수 없습니다.

IIS가 404 오류를 생성하면 URL은 다음과 같습니다.

index.php?404;http://example.com:80/union-contracts

그러나 해당 형식으로는 브라우저에 전달되지 않습니다.

답변1

"뭔가 다른 일"이 벌어지고 있는 게 분명하다는 우려를 댓글로 표현했지만, 어쨌든...

처음부터 실행되어서는 안 되는(읽기: "할 수 없음") 규칙에 대한 예외를 작성하는 것은 어렵습니다. 이는 완전한 추측 작업입니다. 결국, 왜 그럴까요?예외영광이요?

해당 규칙은 몇 가지 "큰" 이유로 이미 주어진 요청을 피해야 합니다.

  1. 요청에 쿼리 문자열이 포함되어 있지 않습니다.
  2. 조건의 정규식(조건 패턴)은 URL의 어떤 부분과도 일치하지 않습니다(쿼리 문자열에 있더라도).

위의 #2를 고려하면 정규식에는 이미 주어진 요청과 일치하지 않는 충분한 예외가 포함되어 있습니다. 그렇다면 "다른" 예외를 어떻게 구현할 수 있습니까?

당신은조건 패턴-단어 "union" 뒤에 하이픈( )이 오는 경우를 피하기 위해부정적인 예측. 예를 들어:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union(?!-)|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)

따라서 위의 내용은 Xunion와 일치하지만 는 일치하지 않습니다 Xunion-. 여기서 는 X첫 번째 문자 시퀀스 중 하나입니다.교대그룹(예: (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00)).

또는 다음 키워드 뒤에 하이픈이 오는 경우:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)(?!-)


(업데이트:다음 두 가지 제안은 아마도 작동하지 않을 것입니다. 왜냐하면 지시문은 처리만 되는 것 같기 때문입니다.~ 후에IIS가 이미 URL을 다시 작성했습니다. 이 시점에서 URL 경로는 단순히 /index.php가 아니라 입니다 /union-contracts.)

또는 RewriteRuleURL 경로가 다음과 같이 시작될 때 일치하지 않도록 수정하십시오 /union-(이렇게 하면 규칙이 차단하려고 하는 XSS 시도에 대한 백도어가 잠재적으로 제공되지만). 예를 들어:

RewriteRule !^/?union- - [F]

(적어도 Apache에서는 플래그를 사용할 L때 플래그가 필요하지 않습니다 . 이는 암시적입니다.)F

또는 다음 위치에서 다른 규칙을 생성합니다.맨 위, 기존 규칙 앞에 시작하고 쿼리 문자열이 없는 URL을 요청할 때 예외를 생성합니다 /union-(다른 규칙을 믿는다면 모순되는 것처럼 보이지만). 예를 들어:

RewriteCond %{QUERY_STRING} ^$
RewriteRule ^/?union- - [L]

그러나 파일의 뒷부분에 어떤 방식으로든 URL을 다시 작성해야 하는 다른 규칙이 있는 경우 요청이 "중단"될 수 있습니다. 이러한 규칙은 발생하지 않기 때문입니다.

나는 Helicon-APE/mod_rewrite가 다음에서 작동한다고 가정합니다.디렉토리형컨텍스트(예: .htaccess스타일 구문과 반대되는 스타일 구문)섬기는 사람또는가상호스트문맥)? 비록 그것이 위의 지시문에 영향을 주어서는 안 되지만, 실제로는 그렇습니다.


업데이트:IIS가 404 오류를 생성하면 URL은 다음과 같습니다.

index.php?404;http://example.com:80/union-contracts

아 예! 해당 URL~ 할 것이다원래 상태에 사로잡히다. 그래서 mod_rewrite 지시문이 처리된 것 같습니다.~ 후에web.config에서 IIS를 "다시 작성"합니다! 이로 인해 이러한 "보안" 지시문은 다소 불필요하거나 심지어 부정확하게 됩니다.추정된클라이언트의 초기 요청에 따라 실행됩니다. 그리고....

URL의 마지막 부분만 필터링하고 해당 문자열과 데이터베이스를 비교하여 저장된 URL과 일치하는지 확인합니다.

URL을 적극적으로 구문 분석하고 필요한 부분만 필터링하므로 적어도 이러한 "404" 요청에 대해서는 이러한 "보안" 검사가 중복되는 것처럼 보입니다. (실제로 잠재적으로 직접 요청할 수 있는 실제 파일(예: 404가 아닌 요청)에 따라 이러한 성격의 악의적인 쿼리 문자열이 현실적으로 모든 URL에 보안 위협을 가할 수 있습니까?)

위의 두 가지 제안은상태"union" 키워드 뒤에 하이픈이 오는 경우 인스턴스를 제외하려면, 또는어느키워드는 여기에 여전히 적용되며 즉각적인 문제를 해결하는 것처럼 보입니다.

또한 양식의 URL이 index.php?404;발견되면(예: IIS에서 URL을 다시 작성한 후) 모든 검사를 중단할 수도 있습니다. (모든 mod_rewrite 지시문이 유사한 "보안" 검사라고 가정합니까?)

예를 들어 다음을맨 위.htaccess스크립트 의~ 전에기존 지시어:

RewriteCond %{QUERY_STRING} ^404;
RewriteRule ^/?index\.php - [L]

이렇게 하면 양식의 URL이 /index.php?404;......발견될 때 추가 처리가 방지됩니다. (어쨌든 스크립트에서 URL을 구문 분석하고 있기 때문입니다.)

관련 정보