Prevenire diretto accesso al fascicolo chiamato da ajax Funzione

Question

sto chiamando il codice php da Ajax in questo modo:

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

Dal momento che è una richiesta GET chiunque può vederlo, semplicemente esaminando le intestazioni. I dati trasmessi non sono sensibili, ma potrebbero essere potenzialmente abusati poiché è anche banale ottenere i nomi dei parametri.

Come impedire l'accesso diretto a http://mysite/func.php ma consentire alla mia pagina Ajax di accedervi?

Inoltre, ho provato la soluzione posted here ma non funziona per me, sempre il messaggio 'Accesso diretto non premesso'.

Answer 1

La maggior parte delle richieste/framework Ajax dovrebbe impostare questa particolare intestazione che è possibile utilizzare per filtrare le richieste Ajax v Non-ajax. Io lo uso per aiutare a determinare il tipo di risposta (JSON/html) in un sacco di progetti:

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

edit: È possibile aggiungere voi stessi nelle proprie richieste Ajax con il seguente nel codice javascript:

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

Answer 2

Mmm ... è possibile generare una password una tantum all'avvio della sessione, che è possibile memorizzare nella _SESSION e aggiungere un parametro alla chiamata ajax che lo ritrasmetterebbe (qualcosa come un captcha). Sarebbe valido solo per quella sessione.

Questo ti proteggerà dagli attacchi automatici, ma un utente che ha accesso al tuo sito potrebbe ancora farlo manualmente, ma potrebbe essere la base per ideare qualcosa di più complicato.

Answer 3

In base alla descrizione, presumo che tu stia cercando di impedire l'abuso sfrenato, ma non hai bisogno di una soluzione solida come la roccia.

Da questo, io suggerirei di usare i cookies:

Proprio setcookie() sulla pagina che utilizza l'AJAX, e verificare $_COOKIE per i valori corretti sul func.php. Questo ti darà qualche ragionevole certezza che chiunque chiami func.php abbia visitato il tuo sito di recente.

Se si desidera ottenere più fantasia, è possibile impostare e verificare ID di sessione univoci (è possibile farlo già) per garantire che il cookie non sia contraffatto o abusato.

Answer 4

quello che uso è: sessioni PHP + un hash che viene inviato ogni volta che faccio una richiesta. Questo hash viene generato utilizzando un algoritmo sul lato server

Answer 5

Mi chiederei perché sei così convinto che nessuno dovrebbe essere in grado di visitare direttamente quel file. La tua prima azione dovrebbe essere davvero assumere che le persone possano visitare direttamente la pagina e agire in base a questa eventualità. Se sei ancora convinto di voler chiudere l'accesso a questo file, devi sapere che non ci si può fidare delle variabili $_SERVER perché le origini di $_SERVER possono essere difficili da determinare e i valori delle intestazioni possono essere falsificati. In alcuni test ho trovato quelle intestazioni ($_SERVER['HTTP_X_REQUESTED_WITH']$_SERVER['HTTP_X_REQUESTED_WITH']) inaffidabili.

Answer 6

Non ha senso farlo. Non aggiunge alcuna sicurezza reale.

Tutte le intestazioni che indicano che una richiesta viene effettuata tramite Ajax (come HTTP_X_REQUESTED_WITH) possono essere contraffatte dal lato client.

Se l'Ajax fornisce dati riservati o consente l'accesso a operazioni sensibili, è necessario aggiungere una protezione adeguata, ad esempio un sistema di accesso.

Answer 7

Chiunque in questa discussione abbia suggerito di guardare le intestazioni è in qualche modo sbagliato. Qualunque cosa nella richiesta (HTTP_REFERER, HTTP_X_REQUESTED_WITH) può essere falsificata da un utente malintenzionato che non è del tutto incompetente, inclusi i segreti condivisi [1].

Non è possibile impedire alle persone di effettuare una richiesta HTTP sul proprio sito. Quello che vuoi fare è assicurarti che gli utenti debbano autenticarsi prima di fare una richiesta ad alcune parti sensibili del tuo sito, tramite un cookie di sessione. Se un utente fa richieste non autenticate, fermati lì e dai loro un HTTP 403.

L'esempio esegue una richiesta GET, quindi suppongo che tu sia interessato ai requisiti delle risorse della richiesta [2]. Puoi eseguire alcuni semplici controlli di integrità nelle intestazioni HTTP_REFERER o HTTP_X_REQUESTED_WITH nelle tue regole .htaccess per impedire che i nuovi processi vengano generati per richieste ovviamente false (o per i crawler di ricerca stupidi che non ascolteranno a robots.txt), ma se l'hacker falsi quelli, ti consigliamo di assicurarti che il tuo processo PHP si chiuda il prima possibile per richieste non autenticate.

[1] È uno dei problemi fondamentali delle applicazioni client/server. Ecco perché non funziona: supponiamo che tu abbia un modo per l'app client di autenticarsi sul server, che si tratti di una password segreta o di un altro metodo. Le informazioni di cui l'app ha bisogno sono necessariamente accessibili all'app (la password è nascosta lì da qualche parte, o qualsiasi altra cosa). Ma poiché viene eseguito sul computer dell'utente, significa che hanno anche accesso a queste informazioni: tutto ciò di cui hanno bisogno è guardare la fonte, o il binario, o il traffico di rete tra la tua app e il server, e alla fine capiranno il meccanismo con cui l'app si autentica e la replica. Forse lo copieranno anche. Forse scriveranno un trucco intelligente per fare in modo che la tua app risolva il problema (puoi sempre inviare un falso input dell'utente all'app). Ma non importa come, hanno tutte le informazioni richieste, e non c'è modo di impedirgli di averlo che non impedisce anche alla tua app di averlo.

[2] Le richieste GET in un'applicazione ben progettata non hanno effetti collaterali, quindi nessuno che le esegue sarà in grado di apportare modifiche al server. Le tue richieste POST devono sempre essere autenticate con la sessione più il token CSRF, per consentire solo agli utenti autenticati di chiamarle. Se qualcuno attacca questo, significa che ha un account con te e che vuoi chiudere quell'account.

Answer 8

Inserire il codice seguente nella parte superiore del file php chiamato ajax. Eseguirà richieste ajax, ma "morirà" se viene richiamato direttamente dal browser.

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

Personalmente, ho scelto di non emettere nulla dopo "die()", come ulteriore misura di sicurezza. Significa che preferisco mostrare solo una pagina vuota all '"intruso", piuttosto che fornire suggerimenti come "se" o "perché" questa pagina è protetta.

Answer 9

ho risolto questo problema la preparazione di una funzione di controllo che fanno tre cose

1. controllo referer $ _SERVER [ 'HTTP_REFERER'];
2. verifica http x richiesta $ _SERVER ['HTTP_X_REQUESTED_WITH'];
3. verificare l'origine tramite un file ponte

se tutti e tre passaggio, è successo nel vedere file php chiamato da ajax, se solo uno non riesce non capisco

I punti 1 e 2 erano già spiegato, la soluzione file di bridge funziona così:

Ponte sul file

immagine il seguente scenario:

A.php chiamata pagina tramite ajax b.php e si vuole impedire l'accesso diretto al b.php

• 1) quando la pagina viene caricata A.php genera un codice casuale complicata
• 2) il codice è copiato in un file C.txt non direttamente accessibile da web (httpd secured)

• 3) allo stesso tempo questo codice è in chiaro scolpito nel file di testo 01preso della pagina A.php (per esempio come attributo di body, es:

  dati-ponte = "ehfwiehfe5435ubf37bf3834i"

• 4) questo codice viene scolpito retrived da JavaScript e inviato tramite ajax richiesta post per b.php

• pagina 5) b.php ottenere il codice e controllo se esiste nel file C.txt
• 6) se corrispondenza del codice il codice è spuntato fuori dalla C.txt e la pagina b.php è accessibile
• 7) se il codice non viene inviato (nel caso in cui si tenta per accedere direttamente alla pagina B ) o non corrisponde affatto (nel caso in cui si supp un vecchio codice intrappolato o un trucco con un codice personalizzato), pagina die B.php.

In questo modo è possibile accedere alla pagina B solo tramite una chiamata AJAX generato dalla pagina padre A. La chiave per pageB.php è dato solo e sempre da pageA.php

Answer 10

Ho provato questo

1) nel file php principale (da cui inviare richiesta ajax) creare una sessione con un valore casuale, come $_SESSION['random_value'] = 'code_that_creates_something_random'; Deve essere sicuro, quella sessione viene creata sopra $.post.

2) poi

$.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) e in process_request.php

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

Prima i definita sessione, campo di input allora nascosto con valore di sessione, allora il valore del campo di input nascosto inviare con l'Ajax. Ma poi ha deciso che il campo di input nascosto non è necessario, perché può inviare senza di esso

Answer 11

Ho provato molti suggerimenti, nessuno ha risolto il problema. Finalmente ho protetto i parametri del file target php ed era l'unico modo per limitare l'accesso diretto al file php. ** Puting del file php e limitazione impostata by.htaccess causato errore Connessione Ajax nella pagina Html principale.