Data type attacks

Data type attacks focus on testing how the system handles different data types, such as strings, numbers, dates, and binary data. Testers should consider the following strategies when performing data type attacks:

Paths/Files¶

When testing paths and file names, consider the following data type attacks to uncover potential issues:

• Long Name (>255 chars): Test with file or path names exceeding typical length limits to check for truncation or errors.

• Special Characters in Name: Use names containing spaces and special characters (e.g., * ? / \ | < > , . ( ) [ ] { } ; : ‘ “ ! @ # $ % ^ & ƒ ~ ` = + _ -) to identify encoding or validation problems.

• Non-Existent: Reference files or paths that do not exist to verify error handling and messaging.

• Already Exists: Attempt to create or write to files/paths that already exist to test overwrite and conflict resolution.

• No Space: Simulate scenarios where disk or storage space is unavailable.

• Minimal Space: Test with very limited available space to observe system behavior under constraints.

• Write-protected: Use write-protected files or directories to check permission enforcement.

• Unavailable: Reference files or paths that are temporarily unavailable (e.g., network drives).

• Locked: Try accessing files that are locked by another process to test concurrency handling.

• On Remote Machine: Access files located on remote machines to validate network and permission handling.

• Corrupted: Use corrupted files to assess error detection and recovery mechanisms.

Time & Date¶

When testing time and date handling, consider the following attacks to uncover potential issues:

• Timeouts: Test system behavior when operations exceed expected time limits.

• Time Difference between Machines: Simulate scenarios where system clocks are not synchronized.

• Crossing Time Zones: Validate correct handling of time zone conversions and boundaries.

• Leap Days: Test with dates like February 29 in leap years.

• Always Invalid Days (Feb 30, Sept 31): Use dates that never occur to check validation.

• Feb 29 in Non-Leap Years: Attempt to use leap day in years that are not leap years.

• Different Formats: Input dates in various formats (e.g., June 5, 2001; 06/05/2001; 06/05/01; 06-05-01; 6/5/2001 12:34) to test parsing and validation.

• Internationalisation: Use international date formats (e.g., dd.mm.yyyy, mm/dd/yyyy).

• am/pm, 24 hours: Test with both 12-hour and 24-hour time formats.

• Daylight Savings Changeover: Validate system behavior during daylight savings transitions.

• Reset Clock Backward or Forward: Simulate clock changes to test for time-based logic errors.

Numbers¶

When testing numeric inputs and calculations, consider the following attacks to uncover potential issues:

• 0: Test with zero values to check for divide-by-zero or unexpected behavior.

• 32768 (2¹⁵): Use boundary values for 16-bit signed integers.

• 32769 (2¹⁵ + 1): Test just above the 16-bit signed integer boundary.

• 65536 (2¹⁶): Use boundary values for 16-bit unsigned integers.

• 65537 (2¹⁶ + 1): Test just above the 16-bit unsigned integer boundary.

• 2147483648 (2³¹): Use boundary values for 32-bit signed integers.

• 2147483649 (2³¹ + 1): Test just above the 32-bit signed integer boundary.

• 4294967296 (2³²): Use boundary values for 32-bit unsigned integers.

• 4294967297 (2³² + 1): Test just above the 32-bit unsigned integer boundary.

• Scientific Notation (1E-16): Input numbers in scientific notation to test parsing and calculations.

• Negative: Use negative numbers to check for sign handling and validation.

• Floating Point/Decimal (0.0001): Test with small decimal values to uncover rounding or precision issues.

• With Commas (1,234,567): Input numbers with commas to test parsing and localization.

• European Style (1.234.567,89): Use European number formats to validate internationalization.

• All the Above in Calculations: Use these values in calculations to test for overflow, underflow, rounding, and logic errors.

Strings¶

When testing string inputs and text fields, consider the following attacks to uncover potential issues:

• Long (255, 256, 257, 1000, 1024, 2000, 2048 or more characters): Test with very long strings to check for truncation, overflow, or performance issues.

• Accented Chars (àáâãäåçèéêëìíîðñòôõöö, etc.): Use accented and diacritical characters to validate encoding and internationalization.

• Asian Chars (漢字): Input Asian characters to test Unicode and multi-byte character handling.

• Common Delimiters and Special Characters ( “ ‘ ` | / \ , ; : & < > ^ * ? Tab ): Use delimiters and special characters to check for parsing, escaping, and validation issues.

• Leave Blank: Test with empty strings to verify required field validation.

• Single Space: Input a single space to check for whitespace handling.

• Multiple Spaces: Use multiple spaces to test normalization and trimming logic.

• Leading Spaces: Input strings with leading spaces to check for trimming and formatting.

• End-of-Line Characters (^M): Include end-of-line or carriage return characters to test for line break handling.

• SQL Injection ( ‘select * from customer ): Attempt SQL injection to validate input sanitization and security.

• With All Actions (Entering, Searching, Updating, etc.): Use these string variations in all relevant actions to uncover edge cases.

• Emojis: Input emojis to test Unicode and rendering support.

Domain-Specific Rules & Uniqueness¶

When testing inputs, consider the following heuristics:

• Violates Domain-Specific Rules: Use values that break business or format rules (e.g., an IP address of 999.999.999.999, an email address with no “@”, an age of -1) to verify validation and error handling.

• Violates Uniqueness Constraint: Input duplicate values where uniqueness is required to check for constraint enforcement and proper error messaging.

Useful Resources¶

• Tomes, S. (2022, March 31). Test heuristics cheat sheet. Ministry of Testing. https://www.ministryoftesting.com/articles/test-heuristics-cheat-sheet