TM256 Cyber security

Block 3 Part 3 Application security:

part (a)
This item contains selected online content. It is for use alongside, not as a replacement for the module website, which
is the primary study format and contains activities and resources that cannot be replicated in the printed versions.
Copyright © 2022 The Open University

Block 3 Part 3

Application security: part (a)

Contents
Introduction 3
1 The need for application security 4
1.1 What is application security? 5
1.2 The importance of application security 6
2 Application security considerations 8
2.1 Cloud application (SaaS) security 8
2.2 Web application security 9
2.3 Mobile application security 11
2.4 Virtualisation 13
Application security: part (a)
Block 3 Part 3

3 Application security techniques 15

3.1 DevSecOps 15
3.2 Application threats 18
Summary 23
References 23

2 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
Introduction

Introduction
So far in Block 3, you have learned about security from the wider perspective of the IT
infrastructure, by looking at protecting networks. You then examined security from the
perspective of an end user by looking at what it means to protect hosts on a network. In
this part, you will start to examine application security, which you will do broadly in two
parts. This week, you will look at the need for application security, the types of application
that need protecting and the threats that exist in various application domains. You will also
examine some of the processes used in the development of secure software.
In the second half of application security next week (Part 4), you will examine in more
detail countermeasure techniques. You will look at security controls and configuration
techniques employed by software to militate against attack. This is followed by a look at
security testing techniques; in particular, application penetration testing. To conclude, you
will look at the importance of keeping applications up to date.
During both weeks, you will engage with learning activities through a variety of tasks such
as reading, research and tutor group forum discussions. You will examine case studies
and complete practical NetLabs activities, which you will also reflect on in your learning
journal.

3 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
1 The need for application security

1 The need for application security

The need for securing applications is now greater than ever, given the range of different
types of application across the variety of platforms that now exist. The need for application
security has always been an important consideration but has in the past been regarded
somewhat as an afterthought, particularly by software developers. Traditionally, the job of
testing software came at the end of the development cycle and was carried out by a team
separate to that of the software developers (however, on occasion that may still be the
case).
Applications across all platforms and domains, whether they are secured or not, are a
threat to security, as they enable attackers to identify vulnerabilities and find their way
through system defences.
To start off this week, you will look at a case study in the following activity.

Activity 3.16 Case study – Heartbleed

Allow approximately 1 hour to complete this activity

Let’s consider one of the most critical application vulnerabilities to have arisen over the
past decade, the OpenSSL Heartbleed vulnerability. What’s worth noting about this
vulnerability is that OpenSSL is one of the most popular open-source applications and
forms the basis of web security as we know it today.
Heartbleed appeared in 2014 and it was quickly discovered that attackers were able to
exploit OpenSSL along with Transport Layer Security (TLS) and Secure Sockets Layer
(SSL). In doing so, this left critical vulnerabilities in web servers that had implemented
HTTPS, allowing an attacker to trick the server into revealing, for example, usernames
and passwords. The CVE website, which is responsible for identifying publicly
disclosed cyber security vulnerabilities, defined Heartbleed as: ‘TLS implementations
in OpenSSL (before 1.0.1g) do not properly handle Heartbeat extension packets,
which allows remote attackers to obtain sensitive information from process memory via
crafted packets’ (CVE, 2014).
The Carnegie Mellon University Software Engineering Institute (SEI) emergency
response coordination centre also highlighted the seriousness of the vulnerability as
well as the impact it was likely to have. They described how remote unauthenticated
attackers were able to gain access to sensitive information, such as secret keys, and:
‘By leveraging this information, an attacker may be able to decrypt, spoof, or perform
man-in-the-middle attacks on network traffic that would otherwise be protected by
OpenSSL’ (Carnegie Mellon University, 2013).
Computers that are communicating using SSL periodically send each other a
‘heartbeat’ to keep the link active. One device sends an encrypted request, to which
the other responds. The problem arose because the size of the request was remaining
unchecked, which meant sometimes that space in memory was not being allocated as
it should, thus leaving the memory space vulnerable. The problem was caused by an
error in a single line of code:
memcpy (bp, pl, payload);
There was no attempt made in the code to check that the amount of data being copied
from a location was equal to the actual space allocated for the payload value.

4 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
1 The need for application security

Fortunately, this vulnerability was found before any significant damage could be done,
but it is important to highlight it, as seemingly insignificant errors in code can have a
massive impact.
Finally, to give perspective to this application flaw, the BuiltWith website (which
provides statistics on web technologies) estimated that, as of April 2021, there were
approximately 12.5 million websites relying on OpenSSL (BuiltWith, 2021).
Now consider the following discussion on wider issues relating to open-source
software.
Going back ten years or so, there was a perception that open-source software is
insecure and unreliable as it is developed and maintained by a community (as
opposed to paid developers).
Do you think this perception is still valid today? Post your thoughts in your tutor group
forum.

1.1 What is application security?

