Un attacco che non modifica lo stato del server può essere considerato un attacco CSRF?

Lo "stato" del server, nel caso di un client BitTorrent, include almeno l'elenco di download in sospeso, correnti e finiti, tutti i dati relativi a tali download e qualsiasi impostazione relativa all'operazione del client BitTorrent.

L '"attacco" sta causando il client Bittorrent per avviare il download dei dati in base ad alcuni file torrent specifici disponibili online, presumibilmente sotto il controllo o scelti dall'hacker.

Il fatto che il client Bittorrent aggiunga un torrent specifico al suo elenco di download in sospeso sembra un chiaro cambiamento di stato, ma potrebbe essere temporaneo. Tuttavia, una volta che il file inizia a scaricare, possiamo facilmente sostenere che l'atto di scaricare il file provoca sicuramente un persistente cambiamento di stato sul sistema memorizzando dati arbitrari, pericolosi e / o illegali su disco, così come il fatto che siamo ora ridistribuendo questi dati ad altri che di per sé potrebbero essere almeno illegali.

Quindi, l'attacco fa cambia lo stato del server (dove in questo caso il "server" è la macchina che esegue il software client Bittorrent che è accessibile attraverso l'interfaccia web tramite il suo web server integrato funzionalità, che il software capita a anche agire come un client Bittorrent è irrilevante qui), e come tale soddisfa la definizione OWASP di un attacco CSRF che hai citato nella tua domanda. Ciò a sua volta porta alla conclusione che sì, la vulnerabilità descritta costituisce un attacco CSRF in base a tale definizione.

La descrizione OWASP di CSRF su link copre esattamente questo esempio:

Let us consider the following example: Alice wishes to transfer $100 to Bob using the bank.com web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to her instead. The attack will comprise the following steps:

• building an exploit URL or script
• tricking Alice into executing the action with social engineering GET scenario

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice's account to her account. She takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

http://bank.com/transfer.do?acct=MARIA&amount=100000 The social engineering aspect of the attack tricks Alice into loading this URL when she's logged into the bank application. This is usually done with one of the following techniques:

• sending an unsolicited email with HTML content
• planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

In poche parole, per "causare un cambiamento nello stato del server" significa che l'attaccante invia una richiesta GET, che cambia lo stato del server da inattivo a "recupero del contenuto richiesto", che l'utente non ha t intenzione di inviare. Non si riferisce a una modifica nella configurazione del server.

Per ulteriori informazioni:

link link