COMP3006 - Secure Software Development

Week 5: Secure Data Processing

Dr. Yusuf Kürşat Tuncel

Department of Computer Engineering

Spring 2024-2025

1 / 43
Outline

1 Introduction to Secure Data Processing

2 Processing Untrusted Data

3 Memory Safety and Buffer Overflows

4 Integer Overflow and Underflow

5 Secure Error Handling

6 Resource Management

7 Summary

2 / 43
What is Secure Data Processing?

Core concept: Handling data in a way that prevents security

vulnerabilities.
Applies to all data entering or moving within a system.
Focus: Protecting integrity, confidentiality, and availability.

3 / 43
Why It Matters

Software interacts with unpredictable external sources:

User inputs, files, network packets.
Risks of poor data handling:
System crashes, data corruption, unauthorized access.
Real-world impact: Exploits like Heartbleed (2014) stemmed from
data mishandling.

4 / 43
Goals of Secure Data Processing

Ensure data is validated and sanitized.

Prevent unintended side effects (e.g., code execution).
Maintain application stability and security.

5 / 43
Defining Untrusted Data

Any data not generated or controlled by the application.

Examples:
User-submitted forms.
API responses from third parties.
Files uploaded by users.

6 / 43
Principle 1: Assume Malicious Intent

Treat all untrusted data as potentially harmful.

Example: A seemingly innocent string like " DROP TABLE users;"
could be SQL injection.
Mindset: ”What’s the worst that could happen?”

7 / 43
Principle 2: Sanitize Before Use

Remove or escape harmful characters.

Example: Strip <script> tags from HTML input.
Tools: Libraries like OWASP Java Encoder.

8 / 43
Principle 3: Limit Scope

Use untrusted data only where necessary.

Avoid passing it to sensitive functions (e.g., system() in C).
Example: Log user input but don’t execute it.

9 / 43
Case Study: Untrusted Data Mishandling

Scenario: Web app accepts filename from user input.

Vulnerability: fopen(user input, "r") without validation.
Exploit: User submits "../../etc/passwd".
Lesson: Always validate and restrict input paths.

10 / 43
What is Memory Safety?

Ensuring programs only access memory they’re allowed to.

Prevents corruption of data or control flow.
Key issue in languages like C/C++ with manual memory
management.

11 / 43
Buffer Overflows Explained

Occurs when data exceeds allocated buffer size.

Overwrites adjacent memory regions.
Consequences:
Crashes (best case).
Arbitrary code execution (worst case).

12 / 43
Buffer Overflow Example 1

char buffer [10];

strcpy ( buffer , " This string is way too long !") ;

Buffer size: 10 bytes.

Input size: 28 bytes.
Result: Overwrites memory beyond buffer.

13 / 43
Buffer Overflow Example 2

void vulnerable ( char * input ) {

char buffer [10];
strcpy ( buffer , input ) ; // No bounds checking !
}
int main () {
vulnerable (" This is an exploit !") ;
return 0;
}

Attacker controls input → can overwrite return address.

14 / 43
Mitigation: Safe Functions

Replace strcpy with strncpy:

char buffer [10];
strncpy ( buffer , " This is too long !" , sizeof ( buffer
) - 1) ;
buffer [9] = ’\0 ’;

Ensures null termination and limits copy size.

15 / 43
Mitigation: Bounds Checking

Manually verify input size:

if ( strlen ( input ) < sizeof ( buffer ) ) {
strcpy ( buffer , input ) ;
} else {
// Handle error
}

Prevents overflow by rejecting oversized input.

16 / 43
Modern Tools

Address Sanitizer (ASan): Detects buffer overflows at runtime.

Languages: Use Rust or Java with built-in memory safety.
Compilers: Enable stack-smashing protection (e.g.,
-fstack-protect).

17 / 43
What is Integer Overflow?

When an integer exceeds its maximum value:

32-bit signed int max = 2,147,483,647.
Adding 1 → -2,147,483,648 (wraparound).

18 / 43
What is Integer Underflow?

When an integer drops below its minimum value:

32-bit signed int min = -2,147,483,648.
Subtracting 1 → 2,147,483,647.

19 / 43
Integer Overflow Example

int size = 2000000000 + 2000000000; // 4 B

printf (" Size : % d \ n " , size ) ; // -294967296

Expected: 4,000,000,000.
Actual: Wraps around due to 32-bit limit.

