René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Introduce reverse matches on cascading rules to enforce scope","articleBody":"## ➹ New Feature implementation request\r\n\r\n### Is your feature request related to a problem?\r\nAs a pentester, I want to gain confidence in letting run secureCodeBox cascading rules unattended, so that I have assurance that secureCodeBox will only scan in-scope targets given the engagement.\r\n\r\nCurrently, cascading rules are triggered based on whether a static value exists in the finding.\r\n```yaml\r\nspec:\r\n  matches:\r\n    anyOf:\r\n      - category: \"Subdomain\"\r\n        osi_layer: \"NETWORK\"\r\n  scanSpec:\r\n    scanType: \"nmap\"\r\n    parameters:\r\n      # Target Port of the finding\r\n      - \"{{location}}\"\r\n```\r\n\r\nIt is however not possible to verify whether the matched subdomain is present in the given scope.\r\n\r\nA practical example engagement scope:\r\n  - `example.com`\r\n  - `subdomain.example.com`\r\n  - `12.34.56.78/24`\r\n\r\nA pentester would like to investigate whether more subdomains exist so runs AMASS, it returns `example.com`, `subdomain.example.com`, and `subdomain2.example.com`. Nmap is triggered on all of them, while `subdomain2.example.com` was out-of-scope. Furthermore, it should have been verified whether `example.com` and `subdomain.example.com` even resolve to an IP in `12.34.56.78/12`.\r\n\r\n### Describe the solution you'd like\r\nIn the cascading rule spec, we can introduce a field allowing rule developers to do reverse matching on scan labels.\r\n\r\n```yaml\r\nmetadata:\r\n  labels:\r\n    \"engagement.scope/domains\": \"example.com,subdomain.example.com\"\r\n    \"engagement.scope/cidr\": \"12.34.56.78/24\"\r\n```\r\n\r\nThen in cascading rule yaml:\r\n```yaml\r\nspec:\r\n  matches:\r\n    scanSelector:\r\n      allOf:\r\n        - key: \"engagement.scope/domains\"\r\n          operator: Contains\r\n          value: {{attributes.host}}\r\n        - key: \"engagement.scope/cidr\"\r\n          operator: InCIDR\r\n          value: {{attributes.ip}}\r\n    anyOf:\r\n      - category: \"Subdomain\"\r\n        osi_layer: \"NETWORK\"\r\n  scanSpec:\r\n    scanType: \"nmap\"\r\n    parameters:\r\n      # Target Port of the finding\r\n      - \"{{location}}\"\r\n```\r\n\r\n`scanSelector`  would be a similar field to the Kubernetes-native `labelSelector`, but fully interpreted in the cascading scans hook. This also allows us to define special operators (like Contains or InCIDR).\r\n\r\n`allOf` is used in the example above. Would `anyOf` or `noneOf` have any further use cases?\r\n\r\nIn any case, I'd like some feedback on the problem and potential solution :thinking: . What do you think?","author":{"url":"https://github.com/EndPositive","@type":"Person","name":"EndPositive"},"datePublished":"2021-10-22T14:20:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/761/secureCodeBox/issues/761"}