Gebruik van cryptografie voor veilige jQuery/REST webapplicaties Frans van Buul Inter Access 1
Frans van Buul
[email protected]
2
De Uitdaging Rijke en veilige webapplicaties Een onveilig en traag netwerk
Onveilige en diverse browsers als clients 3
Agenda
Web Frameworks
hebben zo hun problemen, maar er is een aantrekkelijk alternatief:
State
…maar dat is goed op te lossen met….
Demo (screenshots) en conclusies
REST
dat echter een nieuw probleem lijkt te introduceren…
Crypto
… en dat werkt echt! 4
Web Frameworks: allemaal anders Grails Play! Struts Wicket
JSF Tapestry Web Forms
FubuMVC ASP.NET MVC Ruby on Rails Spring MVC MonoRail
5
URL/data HTTP Request
Request processor
Mechanisme voor action binding Mechanisme voor data binding
HTML HTTP Response
View Rendering Engine
View Definitie Taal
Noties van ‘component’ en ‘template’
Web Frameworks: veel hetzelfde
6
Web Frameworks: introductie van Ajax Functionaliteit
Framework
Pre-Ajax webapplicaties
MVC-like frameworks
Webapplicaties met Ajax addons (“unobtrusive”)
MVC-like frameworks met Ajax addons
Ajax-centric webapplicaties
Nog steeds hetzelfde!
7
“Partial Submit” URL/data HTTP Request
Request processor
Mechanisme voor action binding Mechanisme voor data binding
HTML HTTP Response
View Rendering Engine
“Partial View”
View Definitie Taal
Noties van ‘component’ en ‘template’
Web Frameworks: Typische omgang met Ajax
Views met JavaScript 8
Conclusie: Web Frameworks vs. moderne apps Onnodig slechte performance. Presentatielogica verdeeld over JavaScript en serverside code; slechte onderhoudbaarheid. Risico op business logica in JavaScript.
9
‘Alternatieve architectuur’ URL/data HTTP Request
Statische pagina’s met JavaScript Kale webserver
HTML HTTP Response
Client-side presentatielogica
URL/data HTTP Request Applicatieserver Data HTTP Response
Server-side business-logica 10
REST anno 2000 Representational State Transfer ‘Architectural style’ gedefinieerd in de dissertatie van Roy Fielding. Voordelen Scalability Visibility Reliability
Constraints Uniform (HTTP) Layered Code on demand (Applets) Caching Stateless server
REST anno 2012 Webservices WS-* / SOAP is nogal een drama. REST gebruikt als alternatief. Publieke web-API’s vaker REST dan SOAP. Standaard frameworks voor efficiënt implementeren van REST-services (JAX-RS, WCF). Webapplicaties Zeer volwassen en rijke JavaScript libs (jQuery); nieuwe invulling van ‘code on demand’.
Dus dit zou moeten werken... ‘code on demand’
jQuery
RESTful services
State… traditionele benadering
Session id
Session id
Session data
Session id
Session data
Session id
Session data
Client Server
… dat is niet RESTful!
RESTful State
Session data Client
Server
… lijkt niet erg veilig. Confidentiality Integrity
Doel van crypto-oplossing
Client
Server
Bouwsteen: Symmetrische versleuteling
Vertrouwelijke gegevens Encryptiefunctie Keuze: AES
Client
(+timestamp, random data)
Server
Bouwsteen: Hash-based Message Authentication Code
Authentieke gegevens
Authentieke gegevens
Hashfunctie Keuze: HMAC-SHA1
Client
Server
Niet een bouwsteen: asymmetrische crypto Asymmetrische crypto (in combinatie met PKI) wordt vaak gebruik voor versleuteling + ondertekening. Hier niet: –
Overbodig: geen key distributie issues want keys op server.
–
Onhandig: véél trager (factor 1000)
–
Onhandig: veel groter (factor 4 – 8)
Ook non-crypto bouwstenen Unicode String
JSON
Object
UTF-8
HMAC-SHA1
Byte Array
Base64
CookieSafe String
URL Encoding
ASCII String
AES
Alles samen
Client
Server
Implementatie: standaard bouwstenen! AES HMAC-SHA1 UTF-8
Standaard Java
URLEncoding Base64: Apache Commons Codec JSON: Google Gson
+/- 500 regels ‘eigen’ code (inclusief commentaar en whitespace)
Demo Niet-ingelogde gebruiker komt op inlogpagina. JavaScript wordt actief:
23
Demo
24
Demo
25
Demo
26
Conclusies Bij Inter Access nu één project op deze technologie gedaan; overwogen als standaard voor toekomst. Positief: –
Implementatie van crypto is eenvoudig.
–
Uitstekende performance.
–
Alles bij elkaar beter onderhoudbare code.
Nadeel: –
Weinig standaard componenten (jQuery UI).
–
Deels ‘eigen framework’ code voor dialogen.
–
Developers moeten relatief complexe JavaScript maken.
27
