From aceb07718aa45bb994e595fa23308bcb07d01c2b Mon Sep 17 00:00:00 2001 From: Marcin Zelent Date: Wed, 30 May 2018 14:51:32 +0200 Subject: Updated references --- references.bib | 130 +++++++++++++++++++++++++++++++++++++++++++ synopsis.tex | 171 +++++++++++++++++++++------------------------------------ 2 files changed, 194 insertions(+), 107 deletions(-) create mode 100644 references.bib diff --git a/references.bib b/references.bib new file mode 100644 index 0000000..8b7b5ae --- /dev/null +++ b/references.bib @@ -0,0 +1,130 @@ +@book{wahh, + author = "Dafydd Stuttard and Marcus Pinto", + title = "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, 2nd Edition", + year = "2011", + publisher = "John Wiley \& Sons Inc", + isbn = "978-111802647" +} + +@techreport{owasptop10, + title = "OWASP Top 10 - 2017 (The Ten Most Critical Web Application Security Risks)", + url = "https://www.owasp.org/images/7/72/OWASP_Top_10-2017_(en).pdf.pdf", + institution = "The OWASP Foundation", + year = "2017" +} + +@misc{lyndaowasptop10, + author = "Caroline Wong", + title = "Learning the OWASP Top 10", + url = "https://lynda.com/IT-Infrastructure-tutorials/Learning-OWASP-Top-10/642483-2.html", + publisher = "Lynda.com", + year = "2018" +} + +@misc{cerntalk, + author = "Michael Coates", + title = "Application Security - Understanding, Exploiting and Defending against Top Web Vulnerabilities", + url = "https://youtu.be/sY7pUJU8a7U", + publisher = "CernerEng", + year = "2014" +} + +@article{mobappsec, + author = "Sarah Vonnegut", + title = "Mobile Application Security: 15 Best Practices for App Developers", + journal = "Checkmarx", + month = "8", + year = "2015", + url = "https://www.checkmarx.com/2015/08/19/mobile" +} + +@techreport{sbd, + title = "Security by Design Principles", + url = "https://owasp.org/index.php?title=Security_by_Design_Principles&oldid=220008", + institution = "The OWASP Foundation", + year = "2016" +} + +@techreport{sdl, + title = "Simplified Implementation of the Microsoft SDL", + url = "https://microsoft.com/sdl", + institution = "Microsoft Corporation", + year = "2010" +} + +@techreport{whatisappsec, + title = "What is application security", + publisher = "Veracode", + url = "http://vera.cd/1Qo7OHa", + year = "2015" +} + +@article{appsecimp, + author = "Melissa Francis", + title = "The Importance of Application Security: A Few of the Benefits and Risks", + journal = "Veracode", + month = "1", + year = "2017", + url = "https://www.veracode.com/blog/intro-appsec/importance-application-security-few-benefits-and-risks" +} + +@article{yahoobreaches, + author = "Jonathan Stempel", + title = "Data breach victims can sue Yahoo in the United States: judge", + journal = "Reuters", + month = "3", + year = "2018", + url = "https://www.reuters.com/article/us-verizon-yahoo-breach/data-breach-victims-can-sue-yahoo-in-the-united-states-judge-idUSKCN1GO1TL" +} + +@article{iotsec, + author = "Lisa Froelings", + title = "Cybersecurity Threats in the Age of IoT", + journal = "CSO", + month = "2", + year = "2018", + url = "https://www.cso.com.au/article/632981/cybersecurity-threats-age-iot/" +} + +@article{stolendata, + title = "What do Hackers do with Your Stolen Identity?", + journal = "Trend Micro", + month = "6", + year = "2017", + url = "https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/what-do-hackers-do-with-your-stolen-identity" +} + +@techreport{sqlinjection, + title = "SQL Injection", + institution = "The OWASP Foundation", + year = "2016", + url = "https://www.owasp.org/index.php?title=SQL_Injection&oldid=212863" +} + +@techreport{rfi, + title = "Testing for Remote File Inclusion", + institution = "The OWASP Foundation", + year = "2014", + url = "https://www.owasp.org/index.php?title=Testing_for_Remote_File_Inclusion&oldid=180313" +} + +@techreport{cmdinjection, + title = "Command Injection", + institution = "The OWASP Foundation", + year = "2016", + url = "https://www.owasp.org/index.php?title=Command_Injection&oldid=220078" +} + +@techreport{injectionprev, + title = "SQL Injection Prevention Cheat Sheet", + institution = "The OWASP Foundation", + year = "2018", + url = "https://www.owasp.org/index.php?title=SQL_Injection_Prevention_Cheat_Sheet&oldid=237384" +} + +@techreport{xss, + title = "Cross-site Scripting (XSS)", + institution = "The OWASP Foundation", + year = "2018", + url = "https://www.owasp.org/index.php?title=Cross-site_Scripting_(XSS)&oldid=238389" +} diff --git a/synopsis.tex b/synopsis.tex index d7b7776..0f86212 100644 --- a/synopsis.tex +++ b/synopsis.tex @@ -1,9 +1,13 @@ \documentclass[a4paper]{article} \usepackage[utf8]{inputenc} +\usepackage[english]{babel} +\usepackage{csquotes} +\usepackage[style=verbose-ibid,backend=bibtex]{biblatex} \usepackage{booktabs} \usepackage{minted} +\bibliography{references} \setcounter{tocdepth}{2} \title{Application Security} @@ -126,13 +130,13 @@ to a broader group of users. Having a large user base 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 +These people, often 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. +attackers.\autocite{whatisappsec} In order to achieve their goals, the attackers try to find vulnerabilities, unintended flaws or weaknesses in the application, and exploit them. Although @@ -150,36 +154,34 @@ 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. +attackers.\autocite{wahh} 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. - -\newpage +developers in favor of having more features.\autocite{mobappsec} That could +make them security holes, easy gateways leading to the precious resources. \subsection{Why is application security 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. +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.\autocite{stolendata} 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 @@ -187,16 +189,17 @@ 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. +malicious code into the application and infest its users.\autocite{wahh} 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 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. +who value privacy and wish their data to be secure.\autocite{appsecimp} It +could even lead to lawsuits like it happened to Yahoo which got sued over +security breaches that took place between 2013 and +2016.\autocite{yahoobreaches} 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 the top priority for application developers. IoT creates many new risks that @@ -210,9 +213,7 @@ 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 +even starting a fire.\autocite{iotsec} \subsection{Most common application security vulnerabilities} @@ -221,11 +222,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 -pieces of advice for developers, security testers, organizations and -application managers. +Risks}\autocite{owasptop10}. 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: @@ -307,13 +308,13 @@ 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. +login to the system without a password.\autocite{owasptop10} -The way it works is simple. In this case, it is a SQL injection attack. When a -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: +The way it works is simple. In this case, it is a SQL injection +attack.\autocite{sqlinjection} When a 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: \begin{minted}{sql} SELECT * FROM Users WHERE Username = '$USERNAME'; @@ -341,7 +342,7 @@ 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: +is an example of remote file injection\autocite{rfi} made in PHP: \begin{minted}{php} @@ -385,8 +387,9 @@ superuser privileges. \subsubsection{How to prevent it} 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. +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.\autocites{wahh,injectionprev} 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. @@ -432,7 +435,7 @@ with name \texttt{login' OR '1'='1}. Cross-Site Scripting is closely related to injection as it works by inserting a malicious code to the application. There are two categories of this attack: -stored and reflected. +stored and reflected.\autocite{xss} The first one occurs when injected code is stored permanently on the server. An example could be a comment on a forum, which contains Javascript code. If the @@ -466,14 +469,16 @@ To prevent XSS a few methods could be used. Some special characters like \texttt{\%3E}. This way all input will be displayed, but the script will not be executed. Another way would be to completely prohibit usage of \texttt{