Questa domanda è più una riassicurazione di una direttamente su come codificare. Come autodidatta non avevo molte possibilità di chiedere a professionisti del genere, quindi provo qui.In quale caso è esente da CSRF essere pericoloso?
Ho letto i documenti nelle django-docs (https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/) e alcune informazioni su quella pagina: http://cwe.mitre.org/top25/#CWE-352
Per quanto ho capito, Django trasporta un token (una sorta di pin-code) per una utente. E per verificare che sia davvero lui, deve restituirlo la prossima volta che fa una richiesta. E alcuni ragazzi di Google hanno scoperto che questo è possibile anche con richieste di tipo jax, motivo per cui abbiamo la nuova politica di protezione anche dal 1.2.6. E CSRF parla di qualcuno che mi sta dando qualcosa (codice cattivo, pericoloso, file corrotti o qualcosa del genere) che finge di essere qualcun altro.
Quindi, se ho qualche codice come questo:
@csrf_exempt
def grab(request):
"""
view to download an item
POST because it stores that a user has downloaded this item
"""
item_id = request.POST.get('item', None)
if not loop: return HttpResponseBadRequest('no item id provided')
item = Item.objects.get(pk=int(item_id))
che dovrebbe essere salvo, come io non sono che dà accesso alla banca dati o una parte della mia applicazione prima di provare a convertire il valore dato ad un numero intero. E non c'è troppo danno se faccio una registrazione sbagliata di qualcuno che scarica un file (in questo caso non ne ha quasi). Supponendo che scriverei fatture basandosi su questo punto di vista, l'esenzione CSRF sarebbe una cattiva idea (è vero?).
Inoltre non capisco perché qualcuno non possa rubare il token CSRF da un utente e usarlo per ingannare ancora me (o l'utente). Quindi ho alcune domande su questo argomento:
1) sono le mie supposizioni da sopra a destra?
2) qualcuno può dirmi, cosa (e probabilmente come) un ragazzo non così gentile potrebbe usare la vista sopra per fare trucchi sporchi, e quali sarebbero?
3) è un CSRF un esempio di attacco man-in-the-middle, è solo relativo ad esso, o è qualcosa di completamente diverso?
4) Qualche link valido per ulteriori approfondimenti su tali pericoli?
Forse alcune di queste domande non sono ben informate, ma sto cercando di superarlo. Sarei molto felice se qualcuno potesse aiutarmi.
C'è una luce fioca che appare alla fine del tunnel ... Quindi se volessi inviare cose malvagie ad un server, prima dovrei inviare alcuni dati ad alcuni browser degli utenti. In questi dati nascondo alcuni moduli che inviano automaticamente al server per essere attaccati. Suppongo che l'utente abbia effettuato l'accesso a quel server, perché ha un account lì. E se il server non controllasse qualche token, dovrebbe semplicemente credere che la richiesta fosse legittima. Almeno ora ho un'idea di come funziona e dove tracciare la linea per MIM e XSS. Grazie per quello. – marue
@marue CSRF non riguarda l'invio di dati dannosi al server. Si tratta principalmente di imitazione poiché il sito attaccante può inviare richieste legittime e autentiche a nome della vittima. L'intercettazione, il MITM e l'XSS sono solo mezzi per afferrare un token CSRF attenuante (sebbene la maggior parte degli schemi di gestione dell'autenticazione utilizzi sessioni basate sui cookie, si potrebbe anche ottenere l'ID di sessione). – Gumbo
Quindi CSRF è tutto e "solo" sul fingere di essere qualcuno che non sei? Dove solo non significa non importante, ma tutto il resto è un diverso vettore di attacco. – marue