Fino a che punto si va nella convalida lato server delle richieste POST / GET?

0

La nostra applicazione ha rilevato alcune vulnerabilità di AppScan e abbiamo dovuto aggiungere la validazione lato server per rilevare i tentativi di iniezione SQL.

Ma la mia domanda è: fino a che punto si va nella convalida sul lato server? In teoria, non c'è fine a quanto sia complicato riuscirci.

Supponiamo che sto solo convalidando che non ci sono caratteri speciali nel mio modello, che è il minimo indispensabile

public boolean validateModel(Model model) {
    // Email address has no special chars
    try {
      InternetAdress emailAddr = model.getEmailAddr();
      emailAddr.validate();
    } catch (Exception e) {
       return false;
    }

    // FirstName has no special chars
    if (!StringUtils.isAlphanumeric(model.getFirstName())
         return false;

    // LastName has no special chars
    if (!StringUtils.isAlphanumeric(model.getLastName())
         return false;
    }
    // ...  
    return true;
}

Ma perché fermarsi qui? In qualsiasi operazione CRUD, dobbiamo anche proteggere da ID o numeri non validi, quindi ogni Insert può controllare che l'ID non esista ancora; che tu appartenga o non appartenga a qualsiasi area tu dichiari di essere affiliata (ad esempio, l'ID è un ID valido per te); o qualsiasi aggiornamento / cancellazione può controllare che l'ID debba esistere per primo. Per essere veramente sicuri, possiamo davvero analizzare l'input dell'utente perché gli hacker possono sostituire i dati non validi anche senza caratteri non validi.

Il mio punto è, per raggiungere un livello adeguato di sicurezza lato server, c'è un enorme controllo che si può fare sul lato server. Dove ti fermi? Quali sono le migliori pratiche?

    
posta gene b. 16.05.2018 - 16:50
fonte

3 risposte

3

Personalmente non scrivo praticamente nessun controllo di input sulle mie apis .net.

Ma per quanto riguarda hax0rz!?!? Ti sento piangere.

Semplice. Una combinazione di programmazione difensiva e l'utilizzo del .net integrato ti coprono completamente dal punto di vista funzionale

  1. Autorizza attributo e il tuo livello di autenticazione fave interrompe le richieste non autenticate / non autorizzate

  2. Le query con parametri SqlClient interrompono l'iniezione sql

  3. Eccezioni, si presentano e vengono restituite al client (ora richiede un gestore per renderlo json). Catturali e Lanciali quando qualcosa non va.

  4. Limita la funzionalità sui metodi pubblici alla granularità di sicurezza richiesta. Non creare un metodo DeleteAnything () quando si ha il requisito che le persone possano solo cancellare determinate cose. Avere DeleteThisSpecificTypeOfThing ()

Hai bisogno di un controllo di input quando vuoi restituire messaggi piacevoli all'utente "sembra che il tuo nome abbia un numero. Non è permesso!"

In un Api che è meglio lasciare al cliente. Vogliamo evitare il viaggio di andata.

    
risposta data 16.05.2018 - 18:26
fonte
1

Comprendo il dolore della codifica di tali controlli, ma devi codificarli per avere un'API stabile / sicura.

But why stop there? In any CRUD operation, we also have to protect against invalid IDs or numbers

Suppongo che tu non controlli questo tipo di informazioni?

Sono abbastanza sicuro che esista un po 'di mecanismo per facilitare questi controlli.

So che .NET fornisce alcune classi per gestire i controlli di sicurezza:

  • AuthorizationFilterAttribute per gestire l'autorizzazione su richiesta
  • ValidationAttribute per gestire la convalida del modello
  • ActionFilterAttribute per gestire la convalida dell'input (se il modello non è valido return BadRequest, se id non esiste return NotFound)

Hai guardato questo genere di cose?

L'automazione è la chiave qui!

    
risposta data 16.05.2018 - 17:25
fonte
0

Our application had a few vulnerabilities detected by AppScan and we had to add server-side validation to catch SQL injection attempts.

La convalida sul lato server dovrebbe far parte della tua applicazione fin dall'inizio.

how far do you go in server-side validation?

Nella misura necessaria per proteggere la tua applicazione e i dati degli utenti.

La convalida lato server è la convalida solo che conta o, piuttosto, è la convalida solo che puoi essere certo che succederà .

Non puoi fidarti di qualsiasi cosa che proviene dal client.

Precedentemente risposto (in modo completo) sotto Quali dettagli tecnici dovrebbe prendere in considerazione un programmatore di un'applicazione web prima di rendere pubblico il sito?

    
risposta data 17.05.2018 - 12:41
fonte