As an application is being developed, it traditionally goes through a life cycle (see
Figure 3.27, below) in which the application is first specified in a detailed list of
requirements. This leads to the design of the application, which can be performed in
different ways (e.g. prototyping). The design then feeds into the coding of the application,
which can be carried out as a whole (big bang) or in stages (incrementally). Testing of the
application is then carried out before it is finally deployed and maintained. During the
development process, integrated security components are also developed, added and
tested. This is to achieve the aim of mitigating against weaknesses in the application
giving rise to potential threats.

Security Risk analysis/ Code review/ Penetration Security

requirements threat modelling component testing/ operations and
analysis vulnerability assessment
assessment

Requirements

Design

Implementation

Testing

Maintenance

Figure 3.27 The secure software development life cycle

VMware defines application security as: ‘the process of developing, adding, and testing
security features within applications to prevent security vulnerabilities against threats
such as unauthorised access and modification’ (VMware, 2021).

5 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
1 The need for application security

This is only one example of a technique used for the development of software. Later this
week, you will examine in more detail the secure software development process.

1.2 The importance of application security

While we have already briefly hinted at some threats that exist against applications, it’s
worth considering the importance of application security in a little more detail.
An article titled ‘Why is Application Security Important?’ by EC-Council (EC-Coun-
cil, 2020) highlights three important reasons why application security is important:

● Guaranteeing the security of sensitive information: people are still reluctant to

share information online as the protection of sensitive information is still a major
concern. Organisations go to great lengths to protect the information of customers,
clients and end users to ensure that data doesn’t end up in the wrong hands.
● Developing consumer trust and boosting reputation: as well as demands for an
increase in security at the infrastructure and network level, demands at the
application level are now higher than ever. The sooner that security issues in
applications are discovered and resolved, the sooner that businesses and individuals
are safe.
● Mitigating potential attacks: applications are now facing more attacks than ever
before. Vulnerabilities at the application level can be mitigated through application
security testing as well as patching against further attacks. When integrated properly,
application security tools can make processes more efficient as well as ensuring
better compliance auditing.

The EC-Council article goes on to define the challenges in ensuring application security,
as well as making the claim that not enough time is dedicated to application security (as it
is to network security). One challenge is a workforce shortage: it is difficult to recruit
specialist knowledge into the many different domains of cyber security. Also, it can often
be difficult to meet the demands of the testing process, which can, at times, end up in an
almost endless cycle as applications have to be continually patched and fixed.
The article finishes with recommendations on how challenges can be faced, for example,
by using proactive security measures to allow better investment of time, and also by
making sure that vulnerabilities and ‘holes’ in software aren’t left unattended.

Activity 3.17 Investigation – The State of Software Security

Allow approximately 1 hour to complete this activity

We all know that software contains flaws and that this is the major cause of
security vulnerabilities.
(Veracode, 2021)

Veracode is an organisation that makes it its business to examine applications and

code for errors that could lead to disaster. It claims that its reports often make
uncomfortable reading. The report from February 2021 was no different.
Search the OU Library for the article Veracode: State of Software Security v11.
Once you have found the article, read it and then answer the following questions.

6 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
1 The need for application security

1. What sector showed itself to have the most flaws?

2. What was important about these vulnerabilities?
3. What kind of practices could the industry benefit from and why?
4. What does the report highlight as an issue with code libraries?
5. What are organisations recommended to do to eliminate flaws?

Discussion
1. The retail and hospitality sector.
2. The vulnerabilities were ranked as high severity.
3. The industry could benefit from adopting DevSecOps practices because some of
the code is older than that used in other industries and is not subjected to testing
that is as rigorous.
4. Some code libraries are developed and maintained by individuals and are not
subject to proper security auditing and penetration testing.
5. Perform frequent scanning and combine static and dynamic application security
testing.

7 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
2 Application security considerations

2 Application security considerations

Computer applications have long been at risk from security threats, hence the need for
antivirus systems along with other host defence mechanisms that exist today. There are
desktop applications that have been in existence for many years, such as office and
productivity software, which have come under threat from a variety of areas, such as
computer viruses, including macro viruses. There are also web browsers, which again
have long been the target of attacks, such as hijacking techniques using malware, which
can be mitigated through the use of antivirus software (as discussed in Part 2).
Furthermore, if you think back to Block 2 Part 6, you looked at the importance of operating
system security and learned that the security of an operating system is paramount for the
protection of not just the device itself but also of the applications and information being
hosted.
At this point, it is important to examine some of the more contemporary application areas
in computing and IT, as well as the risks that they now face.

2.1 Cloud application (SaaS) security

