\documentclass[a4paper]{article}\usepackage[utf8]{inputenc}\usepackage{booktabs}\title{Application Security}\author{Marcin Zelent}\date{May 2018}\begin{document}\maketitle\newpage\tableofcontents\newpage\section{Introduction}
One of the mandatory activities in Computer Science course at Erhvervsakademi
Sjælland is an individual specialization project. In this project, student has
to choose a subject, which was not presented during the lectures, research it
and describe it in the synopsis.
I have chosen application security as the topic that I want to learn more about.
Application security is an umbrella term for all of the measures that need to
taken in order to make a secure application. That means finding, fixing and
preventing security vulnerabilities.
I decided to work on this subject, because in previous semesters we have learned
how to make programs, services and web applications, but we did not learn how to
make them safe from exploitation. It is important, since a potential attacker
could use it to gain access to the system without authorization, retrieve some
sensitive data, abuse or even break the system. This could lead to some serious
consequences.
\section{Problem definition}
During my research I am going to delve deeper into the subject of application
security, its meaning, principles, importance in the modern software
development, as well as practical implementation.
The main question which I would like to answer is:
\medskip{\large How to make a secure application?}\medskip
In order to give an answer to it, I will first need to find solutions to the
following problems:
\begin{itemize}\item What is application security?
\item What are the most common application security flaws and attack
techniques?
\item How software developers can prevent them?
\end{itemize}\newpage\section{Method}
The method which I am going to use in my research consists of a few activities:
\begin{itemize}\item Getting general information about application security using all
of the sources available on the internet, this could include
reading articles, watching videos, talks, lectures and and
online courses
\item Reading books related to the subject of application security
\item Finding detailed descriptions and tutorials about specific attack
techniques
\item Trying to reproduce the attacks by creating vulnerable
applications and exploiting them
\end{itemize}\section{Plan}
To optimize my work and to make sure I will deliver the finishied synopsis
before the deadline, I have prepared a plan which I will try to follow:
\begin{table}[h]
\centering\begin{tabular}{@{}lll@{}}\toprule
Week 18 & Week 19 \& 20 & Week 21
\\\midrule
Writing introduction & Doing an actual research & Writing
conclusion \\
Defining the problem & Describing the work & Reflecting on
the work \\
Choosing the method & Preparing examples & Putting
finishing touches \\
Planning &&\\\bottomrule\end{tabular}\caption{Week plan}\label{my-label}\end{table}
The first week is a project initialization phase, in which I will describe what
I am going to do in the next weeks, how and why.
In the second and third week I will focus on learning, finding information and
describing the results of it. I am also going to work on the practical part of
this project, which is learning how to use different attack techniques and
creating examples for the presentation of them.
In the last week I will look back at my work, write summary of it, as well as
reflections on the research process. I will also proof read my synopsis and
correct any mistakes that I find.
\newpage\section{Work}\subsection{What is application security?}
Application security describes activities that need to be taken into
consideration by a developer who creates an application which will be available
to a broader group of users. Having a large userbase means that there is a risk
that, among the regular users, there might be some individuals with malicious
intents.
These people, usually called attackers, could try to access sensitive data
stored in the database connected to the application or use functions that
normally are only available for the users with special privileges. Such data
could include for example a list of users, some important documents or money in
a bank account. Administrator actions, like adding/removing users or changing
application's settings could be an example of functionality wanted by the
attackers.
In order to achieve their goals, the attackers try to find vulnerablities,
unintended flaws or weaknesses in the application, and exploit them. Although
the application security improved over the years, some of the most common
vulnerabilities remain unchanged and include: broken authentication, broken
access controls, SQL injection, cross-site scripting (XSS), information leakage
and cross-site request forgery (CSRF).
When talking about application security, it usually means web application
security. The reason for this is the fact that web apps are nowadays the most
common form of application. Every day billions of people are searching for
information using Google, browsing Facebook and watching videos on YouTube. All
of these are web applications. What makes them different from regular websites
is that they do not just display static content, but allow users to interact
with them. Users can for example sign up, log in, write comments, upload videos.
A lot of sensitive data is flowing between the user and the system. This, and
being publicly available, makes them frequent targets of the attackers.
Other common targets are mobile and desktop applications, with the emphasis on
the first one. Just like web apps they are usually part of a bigger system and
process private data. Moreover, their security is often neglected by the
developers in favor of having more features. That could make them security
holes, easy gateways leading to the precious resources.
\subsection{Why application security is important?}
There should be no doubt about the importance of application security. There are
many reasons for that.
First and most important is the risk of unwanted disclosure of sensitive data to
the attackers, if the application becomes compromised. This could include names,
addresses, login credentials, credit card information, bank account details,
private photos and many more information about the users of the system. By
breaking into the unprotected system, attackers could also gain access to
company's internal data: important documents, list of employees, private keys
and passwords. All this information could be useful for them in various ways.
For example, it could be used to buy things or perform financial operations
without the knowledge of the account owner. The data could be sold on the black
market or published on the internet. It could be used to harass or blackmail the
unfortunate users. Attackers could also impersonate them and cause even more
problems. It could be especially dangerous when pretending to be a corporate
worker as their actions could harm the entire business. Stealing blueprints,
prototypes or early versions of unreleased products could bring massive
losses of money and force changes of plans.
Another issue is the possibility of gaining access to functionality reserved
only for privileged users, such as moderators and administrators. It could allow
not only for data theft, but also for damaging the system and stored
information. It would allow for spreading viruses and malware throughout the
whole platform, creating a botnet, spambots, mining cryptocurrencies and making
it vulnerable to further attacks. It would be sufficient just to insert
malicious code into the application and infest its users.
Other, non-technical risks include the possible lost of trust from customers,
who value privacy and wish their data to be secure. It could even lead to
lawsuits, like it happened to Yahoo which got sued over security breaches that
took place between 2013 and 2016. Private information of at least 3 billions
users were exposed, it included names e-mail addresses, dates of birth,
phone numbers, passwords, etc. It cost the company hundreds of millions of
dollars and damaged the brand image permanently. On the other hand, providing
good security could help in gaining new clients.
In the wake of mobile and Internet of Things applications, security should be
top priority for application developers. IoT creates many new risks that were
never seen before. Since all of the devices are connected to the internet, they
can be accessed by the hackers. It is a big threat to the privacy of their
users, because they can be used to spy on them 24/7 by utilizing built-in
camera, microphone or reading device activity and logs. This information could
be used to blackmail the victims or even help in burglary. By knowing the
victim's daily routine, the criminal could try to break in to the house when its
owner is out. Moreover, he could exploit the "smart home" security system, since
usually it is also connected to the network. Finally, the attacker could use the
functionality of the compromised IoT devices in a bad way, for example making
them use a lot of power, causing short circuit or even starting fire.
\subsection{Most common application security vulnerabilities}
There are many possible weaknesses but some of them occur more often than the
rest. A non-profit organization called Open Web Application Security Project
(or just OWASP for short), which mission is to make software more secure,
publishes a compilation of these vulnerabilities every 3 years in a document
titled \textit{OWASP Top 10 - The Ten Most Critical Web Application Security
Risks}. It is a result of the work of OWASP, over 40 security companies and over
500 individuals. It lists the most common weakness, describes each of them in
details, with examples and ways of prevention. It also contains further advices
for developers, security testers, organizations and application managers.
The latest release of OWASP Top 10 lists these vulnerabilities as the most
critical web application security risks:
\begin{itemize}\item\textbf{A1:2017 - Injection}
Allows the attacker to execute malicious code in the
application's back-end by tricking the interpreter with a
specially crafted message, e.g. SQL injection.
\item\textbf{A2:2017 - Broken Authentication}
Includes every weakness which would enable the attacker to get
into to the application without authentication, i.e. by
hijacking other user's session, guessing or brute-forcing
password, getting keys or bypassing the login completely.
\item\textbf{A3:2017 - Sensitive Data Exposure}
Exposing sensitive data because of weak protection, lack of
encryption, defective error handling or other behavior.
\item\textbf{A4:2017 - XML External Entities (XXE)}
Exploitation of older or poorly configured XML processors, which
could disclose specific files on the server by parsing an
external entity included in the XML message sent by the
attacker.
\item\textbf{A5:2017 - Broken Access Control}
Allows the attacker to use functionality available only to
privileged users without authorization or to access other users'
accounts and sensitive data.
\item\textbf{A6:2017 - Security Misconfiguration}
Insecure configuration of some components of the system, for
example by using default config files or enabling debugging
options, which give detailed error messages with information
useful to the attackers. This includes also neglect of patching
and updating the components.
\item\textbf{A7:2017 - Cross-Site Scripting (XSS)}
Focuses on attacking users of the application by making their
browser execute code which was previously uploaded to the
app. Could allow to hijack the victim's session or redirect it
to a malicious website.
\item\textbf{A8:2017 - Insecure Deserialization}
Flaws in deserialization algorithms allowing remote code
execution, replay attacks, injection attacks and privilege
escalation attacks.
\item\textbf{A9:2017 - Using Components with Known Vulnerabilities}
A weakness in one component could lead to compromisitation of
the whole system. Application is just as secure its weakest
link.
\item\textbf{A10:2017 - Insufficient Logging \& Monitoring}
Application needs to log what is happening inside it and its
status needs to be monitored so, in case of a breach,
the administrators could detect it, find a cause of it and fix
the weakness.
\end{itemize}\section{Conclusion}\section{Reflection}\begin{thebibliography}{9}\bibitem{webapphandbook}
Dafydd Stuttard, Marcus Pinto.
\textit{The Web Application Hacker's Handbook: Finding and
Exploiting Security Flaws, 2nd Edition}.
John Wiley \& Sons Inc, ISBN: 978-1118026472, 2011.
\bibitem{owasptop10}
The OWASP Foundation
\textit{OWASP Top 10 - 2017 (The Ten Most Critical Web
Application Security Risk)}\texttt{https://www.owasp.org/images/7/72/
OWASP\_Top\_10-2017\_(en).pdf.pdf}\bibitem{lyndaowasptop10}
Caroline Wong.
\textit{Learning the OWASP Top 10}.
\texttt{https://lynda.com/IT-\allowbreak{}
Infrastructure-tutorials/Learning-OWASP-Top-10/642483-2.html}\bibitem{cernertalk}
Michael Coates.
\textit{Application Security - Understanding, Exploiting and
Defending against Top Web Vulnerabilities}.
\texttt{https://youtu.be/sY7pUJU8a7U}\bibitem{mobappsec}
Sarah Vonnegut.
\textit{Mobile Application Security: 15 Best Practices for App
Developers}\texttt{https://checkmarx.com/2015/08/19/mobile-application}\end{thebibliography}\end{document}