Nascondono e offuscano le chiavi dei parametri URL come protezione contro la manomissione?

Question

Nascondono e offuscano le chiavi dei parametri URL come protezione contro la manomissione?

#1 da (2 voti)
#2 da (0 voti)

4

L'uso di mod_rewrite rende impossibile l'iniezione di array PHP ( manomissione dei parametri dei parametri web ) quando le chiavi sono sconosciuti (e difficili da indovinare)?

Diciamo che abbiamo il seguente URL:

https://example.com/product.php?id=1&action=show

example.com ha deciso di riscrivere gli URL in una versione più carina come:

https://example.com/product/1

Pertanto usano il seguente RewriteRule :

RewriteRule ^/product/(.*)$ /product.php?id=$1&action=show [L]

Ora le chiavi sono id e action e quei valori sono 1 e show . Capisco che i valori saranno riscritti, nessuna protezione è comunque coinvolta. Le iniezioni sono ancora possibili e così via. Ma le chiavi non possono essere cambiate presumendo che siano sconosciute. In questo esempio ho usato le chiavi ipotizzabili id e action ma potevano anche essere due chiavi completamente lunghe e casuali.

Ora la mia domanda riguarda le chiavi. Potrei iniettare uno o più [] nel parametro per fare in modo che il valore di quel id sia un array PHP invece di una stringa. In questo modo:

https://example.com/product.php?id[]=1&action=show

Per un URL riscritto non è possibile farlo a meno che non si conosca la chiave. Ho ragione? In questo esempio, il seguente sarà ancora possibile perché la chiave è facile da indovinare. L'esempio di seguito che l'URL conoscerà avrà la chiave id due volte e utilizzerà l'ultimo con il% co_de iniettato.

https://example.com/product/1?id[]=1

Ma presumendo che le chiavi non fossero conosciute e facili da indovinare. Diciamo:

RewriteRule ^/product/(.*)$ /product.php?7b8d164d7820713ef5be524d2bde7828999c78d6=$1&28c4abba80b7a2038328e54a81f51367ead9172a=show [L]

Suppongo che non ci sia modo di iniettare [] senza conoscere i tasti.

Inoltre, quando controlli l'URL corrente nel tuo script PHP per i caratteri [] e ? puoi impedire i bypass come & . A mio parere, l'iniezione di matrice o l'alterazione della chiave non sono più possibili solo il valore può essere modificato. Giusto?

php apache url web-application url-redirection

posta Bob Ortiz 14.07.2016 - 11:37

fonte

2 risposte

0

Un buon modo per avvicinarsi è sanare l'input dell'utente nel metodo PHP dedicato poco dopo che la richiesta è stata invocata.

Questo ha diversi vantaggi:

Sei sempre sicuro che vengano inviati solo argomenti formattati corretti, ad es. gli int sono gli interi e le stringhe sono stringhe senza nulla di insolito
Che il numero corretto di argomenti è passato quindi, ad esempio, non c'è modo di aggiungere un altro argomento e fare in modo che lo script faccia qualcos'altro

Se riesci ad abbinare due dei precedenti, è probabile che tu sia in grado di rimuovere alcuni bug esistenti, come il passaggio dell'elenco incompleto di argomenti e l'inizializzazione non corretta delle variabili.

Questo ti dà un migliore approccio strutturale al tuo codice PHP e davvero la convalida dell'input obbligatorio.

Normalmente la convalida dell'input viene eseguita con metodi standard, tuttavia prima della richiesta di routing è opportuno disporre di un posto per disinfettarli: questo è un metodo valido e valido perché è importante disinfettare l'input prima che vengano chiamati più metodi.

In questo modo, la cosa migliore è chiamare sempre un metodo di controller e controllare se tutti gli argomenti sono corrispondenti (esistenti) e sono dei tipi richiesti (nel metodo controller che esegue principalmente il controllo e successivamente chiama solo un altro servizio) , per esempio (è solo un codice per mostrare la logica nel controller):

//router
if($_GET['action'] === 'showItem') {
    showItemController();
}

//controller
function showItemController() {
    try {
        $id = $_GET['id'];
        if(!isint($id)) {
           throw new Exception("id '{$id} is wrong");
        }
        $output = showItem($id);
        render($output);
    } catch(Exception $e) {
      logError($e);
      displayGenericFail();
    }
}

//service
function service($id) {
    $item = new Item($id);
    return $item->getHtml();
}

risposta data 11.08.2016 - 17:14

fonte

Leggi altre domande sui tag php apache url web-application url-redirection

Perché i sistemi di messaggistica crittografata end-to-end sono limitati a un dispositivo per utente? Stabilire la fiducia tra un dispositivo e uno sviluppatore, segnale TLS vs X.509, GnuPG (o entrambi)

score 2 · Accepted Answer

Nasconderà l'effettiva posizione dello script, ma su di esso non c'è nulla che impedisca a un utente malintenzionato di indovinare / dirbustings / etc il file product.php e di accedervi direttamente. L'utente malintenzionato dovrebbe quindi identificare i nomi dei parametri corretti (id e azione). Una volta che l'autore dell'attacco accede direttamente al file, la regola di riscrittura non si applica.

Quindi potresti potenzialmente aumentare lo sforzo minimo richiesto per attaccare il tuo script, tuttavia potresti avere bisogno di riscrivere le regole e non sono molto performanti, quindi potresti introdurre una condizione di negazione del servizio nel processo.