Software Security Assessment COEN 225. Code Auditing vs. Black Box Penetration Testing.

Software Security Assessment

COEN 225

Code Auditing vs. Black Box Penetration Testing


Security audits of software: White box testing

Auditors work with source code Manual code inspection Automated tools such as

RATS, ITS4, Splint, Flawfinder, Jlint, Codespy +: Complete code coverage is possible -: Complexity:

Tools are imperfect and need to be supported by manual review -: Occasional lack of availability of source code

Black box testing Auditors provide input to program / service under audit. +: Black box testing is always possible +: Portability

Can test several applications with the same test suite +: Simplicity -: Coverage -: Lack of intelligence


Black Box Testing Manual Testing

E.g.: Provide single quotes to various parameters in a form to find an sql or XSS attack possibility

Automated Testing or Fuzzing Pros:

Availability: Fuzzing is always possible Reproducibility: Fuzzing ports to similar applications to be tested Simplicity: Fuzzing replaces analysis with extensive trials

Contras: Coverage: Coverage usually implies code inspection Intelligence: Fuzzing is unlikely to find complicated attack patterns


Gray box testing Combines black box testing with some Reverse

Engineering (RE) RE is used to identify possible vulnerabilities Manual gray box testing

Use IDA PRO or similar disassembler tool to generate assembly code of binary

Identify possible vulnerabilities Generate sample input

Automated gray box testing Number of tools that automatize the process

BugScam Inspector Bin Audit

LogiScanSecurityReview


Gray box testingPro:

Availability: Can always be done Coverage: Better than black box testing

Contra: Complexity: Reverse Engineering is very difficult


Examplestruct keyval {

char * key;char * value;

}

int handle_query_string(char * query_string){

struct keyval *qstring_values, *ent;char buf[1024];if(!query_string)

return 0;qstring_values = split_keyvalue_pairs(query_string);

if(ent = find_entry(qstring_values, ″mode″))!= NULL){

sprintf(buf, ″MODE=%s″,ent->value);putenv(buf);

}…

}

Vulnerability:Programmer assumes that ent->value fits into buffer

ent->value is controlled by input

Web server behaves differently if the query string contains mode=xxx

Places string xxx into buffer buffer can overflow

Black box testing will have difficulties finding this possible vulnerability

Gray box testing needs to find the if statement Code inspection can find the faulty sprintf statement and

check for existence of an actual vulnerability


Example

Code Auditing and Development Life Cycle

System Development Life Cycle

Feasibility study Requirements definition Design Implementation Integration and Testing Operation and Maintenance

Trust Relationships

Trust relationships:Different components in a system place

varying degrees of trust in each other.Trust relationships need to be made explicit

and investigated. Transitive Nature of Trust

Trust Relationships:Misplaced Trust Misplaced Trust = Making an unfounded

assumption Input:

Most vulnerabilities are triggered by malicious input

Developer assumes that no-one enters a 5000 character telephone number

Developer assumes that related software module sanitizes input to module under development

Trust Relationships:Misplaced Trust Misplaced Trust = Making an unfounded assumption

Interfaces: Mechanisms by which software components communicate with

each other and the outside world. Developers

chose method of exposing interface that does not provide enough protection from external attackers.

chose reliable method of exposing interface, but configure it incorrectly assume that interface is too difficult for an attacker to access.

Example: Custom network interface with custom encryption. Attacker needs to reverse engineer a client


assumptionEnvironment

Software does not run in a vacuum Developer trusts environment, but attacker

manipulates it Classic example – teaser: /tmp – race

Application creates file in /tmp or /var/tmp Attacker creates symbolic link while app is running Application writes to the symbolic link instead

TEASERTeaser

Teaser


assumptionExceptions

Attacker causes unexpected change in application’s program flow by external measures

Example: App writes to a (attacker-controlled) pipe Attacker causes pipe to close just before write Results in a SIGPIPE exception (in *nix) App aborts, possibly leaving data incoherent

TEASERTeaser

Teaser

Design Review

Algorithms E.g.: Sorted list poses a DoS risk if attacker can

cause it to increase beyond reasonable bounds Problem Domain Logic – Business Logic

Banking Example: Person can make one monthly transaction with their money

market account to or from checking. Can make unlimited transfers to checking account. If checking account is below limit, money is transferred from

money market account to checking

Design Review

Trust RelationshipsTrust boundary

