Cloud Computing2

AJAX in the Cloud

AJAX Database Programming

Brent Hamby & Geoff HendreyOctober 21st 2008

Agenda

In this talk we will cover 3 important questions:

1. What are today's options for cloud databases, and why can'tthey be easily accessed by pure JavaScript APIs?

2. What are the gaps between the Web 1.0 database securitymodel, and the unforgiving JavaScript environment?

3. How can we create a new AJAX/RIA security paradigm forDatabase as a Service (DaaS)?

The Journey

Who we are• From LBS industry• Building mapping web apps in the old days

o huge time and development costso complex geographic information systemso poor user interfaces

• Google Maps: the inspiration of the AJAX revolutiono Object Oriented JavaScript API'so Faster, Cheaper, Better appso initial resistance from big GIS.

haters• Gave birth to the Mash-up application paradigm

Our mission

Apply lessons of the Google maps revolution to Database in thecloud

Our project:

NextDB.net : the hosted AJAX Database

The Cloud Computing Landscape

Establishing a vocabulary:

1. CLOUD SERVERS2. CLOUD VOLUMES3. CLOUD APPLICATION FRAMEWORKS4. CLOUD DATABASES

Cloud ServersGeneral purpose operating systems and executionenvironmentsTrends:• virtualization• provisioning tools• elasticity (ability to add servers to respond in near real-time

offered loads)Examples:• GoGrid• EC2• Flexiscale

Conclusion: Hosted virtualized servers could be used to deploya database, but a virtual server is not a Cloud Database

Cloud Volumes

• Behaves like a block device• Install filesystem on top of it• Survives indepently of the virtual server• Amazon Elastic Block Storage (EBS) is the primary example

Conclusion: hosted volumes could be used as storage fordatabase files, but the hosted volume is not in-and-of-itselfCloud Database

Cloud Application Frameworks

A database systems coupled to an application framework. Hosted App Frameworks Have been around forever -think Tomcat + MySQL Web HostingWhy aren't they Cloud Application Frameworks? -maybe they are -but if they are not, it's because they lack SCALABILITY -limited to a slice of resources on a single serverExamples of new generation of Cloud Application Framework -Google App Engine -Combines Python Web 1.0 application scripting withBigTable -Concusion: Not a Cloud Database, although yourapplication in the cloud can access a database in the cloud

Cloud Databases

databases with an API that can be accessed over the web

Amazon Simple Storage Service (S3) -provides a bucket service (e.g. hashmap) -can be accessed from any secure server that can sign itsrequestAmazon SimpleDB -provides a structured data model -An Amazon SimpleDB domain is like a worksheet, items are like rows of data,attributes are like column headers, and values are the data entered in each of the cells. -same security model as SimpleDB

Conclusion: S3 cannot be considered a database by mostmodern definitions. SimpleDB is a Hierarchical CloudDatabase. Neither is a Relational Cloud Database.

Can I Access SimpleDB or S3 from anAJAX/RIA?

• The AWS security model is based on Secret Keys andDigital Signatures

• The Secret Key is used to sign all messages sent from theclient to the server, along with the key ID.

• The Server looks up its copy of the secret key using the KeyID, and checks the signature

• This model implicitly relies on the ability of the messagesigner to keep the key safe.

Secret Keys and Digital Signatures

Rule #1 of AWS security: Secrets must be ....secret"Your Secret Access Key is a secret, which only you and AWS should know. It isimportant to keep it confidential to protect your account. Store it securely in a safeplace...To provide proof that you truly are the sender of the request, you alsoinclude a digital signature calculated using your Secret Access Key."

Rule #1 of AJAX security: There are no secure AJAX clients

Nothing can possibly be digitially signed or hashed by a JSapplication because the secret key itself would becompromised

So how can I access SimpleDB or S3from a RIA/AJAX

You must build a serverside application to act as a secureproxy between the client and AWS:1. formulate and sign AWS requests without compromising the

key2. validate the identity (username/pwd) of your application end

user via a query to SimpleDB or S33. implement Web 1.0-style application logic to control

