In che modo i servizi che si basano sull'accesso lato client a un'endpoint di consumo di dati o API impediscono l'abuso?

4

Ad esempio, i servizi di monitoraggio delle applicazioni Web come New Relic RUM o Bucky utilizzano JavaScript per raccogliere i dati sulla sessione di un utente e infine inviarli di nuovo a un endpoint. Per New Relic, i dati vengono inviati a un endpoint come " link " con una grande quantità di parametri. Con Bucky un carico utile simile viene inviato a un endpoint di tua scelta.

In che modo questi servizi impediscono agli utenti malintenzionati di abusare di questi endpoint? Non è possibile che un utente possa confondersi facilmente con JavaScript per inviare dati indesiderati? E, con un po 'di lavoro in più, potrebbero essere in grado di inviare molti payload di quei dati spazzatura, inquinando i dati che questi servizi sono destinati a raccogliere?

Io stesso non sono uno sviluppatore front-end (in DevOps), ma da quello che capisco è essenzialmente impossibile per prevenire completamente l'abuso di qualsiasi cosa accessibile nel codice lato client. Altri risposte qui su SE e altrove suggeriscono lo stesso.

Questi servizi si limitano a mordere il proiettile e sperano che nessuno li abusi? Fanno affidamento su oscurità / offuscamento per ridurre al minimo le probabilità? O hanno escogitato un modo per mitigare le implicazioni della natura accessibile dal cliente?

    
posta edaemon 16.11.2016 - 19:06
fonte

2 risposte

1

Gli strumenti di analisi di solito hanno una sorta di transazione che identifica la richiesta, il caricamento della pagina, la sessione o qualsiasi altra unità per cui vogliamo misurare le caratteristiche delle prestazioni. Potremmo usarlo per rendere difficile per me segnalare metriche false sul tuo sito.

Se le metriche saranno accettate solo per le transazioni recenti e gli ID delle transazioni sono una sorta di GUID, lo spazio di ricerca di tutti gli ID di transazione può essere enorme mentre l'insieme degli ID di transazione validi è relativamente piccolo. Posso indovinare gli ID delle transazioni tutto il giorno, ma probabilmente posso solo convincere il sistema ad accettare le metriche per le transazioni che conosco e che ho avviato.

Ciò significa che posso inviarti metriche false sul mio uso del tuo sito ma se voglio inondare dati distorti probabilmente ho bisogno di fare un gran numero di richieste da solo. A quel punto il mio attacco inizia ad assomigliare più a un'inondazione da denial of service che a una subdola manipolazione dei dati metrici.

Comunque, qualsiasi dato segnalato dai clienti deve essere considerato in qualche modo inaffidabile. Bloccanti di annunci e reti inaffidabili significano che un discreto numero di richieste dei clienti non raggiungeranno mai il tuo back-end, quindi, mentre ottieni un utile esempio di prestazioni medie, raramente riesci a ottenere un quadro completo delle prestazioni di ogni cliente.

    
risposta data 17.11.2016 - 09:23
fonte
0

Un modo che conosco è utilizzando la chiave pre-condivisa per un dominio particolare.

Un ottimo esempio di questo sarà l'API di Google Maps.

Le API di Maps consentono l'accesso ai servizi di mappe dal client utilizzando una chiave API (inviata con ogni richiesta).

I server di Google sanno che questa chiave API è associata a questo particolare dominio (da cui proviene la richiesta). Se un altro dominio utilizza la stessa chiave API per ottenere i dati, verrà bloccato dal server. Tuttavia, l'utente abusivo può modificare le intestazioni delle richieste e ottenere i dati. I server gestiscono anche il numero di query ricevute e possono essere configurate per monitorare qualsiasi attività insolita o un numero elevato di richieste.

Quindi ci sono solo misure preventive che il fornitore di servizi può prendere e quindi non possono impedire completamente l'abuso.

    
risposta data 17.11.2016 - 08:09
fonte

Leggi altre domande sui tag