Reflects limitation of trust between modules

Trust Domains Regions of shared trust, limited by trust boundaries

Trust Model Abstraction that presents these relationships

Design Review: Trust Relationship

Win98 Trust Model Users are not protected

from each other If not networked, need to

get physical access to machine

Rest

of

World

Administrator

User 1

User 2

Ph

ysic

al A

cce

ss B

ou

nd

ary

Administrative Privilege Boundary

Design ReviewExamples for Design Flaws Exploiting Strong Coupling

Application is not decomposed along trust boundaries Example: Windows Shatter

Windows WM_TIMER Message Handling can enable privilege elevation (12/2002)

Interactive processes need to react to user events One mechanism is WM_TIMER, sent at expiration of timer Causes process to execute a timer callback function One process can cause another process to execute a timer callback

function (of its choosing), even if the second process did not set a timer.

Several processes run with LocalSystem privileges Attacker logs onto system interactively, executes program, that

levies a WM_TIMER request upon a LocalSystem privilege process, causing it to take any action the attacker specifies.

Fixed by MS 2003

Design ReviewExamples for Design Flaws Exploiting transitive trusts

Solaris Example: Solaris contains automountd

Runs as root Allows root to specify a command as part of a mounting operation Does not listen on an IP network Available only through three protected loopback transports

Solaris contains rpc.statd Runs as root Listens on TCP and UDP interfaces Monitors NFS servers to send out notification if they go down Clients tell rpc.statd which host to contact and what RPC program

number to call on host

Design ReviewExamples for Design Flaws Exploiting transitive trusts

Solaris Example continued: Attacker registers local automountd with rpc.statd Attacker tells rpc.statd that NFS server has crashed rpc.statd contacts automountd daemon through

loopback device automountd trusts message since it comes from root

through loopback device and carries out a command of the attacker’s choice.

Some work needed to make request a valid automountd request.

Design ReviewExamples for Design Flaws Failure Handling

User friendly: Recovers from problem Generates assistance in solving problems

Security conscious: Assumes that failure conditions are result of an

attack Close down app without explanation

Design ReviewExamples for Design Flaws Authentication

Lack of authentication Attacker can get access to a (presumably) private interface

between modules in an app Example: Web site does authentication in a main page, but

then does not check it when using links from main site. Untrustworthy credentials

Versions of sadmind were shipped without a default of “no authentication required” (1999)

Use of source IP address as a credential

Design ReviewExamples for Design Flaws

AuthorizationOmitting authorization checksAllowing users to set up authorization

themselves…

Design ReviewExamples for Design Flaws Accountability

Logging Failure Example: Log of Login

Attempts User name allows

newlines

200801091536 Logon Failure: Bob

200801091539 Logon Success: Alice

200801091547 Logout: Alice

AccountabilityLogging Failure

Example: Log of Login Attempts

User name allows newlines

username: Alice\n 200801091559 Logon Success: Alice

200801091536 Logon Failure: Bob


200801091559 Logon Failure: Alice


Design ReviewExamples for Design Flaws Confidentiality & Integrity

Obfuscation instead of encryption Insecure Use of Encryption

Example: XOR-encryption Storing Sensitive Data Unnecessarily

Example: Storing a password Instead store (1-way) salted hash of password

Without salt, can use rainbow tables to crack password Bait & Switch Attacks

Example: Using an insecure hash (MD5, SHA1) to validate Application signs hash of request If hash is insecure, can generate request with the same hash

Design ReviewThreat Modeling Michael Howard and David LeBlanc:

Writing Secure Code, Microsoft Press, 2002

Frank Swiderski and Window Snyder: Threat Modeling, Microsoft Press 2004

Design ReviewThreat Modeling Process during design phase, updated in

later development phases1. Information Collection

2. Application Architecture Modeling

3. Threat Identification

4. Documentation of Findings

5. Prioritizing of Implementation Review

Design ReviewThreat Modeling: Information Collection Goal: Get understanding of application

Assets: What has value for an attacker?

Entry points: Path through which an attacker can access the system.

External entities: Those that communicate with process through the entry

points External trust levels Major components Use scenarios

Design ReviewThreat Modeling: Information Collection Developer Interviews

Keep in Mind Developers have put lots of efforts into work. Avoid any judgmental or condescending overtones

Developer Documentation Often incomplete Often no longer representative of implementation

