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: http://www.sans.org/top-
vulnerabilities cyber-security-risks/trends.php
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. 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)
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. 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. 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. Threat D R E A D Average
XSS 3 3 2 3 3 2.6
Log 1 1 1 1 1 1
Deletion
This methodology allows you to identify which threats pose the
biggest risk to your application
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. 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
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. 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. 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. 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. Shellcode provides machine instructions for
opening up a shell (terminal) on a
compromised machine
xebx1fx5ex89x76x08x31xc0x88x
46x07x89x46x0cxb0x0bx89xf3x8
dx4ex08x8dx56x0cxcdx80x31xdb
x89xd8x40xcdx80xe8xdcxffxffxff
/bin/sh
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. A static code analyzer that can be used to
detect potential security bugs in code such as
buffer overflows
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. 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. 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. 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. 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. 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. 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. 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