Commit Graph

10 Commits

Author SHA1 Message Date
Tom Hvitved
57f2a74636 Python: Implement ContentSet 2022-04-04 13:51:44 +02:00
Rasmus Wriedt Larsen
83f87f0272 Python: Adjust .expected based on new comment
That was changed in 9866214
2021-12-17 15:29:41 +01:00
yoff
9866214ebe Update python/ql/test/query-tests/Security/CWE-918-ServerSideRequestForgery/full_partial_test.py 2021-12-17 14:26:43 +01:00
Rasmus Wriedt Larsen
1d00730753 Python: Allow http[s]:// prefix for SSRF 2021-12-17 00:27:18 +01:00
Rasmus Wriedt Larsen
8d9a797b75 Python: Add tricky .format SSRF tests 2021-12-17 00:24:51 +01:00
Rasmus Wriedt Larsen
6f297f4e9c Python: Fix SSRF sanitizer tests
They were very misleading before, because a sanitizer that happened
early, would remove taint from the rest of the cases by use-use flow :|
2021-12-16 23:24:08 +01:00
Rasmus Wriedt Larsen
4b5599fe17 Python: Improve full/partial SSRF split
Now full-ssrf will only alert if **all** URL parts are fully
user-controlled.
2021-12-16 22:48:51 +01:00
Rasmus Wriedt Larsen
cb934e17b1 Python: Adjust SSRF location to request call
Since that might not be the same place where the vulnerable URL part is.
2021-12-16 22:48:51 +01:00
Rasmus Wriedt Larsen
b1bca85162 Python: Add interesting test-case 2021-12-16 22:48:51 +01:00
Rasmus Wriedt Larsen
1cc5e54357 Python: Add SSRF queries
I've added 2 queries:

- one that detects full SSRF, where an attacker can control the full URL,
  which is always bad
- and one for partial SSRF, where an attacker can control parts of an
  URL (such as the path, query parameters, or fragment), which is not a
  big problem in many cases (but might still be exploitable)

full SSRF should run by default, and partial SSRF should not (but makes
it easy to see the other results).

Some elements of the full SSRF queries needs a bit more polishing, like
being able to detect `"https://" + user_input` is in fact controlling
the full URL.
2021-12-16 01:48:34 +01:00