Response Time

As  depicted  in  section  4.1,  a  web  application  is  a  distributed  system,  composed  by  a  client  (browser)  that  generates  HTTP  request  to  a  web  server  through  a  TCP/IP  networks.  Web  servers,  in  turn,  issue  database  queries  to  obtain  the  data  needed  for  generating  the  HTTP  response (see Figure 37) 

Figure 37. Response Time Latency 

Therefore,  the  response  time  observed  from  the  user  perspective  (client‐side)  is  the  aggregation of several latency time, described in the following equation:  (XII) _ _ ∑ ∑    Where:  ‐  : Response time.  ‐ _ : Time used by the HTTP request to reach the web server.  ‐ _{_}  : Time used by the HTTP response to reach the web client. 

‐ ∑  :  Aggregation  of  time  used  by  the  web  server  (and  web  application  server,  if  exists) to process the request. 

‐ ∑  : Aggregation of time used to access to the database (if exits). 

In  order  to  perform  complete  performance  testing,  performance  oracles  should  be  able  to  compare  real  measurements  with  the  expected  outcome.  This  leads  me  to  ask  myself  the  following question: What should be the expected response time for any web application?   This question has no simple answer, since there is any generic industry standard for good and  bad  performance.  Some  researches  attempted  to  map  user  productivity  to  response  time  [136], as follows: 

‐ Greater than 15 seconds. If such delays can occur, the system should be designed so that  the user can turn to other activities and request the response at some later time.  

‐ Greater than 4 seconds.  These  delays  are generally too long for a conversation requiring  the end‐user to retain information in short‐term end‐user memory.  

‐ From 2 to 4 seconds. A delay in this range may be sometimes acceptable. For example, it  may be acceptable to make a purchaser wait 2 to 4 seconds after typing in her address and  credit  card  number,  but  not  at  an  earlier  stage  when  she  is  comparing  various  product  features. 

‐ Less than 2 seconds. For complex activities, 2 seconds represents an important response‐ time limit. When the user has to remember information throughout several responses, the  response time must be short. The more detailed the information to be remembered, the  greater the need for responses of less than 2 seconds.  

‐ Sub‐second  response  time.  Certain  types  of  thought‐intensive  work  (e.g.  writing  a  book),  require  very  short  response  times  to  maintain  the  users’  interest  and  attention  for  long  periods of time. 

‐ Deci‐second response time. This response time is required when instantaneous responses  are required, such as the response to pressing a key of seeing the character displayed on  the screen or to clicking a screen object with a mouse.  

The critical response time barrier seems to be around 4 seconds. Response times greater than  this have a definite impact on productivity for the average user. This fact is confirmed in the  several  surveys  [80][103]  that  have  shown  that  high  user  latencies  drive  web  users  away.  Response times above 4 seconds interrupt the user experience, causing the user to leave the  web site.   All in all, the figure employed in this dissertation to assert the maximum response time (i.e., a  performance oracle) will be 4 seconds.  6.2.1.2.2. Throughput In broad terms, throughput measures the amount of work performed by web server. It can be  defined as the number of requests processed per minute per server instance, i.e. the volume of  session  data  stored  per  minute.  To  calculate  throughput  per  web  page,  I  use  the  following  formula [129]:  (XIII) ser_rate t   Where:  ‐  : Throughput per web page.  ‐ ser  : User arrival rate (new users per second).  ‐ t  : Average pages per visit. 

6.2.2. Security

Web application security is difficult  because these  applications  are, by definition, exposed to  the  general  public,  including  malicious  users.  Additionally,  input  to  web  applications  comes  from  within  HTTP  requests.  The  incorrect  or  missing  input  validation  causes  most  of  the  vulnerabilities in web applications [72].   

As  depicted  in  the  methodology  section,  security  will  be  assessed  by  means  of  black‐box  testing. This type of security testing is carried out by means of web application scanners, i.e.  automated program that  examines web applications for security vulnerabilities by simulating  attacks  on  it.    This  involves  generation  of  malicious  inputs  and  subsequent  evaluation  of  application’s response.  

Vulnerabilities  are  flaw  or  weakness  in  a  system's  design,  implementation,  or  operation  and  management that could be exploited to violate the system's security policy [79]. New security  vulnerabilities  are  discovered  every  day  in  commonly  used  applications.  The  Open  Web  Application  Security  Project  (OWASP)25 publishes  the  list  of  the  most  critical  web  application  vulnerabilities. Some common vulnerabilities and attacks are:  

‐ Cross‐site scripting (XSS) vulnerabilities. The vulnerability occurs when an attacker submits  malicious data to a web application.  

‐ Injection  vulnerabilities.  This  includes  data  injection,  command  injection,  resource  injection,  and  SQL  injection.  SQL  Injection  occurs  when  a  web  application  does  not  properly filter user input and places it directly into a SQL statement.  

‐ Cookie poisoning is a technique mainly employed for achieving impersonation and breach  of  privacy  through  manipulation  of  session  cookies,  which  maintain  the  identity  of  the  client.  

‐ Unvalidated input. It includes tainted data and forms, improper use of hidden fields, use of  unvalidated  data  in  array  index,  in  function  call,  in  a  format  string,  in  loop  condition,  in  memory allocation and array allocation.  

‐ Authentication, authorization and access control vulnerabilities could allow malicious user  to gain control of the application or backend servers.  

‐ Incorrect  error  handling  and  reporting  may  reveal  information  thus  opening  doors  for  malicious users to guess sensitive information.  

