Dovresti proteggerti da valori imprevisti da API esterne?

Supponiamo che stai codificando una funzione che accetta input da un'API esterna MyAPI.

L'API esterna MyAPIha un contratto che afferma che restituirà a stringo a number.

E 'consigliato a guardia contro le cose come null, undefined, boolean, ecc anche se non fa parte delle API di MyAPI? In particolare, dal momento che non hai alcun controllo su quell'API, non puoi fornire la garanzia attraverso qualcosa come l'analisi del tipo statico, quindi è meglio prevenire che curare?

Sto pensando in relazione al principio di robustezza .

Non dovresti mai fidarti degli input per il tuo software, indipendentemente dalla fonte. Non solo è importante convalidare i tipi, ma anche intervalli di input e anche la logica aziendale. Per un commento, questo è ben descritto da OWASP

In caso contrario, nella migliore delle ipotesi vi lasceremo con i dati spazzatura che dovrete successivamente ripulire, ma nella peggiore delle ipotesi lascerete un'opportunità per exploit dannosi se quel servizio a monte viene compromesso in qualche modo (qv l'hack Target). La gamma di problemi nel mezzo include il ripristino dell'applicazione in uno stato irrecuperabile.

Dai commenti posso vedere che forse la mia risposta potrebbe usare un po 'di espansione.

Per "non fidarti mai degli input", intendo semplicemente che non puoi presumere che riceverai sempre informazioni valide e affidabili da sistemi a monte o a valle, e quindi dovresti sempre disinfettare quell'input al meglio delle tue capacità, o rifiutare esso.

Un argomento emerso nei commenti che affronterò a titolo di esempio. Sebbene sì, devi fidarti del tuo sistema operativo in una certa misura, non è irragionevole, ad esempio, rifiutare i risultati di un generatore di numeri casuali se gli chiedi un numero compreso tra 1 e 10 e risponde con "bob".

Analogamente, nel caso dell'OP, è necessario assicurarsi che l'applicazione accetti solo input validi dal servizio upstream. Quello che fai quando non va bene dipende da te e dipende molto dall'effettiva funzione aziendale che stai cercando di realizzare, ma minimamente lo registreresti per il debug successivo e in caso contrario assicureresti che la tua applicazione non vada in uno stato irrecuperabile o insicuro.

Anche se non puoi mai sapere ogni possibile input che qualcuno / qualcosa potrebbe darti, puoi certamente limitare ciò che è consentito in base ai requisiti aziendali e fare una sorta di whitelist di input basato su quello.

Sì certo. Ma cosa ti fa pensare che la risposta potrebbe essere diversa?

Sicuramente non vuoi lasciare che il tuo programma si comporti in modo imprevedibile nel caso in cui l'API non restituisca ciò che dice il contratto, vero? Quindi almeno devi affrontare un simile comportamento in qualche modo . Una forma minima di gestione degli errori vale sempre lo sforzo (molto minimo!) E non ci sono assolutamente scuse per non implementare qualcosa del genere.

Tuttavia, quanto sforzo dovresti investire per affrontare un caso del genere dipende fortemente dal caso e può essere risolto solo nel contesto del tuo sistema. Spesso può essere sufficiente una breve registrazione e lasciare che l'applicazione termini correttamente. A volte, sarà meglio implementare una gestione dettagliata delle eccezioni, gestendo diverse forme di valori di ritorno "errati" e forse sarà necessario implementare una strategia di fallback.

Ma fa davvero la differenza se stai scrivendo solo un'applicazione di formattazione di fogli di calcolo interna, da utilizzare da meno di 10 persone e in cui l'impatto finanziario di un incidente dell'applicazione è piuttosto basso, o se stai creando una nuova guida autonoma in auto sistema, in cui un arresto anomalo dell'applicazione può costare la vita.

Quindi non ci sono scorciatoie per riflettere su ciò che stai facendo , usare il tuo buon senso è sempre obbligatorio.

Il principio di robustezza - in particolare, "sii liberale in ciò che accetti" metà di esso - è una pessima idea nel software. È stato originariamente sviluppato nel contesto dell'hardware, dove i vincoli fisici rendono le tolleranze ingegneristiche molto importanti, ma nel software, quando qualcuno ti invia input non corretto o altrimenti improprio, hai due scelte. Puoi rifiutarlo (preferibilmente con una spiegazione di cosa è andato storto) oppure puoi provare a capire cosa avrebbe dovuto significare.

EDIT: Si scopre che mi sono sbagliato nella dichiarazione di cui sopra. Il principio di robustezza non proviene dal mondo dell'hardware, ma dall'architettura di Internet, in particolare RFC 1958 . Afferma:

3.9 Sii severo quando invii e tollerante quando ricevi. Le implementazioni devono seguire le specifiche proprio quando si inviano alla rete e tollerare input errati dalla rete. In caso di dubbio, scartare silenziosamente l'input difettoso, senza restituire un messaggio di errore, a meno che ciò non sia richiesto dalle specifiche.

