Project 14: Secure Configuration Parser

A secure configuration file parser that handles INI/TOML-like syntax with proper bounds checking, integer validation, and path safety—demonstrating secure parsing techniques.

Quick Reference

Attribute Value
Primary Language C
Alternative Languages Python, Rust
Difficulty Level 2: Intermediate
Time Estimate 2 weeks
Knowledge Area Secure Coding / Input Parsing
Tooling Fuzzer (AFL++), Valgrind
Prerequisites Projects 1, 2, 9

What You Will Build

A secure configuration file parser that handles INI/TOML-like syntax with proper bounds checking, integer validation, and path safety—demonstrating secure parsing techniques.

Why It Matters

This project builds core skills that appear repeatedly in real-world systems and tooling.

Core Challenges

  • Handling malformed input → maps to graceful error handling
  • Line length limits → maps to bounded buffers
  • String escaping → maps to preventing injection
  • Type conversion safety → maps to integer overflow in values

Key Concepts

  • Parser State Machine: Compiler textbooks
  • Defensive Parsing: “Secure Coding in C” Ch. 8
  • Fuzz Testing: AFL++ documentation

Real-World Outcome

$ cat config.ini
[database]
host = localhost
port = 5432
max_connections = 100

[paths]
log_file = /var/log/app.log
data_dir = ../../../etc/passwd  # Attack attempt!

[security]
timeout = 999999999999999999    # Overflow attempt!

$ ./secure_parser config.ini
Parsing config.ini...

[database]
  host = "localhost" (string, 9 chars)
  port = 5432 (integer, range: 1-65535 ✓)
  max_connections = 100 (integer, range: 1-10000 ✓)

[paths]
  log_file = "/var/log/app.log" (path, validated ✓)
  data_dir = ERROR: Path traversal detected ("../../../etc/passwd")

[security]
  timeout = ERROR: Integer overflow (value exceeds INT_MAX)

Parse complete: 4 values loaded, 2 errors

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: LEARN_SECURE_C_AND_EXPLOIT_AWARENESS.md
  • “C Interfaces and Implementations” by David R. Hanson