This is the first presentation in the 300 level, specifically targeting developers with a more hardcore training program. This program includes numerous case studies and live demonstrations and is considered very technical.

1. Application and Website
Security – Developer
Edition:
Introducing Security Into Development
Daniel Owens
IT Security Professional

2. Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclusion And Appendices

3. Session Prerequisites
Development experience is a plus
Knowledge of basic SQL is a plus

4. Communication Media and Security
Concerns
Communication media:
‘Wired’ networks
‘Wireless’ networks
Security concerns:
The Insider
The Outsider
The Technology
Nature

5. Consequences of Poor Security
Stolen intellectual property
System downtime
Lost productivity
Damage to NASA’s reputation
Lost public confidence
Lost revenue
Congressional inquiries

6. Examples of Security Intrusions
Apache Software
Foundation
Red Hat
LMIT/NGC
Tricare
VA
NASA
Attacker
Virus

7. Challenges When Implementing
Security
Attacker needs to know only one flaw or be an expert in one thing
Defender needs to know of and secure all entry points
Attacker has unlimited time and potentially greater resources
Defender works with time and budget constraintsAttackers vs. Defenders
Security vs. Usability
Overly/Improperly secured systems can be more difficult to use
Complex or strong passwords can be difficult to remember
Users prefer simple passwords and simply password reset
mechanisms
Do I need
security…
Security As an Afterthought
Many developers think that security hinders functionality and is
harmful to the user
Management often thinks of security and patching flaws as purely
overhead

8. The Developer Role in Security
Developers must:
Work with clients, program managers, designers,
testers, architects, and systems administrators to
ensure security
Work with specialists who are knowledgeable
concerning application and website security
Contribute to security by:
Adopting good security development practices
Knowing where security vulnerabilities occur and how
to avoid them
Using secure programming techniques
Communicate heavily with peers and users

9. Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclusion And Appendices

10. Secure Software Development
Lifecycle
Requirements
Phase
Architecture
Phase
Design
Phase
Implementation
Phase
Test
Phase
Deployment
Phase

11. Requirements Phase
Application Program Manager must take the
initiative and document the following (in
concert with the client):
What the application MUST be able to do
What kind of data the application is to
hold/process (e.g. SSNs and health information)
The security requirements to be followed
Any legal requirements the application MUST
follow

12. Requirements Phase (cont.)
Examples:
Client Application PM must also dictate:
Developer training requirements
Testing requirements/secure coding requirements
Developer security controls regarding the source
code
Any requirements incumbent upon the client (e.g.
Computer Security Act of 1987 and E-
Government Act of 2002)
Any additional requirements (e.g. L&F,
acceptable languages, environment)

13. Architecture Phase
Application Program Managers must take the
initiative and document the following (in
concert with the client):
The operating system(s) upon which the
application is to operate
Operating System constraints
Memory constraints
Processing power constraints
The network environment
Any other operational/architectural constraints
and requirements

14. Design Phase
During the design phase, the Design Team
should document the following:
The language(s) to be used
Coding Standards and Guidelines
The third party modules, libraries to be used
How to secure data
Data types, naming schemas, etc
These should detail HOW to accomplish the
requirements while not exceeding the
constraints and should be carefully examined

15. Implementation Phase
The Development Team should ensure that
the code:
Follows the Coding Standards and Guidelines
Follows the design documentation
Does not allow a violation of the Byzantine
Generals Problem
Is well-written; methodically written; and adheres
to all requirements, protocols, standards and best
practices that are applicable for the system
Is SAFE and SECURE

16. Test Phase
The Test Team should ensure that the
system:
Never enters an unstable or unknown state
Is free from input validation, logic, and other flaws
Provides the appropriate levels of assurance for
confidentiality, integrity, and availability
Maintains adequate code coverage statistics
Adheres to the requirements set forth in the
previous phases

17. Deployment Phase
The Release Manager and Application
Administrator should ensure that:
The source code and binaries are fully protected
The software is distributed with appropriate
security guidance
The software is installed in accordance with all
appropriate security guidance
The software is operated in a secure manner

18. Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclusion And Appendices

19. Common Vulnerabilities
* Often Cited As Two Major Areas:
Design
Implementation
* But A Third Major Area Exists:
• Architecture
* Other Areas:
Requirements
Deployment
Testing

20. Design Flaws
Design flaws often require significant
redesign and redevelopment to resolve
Example Design Flaws
Weak encryption or using encoding instead of
encryption
Requires choosing a new encryption algorithm and can
require a slew of changes… especially in a client-
server model
Weak access control
Often requires a complete redesign of both the
authentication mechanisms and most of the modules to
accommodate the new access control

21. Design Flaws (cont.)
Example Design Flaws (cont.)
Overexposed resources
May require a complete redesign of the entire system
Incomplete input validation mechanisms or
algorithms
Will likely require modifications in several places
Incomplete threat modeling
May require a complete redesign of the entire system
Math flaws, bad assumptions, etc.
May require a complete redesign of the entire system

22. Design Flaws (cont.)
Example Design Flaws (cont.)
Poor adherence to secure design principles
May require a complete redesign of the entire system
and significant code rewrites
Poor adherence to multi-threading or multi-
processing design principles
May be extremely difficult to reproduce, track down,
and then eliminate
Poor adherence to requirements and architecture
documents
May require a complete redesign of the entire system
and significant code rewrites

23. Design Flaws (cont.)
Example Design Flaws (cont.)
Choosing the wrong language
May make implementation difficult, extremely buggy,
break the time or space requirements set forth by the
architecture documents, or result in code that is difficult
to manage

24. Flaw Case Studies 1
Design Flaws
Weak Encryption
Weak Access Control
Overexposing Resources
Incomplete Input Validation
Failure To Follow Secure Design Principles
Neglecting To Adhere To Requirements
Choosing The Wrong Language

25. Implementation Flaws
Implementation flaws may be hard to track
down in large projects and may require
substantial modifications to the source code
Example Implementation Flaws
Poor adherence to multi-threading or multi-
processing development principles
May be extremely difficult to reproduce, track down,
and then eliminate
Poor adherence to change management
principles
Violates the Byzantine Generals Problem

26. Implementation Flaws (cont.)
Example Implementation Flaws (cont.)
Poor adherence to the client-server principles
May produce software that doesn’t operate with other
software, is more buggy, or is more vulnerable to
attack
Poor adherence to the requirements, architecture,
and design phase documentation
May make the software unusable and require a
complete rewrite of major portions of the code
Programming errors, misunderstandings, math
errors, etc
Can be simple to correct, but can also be numerous

27. Flaw Case Studies 2
Implementation Flaws
Race Conditions
Weak Change Management
Failure To Follow Client-Server Model
Programming Errors
Math Flaws
Misunderstandings
Failure To Follow Design, Requirements, Arch.

28. Architecture Flaws
Architecture flaws normally don’t become
obvious until either during testing or once the
system has been deployed, so they can
become both embarrassing and impossible to
get passed
Example Architecture Flaws
Poor understanding of the requirements
If not caught soon enough, the system may not recover
Poorly architected hardware
This can doom a system

29. Flaw Case Studies 3
Architecture Flaws
Poor Understanding Of The Requirements
Poorly Architected Hardware

30. Requirements Flaws
Requirements flaws, like architecture flaws
occur in the beginning of the cycle, so impact
the most phases in the cycle; if not caught
early, these can be expensive to fix
Example Requirements Flaws
Neglecting to spell out client requirements
If the client’s requirements aren’t well known, the
system cannot be properly constructed
Neglecting to spell out functional requirements
If these requirements aren’t properly dictated, the
system will most likely be missing desired functionality

31. Requirements Flaws (cont.)
Example Requirements Flaws (cont.)
Neglecting to spell out testing
activities/requirements
The software may not be tested in accordance with
client requirements or not properly/fully tested
Neglecting to spell out security requirements
The software may have additional vulnerabilities
Neglecting to spell out protocols and relationships
between interprocessing units
Can make the software unusable in a parallel
processing or client-server environment (or
heterogeneous environment)

32. Flaw Case Studies 4
Requirements Flaws
Neglecting To Spell Out Client Requirements
Neglecting To Spell Out Functional Requirements
Neglecting To Spell Out Testing Activities
Neglecting to Spell Out Security Requirements
Neglecting To Spell Out Protocols And
Relationships Between Interprocessing Units

33. Deployment Flaws
Deployment flaws may be the result of poor
requirements or architecture, they may also
be because of design flaws or implementation
flaws, but often require a knowledge of the
system to detect/remediate
Example Deployment Flaws
Poor adherence to secure installation and
operation guidance
If none is available, it must be created, otherwise it
may be easy to fix unless this is required because of a
bug in the software

34. Deployment Flaws (cont.)
Example Deployment Flaws (cont.)
Insecure defaults
Requiring a slew of changes to make a system more
secure means that some changes may be missed or
simply not made
Enabling debugging or compiling with debugging
flags
This provides an attacker with more information than
the attacker needs to have
Poor change management
Can doom a system

35. Flaw Case Studies 5
Deployment Flaws
Poor Adherence To Secure Installation/Operation
Documentation
Insecure Defaults
Debugging Enabled
Poor Change Management

36. Testing Flaws
Testing flaws allow immature code to be put
into production environments, putting the
production environment at risk
Example Implementation Flaws
Failure to follow the requirements and test for
adherence to the requirements
The tests may not be valid or may miss key bugs and
requirements that were not adhered to
Failure to have complete code coverage
Without complete code coverage, there could be many
simple bugs that were missed

37. Testing Flaws (cont.)
Example Testing Flaws (cont.)
Failure to test for security vulnerabilities
Allows security vulnerabilities to go unnoticed
Failure to perform tests in a realistic environment
The tests are only valid for the environment in which it
the tests are performed
Failure to properly report problems
If they aren’t properly reported, they are difficult to fix
Failure to perform regression testing and verify
fixes
Can lead to incorrect assumptions of correctness

38. Flaw Case Studies 6
Testing Flaws
Failure To Follow/Test Requirements
Inadequate Code Coverage
Poor Vulnerability Testing
Failure To Simulate Real Environment
Failure To Properly Report Bugs
Failure To Perform Regression Testing

39. Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclusion And Appendices

40. Holistic Approach to Security
Security must be considered at:
All stages of a project
Requirements
Architecture and Design
Development
Test and Deployment
All levels
Physical
Network
Operating System
Application

41. Threat Modeling
Threat modeling is:
A critical part of the requirements and design
phase
Requires the system be examined for possible
security threats
Threat modeling:
Reduces the cost of securing a system
‘Bakes’ security into the system
Helps the design and development teams:
Identify where the application needs the most
protection

42. Ongoing Education
Provide training that teaches
How security features work
How to use the security features to build secure
systems
What security vulnerabilities look like in order to
identify flawed code
What attacks look like in order to test for flaws
and better understand the issues
How to avoid common security vulnerabilities or
repeat previous mistakes

43. Input Validation
Buffer overruns
Buffer underruns
SQL injection
Cross-site scripting
Typing
Command injection

44. ASP.NET Cross-Site Scripting
<%@ Page Language="C#"
ValidateRequest="false" %>
<html>
<script runat="server">
void btnSubmit_Click(Object sender, EventArgs e)
{
Response.Write(txtString.Text);
}
</script>
// CONTINUED ON NEXT SLIDE

45. ASP.NET Cross-Site Scripting (cont.)
// CONTINUED FROM PREVIOUS SLIDE
<body>
<form id="form1" runat="server">
<asp:TextBox id="txtString" runat="server"
Text="<script>alert(‘hi’);</script>" />
<asp:Button id="btnSubmit" runat="server"
OnClick="btnSubmit_Click"
Text="Submit" />
</form>
</body>
</html>

46. ASP.NET Cross-Site Scripting 2
<%@ Page Language="C#”
AutoEventWireup="true"%>
<html>
<form id="form1" runat="server">
<div>
Color:&nbsp;<asp:TextBox ID="TextBox1"
runat="server"></asp:TextBox><br />
<asp:Button ID="Button1" runat="server"
Text="Show color"
OnClick="Button1_Click" /><br />
<asp:Literal ID="Literal1"
runat="server"></asp:Literal>
</div>

