Secure Coding

Transcript

1. Secure Coding Presented by the UNT Cybersecurity Club
2. 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
3. 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
4. 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/
5. 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
6. 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/
7. 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
8. 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/
9. 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
10. 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/
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. Any Questions?
19. Upcoming Events • 2/20: Citi Bank • 2/27: Secure Coding Activity related to today’s presentation
20. 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