Questo è, chiaramente parlando, semplicemente sbagliato dall'inizio alla fine. È difficile concepire una nozione più errata di gestione degli errori rispetto a "scartare silenziosamente input errati senza restituire un messaggio di errore", per i motivi indicati in questo post.

Vedi anche l'articolo IETF Le conseguenze dannose del principio di robustezza per ulteriori approfondimenti su questo punto.

Mai, mai, mai scegliere questa seconda opzione se non si dispone di risorse equivalenti a team di ricerca di Google per buttare a progetto, perché è quello che ci vuole per elaborare un programma per computer che fa qualcosa di simile a un lavoro decente in quel particolare dominio del problema. (E anche allora, i suggerimenti di Google sembrano usciti dal campo sinistro per circa la metà del tempo.) Se provi a farlo, quello che finirai è un enorme mal di testa in cui il tuo programma cercherà spesso di interpretare input errato come X, quando il mittente intendeva davvero Y.

Questo è negativo per due motivi. Quello ovvio è perché allora hai dei dati cattivi nel tuo sistema. Il meno ovvio è che in molti casi, né tu né il mittente capirete che qualcosa è andato storto fino a molto più tardi lungo la strada quando qualcosa ti è saltato in faccia, e poi improvvisamente hai un grosso e costoso pasticcio da risolvere e nessuna idea cosa è andato storto perché l'effetto evidente è così lontano dalla causa principale.

Questo è il motivo per cui esiste il principio Fail Fast; salva tutte le persone coinvolte nel mal di testa applicandolo alle tue API.

In generale, il codice dovrebbe essere costruito per sostenere almeno i seguenti vincoli quando possibile:

1. Quando viene fornito un input corretto, produce un output corretto.

2. Quando viene fornito un input valido (che può essere o non essere corretto), produce un output valido (allo stesso modo).

3. Quando viene fornito un input non valido, elaborarlo senza effetti collaterali oltre a quelli causati dall'input normale o quelli definiti come segnalazione di un errore.

In molte situazioni, i programmi passano essenzialmente attraverso vari blocchi di dati senza preoccuparsi in particolare della loro validità. Se tali blocchi contengono dati non validi, l'output del programma conterrà probabilmente dati non validi di conseguenza. A meno che un programma non sia specificamente progettato per convalidare tutti i dati e garantire che non produrrà un output non valido anche quando viene fornito un input non valido , i programmi che elaborano il suo output dovrebbero consentire la possibilità di dati non validi al suo interno.

Sebbene sia spesso auspicabile convalidare i dati all'inizio, non è sempre particolarmente pratico. Tra l'altro, se la validità di un blocco di dati dipende dal contenuto di altri blocchi e se la maggior parte dei dati immessi in una sequenza di passaggi verrà filtrata lungo il percorso, limitando la convalida ai dati che lo superano tutte le fasi possono offrire prestazioni molto migliori rispetto al tentativo di convalidare tutto.

Inoltre, anche se si prevede che a un programma vengano forniti solo dati preconvalidati, è spesso utile che mantenga comunque i vincoli di cui sopra in ogni momento pratico. La ripetizione della convalida completa in ogni fase dell'elaborazione costituirebbe spesso un grave calo delle prestazioni, ma la quantità limitata di convalida necessaria per sostenere i vincoli di cui sopra potrebbe essere molto più economica.

Confrontiamo i due scenari e proviamo a giungere a una conclusione.

Scenario 1 La nostra applicazione presuppone che l'API esterna si comporti secondo l'accordo.

Scenario 2 La nostra applicazione presuppone che l'API esterna possa comportarsi in modo errato, quindi aggiungere precauzioni.

In generale, esiste la possibilità che qualsiasi API o software violi gli accordi; potrebbe essere dovuto a un bug o a condizioni impreviste. Anche un'API potrebbe avere problemi nei sistemi interni con risultati imprevisti.

Se il nostro programma è scritto presupponendo che l'API esterna aderisca agli accordi ed eviti di aggiungere precauzioni; chi sarà la parte che affronterà i problemi? Saremo noi, quelli che hanno scritto il codice di integrazione.

Ad esempio, i valori null selezionati. Ad esempio, secondo l'accordo API, la risposta dovrebbe avere valori non nulli; ma se viene improvvisamente violato il nostro programma si tradurrà in NPE.

Quindi, credo che sarà meglio assicurarsi che l'applicazione disponga di un codice aggiuntivo per affrontare scenari imprevisti.

È sempre necessario convalidare i dati in arrivo, immessi dall'utente o in altro modo, quindi è necessario disporre di un processo da gestire quando i dati recuperati da questa API esterna non sono validi.