Standards Documentation Source Profiling (Not Source Inspection)

Design ReviewThreat Modeling: Information Collection System Profiling

Requires access to a functioning installation Approaches:

File system layout Code reuse Imports and Exports Sandboxing

Determine all objects touched and all activities performed Use sniffer and application proxies to record any network

activity Use tools such as FileMon, RegMon, WinObj, Process Explorer

Scanning

Design ReviewThreat Modeling: Application Architecture Modeling

Create Data Flow Diagrams

User

Web

ApplicationDatabase

http request

https request

http answer

https answer

database query

database response


DFD level-0 diagram of login process

User

Login

process

Database

login database query

database response

Authenticated Operations

login status

operational request

operational response

Authe

ntica

ted

user

bou

ndar

y

database response

database query


UserDatabase

Submit login request

Query password salt for user

Query for username with

salted password

Redirect to https

Login accepted

Login failed

Check for

HTTPS

Look-up user

Check password

Access denied

https connection accepted

Return saltSalt is valid

Return user recordInvalid password

Invalid salt value


UserDatabase

Submit login request

Query password salt for user

Query for username with

salted password

Redirect to https

Login accepted

Invalid user name

Check for

HTTPS

Look-up user

Check password

https connection accepted

Return salt

Salt is valid

Return user record

Invalid password

Design ReviewThreat Identification Process of determining an application’s

security exposure Uses attack trees

Design ReviewThreat Identification

1. Adversary gains access to a user’s personal information

1.1. Gain direct access to the

database

1.2. Login as target user

1.3. Hijack user session

1.4. Passively intercept personal

data

1.1.1. Exploit a hole in system

application or kernel

1.2.1. Brute force login

1.2.2. Steal user

credentials

1.3.1. Steal user session

cookie

1.4.1. Identify user

connection initiation

1.4.2. Sniff network traffic for personal

data

1.2.1.1. Identify user

name


password

Design ReviewThreat Identification Textual representation1. Adversary gains access to a user’s personal information

OR 1.1 Gain direct access to the database

1.1.1 Exploit a hole in system application or kernel

1.2 Log in as target user

OR 1.2.1 Brute-force login

AND 1.2.1.1 Identify user name

1.2.1.2 Identify user password

1.2.2 Steal user credentials

1.3 Hijack user session

1.3.1 Steal user session cookie

1.4 Passively intercept personal data

AND 1.4.1 Identify user connection initiation

1.4.2 Sniff network traffic for personal data

Design ReviewThreat Mitigation Adorn attack tree with threat mitigation

measures Dashed lines indicate improbable attack

vectors

Design ReviewThreat Mitigation

1. Adversary gains access to a user’s personal information

1.1. Gain direct access to the

database

1.2. Login as target user

1.3. Hijack user session

1.4. Passively intercept personal

data

1.1.1. Exploit a hole in system

application or kernel

1.2.1. Brute force login

1.2.2. Steal user

credentials

1.3.1. Steal user session

cookie

1.4.1. Identify user

connection initiation

1.4.2. Sniff network traffic for personal

data


name


passwordSystem patches

up to date

https required https

required

Design ReviewDocumentation of Findings Threat summary structure:

Threat: Bruce force login Affected component: Web application login Description: Clients can brute force attack usernames and

passwords by repeatedly connecting and attempting to log in. This thread is increased because the application returns different error messages for invalid usernames and passwords making usernames easier to guess.

Result: Untrusted clients can gain access to a user account and therefore read or modify sensitive information

Mitigation Strategies: Make error messages ambiguous so that an attacker does not know whether the username or password is invalid. Lock the account after repeated failed login attempts

Design ReviewDREAD Risk Ratings

Brute force login Damage potential: 6

Reproducibility 8

Exploitability 4

Affected users 5

Discoverability 8

Overall 6.2

Operational Review

Operational vulnerabilities result from application’s configuration result from deployment environment

Operational vulnerabilities can result from configuration options failure to use platform security mechanisms properly insecure deployment insecure base platform

Hence, responsibility falls between developer and administrative personnel

Operational Review

Attack surface reductions Minimizing attack surface = Hardening platform Get rid of unnecessary services

Use virtualization Example:

IIS HTR vulnerabilities Scripting technology not widely used because supplanted by ASP Default IIS enabled HTR service 1999 – 2002: Number of HTR vulnerabilities

