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 &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

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