OWASP  initiative  has  also  created  the  Application  Security  Verification  Standard  (ASVS)  with  the primary to normalize the range in the coverage and level of rigor available in the market  when it comes to performing web application security assessment [78]. The standard provides  a  basis  for  testing  application  technical  security  controls,  as  well  as  any  technical  security  controls in the environment, that are relied on to protect typical vulnerabilities. Therefore, this  standard can be used to establish a level of confidence in the security of web applications.  The ASVS defines four levels of verification that increase in both breadth and depth as moving  up the levels: 

‐ Level 1, “Automated  Verification”.  It is typically appropriate for  applications  where some  confidence  in  the  correct  use  of  security  controls  is  required.  There  are  two  constituent  components  for  Level  1.  Level  1A  is  for  the  use  of  automated  application  vulnerability  scanning  (dynamic  analysis)  tools  in  order  to  detect  vulnerabilities  in  the  application’s  security  controls.  Level  1B  is  for  the  use  of  automated  source  code  scanning  (static  analysis)  tools  to  search  through  the  application  source  code  to  find  patterns  that  represent vulnerabilities.  

‐ Level 2, “Manual Verification”. It provides some confidence in the correct use of security  controls and confidence that the security controls are working correctly. Level 2A consists  on  manual  application  security  testing  consists  of  creating  dynamic  tests  to  verify  an  application’s proper design, implementation, and use of security controls. Level 2B consists  on manual code review consists of human searching and analysis of the application source  code in order to verify the application’s design, implementation, and proper use of security  controls.  

‐ Level  3,  “Design  Verification”.  It  is  typically  appropriate  for  applications  that  handle  significant  business‐to‐business  transactions,  including  those  that  process  healthcare  information, implement business‐critical or sensitive functions, or process other sensitive  assets.  

‐ Level  4,  “Internal  Verification”.  It  is  typically  appropriate  for  critical  applications  that  protect life and safety, critical infrastructure, or defence functions.  

Therefore,  the  proposed  method  to  evaluate  security  in  this  dissertation  corresponds  to  the  Level 1A, since 1B requires access to the source code in the server‐side. It is not the greatest  procedure  to  assess  the  security  of  a  website,  but  at  least  provides  a  minimum  effort  for  developers because it is completely automatic. 

Similarly to performance testing, security testing will be assessed by adding a web application  scanner  to  the  functional  approach.  This  scanner  will  attack  each  page  of  each  path  in  the  navigation. This module will also be in charge of the security oracle, i.e. to check whether or  not  each  attack  is  effective  or  not.  When  an  attack  discovers  a  security  hole,  it  should  be  documented in the test report as usual. 

Another  similar  way  of  classify    web  applications  security  assessment  tools  was  proposed  by  Curphey  and  Araujo  [71],  establishing  eight  categories  of  such  tools:  source  code  analysers,  web  application  (black‐box)  scanners,  database  scanners,  binary  analysis  tools,  runtime  analysis  tools,  configuration  management  tools,  HTTP  proxies,  and  miscellaneous  tools,  as  follows: 

‐ Source  code  analysers.  This  kind  of  tools  search  patterns  in  source  code  files  to  detect  security  defects.  The  main  benefit  of  these  tools  is  that  they  integrate  tightly  into  the  development  process  and  early  in  the  construction  process.  The  main  drawback  is  that  they are limited in what they actually find and are prone to reporting false positives.  ‐ Web application scanners (also known as black‐box scanners) use a web browser to mimic 

an attack. These tools attempt to inject malicious payloads into HTTP requests and watch  for indications of success in the resulting HTTP response. The benefit of black‐box scanners  is  that  they  require  little  skill  and  they  are  also  effective  at  finding  many  configuration  management issues. The drawback is that these tools perform poorly, i.e., they find little  vulnerabilities.  

‐ Database  scanners  act  as  an  SQL  client  and  perform  various  database  queries  to  analyse  the database’s security configuration. These tools are easy to use but rarely find problems  outside database configuration.  

‐ Binary Analysis Tools. These tools attempt to fuzz the input parameters of public functions  (mainly  C  and  C++)  looking  for  signs  of  an  application  crash,  common  vulnerability  signatures,  and  other  improper  behaviour.  Binary  analysis  tools  are  easy  to  use  but  produce very complex results so a highly skilled analyst is required to understand and use  the results effectively. 

‐ Runtime  analysis  tools  essentially  act  like  profilers  and  intercept  function  calls  as  they  occur.  Instead  of  identifying  application  bugs,  these  tools  give  reviewers  and  testers  a  variety of critical information, letting them make the decision themselves.  ‐ Configuration Analysis Tools. These tools usually performs static analysis, but rather than  examining code, typically operate against the application configuration files, host settings,  or server configuration.  ‐ Proxies trap the HTTP request and response, allowing testers to view and modify different  parts of the request, ranging from cookies, HTTP headers, GET and POST parameters, and  HTML content. 

- Miscellaneous:  Other  tools  do  not  directly  fit  under  any  category,  such  as:  i)  White‐box  tools for performing security‐related activities such  as unit testing and web  UI testing. ii)  Black‐box  tools  that  attempt  brute‐force  authentication  against  the  web  application  or  check for search‐engine information leakage (leading to what is often termed as “Google  hacking”). 

All in all, web applications scanners (which correspond to the level 1A of security according to  OWASP)  will  be  employed  in  this  dissertation  to  assess  security  in  the  client‐side  of  web  applications.