ajax 함수로 호출된 파일에 대한 직접 액세스 방지

ajax 함수로 호출된 파일에 대한 직접 액세스 방지

이 질문에는 이미 답변이 있습니다.

JSON 서비스에 직접 액세스하지 않도록 하려면 어떻게 해야 합니까? (7개의 답변)

닫힘3년 전.

저는 다음과 같이 에이잭스에서 php 코드를 호출합니다.

ajaxRequest.open("GET", "func.php" + queryString, true);

get request이기 때문에 헤더를 확인하는 것만으로 누구나 알 수 있습니다.전달되는 데이터는 중요하지 않지만 매개 변수 이름을 얻는 것도 간단하므로 악용될 수 있습니다.

http://mysite/func.php에 대한 직접 액세스를 방지하고 Ajax 페이지에 대한 액세스를 허용하려면 어떻게 해야 합니까?

또, 여기에 게재되어 있는 솔루션을 시험해 보았습니다만, 기능하지 않습니다.항상 'Direct access not premitted'라는 메시지가 표시됩니다.

대부분의 Ajax 요청/프레임워크는 Ajax v Non-ajax 요청을 필터링하는 데 사용할 수 있는 특정 헤더를 설정해야 합니다.많은 프로젝트에서 응답 유형(json/html)을 결정하기 위해 사용합니다.