At several points throughout your studies (e.g. in TM112 and TM129), you have come
across cloud technologies and, in particular, Software as a Service (SaaS). Securing
applications in the cloud is now more important than ever. The International Data
Corporation (IDC) predicts that: ‘By 2022, 90% of new enterprise applications worldwide
will be developed as cloud-native …’ (Dynatrace, 2021). This of course brings additional
challenges in terms of how applications are secured. A cloud environment typically
provides shared resources, which means that it is important that users have authorised
access only to the data within the cloud applications they are using. As data is (normally)
being transmitted across the internet, this presents vulnerability issues, especially as the
data may be sensitive.
A paper about the issues and challenges with SaaS security (Fehér and Sándor, 2019)
demonstrates just how popular SaaS technologies have become over recent years. This
is shown in Figure 3.28 below.

8 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
2 Application security considerations

100 SaaS

90

80

70

60
PaaS
50

40

30

20
IaaS
10
DaaS
0
Jul-2011
Jan-2004
Oct-2004
Jul-2005
Apr-2006
Jan-2007
Oct-2007
Jul-2008
Apr-2009
Jan-2010
Oct-2010

Apr-2012
Jan-2013
Oct-2013
Jul-2014
Apr-2015
Jan-2016
Oct-2016
Jul-2017
Apr-2018
Jan-2019
Figure 3.28 Trends in cloud technologies
In the context of cyber security and the challenges of applications in the cloud, the paper
discusses risks in sharing information with third parties and problems with unauthorised
users gaining access to data. The paper also touches on aspects of physical security and
the potential for loss of data due to disaster.
Architectural elements of security can also be considered, given that SaaS technology is
now enabling organisations to break free of the limitations of on-premises network
security appliances. Cloud vendors are now employing sophisticated firewall appliances
and configurations as well as advanced SIEM solutions. The paper concludes by saying
that as a result of the advanced cyber security solutions now being offered by SaaS
vendors, the vendors are able to gain high levels of trust with the customer – however,
protection of data still remains a concern.

2.2 Web application security

Web application security typically applies to web applications that provide services
through a web-based interface that is accessed across a network or the internet. Most of
the concerns about the security of web applications stem from the same reasons that
were mentioned in the previous section. For example, web applications are normally
provided via a remote server and therefore data is in transit over a network between the
client and the server, leaving it open to interception by malicious users. We also must
consider the data that is being held on the servers themselves, which, when
compromised, may reveal sensitive customer information. Next week, you will be learning
about web and mobile application security in more detail.

2.2.1 A note about architecture

The architecture of web applications has changed somewhat over recent years.
Traditionally, applications were built using server-side technologies that employed mainly
HTML, JavaScript and CSS, which relied heavily on server-side processing (via a server-

9 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
2 Application security considerations

side language). Today, we see a collection of applications communicating with each other
(using secure transmission methods), rather than one application running on a server.
These collections of applications are connected through a Representational State
Transfer (REST) API. The APIs themselves don’t store information because they exist
only to manage requests between different applications (i.e. they are stateless).
Some examples of technologies used in web architectures today include:

● REST API
● JSON, XML
● JavaScript
● Single Page Application (SPA) framework
● authentication and authorisation methods (e.g. login methods)
● web server platform (e.g. Linux, Apache or Nginx)
● database (e.g. MariaDB, MySQL)
● local data store (cookies, web storage).

Given the stateless nature of current web applications, you would think that they bring a
more sophisticated level of security, as data is not actually being stored. However, it could
be argued that the involvement of more technologies now creates a bigger attack surface.
According to Hoffman (2020): ‘Each of these new and upcoming technologies brings with
it new security holes to be found and exploited for good or for evil. It is an exciting time to
be in the business of exploiting or securing web applications.’

2.2.2 Web application firewalls

At different points throughout Block 3, you have learned about firewalls and their use in
different contexts. In Part 1 of this block, you studied the role of the firewall in the overall
context of network security. In Part 2, you examined the use of host-based firewalls.
However, it’s worth mentioning them again and the role that they play in the protection of
web and mobile applications.
Web application firewalls differ from ‘traditional’ firewalls in the sense that they have the
sole aim of protecting web applications (and sites), which they do through analysing HTTP
traffic. Placement is important: a web application firewall is likely to sit in a network behind
a normal (perimeter or external) firewall and in front of the web application server it is
protecting. In Figure 3.29, below, HTTP/HTTPS traffic enters onto the network through the
external firewall, and router access control/screening forwards the HTTP/HTTPS traffic to
the web application server via the web application firewall sitting inside the DMZ.

10 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
2 Application security considerations

External Internal
firewall Screening firewall
router
Internet/
external Internal
network network

HTTP/S Web application

traffic firewall

DMZ Web application

server

Figure 3.29 Web application firewall

A standard firewall employs packet filtering and stateful/stateless mechanisms to permit
or deny traffic, whereas a web application firewall typically employs heuristic, anomaly
and signature-based detection, not unlike antivirus software. If we think about this in terms
of the Open Systems Interconnection (OSI) model, it helps us to understand the operation
of standard and web application firewalls (see Figure 3.30).

Application layer
7. Application filtering HTTP/HTTPS

6. Presentation Web application

firewall

5. Session
TCP – filtering ports
4. Transport
IP – filtering IP addresses

