Ajax e javascript, chiudere la stalla quando i buoi sono già scappati?

Programmazione e animali simili — root on January 7, 2007 at 4:48 pm

Mi sono entusiasmato, come tutti, quando ho visto le prime applicazioni ajax like. Ho provato a combinare qualcosa riscrivendo qualche esempio e cercando di capire come funzionassero le chiamate e se ci fosse qualche modo veloce per scrivere interfacce ajax.
Nella mia ricerca ho dato un occhio a metodologie per creare pagine ajax più o meno complicate e su diverse piattaforme, da Openlaszlo a GWT , e anche framework come moo.fx a script.aculo.us.
E’ chiaro (almeno a me :D) che quella del web 2.0 non è “una bolla”, “una moda” per la costruzione delle interfacce. Effettivamente (dove viene usato in modo corretto) permette un interazione e una presentazione delle informazioni che fin ora non ha avuto eguali se non in interfacce pesanti e proprietarie (Flash e Java Applet [ora GPL n.d.r. ma non è questo il punto]).
Sono stato quasi deriso quando ho sollevato i primi dubbi sui pericoli che può celare ajax sul web e la programmazione stessa ajax like. Non son qui per dire “l’avevo detto!” “l’avevo detto!” ma fare qualche riflessione utile a chi legge ed è interessato alla problematica.

Per trovare un po’ di articoli circa best pratices e esplicazioni più o meno tecniche su ajax e co. basta il sontro amico Google, ve ne riporto qualcuno abbastanza interessante che ho trovato sul mio cammino:

Ajax Security Basics - Security Focus
Community Creators, Secure your Code!A list apart
What You Should Know About AJAX Security: 24 TutorialsMax Kiesler

AJAX (Asynchronous Javascript and XML) Security Suggested LinksCgi Security

Proprio spulciando nel’ultimo c’è un interessante disamina su quanto i timori verso l’approccio Ajax like siano in parte infondati:

Myth-Busting AJAX (In)securityWhiteHat Security di Jeremiah Grossman

La tesi sostenuta nell’articolo si può riassumere in:

AJAX technology makes website interactivity smoother and more responsive. That’s it. Nothing changes on the web server, where security is supposed to reside. If that’s the case, thenwhat is everyone talking about? Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadlyscripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged.

Trad:

La tecnologia AJAX fa si che i siti siano più agili e responsivi. E questo è tutto. Non cambia nulla sui Web Server, dove si suppone ci possano essere problemi di sicurezza. Quindi se è così, dov’è il problema di cui tutti parlano? Sulle “strade telematiche” si dice che ajax sia il quid che porta a un ampia superfice di attacco, aumento della complessità, fake requests, denial of service, cross-site-scripting, compromissione della sicurezza client-side, etc. In realtà queste problematiche esistono da prima di AJAX. Le best pratices circa la programmazione rimangono le stesse (Trad di CM).

Sono totalmente d’ accordo. Tutto l’ articolo merita di essere letto, ne voglio sintesizzare puntualizzare alcuni argomenti.

Does AJAX cause a larger “Attack Surface”? No.

La risposta più esatta secondo me è NI :D.
Non è da tutti mettersi a lavorare in Javascript, la scelta più semplice è includere un framework esistente che permetta di utilizzare procedure Ajax di richiesta al server e di formattazione lato client. Non è l’ inclusione avventata di questi pezzi di codice (e il bad habit di non tenersi allineati all’head del framework) un modo di allargare il numero dei possibili siti attaccabili attraverso vulnerabilità del framework che hanno in comune?

Does AJAX make Cross-Site Scripting (XSS) attacks worse? I hope not.

Sono d’ accordo, e quello che è importante è che la questione ajax abbia messo in evidenza la necessità di tenere sotto controllo la “Javascript side of the moon”, perché (come dice anche Grossman), tutto quello che può essere fatto con XHR, può essere anche fatto con javascript puro.
A metà tra le problematiche XHR e Javascript si pone ad esempio la tecnica chiamata Prototype Hijacking presentata da due italiani al 23rd Chaos Communication Congress.

Una cosa è certa (e qui prendo a braccetto il WhiteHat guy) i metodi per implementare dei servizi web sicuri partono dall’implementazione:

1) Pensare alla sicurezza sin dal design dell’applicazione;
2) Validare tutti gli input;
3) Utilizzare librerie sicure;
4) Configurazione adeguata delle componenti;
5) Trovare e fixare le vulnerabilità.

Vabbè qualcosa si può fare insomma, in qualche modo un pò di bistecche si possono ancora fare anche con questi buoi :D.
(humm.. meglio un buffalocheese)

0 Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. | Consequentia Mirabilis