Another doc written back in 2007 for a client

1. 1
RIA
Implementation
RIA
Data
and
Security
Data
Transactions
This
section
describes
couple
of
technologies
that
can
be
used
for
data
transactions
within
client/server
RIA
application
REST
REST
is
an
acronym
standing
for
Representational
State
Transfer.
REST
is
a
model
for
distributed
computing.
It
is
the
one
used
by
the
world's
biggest
distributed
computing
application,
the
Web.
When
applied
to
web
services
technologies,
it
usually
depends
on
a
trio
of
technologies
designed
to
be
extremely
extensible:
XML,
URIs,
and
HTTP.
XML's
extensibility
should
be
obvious
to
most,
but
the
other
two
may
not
be.
URIs
are
also
extensible:
there
are
an
infinite
number
of
possible
URIs.
More
importantly,
they
can
apply
to
an
infinite
number
of
logical
entities
called
"resources."
URIs
are
just
the
names
and
addresses
of
resources.
Some
REST
advocates
call
the
process
of
bringing
your
applications
into
this
model
"resource
modeling."
This
process
is
not
yet
as
formal
as
object
oriented
modeling
or
entity-­‐relation
modeling,
but
it
is
related.
The
strength
and
flexibility
of
REST
comes
from
the
pervasive
use
of
URIs.
This
point
cannot
be
over-­‐
emphasized.
When
the
Web
was
invented
it
had
three
components:
HTML,
which
was
about
the
worst
markup
language
of
its
day
(other
than
being
simple);
HTTP,
which
was
the
most
primitive
protocol
of
its
day
(other
than
being
simple),
and
URIs
(then
called
URLs),
which
were
the
only
generalized,
universal
naming
and
addressing
mechanism
in
use
on
the
Internet.
Why
did
the
Web
succeed?
Not
because
of
HTML
and
not
because
of
HTTP.
Those
standards
were
merely
shells
for
URIs.
HTTP's
extensibility
stems
primarily
from
the
ability
to
distribute
any
payload
with
headers,
using
predefined
or
(occasionally)
new
methods.
What
makes
HTTP
really
special
among
all
protocols,
however,
is
its
built-­‐in
support
for
URIs
and
resources.
URIs
are
the
defining
characteristic
of
the
Web:
F e b r u a r y
1 6 ,
2 0 0 7
the
mojo
that
makes
it
work
and
scale.
HTTP
as
a
protocol
keeps
them
front
and
center
by
defining
all
methods
as
operations
on
URI-­‐addressed
resources.
AMF
AMF
is
the
Action
Message
Format.
AMF
is
a
proprietary
data
format
created
by
Macromedia
and
used
by
different
mediums:
Flash
Remoting,
FlashComm,
LocalConnection
and
Shared
Objects.
Skitsanos
Inc.

