Application Security

security padlock

1. Introduction

Network security is often viewed as covering the 7 layer TCP/IP model. This report covers why the distinction is made between Network Security and Application Security and the tools available to developers enabling best practise to be followed.

2. Network Security

Working with the aim of protecting network assets against threats, Network Security can have a very broad scope ranging from hardware, servers, switches, routers, software applications and data, working to achieve Confidentiality, Integrity and Availability (C.I.A.) (Skinner, 2017). However, when considering the 7 layer TCP/IP model only layers 1-4 specifically deal with network transport and 5-7 are application centric, figure 1. For example, a SYN flood attack directly targets vulnerabilities within the TCP/IP protocol suite at layer 4, whereas a buffer overflow attack will occur at level 7 within the application, having clearly left the Network portion of the model.

Figure 1 – 7 Layer OSI TCP/IP Model

3. Applications

Networks enable communication and at either end there is a device running an application receiving or sending data. These applications themselves might legitimately have reason to be publicly available and visible, such as a company webserver running a website. Although, insecure programming techniques could cause unintended application behaviour, potentially leading to data leakage and or system compromise.

Given that different companies and their employees wish to utilise a variety of different products and services both internally and externally, and with introductions of Bring Your Own Device (BYOD) this can lead to a large portfolio of deployed programmes and services running across the network. As of February 2017, The National Vulnerability Database (U.S. Government, 2017) lists over 83,000 known vulnerabilities and another user generated site listing as many as 36700 (Exploit Database, 2017). Additionally, and possibly most importantly vulnerable applications don’t always need to be publicly visible via a network to be exploited by an attacker, the most recently listed vulnerability with CVE allocation 2017-0003 for Microsoft Word allows for a maliciously crafted document to execute arbitrary code resulting in complete system disclosure (CVE Details, 2017), figure 2. Requiring a form of social engineering, or physical contact with the device to exploit.

Figure 2 – CVE-2017-0003 Evaluation (CVE Details, 2017)

It could be reasonably assumed that a network security operative will not have control over source code for the application and that application security be given its own title. This specialist area provided by the programmers who supply the software. Security frameworks have been designed to facilitate secure application development.

4. Frameworks

Given the outlined scope of application security several frameworks exist to help developers of software mitigate the most common mistakes that cause these vulnerabilities. The Open Web Application Security Project (OWASP) provides one such set of guidelines for secure coding practises covering the following topics and more (OWASP, 2010);

  • Input Validation
  • Output Encoding
  • Authentication and Password Management
  • Session Management
  • Cryptographic Practices
  • Error Handling and Logging
  • Data Protection
  • Communication Security
  • System Configuration
  • Database Security
  • File Management
  • Memory Management

Under OWASPs framework each topic is expanded to a series of checklists providing best practise for software development in each language, ensuring that technology and practises are clear, enabling developers to make the correct choices to attain best case of safe or as close to secure applications as possible.

Having frameworks like OWASP provides a standardised approach but new technologies and attacks are constantly pushing the boundaries.

5. Common Application Attacks

IBM (developerWorks security editors, 2015) covers OWASPs 2015 top 10 web application security risks, listing injection attacks as the most common attack taking place. Meanwhile figure 3 shows statistics released by Symantec (Symantec, 2016) on data breaches ranging from 2013-2016, clearly showing high numbers of incidents and the potential risk to businesses and users of their services.

Figure 3 – Reported Data Breaches 2013 – 2015 (Symantec, 2016, p. 8)

Injection attacks at layer 7 are frequently referred to when discussing SQL injection but this can also fall under other headings (IBM Security, 2014);

  • SQL Injection
  • Code Injection
  • OS Commanding
  • LDAP Injection
  • XML Injection
  • SSL Injection
  • IMAP/SMTP injection
  • Buffer Overflow

These headings alone fall under OWAPS’s (IBM Security, 2014) number one category of top ten vulnerabilities and given the large number of reported data breaches this is a significant issue within security, let alone the other nine categories within the OWASP top ten.

Reputable software companies will normally support their products for a specified time but there are many applications in the wild, with many different approaches to application security which could be expensive.

5.1. Attack Costs

Studies performed by the Ponemon Institute (2013) into 277 companies that had experienced sensitive data theft or loss found the following;

  • Highest total average cost to business unit $5.4 million in the US
  • Lowest total average cost $1.1 million in India

Financial cost is not the only concern for businesses, reputation is also at stake. After attacks took place in 2016 on TalkTalk they reportedly lost over 100,000 customers whilst incurring estimated costs of around £60 million (McGoogan & Palmer, 2016) (Farrell, 2016) (Hall, 2016).

Threats are also faced internally from employees, they could be completely unaware that they are enabling an attack in the case of social engineering or they could on the other hand have malicious intent. For example, the F.B.I. (2010) records programmer R.Makwana working for Fannie Mae, who was convicted for malicious code insertion; which if executed was designed to destroy all company data.   The next section looks at mitigating the common SQL injection attack using best practise as outlined by OWASP.

6. Mitigating SQL Injections

User input can come in many forms, sometimes users will input expected values other times they may simple enter it wrong, but if used maliciously user input can be used to extract confidential information from an unauthorised source. When looking at SQL injection OWSAP (2016) looks at the causes of SQL injection and details that it is typically developer design, either creating dynamic queries on the fly or user supplied input containing malicious SQL commands which cause problems.

