1. AJAX in the Cloud
AJAX Database Programming
Brent Hamby & Geoff Hendrey
October 21st 2008

2. Agenda
In this talk we will cover 3 important questions:
1. What are today's options for cloud databases, and why can't
they be easily accessed by pure JavaScript APIs?
2. What are the gaps between the Web 1.0 database security
model, and the unforgiving JavaScript environment?
3. How can we create a new AJAX/RIA security paradigm for
Database as a Service (DaaS)?

3. The Journey
Who we are
• From LBS industry
• Building mapping web apps in the old days
o huge time and development costs
o complex geographic information systems
o poor user interfaces
• Google Maps: the inspiration of the AJAX revolution
o Object Oriented JavaScript API's
o Faster, Cheaper, Better apps
o initial resistance from big GIS.
 haters
• Gave birth to the Mash-up application paradigm

4. Our mission
Apply lessons of the Google maps revolution to Database in the
cloud
Our project:
NextDB.net : the hosted AJAX Database

5. The Cloud Computing Landscape
Establishing a vocabulary:
1. CLOUD SERVERS
2. CLOUD VOLUMES
3. CLOUD APPLICATION FRAMEWORKS
4. CLOUD DATABASES

6. Cloud Servers
General purpose operating systems and execution
environments
Trends:
• 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 deploy
a database, but a virtual server is not a Cloud Database

7. 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 for
database files, but the hosted volume is not in-and-of-itself
Cloud Database

8. Cloud Application Frameworks
A database systems coupled to an application framework.
Hosted App Frameworks Have been around forever
-think Tomcat + MySQL Web Hosting
Why 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 server
Examples of new generation of Cloud Application Framework
-Google App Engine
-Combines Python Web 1.0 application scripting with
BigTable
-Concusion: Not a Cloud Database, although your
application in the cloud can access a database in the cloud

9. 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 its
request
Amazon 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 most
modern definitions. SimpleDB is a Hierarchical Cloud
Database. Neither is a Relational Cloud Database.

10. Can I Access SimpleDB or S3 from an
AJAX/RIA?
• The AWS security model is based on Secret Keys and
Digital Signatures
• The Secret Key is used to sign all messages sent from the
client to the server, along with the key ID.
• The Server looks up its copy of the secret key using the Key
ID, and checks the signature
• This model implicitly relies on the ability of the message
signer to keep the key safe.

11. Secret Keys and Digital Signatures
Rule #1 of AWS security: Secrets must be ....secret
quot;Your Secret Access Key is a secret, which only you and AWS should know. It is
important to keep it confidential to protect your account. Store it securely in a safe
place...To provide proof that you truly are the sender of the request, you also
include a digital signature calculated using your Secret Access Key.quot;
Rule #1 of AJAX security: There are no secure AJAX clients
Nothing can possibly be digitially signed or hashed by a JS
application because the secret key itself would be
compromised

12. So how can I access SimpleDB or S3
from a RIA/AJAX
You must build a serverside application to act as a secure
proxy between the client and AWS:
1. formulate and sign AWS requests without compromising the
key
2. validate the identity (username/pwd) of your application end
user via a query to SimpleDB or S3
3. implement Web 1.0-style application logic to control
application behavior based on user's identity established in
step 2
Would the Google Maps Mash-up revolution have happened if you had to
write the server side component?
(no... obviously)

13. The Paradox
The RIA/AJAX paradigm relies on a Web 1.0 serverside
architecture for accessing secure resources such as a
database.
To understand how to move Cloud databases forward, and
eliminate the serverside application, we have to start by going
backward, to understand what is broken in the RDBMS security
model.

14. The RDBMS Security Model
The modern Relational Database Management System
(RDBMS) is knows as a quot;client-serverquot; database architecture
with a security model designed before the advent of the Web.
The notion of quot;clientquot; in this context was conceived under the
following 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 (quot;scott/tigerquot;...anyone...anyone)
• clients, in reality, are trusted applications
• because clients are trusted applications, they are free to
execute ad-hoc SQL

15. Can we apply the RDBMS client/server
model over the web?
NO!
• To apply the RDBMS client-server model, you need a trust
relationship with every end-user of the application, and an
associated 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 application
end users, you will get hacked:
o Sensitive data will be stolen (SELECT * FROM USER)
o Your system will get wiped out (DELETE FROM USERS)

16. Identity and Security
One of the cornerstones of the relational database model is the
concept of identity. “Identity” is a familiar concept to everyone
who 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” is
simply a value that is used to keep track of data. Rows in a
database table typically have an identity defined by the row's
primary key (PK).
If your Social Security Number or credit card number is stolen it
can be impossible to “put the genie back in the bottle”.
Similarly, if a Primary Key is accessible to an application, or
malicious user, it can be saved and used for malicious
purposes, like changing the price of a product, or altering data
that should be secure.

17. The Role of the Primary Key
In a Web 1.0 serverside RDBMS application, primary keys act
as a common currency between the serverside application and
the database.
Primary keys and foreign keys form a relationship graph
connecting rows in the database.
Primary keys are a natural mechanism for traversing this graph:
SELECT * FROM ACCOUNT WHERE FK_TO_USER = 19