2. 2
RIA
Implementation
All
of
these
mediums
share
the
same
core
data
types
and
ActionScript
data
types.
Each
medium
uses
its
own
exclusive
envelope.
Any
AMF-­‐related
project
should
implement
reading
and
writing
core
data
types,
relevant
ActionScript
types,
as
well
as
providing
support
for
its
envelope
type.
Flex-­‐Ajax
Bridge
The
Flex™
AJAX
Bridge
(FABridge)
is
a
small,
unobtrusive
code
library
that
you
can
insert
into
an
Adobe®
Flex™
application,
a
Flex
component,
or
even
an
empty
SWF
file
to
expose
it
to
scripting
in
the
browser.
To
humbly
borrow
a
page
from
the
Ruby
on
Rails
community,
FABridge
is
built
with
the
“don’t
repeat
yourself”
principle
in
mind.
Rather
than
having
to
define
new,
simplified
APIs
to
expose
a
graph
of
ActionScript
objects
to
JavaScript,
with
FABridge
you
can
make
your
ActionScript
classes
available
to
JavaScript
without
any
additional
coding.
After
you
insert
the
library,
essentially
anything
you
can
do
with
ActionScript,
you
can
do
with
JavaScript.
JSON
JSON
(JavaScript
Object
Notation)
is
a
lightweight
computer
data
interchange
format.
It
is
a
text-­‐based,
human-­‐readable
format
for
representing
objects
and
other
data
structures
and
is
mainly
used
to
transmit
such
structured
data
over
a
network
connection
(in
a
process
called
serialization).
JSON
finds
its
main
application
in
Ajax
web
application
programming,
as
a
simple
alternative
to
using
XML
for
asynchronously
transmitting
structured
information
between
client
and
server.
JSONRequest
XMLHttpRequest
has
a
security
model
which
is
inadequate
for
supporting
the
next
generation
of
web
applications.
JSONRequest
is
proposed
as
a
new
browser
service
that
allows
for
two-­‐way
data
exchange
with
any
JSON
data
server
without
exposing
users
or
organization
to
harm.
It
exchanges
data
between
scripts
on
pages
with
JSON
servers
in
the
web.
It
is
hoped
that
browser
makers
will
build
this
feature
into
their
products
in
order
to
enable
the
next
advance
in
web
application
development.
JSONRequest.post
does
an
HTTP
POST
of
a
serialization
of
a
JavaScript
object
or
array,
gets
the
response,
and
parses
the
response
into
a
JavaScript
value.
If
the
parse
is
successful,
it
returns
the
value
to
the
requesting
script.
In
making
the
request,
no
HTTP
authentication
or
cookies
are
sent.
Any
cookies
returned
by
the
server
cause
the
request
to
fail.
The
JSONRequest
service
can
only
be
used
to
send
and
receive
JSON-­‐encoded
values.
JSONRequest
cannot
be
used
to
retrieve
other
text
formats.
BISON
F e b r u a r y
1 6 ,
2 0 0 7
Binary
Interchange
Standard
and
Object
Notation
(BISON)
is
a
new
binary
format
created
by
Kai
Jäger.
Essentially,
you
can
now
serialize
any
JavaScript
variable
into
a
string
that
holds
a
binary
representation
of
whatever
you
had
in
that
variable.
This
string
may
then
be
sent
over
XMLHTTPRequest
to
a
script
running
on
a
web
server.
SOAP
SOAP
(originally
Simple
Object
Access
Protocol)
is
a
protocol
for
exchanging
XML-­‐based
messages
over
computer
networks,
normally
using
HTTP.
SOAP
forms
the
foundation
layer
of
the
Web
services
stack,
Skitsanos
Inc.

3. 3
RIA
Implementation
providing
a
basic
messaging
framework
that
more
abstract
layers
can
build
on.
The
original
acronym
was
dropped
with
Version
1.2
of
the
standard,
which
became
a
W3C
Recommendation
on
June
24,
2003,
as
it
was
considered
to
be
misleading.
There
are
several
different
types
of
messaging
patterns
in
SOAP,
but
by
far
the
most
common
is
the
Remote
Procedure
Call
(RPC)
pattern,
in
which
one
network
node
(the
client)
sends
a
request
message
to
another
node
(the
server),
and
the
server
immediately
sends
a
response
message
to
the
client.
SOAP
is
the
successor
of
XML-­‐RPC,
though
it
borrows
its
transport
and
interaction
neutrality
and
the
envelope/header/body
from
elsewhere.
F e b r u a r y
1 6 ,
2 0 0 7
Skitsanos
Inc.