OWASP goes on to look at ways of preventing this type of attack using one or more of the following;

  • Prepared statements
  • Database stored procedures
  • Escaping all user input
  • White list validation

An example of unsafe PHP code can be seen below in figure 4.

Figure 4 – Unsafe SQL query construction

6.1. Prepared Statements

OWASP (2016) SQL prevention guide recommends the use of prepared parametrised query statements, these allow otherwise unsafe strings to be passed to the database making clear distinction between the SQL and the user supplied data. Attacks using ‘or ‘1==1’ or similar are mitigated sending the entire user input string as the data to be queried.

6.2. Database Stored Procedures

Operating in a similar fashion to prepared statements, except that the SQL is defined and stored within the database. OWASP’s SQL guide points out that dynamic code generation is still achievable within stored procedures and should be avoided whenever possible.

6.3. White Listing Input

If dynamic queries are to be used, then OWASP (2016) SQL prevention guide recommends validating user input against expected values mapping to predefined values in code. An example has been provided using C# in figure

Figure 5 – White Listing Input

Since the returned table name is predefined it is safe to use directly within a concatenated SQL string.

Other OWSAP (2016) recommendations include converting data to their specific types at the earliest opportunity for example; using Boolean values for simple differentiation of commands, an example is provided in figure 6.

Figure 6 – Boolean ASC / DEC selection

6.4. Escaping All User Data

Used only as a last resort OWASP (2016) outlines that it can be extremely difficult to catch all invalid input cases and sometimes will result in valid quires being rejected decreasing application usability.

The OWASP also provides the Enterprise Security API (ESAPI) as a free resource available to developers looking to introduce security options and input validation within their applications, but prepared statements or stored procedures should be used wherever possible.

7. Conclusion

Application security demands careful attention from developers, the risks to businesses can be extremely expensive both financially and in reputation, with such a large range of potential attack vectors and mitigation techniques it is no surprise that vulnerabilities exist. Yet OWASP provides a solid framework comprised of multiple techniques for securing application code against attack, which if followed can prevent leakage of company or user sensitive data and or prevent access to the underlying system or OS from unauthorised parties.

References

CVE Details, (2017) Vulnerability Details : CVE-2017-0003.
Available at: https://www.cvedetails.com/cve/CVE-2017-0003/
(Accessed: 28 Febuary 2017).

developerWorks security editors, (2015) OWASP top 10 vulnerabilities.
Available at: https://www.ibm.com/developerworks/library/se-owasptop10/
(Accessed: 14 March 2017).

Exploit Database, (2017) Exploit Database.
Available at: https://www.exploit-db.com/
(Accessed: 28 February 2017).

F.B.I., (2010) Former Employee of Fannie Mae Contractor Convicted of Attempting to Destroy Fannie Mae.
Available at: https://archives.fbi.gov/archives/baltimore/press-releases/2010/ba100410a.htm
(Accessed: 03 March 2017).

Farrell, S., (2016) TalkTalk counts costs of cyber-attack.
Available at: https://www.theguardian.com/business/2016/feb/02/talktalk-cyberattack-costs-customers-leave
(Accessed: 02 March 2017).

Hall, K., (2016) TalkTalk admits losing £60m and 101,000 customers after that hack.
Available at: https://www.theregister.co.uk/2016/02/02/talktalk_hack_cost_60m_lost_100k_customers/
(Accessed: 02 March 2017).

IBM Security, (2014) OWASP Top 10 Vulnerabilities: #1 Injection.
Available at: https://www.youtube.com/watch?time_continue=48&v=02mLrFVzIYU
(Accessed: 14 March 2017).

Matthews, T., (2014) Incapsula Survey : What DDoS Attacks Really Cost Businesses.
Available at: https://lp.incapsula.com/rs/incapsulainc/images/eBook%20-%20DDoS%20Impact%20Survey.pdf
(Accessed: 2 March 2017).

McGoogan , C. & Palmer, K., (2016) TalkTalk loses 101,000 customers after hack.
Available at: http://www.telegraph.co.uk/technology/2016/02/02/talktalk-loses-101000-customers-after-hack/
(Accessed: 02 March 2017).

OWASP, (2010) OWASP Secure Coding Practises Quick Reference Guide v2.
Available at: https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf
(Accessed: 28 February 2017).

OWASP, (2016) SQL Injection Prevention Cheat Sheet.
Available at: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
(Accessed: 14 March 2017).

Ponemon Institute LLC, (2013) 2013 Cost of Data Breach Study: Global Analysis.
Available at: https://www.symantec.com/content/dam/symantec/docs/reports/cost-of-a-data-breach-global-report-2013-en.pdf
(Accessed: 02 March 2017).

Skinner, R., (2017) NetSec Week1.
Available at: https://learn.ucs.ac.uk/webapps/blackboard/execute/content/file?cmd=view&content_id=_606238_1&course_id=_19349_1
(Accessed: 02 February 2017).

Subashini, S. & Kavitha, V., (2011) A survey on security issues in service delivery models of cloud computing. Journal of Network and Computer Applications, 34(1), pp. 1-11.

Symantec, (2016) Internet Security Threat Report.
Available at: https://www.symantec.com/content/dam/symantec/docs/reports/istr-21-2016-en.pdf
(Accessed: 14 March 2017).

U.S. Government, (2017) National Vulnerability Database.
Available at: https://web.nvd.nist.gov/view/vuln/search-results?query=&search_type=all&cves=on
(Accessed: 28 February 2017).

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *