![Page 1: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/1.jpg)
Christopher M. Frenz
![Page 2: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/2.jpg)
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
![Page 3: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/3.jpg)
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
![Page 4: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/4.jpg)
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)
![Page 5: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/5.jpg)
Requirements
Design
Implementation
Testing
Release/Maintain
![Page 6: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/6.jpg)
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
![Page 7: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/7.jpg)
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
![Page 8: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/8.jpg)
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
![Page 9: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/9.jpg)
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
![Page 10: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/10.jpg)
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
![Page 11: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/11.jpg)
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
![Page 12: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/12.jpg)
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 …
![Page 13: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/13.jpg)
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
![Page 14: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/14.jpg)
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
![Page 15: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/15.jpg)
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)
![Page 16: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/16.jpg)
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
![Page 17: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/17.jpg)
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); }
![Page 18: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/18.jpg)
A static code analyzer that can be used to detect potential security bugs in code such as buffer overflows
![Page 19: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/19.jpg)
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
![Page 20: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/20.jpg)
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
![Page 21: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/21.jpg)
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
![Page 22: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/22.jpg)
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
![Page 23: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/23.jpg)
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
![Page 24: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/24.jpg)
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
![Page 25: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/25.jpg)
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
![Page 26: An Introduction to Secure Application Development](https://reader034.vdocument.in/reader034/viewer/2022042713/5495af72b479593d4d8b4dd6/html5/thumbnails/26.jpg)
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