4. 4
RIA
Implementation
The
security
risks
in
Web
2.0
This
technological
transformation
is
bringing
in
new
security
concerns
and
attack
vectors
into
existence.
Yamanner,
Samy
and
Spaceflash
type
worms
are
exploiting
“client-­‐side”
AJAX
frameworks,
providing
new
avenues
of
attack
and
compromising
some
of
the
confidential
information.
On
the
“server-­‐side”,
XML
based
Web
services
are
replacing
some
of
the
key
functionalities
and
providing
distributed
application
access
through
Web
services
interfaces.
These
remote
capabilities
to
invoke
methods
over
GET,
POST
or
SOAP
from
the
Web
browser
itself
provide
new
openings
to
applications.
On
other
side,
RIA
frameworks
running
on
XML,
XUL,
Flash,
Applets
and
JavaScripts
are
adding
new
possible
sets
of
vectors.
RIA,
AJAX
and
Web
services
are
adding
new
dimensions
to
Web
application
security.
Here
is
the
list
of
10
attack
vectors
along
with
a
brief
overview
of
each:
1.
Cross-­‐site
scripting
in
AJAX
In
the
last
few
months,
several
cross-­‐site
scripting
attacks
have
been
observed,
where
malicious
JavaScript
code
from
a
particular
Web
site
gets
executed
on
the
victim’s
browser
thereby
compromising
information.
A
recent
example
is
the
Yamanner
worm
that
exploited
cross-­‐site
scripting
opportunities
in
Yahoo
mail’s
AJAX
call.
Another
recent
example
is
the
Samy
worm
that
exploited
MySpace.com’s
cross-­‐
site
scripting
flaw.
AJAX
gets
executed
on
the
client-­‐side
by
allowing
an
incorrectly
written
script
to
be
exploited
by
an
attacker.
The
attacker
is
only
required
to
craft
a
malicious
link
to
coax
unsuspecting
users
to
visit
a
certain
page
from
their
Web
browsers.
This
vulnerability
existed
in
traditional
applications
as
well
but
AJAX
has
added
a
new
dimension
to
it.
2.
XML
poisoning
XML
traffic
goes
back
and
forth
between
server
and
browser
in
many
of
the
WEB
2.0
applications.
Web
applications
consume
XML
blocks
coming
from
AJAX
clients.
It
is
possible
to
poison
this
XML
block.
Not
uncommon
is
the
technique
to
apply
recursive
payloads
to
similar-­‐producing
XML
nodes
multiple
times.
If
the
engine’s
handling
is
poor
this
may
result
in
a
denial
of
services
on
the
server.
Many
attackers
also
produce
malformed
XML
documents
that
can
disrupt
logic
depending
on
parsing
mechanisms
in
use
on
the
server.
There
are
two
types
of
parsing
mechanisms
available
on
the
server
side
–
SAX
and
DOM.
This
same
attack
vector
is
also
used
with
Web
services
since
they
consume
SOAP
messages
and
SOAP
messages
are
nothing
but
XML
messages.
Large-­‐scale
adaptation
of
XMLs
at
the
application
layer
opens
F e b r u a r y
1 6 ,
2 0 0 7
up
new
opportunities
to
use
this
new
attack
vector.
XML
external
entity
reference
is
an
XML
property
which
can
be
manipulated
by
an
attacker.
This
can
lead
to
arbitrary
file
or
TCP
connection
openings
that
can
be
leveraged
by
an
attacker.
XML
schema
poisoning
is
another
XML
poisoning
attack
vector
which
can
change
execution
flow.
This
vulnerability
can
help
an
attacker
to
compromise
confidential
information.
Skitsanos
Inc.

