:::success
# AS Lab 1 - Threat Modeling
**Document Owner: Fiege Polina**
Participants: Ivan & Alexandr
Reviewer: Nikita
:::

**Application Name:** Сhicle
**Application Version:** pre-alpha 0.0.2
**Description:**

:::info
In this assignment, you will perform threat modeling for an example application. There is a company that wants to implement a **youtube-like application**. At this stage they are designing the system and ask you for a security consulting. They want to know what potential issues they may have and how to mitigate them.
:::

Following the OWASP instructions, I first identified the main user groups. Due to the fact that there was no description of any administration tools in the declared functionality (for moderators or administrators of the platform), there are only two key users: an authorized user and an unauthorized one. To simplify understanding, I renamed them to **"user"** and **"viewer"**.

<center>

| Features | User | Viewer |
| ---------------------------------------------------------------------------------------------------------- |:----:|:------:|
| 1. Upload and delete videos | + | - |
| 2. Get video streams with desired quality | + | + |
| 3. Search available videos (filtering and sorting by some attributes) | + | + |
| 4. Display user profile and uploaded videos | + | + |
| 5. Some videos are private (only specific user) and some are hidden (not shown in search and on user page) | + | - |
| 6. Display view history | + | - |
| 7. Display, create and delete comments on video | + | - |

Table 1 - Main features of each user-group
</center>

This is what concerns the conditionally user side of the application. Now I would like to look at the technical side of the video download process. To do this, I ask you to pay attention to the approximate model of the application shown in the image below.

<center>

Figure 1 - General scheme of Сhicle
</center>

Now it is necessary to determine the external dependencies ([link to table](https://docs.google.com/spreadsheets/d/1dbRTAxZC0da2E0Q1GCDUhth2vCkwQUwNcSSDOcJPJoE/edit?usp=sharing)) of each of the application elements, thereby determining their interaction with each other.

<center>

Figure 2 - Table of External dependencies
</center>

:::info
1.1 Create a table for Entry points ([link to table](https://docs.google.com/spreadsheets/d/1n1NLne1yVhfWohxD2YIawG4X3tE8IIyAgTZ-MFF30bg/edit?usp=sharing))
:::

The input points of the system were defined as follows: HTTPS-port is the main entry point, behind which the frontend, backend and S3 parts of the system are located. Below you can see a table with a full description of all handlers and pages.

<center>

Figure 3 - Table of Entry points
</center>

:::info
1.2 Create a table for Trust levels
:::

Now I need to define trust levels in order to understand which user or process will have access to various entry points and various resources of the Chicle application. You can see the full picture illustrating all levels of trust and their description in the table below or at this link ([link to table](https://docs.google.com/spreadsheets/d/1qQ0Jua8Ve7IZzblDguspHwAUD8DhM1ALjdDU3k4KXUk/edit?usp=sharing)).

:::info
1.3 Create a table for Assets
:::
The Asset (resource) table is a complete description of both the conditionally physical objects of the system (user data in the form of text, for example) and the possibilities (ability to manage the system under administrator rights, for instance) that an attacker may be interested in in order to commit illegal actions ([link to table](https://docs.google.com/spreadsheets/d/18COJ3TRM0QvC7N3AjPbs3hDuvQCOljaf0th_XNxNSNA/edit?usp=sharing)).

:::info
2. Select at least 3 use cases that you think are the most interesting and prepare **Data Flow Diagrams (DFD)** for them.
:::

Let's consider a few cases of using the application. For example, a user wanted to delete one of their videos. I mean that the user has already logged in to his account and has now gone to his account page. Now in it, he sends a request to delete the preferred video. The handler accesses the storage to request access to this video (that is, to check if the video is correct). Then the deletion process takes place, which is also associated with the video storage, since this action must be recorded. Then, through the response form, the user receives a response to his action.

<center>

Figure - DFD "User wants to delete the video"
</center>

In the next case, the user wanted to create a new comment under the video. To do this, he needs to go to the page of a specific video. The video will be uploaded along with all the information belonging to it. In particular, a list of comments already existing under this video will be displayed. After that, the user will have the opportunity to leave a comment in text form. The comment will be processed and checked for the presence of prohibited information (here I mean a restriction on the placement of links leading to third-party resources, the use of prohibited statements, etc.). After verification, the comment will be published and shown to the user.

<center>

Figure - DFD "User wants to create a new comment"
</center>

In this case, the user wants to open access to his video for some users (by condition, these users are in groups associated with this user, for example, these are his Subscribers, Friends or another group). After the user sends a change request, the video is checked for the possibility of these changes (so that the user does not do again what has already been done, for example, the video is already available only to this group). After permission, the required user group is selected. Then the status of the video changes, then the changes are applied, simultaneously opening access to the video for the selected users.

<center>

Figure - DFD "User wants to change the access to the video"
</center>

## Part 2 - Threat Modeling

Now when I have decomposed the system I can determine possible threats. Categorizations such as STRIDE allow to identify threats in the application in a
structured and repeatable manner.

> Note that you can skip category, if you think there is no threat for that data flow that falls in that category.

Guided by this formulation, I transferred to the threat table all the resources of the Chicle application that I identified at the last step. And then I consistently searched for possible threats to the data flow from the categories proposed by the model. Thus, the table displays empty fields opposite those resources that are inaccessible to the attacker in any case. That is, I want to say that we were able to design together a system that is sufficiently protected from attacks (not taking into account its small scale). An attacker can manipulate inside user interfaces by gaining access to a user's account through any method of social engineering, for example. For possible attacks by bots or scripts, we suggest tracking suspicious user activity and using traffic monitoring in the form of IPS/IDS systems. As for internal servers and services, an attacker can access them only in case of errors by an administrator or an engineer at the stage of debugging or testing some functions in the system, however, and here we believe that this is too large an area for possible attacks. The attacker just gets access to all the internal servers and can do whatever he wants.

You can use [this link](https://docs.google.com/spreadsheets/d/1LArHRJnKeEt3BuoUcsi4yhMkOB0sB74U00stRpJ-LCg/edit?usp=sharing) to go to the table designed according to the STRIDE model.

## References:
1. [Threat Modeling Process | OWASP](https://owasp.org/www-community/Threat_Modeling_Process#)
2. [Youtube Documentation](https://developers.google.com/youtube/documentation)
3. [CVSS Calculator](https://www.first.org/cvss/calculator/3.0)