Insecure Defaults In order to make installation simple Pay attention to

Application’s default settings Platform’s default settings

Operational Review

Access Control Externally, application depends completely on access

control of host OS or platform Example:

Python on Windows installed on C:\Python25 Default write permissions on Windows to any direct

subdirectory of c: drive python uses mscvr71.dll Attacker can provide mscvr71.dll in the Python25 directory python.exe will pick mscvr71.dll in its own directory by

preference

Operational Review

Secure Channel Vulnerabilities: Simply not using a secure channel

Example: Web site sends session cookie in the clear Acceptable for web-based email Not acceptable for banking

Spoofing and Identification Trusting TCP or UDP source addresses

Network profiles NFS or Server Message Block (SMB) are acceptable

within a firewall, but not without

Operational Review

HTTP request methods:Question honoring TRACE, OPTIONS, and

CONNECT requests OPTIONS – Lists all services server accepts TRACE – echoes request body to client

Worry about cross-scripting attacks CONNECT – provides way for proxies to establish

SSL connections

Directory Indexing

Operational Review

Protective Measures Stack protection

Non-executable stack Canaries

Address space layout randomization Registered function pointers

Long-lived function pointer calls are wrapped by protective checks

Virtual machines

Operational Review

Host-based measures Object and file system permissions Restricted accounts Chroot jails System virtualization

One virtual system per service Enhanced kernel protection

SELinux, Core Force Host-based firewalls Antimalware applications File and object change monitors Host-based intrusion detection systems

Operational Review

Network-based measuresNetwork address translationVirtual private networksNetwork Intrusion Detection Systems (NIDS)

Application Review Process


Process OutlinePreassessment

Planning and scoping an application review Setting up a time line

Application ReviewDocumentation and AnalysisRemediation Support


Application Access can beSource onlyBinary onlyBoth binary and sourceChecked build

Binary with additional debug information

Strict black box


Application ReviewNatural to follow waterfall model, starting with

designHowever, design review needs thorough

understanding of code, which comes with exposure.

Postpone design review.


Methodology is constrained by code reviewer’s capability to concentrate

Application review process1. Initial preparation

Without documentation Derive design from implementation: Top Down, Bottom Up, or Hybrid

2. Iterate through 2-3 hr cycles:1. Plan step2. Work3. Reflect4. Break

3. Documentation, Analysis, and Recommendations

Application Review ProcessCode Navigation Described in terms of

External flow sensitivity Control flow vs. data flow

Tracing direction Forward vs. backward

Application Review ProcessCode Navigationint foo(int c) {

if( c == 4) bar(c);

if( c == 72) fubar();

for(; c; c--)

updateGlobalState();

}

Ignoring external control flow and data flow:Read code from top to bottom

Control flow sensitive:Start with top. Then inspect bar, fubar, and

updateGlobalState

Data flow sensitive:Start with top. Then follow into bar, because it receives c.

Do not follow fubar and updateGlobalState, because they do nothing with c.

Control and data flow:You would have some idea on the range of c. For

example, if c is always larger than 40, you would not bother following bar.

Application Review ProcessCode Auditing Strategies Three basic categories of code auditing

strategies:1. Code Comprehension

Analyze source code directly to discover vulnerabilities to improve understanding of code

2. Candidate Point Strategies1. Create list of potential issues2. Examine source code to determine relevance of issues

3. Design Generalization Strategies To analyze potential medium to high logic and design flaws

Application Review ProcessCode Comprehension Strategies

CC1: Tracing malicious inputStart at entry point to the systemTrace flow of code forward, while performing

limited data flow analysis Basically, keep set of “malicious input” in the back

of your mind as you read the code Focus effort on any type of behavior that fits into a

vulnerability class that you know

Strengths: Inherent focus on security-relevant code

Can sometimes identify subtle flaws

Difficult to go off track

Weaknesses: Code and data paths balloon up quickly

Easy to overlook issues

Requires focus and experience


CC2: Analyze a moduleRead a single source file from top to bottomLook at each function in a vacuum and

document potential issuesStrengths: You learn the way application is programmed

Easier to analyze cohesive modules

Can find subtle and abstract flaws

Weaknesses: Mentally taxing

Easy to mismanage time

Constant documentation requires discipline


CC3: Analyze an algorithmLook at the algorithm and identify any

possible weakness in the design of the algorithm