18. The dialog between the serverside
application and the database
app: quot;give me the primary key for USER
johndoe/abc123quot;(SELECT PK FROM USER WHERE NAME='johndoe'
AND PWD='abc123')
database: quot;19quot;
app: quot;give me the account information corresponding to the
user identified by PK 19quot;
(SELECT * FROM ACCOUNT WHERE FK_TO_USER=19)
As we can see from the dialog above that the database will
blindly return the raw identity for the user (think SSN), for any
primary key. Therefore, the security/integrity of this dialog
cannot be maintained if the application code can be tampered,
or ad-hoc values can be sent to the database.

19. Primary Keys Won't Work For
AJAX/RIA
Primary Key is an insecure mechanism for identifying rows
between a server and an AJAX/RIA (or any browser-based
application).The following is to state the obvious.
primary keys are typically auto-incrementing surrogate keys
o divulges hints about number of rows in a table
o can be altered (primary key quot;mathquot;, like quot;pointer mathquot;) to
affect malicious results
o http://bank.com?action=viewbalance&accountPK=2359
o 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 pass
primary keys back and forth between a web client and server.

20. So Are We Stuck With The Serverside
App?
No (as we will see later).
And there are many good ideas we should carry forward from
the relatively secure Web 1.0 style of programming:
1. Never allow the client to formulate ad-hoc queries
2. Prevent injection attacks by parameterizing queries
3. Never return primary keys to the browser

21. The Missing Piece?
A Web-safe alternative to the primary key that:
1. is fundamentally secure in a web client-server architecture
2. preserves the semantics of quot;dialogquot; between client and
server
3. is retrieved directly from the database
What we need is a Secure Unique Result Identifier (SURID).

22. Introducing the SURID
Nextdb.net's web-safe alternative the PK
One SURID is generated by the database for each row
returned 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 in
JSON.
• ciper function: performs strong encryption using a private key

23. Anatomy of the SURID
• TABLENAME: the name of the table from which the row
data was retrieved (in the case of data joined from multiple
tables, 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 to
data identified by a SURID
• MESSAGE_DIGEST: SHA-1 or MD5 digest (detects
tampering)

24. Example using SURID
Considering the following rules for a hypothetical application:
1. A user may query his account profile
2. A user may update his account profile
3. A user may NOT delete his account profile

25. Dialog Between AJAX/RIA and DaaS
AJAX/RIA: quot;give me the ACCOUNT row and SURID for
jdoe/abc123quot;
DaaS:quot;here is the JSON for this USER
{nickName:quot;john doequot;, userName:quot;jdoequot;,
email:quot;jdoe234@gmail.comquot;
PK:quot;dj38f3cvcvrn3z4egr434b469rtg3sss3rewesquot;}quot;
AJAX/RIA: quot;UPDATE the nickName column to quot;johnnyBoyquot; for
PK:dj38f3cvcvrn3z4egr434b469rtg3sss3rewesquot;
DaaS: I decrypted the SURID and checked its digest. It is
valid, and its ACCESS_CONTROL allows UPDATE. I will
perform the requested operation.

26. Moving from dialog to actual JS code
var connection = new net.nextdb.Connection(quot;anAcctquot;, quot;aDBquot;);
var query = new net.nextdb.Query(quot;loginquot;);
query.params = {name:quot;jdoequot;, pwd=quot;abc123quot;};
connection.executeQuery(q, function(rows, error){
alert(quot;login succeeded.quot;);
var update = new net.nextdb.Update(quot;USER_TABLEquot;);
update.setParameters(nickname:quot;johnnyboyquot;);
update.setRowId(rows[0].TABLE1.PK);//use SURID
conn.executeUpdate(update, function(key,error){
alert(quot;update succeededquot;);
});
});

27. Important!
In the previous code snippet, there is NO serverside code
needed.
the SURID moves freely over the web, exchanged back and
forth between the AJAX app and the Daas without
compromising security.

28. Security Hole?
What prevents a hacker from inserting this code with a
debugger and violating rule 3, quot;A user may NOT delete his
account profilequot;?
var del = new net.nextdb.Delete(quot;USER_TABLE);
del.setRowId(rows[0].TABLE1.PK);
connection.executeDelete(del, function(key, error){
if( ! error){
alert(quot;My hack worked! I broke the rules!quot;);
}else{
alert(quot;My hack failed.quot;);
}
});

29. SURID Access Control
The ACCESS_CONTROL bits encoded in a SURID are set
dynamically when the query executes.
a query named quot;PRIVATE_ACCOUNT_ACCESSquot; might be
parameterized with a username and password, and write FOR
UPDATE into the ACCESS_CONTROL bits.
a query named quot;PUBLIC_ACCOUNT_VIEWquot; would not be
parameterized with username and password, but would NOT
set the FOR UPDATE or FOR DELETE access control bits.
Conclusion: SURID allows the query to specify the security
model for results returned from the query.

30. What has characterized the architecture
of database computing
CLIENT/SERVER
Irony: why can't the client be web based? Who says the client
has to be a LAN client?

31. Let's look at some tools and live demos

36. Concluding remarks
1. What are today's options for cloud databases, and why can't
they 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 for
Database as a Service (DaaS)?
o Introducing a paradigm shift in the security model, which
is the goal of the NextDB.net project.