AJAX è fondamentalmente insicuro?

Risposta breve: sei corretto, dipende da come si codifica la pagina.

Risposta più lunga:
Non c'è nulla di intrinsecamente insicuro su AJAX, per la maggior parte è suscettibile alla maggior parte delle stesse minacce e attacchi delle normali pagine Web.
Tuttavia, ci sono anche alcuni attacchi specifici per AJAX, ma di nuovo dipende da come lo si codifica. Ma questo non lo rende "fundamentally insecure" .

Tuttavia, vi è spesso un problema diverso e sottile in gioco: mentre (la maggior parte) i programmatori alla fine hanno messo in evidenza il fatto che qualsiasi cosa "nascosta" nella pagina web, o nella comunicazione tra browser e server, non sono protetti dall'utente ( anche se è passato troppo tempo perché il groking diventi mainstream), è ancora diffusa l'idea che le chiamate AJAX siano in qualche modo "speciali". Pertanto, spesso vengono utilizzati in modo improprio ... Ad esempio, vedo ancora molti siti con SSL su tutte le pagine normali, ma i dati sensibili effettivi circolano liberamente su AJAX su HTTP non crittografato.

In breve, in qualche misura anche le tue opinioni sui cowgirl sono parzialmente in colpa - aspettando che AJAX sia in qualche modo "speciale".

La risposta dipende dalle risorse che stai cercando di proteggere e dal tuo modello di minaccia.

Se sei preoccupato per l' utente che attacca il tuo contenuto della pagina web e il codice AJAX al suo interno e scopri qualcosa nella pagina che non volevi che loro sapessero, allora è vero che AJAX non è sicuro, poiché l'utente ha accesso fisico all'ambiente in cui viene eseguita la pagina Web. Un esempio di questo è l'esempio di gioco che Thomas descrive in una delle altre risposte. Se la pagina implementa un'interfaccia di gioco e include informazioni su dove sono gli altri giocatori, l'utente può capire tutto ciò e "vedere attraverso i muri" e potrebbe imbrogliare.

D'altra parte, se sei preoccupato per l'utente che attacca il tuo server e ritieni che l'utente possa modificare qualsiasi cosa nella pagina web e il codice associato, prendi le dovute precauzioni per proteggere il tuo server contro qualsiasi cosa l'utente possa fare in tali circostanze, quindi come altri hanno notato che AJAX è altrettanto sicuro di qualsiasi altra buona tecnica di programmazione, e dipende in gran parte dal codice lato server, come sempre. Aggiornamento : ma farlo può essere complicato e, come sottolinea @iivel, una pagina OWASP spiega le varie cose da tenere a mente: Test delle vulnerabilità AJAX (OWASP-AJ-001)

Tutto questo si applica ad altre tecniche lato client come applet Flash o Java o Silverlight, ecc., si applica anche a Word o PDF - se si inserisce del contenuto (come la meta informazione su chi è l'autore o il proprietario del il software è, o il contenuto che viene "cancellato" sovrapponendolo con il bianco digitale) che non pensate che la gente vedrà o non vi ricordate nemmeno che viene incluso automaticamente, quindi sarete tristemente delusi quando l'utente esperto guarda i bit.

È molto importante pensare attentamente al modello di minaccia e verificare se i tuoi strumenti lo affrontano.

AJAX significa: "una pagina web con qualche codice in esso - e intendo proprio così". Non esiste una chiara distinzione tra AJAX e una pagina "normale", poiché le pagine normali potrebbero contenere anche elementi di script. AJAX è più un modo per affermare che intendi spingere alcune parti della tua applicazione nel browser client.

Un'applicazione basata su Web viene eseguita sull'unione del server e del client. Si è tentati di fare il client un po 'di più di una semplice visualizzazione delle pagine inviate dal server, perché:

• aumenta la reattività dell'interfaccia (l'esperienza dell'utente è migliorata);
• potrebbe ridurre il carico di rete (molte operazioni basate su GUI possono essere eseguite sul client senza parlare al server);
• potrebbe ridurre il carico di elaborazione (più lavoro per la macchina client, meno lavoro per il server).

Un'analogia può essere fatta con i giochi online, ad es. con giochi FPS. Diversi utenti si sparano l'un l'altro. Il server tiene traccia di dove sono tutti e chi uccide chi. Per tali giochi, la reattività dell'interfaccia è di fondamentale importanza; di conseguenza, è completamente inimmaginabile che il server calcoli tutto e invii solo frame da mostrare al client. Invece, i client devono eseguire il pesante lavoro di rendering 3D e il server invia semplicemente mappe di livello e aggiornamenti della posizione dei giocatori.

A quel punto, entra in gioco la sicurezza, a causa della regola fondamentale:

• Dal punto di vista del server, il cliente è un cattivo.

Nell'analogia del gioco, ciò significa che il server deve fidarsi del codice client: per il rendering 3D, il cliente deve conoscere la mappa del livello e la posizione di tutti gli altri giocatori. Sarebbe facile, per un cliente modificato, mostrare la mappa al giocatore e individuare gli altri giocatori. In realtà, ci sono molti imbroglioni là fuori, ei motori di gioco usano sofisticate tecniche di offuscamento del codice per cercare di scoraggiare la maggior parte degli imbroglioni (perché i cheaters uccidono il divertimento, e senza il divertimento i giocatori se ne vanno).

Questo illustra il problema della sicurezza AJAX: poiché è un codice che viene eseguito sul lato client, qualunque cosa faccia non può essere considerata attendibile dal server, anche se l'utente è debitamente autenticato (sapendo chi fa non lo rende automaticamente legittimo). Questo di solito non è un problema per le interazioni relative alla GUI, a meno che non ci siano problemi di sicurezza sulla GUI, come la funzione "visualizzazione della mappa di livello" nell'analogia di gioco. Il modo corretto di analizzare la sicurezza delle applicazioni basate sul Web è di supporre che ogni singolo byte emesso dal server sia noto al client e che ogni byte del client sia potenzialmente dannoso.

Come esempio approssimativo, considera l'iniezione SQL. Un modo per evitare attacchi SQL injection è assicurarsi che l'elemento dati che si collega alla richiesta non abbia caratteri speciali senza caratteri di escape. Questo passaggio di convalida DEVE essere eseguito sul server. Non puoi farlo in modo sicuro in AJAX, poiché qualsiasi cosa faccia AJAX può essere aggirata dal client.

OWASP ha un buon articolo su questo argomento. Il problema principale con AJAX è una superficie di attacco più ampia, insieme ad alcuni attacchi che sono realisticamente possibili solo su applicazioni AJAX (hack JSON o hacking di eventi del client).

Test delle vulnerabilità AJAX (OWASP-AJ-001)
link

Per la natura asincrona dell'applicazione, e quindi i servizi richiesti, più aree sono suscettibili agli attacchi. Le strutture di dati e i metodi degli eventi stessi sono anche più suscettibili agli attacchi di quanto sarebbe normalmente un viaggio di andata e ritorno da posta.