5. 5
RIA
Implementation
3.
Malicious
AJAX
code
execution
AJAX
calls
are
very
silent
and
end-­‐users
would
not
be
able
to
determine
whether
or
not
the
browser
is
making
silent
calls
using
the
XMLHTTPRequest
object.
When
the
browser
makes
an
AJAX
call
to
any
Web
site
it
replays
cookies
for
each
request.
This
can
lead
to
potential
opportunities
for
compromise.
For
example,
John
has
logged
in
to
his
bank
and
authenticated
on
the
server.
After
completing
the
authentication
process
he
gets
a
session
cookie.
His
bank’s
page
has
a
lot
of
critical
information.
Now
he
browses
other
pages
while
still
logged
in
to
his
bank’s
account
Web
page
and
lands
at
an
attacker’s
Web
page.
On
this
page
the
attacker
has
written
silent
AJAX
code
which
makes
backend
calls
to
his
bank
without
John’s
consent,
fetches
critical
information
from
the
pages
and
sends
this
information
to
the
attacker’s
Web
site.
This
leads
to
a
security
breach
and
leakage
of
confidential
information.
4.
RSS
/
Atom
injection
This
is
a
new
WEB
2.0
attack.
RSS
feeds
are
common
means
of
sharing
information
on
portals
and
Web
applications.
These
feeds
are
consumed
by
Web
applications
and
sent
to
the
browser
on
the
client-­‐side.
One
can
inject
literal
JavaScripts
into
the
RSS
feeds
to
generate
attacks
on
the
client
browser.
An
end
user
visits
this
particular
Web
site
loads
the
page
with
the
RSS
feed
and
the
malicious
script
–
a
script
that
can
install
software
or
steal
cookies
–
gets
executed.
This
is
a
lethal
client-­‐side
attack.
Worse,
it
can
be
mutated.
With
RSS
and
ATOM
feeds
becoming
integral
part
of
Web
applications,
it
is
important
to
filter
out
certain
characters
on
the
server-­‐side
before
pushing
the
data
out
to
the
end
user.
5.
WSDL
scanning
and
enumeration
WSDL
(Web
Services
Definition
Language)
is
an
interface
to
Web
services.
This
file
provides
key
information
about
technologies,
exposed
methods,
invocation
patterns,
etc.
This
is
very
sensitive
information
and
can
help
in
defining
exploitation
methods.
Unnecessary
functions
or
methods
kept
open
can
cause
potential
disaster
for
Web
services.
It
is
important
to
protect
WSDL
file
or
provide
limited
access
to
it.
In
real
case
scenarios,
it
is
possible
to
discover
several
vulnerabilities
using
WSDL
scanning.
6.
Client
side
validation
in
AJAX
routines
WEB
2.0
based
applications
use
AJAX
routines
to
do
a
lot
of
work
on
the
client-­‐side,
such
as
client-­‐side
validations
for
data
type,
content-­‐checking,
date
fields,
etc.
Normally,
these
client-­‐side
checks
must
be
backed
up
by
server-­‐side
checks
as
well.
Most
developers
fail
to
do
so;
their
reasoning
being
the
assumption
that
validation
is
taken
care
of
in
AJAX
routines.
It
is
possible
to
bypass
AJAX-­‐based
validations
and
to
make
POST
or
GET
requests
directly
to
the
application
–
a
major
source
for
input
F e b r u a r y
1 6 ,
2 0 0 7
validation
based
attacks
such
as
SQL
injection,
LDAP
injection,
etc.
that
can
compromise
a
Web
application’s
key
resources.
This
expands
the
list
of
potential
attack
vectors
that
attackers
can
add
to
their
existing
arsenal.
AJAX
routines
are:
7.
Web
services
routing
issues
Web
services
security
protocols
have
WS-­‐Routing
services.
WS-­‐Routing
allows
SOAP
messages
to
travel
in
specific
sequence
from
various
different
nodes
on
the
Internet.
Often
encrypted
messages
traverse
these
nodes.
A
compromise
of
any
of
the
intermediate
nodes
results
in
possible
access
to
the
SOAP
Skitsanos
Inc.

6. 6
RIA
Implementation
messages
traveling
between
two
end
points.
This
can
be
a
serious
security
breach
for
SOAP
messages.
As
Web
applications
move
to
adopt
the
Web
services
framework,
focus
shifts
to
these
new
protocols
and
new
attack
vectors
are
generated.
8.
Parameter
manipulation
with
SOAP
Web
services
consume
information
and
variables
from
SOAP
messages.
It
is
possible
to
manipulate
these
variables.
For
example,
“10”
is
one
of
the
nodes
in
SOAP
messages.
An
attacker
can
start
manipulating
this
node
and
try
different
injections
–
SQL,
LDAP,
XPATH,
command
shell
–
and
explore
possible
attack
vectors
to
get
a
hold
of
internal
machines.
Incorrect
or
insufficient
input
validation
in
Web
services
code
leaves
the
Web
services
application
open
to
compromise.
This
is
a
new
available
attack
vector
to
target
Web
applications
running
with
Web
services.
9.
XPATH
injection
in
SOAP
message
XPATH
is
a
language
for
querying
XML
documents
and
is
similar
to
SQL
statements
where
we
can
supply
certain
information
(parameters)
and
fetch
rows
from
the
database.
XPATH
parsing
capabilities
are
supported
by
many
languages.
Web
applications
consume
large
XML
documents
and
many
times
these
applications
take
inputs
from
the
end
user
and
form
XPATH
statements.
These
sections
of
code
are
vulnerable
to
XPATH
injection.
If
XPATH
injection
gets
executed
successfully,
an
attacker
can
bypass
authentication
mechanisms
or
cause
the
loss
of
confidential
information.
There
are
few
known
flaws
in
XPATH
that
can
be
leverage
by
an
attacker.
The
only
way
to
block
this
attack
vector
is
by
providing
proper
input
validation
before
passing
values
to
an
XPATH
statement.
10.
RIA
thick
client
binary
manipulation
Rich
Internet
Applications
(RIA)
use
very
rich
UI
features
such
as
Flash,
ActiveX
Controls
or
Applets
as
their
primary
interfaces
to
Web
applications.
There
are
a
few
security
issues
with
this
framework.
One
of
the
major
issues
is
with
session
management
since
it
is
running
in
browser
and
sharing
same
session.
At
the
same
time
since
the
entire
binary
component
is
downloaded
to
the
client
location,
an
attacker
can
reverse
engineer
the
binary
file
and
decompile
the
code.
It
is
possible
to
patch
these
binaries
and
bypass
some
of
the
authentication
logic
contained
in
the
code.
This
is
another
interesting
attack
vector
for
WEB
2.0
frameworks.
F e b r u a r y
1 6 ,
2 0 0 7
Skitsanos
Inc.

7. 7
RIA
Implementation
Securing
Application
A
key
problem
with
JavaScript
is
that
it
was
designed
so
that
its
scripts
can
do
anything
the
user
can
do.
For
example,
it
can
pretend
the
user
clicked
on
a
particular
link,
or
typed
in
some
text
into
a
Web
page.
There
are
a
lot
of
things
we
might
like
to
allow
a
user
to
do
that
it's
not
a
good
idea
to
let
a
JavaScript
script
of
unknown
provenance
do.
Unfortunately,
JavaScript
doesn't
provide
any
good
way
to
enforce
such
a
distinction.
What
should
AJAX
developers
do?
As
a
Web
2.0
programmer,
a
RIA
programmer,
you
need
to
both
protect
the
user
and
not
trust
the
user,
it
might
seem
counterintuitive,
but
think
about
it;
the
user
can
be
both
an
attacker
and
a
victim.
Doing
both
of
those
things
at
once
is
a
bit
of
a
juggling
act,
but
necessary
from
a
security
standpoint.
Developers
need
to
be
aware
of
security
and
take
responsibility
for
their
applications.
One
of
the
benefits
of
new
Web
technologies
has
been
to
make
Web
programming
accessible
to
a
much
broader
interface,
-­‐
but
that
is
a
double-­‐edged
sword,
because
many
of
these
new
Web
developers
aren't
necessarily
trained
in
or
fully
aware
of
security
issues.
As
software
developers,
it
behooves
us
to
think
proactively
about
how
our
code
might
be
misused.
Below
you
can
find
couple
of
options
that
can
be
used
for
client/server
data
transmission
security
implementation.
Combining
some
of
them
together
might
lead
you
into
pretty
safe
application
construction.
Cross-­‐site
request
forgery
prevention
Cross-­‐site
request
forgery,
also
known
as
one
click
attack,
or
session
riding,
and
abbreviated
as
CSRF
or
XSRF,
is
a
kind
of
malicious
exploit
of
websites.
Although
similar-­‐sounding
in
name
to
cross-­‐site
scripting
(XSS),
it
is
a
very
different
and
almost
opposite
form
of
attack.
Whereas
cross-­‐site
scripting
exploits
the
trust
a
user
has
in
a
website,
a
cross-­‐site
request
forgery
exploits
the
trust
a
Web
site
has
in
a
user
by
forging
a
request
from
a
trusted
user.
Compared
to
XSS
attacks,
CSRF
attacks
are
often
less
popular
(so
there
are
fewer
defense
resources
available)
and
more
difficult
to
defend
against,
and
thus
are
considered
to
be
more
dangerous.
For
the
web
site,
switching
from
a
persistent
authentication
method
(e.g.
a
cookie
or
HTTP
authentication)
to
a
transient
authentication
method
(e.g.
a
hidden
field
provided
on
every
form)
will
help
prevent
these
attacks.
A
similar
approach
is
to
include
a
secret,
user-­‐specific
token
in
forms
that
is
F e b r u a r y
1 6 ,
2 0 0 7
verified
in
addition
to
the
cookie.
An
alternate
method
is
to
"double
submit"
cookies.
This
method
only
works
with
Ajax
based
requests,
but
it
can
be
applied
as
a
global
fix
without
needing
to
alter
a
large
number
of
forms.
If
an
authentication
cookie
is
read
using
JavaScript
before
the
post
is
made,
the
stricter
(and
more
correct)
cross-­‐domain
rules
will
be
applied.
If
the
server
requires
requests
to
contain
the
value
of
the
authentication
cookie
in
the
body
of
POST
requests
or
the
URL
of
GET
requests,
then
the
request
must
have
come
from
a
trusted
domain,
since
other
domains
are
unable
to
read
cookies
from
the
trusting
domain.
Skitsanos
Inc.