application behavior based on user's identity established instep 2

Would the Google Maps Mash-up revolution have happened if you had towrite the server side component?(no... obviously)

The Paradox

The RIA/AJAX paradigm relies on a Web 1.0 serversidearchitecture for accessing secure resources such as adatabase.

To understand how to move Cloud databases forward, andeliminate the serverside application, we have to start by goingbackward, to understand what is broken in the RDBMS securitymodel.

The RDBMS Security Model

The modern Relational Database Management System(RDBMS) is knows as a "client-server" database architecturewith a security model designed before the advent of the Web.

The notion of "client" in this context was conceived under thefollowing constraints that DO NOT HOLD for AJAX/RIA:• clients are typically secured behind the same firewall, and

reside on the same LAN (or virtual network) as the server• client are authenticated via the RDBMS's notion of users

and roles ("scott/tiger"...anyone...anyone)• clients, in reality, are trusted applications• because clients are trusted applications, they are free to

execute ad-hoc SQL

Can we apply the RDBMS client/servermodel over the web?

NO!

• To apply the RDBMS client-server model, you need a trustrelationship with every end-user of the application, and anassociated user/role in the RDBMS. That's just ridiculous!(it's table-level security at best, not row-level security)

• Since you can't create an RDBMS user/role for applicationend users, you will get hacked:o Sensitive data will be stolen (SELECT * FROM USER)o Your system will get wiped out (DELETE FROM USERS)

Identity and Security