47. ASP.NET Cross-Site Scripting 2
(cont.)
</form>
</html>
<script runat="server">
private void Page_Load(Object Src, EventArgs e){
protected void Button1_Click(object sender,
EventArgs e){
Literal1.Text = @"<span style=""color:"
+ Server.HtmlEncode(TextBox1.Text)
+ @""">Color example</span>";
}
}
</Script>

48. Sample Cross-Site Scripting Strings
<script>alert(‘hi’);
<script<< alert(‘hi’) </script<<
%3Cscript%3Epref%3Dfunction(a%2Cb)
{document.write(a%2B%22%20-
%3E%20%22%2Bb%2B%22%3Cbr%20%2F%3
E%22)%3B}
%3B%3C%2Fscript%3E%3Cscript%20src%3D%
22view-
source%3Aresource%3A%2F%2F%2Fgreprefs%
2Fall.js%22%3E%3C%2Fscript%3E
<iframe src=”google.com” width=”800px”
height=”400px”
onMouseOut=”parent.location=’machine.aspx’”;>
</iframe>

49. Sample Cross-Site Scripting Strings
(cont.)
<img src=””
onMouseOver=”alert(document.cookie)”; />
http://pizzahut.com%22;%0A%0Dfunction%20help(
){%0A%0D%0A%0Dwindow.open(_helpurl,%20
%22ppwbhelp%22,%22toolbar=yes,location=no,d
irectories=no,status=yes,menubar=yes,scrollbars
=yes,resizable=yes,width=450,height=500%22);
%0A%0D}%0A%0D//%20--
%3E%0A%0D%3C/script%3E%3C!--%20

50. Demonstration 1
Cross-Site Scripting
Bypassing Security Checks

51. C# Overflow On The Heap
static void Main(string[] args){
char[] smallStr=new char[20];
char[] largeStr=new char[250];
for(int i=0;i<250;i++)
largeStr[i]=‘A’;
for(int i=0;i<largeStr.Length;i++)
smallStr[i]=largeStr[i];
}

52. C# Overflow Using Pointer Math
static void Main(string[] args){
Overflow();
Console.WriteLine(“done”);
}
unsafe static void Overflow(){
int* pointer=stackalloc int[32];
for(int i=96;i>0;i--)
*pointer++=0;
}

53. Demonstration 2
Buffer Overflows
Bypassing Security Checks

54. Java SQL Injection
static void main(String[] args){
Connection conn=null;
String username=args[0];
String password=args[1];
String query=“SELECT uid, pass FROM users
WHERE uid LIKE “+username+”%”;
conn=DriverManager.getConnection(“jdbc:odbc:l
ogistics”,”admin”,”LetMeIn”);
Statement stmnt=conn.createStatement();
ResultSet rs=stmnt.executeQuery(query);
…
}

55. PHP SQL Injection
$id=$_GET[‘id’];
if(intval($id)>0){
$dbhandle=new
mysqli(“host”,”username”,”password”,”maindb”);
$query=$dbhandle->query(“SELECT image
FROM images WHERE id = ‘$id’;”);
$result=$query->fetch_row();
$image=base64_decode($result[0]);
$query->close();
…
}

56. PHP SQL Injection 2
$id=intval($_GET[‘id’]);
if($id>0){
$dbhandle=new
mysqli(“host”,”username”,”password”,”maindb”);
$query=$dbhandle->query(“SELECT image
FROM images WHERE id = ‘$id’;”);
$result=$query->fetch_row();
$image=base64_decode($result[0]);
$query->close();
…
}

57. PHP SQL Injection 3
$name=$_GET[‘name’]; $id=intval($_GET[‘id’]);
$dbhandle=new
mysqli(“host”,”username”,”password”,”maindb”);
if(!mysqli_connect_errno()){
$stmt=$dbhandle->prepare(“SELECT * FROM
WHERE name = ‘?’; and id = ‘?’”);
$stmt->bind_param(“si”,$dbhandle-
>real_escape_string($name),$id);
$stmt->execute();
$stmt->bind_results($image,$name,$id,$ssn);
if(!$stmt->fetch()) handleError(“Fetch failed”);
…
}

58. Demonstration 3
SQL Injection
Bypassing Security Checks

59. Whitelisting And RegEx
Whitelisting is:
Specifying only the data that you allow
Normally uses regular expressions to improve
speed
Sample Expressions:
Alpha-Numeric Text Only:
/^[a-zA-Z0-9]+$/
Email Addresses:
/^[w-]+(.[w-]+)*@([a-z0-9-]+(.[a-z0-9-]+)*?.[a-
z]{2,6}|(d{1,3}.){3}d{1,3})(:d{4})?$/
/^[w-]+(.[w-]+)*@nasa.gov?$/

60. Whitelisting And RegEx (cont)
Sample Expressions (cont):
Passwords
/(?=^.{16,255}$)(?=.*d)(?=.*[a-z])(?=.*[A-
Z])(?=.*[!@#$%^&*()_+}{":;'?//<.>,[] ]).*$/
Search for ‘, ’, ’, “, ”, ”, etc.:
/()*[x22x27]/
Search for many SQL injection strings
/(()*[x22x27])|(x23)|(x3b(x20)*--)|(--
x20)|(x2fx2a)|(x2ax2f)|(x2fx2f)/
Search for Non-Standard ASCII characters
/[^x09x0ax0dx20-x7e]+/

61. Overview of Security Technologies
Developers need to use and apply:
Secure communication (to include IPC)
Encryption/Hashing
Digital signatures/Digital certificates
Authentication
Authorization
Access Control and principles of least privilege
Auditing and logging
Ringed architecture (where required) and
interfaces

62. Encryption
Encryption is the process of encoding data
To protect a user’s identity or data from being
read
To protect data from being altered
To verify that data originates from a particular
user
Encryption can be:
Asymmetric
Symmetric

63. Case Study 7
Incorrect Use of SSL
Using weak ciphers
Using unknown CAs (like NASA does)
Only securing the login
Only securing the HTML/images

64. Case Study 8
Common Cryptography
Mistakes
Using encoding
Using a “home-grown” algorithm
Relying on broken algorithms

65. Authentication
Authentication Methods
Basic
Digest
Digital signatures and digital certificates
Integrated
Single Sign-On/Federated Systems
SAML (1.0, 1.1, 2.0, extended, etc)
OTP
Biometrics

66. Case Study 9
Common Authentication
Mistakes
Authenticating once (not every page)
Session hijacking/Session fixation
Error messages
Improper/Poor protection of auth data

67. Demonstration 4
Common Authentication
Mistakes
Session Theft
Cookie Theft

68. Auditing and Logging
Auditing and logging actions include tracking:
Successful and unsuccessful logon attempts
Resource access and usage
Application errors and failures
Auditing:
Helps administrators detect suspicious activities
and compromises
Lets IR teams, administrators, and developers
determine the cause and impact of a compromise
Helps developers detect coding and design flaws

69. Case Study 10
Common Auditing Mistakes
Not protecting audit data
Inadequate auditing (and not customizable)
Writing input directly to the audit logs

70. Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclusion And Appendices

71. Free Code Auditing Tools
C/C++
Lint
Rats
Flawfinder
Yasca
Splint
ASP.NET
CAT.NET
FxCop
SSW Code Auditor (free version)

72. Free Code Auditing Tools (cont.)
Java
PMD
Yasca
LAPSE
PHP
Pixy (for PHP4… PHP5 code must be converted
to PHP4 code)
PHP_CodeSniffer
Spike PHP
Rats

73. Free Code Auditing Tools (cont.)
Perl
Rats
Perl::Critic
Python
Rats
Similar Tools
Valgrind
GDB
010 Editor
Bunny the Fuzzer

74. Security Compass
XSS-Me
A free Firefox plug-in
Performs semi-automated XSS attacks against
POST fields
SQL Inject-Me
A free Firefox plug-in
Performs semi-automated SQL injection attacks
against POST fields
Access-Me
A free Firefox plug-in…

75. Other Firefox Add-ons
Web Developer Add-on
Free
Let’s you view source files cleanly and easily
Let’s you quickly enable and disable things (like
cookies, JavaScript, and Meta Refresh)
Let’s you view and modify form fields and cookie
data
Tamper Data
Free
Let’s you modify most request data

76. Fuzzers
BED.pl
Free Perl script
Performs basic tests of your SERVER
JBroFuzz
Free Java application
Let’s you fuzz any part of an HTTP/HTTPS
request in a semi-automated fashion
Powerfuzzer
Free and commercial versions (Python script)
Easy and multi-talented… automated

77. Other Tools
Sothink SWF Decompiler
Decompiles any Adobe Flash or Flux script
Cavaj
Free
Decompiles any Java program
Nikto
Free
Provides scans of the website looking for
common, basic vulnerabilities and
misconfigurations

78. For More Information
Microsoft Security Site (all audiences)
http://www.microsoft.com/security
MSDN Security Site (developers)
http://msdn.microsoft.com/security
TechNet Security Site (IT professionals)
http://www.microsoft.com/technet/security
SANS Top-20 (IT Professionals)
http://www.sans.org/top20/

79. For More Information (cont.)
Common Weakness Enumeration
(CWE)/SANS Top 25 Most Dangerous
Programming Errors (developers)
http://cwe.mitre.org/top25/index.html
GRC IT Security Office
http://itsecurity.grc.nasa.gov
Most Common Software Errors
http://discussweb.com/software-testing/803-most-
common-software-errors.html

80. Acknowledgements
I stole the background and come clipart from
Microsoft
I stole a lot from my experiences and
previous writings