3. Network
Firewall
2. Data-link

1. Physical

Figure 3.30 Firewalls in the context of the OSI model

2.3 Mobile application security

As with cloud and web applications, mobile applications also send and receive data
across the internet, making them just as vulnerable to attack. Mobile applications
generally have a lot in common with web applications and are said to live in the same
‘ecosystem’, as well as being prone to similar kinds of threat. Over the last decade or so,
the increasingly commonplace use of mobile devices (as well as the internet) has led to a
dramatic change in the way applications are being produced. Mobile devices have now
become the most popular way to access the internet, with applications providing not only

11 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
2 Application security considerations

access (through browsers) but also a wide variety of services. ‘There is an app for
everything’ became the mantra of appified software ecosystems, which produced
numerous applications for all sorts of use cases and application areas (Fahl, 2019).
Figure 3.31 below outlines the close relationship between mobile and web applications as
well as how the various processes interact. It’s worth noting that secure development
happens at various stages; for example, security checks or vetting by the app store as
well as within infrastructure, web services and applications. Applications are verified
before release through stores.

Client-side Server-side
Install apps
Mobile Published/
device App store
Update apps

App
User server data Developer
exchange

HTTPS
request
Web Web/app
browser server
HTTPS
response

Figure 3.31 Mobile and web applications

SAQ 3.6 Citizen developer

The CyBOK Web & Mobile Security Knowledge Area discusses how development
tools have led to the rise of non-professional (citizen) developers and discusses the
issues this causes with regard to application security.
Browse to the paper: Web & Mobile Security Knowledge Area. Read the information
box on page 5 (‘The Rise of the Citizen Developer’) and answer the following
questions.

1. Briefly outline some of the issues with citizen development.

2. Are there any other security issues that you think would arise out of this scenario?

Answer
1. Apps are being produced by inexperienced (citizen) developers. APIs that are
used may be from unreliable or untrusted sources, and therefore insecure.
2. Unsecure apps being vulnerable to attacks, such as code injection, and apps
being hosted on unsecure infrastructure.

12 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
2 Application security considerations

Activity 3.18 NetLabs – Working with Android

Allow approximately 1 hour to complete this activity

This activity ties in closely with some of the mobile device concepts that you have just
been reading about. You will use a virtual Android device manager and command-line
tools to debug a phone. The objective for this activity is for you to deploy devices
securely in a given scenario.
Go to NetLabs and complete NetLabs Activity 20: Working with Android. The
instructions to this activity are embedded within the NetLabs environment but a
download is also available from the NetLabs resources page on the module website.

Reflection
After you have completed the activity, write a short reflective account in your learning
journal about any challenges you faced and what you learned from it.

2.4 Virtualisation
You have learned about virtualisation at various points throughout this module; however,
it’s also worth examining the benefits of virtualisation to application security. Virtualisation
is the process of running (emulating) hardware and software within its own isolated
environment. When we create virtual machines (VMs), we can use a hypervisor (either
type 1 or 2) to manage hardware and share hardware resources and operating systems.
This means also running associated applications within the isolated operating system,
which creates additional layers of security.
An operating system and its applications running inside a virtual environment is likely to
be protected in the same way any non-VM-based operating system and applications are –
for example, through host-based security mechanisms like antivirus. The hypervisor may
also offer intrusion detection features, where the hypervisor would alert the VM of any
compromise. Hypervisors and VMs themselves, however, do become targets of VM DoS
attacks. In this case, the attacks have the aim of blocking and/or disrupting the operation
of a VM but not necessarily trying to gain control or access/extract data.
Vulnerabilities and lack of security configuration in VM management consoles (used for
the management of VM resources) can lead to the shutdown of VMs. Virtual networking
hardware can also be the target of DDoS attacks, in which VMs can be overloaded with
data, causing them to slow down or become completely unavailable. These types of
attack are commonly militated against by administrators reconfiguring hardware to reduce
the hardware footprint of the VM that is under attack – for example, deallocating RAM,
disk space and CPU functions.

13 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
2 Application security considerations

Other more elaborate attacks may take place, such as exposing inherent flaws in the VM
software itself, kernel exploitations associated with the operating system running on the
VM and hyperjacking/injection, in which we see the addition of a malicious hypervisor.

2.4.1 Containers
We cannot mention virtualisation security without also discussing the security of
containers. Over recent years, containers have become a very popular method of
building, packaging and deploying software. Containers have the following benefits:

● Flexibility: elements of a container can be updated without having to redevelop and/

or rebuild the entire application.
● Speed: allow for faster and more frequent deployment of software and automated
development methods.
● Resource allocation: containers operate independently of the underlying operating
system and hardware. This allows for more lightweight applications that don’t place
as much demand on the hardware itself (this is where containers differ from VMs).
● Platform independence: they can operate effectively in any environment; for
example, in the cloud or on a host desktop.

