JSON attraverso lo script src =, come si ottiene l'oggetto JS nella pagina canaglia?

Question

JSON attraverso lo script src =, come si ottiene l'oggetto JS nella pagina canaglia?

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

2

Stavo spiegando l'attacco a un API JSON REST l'altro giorno (nella vita reale, al lavoro, non qui), e ho capito che non capisco parte del vettore di attacco.

Scusa se questa è una domanda di base, non sono eccezionale con JavaScript.

Un modo comune in cui questo attacco si verifica è che hai un'API, ad esempio http://myfavouritebank.com/api/account/ che restituisce quanto segue su una richiesta GET:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{ "customer name": "Bob",
  "account number": 123,
  "balance" : 123.56
}

Questo verrà restituito quando l'utente ha effettuato l'accesso (ad esempio, utilizzando un'autenticazione basata su cookie). Quando l'utente non ha effettuato l'accesso, restituisce semplicemente 403.

Quindi, una pagina di rouge contiene:

<script src="http://myfavouritebank.com/api/account/"/>

Elapaginacanagliacaricheràl'oggettoJSON(datochel'utenteèattualmenteloggatonelsitowebdellabanca).

Maladomandaè

Inchemodolapaginacanagliautilizzaeffettivamentequell'oggetto?Èsolounoggettoorfanoall'internodell'ambientediscript,comepuòessereassegnatoadunavariabile,adesempio?

Inaltreparole,hocapitochenonhomaicapitocomesisvolgaquestoattaccodaqui.

_{Cisonomolteottimerispostesu come prevenire CSRF su un'API REAST che spiega l'invio dei dati come JSON. Sto cercando di capire come viene costruita la pagina canaglia per recuperare i dati da un tale JSON, con queste informazioni posso spiegare meglio l'attacco.}

html javascript json

posta grochmal 03.09.2016 - 02:50

fonte

2 risposte

1

Un attacco CSRF di solito comporta l'induzione di una modifica sul conto delle vittime, sotto la custodia del sito vulnerabile, piuttosto che l'estrazione di informazioni sull'account delle vittime. Cioè, l'attacco si concentra sui dettagli di implementazione del sito vulnerabile, piuttosto che sui dettagli dei dati della vittima. Non è necessario conoscere o estrarre informazioni sulla vittima.

Un sito vulnerabile ha un endpoint, come / transfer-funds /, che prende i parametri che indicano quale account a cui trasferire i fondi, un importo da trasferire ed esegue il trasferimento dall'account degli utenti autenticati. Ha senso?

Se l'account degli utenti autenticati è stato identificato dal cookie emesso dal sito vulnerabile, un utente malintenzionato doveva semplicemente costruire un modulo in una pagina che controlla i POST sull'endpoint vulnerabile e quindi indurre l'utente a fare clic su un pulsante che attiva il INVIARE.

Il browser includerebbe i cookie nella richiesta nonostante la richiesta venga avviata da un altro sito e, in seguito alla presentazione, i fondi sarebbero magicamente e purtroppo trasferiti come se la richiesta fosse stata avviata dalla vittima.

Questa sottomissione di dati cross-site con credenziali, con molte varianti sullo specifico scenario naive di cui sopra, era di default consentita per un tempo molto lungo, ed è ancora un modello comune sul web. Gli attacchi dovevano essere specificamente bloccati o difesi, piuttosto che un uso valido specificamente e strettamente consentito.

Molto è cambiato da quando l'attacco è stato identificato per aumentare il livello di sicurezza di base, ma al costo di aumentare drasticamente il carico di configurazione e la complessità coinvolti nel mantenimento della sicurezza in tutti gli scenari conosciuti.

risposta data 03.09.2016 - 03:25

fonte

Leggi altre domande sui tag html javascript json

Perché firefox sta tentando di indirizzarmi verso un Captive Portal, quando sono connesso al mio router? Confuso con la definizione del digest del messaggio

score 2 · Accepted Answer

Vedi questa domanda per maggiori dettagli, ma in breve, manomettere i prototipi di Object e Array ti consente di leggere il contenuto di qualsiasi oggetto così come è stato creato. Quindi un attaccante aggiusta i prototipi, document.write è il tag script e anche se l'oggetto JSON non viene salvato, la strumentazione dell'attaccante viene notificata quando ogni proprietà viene impostata e può fare una copia.