One of the cornerstones of the relational database model is theconcept of identity. “Identity” is a familiar concept to everyonewho owns a credit card (the credit card number is the card's“identity”). Another for of identiy is a Social Security Number(SSN) that identifies you as a United States Citizen. “Identity” issimply a value that is used to keep track of data. Rows in adatabase table typically have an identity defined by the row'sprimary key (PK).

If your Social Security Number or credit card number is stolen itcan be impossible to “put the genie back in the bottle”.Similarly, if a Primary Key is accessible to an application, ormalicious user, it can be saved and used for maliciouspurposes, like changing the price of a product, or altering datathat should be secure.

The Role of the Primary Key

In a Web 1.0 serverside RDBMS application, primary keys actas a common currency between the serverside application andthe database.

Primary keys and foreign keys form a relationship graphconnecting rows in the database.

Primary keys are a natural mechanism for traversing this graph:

SELECT * FROM ACCOUNT WHERE FK_TO_USER = 19

The dialog between the serversideapplication and the databaseapp: "give me the primary key for USERjohndoe/abc123"(SELECT PK FROM USER WHERE NAME='johndoe'AND PWD='abc123')database: "19"app: "give me the account information corresponding to theuser identified by PK 19"(SELECT * FROM ACCOUNT WHERE FK_TO_USER=19)

As we can see from the dialog above that the database willblindly return the raw identity for the user (think SSN), for anyprimary key. Therefore, the security/integrity of this dialogcannot be maintained if the application code can be tampered,or ad-hoc values can be sent to the database.

Primary Keys Won't Work ForAJAX/RIAPrimary Key is an insecure mechanism for identifying rowsbetween a server and an AJAX/RIA (or any browser-basedapplication).The following is to state the obvious.

primary keys are typically auto-incrementing surrogate keyso divulges hints about number of rows in a tableo can be altered (primary key "math", like "pointer math") to

affect malicious resultso http://bank.com?action=viewbalance&accountPK=2359o hmm...how about I change 2359 to 2360? Will I see

someone else's account balance?For these reasons, nobody in their right mind would passprimary keys back and forth between a web client and server.

So Are We Stuck With The ServersideApp?

No (as we will see later).

And there are many good ideas we should carry forward fromthe relatively secure Web 1.0 style of programming:1. Never allow the client to formulate ad-hoc queries2. Prevent injection attacks by parameterizing queries3. Never return primary keys to the browser

The Missing Piece?

A Web-safe alternative to the primary key that:1. is fundamentally secure in a web client-server architecture2. preserves the semantics of "dialog" between client and

server3. is retrieved directly from the database

What we need is a Secure Unique Result Identifier (SURID).

Introducing the SURIDNextdb.net's web-safe alternative the PK

One SURID is generated by the database for each rowreturned to the AJAX/RIA client, according to this algorithm:

base64Encode( cipher( TABLENAME + PK + ACCESS_CONTROL+ MESSAGE_DIGEST))

• base64Encode function: converts binary to text for transport inJSON.

• ciper function: performs strong encryption using a private key

Anatomy of the SURID

• TABLENAME: the name of the table from which the rowdata was retrieved (in the case of data joined from multipletables, multiple SURIDs are returned)

• PK: the actual primary key of the data• ACCESS_CONTROL: dynamically generated rules which

define if UPDATE or DELETE operations can be applied todata identified by a SURID

• MESSAGE_DIGEST: SHA-1 or MD5 digest (detectstampering)

Example using SURID

Considering the following rules for a hypothetical application:

1. A user may query his account profile2. A user may update his account profile3. A user may NOT delete his account profile

Dialog Between AJAX/RIA and DaaSAJAX/RIA: "give me the ACCOUNT row and SURID forjdoe/abc123"

DaaS:"here is the JSON for this USER{nickName:"john doe", userName:"jdoe",email:"[email protected]"PK:"dj38f3cvcvrn3z4egr434b469rtg3sss3rewes"}"

AJAX/RIA: "UPDATE the nickName column to "johnnyBoy" forPK:dj38f3cvcvrn3z4egr434b469rtg3sss3rewes"

DaaS: I decrypted the SURID and checked its digest. It isvalid, and its ACCESS_CONTROL allows UPDATE. I willperform the requested operation.

Moving from dialog to actual JS code

var connection = new net.nextdb.Connection("anAcct", "aDB");var query = new net.nextdb.Query("login");query.params = {name:"jdoe", pwd="abc123"};connection.executeQuery(q, function(rows, error){ alert("login succeeded."); var update = new net.nextdb.Update("USER_TABLE"); update.setParameters(nickname:"johnnyboy"); update.setRowId(rows[0].TABLE1.PK);//use SURID conn.executeUpdate(update, function(key,error){ alert("update succeeded"); }); });

Important!

In the previous code snippet, there is NO serverside codeneeded.

the SURID moves freely over the web, exchanged back andforth between the AJAX app and the Daas withoutcompromising security.

Security Hole?

What prevents a hacker from inserting this code with adebugger and violating rule 3, "A user may NOT delete hisaccount profile"?

var del = new net.nextdb.Delete("USER_TABLE);del.setRowId(rows[0].TABLE1.PK);connection.executeDelete(del, function(key, error){ if( ! error){ alert("My hack worked! I broke the rules!"); }else{ alert("My hack failed."); }});

SURID Access Control

The ACCESS_CONTROL bits encoded in a SURID are setdynamically when the query executes.

a query named "PRIVATE_ACCOUNT_ACCESS" might beparameterized with a username and password, and write FORUPDATE into the ACCESS_CONTROL bits.

a query named "PUBLIC_ACCOUNT_VIEW" would not beparameterized with username and password, but would NOTset the FOR UPDATE or FOR DELETE access control bits.

Conclusion: SURID allows the query to specify the securitymodel for results returned from the query.

What has characterized the architectureof database computingCLIENT/SERVER

Irony: why can't the client be web based? Who says the clienthas to be a LAN client?

Let's look at some tools and live demos

Concluding remarks

1. What are today's options for cloud databases, and why can'tthey be easily accessed by pure JavaScript APIs?o today's cloud databases cannot be accessed from AJAX

API's.2. What are the gaps between the Web 1.0 database security

model, and the unforgiving JavaScript environment?o The RDBMS security model cannot be applied to AJAX.

3. How can we create a new AJAX/RIA security paradigm forDatabase as a Service (DaaS)?o Introducing a paradigm shift in the security model, which

is the goal of the NextDB.net project.