an introduction to secure application development
DESCRIPTION
A high level overview of secure software developmentTRANSCRIPT
Christopher M. Frenz
According to a September 2009 SANS report: ◦ 60% of all internet attacks
target Web applications ◦ SQL Injection and XSS
constitute 80% of all recently discovered vulnerabilities
◦ Application vulnerabilities now exceed OS vulnerabilities
Image Source: http://www.sans.org/top-cyber-security-risks/trends.php
Injection
Cross Site Scripting
Broken Authentication and Session Management
Insecure Direct Object References
Cross Site Request Forgery
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Unwanted Redirects and Forwarding
More developers need to be made aware of the need for secure software development as well as the practices associated with secure software development ◦ Education is key
Security needs to be part of the mindset of any software development project from day 1 ◦ Security CANNOT be an afterthought
◦ Security CANNOT be effectively added on later (e.g. firewalls)
Requirements
Design
Implementation
Testing
Release/Maintain
A requirements analysis is used to determine the needs and goals that a software project must meet ◦ Security NEEDS to be a requirement
Threat Modeling and Risk Assessment are often used to help identify and evaluate security requirements ◦ Examples include
STRIDE and DREAD
OCTAVE
A threat modeling methodology ◦ Spoofing
◦ Tampering
◦ Repudiation
◦ Information disclosure
◦ Denial of Service
◦ Elevation of privilege
Makes programmers think like an attacker in order to identify potential ways in which their application could be abused
A risk assessment methodology used to rank threats according to ◦ Damage potential ◦ Reproducibility ◦ Exploitability ◦ Affected Users ◦ Discoverability
Each threat is ranked in each category on a scale of 1 to 3, with 1 being a threat with minimal potential impact and 3 being a serious threat
Threat D R E A D Average
XSS 3 3 2 3 3 2.6
Log Deletion
1 1 1 1 1 1
This methodology allows you to identify which threats pose the biggest risk to your application
The design phase of software development lays out the application architecture and creates the framework upon which the implementation of the software will be based
The design phase must specify what security controls will be implemented in the application and how those security controls are to be implemented
The design must be sure to meet all established security requirements
Input Validation ◦ Whitelisting – matches a US phone # (\s?\(?\d{3}\)?[-\s.]?\d{3}[-.]\d{4})
◦ Blacklisting – matches html tags ((\%3C)|<).*?((\%3E)|>)
Escaping ◦ Converting < to < to render content contained in
<script></script> tags non-executable
Error Handling ◦ Don’t want your application to crash if something
unexpected or unaccounted for happens
Encryption ◦ Don’t want someone sniffing your data or seeing
something they were never meant to see
Authentication ◦ Need to ensure that only valid users gain access
Session Management ◦ Make sure that no one can MITM your sessions or
reinstitute a closed session
Thread Management ◦ Don’t allow for the potential for race conditions or
deadlocks
And many more …
It is important to take time to review your own design and have others review your design to make sure there are no design weaknesses.
It is much easier (and cheaper) to fix a problem at an early stage of the SDLC than at a later stage
Poor design contributes to some of the worst application security problems
The implementation phase deals with the actual writing of code
Before any code is written secure coding standards should be in place and developers educated in the importance and requirements of these standards
Standards help to prevent the introduction of potential vulnerabilities such as buffer overflows
Occur when code is written that allows more data to be passed into a buffer than the buffer was designed to contain
Excess data passed into the buffer can overwrite data in memory and allow an attacker to inject his own instructions (typically shellcode)
Shellcode provides machine instructions for opening up a shell (terminal) on a compromised machine
\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh
void function (char *str) { char buffer[16]; strcpy (buffer, str); } int main () { char *str = "I am greater than 16 bytes"; // length of str = 27 bytes function (str); }
A static code analyzer that can be used to detect potential security bugs in code such as buffer overflows
Peer code review can also be beneficial since it can help to pick up errors that static code analyzers will not be able to identify such as an improper implementation of the design specifications
While many developers are resistant to the idea of code reviews they can be a valuable security and educational tool ◦ Developers are often too close to their own code to
see some flaws
Testing normally entails verification that the application functions properly when presented with a series of use cases
Security testing needs to go beyond use cases and also present the application with “abuse” cases designed to test security controls such as input validation, error handling, etc
Fuzzing is an automated process of providing invalid and random inputs into an application and monitoring the application for crashes
It can help to identify inputs that the application cannot properly handle and that hence could be used as potential attack vectors
Examples ◦ PeachFuzzer
◦ JBroFuzz
Some organizations will also elect to perform penetration testing against their application
Pen testing involves an EXPERIENCED attacker targeting your application and can often lead to the discovery of vulnerabilities that automated testing will not find
Application pen testing is different than network security pen testing ◦ Make sure your pen tester has application security
experience
While it is reasonable for pen testers to make use of vulnerability scanners a vulnerability scan is not a pen test ◦ Passing a Nessus scan does not, in and of itself,
mean your application is secure
Eventually it will come time to release and distribute your application
No matter how carefully you adhered to secure SDLC practices your code WILL have bugs in it
Responsible organizations should have plans in place to deal with the identification, verification, patching of bugs, as well as the distribution of updates, prior to the product being released
Software security is a much needed skill set amongst software developers
Improvements in application security will be highly beneficial to improving the security of information systems
Security needs to be a continuous process that begins with the onset of the software project inception and persists throughout the lifetime of the project
OWASP - https://www.owasp.org/index.php/Main_Page
Building Security In - https://buildsecurityin.us-
cert.gov/bsi/home.html
McGraw, G. (2006) Software Security: Building Security In, Addison Wesley
Howard, M. & Lipner, S. (2006) The Security Development Lifecycle, Microsoft Press