An Introduction to Secure Application Development


Published on

A high level overview of secure software development

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

An Introduction to Secure Application Development

  1. 1. Christopher M. Frenz
  2. 2.  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 Image Source: vulnerabilities cyber-security-risks/trends.php
  3. 3.  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
  4. 4.  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)
  5. 5.  Requirements Design Implementation Testing Release/Maintain
  6. 6.  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
  7. 7.  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
  8. 8.  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
  9. 9. Threat D R E A D AverageXSS 3 3 2 3 3 2.6Log 1 1 1 1 1 1Deletion This methodology allows you to identify which threats pose the biggest risk to your application
  10. 10.  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
  11. 11.  Input Validation ◦ Whitelisting – matches a US phone #  (s?(?d{3})?[-s.]?d{3}[-.]d{4}) ◦ Blacklisting – matches html tags  ((%3C)|<).*?((%3E)|>) Escaping ◦ Converting < to &lt 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
  12. 12.  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 …
  13. 13.  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
  14. 14.  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
  15. 15.  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)
  16. 16.  Shellcode provides machine instructions for opening up a shell (terminal) on a compromised machine xebx1fx5ex89x76x08x31xc0x88x 46x07x89x46x0cxb0x0bx89xf3x8 dx4ex08x8dx56x0cxcdx80x31xdb x89xd8x40xcdx80xe8xdcxffxffxff /bin/sh
  17. 17. 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);}
  18. 18.  A static code analyzer that can be used to detect potential security bugs in code such as buffer overflows
  19. 19.  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
  20. 20.  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
  21. 21.  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
  22. 22.  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
  23. 23.  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
  24. 24.  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
  25. 25.  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
  26. 26.  OWASP - Building Security In - McGraw, G. (2006) Software Security: Building Security In, Addison Wesley Howard, M. & Lipner, S. (2006) The Security Development Lifecycle, Microsoft Press