Qualcuno ha mai pensato di farlo?

Sì, in realtà si è parlato esattamente di questo al defcon 21 ( video, diapositive).

La loro conclusione è stata che lavorare con i codici di risposta come sicurezza offensiva a volte può comportare un grave rallentamento degli scanner automatici, degli scanner non funzionanti e un'enorme quantità di falsi positivi o falsi negativi (ovviamente farà poco o niente per le scansioni manuali).

Sebbene la sicurezza per oscurità non dovrebbe mai essere la tua unica difesa, può essere utile come difesa in profondità (un altro esempio: si consiglia di non trasmette i numeri di versione di tutti i componenti utilizzati).

D'altra parte, un'API REST dovrebbe essere il più pulita possibile e rispondere con codici HTTP intenzionalmente errati può creare confusione per sviluppatori e client legittimi (questo è un po 'meno un problema per i browser, dove gli utenti in realtà non vedono i codici). Per questo motivo non lo consiglierei nel tuo caso, ma è comunque un'idea interessante.

In realtà non rallenterà un utente malintenzionato in misura apprezzabile, ma causerà fastidio a tutti gli sviluppatori futuri che lavorano sulla tua piattaforma. Potrebbe anche far sì che alcune caratteristiche interessanti delle tue librerie di richieste HTTP non siano così belle, poiché funzionano sulla base di informazioni errate.

Questa è una forma molto debole di sicurezza attraverso l'oscurità. Quando si progetta un sistema come questo, si dovrebbe pensare di rallentare un aggressore di centinaia di anni, non di decine di minuti, altrimenti si perde comunque.

Invece di restituire un "401 Non autorizzato", perché non restituire, ad es. "305 Use Proxy", cioè intenzionalmente confuso.

Sì, confonderà un attaccante. Ma per uno addestrato, potrebbe non durare più di due secondi netti. E i codici di stato non sono poi così utili, principalmente solo quando si forzano i nomi dei file.

Supponiamo che io abbia una chiave valida e posso osservare che restituisci codici di 200 intervalli per la mia autenticazione. Se cambio un po 'nella mia chiave, e per ogni richiesta restituisci 305s, penserò immediatamente "Hmm. Sembra che lo sviluppatore possa aver sbagliato". Se restituisci codici casuali, saprò che è stato apposta e li ignoro.

la difficoltà nel decodificare un'app iOS si spera scoraggerà tutti tranne gli hacker più determinati

Sì, ma dal momento che ne basta uno per pubblicarlo, di nuovo lo sta solo rallentando ..

Questa è sicurezza attraverso l'oscurità, vale a dire che non fornisce molta sicurezza. La soluzione che stai suggerendo rallenterà solo un utente malintenzionato, non gli impedirà di utilizzare il proprio client. In effetti, il tuo metodo di crittografia delle richieste, a seconda della tua implementazione, potrebbe effettivamente rendere la tua applicazione meno sicura aprendo attacchi ad altre parti del sistema crittografico. Il tuo impegno sarebbe meglio spendere cercando di proteggere le funzioni API stesse (ad es. Test di penna e proteggerle da attacchi come l'iniezione SQL), piuttosto che tentare di impedire l'accesso a client non autorizzati.

Ma l'utente STA già utilizzando il tuo protocollo.

Il tuo problema è che l'interfaccia del tuo server di ciò che l'utente può fare non è sicura!
Tu decidi quali dati inviare il tuo server a chi!
(Ciao, cari giornali online. Sì, ti sto guardando!)

Progettalo , supponendo che l'utente sia il client. Non il tuo codice. Perché lo è. Non dovrebbe importare quale client viene utilizzato.
La tua app viene eseguita su una CPU che è sotto il controllo hardware dell'utente. Il tuo codice è solo un elenco di comandi / dati e l'utente e la sua CPU possono elaborarlo come preferiscono. Compreso non elaborarlo.
Decide cosa fa la sua CPU. Non confondere la sua grazia di accettare il codice della tua app così com'è con un diritto all'esecuzione cieca. Sei tu quello di cui si fida qui e quella fiducia è molto fugace.
Soprattutto con tattiche squallide come questa.

In ogni caso: dai all'utente la chiave di crittografia e tutto il resto e ti aspetti che per non usarlo da solo, perché lo metti da qualche parte nel tuo cestino di codice. … Proprio come DRM, quello è olio di serpente e non può mai funzionare.
Basta una persona per trovare dove metti la chiave. (Sarei io, ad esempio.) Tutti gli altri devono solo cercarlo su Google.

Ma sono sorpreso che tu pensi solo a crittografare il protocollo contro l'utente, invece che per la sua protezione dagli attacchi man-in-the-middle.
Supponendo che il motivo per cui questo viene solitamente fatto (Sì, sto parlando di nuovo con te "industria dei contenuti".): Se il tuo utente è il tuo nemico, forse dovresti cercare un modello di business basato sull'equità e su un vantaggio per tutti, invece di derubare l'utente e dover affrontare il contraccolpo.

