Data Forensic API

This solution allows a company to sign data flows coming from Single Page Applications (SPA), Native Applications, or IoT (Internet of Things) devices; also in this case, the signatures happen within a forensic environment using a proprietary and patented methodology following the standard ISO/IEC 27037:2012. The key difference between this solution and the Webpage Forensic API is that in this case the context that produces the signature is not acquired forensically.

This workflow defines how to use WT to acquire a user's API call directed to the company's Web Server. For instance, an API call coming from a Single Page Application (SPA). The acquisition will include only the user's action that provoked an API call from the SPA. However, it will not include any context whatsoever (i.e., the SPA itself).

Let's take into account the following initial scenario:

The previous image shows a simple interaction between a user and a company via an API call, which in this case originated from an SPA.

  1. The user opens a company's URL, where the SPA is being served;

  2. The SPA is sent to the user's browser;

  3. At this point the user interacts with the SPA (e.g. moves around and eventually fills a form) and finally submits an action to the server via an API call originating from the SPA;

  4. The server sends back a response to the user regarding the submitted action, and the SPA is updated accordingly.

Steps 1 and 2 are out of WT's scope. Hence, we will focus from the moment of the API call onwards, losing this way any context the user may have had before submitting the action.

Let's assume the company wants to forensically sign the interaction that occurs between the user and the company's web server via an API call originating from the SPA.

The following diagram shows, at a certain level of abstraction, how the interaction takes place once WT is integrated within the company's process.

In the previous diagram, there is no reference to the fact that the user opened and interacted with the SPA. Since those actions are out of WT's scope, we will start from the moment the API call originated.

  1. The user, while interacting with the SPA, triggers a specific action that informs the company's Web Server that he is willing to do (or it is very likely that he will do) a specific request that the company wants to acquire using WT. Note: at this point, the company must prevent the user from doing the action that triggers the request the company wants to acquire with WT.

  2. The company's Web Server, instead of responding right away, will create a new interaction using the endpoint createInteraction, specifying the property variation with value no_html. The user's Request that the company wants to acquire with WT has to be sent to WT before reaching its final destination in the company's Web Server. It is paramount that the company specify the O-URL as a parameter in the interaction creation so that when the process is concluding, WT can redirect the request to this URL.

  3. WT initialises the new interaction object. This object will represent the interaction that should take place between the user and the company's Web Server.

  4. The WT gateway will return such an interaction object to the caller. The returned object contains the ID of the newly created interaction and the forwarding URL (F-URL) to which the company's Web Server must redirect the user's API call.

  5. The company's Web Server responds to the HTTP request sent by the user via the SPA in step 1 with an HTTP redirection to F-URL. The redirection can be done in two possible ways:

  • The first one implies a prior modification of the SPA. Assuming the API call is done from a button event handler, the following can be done:

    async function eventHandler(...) { ... 
// call the endpoint that will provoke the interaction creation let interactionResponse = await fetch(COMPANY_WEB_SERVER_URL, options); 
// call the F-URL endpoint in the WT gateway let realResponse = await fetch(interactionResponse.fUrl, options); 
... }

  • The second way uses the HTTP redirection mechanism. Using this way, the SPA does not need to be modified. However, it is necessary that the company's Web Server respond with an HTTP redirect to F-URL using the HTTP code 307 to ensure the preservation of the method as well as the body.

  1. The action is then resubmitted to the F-URL endpoint in the WT gateway.

  2. At that point the WT gateway asks for the corresponding interaction for the effective URL (E-URL). This URL will be an endpoint within WT, to where the action will be redirected in order to perform a forensic acquisition.

  3. The previous action will indicate to our system to initialise a secured container to serve the effective page. The container will immediately start a forensic acquisition session.

  4. The E-URL is then returned to the WT gateway.

  5. The WT gateway will respond to the user's request in step 6 with an HTTP redirection E-URL using code 307.

  6. The action gets resubmitted this time to the E-URL served from the secured container.

  7. An HTTP redirection (of the submitted action) to O-URL will be sent back to the user's browser.

  8. The secured container will conclude the acquisition session started in step 8.

  9. The corresponding interaction will be updated accordingly, reflecting the acquisition status and all the gathered data.

  10. Due to the redirection in step 14, the user's browser will resubmit the action to O-URL served by the company.

  11. The company's Web Server sends a proper response to the user.

This extended process proposed by WT is an expansion of the normal interaction that would have taken place between the user and the company. Note that those are steps 1 and 16 of the previous flow.