As the popularity of containers has recently risen, so have the threats against them. For
attackers, a compromised container is potentially an entry point into an organisation’s
system. There is also the potential for traffic traversing a network to be compromised –
much the same scenario as described in previous sections this week.

Activity 3.19 Investigation – Application Container Security Guide

Allow approximately 1 hour to complete this activity

In 2017, the National Institute of Standards and Technology (NIST) published

guidance on container security. The publication explains potential security concerns
about the use of containers and provides recommendations for addressing these
concerns.
Browse to the guidance: Application Container Security Guide. Read Section 3.4 on
pages 16–17. Briefly summarise each of the points on ‘container risks’ and record your
work in your learning journal.

14 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

3 Application security techniques

Having discussed different application areas and domains, one thing is common to each:
the techniques used to ensure security. You have already learned about most of these
techniques at different points in this module. However, it is worth recapping the role these
techniques play in the development of secure software.
In Section 1.1, you learned about the development life cycle of secure software.
Developers now take account of integrating security features throughout the whole
application development process rather than only at the end of the process during the
testing period. These features are shown in Table 3.6, below.

Table 3.6 Features of application security

Authentication The process of determining that the user is who they say they are. This can
be carried out in different ways, the most common being through the
provision of a username and password. Some applications may require users
to also provide other means of authentication (multi-factor authentication); for
example, entering a passcode that has been sent by email or text.
Authorisation After authenticating the user, providing them with authorisation to use the
application. The system compares the user with authorised users to match
credentials.
Encryption Measures to prevent user account information and sensitive data that is
moving between the end user and the cloud being seen by attackers. HTTPS
provides encryption for traffic across the internet for web applications.
Logging Application log files can identify who has accessed the application and at
what time. Useful if the application is ever compromised.
Security testing The testing process that takes place to ensure that all the security controls
outlined above are working as they should. This is normally an iterative
process.

3.1 DevSecOps
The software development industry has seen a shift over recent years in how security
processes are integrated into the development of applications. The area of DevSecOps
aims to integrate security into already existing methodologies (e.g. agile development).
IBM (2020) describes DevSecOps as: ‘short for development, security, and operations –
[it] automates the integration of security at every phase of the software development
lifecycle, from initial design through integration, testing, deployment, and software
delivery.’
As highlighted earlier this week, security was sometimes regarded as an afterthought and
took place near the end of the development process during the testing phase, and also
when applications were updated once or twice a year. Testing was also typically carried
out by a separate testing and quality assurance team (this, however, may still sometimes
be the case). As well as integrating security at every stage of development, DevSecOps
aims to develop the culture in development teams that everyone is responsible for
security, not just the testers.
There have been many factors that have contributed to the rise of DevSecOps – for
example, the increased importance of security for cloud, mobile and web application

15 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

services, increases in numbers of security incidents, and data protection requirements for
cloud tenants. Figure 3.32, below, outlines the integration of teams within an organisation
as well as the drivers and challenges that they face in the development of secure
services.
External factors

Regulation
Compliance
Market Development teams

Secure
Quality Assurance Security services
New
technology
Security threats Operations/IT
Rapid
releases

Challenges

Figure 3.32 DevSecOps teams and the external factors and challenges they face
The DevSecOps environment operates as follows:

● The development team is responsible for carrying out security testing, along with
‘traditional’ testing teams (QA), with input from operational staff.
● The development team is responsible for managing and fixing any issues that are
found.
● The development team is trained to manage and fix issues to keep issues internal
(in-house) to development processes (not having to rely on external developers to
carry out fixes).

With the rise in popularity of web applications, cloud SaaS and containers, large
(monolithic) applications are now broken down into smaller parts that run more
independently, such as the web application architectural elements mentioned in
Section 2.2.1. This, of course, has led to changes in the development/release cycle: agile
development practices with rolling releases, where software is developed and released at
a rapid pace. Among these, however, there are also now automated development and
testing tools, allowing teams to keep abreast of the rapid changes required.

3.1.1 A brief note on agile software development

Agile software development is an overarching term for a set of development frameworks
and practices that are based on a set of values and 12 principles. Where agile
development differs from traditional software development methods is in its focus on the
people who are doing the work and how they are working together: teams collaborate and
self-organise. Teams should have the ability (through predefined roles in the team) to
figure out how they are going to approach problems on their own through available skill
sets.

16 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

When software development is approached using agile practices: ‘… it’s generally good to
live by these values and principles and use them to help figure out the right things to do
given your particular context’ (Agile Alliance, 2021).

3.1.2 Continuous Integration/Continuous Delivery

One of the newest development practices and set of tools to emerge out of the
DevSecOps arena is ‘CI/CD pipelining’. This can be described, according to Semaphore
(2021), as follows: ‘CI, short for Continuous Integration, is a software development
practice in which all developers merge code changes in a central repository multiple times
a day. CD stands for Continuous Delivery, which on top of Continuous Integration adds
the practice of automating the entire software release process.’
Semaphore (2021) goes on to define the process:

