L'esposizione delle informazioni sulle eccezioni nel servizio Web rappresenta un rischio per la sicurezza? [duplicare]

L'API non deve esporre alcuna informazione interna, cioè tracce dello stack o simili. Come hai realmente notato, potrebbero perdere informazioni che potrebbero essere utilizzate per attaccare l'implementazione.

Inoltre, di solito sono rilevanti solo per lo sviluppatore dell'API e non per l'utente dell'API. Questi utenti si aspettano comunque messaggi di errore corretti e non qualche strano messaggio in cui avrebbero bisogno di chiedere allo sviluppatore dell'API prima cosa significhi e lo sviluppatore avrebbe bisogno di guardare il codice sorgente. Quindi questo potrebbe essere meno un problema di sicurezza, ma più un problema di usabilità dell'API se si butta la traccia dello stack all'utente piuttosto che qualcosa di significativo per l'utente.

Di solito ci sono due tipi di eccezioni:

• Eccezioni previste, come valori di input non validi; o errore di autenticazione; o per chiedere un oggetto inesistente. Quindi puoi (e dovresti) essere preparato ad affrontare questo genere con garbo, con un codice di errore e un messaggio descrittivi e documentati. In questo caso non vi è alcun punto di traccia di stack.

• Eccezioniinterne(oimpreviste):indisponibilitàdeldatabase;memoriainsufficiente;bugnelcodicecheportaa NPE . Inoltre, non vi è alcun punto nello stack trace per l'utente API . Tu (come sviluppatore), tuttavia, sei interessato a tali tracce dello stack. Per la maggior parte dei casi, l'utente stesso non può risolvere questo problema, quindi deve contattare lo sviluppatore. Puoi allegare crittografato traccia dello stack a un messaggio generico "mi dispiace", in modo che tu lo sviluppatore possa risolvere più facilmente il problema degli utenti:

È un problema di usabilità rispetto a sicurezza .

• Un'API , specialmente uno REST, dovrebbe essere amichevole , auto-documentato. Questo include dare errori amichevoli che indicano il errore esatto, possibile causa, stack, ecc.

• D'altra parte, pensa che friendly sia rischioso ...

Quindi la risposta è: Sì, si tratta di un problema di sicurezza. Le informazioni aiuteranno un potenziale utente malintenzionato a saperne di più sulla tua API.

modi comuni per farlo?

In ASP.NET hai impostato in web.config per controllare quanto verbosi sono gli errori ( CustomErrors ).

Le impostazioni predefinite mostrano un errore sicuro generico, tranne che stai navigando dallo stesso computer , quindi mostra un errore completo. In questo modo gli sviluppatori nei loro computer locali possono vedere gli errori ma una volta distribuiti in un ambiente non è possibile visualizzare informazioni dettagliate sull'errore.

<?xml version="1.0"?>
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>