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
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
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/
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
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/
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
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 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
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/
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
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 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
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
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
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
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
unt_csc
tammielis
deanohume
inesmontani
ryanjones
erikaheidi
uxyall
rkendrick25
addyosmani
thirion
aleyda
panda_program