● With CI, each change in code triggers an automated build-and-test sequence for the
given project, providing feedback to the developer(s) who made the change. The
entire CI feedback loop should run (carried out) in less than ten minutes.
● CD includes infrastructure provisioning and deployment, which may consist of
multiple stages. What’s important is that all these processes are fully automated, with
each development run fully logged and visible to the entire team.

From an application security perspective, CI/CD is critical for the following reasons:

● It allows developers to focus on writing while monitoring the behaviour of the system.
● All code changes, tests and deployments are logged, should there be any need for
inspection (if security issues arise).
● Rolling back to previous versions is a straightforward process.
● The rapid development cycle encourages a culture of responsibility.

3.1.3 Other approaches

DevNet is an approach developed by Cisco and has the intention of providing a
development environment aimed at infrastructure professionals and developers who
employ the use of Cisco hardware and software products.
This allows developers to securely integrate software products and automated
procedures into areas such as the cloud, networking hardware (routers and switches),
software-defined networking (SDN), data centres and the IoT. In more general terms, it
allows teams to interact securely throughout the development life cycle using the same
methodologies they would in DevSecOps – for example, agile and CI/CD processes. You
will learn more about Cisco DevNet in Level 3 of the OU Cyber Security qualification
(TM357: Cisco networking (CCNA) part 2).
Microsoft employs its own security development life cycle (SDL), in which a set of 12
predefined practices support security assurance and compliance. SDL also aims to drive
down the cost of development while letting developers build secure software and identify
vulnerabilities.
SAFECode and Touchpoints for software security also exist, where various security
practices, similar to the development life cycle model in Figure 3.27 (Section 1.1), are
employed at stages of the development process.

17 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

3.2 Application threats

Today’s pace of application development is continuously accelerating, giving
way to complex, interconnected software systems. Security and risk manage-
ment leaders need to adopt innovations in the application security space to
handle the growing complexity.
(Gartner, 2020)

We have already hinted at methods we can use during the development process to
secure applications, as well as factors that need to be taken into consideration when
developing applications across different areas such as web, mobile and the cloud. In the
final section of this week, you will examine some of the threats that exist against
applications, and you will also complete this week’s practical exercise where you’ll look at
Cross-Site Scripting.
Given the range and complexity of applications, the threats that exist against them have
become equally complex. The demand for the development of secure applications has
also grown, being driven by a number of factors, such as the external factors identified in
Figure 3.32 (Section 3.1).
Gartner (2020) also says that IT managers: ‘need to go beyond identifying common
application development security errors and protecting against common attack
techniques.’
The Common Weakness Enumeration (CWE) website provides a good starting point for
the identification of threats that exist against applications, some of which you will now
examine.

3.2.1 Cross-Site Scripting

Cross-Site Scripting (XSS) is one of the most common threats to be found on the internet
that affects web applications. XSS is a type of injection, where an attacker inserts
malicious code into a web page, form or URL. The attack normally takes advantage of the
fact that a web browser is responsible for executing the web application script.
XSS attacks can be executed in a number of ways; however, the most popular methods of
attack are as follows:

● Document Object Model (DOM)-based: where malicious code is stored and

executed within the browser. This often affects client-side JavaScript, where the
JavaScript processes data from a malicious source and then writes data back to
the DOM.
● Stored: where malicious code is stored in a database before being executed. This
method is also sometimes known as ‘persistent XSS’. The code that is stored in the
database can attack either the system itself or all users of the application (when the
application interacts with the database).
● Reflected: where malicious code is non-persistent and reflected off the server to the
application under attack. This method is arguably the most common type of attack as
well as being the easiest to prevent. It is also commonly used in phishing attacks.

An XSS attack is most commonly found in JavaScript; however, it can also be found in
HTML and CSS, as well as older web technologies such as Flash and ActiveX (in older
web browsers).

18 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

Figure 3.33 demonstrates a stored attack, where an attacker sends a malicious script that
is stored in a database, which then attaches itself to a vulnerable website. The user
accesses the vulnerable site and the malicious script is sent to the user (to be used for
malicious purposes).
Web Database
Malicious server server
script

Attacker

Data sent
to attacker

Malicious Vulnerable website

Victim script

Figure 3.33 XSS – stored attack example

3.2.2 Misconfigured security

Misconfigured security is one of the biggest threats to applications and, in particular, web
applications. Vulnerabilities exist when an application has weak security options set as
default. Identifying application security misconfigurations can result in quite an exhaustive
list, especially if we think about it in terms of the web application stack: ‘Security
misconfiguration can happen at any level of an application stack, including the network
services, platform, web server, application server, database, frameworks, custom code,
and pre-installed virtual machines, containers, or storage’ (OWASP, 2021a).
Some of the biggest causes of application vulnerabilities include the following:

● incorrect file permissions/ownership

