Secure Coding Presented by the UNT Cybersecurity Club 

What is Secure Coding? ● Secure coding is the act of programming with security in mind in order to keep applications free from vulnerabilities ○ Or, more realistically, to reduce the number of vulnerabilities present in an application ● Secure coding involves a shift in mindset ○ Instead of just thinking about functionality, think about security as well ○ Don’t let security be an afterthought 

Why Do We Care? ● One study found that one application security incident can cost companies an average of $300,000 ● Sensitive user data is often at risk ○ For example, credit card information, social security number, etc. ● If we can make our code more secure, we can reduce the risk of malicious attackers finding and exploiting vulnerabilities in our applications ● Cybersecurity: It’s All About the Coders 

Security in the SDLC ● Security is often an afterthought during testing and maintenance ● Ideally, though, security should be a concern all throughout the SDLC ○ This doesn’t mean every developer needs to become a security expert ○ However, everyone involved should be aware of security concerns ○ For example, think about security concerns when planning and designing an application ○ Follow secure coding practices when actually creating an application http://ddi-dev.com/blog/programming/7- best-software-development- methodologies-pros-and-cons/ 

Facets of Secure Coding ● Secure coding encompasses a number of different security and development- related concerns and topics including: ○ Input validation ○ Proper cryptography ○ Error handling ○ Permissions ○ Threat modeling ○ And more ● Simply being aware of these concerns can help you take steps to improve application security 

Input Validation ● Improperly validating inputs (or not validating them at all) can leave software vulnerable to a number of different attacks ● Primarily: ○ Buffer overflow attacks ○ SQL injection attacks ○ XSS attacks ● Luckily, the solution is (generally) pretty simple: validate your inputs! ● The exact way of validating inputs varies based on language and situation, but it generally is not very difficult https://xkcd.com/1354/ 

Buffer Overflow Attacks ● A buffer overflow attack can occur when a buffer is given more data than it is intended to hold ○ Buffer: “sequential section of memory allocated to contain anything from a character string to an array of integers” ○ Data flows past the end of buffer into other areas of memory ○ Mostly a concern when dealing with memory management in low-level languages (eg. C or C++) ● Buffer overflow attacks can allow execution of malicious code or the extraction of data being read ○ For example, a malicious user could write over a return address in a stack frame to force code execution somewhere other than intended 

Preventing Buffer Overflow Attacks ● Buffer overflow attacks can be prevented by validating inputs and using safe system functions ○ Make sure users can’t write more data than expected to a buffer ○ For example, in C, use fgets() instead of gets() ■ gets() doesn’t allow you to check buffer length, thus leaving you vulnerable ○ Exact solutions vary based on language and situation; take the time to learn what needs to be done in a given language https://www.synopsys.com/blogs/software-security/detect-prevent-and-mitigate-buffer-overflow- attacks/ 

SQL Injection Attacks ● SQL injection attacks take advantage of SQL queries to obtain or modify data users are not supposed to have access to, get around authentication, etc. ● SQL injection attacks work by altering a SQL query or performing an additional query afterwards ○ SQL queries are common whenever data needs to be retrieved, creating many opportunities for SQL injection attacks ○ For example, a SQL injection attack on an online store could reveal user data which could then be used to retrieve credit card information, home addresses, etc. by querying data from a users table in some way ○ A SQL injection attack could also be to bypass an admin login by appending some true statement to the end ■ For example something like, “password’ OR 1=1” could bypass weak login forms ● Injection is #1 on the OWASP Top Ten list of web app vulnerabilities 

Preventing SQL Injection Attacks ● SQL injection attacks can be prevented or mitigated by validating inputs ● Avoid sending user input directly into a query; instead sanitize it first ○ For example, remove or replace single quotes that can end a string input ● Additionally, parameterized queries (also called prepared statements) can help prevent SQL injection attacks ○ This is because inputs are forced to act as strings ● See the OWASP SQL Injection Prevention Cheat Sheet for more https://xkcd.com/327/ 

XSS Attacks ● Cross Site Scripting (XSS) attacks inject malicious browser code (eg. HTML, JavaScript, etc.) into a website through some sort of input form ○ This code can access cookies, session data, etc. from other users ○ It can also write over the existing HTML source ● Stored XSS attacks store some browser code on a server ○ It could be stored in a comment, on a forum board, etc. ○ This code is then executed whenever a user visits that part of the website ● Reflected XSS attacks are passed through some sort of link or email ○ Typically, the malicious code is in the URL in some way ○ However, your browser will trust the source of the website 

Preventing XSS Attacks ● Validate data so that users can’t inject code into your website ● Avoid putting untrusted data (ie user-inputted data) anywhere in your HTML, JavaScript, or CSS as much as possible ● Escape out of any characters that could cause code to execute ○ For example, escape out of &, <, >, ‘, “, and / for HTML ○ Escape out of non-alphanumeric characters for JavaScript ● See the OWASP XSS Prevention Cheat Sheet for more info 

Use Cryptography ● If you have any data at all, use cryptography to secure it ● Any language you use will have libraries, frameworks, and/or built-in cryptographic functionality ○ Take advantage of this! ○ You should never implement cryptography yourself (in production code) ● Additionally, any passwords you store should be hashed (with salts) ○ Never store passwords in plaintext ● Be aware of what is considered cryptographically secure ○ For example, don’t use DES for encryption 

Handle Errors Gracefully ● Default error messages often give away information about what language your program uses, what kind of backend server you have, etc. ○ This information can be valuable to an attacker ○ Any additional knowledge about your systems or your network can potentially be exploited ● When handling errors, it’s best to override default messages and insert custom messages that don’t give away any valuable information 

Principle of Least Privilege ● Run processes for your application with the least privilege needed to get the job done ● Avoid giving processes unnecessary extra permissions ○ These elevated permissions could be exploited by attackers ○ For example, don’t run a backend server as root user unless you absolutely need to (which you probably don’t) ● If elevated permissions are required for a process or task, minimize the amount of time these permissions are granted 

Threat Modeling ● Threat modeling is a way of understanding and documenting potential threats to a system ● When modeling threats, you should seek to understand: ○ What your system is and how it is supposed to function ○ What assumptions you’re making about the system ○ The potential threats to your system ○ How to mitigate those threats ● Building a threat model can help you secure your applications, understand and balance risks, and better test your systems 

Learning More ● Take the time to find out about security and cryptography features in the languages you work with ● Start thinking about security when you write code ● Be aware of what vulnerabilities can arise in the applications you create ● Look into OWASP, Microsoft Secure Development Lifecycle, CERT secure coding standards, etc. ● Links with additional information can be found on the References slide 

Any Questions? 

Upcoming Events ● 2/20: Citi Bank ● 2/27: Secure Coding Activity related to today’s presentation 

References ● https://www.perforce.com/blog/sca/what-secure-coding ● https://www.insecure.in/input_validation.asp ● https://whatis.techtarget.com/definition/input-validation-attack ● https://www.veracode.com/security/buffer-overflow ● https://beej.us/guide/bgc/html/multi/gets.html ● https://www.acunetix.com/websitesecurity/sql-injection/ ● https://owasp.org/www-community/attacks/xss/ ● https://en.wikipedia.org/wiki/Category:Broken_cryptography_algorithms ● https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices ● https://owasp.org/www-community/Application_Threat_Modeling ● http://www.infosecisland.com/blogview/13075-Software-Security-Incidents-Cost-an-Average- 300000.html