RIA Data and Security, 2007


Published on

Another doc written back in 2007 for a client

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

RIA Data and Security, 2007

  1. 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  worlds  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.  XMLs  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.   HTTPs   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. 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. 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. 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. 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. 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. 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  its  not  a  good  idea  to  let  a  JavaScript   script   of   unknown   provenance   do.   Unfortunately,   JavaScript   doesnt   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   arent   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. 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  browsers  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  doesnt  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. 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. 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.