20 / 43
Security Implications

Buffer Allocation:
int len = n + 100; // Overflow possible
char * buf = malloc ( len ) ;

If len overflows, malloc allocates a tiny buffer → overflow risk.

21 / 43
Mitigation: Bounds Checking

if ( n > INT \ _MAX - 100) {

// Handle overflow
} else {
int len = n + 100;
char * buf = malloc ( len ) ;
}

Check before arithmetic to avoid wraparound.

22 / 43
Mitigation: Larger Types

Use uint64 t or long long for bigger ranges:

uint64 \ _t size = ( uint64 \ _t ) n + 100;

Avoids overflow for larger computations.

23 / 43
Library Support

Use safe integer arithmetic libraries:

SafeInt (C++).
Built-in checks in Python, Java.
Compiler flags: -ftrapv (trap on overflow).

24 / 43
Why Secure Error Handling?

Errors are inevitable: file not found, invalid input, etc.

Poor handling can:
Leak sensitive info (e.g., stack traces).
Cause crashes or undefined behavior.

25 / 43
Common Mistake: Info Leakage

try {
processFile ( filename ) ;
} catch ( Exception e ) {
System . out . println ( e . getStackTrace () ) ; // Leaks
details
}

Attacker sees internal paths, function names.

26 / 43
Best Practice: Generic Messages

try {
processFile ( filename ) ;
} catch ( Exception e ) {
logError ( e ) ; // Secure logging
System . out . println (" An error occurred . Contact
support .") ;
}

User sees vague message; details stay in logs.

27 / 43
Best Practice: Handle All Cases

Don’t ignore errors:

FILE * fp = fopen (" file . txt " , " r ") ;
if ( fp == NULL ) {
// Handle error , d o n t proceed blindly
}

Prevents downstream failures.

28 / 43
Secure Logging

Log errors without sensitive data:

Avoid logging passwords, tokens.
Use sanitized placeholders (e.g., [REDACTED]).
Encrypt logs if stored externally.

29 / 43
Graceful Degradation

Design apps to fail safely:

Return to a safe state (e.g., close resources).
Notify users without crashing.
Example: Retry mechanisms for network failures.

30 / 43
What Are Resources?

Memory, files, sockets, database connections, etc.

Limited and must be managed carefully.

31 / 43
Risk: Resource Leaks

FILE * fp = fopen (" data . txt " , " r ") ;

// Forgot fclose ( fp ) !

File handle remains open → exhausts system resources.

32 / 43
Risk: Denial-of-Service

Attacker floods app with requests:

Opens many sockets/files.
App runs out of resources → crashes.

33 / 43
Best Practice: Always Free Resources

FILE * fp = fopen (" data . txt " , " r ") ;

if ( fp ) {
// Use file
fclose ( fp ) ; // Always close
}

Prevents leaks by releasing resources explicitly.

34 / 43
RAII in C++

# include < fstream >

void example () {
std :: ifstream file (" data . txt ") ;
// Use file
} // file auto - closed when scope ends

Resource Acquisition Is Initialization: Auto cleanup.

35 / 43
Timeouts and Quotas

Limit resource usage:

Set timeouts on network operations.
Cap open files/sockets (e.g., ulimit).
Prevents exhaustion attacks.

36 / 43
Monitoring Resource Usage

Track memory, file handles in real-time:

Tools: valgrind, lsof.
Detect leaks early during development.

37 / 43
Key Takeaways: Processing Untrusted Data

Assume malice, sanitize, limit scope.

Example: Validate all inputs before use.

38 / 43
Key Takeaways: Memory Safety

Prevent buffer overflows with safe functions and checks.

Tools like ASan help catch issues.

39 / 43
Key Takeaways: Integer Issues

Check bounds or use larger types to avoid overflows/underflows.

Critical in buffer sizing.

40 / 43
Key Takeaways: Error Handling

Avoid leaks, handle all cases, fail gracefully.

Secure logs protect sensitive data.

41 / 43
Key Takeaways: Resource Management

Free resources, use RAII, set limits.

Prevents leaks and DoS attacks.

42 / 43
Next Steps

Practice: Write code with these principles.

Next Week: Program Interaction Security (SQL Injection, APIs, etc.).
Reading: McGraw, G. ”Software Security: Building Security In” (Ch.
5).

43 / 43