● applications and systems not appropriately hardened
● insecure databases (including access rights)
● out-of-date/unpatched software
● incorrect/reset configuration due to update
● debugging information revealing sensitive information
● application code not properly tested (holes in software).

It’s worth noting that a lot of security misconfigurations are brought about by human
factors/errors, which you will find is a common theme throughout the module.

3.2.3 SQL injection

Along with XSS, SQL injection is one of the most common attacks on the internet today.
This type of attack targets the SQL databases that provide back-end services to a
website. An attacker adds their own parameters to an existing SQL query, or else finds a
way of providing their own query. In any case, this results in the compromise of the

19 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

database, which can result in the loss of data, corruption of tables, or, worse, the loss of
the database itself.
Over the last 20 or so years, SQL has become one of the fundamental elements in
contemporary web development. Used alongside a server-side scripting language
(e.g. PHP), SQL provides the mechanism for interacting directly with the database. The
scripting language is responsible for interacting with the web page (displaying
information), handling the connection to the database and initiating queries via SQL.
SQL’s role alongside the scripting language (being processed by the server) leaves it
vulnerable to malicious injection. According to Hoffman (2020): ‘Old-school PHP
developers would interweave a combination of SQL, HTML, and PHP into their PHP files
– an organizational model supported by PHP that would be misused, resulting in an
enormous amount of vulnerable PHP code.’
Normally, an SQL string is escaped in a HTTP payload, which then leads to the altered
SQL queries being executed on behalf of the end user, as shown in Figure 3.34.

A user sends a web page/script to

a server containing SQL escape
characters and SQL queries

The script (on behalf of the

server) queries the database
based on user input

The SQL interpreter is escaped,

allowing the SQL query to run,
changing the user to ‘admin’

Unknown to the user, the query

has been executed and potential
damage done

Figure 3.34 The stages of an SQL injection attack

W3Schools describes SQL injection as occurring usually when a malicious user is asked
for input, such as a username. Instead of providing that information, the user provides an
SQL statement that is unknowingly run on a database (W3Schools, 2021).

3.2.4 Buffer overflow

Buffer overflow attacks often occur as a result of poorly coded applications and are a
common method for attackers to expose vulnerabilities in applications. A buffer can be
described as a technique of transferring data into temporary storage prior to processing or
output, which then enables the simultaneous operation of devices. An example of a buffer
is a hard drive, which provides buffering to improve performance. Another example is
streaming of audio and video data across a network, which employs buffering techniques
to reduce interruption.
Buffer overflows occur when an application receives more data than it is programmed to
accept. This can cause the application to crash or to write data beyond the end of the
space allocated in memory. If the application crashes, it may cause the system to send

20 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

data that is stored in an unsecure temporary access area within memory, revealing
information in the system. If data is written beyond the end of the space allocated,
important data may be lost. Buffer overflows are a common type of DoS attack.
There are four common types of buffer overflow attack:

● Stack overflow: overflowing a buffer on the RAM call stack.

● Heap overflow: targeting data being held in the heap open memory pool.
● Unicode overflow: inserting Unicode characters instead of ASCII characters
(causing overflow as Unicode characters are larger).
● Integer overflow: causing errors in arithmetic operations that result in integers that
are too large.

The Heartbleed example that we examined at the beginning of this week is a classic
example of a buffer overflow attack.

3.2.5 Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) attacks are designed to take advantage of the way
web browsers operate, as well as the trust relationship that exists between the browser
and the website. When logged into an application, CSRF can trick the browser into
executing malicious actions. This can result in a number of potentially dangerous actions
such as data theft and users revealing sensitive information (e.g. account details,
usernames and passwords). CSRF normally happens through one of the following
methods:

● Phishing techniques – an attacker tricks an authenticated user into following a link

and loading a web page. When the page is loaded, a malicious script executes.
● The attacker sends a HTTP request from the victim’s browser. The website receiving
the request processes it without knowing who has sent the request. The HTTP
request contains information such as the session cookies and IP address
information. As the session cookies ensure that repeated authentication isn’t
required, the attacker can exploit the session to impersonate the user and send
forged requests.

Session cookies are typically used by banking and eCommerce sites to remember
customer information and are therefore vulnerable to attack. Ways to avoid CSRF are as
follows:

● Carry out online banking in a separate browser application to that which you use for
regular internet usage.
● Avoid suspicious emails.
● When using banking or eCommerce sites, make sure to log off completely (instead of
closing the window or browser with the session still open).

3.2.6 A note about the Open Web Application Security Project

The Open Web Application Security Project (OWASP) is a non-profit internet standards
foundation that has been in existence for around two decades. OWASP has the main aim
of working to improve the security of software: ‘Through community-led open-source
software projects, hundreds of local chapters worldwide, tens of thousands of members,

21 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
3 Application security techniques

and leading educational and training conferences, the OWASP Foundation is the source
for developers and technologists to secure the web’ (OWASP, 2021b).
OWASP is known mainly for its OWASP Top Ten, which is an online reference document
for outlining and providing detailed information on the ten most critical web application
security concerns. Data from a number or organisations all over the world is analysed and
then put together to form an ‘awareness document’, in which recommendations are made
as to how organisations can mitigate security risks.