Pick security relevant algorithms Crypto Security model enforcement Input processing

Strengths: You cannot go off track

Can find subtle and abstract flaws


Lacks context


CC4: Analyze a class / objectFocus on class instead of module (CC2)

Strengths: Less likely to go off track than for module analysis


Might lack context

More likely to go off track than algorithm analysis


CC5: Trace black box hitsStart out with a list of possible problems

obtained by fuzzing or manual black boxing Problems : program crashes or program displays

useful information

Trace input to vulnerabilities

Strengths: Traces some form of known issue

Easy to stay on track

Simple

Weaknesses: Ignores many other issues

Has the potential to have to deal with many false positives

Application Review ProcessCandidate Point Strategies CP1: General Candidate Point Approach

Start with low level routines that grant access to application assets or that could harbor vulnerabilities

Trace backward to the code to see whether these routines expose any vulnerabilities accessible from an application entry point

Strengths: Good coverage of known vulnerability classes

Not too difficult

Hard to get off track

Weaknesses: Biases towards a limited set of potential issues

Comprehensive impact is much lower than with code comprehension strategies

The results are only as good as your candidate points

Application Review ProcessCP1 Example Assume tool reports: util.c line 143: sprintf() used on a stack buffer

You cannot determine whether this bug is exploitable unless you can control either argument get them to be long enough to overflow buffer

Need to check all calls to the functionint construct_email(char * name, char * domain)

{

char buf [1024];

sprintf(buf, %s@%s, name, domain);

...

}

Application Review ProcessCandidate Point Strategies CP2: Automated source analysis tool

Early source analysis tools were simply lexical analyzers

Search for patterns matching potentially vulnerable source code

Newer systems do a more extensive analysis job Helpful in identifying candidate points Offer some level of analysis to speed up manual review

Strengths: Good coverage for easily identified vulnerabilities

Not too difficult


Weaknesses: Biases towards confirming only a limited set of potential issues

Comprehensive impact is much lower than with code comprehension strategies

The results are only as good as your tool

Application Review ProcessCandidate Point Strategies CP3: Simple lexical candidate points

A wide range of vulnerabilities can be easily identified SQL injection format string vulnerabilities

Simple tools can find all instances of a certain vulnerability class

Eliminate from this list everything that cannot be a vulnerability, based on whether a module handles any potentially malicious input

After pairing down, use the candidate point strategy

Strengths: Good coverage for known vulnerability classes

Not too difficult


Weaknesses: Confirms only a limited set of issues

Does not lead to comprehension

Search results depends on the pattern used

Application Review ProcessCandidate Point Strategies CP4: Simple binary candidate points

Certain classes of vulnerabilities can also be found in binary code

sign extension vulnerabilities by looking for MOVSX instruction

…

Trace backward from these candidates


Not too difficult

Hard to go off track



Search results depends on the pattern used

Application Review ProcessCandidate Point Strategies CP5: Black box generated candidate

pointsUse fuzzing or manual black boxing to find

issuesTrace them back to user-malleable input


Not too difficult, after training and depending on trace




Results depend on the tool

Application Review ProcessExample

movzx ecx, word ptr [eax+0Ah]

dec ecx

mov edx, ecx

shr ecx, 2

lea edi, [eax+19h]

rep movsd

mov ecx, edx

and ecx, 3

rep movsb

pop edi

pop esi

A huge copy occurs if we control the short integer at [eax+0Ah] and set it to zero.

The dec ecx will result in an integer underflow

Crash would occur on the rep movsd instruction (which get the number of moves from the ecx register)

Once crash is identified, we need to figure out where [eax+0Ah] is populated

Application Review ProcessExample Crash in analyzed by:

Finding the instruction where the program crashed Examine why it crashed there:

Invalid source operand? Invalid destination written to? Index to memory to large? Loop counter not a sane value?

Work backward to determine where the invalid operand came from.

Connect invalid operand with some data fed to the program at the entry point that was fuzz-tested. Determine the part of data that causes the exception to occur

Application Review ProcessExample Dealing with faults where application seems to crash at a random

location: Usually memory corruption, where corrupted portion is not used

immediately: In our example:

You determined that [eax+0Ah] was set to 10h at initialization and never changed

But obviously it now contains 0. Two possibilities:

1. Memory corruption in the structure to which eax points2. Corruption of another buffer on the heap has overwritten the structure eax