PS: ignora tutte le risposte "sicurezza attraverso l'oscurità". Questo è un errore che si traduce in un comportamento corretto ma è ancora basato su presupposti non validi. Usarlo come argomento è, nella migliore delle ipotesi, amatoriale e poco competente.
In realtà, tutta la sicurezza passa attraverso l'oscurità. Alcuni sono solo più oscuri (= meglio mascherati). La vera ragione per cui questo è negativo, è perché ciò che chiamiamo sicurezza reale è un miliardo volte più oscuro, dandogli un'oscurità effettiva (statistica) affidabile, al contrario di molto semplice oscurità che è semplicemente troppo probabile perché qualcuno se ne venga fuori dal nulla.

Come altri hanno già spiegato, la sicurezza per oscurità rallenta al massimo un aggressore.

Nel tuo caso specifico, direi che non avrà alcun effetto apprezzabile. Per arrivare a questo punto, il tuo aggressore ha già dovuto decodificare la tua App ed estrarre la chiave privata. Ciò significa che il tuo aggressore non è un idiota e sa cosa sta facendo. Un po 'di oscurità gli costerà meno tempo di quanto ci vuole per implementarlo.

Come altri hanno già detto, stai proponendo di utilizzare Security by Obscurity. Sebbene questa tecnica abbia il suo scopo, considera quanto segue prima di scegliere di adottare questo approccio:

• Fornire supporto tecnico per la tua API. L'utilizzo di codici di risposta HTTP ingannevoli rende difficile per chiunque altro oltre a te fornire supporto. Devono considerare se la situazione particolare sta effettivamente inviando il codice di risposta corretto o se ne sta inviando uno oscuro. Se decidi di rimanere l'unico contatto per eventuali richieste di supporto, questo non dovrebbe essere un problema.
• Che cos'è un "utente dannoso"? Prestare attenzione quando si classifica una richiesta come dannosa perché può avere effetti negativi. Si supponga che venga determinato che un IP invia traffico dannoso e che vengano utilizzate contromisure. Supponiamo ora che lo stesso IP sia in realtà un proxy con centinaia o migliaia di utenti dietro di esso. Ora hai applicato la tua contromisura a tutti loro. Lo stesso principio può essere applicato per identificare attività dannose nelle intestazioni e / o nel corpo.
• Il codice dell'applicazione è il più lento. La richiesta deve attraversare l'intero stack per arrivare finalmente alla logica di "sicurezza". Questa architettura non si adatta bene ed è lenta. Le richieste errate dovrebbero essere interrotte il prima possibile, che è la premessa per l'utilizzo di Web Application Firewall (WAF).
• Estensione dell'accesso. Se la tua API dovesse diventare accessibile a più client di quelli per cui era stata originariamente progettata, quei nuovi client dovranno essere consapevoli del possibile utilizzo di codici di risposta HTTP ingannevoli.
• Utenti malintenzionati persistenti. Come altri hanno già detto, questa tecnica è solo un acceleratore.

Approccio migliore

Concentra il tuo tempo sulla white list di tutte le richieste valide conosciute. È molto più semplice che cercare di identificare tutte le potenziali richieste errate. Tutto ciò che non appare nella lista bianca dovrebbe ricevere immediatamente un codice di risposta appropriato come HTTP 400 o HTTP 405 se stai filtrando i verbi HTTP (come esempi). Preferibilmente questo accade prima che la richiesta raggiunga il codice dell'applicazione.

Insieme alle richieste consentite dalla white list, assicurati che la tua applicazione sia protetta in base alle Linee guida OWASP. Otterrai risultati di gran lunga migliori trascorrendo il tuo tempo con OWASP, quindi proverai a determinare cos'è un utente malintenzionato e restituirai un oscuro codice di risposta HTTP.

Fondamentalmente, NON PUOI impedire a client non autorizzati di inviare richieste. La cosa più vicina possibile sarebbe eseguire una sorta di controllo crittografico nel client, ma come disse Sherlock Holmes, "ciò che si può inventare, un altro può scoprire". (Lo so per certo, perché ho violato la sicurezza lato client delle persone in diverse occasioni.)

Invece, crea la tua API in modo che chiunque possa usarla utilizzando client personalizzati. Rendilo amichevole. Cosa perdi con questo? Gli aggressori attaccheranno qualunque cosa tu faccia e se rendi la tua API facile da usare, qualcuno inventerà qualcosa a cui non hai mai pensato e renderà il tuo server ancora più grande di quanto avresti mai immaginato potesse essere. Cosa potrebbe essere fatto da un cliente che parla sia con la tua API che con qualcun altro? Quali miriadi di possibilità ci sono e ti farà davvero male permetterle?

