Application and Website
Security – Developer
Edition:
Introducing Security Into Development
Daniel Owens
IT Security Profe...
Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclus...
Session Prerequisites
Development experience is a plus
Knowledge of basic SQL is a plus
Communication Media and Security
Concerns
Communication media:
‘Wired’ networks
‘Wireless’ networks
Security concerns:
The...
Consequences of Poor Security
Stolen intellectual property
System downtime
Lost productivity
Damage to NASA’s reputation
L...
Examples of Security Intrusions
Apache Software
Foundation
Red Hat
LMIT/NGC
Tricare
VA
NASA
Attacker
Virus
Challenges When Implementing
Security
Attacker needs to know only one flaw or be an expert in one thing
Defender needs to ...
The Developer Role in Security
Developers must:
Work with clients, program managers, designers,
testers, architects, and s...
Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclus...
Secure Software Development
Lifecycle
Requirements
Phase
Architecture
Phase
Design
Phase
Implementation
Phase
Test
Phase
D...
Requirements Phase
Application Program Manager must take the
initiative and document the following (in
concert with the cl...
Requirements Phase (cont.)
Examples:
Client Application PM must also dictate:
Developer training requirements
Testing requ...
Architecture Phase
Application Program Managers must take the
initiative and document the following (in
concert with the c...
Design Phase
During the design phase, the Design Team
should document the following:
The language(s) to be used
Coding Sta...
Implementation Phase
The Development Team should ensure that
the code:
Follows the Coding Standards and Guidelines
Follows...
Test Phase
The Test Team should ensure that the
system:
Never enters an unstable or unknown state
Is free from input valid...
Deployment Phase
The Release Manager and Application
Administrator should ensure that:
The source code and binaries are fu...
Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclus...
Common Vulnerabilities
* Often Cited As Two Major Areas:
Design
Implementation
* But A Third Major Area Exists:
• Architec...
Design Flaws
Design flaws often require significant
redesign and redevelopment to resolve
Example Design Flaws
Weak encryp...
Design Flaws (cont.)
Example Design Flaws (cont.)
Overexposed resources
May require a complete redesign of the entire syst...
Design Flaws (cont.)
Example Design Flaws (cont.)
Poor adherence to secure design principles
May require a complete redesi...
Design Flaws (cont.)
Example Design Flaws (cont.)
Choosing the wrong language
May make implementation difficult, extremely...
Flaw Case Studies 1
Design Flaws
Weak Encryption
Weak Access Control
Overexposing Resources
Incomplete Input Validation
Fa...
Implementation Flaws
Implementation flaws may be hard to track
down in large projects and may require
substantial modifica...
Implementation Flaws (cont.)
Example Implementation Flaws (cont.)
Poor adherence to the client-server principles
May produ...
Flaw Case Studies 2
Implementation Flaws
Race Conditions
Weak Change Management
Failure To Follow Client-Server Model
Prog...
Architecture Flaws
Architecture flaws normally don’t become
obvious until either during testing or once the
system has bee...
Flaw Case Studies 3
Architecture Flaws
Poor Understanding Of The Requirements
Poorly Architected Hardware
Requirements Flaws
Requirements flaws, like architecture flaws
occur in the beginning of the cycle, so impact
the most pha...
Requirements Flaws (cont.)
Example Requirements Flaws (cont.)
Neglecting to spell out testing
activities/requirements
The ...
Flaw Case Studies 4
Requirements Flaws
Neglecting To Spell Out Client Requirements
Neglecting To Spell Out Functional Requ...
Deployment Flaws
Deployment flaws may be the result of poor
requirements or architecture, they may also
be because of desi...
Deployment Flaws (cont.)
Example Deployment Flaws (cont.)
Insecure defaults
Requiring a slew of changes to make a system m...
Flaw Case Studies 5
Deployment Flaws
Poor Adherence To Secure Installation/Operation
Documentation
Insecure Defaults
Debug...
Testing Flaws
Testing flaws allow immature code to be put
into production environments, putting the
production environment...
Testing Flaws (cont.)
Example Testing Flaws (cont.)
Failure to test for security vulnerabilities
Allows security vulnerabi...
Flaw Case Studies 6
Testing Flaws
Failure To Follow/Test Requirements
Inadequate Code Coverage
Poor Vulnerability Testing
...
Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclus...
Holistic Approach to Security
Security must be considered at:
All stages of a project
Requirements
Architecture and Design...
Threat Modeling
Threat modeling is:
A critical part of the requirements and design
phase
Requires the system be examined f...
Ongoing Education
Provide training that teaches
How security features work
How to use the security features to build secur...
Input Validation
Buffer overruns
Buffer underruns
SQL injection
Cross-site scripting
Typing
Command injection
ASP.NET Cross-Site Scripting
<%@ Page Language="C#"
ValidateRequest="false" %>
<html>
<script runat="server">
void btnSubm...
ASP.NET Cross-Site Scripting (cont.)
// CONTINUED FROM PREVIOUS SLIDE
<body>
<form id="form1" runat="server">
<asp:TextBox...
ASP.NET Cross-Site Scripting 2
<%@ Page Language="C#”
AutoEventWireup="true"%>
<html>
<form id="form1" runat="server">
<di...
ASP.NET Cross-Site Scripting 2
(cont.)
</form>
</html>
<script runat="server">
private void Page_Load(Object Src, EventArg...
Sample Cross-Site Scripting Strings
<script>alert(‘hi’);
<script<< alert(‘hi’) </script<<
%3Cscript%3Epref%3Dfunction(a%2C...
Sample Cross-Site Scripting Strings
(cont.)
<img src=””
onMouseOver=”alert(document.cookie)”; />
http://pizzahut.com%22;%0...
Demonstration 1
Cross-Site Scripting
Bypassing Security Checks
C# Overflow On The Heap
static void Main(string[] args){
char[] smallStr=new char[20];
char[] largeStr=new char[250];
for(...
C# Overflow Using Pointer Math
static void Main(string[] args){
Overflow();
Console.WriteLine(“done”);
}
unsafe static voi...
Demonstration 2
Buffer Overflows
Bypassing Security Checks
Java SQL Injection
static void main(String[] args){
Connection conn=null;
String username=args[0];
String password=args[1]...
PHP SQL Injection
$id=$_GET[‘id’];
if(intval($id)>0){
$dbhandle=new
mysqli(“host”,”username”,”password”,”maindb”);
$query=...
PHP SQL Injection 2
$id=intval($_GET[‘id’]);
if($id>0){
$dbhandle=new
mysqli(“host”,”username”,”password”,”maindb”);
$quer...
PHP SQL Injection 3
$name=$_GET[‘name’]; $id=intval($_GET[‘id’]);
$dbhandle=new
mysqli(“host”,”username”,”password”,”maind...
Demonstration 3
SQL Injection
Bypassing Security Checks
Whitelisting And RegEx
Whitelisting is:
Specifying only the data that you allow
Normally uses regular expressions to impro...
Whitelisting And RegEx (cont)
Sample Expressions (cont):
Passwords
/(?=^.{16,255}$)(?=.*d)(?=.*[a-z])(?=.*[A-
Z])(?=.*[!@#...
Overview of Security Technologies
Developers need to use and apply:
Secure communication (to include IPC)
Encryption/Hashi...
Encryption
Encryption is the process of encoding data
To protect a user’s identity or data from being
read
To protect data...
Case Study 7
Incorrect Use of SSL
Using weak ciphers
Using unknown CAs (like NASA does)
Only securing the login
Only secur...
Case Study 8
Common Cryptography
Mistakes
Using encoding
Using a “home-grown” algorithm
Relying on broken algorithms
Authentication
Authentication Methods
Basic
Digest
Digital signatures and digital certificates
Integrated
Single Sign-On/F...
Case Study 9
Common Authentication
Mistakes
Authenticating once (not every page)
Session hijacking/Session fixation
Error ...
Demonstration 4
Common Authentication
Mistakes
Session Theft
Cookie Theft
Auditing and Logging
Auditing and logging actions include tracking:
Successful and unsuccessful logon attempts
Resource ac...
Case Study 10
Common Auditing Mistakes
Not protecting audit data
Inadequate auditing (and not customizable)
Writing input ...
Agenda
Course Introduction
Secure Software Development Lifecycle
Common Vulnerabilities And Mistakes
Into The Deep
Conclus...
Free Code Auditing Tools
C/C++
Lint
Rats
Flawfinder
Yasca
Splint
ASP.NET
CAT.NET
FxCop
SSW Code Auditor (free version)
Free Code Auditing Tools (cont.)
Java
PMD
Yasca
LAPSE
PHP
Pixy (for PHP4… PHP5 code must be converted
to PHP4 code)
PHP_Co...
Free Code Auditing Tools (cont.)
Perl
Rats
Perl::Critic
Python
Rats
Similar Tools
Valgrind
GDB
010 Editor
Bunny the Fuzzer
Security Compass
XSS-Me
A free Firefox plug-in
Performs semi-automated XSS attacks against
POST fields
SQL Inject-Me
A fre...
Other Firefox Add-ons
Web Developer Add-on
Free
Let’s you view source files cleanly and easily
Let’s you quickly enable an...
Fuzzers
BED.pl
Free Perl script
Performs basic tests of your SERVER
JBroFuzz
Free Java application
Let’s you fuzz any part...
Other Tools
Sothink SWF Decompiler
Decompiles any Adobe Flash or Flux script
Cavaj
Free
Decompiles any Java program
Nikto
...
For More Information
Microsoft Security Site (all audiences)
http://www.microsoft.com/security
MSDN Security Site (develop...
For More Information (cont.)
Common Weakness Enumeration
(CWE)/SANS Top 25 Most Dangerous
Programming Errors (developers)
...
Acknowledgements
I stole the background and come clipart from
Microsoft
I stole a lot from my experiences and
previous wri...
Upcoming SlideShare
Loading in …5
×

Application and Website Security -- Developer Edition: Introducing Security Into Development

2,846 views

Published on

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.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,846
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
34
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • There are currently numerous software development models--for example iterative development, incremental development, agile, waterfall, spiral, and extreme programming (XP).More recently, however, several papers have used a general lifecycle that can be implemented by almost any project for almost any reason. (Owens, Lauderdale, et al. 2008)The lifecycle involves six phases, none of which can be skipped, but which can be restarted any number of times.The lifecycle, shown above, starts at the requirements phase (where requirements are gathered)Moves to the architecture phase (where the architecture is developed – constraints are specified)The design phase (where the actual design is created)The implementation phase (where the programming is performed)The test phase (where the application is heavily tested)The deployment phase (where the application is deployed).If a bug is discovered after the application is deployed, we repeat the above process, which bares resemblance to all of the aforementioned models.
  • The Requirements Phase is largely up to the Application Program Managers to accomplishThey must determine and document:The purpose of the system (why is it here?)What the system is to be able to doWhat the system should be processing and/or storing or providing to othersWhat security requirements the system is to adhere to… For example, it may be proper for the system to adhere to DISA (a branch of the DoD that makes IT security requirements) or NSA standards and requirements… any of those that are applicable should be clearly statedAny legal requirements that the system must adhere to… e.g. HIPAA and any constract
  • While the client APM should perform what’s on the slide above in coordination with the developer APM, the client APM has a duty to especially focus on the following to ensure a successful program:Developer training requirements… annual training that includes secure programming? Any degrees, certifications, or certificates that are required… for example, every member of the development team should have a BS in Computer Science, the team lead should also have a Master’s in Computer Science, etcTesting and secure coding requirements – The client APM should ensure that the developer is required to test the system for security flaws and that the developer users secure coding practices, such as creating secure coding standards and guidelines that include unsafe function listsThe client APM should push down any requirements that are incumbent upon the client so that the client maintains compliance… For example, all software used by the government (excluding the DoD, which has its own body, DISA) must adhere to NIST 800-53 and websites should be 508A compliantAnd of course the client APM should convey any additional requirements, such as whether or not the software must have a GUI, the languages that are (or aren’t) acceptable, etc
  • The Architecture Phase is largely in the hands of the Application Program Managers on both the client and developer side.In short, the phase is designed to layout any constraints on the system that will impact how the system is to be designed.This is in contrast to the requirements phase where it was being specified what the system MUST be able to do… here we are specifying what it cannot DO (e.g. consume 20 GB of memory, require a distributed network, etc)
  • It is important that the designers document (in a complete, descriptive manner):Whether or not it will be an application or a scriptWhether or not a database will be involvedThe requirements and constraints, as well as the above should then allow the design team determine the language to be usedThen using that, the team needs to create the Coding Standards and Guidelines – which MUST be strictly enforcedAfter which any external modules/libraries that the tool will use (or may use) should be determinedThen the team must document how data is to be secured – any algorithm and module to be used, how data will be sanitized, etcAfter which the team can start with the standard design phase… creating the UML diagrams, etcOf course, all design documentation (to include UML diagrams) should be carefully examined for design flaws PRIOR to any implementation efforts
  • The Development team (those actually writing the code) should:Ensure that the code follows the Coding Standards and Guidelines created during the design phase. This includes any unsafe functions lists. Some of the best methods for ensuring this includes plugins to development environments that allow syntax to be verified as well as simple tools such as grep to search for unsafe or disallow functionsEnsure that the code follows the design documentation – in order to be truly effective, the code must follow the design documentation, since that is the documentation that the team is using to create each individual pieceEnsure that the code prevents the system from violating the Byzantine Generals Problem – a series of problems used by Lamport, Shostak, and Pease in 1982 whereby the goal is to ensure that data and message integrity is preserved. This applies to a slew of different topics, but can be summed up as the system ensuring that anything it produces is accurate by having checks and balances, but is also inclusive a very serious and yet frequent flaw to be discussed in the last bulletEnsure that the code is well-written through code reviews, methodically written through strict standards and guidelines, and adheres to all requirements, protocols, standards and best practices through all of the above and strict adherence to the design and architecture information – it is important that developers be well versed in secure coding practices and adhere to them, particularly relating to input validation and code management (e.g. dead code removal)Ensure that the code is SAFE and SECURE… more specifically, that the source code repository is safe and secure. If a malicious entity were able to modify the source code (or binaries) without anyone knowing, the system itself could be trivially defeated and cannot pass the Byzantine Generals Problem
  • The test team should:Ensure that the system always remains in a known, stable state (all errors should be properly handled and the system should never black hole)Ensure that the system is free from input validation flaws, logic flaws (and design flaws), processing and storage flaws, etcEnsure that the system provides the appropriate levels of assurance for confidentiality, integrity, and availability… this should be handed by the above, but it’s important that testers are reminded to check that the system acts as required given the data that the system handles and its missionEnsure that the system maintains adequate code coverage statistics… this should really be 100% or the system has either not been fully tested or has dead code that needs to be removed. It should also be noted that the system should have 100% code coverage PRIOR to deploymentEnsure that the system adheres to the requirements set forth in the Requirements Phase, Architecture Phase, Design Phase, and Implementation Phase
  • The Release Manager (the member of the developer team who manages the releases) should:Ensure that the source code repository and source code is protectedEnsure that the binaries and all distributed files are protected to the extent possible by the developerEnsure that proper guidance for securely installing and operating the system is provided to clientsEnsure that all appropriate documentation is properly maintained, protected, and provided to clientsThe Application Administrator should:Ensure that any source code under his/her control is properly securedEnsure that the software is installed in accordance with all provided guidance, paying particular attention to the secure installation guidanceEnsure that the software is operating in accordance with all provided guidance, paying particular attention to the secure operation guidanceEnsure that the documentation under his/her control is properly maintained and secured
  • Some researchers have suggested that design flaws alone account for about half of the vulnerabilities in software written todaySimilarly, researchers have suggested that the cost to repair many of these flaws (both direct and indirect costs) outweigh the costs on a flaw-by-flaw basis of most other flaws, largely because a design flaw impacts most of the other phases – it requires a redesign, more coding, then testing, and then redeployment of the systemWhile there are numerous potential design flaws, we’ll look at some of the major or more common onesA design that relies on weak encryption or (worse still) encoding to protect data is one that is grossly negligent… Such a mistake requires the redesign of the system to accommodate a new algorithm – which has the potential of requiring a new look at the requirements and architecture phases, not to mention the potential for large code changesFor example, if a website was using a simple XOR-based encryption scheme (or even worse, base64 encoding) to protect passwords, the website may have to restructure the database, particularly if the passwords were encrypted using the schemeIf the system used a database to store passwords, but they were not encrypted in the database, encrypting them will mean that the developers will have to redesign the authentication mechanisms – especially if the system simply did a compareA good example of where this hurt many people deals with wireless networking… WEP relies on RC4 or ARC4, which is a broken algorithm, but needs very little processing power. When KoreK put the final nail in WEP’s coffin, some vendors tried to apply patches to their devices to allow for WPA (also broken), which resulted in devices that didn’t work. Worse still, even after people proved that WEP could be broken in less than 30 seconds, manufacturers were still pushing out devices that could only handle WEP… the result? The industry crippled itself by created WPA TKIP – which solved little and continued to use the broken RC4/ARC4 algorithm. Many people now are stuck with wireless networks that are little better than an insecure radio tower.As another consideration, if the tool interfaces with a client (or server) changing the algorithm may be impossible unless the developer of produces both the client and the server.Weak access control will often require the developer to redesign the authentication mechanisms and most of the modules in the system – at least on the front and back ends – to accommodate a new, better access control mechanism.For example, if the system AAs a user who hits a specific section of the tool, but never performs AA beyond that, the rest of the frontend and backend will have to later be redesigned and recoded to actually AA the user.For example… a website is designed to AA a user who hits index.asp. The user enters a username and password and a cookie is put on the user’s system. The user now has access and is presented to main.asp. An attacker (authenticated or otherwise) who can go to main.asp without having proper privileges means that the system must now be redesigned to AA on main.asp.
  • Overexposing resources can be a multitude of things… it may be a lack of protecting memory, having a SQL server directly accessible to anyone, verbose error messages (or debugging), or numerous other thingsDepending on what’s exposed and the amount of exposure, it can be difficult to fixFor example, if memory is not properly protected and is exposed, the solution is not normally a step or two process… in C, C++, Java, C#, or similar languages you will have to not only adjust the scope, but may have to also encrypt memory, which means that not only will you likely break things when you move the scope, but you also not have to put in extra steps to encrypt and decrypt the memory prior to its useIn the case of verbose output to users, this can be something like having debugging enabled or producing messages that provide too much information. Common examples include webserver software and database software, as well as authentication mechanisms. For example, many SQL servers (whether or not debugging is enabled) will provide bits and pieces of the SQL query that is failing or clues as to what is failing and how to solve it. These messages can be trivially used by an attacker with even fledgling skills to further penetrate the system. The common mistakes regarding authentication mechanisms tend to center around also providing too much information. For example, if the mechanisms tell the user that the username is correct but the password is not (by having a different message for the two events), and attacker can determine valid user credentials much faster. Furthermore, if the mechanisms also let the attacker know how long (or short) the passwords can be, the attacker can hone the attack such that it is most effective.Incomplete input validation mechanisms or algorithms is both explicit and ambiguous. These mechanisms and algorithms serve as the gatekeepers and either allow data to permeate or kill the data prior to it actually becoming part of the system. When they are incomplete or inadequate (or even when they are too stringent or too much) they can harm the system.The design will need to be modified and depending on the system, code may need modified in several different placesThese are actually fairly common. It’s one thing to forget to implement a check in an if statement, it’s another thing entirely to not even design for that check to exist. Often, when checks are not well thought-out during the design phase, there have to be major changes in multiple code locations (not to mention the overall design) to accommodate the new design. For example, if an application accepts strings and outputs them to the user, but doesn’t check the bounds, type, and range, this normally means that the application’s boundaries weren’t well defined in the design phase, which means that the boundaries will need to be redefined. It also normally means that a new check will be created, a new error possible, so you have to determine how to present the error to users (if at all) to continue to provide the same level of service.Incomplete threat modeling is related to the final bullet. Threat models serve an important role in protecting the system from attack – both malicious and unintentional. When threat models aren’t created or carefully thought-out the entire system is at risk.In most cases this will require a redesign of the system and significant changes in the code.Depending on the severity of the gap, it may be best to just start over and try again.For example, Windows 9X (Windows 95, 98, and ME) were all created under a very ideal threat model where the world was generally good and the any system running on these versions of Windows were assumed to be home computers that required little security. This resulted in a multitude of weaknesses when place (inappropriately) in a public, corporate, or government environment. Users weren’t really required to log into the systems – even when networked and on a Windows domain (you simply hit ‘Cancel’ on the login screen and you were logged in) – so there was no real accountability. Additionally, the threat of malware had gone unnoticed so all users were given the same permissions and privileges, excluding a couple of exceptions, and a malware infect on these systems rendered them completely unusable. In fact, some malware used this to their advantage to damage physical hardware, wipe the CMOS, etc.Math flaws, bad assumptions, poor planning, etc, are common. These flaws commonly crop up during the design phase and illustrate poor requirements and architecture, as well as poor communication.Depending on the flaw, the system may require massive rewrites and a complete redesign.Take again Windows 9X. Microsoft assumed the user base, threats, and needs incorrectly – or perhaps did not communicate them well enough to the users. The result was the eventual death of the Window 9X line and the move to a strict Windows NT-based operating system. Even there Microsoft had to rewrite and redesign – hence Windows 5X (Windows 2000, XP, and 2003) and then Windows 6X (Windows Vista and Windows 2007) and now Windows 7X (Windows 7). Similarly, Macintosh made numerous bad assumptions about the users base and threats that resulted in huge changes between Macintosh OS 9 and Macintosh OS X to include a terminal that users actually had to use (a more Microsoft approach) with even more drastic changes being made in Macintosh OS 10.3, then 10.4, and 10.5 (all “subversions” of OS X).Math flaws in design can be crippling, but are normally only so when the flaws exist in something like an authentication algorithm or mechanism. For example, WEP uses the broken RC4 (ARC4) and had several math flaws and assumptions that are trivial to exploit, allowing someone to passively defeat WEP within seconds and discover the secret key.
  • Poor adherence to secure design principles – this may seem broad, but it can be narrowed down based on experiencesDepending on how poorly the design team adhered to the secure design principles, there may be significant redesign and a large portion of the code may need to be either rewritten or just scrappedFor example, the implementation team relies on the design team to ensure that good coding standards and guidelines have been produced. If the standards and guidelines are weak, demonstrate bad coding practices claiming them as good, or neglect things such as an unsafe function list, the system may be so rot with with errors that it may not be salvageable and requires a complete rewritePoor adherence to multi-threading or multi-processing design principles can mean several different things but the result is normally the existence or potential for a race conditionRace conditions are notoriously difficult to find and even once they are tracked down they can be extremely difficult to eliminate without removing the parallel processing. Some race conditions have been fatal – some of the most published including Therac 25Poor adherence to requirements and architecture documentation can cripple a project to the point of no returnIf the requirements and architecture are either completely ignored or poorly monitored, the design could be so incomplete, inadequate, or improper that the project must either undergo a massive overhaul or be dropped
  • To wrap up the examples of design flaws, one of the worst and most costly mistakes is for the design team to choose the wrong language(s) for a projectDepending on how bad the choice, it may be impossible to actually produce the code or follow the designThe choice may result in overly buggy code – every language has a point, purpose, and specialty – and code that is unmanageableThis is the fastest way to kill a project… no one language can or should be used to solve ALL of the world’s problems
  • While design flaws are alleged to account for nearly half of all vulnerabilities discovered according to some researchers, implementation flaws tend to be the second most common source of vulnerabilities and bugs.Like design flaws, implementation flaws can become extremely expensive, depending on the flaw. For example, if the developer did not follow the design specifications, or such specifications are not clear, the entire code or large sections may need overhauledWhile there are numerous potential implementation flaws, we’ll look at some of the major or more common onesImplementing a parallel processing environment through multithreading or multiprocessing can be difficult; even with a well thought-out, carefully create design, a programmer who is not skilled at this kind of development can both follow the design and create potential race conditions. The result is code that may be just as expensive as the corresponding design flaw to discover and correctAs with race conditions that are created due to design flaws, race conditions that are created because of the implementation of the design can be extremely hard to track down and fixPoor adherence to change management principles can devastate a project and create a very heavy cost to fix the various problems that can resultThe lack of strong change management means that anyone (developers or otherwise) can insert arbitrary code or otherwise impact the machine or binary codeWithout strong change management, a system cannot be guaranteed to be free of backdoors, logic bombs, time bombs, or various other malicious codeWithout strong change management, a system cannot be said to pass the Byzantine Generals Problem and MUST be assumed to be malicious or inaccurateFor more about change management and its importance, please see the corresponding whitepaper “IT Security Threats: Improper or Inadequate Change Management” at https://itsecurity.grc.nasa.gov/program.office/helpful.it.sec.docs/whitepapers/change.management.pdf
  • Poor adherence to the client-server principles (the server should accept everything and provide strictly formatted output to anything, while the client should accept little and provide strictly formatted output) can result in code that is not interoperableFor example, if a server’s input parameters are more restrictive than the client’s output parameters, the server will constantly provide error messages as output, making the interaction between the two unbearable and frustrating any usersIf the server’s output parameters are not within the standards and protocols set forth for communication, the client should be throwing errors – this will make communications between the two impossible, but will protect the clientThe server should accept ALL input, but that doesn’t mean that it has to use it… it can throw errors for anything out of bounds or, as appropriate, bring it into bounds (HTTP servers do this all of the time, as do many other servers… of course, authentication mechanisms should be strict, etc)… this principle should be completely understood before a developer should be allowed to begin creating the interfacesPoor adherence to the requirements, architecture, and design phase documentation can result in various implementation flaws that can doom a projectFor example, if a system were to require more memories or fail to take advantage of what is available, the system could become an annoyance, not a tool, and ultimately doom itselfIf a system is implemented in code without following the design documentation (or if the design, etc, phase is passed over or poorly worked), the code is likely to become tightly coupled, hard to maintain or adjust, full of “hacks” that are fragile and break when tweaks are made not only to that code, but also surrounding code, etc.Programming errors, misunderstandings between programmers and designers (or others), math errors, etc, are often relatively easy to correct, but they can and tend to be numerousOff-by-ones are common examples of mistakes made by developers – often because of misunderstandings between either two developers or the developers and designers – that are easy to fixForgetting conditions or messing up a condition is another common error that can spell disaster when it comes down to a tool maintaining its availability, confidentiality, and integrity; for example, fragmentation in various Internet Protocol protocols has resulted in numerous major vulnerabilities to include the major tear drop vulnerability and the reassembly vulnerabilities
  • Architecture flaws, while not as common as the design and implementation flaws, can be extremely costly or impossible to fix – assuming that something CAN be done, it is likely difficult to perform and push out once the system has been deployedWhile there are numerous potential architecture flaws, we’ll look at some of the major or more common onesPoor understanding of the requirements if not caught until after deployment can make the system unusable and unable to perform the tasks required by the client or in a manner commiserate with the intended missionOften, the system cannot be modified because it has been deployed and the modifications would require a redesign, redevelopment, and retestingPoorly architecting the hardware as compared to the requirements and the software can make the system unusable and unable to perform the tasks required or desired by the clientFor example, many wireless networking devices were poorly architected to have the minimum hardware required to operate with the Wireless Encryption Protocol (WEP)… once WEP was broken, some manufacturers attempted to update the software on the slow hardware which resulted in software that allowed an unusable form of the now defeated WPA standard – giving rise to the also broken WPA using TKIP instead of AES and thereby forcing the IEEE to wound WPA before it was ever even a standard
  • Some researchers have suggested that design flaws alone account for about half of the vulnerabilities in software written todaySimilarly, researchers have suggested that the cost to repair many of these flaws (both direct and indirect costs) outweigh the costs on a flaw-by-flaw basis of most other flaws, largely because a design flaw impacts most of the other phases – it requires a redesign, more coding, then testing, and then redeployment of the systemWhile there are numerous potential design flaws, we’ll look at some of the major or more common onesA design that relies on weak encryption or (worse still) encoding to protect data is one that is grossly negligent… Such a mistake requires the redesign of the system to accommodate a new algorithm – which has the potential of requiring a new look at the requirements and architecture phases, not to mention the potential for large code changesFor example, if a website was using a simple XOR-based encryption scheme (or even worse, base64 encoding) to protect passwords, the website may have to restructure the database, particularly if the passwords were encrypted using the schemeIf the system used a database to store passwords, but they were not encrypted in the database, encrypting them will mean that the developers will have to redesign the authentication mechanisms – especially if the system simply did a compareA good example of where this hurt many people deals with wireless networking… WEP relies on RC4 or ARC4, which is a broken algorithm, but needs very little processing power. When KoreK put the final nail in WEP’s coffin, some vendors tried to apply patches to their devices to allow for WPA (also broken), which resulted in devices that didn’t work. Worse still, even after people proved that WEP could be broken in less than 30 seconds, manufacturers were still pushing out devices that could only handle WEP… the result? The industry crippled itself by created WPA TKIP – which solved little and continued to use the broken RC4/ARC4 algorithm. Many people now are stuck with wireless networks that are little better than an insecure radio tower.As another consideration, if the tool interfaces with a client (or server) changing the algorithm may be impossible unless the developer of produces both the client and the server.Weak access control will often require the developer to redesign the authentication mechanisms and most of the modules in the system – at least on the front and back ends – to accommodate a new, better access control mechanism.For example, if the system AAs a user who hits a specific section of the tool, but never performs AA beyond that, the rest of the frontend and backend will have to later be redesigned and recoded to actually AA the user.For example… a website is designed to AA a user who hits index.asp. The user enters a username and password and a cookie is put on the user’s system. The user now has access and is presented to main.asp. An attacker (authenticated or otherwise) who can go to main.asp without having proper privileges means that the system must now be redesigned to AA on main.asp.
  • Neglecting to spell out testing activities and requirements may mean that the software may not be completely or properly tested, particularly against the client’s needsIt is important that test methods, activities, guidelines, and specifications be given that are as complete and succinct as possible, if this is not done, testing may not be adequate and things may be missed or the testing phase may need to be performed againNeglecting to spell out security requirements indicates that security is not a focus (and likely not even on the radar of either the developer or the client) – this can be very dangerousIf security is not integrated into the very fabric of the SDLC, the software is likely to have many vulnerabilities that it would not otherwise have had, which can result in huge losses, costly redevelopment, or the death of an otherwise good toolNeglecting to spell out the protocols and relationships between interprocessing units means that such things are likely to be missed of incompletely addressed in the later phases of the SDLCIf a software cannot operate in a heterogeneous environment, cooperate (especially with itself) with software or processes properly, or causes other processes or systems to enter unstable states (or itself enters them because of other processes), the system may quickly become unusable or require costly fixes
  • Deployment flaws are commonly the result of either unclear or insecure installation/operating instructions created by the developer, inflexible instructions created by the developer, the developer too easily providing methods to operate less securely, or the developer not even providing secure operations instructions (or making the instructions hard to find)While there are numerous potential deployment flaws, we’ll look at some of the major or more common onesPoor adherence to secure installation and operation guidance can make a system more vulnerable to attack and be responsible for successful compromise of the system – of course, not even having such documentation is perhaps worse than not following it (depending on the perspective)
  • Insecure defaults means that the system is not secure by default or on a default installationIf no documentation exists as to how to secure the system, it won’t be securedIf such documentation exists but is poorly written or not distributed, it won’t be securedIf the documentation to secure the system includes too many different things, it’s likely that things will be missed (both in the document and in implementing according to the document) and that things will simply not happenThis needlessly increases the surface of attack and violates best practicesEnabling debugging (particularly by default) or compiling a system with debugging flags enabled may allow an attacker to have access to a slew of information that the attacker would not have otherwise had access toA common mistake on servers is to enable debugging in an operational environment – the attacker is now given programmer-level information about the system, particularly if they manage to cause an error in the system – and allows an attacker to gain enough data in most cases as to allow a trivial compromise of the systemA mistake for some developers is to compile production code with debugging flags; if an attacker were to decompile the software, they would have more information and be better able to formulate an attackPoor change management can result in missing patches, botched updates, and a seriously messed up configurationThis does include release mangement (how updates, patches, hotfixes, and new major versions are released) and how packages are assured to be both untampered with and safeIt also includes the release of documentation and maintaining control over the binaries, source code, and any supporting documentation (both by the developer and the client)
  • An often overlooked phase in which flaws slip into (or through) the SDLC’s grasp is the testing phase. Flaws that occur or are missed here are the ones that you must find and discover later in an environment not under your control – the result is increased complexity to find the reported bug, sift through false reports, and spend a large amount more money than would otherwise have been spent finding and fixing bugs.While there are numerous potential testing flaws, we’ll look at some of the major or more common onesFailure to follow the requirements and test for adherence to the requirements means that the tests may not be valid – without testing to the requirements, the tests may be incomplete or may have misunderstandings and misinterpretations – this is why IV&amp;V is importantWithout testing the software for compliance, the software may not meet the required capabilities and functionality (the same is true with testing the architecture); this mistake may not be made until the system is in production, which may be too lateIf requirements are not met (and a contract is involved) a lawsuit may occurFailure to have complete code coverage can actually be damagingIt may result in someone noting due diligence and due care was lacking in the development process (potential law suit)It may result in dead code not being examined – if dead code contains vulnerabilities and an attacker can hit the code, the system may be compromisedIt may miss simple bugs that could have been fixed quickly and easily; the result would be a much more difficult process leaving customers scratching their heads wondering why the bug wasn’t found earlier (thereby damaging the reputation)Let’s not forget, some people count the number of patches… too many (e.g. Apple releasing more than 100 by April of this year for Macintosh) and people will start complaining or at least take note because it indicates an immature product and immature development
  • Failure to test for security vulnerabilities could result in a very insecure product and the potential for lawsuitsIt may also result in a slew of patches and fixes that embarrass the company and developersFailure to perform tests in a realistic environment means a failure to test the architecture and fully test the requirementsFor example, it is likely that the system has performance requirements; if the tests are performed against a better machine than the minimum that will be rolled out (or that the system can be installed on), the metrics for performance would be invalidAdditionally, the tests are only valid under the environment in which the tests were performed… if something is tested only under single user mode, the results of the test can not be used to state how secure the system is in multi-user modeFailure to properly report problems – to include a failure to notice or report a problem, failure to completely write up or identify the problem, and failure to provide a final report – can result in problems never being fixed or noticed by others in the development teamThis can cause others to question any and all findings, as well as the validity of the testing and the people performing the test’s credentials/capabilitiesFailure to perform regression testing and verify fixes can make developers think that problems are solved or no longer exist when such is not the caseThis can result in an immature product
  • The code here is vulnerable to XSS
  • The code here (similar to the above) has a single, important step to help hamper XSS
  • HtmlEncode here helps prevent XSS… without it, the site is now vulnerable to XSS
  • The above are various strings that may be used in a XSS attackThe first simply pops up a dialog box that says “hi” to the userThe second is another of script that works well against some browsersThe third exploits a vulnerability that exists in all current known versions of Firefox (note the use of encoding to bypass many filters and HTTP firewalls)The four creates an iframe on the page that, when moused out of, breaks out of the frame and redirects the victim to “machine.aspx”
  • The above are various strings that may be used in a XSS attackThe first contains a non-existent image that when moused over will pop up a dialog box containing all of the website’s cookie informationThe second contains a very potent XSS attack that can be used in the (X)HTML’s head to modify the website’s button operation to open a new window to http://pizzahut.comNote that the attacker in all of these is using different techniques, preventing a blacklist approach to XSS prevention from working… as well as thwarting attempts to simply perform string replace operations based on specific characters (using a different encoding scheme would also do this… like UTF-8 or UNICODE when ASCII was expected, etc)
  • The code here illustrates a simple means for an overflow to occur in C#
  • The above code shows a trivially exploitable overflow using pointer math
  • The above code illustrates a SQL injection vulnerability
  • The above code illustrates a SQL injection vulnerability even though the input is ‘validated’There is a quirk in the way that PHP’sintval works… a string such as 5’ and ‘1’=‘2 would evaluate to 5…Since intval returned 5 the check passed, but $id contains an actual attack because it was never overwritten…There are four possible fixes to this particular problem; one that is specific to this code, one that doesn’t make full use of SQL but may be ideal for authentication, and two others that will hamper most any SQL injection attack when properly implementedYou can make use of things like setting id equal to intval($id), but that only works for integersYou can actually get rid of the WHERE clause and then compare the SQL results trying to find a match between the input and the results… this is only effective for SELECT and doesn’t make full use of SQL’s efficienciesYou can use a whitelist, regular expressions that do substitutions, AND string escapes (the latter is useful particularly if the whitelist has to include single quotes and the substitutions don’t do what you think they do)You can use prepared statements and string escapes (of course, the best thing is to use this plus all of the above, which allows you to thwart SQL injection regardless of the language)
  • This fix can actually be used to solve SQL injection against ANY integer value in PHP, but it only works when you expect an integer
  • This fix can actually be used to solve SQL injection against ANY input data type however should also make use of whitelisting to catch invalid data prior to the data hitting the SQL server
  • Application and Website Security -- Developer Edition: Introducing Security Into Development

    1. 1. Application and Website Security – Developer Edition: Introducing Security Into Development Daniel Owens IT Security Professional
    2. 2. Agenda Course Introduction Secure Software Development Lifecycle Common Vulnerabilities And Mistakes Into The Deep Conclusion And Appendices
    3. 3. Session Prerequisites Development experience is a plus Knowledge of basic SQL is a plus
    4. 4. Communication Media and Security Concerns Communication media: ‘Wired’ networks ‘Wireless’ networks Security concerns: The Insider The Outsider The Technology Nature
    5. 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. 6. Examples of Security Intrusions Apache Software Foundation Red Hat LMIT/NGC Tricare VA NASA Attacker Virus
    7. 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. 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. 9. Agenda Course Introduction Secure Software Development Lifecycle Common Vulnerabilities And Mistakes Into The Deep Conclusion And Appendices
    10. 10. Secure Software Development Lifecycle Requirements Phase Architecture Phase Design Phase Implementation Phase Test Phase Deployment Phase
    11. 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. 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. 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. 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. 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. 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. 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. 18. Agenda Course Introduction Secure Software Development Lifecycle Common Vulnerabilities And Mistakes Into The Deep Conclusion And Appendices
    19. 19. Common Vulnerabilities * Often Cited As Two Major Areas: Design Implementation * But A Third Major Area Exists: • Architecture * Other Areas: Requirements Deployment Testing
    20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 29. Flaw Case Studies 3 Architecture Flaws Poor Understanding Of The Requirements Poorly Architected Hardware
    30. 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. 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. 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. 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. 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. 35. Flaw Case Studies 5 Deployment Flaws Poor Adherence To Secure Installation/Operation Documentation Insecure Defaults Debugging Enabled Poor Change Management
    36. 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. 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. 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. 39. Agenda Course Introduction Secure Software Development Lifecycle Common Vulnerabilities And Mistakes Into The Deep Conclusion And Appendices
    40. 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. 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. 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. 43. Input Validation Buffer overruns Buffer underruns SQL injection Cross-site scripting Typing Command injection
    44. 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. 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. 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. 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. 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. 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. 50. Demonstration 1 Cross-Site Scripting Bypassing Security Checks
    51. 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. 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. 53. Demonstration 2 Buffer Overflows Bypassing Security Checks
    54. 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. 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. 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. 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. 58. Demonstration 3 SQL Injection Bypassing Security Checks
    59. 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. 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. 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. 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. 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. 64. Case Study 8 Common Cryptography Mistakes Using encoding Using a “home-grown” algorithm Relying on broken algorithms
    65. 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. 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. 67. Demonstration 4 Common Authentication Mistakes Session Theft Cookie Theft
    68. 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. 69. Case Study 10 Common Auditing Mistakes Not protecting audit data Inadequate auditing (and not customizable) Writing input directly to the audit logs
    70. 70. Agenda Course Introduction Secure Software Development Lifecycle Common Vulnerabilities And Mistakes Into The Deep Conclusion And Appendices
    71. 71. Free Code Auditing Tools C/C++ Lint Rats Flawfinder Yasca Splint ASP.NET CAT.NET FxCop SSW Code Auditor (free version)
    72. 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. 73. Free Code Auditing Tools (cont.) Perl Rats Perl::Critic Python Rats Similar Tools Valgrind GDB 010 Editor Bunny the Fuzzer
    74. 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. 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. 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. 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. 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. 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. 80. Acknowledgements I stole the background and come clipart from Microsoft I stole a lot from my experiences and previous writings

    ×