8. 8
RIA
Implementation
Contrary
to
popular
belief,
using
POST
instead
of
GET
does
not
offer
sufficient
protection.
JavaScript
can
be
used
to
forge
POST
requests
with
ease.
Nonetheless,
requests
that
cause
side
effects
should
always
use
POST.
Also,
POST
does
not
leave
a
trail
of
variable
data
in
web
server
and
proxy
server
logs,
while
GET
does
leave
such
a
trail.
It
is
still
clearly
best
to
use
POST
when
coding
in
a
defense-­‐in-­‐depth
approach.
Although
cross-­‐site
request
forgery
is
fundamentally
a
problem
with
the
web
application,
not
the
user,
users
can
help
protect
their
accounts
at
poorly
designed
sites
by
logging
off
the
site
before
visiting
another,
or
clearing
their
browser's
cookies
at
the
end
of
each
browser
session.
AJAX
Secure
Service
Layer
AJAX
Secure
Service
Layer
–
aSSL,
is
a
library
distributed
under
MIT
License
that
implements
a
technology
similar
to
SSL
without
HTTPS.
aSSL
enables
the
client
to
negotiate
a
secret
random
128-­‐bit
key
with
the
server
using
the
RSA
algorithm.
Once
the
connection
has
been
established,
the
data
will
be
sent
and
received
using
AES
algorithm.
aSSL
is
composed
of
some
JavaScript
files
and
a
server
side
component.
Because
I
have
recently
changed
the
negotiation
algorithm
from
RC4
to
RSA,
only
a
pure
JavaScript
(ASP)
server
component
is
currently
available.
I
will
do
a
porting
for
the
main
web
languages
(PHP,
Java,
Perl,
Python,
TKL,
etc.)
as
soon
as
possible
once
the
library
has
passed
the
beta
phase.
Is
aSSL
secure
as
SSL?
No.
SSL
is
secure
because
it
is
a
technology
implemented
at
browser
level
so
that
when
an
HTTPS
connection
has
been
established,
the
browser
checks
the
SSL
Certificate
before
continuing.
Suppose
that
a
hacker
were
to
attack
you
with
a
man-­‐in-­‐the-­‐middle
(MiTM)
attack.
With
an
SSL
connection,
the
attack
would
be
successful
only
should
the
user
click
Ok
when
the
browser
alerts
him
saying
that
the
certificate
doesn't
correspond
to
the
connected
server
(the
alert
may
also
appear
if
some
file
is
transferred
over
HTTP
instead
of
HTTPS
because
in
this
file
a
hacker
could
inject
malicious
code).
If
a
hacker
were
to
attack
you
with
a
MiTM
attack
during
an
aSSL
connection,
he
could
be
successful.
But
MiTM
attacks
require
great
skill
and
a
lot
of
organization.
They
are
rare
and
a
hacker
would
only
be
F e b r u a r y
1 6 ,
2 0 0 7
worth
while
to
the
hacker
if
he
has
a
lot
to
gain
for
is
efforts.
aSSL
is
designed
for
non-­‐critical
sites
as
chats,
blogs,
etc.
where
the
potential
payoff
for
hackers
would
be
low,
and
therefore
they
would
not
be
targeted
by
such
attacks.
Password
sniffing
is
much
more
diffuse
because
it
is
much
easier.
In
fact,
there
are
specific
software
that
sniff
the
traffic,
recognize
user
id
and
passwords,
and
register
them.
Skitsanos
Inc.

9. 9
RIA
Implementation
aSSL
protects
against
these
sniffers.
When
a
server
exchanges
account
information
in
clear
HTTP,
a
sniffer
can
simply
intercept
all
the
data,
but
if
the
server
exchanges
the
data
via
aSSL
it
is
not
possible
to
decode
the
passed
data
and
so
the
level
of
security
of
the
site
is
notably
better.
F e b r u a r y
1 6 ,
2 0 0 7
Skitsanos
Inc.

10. 10
RIA
Implementation
References
REST
Links
• http://en.wikipedia.org/wiki/Representational_State_Transfer
• http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html
• http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
• http://www.xfront.com/REST-­‐Web-­‐Services.html
AMF
Links
• http://www.adobe.com/devnet/flex/articles/intro_fms_08.html
• http://livedocs.adobe.com/flashremoting/mx/Using_Flash_Remoting_MX/intro2.htm
• http://web.archive.org/web/20040603100453/chattyfig.figleaf.com/flashcoders-­‐
wiki/index.php?SharedObjectFile
FLEX-­‐AJAX
Bridge
• http://labs.adobe.com/wiki/index.php/Flex_Framework:FABridge
• http://www.flex.org/
• http://www.adobe.com/devnet/flex/articles/flex_security_wp/flex_security_wp.html
• http://www.adobe.com/devnet/security/
• http://www.adobe.com/cfusion/exchange/index.cfm?view=sn610
JSON
• http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=AJAXWithoutXML
JSONRequest
• http://json.org/JSONRequest.html
BISON
• http://www.kaijaeger.com/articles/introducing-­‐bison-­‐binary-­‐interchange-­‐standard.html
SOAP
Links
• http://en.wikipedia.org/wiki/SOAP
Security
F e b r u a r y
1 6 ,
2 0 0 7
• http://news.com.com/The+security+risk+in+Web+2.0/2100-­‐1002_3-­‐6099228.html
• http://www.spidynamics.com/assets/documents/HackingFeeds.pdf
• http://www.net-­‐security.org/article.php?id=949&p=1
• http://assl.sullof.com/assl/
Skitsanos
Inc.