points at.1. In the first case: fuzzing with same input should result in an identical

crash2. In the second case: application might crash somewhere else or not at

all

Application Review ProcessCandidate Point Strategies CP6: Application specific candidate points

Sometimes after working with an application, you find recurring vulnerability patterns

Search for the resulting patterns – the application specific candidate points

Strengths: Good balance of speed and depth of coverage

Not too difficult


Weaknesses: Requires a thorough understanding of the code base

Deals only with a limited set of issues

Application Review ProcessDesign Generalization Strategies DG1: Model the system

Start with implementationReverse engineer designLimit yourself to security-critical components

Strengths: Most effective method for identifying logic and design vulnerabilities

Can identify even some operational vulnerabilities

Provides detailed knowledge of the application’s design

and architecture

Weaknesses: Requires a thorough understanding of the system implementation

Requires focus and experience

Can be extremely time consuming

Application Review ProcessDesign Generalization Strategies DG2: Hypothesis testing

Determines design of smaller elements of code by making a hypothesis and testing the hypothesis

If you are correct, you reverse engineered a part of the application and investigates its consequences

If not, then you probably understand the code element better and can make a better guess

Strengths: Faster method to identify issues with design

Helps build good understanding of design

Is well suited to identify more complex and subtle issues

Weaknesses: Easy to go off track

Poor assumptions can derail design analysis

Mentally taxing

Application Review ProcessDesign Generalization Strategies DG3: Deriving purpose and function

Try to directly identify the abstraction that the implementation represents

Pick key programmatic elements elements and summarize them

Should lead to a good understanding of the programmatic idioms responsible for the components of the trust model

Derive and identify design and architectural issues

Strengths: Focuses on areas known to be security relevant

Builds good understanding of the application design and architecture

Builds good understanding of individual design aspects

Weaknesses: Poor assumptions can derail later elements of the review

Mentally taxing

Application Review ProcessDesign Generalization Strategies DG4: Design conformity check

Focuses on vulnerabilities arising from differences between implementation and design

Design is typically underspecified Implementation can also just deviate from design

Method tries to find “policy breaches” These are then analyzed for security

consequences

Strengths: Hard to go off track

Provides good balance between implementation and design understanding

Much easier than deriving function without a design

Weaknesses: Misinterpretation of design could result in overlooking vulnerabilities

Quality of result depends on the quality of original design

Application Review ProcessCode Auditing Tactics CODE AUDITING TACTICS:

Purpose: Make errors such as skipping a line of code less

likely

Set of simple tricks

Application Review ProcessCode Auditing Tactics Internal Flow Analysis

Follow all control and data flows in a given module

Overlooked, but potentially relevant code: Error-checking branches Pathological code paths:

Functions with many small and non-terminating branches

Example:

char * ReadString(int fd, int maxlength)

{

int length;

char * data;

if(read_integer(fd, &length) < 0)

return NULL;

data = (char *) malloc(length + 1);

if (data ==NULL)

return NULL;

if (read(fd, data, length) < 0)

{

free(data);

return NULL;

}

data[length] = ‘\0’;

return data;

}

If read_integer fails:

read_integer(fd, &length);

return NULL;

Not very exciting.

If read fails:

read_integer(fd, &length);

data = (char *) malloc(length + 1);

return NULL;

read(fd, data, length)

free(data);

return NULL;

There is a major difference in handling a failure between these two function calls

Application Review ProcessCode Auditing Tactics Subsystem and dependency analysis

Often, security sensitive code is spread over several modules

Rereading codeWith different emphasis and vulnerability

class targets

Application Review ProcessCode Auditing Tactics Desk-Checking

Create table of all variables in a code fragment

Populate them with initial valuesFollow execution by steping through each line

of code.

Application Review ProcessCode Auditing Tactics Test Cases

For a program or a small isolated part of code Implemented by:

Writing software to interact with program and provide input Entering values manually into a program using debugger Entering values manually into a program using desk-checking

Choosing test values: Boundary values Several inputs Too many cases

Constraint establishment Practice of verifying that certain test values cannot reach the program fragment

Extraneous input thinning Eliminate test inputs that are not a concern

Software Security Assessment COEN 225. Code Auditing vs. Black Box Penetration Testing.

Documents

Transcript of Software Security Assessment COEN 225. Code Auditing vs. Black Box Penetration Testing.