search

oasis-open / cti-pattern-validator

OASIS TC Open Repository: Validate patterns used to express cyber observable content in STIX Indicators
https://stix2-patterns.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
26 stars 23 forks source link

No SCO property value but "hashes" is validated #86

Open saaj opened 2 years ago

saaj commented 2 years ago

Here is an example with stix2-patterns==1.3.2:

$ validate-patterns 
Enter a pattern to validate: [file:hashes.MD5 = '3858f62230ac3c915f300c664312c63f']

PASS: [file:hashes.MD5 = '3858f62230ac3c915f300c664312c63f']
Enter a pattern to validate: [file:hashes.MD5 = '3858f62230ac3c915f300c664312c63'] 
FAIL: '3858f62230ac3c915f300c664312c63' is not a valid MD5 hash 

Enter a pattern to validate: [email-addr:value = 'MUST NOT <jane.smith@example.com>']

PASS: [email-addr:value = 'MUST NOT <jane.smith@example.com>']
Enter a pattern to validate: [ipv4-addr:value = 'http://1.2.3.4/login']

PASS: [ipv4-addr:value = 'http://1.2.3.4/login']
Enter a pattern to validate: 
PASSED: 3  patterns
FAILED: 1  patterns

For email-addr:value the example above explicitly contradicts what the spec requires:

Specifies the value of the email address. This MUST NOT include the display name.

For ipv4-addr:value the spec is softer, but an URL is obviously not a CIDR:

Specifies the values of one or more IPv4 addresses expressed using CIDR notation.

And so on for bunch of MUSTs and plain definitions of what is what in the spec about SCOs.

Invalid ipv4-addr STIX 2.1 SCOs is already something that one can see in the wild.

Code-wise property-level validation happens here. I think the same regex-based approach can cover many if not most of the constraints (though that's understandingly quite a bit of work).

https://github.com/oasis-open/cti-pattern-validator/blob/52de2bc3373a334125fbeee0232d05fb96aa4bd8/stix2patterns/v21/object_validator.py#L24-L42

clenk commented 2 years ago

Hi @saaj, the pattern validator has so far been more concerned with the syntax of the pattern than the content, fields, and values used in it. It is definitely possible to add checks for every STIX property, but would involve adding a lot of checks. It's not something we can devote time to right now, but I'm not opposed to it, and would welcome a Pull Request to add additional checks. If there is enough interest on this issue we can make this more of a priority.