Fake cookie hack to access "case/timeline/advanced-filter" as an API client

[59e5aaf4]

Hi,

Interestingly enough, the case/timeline/advanced-filter API endpoint has a different behavior depending on the authentication nature. If you're an API client with Authorization: Bearer $token, you'll get a not-that-usable JSON, and if you happend to be a web browser with Cookie: session=$session_cookie, you'll get a really usable JSON with ids of associated IOC & assets to your events.

Source code that splits the behavior for the same URL:

iris-web/source/app/blueprints/case/case_timeline_routes.py

Line 638 in d433bb6

if request.cookies.get('session'):

Here's how we hacked our way through this, so that we could export to our threat intelligence platform the relationships between IOC & assets, should they not be already carried in the asset & IOC properties ( there's a checkbox disabling that when creating a timeline event ) :

We go scavenge the ClientSession or our Case and build a raw request with it, adding our token as expected, and a fake Cookie: session=hack header so that the API code is happy to see "a session cookie".

# self.case : dfir_iris_client.case.Case
# self.case._s : dfir_iris_client.session.ClientSession
r = requests.request(
    method = 'get',
    url = self.case._s._pi_uri(f'case/timeline/advanced-filter?cid={self.case_id}&q=%257B%257D'),
    headers = {
        'Content-Type': "application/json",
        'Authorization': "Bearer " + self.case._s._apikey,
        'User-Agent': self.case._s._agent,
        'Cookie': 'session=hack',
    },
    verify = self.case._s._ssl_verify,
    timeout = self.case._s._timeout,
)
result = r.json()

There's no valid reason to keep sending a Content-Type: application/json for a GET request lol, but hey ClientSession does that so.. :D