Non lo farei. Generalmente significa che stai creando il tuo standard, il che fa sì che:

1. la tua API sia predittiva dopo aver creato una mappa delle tue risposte http al loro significato effettivo. La modifica delle risposte HTTP potrebbe funzionare su alcuni "hacker" che si arrenderebbero dopo pochi tentativi, ma non su altri, più determinati. Vuoi proteggere la tua API solo dal tipo precedente, cioè dai bambini di 11 anni? Non credo.

2. un po 'di confusione per sviluppatori e probabilmente tester, specialmente quelli che sono abituati a operare secondo standard globali.

3. Scegli un altro modo. Ce ne sono sicuramente alcuni. Ho lottato anch'io con lo stesso grattacapo per alcune settimane ultimamente e ho escogitato almeno 2 modi più o meno affidabili per ottenere le restrizioni desiderate [non posso pubblicarle qui].

ol >

Ci sono sicuramente modi migliori e MOLTO più efficaci per ottenere ciò che desideri. Prova a guardare la tua API da una prospettiva diversa ... Se tu fossi un hacker e la tua vita dipendesse dall'hacking di quell'API, cosa faresti per avere successo? Cosa dovrebbe accadere per essere frustrato nei tuoi tentativi di romperlo?

Una buona ragione per non farlo, soprattutto per un'app mobile, è che è molto probabile che la tua app stia già parlando con il tuo server tramite più proxy, ad esempio nella compagnia telefonica, già. La maggior parte delle grandi aziende utilizza proxy sulla propria rete per cercare di proteggere i propri sistemi da contenuti dannosi e molte compagnie telefoniche riducono la qualità del video o delle immagini in transito. Ti renderà anche inutile l'utilizzo delle varie librerie di sistema per HTTP sulla tua piattaforma. Un approccio comunemente utilizzato consiste nel ricavare una chiave o un token da informazioni che è improbabile che l'utente desideri condividere, come l'hashing del nome, dell'indirizzo e dei dettagli della carta di credito. In questo modo, anche se la tua app è stata compromessa, le persone saranno diffidenti nel fornire le informazioni richieste a un programma casuale che hanno scaricato, limitando la capacità di condivisione di qualsiasi attacco provato.

Generalmente non è una buona idea.

Ne ho fatto un uso molto mirato una volta con buoni risultati quando il sito web di un cliente veniva utilizzato da un circuito di riciclaggio di carte di credito rubate. C'erano alcune caratteristiche di identificazione condivise solo dalle transazioni fraudolente, quindi piuttosto che rifiutarle educatamente avrei fatto ritardare la risposta di un paio di minuti (a nessuno piace un sito web che impiega minuti per fare qualcosa) e poi restituire un 500 con il sito messaggio standard "scusa, non sei tu, sono io" per gli errori del server (registrava anche i dettagli da trasmettere alle forze dell'ordine). Abbiamo avuto tre tentativi di transazioni che hanno ottenuto questa risposta da opossum e poi non abbiamo più avuto notizie da loro.

Questo però era:

1. In risposta a qualcosa che sapevamo fosse un attacco piuttosto che essere odioso per gli utenti che hanno un problema.
2. Non una difesa contro un attacco alla sicurezza del protocollo stesso, ma a livello umano superiore.
3. Spiegabile attraverso altre spiegazioni , cioè stavamo fingendo di avere un sito Web davvero schifoso in una situazione in cui ciò era plausibile (ci sono molti siti Web schifosi là fuori) e non eravamo un target specifico (i criminali sarebbero passati a qualcun altro).

Gli utenti che hanno un problema dovrebbero essere aiutati, non abusati. "Non posso farlo perché non sei autorizzato correttamente" si rifiuta di fare qualcosa in modo utile. "Non posso farlo perché devi usare un proxy" quando qualcuno non ha bisogno di usare un proxy è offensivo. Essere deliberatamente inutili è appropriato solo quando sai di essere stato attaccato e quindi non dovrebbe sembrare un messaggio ovviamente fasullo o non hai nascosto nulla (potenzialmente hai effettivamente rivelato qualcosa se non viene utilizzato lo stesso stato fasullo per ogni errore del client).

Detto questo, è appropriato adottare misure per fare in modo che gli stati non perdano informazioni. Per esempio. è accettabile (come descritto come tale negli standard) per / admin / fino a 404 sebbene sarebbe 200 in un altro caso (utente autorizzato, indirizzi IP client consentiti, ecc.) In alternativa se / members / my-profile sarà 200 per un utente autorizzato e 403 o 401 altrimenti, quindi se / members / fdsasafdasfwefaxc sarà 404 per un utente autorizzato, è una buona idea che sia 403 o 401 per l'utente non autorizzato. Non si tratta tanto di sicurezza dall'oscurità quanto di considerare quali URI si riferiscono alle risorse per essere uno dei bit di informazione che vengono protetti.