Web Security, Services and AJAX

brickborderSecurity

Nov 3, 2013 (3 years and 9 months ago)

88 views


Briefi ng
-
10
9

Briefing
-
10
9

This document is available at:



This document is available at:


<
http://www.ukoln.ac.uk/qa
-
focus/documents/briefings/briefing
-
10
9
/
>


<
http://www.ukoln.ac.uk/qa
-
focus/documents/briefings/briefing
-
10
9
/
>



Web Security, Services

and AJAX

A QA Focus Document

About This Document

Web security is an ongoing concern of many


site developers, browser developers and
everyday users. Some of the basics of Web security have been covered in a previous
briefing pap
er [1]. However, the increasing use of
Web Services
and APIs in various
contexts has led to some novel security concerns, as well as the resurgence of several
older issues. This document will discuss a few of the security issues brought up by the
use of AJ
AX and ‘Web 2.0’ service APIs.

Cross
-
domain R
equests

Since Web services are not hosted locally, consuming data from such services involves
making requests to services on other domains. Default security settings in JavaScript
disallow this


most browsers
will not permit it for security reasons. There are
legitimate security reasons for this. If developers wish to overcome this restriction, they
typically create a
proxy

for that service


a server
-
side script running on their local
domain that forwards the

request and returns the response. Proxies must be secured
against unauthorised use. Many services will ask for an API key or password; be careful
with this information and do not make it visible in the JavaScript of your page.

Multi
-
layered
S
ecurity

Do no
t consider the browser as a secure environment; users can read JavaScript


even
if it has been obfuscated


and alter it as it runs on their machine. In fact, they can tailor
requests that do not make use of the page at all. Therefore, ensure that all the

crucial
business logic takes place on the server, rather than the browser. You may wish to
perform it on the browser to avoid unnecessary crosstraffic between client and server, or
for usability/interface reasons, but though this means that the logic has
been duplicated,
it is important to perform this step again when processing input requests.

According to research by Gartner Inc, 70% of attacks occur via the application layer [3].
Before deploying AJAX, consider the risks, and ensure that your project i
s ready and
able to meet the commitment required to complete the task securely. Access control in
particular should be considered attentively, as well as communications channels


remember that by default XMLHTTPRequest does not encrypt the data it transmi
ts.



Web Security, Services

and AJAX

A QA Focus Document

About This Document

Web security is an ongoing concern of many


site developers, browser developers and
everyday users. Some of the basics of Web security have been covered in a previous
briefing

paper [1]. However, the increasing use of
Web Services
and APIs in various
contexts has led to some novel security concerns, as well as the resurgence of several
older issues. This document will discuss a few of the security issues brought up by the
use o
f AJAX and ‘Web 2.0’ service APIs.

Cross
-
domain
R
equests

Since Web services are not hosted locally, consuming data from such services involves
making requests to services on other domains. Default security settings in JavaScript
disallow this


most brows
ers will not permit it for security reasons. There are
legitimate security reasons for this. If developers wish to overcome this restriction, they
typically create a
proxy

for that service


a server
-
side script running on their local
domain that forwards

the request and returns the response. Proxies must be secured
against unauthorised use. Many services will ask for an API key or password; be careful
with this information and do not make it visible in the JavaScript of your page.

Multi
-
layered
S
ecurity

D
o not consider the browser as a secure environment; users can read JavaScript


even
if it has been obfuscated


and alter it as it runs on their machine. In fact, they can tailor
requests that do not make use of the page at all. Therefore, ensure that all

the crucial
business logic takes place on the server, rather than the browser. You may wish to
perform it on the browser to avoid unnecessary crosstraffic between client and server, or
for usability/interface reasons, but though this means that the logic
has been duplicated,
it is important to perform this step again when processing input requests.

According to research by Gartner Inc, 70% of attacks occur via the application layer [3].
Before deploying AJAX, consider the risks, and ensure that your proje
ct is ready and
able to meet the commitment required to complete the task securely. Access control in
particular should be considered attentively, as well as communications channels


remember that by default XMLHTTPRequest does not encrypt the data it tra
nsmits.

Published by QA Focus
-

supporting best practices for digital library programmes

Sept 2006

Published by QA Focus
-

supporting best practices for digital library programmes

Sept 20
06

Bandwidth and
S
peed

Several applications of AJAX have been designed to provide almost real
-
time input or
feedback to the user, or for continuous small updates to be made to a page. When
putting together an application using AJAX or frequent service

calls in general, add up
the amount of bandwidth that will be used during a typical interaction or use of the
service.

Fallback
P
lans

If your service is slow or unavailable


or JavaScript is turned off on the browser


the
majority of web applications
should still work. The only exception to this is the
relatively small subset of applications whose functionality depends directly on input
taken from services, such as mash
-
ups based around maps taken from Google Earth.

Managing
C
omplexity

Because AJAX ap
plications share the business logic between the server and the client,
the developers responsible for each element need to work together closely. Developers
dealing with technology relatively new to them will need time to produce successive
prototypes, sin
ce this is a learning process with few authoritative references from which
to work.

Conclusions

As with traditional Web applications [1], make security a priority, and plan for
maintenance in your budget. When specifying an application, page or component
that
takes user input, write down a list of possible vulnerabilities and ensure that you have
addressed these during the design and build phases. Test your
W
eb applications


both
the JavaScript layer and the server
-
side layer(s). Speak to a security exper
t if possible,
and ensure that you have taken reasonable precautions. A secure application can only be
ensured by an ongoing commitment to that aim.

Finally, be conservative with application of novel technologies, and consider a ‘feature
-
freeze’ and testin
g cycle before deployment. New features will also require testing
before deployment, so plan to add features only when there is time to audit the result.

References

1.

An Introduction to
Secure Web Practice
, QA
-
Focus briefing document no. 108,
<http://www.uko
ln.ac.uk/qa
-
focus/documents/briefings/briefing
-
108/>

2.

AJAX Security
, Stewart Twynham, IT Observer,

<http://www.it
-
observer.com/articles/1062/ajax_security/>

3.

AJAX Threats Worry Researchers
, Bill Brenner,
<http://searchsecurity.techtarget.com/originalContent
/0,289142,sid14_gci1207759,0
0.html>

Bandwidth and
S
peed

Several applications of AJAX have been designed to provide almost real
-
time input or
feedback to the user, or for continuous small updates to be made to a page. When
putting together an application u
sing AJAX or frequent service calls in general, add up
the amount of bandwidth that will be used during a typical interaction or use of the
service.

Fallback
P
lans

If your service is slow or unavailable


or JavaScript is turned off on the browser


the
majority of web applications should still work. The only exception to this is the
relatively small subset of applications whose functionality depends directly on input
taken from services, such as mash
-
ups based around maps taken from Google Earth.

Managi
ng
C
omplexity

Because AJAX applications share the business logic between the server and the client,
the developers responsible for each element need to work together closely. Developers
dealing with technology relatively new to them will need time to produ
ce successive
prototypes, since this is a learning process with few authoritative references from which
to work.

Conclusions

As with traditional Web applications [1], make security a priority, and plan for
maintenance in your budget. When specifying an ap
plication, page or component that
takes user input, write down a list of possible vulnerabilities and ensure that you have
addressed these during the design and build phases. Test your Web applications


both
the JavaScript layer and the server
-
side layer(
s). Speak to a security expert if possible,
and ensure that you have taken reasonable precautions. A secure application can only be
ensured by an ongoing commitment to that aim.

Finally, be conservative with application of novel technologies, and consider
a ‘feature
-
freeze’ and testing cycle before deployment. New features will also require testing
before deployment, so plan to add features only when there is time to audit the result.

References

1.

An Introduction to
Secure Web Practice
, QA
-
Focus briefing docu
ment no. 108,
<http://www.ukoln.ac.uk/qa
-
focus/documents/briefings/briefing
-
108/>

2.

AJAX Security
, Stewart Twynham, IT Observer,

<http://www.it
-
observer.com/articles/1062/ajax_security/>

3.

AJAX Threats Worry Researchers
, Bill Brenner,
<http://searchsecurity.t
echtarget.com/originalContent/0,28
9142,sid14_gci1207759,
00.html
>