Come convalidare una richiesta di jax viene dalla pagina corretta e non viene manomessa?

Question

Come convalidare una richiesta di jax viene dalla pagina corretta e non viene manomessa?

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

3

Sto costruendo un semplice Q & Un'app con PHP, HTML e JS. Ho tre tabelle: users , question e answers , ogni tabella ha la sua chiave primaria e questions e answers hanno entrambi vincoli di chiave esterna. questions store users.uID per cercare autore e answers store question.qID per identificare a quale domanda appartengono, e anche autore che ha scritto la risposta, quindi users.uID è anche chiave esterna.

Ed ecco la mia preoccupazione principale: come implementare correttamente il pulsante di invio per la risposta, che passa l'ID autore e anche l'ID della domanda che deve essere inserito nella tabella answers tramite richiesta Ajax, quindi deve ottenere quell'ID da qualche parte. La preoccupazione principale non è XSRF, ma il fatto che l'utente autorizzato possa manometterlo, modificando una parte del codice html se l'ID è memorizzato in modo visibile (o invisibile) da qualche parte.

L'ID utente è semplice, può essere archiviato in sessione una volta recuperato dal DB e l'accesso dell'utente e verrà riutilizzato anche altrove, quindi non è un grosso problema in termini di costi delle prestazioni e può essere accessibile da tutti gli script mentre è nascosto all'utente. Ma anche memorizzare l'ID della domanda in sessione, ogni volta che l'utente visita una domanda, e quindi sostituirlo con un'altra ID di domanda quando visita un'altra domanda mi sembra che stia chiedendo di provocare un carico pesante sul server ad un certo punto.

Aggiungendo hash al pulsante di invio, che viene quindi convalidato dallo script che elabora, anche i dati delle chiamate ajax appaiono complicati, dal momento che è necessario memorizzare anche quell'hash in sessione. Anche l'utilizzo del campo nascosto non è sicuro, poiché l'utente può vedere quel campo nel codice sorgente e può manometterlo.

Quindi dove archiviare in modo efficiente quell'ID domanda, quindi è pronto quando viene premuto il pulsante di invio e anche quell'utente non può manometterlo e inviare una chiamata con un altro ID? La sessione è davvero solo un'opzione?

html javascript php security ajax

posta The Law 14.12.2016 - 12:24

fonte

2 risposte

0

Cifra tutti i dati "importanti" sul server e archivia il valore crittografato in un campo nascosto. Puoi esporre gli stessi dati in forma non crittografata se gli script sul lato client devono utilizzarli.

E non temere "carico pesante sul server". Ci sono molti modi per ridimensionare e probabilmente il carico sul database sarà la tua preoccupazione principale.

risposta data 14.12.2016 - 13:36

fonte

Leggi altre domande sui tag html javascript php security ajax

Dove si trova la documentazione di OpenSSL? Implementazione del modello di osservatore con un osservatore / più editori e più eventi?

score 2 · Accepted Answer

The main concern is not XSRF, but the fact that authorised user could tamper with it, by changing a part of html code if the ID is stored visibly (or invisibly) somewhere.

Comprendo il desiderio di assicurarmi che l'utente non elimini l'interfaccia utente che hai fornito. Tuttavia, non è facile da fare e non migliorerà la sicurezza.

Dovresti memorizzare lo stato utente pertinente sul lato server e confrontarlo con lo stato fornito dall'utente. Poiché lo stesso stato è ora in due punti, c'è sempre la possibilità che questi stati non siano sincronizzati, ad es. se l'utente interrompe un'azione o se la connessione di rete viene interrotta. L'utente può anche avere più stati, ad es. se stanno utilizzando la tua app Web in più schede del browser.
È anche possibile creare una firma crittografica dello stato utente e assegnare all'utente questa firma come token. L'utente deve trasmettere il token con ogni richiesta, in modo che possa essere convalidato dal server. Tuttavia, esiste ancora la possibilità di attacchi di riproduzione se questo token non è implementato come nonce.

Tutto questo è facile da sbagliare e può causare molta frustrazione per gli utenti se non funziona come previsto (ho incontrato un paio di siti che a volte sono inutilizzabili a meno che non elimini alcuni cookie). Questo sforzo è certamente giustificato per i domini bancari online o simili in cui preferiresti essere al sicuro che dispiaciuti. In altri domini, è più probabile che questo sia percepito come utente-ostile.

Invece di controllare che l'utente si attenga ai collegamenti che hai fornito, controlla che l'utente abbia le autorizzazioni necessarie per qualsiasi azione che sta tentando di intraprendere.

Se in genere sono autorizzati a visualizzare, creare o modificare una risorsa, consentire all'utente di eseguire tale azione anche se hanno manipolato l'URL.
Se non sono autorizzati ad accedere alla risorsa, negarli anche se possono indovinare l'URL corretto. Un certo numero di "violazioni" dei dati ha avuto la causa che i dati privati non erano protetti da un modello di autorizzazione, ma solo da un ID "segreto" che altri utenti non dovevano sapere - ma potevano essere indovinati o intercettati dall'attaccante.

Per difendersi dall'abuso delle risorse a cui l'utente può accedere:

Utilizza i limiti di velocità. Per esempio. in un sistema Q & A, un utente normale non può e non deve pubblicare 5 risposte entro 10 minuti.
Sviluppa un sistema per la segnalazione e la revisione dei contenuti generati dagli utenti, in particolare se il contenuto dell'utente è pubblicamente visibile.
Se gli utenti fanno ricorso ai bot quando usano la tua app web, questo potrebbe significare che ti mancano alcune funzionalità cruciali. Offri un'API più conveniente rispetto allo scraping. A volte, un pulsante da esportazione a CSV è mancante a tutti gli utenti.