Enumerazione dei parametri del metodo API tramite browser Web

Question

Enumerazione dei parametri del metodo API tramite browser Web

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Sono obbligato per contratto a impedire l'enumerazione dei parametri di un metodo API ma non riesco a raggiungerlo.

Quando invio una richiesta vuota al server API in un browser Web, il server risponde con i parametri esatti richiesti da quel metodo API. Questo rende molto più facile il lavoro di un utente malintenzionato perché sa esattamente quali dati inviare a quel metodo API.

Ad esempio, se inserisco link in un browser web, ottengo una risposta, simile alla seguente, contenente i parametri esatti usati da quel metodo:

{"initObj": {"Locale":
   {"LocaleLanguage":"","LocaleCountry":"","LocaleDevice":"","LocaleUserState":"PossibleValue1 || PossibleValue2"},
   ”Another Parameter":""”,"AnotherParameter”:”PossibleValue1 || PossibleValue2"},
   "username": "", "password": ""}

Questa informazione dice esattamente al malintenzionato quali dati inviare al metodo API rendendolo molto più facile da attaccare.

Quello che devo fare è impedire al server di rispondere con queste informazioni quando viene inviata una richiesta vuota.

Naturalmente, questi parametri vengono sempre inviati tramite POST, non GET come quando invio l'URL nel browser web. Quindi, una soluzione è prevenire le richieste GET.

Come posso evitare queste risposte dal server senza fare affidamento su questo lavoro?

api rest appsec attack-prevention enumeration

posta user94044 09.12.2015 - 11:52

fonte

3 risposte

Leggi altre domande sui tag api rest appsec attack-prevention enumeration

Come posso nascondere la chiave di accesso AWS S3 e il segreto in C ++? [duplicare] Come testare gli attacchi DOS attraverso il router?

score 1 · Answer 1

Stai andando in sicurezza nel modo sbagliato!

Il tentativo di proteggere qualcosa nascondendo le informazioni su di esso si chiama sicurezza per oscurità . È considerato una cattiva pratica e non dovrebbe essere usato. La filosofia generale è che è difficile mantenere le cose come un segreto API. Un determinato utente malintenzionato eseguirà il backstore dell'installazione dell'applicazione client, guarderà il traffico di rete, verificherà il server, ecc. Per scoprire la firma di un'API.

Invece, implementa un'API che è sicura anche di fronte all'essere pubblicamente conosciuti. Affidati a segreti (come password e chiavi di autenticazione ) e altri meccanismi di controllo dell'accesso per proteggere la sicurezza dell'API. OWASP è un buon punto di partenza per iniziare a leggere sulla sicurezza.

score 0 · Answer 2

Per il CERT Oracle Coding Standard per Java ," la riflessione con le autorizzazioni del codice attendibile è una delle "ultime" violazioni della sicurezza in Java. consentire codice non attendibile per richiamare qualsiasi API che alla fine utilizza la riflessione per realizzare le sue azioni. " MSC53-J. Disegna attentamente le interfacce prima di rilasciarle

Un'altra utile risorsa per la protezione delle API sarebbe Rule 10. Thread APIs (THI)

score 0 · Answer 3

Fondamentalmente, Neil ha un grande vantaggio, anche se penso che in particolare il problema su cui devi concentrarti sia:

Sembra che l'endpoint dell'API sia aperto e non implementa sistemi di autenticazione o controlli di accesso su qualsiasi livello.

La Guida al controllo di accesso di OWASP & Guida all'autenticazione tratta questo in modo molto dettagliato.

Per soddisfare i requisiti aziendali che hai specificato utilizzando un approccio di difesa in profondità , dovresti (a almeno) implementare i seguenti livelli di sicurezza)

[Network Layer] -- Network ACLs (at Firewall / Router) specifying the IP addresses
   or network segments that are allowed to access the systems hosting your API

[Application Layer] -- Authentication Logic - before any request is processed by
   your API, you should require that the submitter present an authentication key
   or token to validate that they have been trusted to interact with your API.  
   Failure of a client to present a valid key should cause your API to return 
   an HTTP Status Code 404.

[Application Layer] -- Business Logic - After completing your authentication
  logic you should inspect the parameters and return an error code 5XX 
  along with a message indicating that parameters are missing.

Nota: dalla tua descrizione, sembra che stai usando IIS per ospitare i tuoi endpoint API. Non sono così familiare con la piattaforma, ma quello che stai descrivendo mi sembra un comportamento predefinito che viene eseguito perché:

Non hai sovrascritto la logica di risposta .Net predefinita con codice personalizzato che implementa qualcosa come i suggerimenti precedenti.
Non hai configurato le impostazioni predefinite del server web IIS per evitare questa enumerazione dei parametri.

Sebbene l'indirizzamento di uno dei due precedenti dovrebbe soddisfare i tuoi requisiti, suggerirei il n. 1 per darti più controllo sul comportamento esattamente eseguito e un sistema di sicurezza più robusto. Ecco alcuni link di riferimento aggiuntivi che possono essere utili in entrambi gli approcci sulla piattaforma IIS: