Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
requests-racer — Piccola libreria Python che rende facile sfruttare le race condition nelle applicazioni web con Requests. | Kitploit
Strumenti/GitHubGitHub/nccgroup/requests-racer
Analisi delle VulnerabilitàSfruttamento di Applicazioni WebSicurezza WebPenetration Testing
GitHubnccgroup/requests-racer

requests-racer

Piccola libreria Python che rende facile sfruttare le race condition nelle applicazioni web con Requests.

Vedi Repository
161163 anni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
Sito web

Requests-Racer

Requests-Racer è una piccola libreria Python che ti consente di utilizzare la libreria Requests per inviare più richieste che verranno elaborate dai rispettivi server di destinazione approssimativamente nello stesso momento, anche se le richieste hanno destinazioni diverse o payload di dimensioni diverse. Questo può essere utile per individuare e sfruttare le vulnerabilità di race condition nelle applicazioni web. (Per maggiori informazioni, vedi motivation.md.)

Disclaimer

Requests (e urllib3, che Requests usa internamente) non sono mai state pensate per permetterti di fare qualcosa del genere. Requests-Racer è quindi costretto a ricorrere ad alcuni hack piuttosto brutti per ottenere un controllo granulare su come vengono inviate le richieste.

Questi hack includono la manomissione dello stato privato di alcuni oggetti urllib3, quindi un aggiornamento di urllib3 che è retro-compatibile rispetto alla sua API pubblica potrebbe comunque rompere Requests-Racer. Pertanto, consiglio di usare Requests-Racer in un virtualenv e installarlo prima di Requests o urllib3, così da ottenere come dipendenza una versione nota e compatibile di queste librerie.

Installazione

Per usare Requests-Racer, avrai bisogno di Python 3.5 o successivo. Innanzitutto, crea e attiva un ambiente virtuale Python:

root@kitploit:~
python3 -m venv env
source env/bin/activate

Quindi scarica una copia della libreria e installala:

root@kitploit:~
git clone https://github.com/nccgroup/requests-racer.git
cd requests-racer
python setup.py install

Utilizzo

Requests-Racer funziona fornendo un Transport Adapter alternativo per Requests chiamato SynchronizedAdapter. Raccoglierà tutte le richieste che farai tramite esso e le completerà solo quando viene chiamato il metodo finish_all():

root@kitploit:~
import requests
from requests_racer import SynchronizedAdapter

s = requests.Session()
sync = SynchronizedAdapter()
s.mount('http://', sync)
s.mount('https://', sync)

resp1 = s.get('http://example.com/a', params={'hello': 'world'})
resp2 = s.post('https://example.net/b', data={'one': 'two'})

# at this point, the requests have been started but not finished.
# resp1 and resp2 should *not* be used.

sync.finish_all()

print(resp1.status_code)
print(resp2.text)

Per semplificare il tuo codice, puoi anche usare SynchronizedSession, che è semplicemente un oggetto requests.Session che monta automaticamente un SynchronizedAdapter per HTTP[S] e inoltra il metodo finish_all(), quindi il codice sopra può essere riscritto come segue:

root@kitploit:~
from requests_racer import SynchronizedSession

s = SynchronizedSession()

resp1 = s.get('http://example.com/a', params={'hello': 'world'})
resp2 = s.post('https://example.net/b', data={'one': 'two'})

# at this point, the requests have been started but not finished.
# resp1 and resp2 should *not* be used.

s.finish_all()

print(resp1.status_code)
print(resp2.text)

Ecco alcune avvertenze da tenere a mente e cose più avanzate che puoi fare:

  • SynchronizedAdapter non è thread-safe.
  • Le richieste effettuate tramite un SynchronizedAdapter non aggiorneranno l'oggetto sessione (ad es. i cookie provenienti dagli header Set-Cookie non verranno aggiunti al cookie jar della sessione).
  • I redirect potrebbero non essere seguiti, cerca di evitarli.
  • Se si verifica un'eccezione durante l'avvio di una richiesta, verrà rilanciata esattamente come con le richieste normali. Tuttavia, se si verifica durante il completamento di una richiesta, non verrà rilanciata. Invece, la risposta alla richiesta avrà stato 999 e conterrà un traceback nel suo attributo .text.
  • SynchronizedSession.from_regular_session costruisce una SynchronizedSession a partire da un'istanza di requests.Session. Questo è utile se devi fare alcune semplici richieste, ad es. per accedere a un servizio e ottenere un cookie di sessione che ti servirà per le richieste sincronizzate.
  • SynchronizedAdapter e SynchronizedSession accettano un parametro opzionale chiamato , che indica il numero massimo di thread che l'adapter utilizzerà. Se non specificato, l'adapter userà un thread per richiesta.

Vedi benchmark/ per note sulle prestazioni.

Licenza

Copyright (C) 2019 Aleksejs Popovs, NCC Group

Questo programma è software libero: puoi ridistribuirlo e/o modificarlo secondo i termini della GNU General Public License come pubblicata dalla Free Software Foundation, sia la versione 3 della Licenza, o (a tua scelta) qualsiasi versione successiva.

Questo programma è distribuito nella speranza che sia utile, ma SENZA ALCUNA GARANZIA; senza nemmeno la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ PER UN PARTICOLARE SCOPO. Vedere la GNU General Public License per maggiori dettagli.

Devi aver ricevuto una copia della GNU General Public License insieme a questo programma. Se non l'hai ricevuta, vedi https://www.gnu.org/licenses/.

Scarica lo strumento
num_threads
  • finish_all() accetta un parametro opzionale chiamato timeout, che indica la quantità massima di tempo (in secondi) che l'adapter aspetterà per il completamento di un thread.