In generale, qualsiasi giuntura in cui si incontrano sistemi extra-organizzativi dovrebbe richiedere autenticazione, autorizzazione (se non definita semplicemente dall'autenticazione) e convalida.

In generale, sì, devi sempre proteggerti da input errati, ma a seconda del tipo di API, "guardia" significa cose diverse.

Per un'API esterna a un server, non si desidera creare accidentalmente un comando che si arresti in modo anomalo o comprometta lo stato del server, quindi è necessario proteggerlo.

Per un'API come ad esempio una classe di contenitore (elenco, vettore, ecc.), Generare eccezioni è un risultato perfettamente corretto, compromettere lo stato dell'istanza di classe può essere accettabile in una certa misura (ad esempio un contenitore ordinato dotato di un operatore di confronto difettoso non lo farà essere ordinati), anche l'arresto anomalo dell'applicazione potrebbe essere accettabile, ma compromettere lo stato dell'applicazione, ad esempio scrivere in posizioni di memoria casuali non correlate all'istanza della classe, molto probabilmente no.

Per dare un'opinione leggermente diversa: penso che possa essere accettabile lavorare con i dati che ti vengono dati, anche se viola il suo contratto. Questo dipende dall'uso: è qualcosa che DEVE essere una stringa per te, o è qualcosa che stai solo visualizzando / non usi ecc. In quest'ultimo caso, semplicemente accettalo. Ho un'API che necessita solo dell'1% dei dati forniti da un'altra API. Non potrebbe importarmi di meno che tipo di dati siano nel 99%, quindi non lo controllerò mai.

Deve esserci un equilibrio tra "avere errori perché non controllo abbastanza i miei input" e "rifiuto dati validi perché sono troppo severi".

La mia opinione su questo è sempre, controllare sempre ogni input al mio sistema. Ciò significa che ogni parametro restituito da un'API deve essere verificato, anche se il mio programma non lo utilizza. Tendo anche a verificare la correttezza di tutti i parametri che invio a un'API. Ci sono solo due eccezioni a questa regola, vedi sotto.

Il motivo del test è che se per qualche motivo l'API / input non è corretto il mio programma non può fare affidamento su nulla. Forse il mio programma era collegato a una vecchia versione dell'API che fa qualcosa di diverso da quello in cui credo? Forse il mio programma si è imbattuto in un bug nel programma esterno che non è mai successo prima. O peggio ancora, succede sempre ma a nessuno importa! Forse il programma esterno viene ingannato da un hacker per restituire cose che possono danneggiare il mio programma o il sistema?

Le due eccezioni al test di tutto nel mio mondo sono:

1. Prestazioni dopo un'attenta misurazione delle prestazioni:

   • mai ottimizzare prima di aver misurato. Il test di tutti i dati immessi / restituiti richiede spesso un tempo molto piccolo rispetto alla chiamata effettiva, quindi rimuoverlo spesso consente di risparmiare poco o nulla. Conserverei comunque il codice di rilevamento degli errori, ma lo commenterei, magari con una macro o semplicemente commentandolo.

2. Quando non hai idea di cosa fare con un errore

   • ci sono momenti, non spesso, in cui il tuo progetto semplicemente non consente la gestione del tipo di errore che potresti trovare. Forse quello che dovresti fare è registrare un errore, ma non ci sono errori di registrazione nel sistema. È quasi sempre possibile trovare un modo per "ricordare" l'errore che consente almeno a te come sviluppatore di verificarlo in seguito. I contatori di errori sono una buona cosa da avere in un sistema, anche se si sceglie di non avere la registrazione.

Esattamente come controllare attentamente gli input / i valori di ritorno è una domanda importante. Ad esempio, se si dice che l'API restituisce una stringa, verificherei che:

• il tipo di dati actully è una stringa

• e quella lunghezza è compresa tra i valori minimo e massimo. Controlla sempre le stringhe per la dimensione massima che il mio programma può aspettarsi di gestire (restituire stringhe troppo grandi è un classico problema di sicurezza nei sistemi in rete).

• Alcune stringhe dovrebbero essere controllate per caratteri o contenuti "illegali" quando ciò è rilevante. Se il tuo programma potrebbe inviare la stringa per dire un database in un secondo momento, è una buona idea controllare gli attacchi al database (ricerca di SQL injection). Questi test vengono eseguiti meglio ai confini del mio sistema, dove posso individuare da dove proviene l'attacco e posso fallire presto. Fare un test di iniezione SQL completo potrebbe essere difficile quando le stringhe vengono successivamente combinate, quindi quel test dovrebbe essere fatto prima di chiamare il database, ma se si possono trovare alcuni problemi in anticipo può essere utile.

Il motivo del test dei parametri che invio all'API è quello di essere sicuro di ottenere un risultato corretto. Ancora una volta, fare questi test prima di chiamare un'API potrebbe sembrare superfluo, ma richiede pochissime prestazioni e potrebbe rilevare errori nel mio programma. Quindi i test sono più preziosi quando si sviluppa un sistema (ma al giorno d'oggi ogni sistema sembra essere in continuo sviluppo). A seconda dei parametri i test possono essere più o meno approfonditi, ma tendo a scoprire che spesso è possibile impostare valori min e max consentiti sulla maggior parte dei parametri che il mio programma potrebbe creare. Forse una stringa dovrebbe sempre avere almeno 2 caratteri e contenere al massimo 2000 caratteri? Il minimo e il massimo dovrebbero essere all'interno di ciò che l'API consente poiché so che il mio programma non utilizzerà mai l'intera gamma di alcuni parametri.