Santandersecurityresearch/corsair_scan

Add option to scan even if no origin header was present.

Closed this issue · 9 comments

  • Corsair_scan version: 0.2.0
  • Python version: 3.7
  • Operating System: Pop!_OS

Description

Some CORS setups may only respond with CORS headers if the request's Origin header was accepted/allow-listed.
However, the current functionality only continues to scan if the server responded with a CORS header for the origin https://scarymonster.com.

if url_data.get('headers').get('Origin'):

It'd be great if the tool tried each of the CORS tests without this check, as this could miss some valid results.

Hi. Thanks for the comment

The tool always sends a fake origin even if no origin exists in the initial request. It doesn’t run the pre-domain or post-domain tests If there is no origin

report['fake_origin'] = validate_response(url_data, SM_ORIGIN, verify)

Hey, thanks for the tool!

Ah sorry, in my haste I misread the line I highlighted. In that case this issue can be closed, though it might also be useful to add the option to use the Host header in the post/sub/pre-domain checks in addition to the original request's origin header. Do you agree?

That would be a different tool ;) This one only targets CORS so should focus only on Origin header

Thanks!

This one only targets CORS so should focus only on Origin header

Sorry, I guess I wasn't clear here :)

The tool currently scans for pre/post/sub-domain misconfigurations if the request you supply already has an Origin header, but this means you need to supply a cross-origin domain to begin with. If the site (e.g. Vulnerable.com) is already making CORS requests (Origin: sistersite.com), they'll just use that. If the site isn't already making CORS requests, it's likely a tester will just include their own domain as a basic test and let the tool do the work (e.g. Origin: attacker.com).

However, since you're basing the pre/post/sub-domain misconfig checks on the Origin header that was supplied, it's possible you're missing some test cases. For example, if we assume the site is configured to respond with CORS headers for the origin sistersite.com and *vulnerable.com, we won't detect the second misconfiguration.

My suggestion is to also add pre/post/sub-domain misconfig checks using the site's Host header. I don't mean modifying the Host header here, as like you said this would be a separate tool. Instead I'm just recommending that the tool constructs new Origin headers, using the original Host header as test cases.

For example:

GET /api/example HTTP/1.1
Host: vulnerable.com
Origin: sistersite.com
Connection: close

Test cases:

Origin: https://scarymonstersistersite.com #Pre-domain Injection
Origin: https://sistersite.com.scarymonster.com #Post-domain Injection
Origin: https://scarymonster.sistersite.com #Sub-domain Injection

//Test cases to be added
Origin: https://scarymonstervulnerable.com
Origin: https://vulnerable.com.scarymonster.com
Origin: https://scarymonster.vulnerable.com

I see what you mean now. We are doing pre-domain and post-domain tests only when the origin exists, and using as a base the value of origin. Your suggestion is to do this using as a base the host header and do it always even if there is no origin, correct?

That's correct yes. I feel like this could pick up some useful test-cases.

Thats interesting, it can be added as an optional flag. Can you open a new issue for this? And what is more important... would you like to contribute with this? :)

Will do, and of course! I'm happy to implement both my suggestions, and I'll send a PR once they're done.

I would have bypassed creating the issues altogether and gone straight to PR originally, but wanted to get thoughts on the issue in the meantime until I finished my days work :)