Activity 3.20 NetLabs – Web application scanning

Allow approximately 2 hours to complete this activity

This activity ties in closely with some of the concepts that you have been examining
this week, and introduces some concepts you will learn about next week. The activity
has two objectives:

● to scan a website for vulnerabilities

● to investigate attack techniques.

Go to NetLabs and complete NetLabs Activity 21: Web Application Scanning. The
instructions to this activity are embedded within the NetLabs environment but a
download is also available from the NetLabs resources page on the module website.

Reflection
After you have completed the activity, write a short reflective account in your learning
journal about any challenges you faced and what you learned from it.

22 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
Summary

Summary
During this week, you have examined the basics of application security. You looked at the
need for security and why it is important in the context of different application domains,
such as web, mobile and virtualisation.
You then considered some of the different techniques that are employed by developers
when developing secure software, such as traditional development life cycle approaches,
as well as newer techniques, such as DevSecOps and CI/CD.
You then finished off this week by looking at some of the threats that exist against
applications.
In the next part of Block 3, you will continue to study the topic of application security and
learn about some of the techniques that can be employed as countermeasures to such
threats.

References
Agile Alliance (2021) What is agile?. Available at: https://www.agilealliance.org/agile101
(Accessed: 1 May 2021).
BuiltWith (2021) OpenSSL usage statistics. Available at: https://tinyurl.com/2uth6cdd
(Accessed: 1 April 2021).
Carnegie Mellon University (2013) Software Engineering Institute: OpenSSL TLS
heartbeat extension read overflow discloses sensitive information. Available at: https://
www.kb.cert.org/vuls/id/720951 (Accessed: 1 April 2021).
CVE (2014) CVE-2014-0160. Available at: https://cve.mitre.org/cgi-bin/cvename.cgi?
name=cve-2014-0160 (Accessed: 1 April 2021).
Dynatrace (2021) Securing cloud-native applications. Available at: https://www.dynatrace.
com/monitoring/platform/application-security (Accessed: 1 April 2021).
EC-Council (2020) Why is application security important?. Available at: https://www.
eccouncil.org/what-is-application-security/ (Accessed: 1 April 2020).
Fahl, S. (2019) Web and mobile security knowledge area. Available at: https://www.cybok.
org/media/downloads/Web__Mobile_Security_issue_1.0_XFpbYNz.pdf (Accessed: 1
April 2021).
Fehér, D.J. and Sándor, B. (2019) ‘Cloud SaaS security issues and challenges’, 2019
IEEE 13th international Symposium on Applied Computational Intelligence and
Informatics (SACI), Timisoara, Romania, 29–31 May. Pp. 000131–000134. doi:10.1109/
SACI46893.2019.9111529.
Gartner (2020) Hype cycle for application security, 2020. Available at: https://www.gartner.
com/doc/reprints?id=1-24AQLK47&ct=201002&st=sb (Accessed: 1 April 2020).
Hoffman, A.J. (2020) Web application security: exploitation and countermeasures for
modern web applications. Beijing: O’Reilly Media.
IBM (2020) What is DevSecOps?. Available at: https://www.ibm.com/cloud/learn/
devsecops (Accessed: 1 May 2021).
OWASP (2021a) A6:2017-Security misconfiguration. Available at: https://owasp.org/
www-project-top-ten/2017/A6_2017-Security_Misconfiguration (Accessed: 1 April 2021).

23 of 24 Copyright © 2022 The Open University Thursday 17 March 2022

Application security: part (a)
References

OWASP (2021b) Who is the OWASP Foundation?. Available at: https://owasp.org/

(Accessed: 1 April 2021).
Semaphore (2021) CI/CD pipeline: a gentle introduction. Available at: https://semaphor-
eci.com/blog/cicd-pipeline (Accessed: 1 April 2021).
Veracode (2021) ‘Veracode: state of software security v11’, Network Security, 2021(2),
p. 4-4. doi:10.1016/S1353-4858(21)00016-7.
VMware (2021) Application security. Available at: https://www.vmware.com/topics/
glossary/content/application-security (Accessed: 1 April 2021).
W3Schools (2021) SQL injection. Available at: https://www.w3schools.com/sql/sql_injec-
tion.asp (Accessed: 1 April 2021).

All rights including copyright in these materials are owned or controlled by The Open
University and are protected by copyright in the United Kingdom and by international
treaties worldwide.
In accessing these materials, you agree that you may only use the materials for your
own personal non-commercial use.
You are not permitted to copy, broadcast, download, store (in any medium), transmit,
show or play in public, adapt or change in any way these materials, in whole or in part,
for any purpose whatsoever without the prior written permission of The Open
University.
WEB 10948 5
1.1

24 of 24 Copyright © 2022 The Open University Thursday 17 March 2022