if( isset( $_SERVER['HTTP_X_REQUESTED_WITH'] ) && ( $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest' ) )
{
    // allow access....
} else {
    // ignore....
} 

편집: Javascript 코드에 다음과 같이 Ajax 요청으로 직접 추가할 수 있습니다.

var xhrobj = new XMLHttpRequest();
xhrobj.setRequestHeader("X-Requested-With", "XMLHttpRequest"); 

제가 사용하는 것은 PHP 세션 + 요청을 할 때마다 전송되는 해시입니다.이 해시는 서버 측의 알고리즘을 사용하여 생성됩니다.

음... 세션 시작 시 원타임패스워드를 생성하여 _SESSION에 저장하고 이를 재발송신하는 파라미터를 Ajax 콜에 추가할 수 있습니다(캡차 등).그 세션에만 유효합니다.

이렇게 하면 자동 공격으로부터 사용자를 보호할 수 있지만 사이트에 액세스할 수 있는 사람은 여전히 수동으로 이 작업을 수행할 수 있지만 더 복잡한 방법을 고안하는 기반이 될 수 있습니다.

이 스레드에서 헤더를 볼 것을 제안한 사람은 어떤 식으로든 잘못된 것입니다.요청 내의 모든 것(HTTP_REFERER, HTTP_X_REQUESTED_WITH)은 공유 비밀 정보를 포함하여 완전히 무능하지 않은 공격자에 의해 스푸핑될 수 있습니다.

사용자가 사이트에 HTTP 요청을 하는 것을 막을 수 없습니다.사용자가 세션 쿠키를 통해 사이트의 중요한 부분에 요청을 하기 전에 인증해야 합니다.사용자가 인증되지 않은 요청을 할 경우 여기서 멈추고 HTTP 403을 제공합니다.

이 예에서는 GET 요구를 하고 있기 때문에 요청의 자원 요건에 관심이 있을 것으로 생각됩니다.[2].HTTP_REFERER 또는 HTTP_X_REQUESTED_에서 간단한 건전성 검사를 수행할 수 있습니다..htaccess 규칙에 헤더가 포함되어 있어 명백히 가짜 요청(또는 로봇의 말을 듣지 않는 멍청한 검색 크롤러)을 위해 새로운 프로세스가 생성되는 것을 방지합니다.txt) 단, 공격자가 이를 조작할 경우 인증되지 않은 요청에 대해 PHP 프로세스를 가능한 한 빨리 종료해야 합니다.

[1] 클라이언트/서버 애플리케이션의 근본적인 문제 중 하나입니다.동작하지 않는 이유는 다음과 같습니다.클라이언트 앱이 서버에 대해 자신을 인증할 수 있는 방법이 있다고 가정해 보십시오. 비밀 암호든 다른 방법이든 상관없습니다.앱이 필요로 하는 정보는 앱에서 반드시 액세스할 수 있습니다(비밀번호는 앱 어딘가에 숨겨져 있습니다).그러나 사용자의 컴퓨터에서 실행되므로 사용자는 다음 정보에 액세스할 수 있습니다.앱과 서버 간의 소스, 바이너리 또는 네트워크 트래픽을 확인하기만 하면 앱이 인증되는 메커니즘을 파악하여 복제할 수 있습니다.베끼기도 할 거야아마도 그들은 당신의 앱이 무거운 작업을 할 수 있도록 영리한 해킹을 쓸 것이다(언제나 앱에 가짜 사용자 입력을 보낼 수 있다).그러나 어떤 경우에도 필요한 모든 정보를 가지고 있으며, 앱이 해당 정보를 보유하는 것을 막을 수 있는 방법은 없습니다.

[2] 잘 설계된 어플리케이션의 GET 요구는 부작용이 없기 때문에 아무도 서버에서 변경을 할 수 없습니다.인증된 사용자만 POST 요청을 호출할 수 있도록 항상 세션과 CSRF 토큰을 사용하여 POST 요청을 인증해야 합니다.다른 사람이 이를 공격하면 해당 사용자가 계정을 가지고 있으며 해당 계정을 종료하고 싶어한다는 의미입니다.

왜 아무도 그 파일을 직접 방문할 수 없다고 확신하는지 의문입니다.당신의 첫 번째 행동은 사람들이 이 페이지를 직접 방문하여 이 만일의 사태에 대비해서 행동할 수 있다고 가정하는 것입니다. 이 에 대한 할 수 것을 .$_SERVER, 즉 '으로 지정됩니다.$_SERVER는 판별이 어려워 헤더의 값을 스푸핑할 수 있습니다.에서 그헤더를 했습니다.$_SERVER['HTTP_X_REQUESTED_WITH']&$_SERVER['HTTP_X_REQUESTED_WITH']할 수 도 신뢰할 수 없습니다.

다음 코드를 ajax에 의해 호출된 php 파일의 맨 위에 넣습니다.Ajax 요청을 실행하지만 브라우저에서 직접 호출되면 "die"가 됩니다.

define('AJAX_REQUEST', isset($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest');
if(!AJAX_REQUEST) {die();}

개인적으로는 보안 대책으로서 die() 뒤에 아무것도 출력하지 않는 것을 선택하고 있습니다.즉, 이 페이지가 보호되고 있는 경우나 「이유」등의 힌트를 주는 것보다, 「침입자」에게 빈 페이지만을 표시하는 것을 선호합니다.

나는 세 가지를 만드는 체크 기능을 준비해서 이 문제를 해결했다.

1. 참조자 $_SERVER['] 체크HTTP_REFERER'];
2. 체크 http x 요청 $_SERVER [''HTTP_X_REQUESTED_WITH'];
3. 브리지 파일로 출처를 확인하다

3개 모두 합격하면 ajax에서 호출된 php 파일을 볼 수 있고, 1개만 실패하면 얻을 수 없습니다.

포인트 1과 포인트2는 이미 설명되었으며 브리지 파일솔루션은 다음과 같이 기능합니다.

브리지 파일

다음 시나리오를 상정합니다.

A.php 페이지 콜을 ajax B.php 경유로 실시해, B.php에의 직접 액세스를 금지한다.

• 1) A.php 페이지가 로드되면 복잡한 랜덤 코드를 생성합니다.
• 2) 웹에서 직접 액세스할 수 없는 C.txt 파일에 코드가 복사됩니다(httpd 보안).

• 3) 동시에 이 코드는 A.php 페이지의 렌더링된 html에 명확하게 조각되어 있습니다(예를 들어 본문의 속성으로서 다음과 같습니다).

  data-bridge="ehfwiehfe5435ubf37bf3834i"

• 4) 이 조각된 코드를 javascript에서 검색하여 Ajax 포스트 요청을 통해 B.php로 전송합니다.

• 5) B.php 페이지에서 코드를 취득하여 C.txt 파일에 존재하는지 확인합니다.
• 6) 코드가 일치하면 코드는 C.txt에서 튀어나와 B.php 페이지에 액세스 할 수 있습니다.
• 7) 코드가 송신되지 않거나(B페이지에 직접 접속하려고 하는 경우), 전혀 일치하지 않는 경우(오래된 코드를 트랩하거나 커스텀 코드를 사용하여 트릭하는 경우), B.php 페이지가 소멸합니다.

이 방법에서는 아버지 페이지A에서 생성된Ajax 콜을 통해서만B 페이지에 액세스 할 수 있습니다.페이지 B의 키.php는 페이지A에서만 제공됩니다.php

이렇게 해도 소용없다.실제 보안은 추가되지 않습니다.

Ajax 것을 모든 (「Ajax」등).HTTP_X_REQUESTED_WITH할 수 는 클라이언트 측에서 위조할 수 있습니다.

Ajax가 중요한 데이터를 제공하거나 중요한 작업에 대한 액세스를 허용하는 경우 로그인 시스템과 같은 적절한 보안을 추가해야 합니다.

이거 먹어봤어

1) 파일요구를 한다)에서 1)과 같이 값을 .$_SESSION['random_value'] = 'code_that_creates_something_random';은 반드시 위에 $.post.

2) 그럼

$.post( "process_request.php", 
{ 
input_data:$(':input').serializeArray(),
random_value_to_check:'<?php echo htmlspecialchars( $_SESSION['random value'], ENT_QUOTES, "UTF-8"); ?>' 
}, function(result_of_processing) {
//do something with result (if necessary)
});

및 3) 및 3process_request.php

if( isset($_POST['random_value_to_check']) and 
trim($_POST['random_value_to_check']) == trim($_SESSION['random value']) ){
//do what necessary
}

세션을 정의하기 전에 세션 값을 가진 숨겨진 입력 필드를 정의한 다음 숨겨진 입력 필드의 값을 ajax와 함께 보냅니다.그러나 숨겨진 입력 필드는 필요없다고 판단했습니다.왜냐하면, 이 입력 필드 없이도 송신할 수 있기 때문입니다.

나는 에도아르도의 해법을 간략화했다.

1. 인 "A"를 .[token] 파일을 를 들어 . with " " " " " " " " " " " " " " .htaccess with .htaccess with .htaccess with .htaccess with " " " " ） " 。htaccess with .htaccess with with .htaccess with " 。htaccess " 。Deny from all(아파치 우경))

2. 가 A에 [token]B에 ('B'에서) AJAX의 '(OP'에서)queryString를 참조해 주세요.

3. 는, 「B」가 「B」인지 아닌지를 확인합니다.[token]filename이 존재하며 존재하는 경우 스크립트의 나머지 부분에서도 계속됩니다.그렇지 않으면 종료됩니다.

4. 또한 Cron을 사용하여 이전 토큰이 디스크에 누적되지 않도록 몇 가지 클리닝 스크립트를 설정해야 합니다.

, 지우다, 지우다, 지우다를 지우는 것도 .[token]스크립트 B를 사용하여 즉시 파일을 작성하여 여러 요청을 제한합니다.

HTTP 헤더 체크는 쉽게 스푸핑이 되기 때문에 필요하지 않다고 생각합니다.

당신의 설명으로 볼 때, 저는 당신이 만연한 학대를 막으려고 노력하고 있다고 생각하지만, 확실한 해결책은 필요하지 않습니다.

그 중에서 쿠키를 사용하는 것이 좋습니다.

★★★★★★★★★★★★★★★★★.setcookie()를 에서, AJAX 를 체크합니다.$_COOKIE.display에 합니다.이것에 의해, func.php에 전화하는 사람이 최근 당신의 사이트를 방문했다는 것을 합리적으로 보증할 수 있습니다.

cookie가 위조되거나 악용되지 않도록 하기 위해 고유한 세션 ID를 설정 및 확인할 수 있습니다(이미 이 작업을 수행할 수 있습니다).

여러 가지 제안을 해봤지만 아무도 문제를 해결하지 못했어요.마지막으로 php 타겟 파일의 파라미터를 보호했습니다.그것이 php 파일에 대한 직접 접근을 제한하는 유일한 방법입니다.** php 파일을 삽입하고 제한을 설정함으로써 메인 HTML 페이지에서 Ajax 접속에 실패했습니다.

언급URL : https://stackoverflow.com/questions/1756591/prevent-direct-access-to-file-called-by-ajax-function