jasonpuglisi / emmental Goto Github PK

Acceptance Criteria

1. Authenticated user must be able to upload a video that exists on their local filesystem
2. Video must be in a valid format
3. Video must be stored and disk have its metadata added to database/index
4. Test case must exist for video upload, access/view, and then deletion

Acceptance Criteria

1. Test is created using pytest
2. Test asserts that application is running and accessible on port 80
3. Test asserts that application body contains Hello World
4. Test is located in directory /tests/
5. Test is automatically run by Travis CI when submitted in a pull request
6. Travis CI updates pull request with results of test

Acceptance Criteria

1. The attached documentation questions are answered in a new wiki page titled Development FAQ: Video Platform
2. The new wiki page is added to the wiki index on the home page of the wiki

Questions

1. How do you prevent XSS is this step when displaying the username of the user who uploaded the video?
2. How do you ensure that users can’t delete videos that aren’t their own?

Acceptance Criteria

1. The attached documentation questions are answered in a wiki page

Questions

1. What Web Application security mechanisms are involved in your topology? What security mechanisms would ideally be involved?
2. What testing framework did you choose and why?

Acceptance Criteria

1. Page must be the only page accessible to the public.
2. Page must be located at the root URL.
3. Page must present the user with the option to create an account or login.

A development guide should exist for consistency across all contributors.

Acceptance Criteria

1. Requirements are well-defined for user story creation
2. Requirements are well-defined for moving user stories between progress columns
3. Requirements are well-defined for creating branches and pushing commits
4. Requirements are well-defined for creating pull requests
5. Requirements are well-defined for reviewing pull requests
6. Requirements are well-defined for merging pull requests

Acceptance Criteria

1. Player page must allow a user to view a single video
2. Player page must be designed according to previously-made mockups (loosely)

Acceptance Criteria

1. The attached documentation questions are answered in a new wiki page titled Development FAQ: Command injection
2. The new wiki page is added to the wiki index on the home page of the wiki

Questions

1. How would you fix your code so that this issue is no longer present?

Acceptance Criteria

1. State diagrams are created according to the Unified Modeling Language (UML) (see link in resources)
2. State diagrams are stored in the directory /docs/state-diagrams/
3. State diagrams are well defined for each application component

Resources:

• State diagram guide: https://www.uml-diagrams.org/state-machine-diagrams.html

Acceptance Criteria

1. Video uploader must be able to delete any or all of their uploaded videos
2. Videos may not be deleted by anyone except the uploader
3. Test case must exist for video upload, access/view, and then deletion
4. Video must be deleted from disk

Acceptance Criteria

1. User must be able to perform command injection.
2. Test must be created to demonstrate this vulnerability automatically.
3. Video must be created to demonstrate this vulnerability manually.
4. Video must be stored in /docs/vulnerabilities/sql-injection/.

Acceptance Criteria

1. User must be able to perform SQL injection and receive output that either contains the query being executed or shows results from the database.
2. Test must be created to demonstrate this vulnerability automatically.
3. Video must be created to demonstrate this vulnerability manually.
4. Video must be stored in /docs/vulnerabilities/sql-injection/.

Acceptance Criteria

1. Developers should be able to add user stories/issues to the epic
2. Developers should be able to add user stories to the sprint/milestone
3. User stories should have a predefined template for consistency

Acceptance Criteria

1. User must be able to perform an SSRF attack.
2. Test must be created to demonstrate this vulnerability automatically.
3. Video must be created to demonstrate this vulnerability manually.
4. Video must be stored in /docs/vulnerabilities/ssrf/.

Acceptance Criteria

1. Network topology is created according to the Unified Modeling Language (UML) (see link in resources)
2. Network topology is stored in the directory /docs/network-topologies/
3. Network topology is well-defined and includes each application component

Resources:

• Network diagram guide: https://www.uml-diagrams.org/network-architecture-diagrams.html

Acceptance Criteria

1. Page must only be accessible after authenticating.
2. Page must be located at the root URL.
3. User must be redirected to page after creating account or logging in.
4. User must be presented with the option of logging out.
5. Logging out must be handled appropriately by the server and redirect the user to the unauthenticated landing page.

Notes

This page does not yet need to contain any content, it just needs to demonstrate successful authentication. Adding content will come later.

Acceptance Criteria

1. Users should not be able to make repeated unsuccessful login attempts.

Notes

We should discuss how to best handle this. Probably by using failed login logs from database per IP address.

Acceptance Criteria

1. Flow graphs are created according to the Unified Modeling Language (UML) (see link in resources)
2. Flow graphs are stored in the directory /docs/flow-graphs/
3. Flow graphs are well-defined for each application component

Resources:

• Flow graphs (activity diagrams) guide: https://www.uml-diagrams.org/activity-diagrams.html

Acceptance Criteria

1. Reverse proxy must be deployed through NGINX.
2. Reverse proxy must connect to the application server.
3. Reverse proxy must be the only system exposed to the external network.
4. Reverse proxy must be deployed through Docker Compose.

Acceptance Criteria

1. Use cases are created according to the Unified Modeling Language (UML) (see link in resources)
2. Use cases are stored in the directory /docs/use-cases/
3. Use cases are well-defined for each application component

Resources:

• Use case diagram guide: https://www.uml-diagrams.org/use-case-diagrams.html

Acceptance Criteria

1. Mockup includes all application pages and components
2. Mockup appears professional and usable
3. Mockup is of a level of complexity that can be developed in the time requirements for this project
4. Mockup files are stored in the directory /docs/mockups/
5. Mockup files include both sources (e.g., .psd, .sketch, etc.) and PNG renders

Acceptance Criteria

1. Database must be an instance of MariaDB (a better version of MySQL) in Docker.
2. Database must be deployed via Docker Compose.
3. Database must follow the documented database schema.
4. If changes need to be made to the database schema, the documentation must be updated accordingly.

Acceptance Criteria

1. The attached documentation questions are answered in a new wiki page titled Development FAQ: Server side request forgery (SSRF)
2. The new wiki page is added to the wiki index on the home page of the wiki

Questions

1. How would you fix your code so that this issue is no longer present?
2. How does your test demonstrate SSRF as opposed to just accessing any old endpoint?

Acceptance Criteria

1. Internal project collaborators should have editing rights on the repository

Notes

Nobody should be able to push to master. All commits should be pushed on separate branches and added as pull requests. They should be merged using the GitHub web interface.

Acceptance Criteria

1. Code conforms to a single style
2. Linting and formatting is set up and standardized for consistent development

Acceptance Criteria

1. Authenticated user must be able to upload a video that exists at a specified web URL
2. Video must be in a valid format
3. Video must not be located at a local/private IP address or hostname (including localhost)
4. Video must be located at a fully-qualified domain name (including TLD)
5. Video must be stored and disk have its metadata added to database/index
6. Test case must exist for video upload, access/view, and then deletion

Acceptance Criteria

1. The attached documentation questions are answered in a wiki page

Questions

1. What is the URL of your Github project?
2. How did you breakup your projects and what are the security ramifications?
3. How did you choose to break down your Epic into various issues (tasks)?
4. How long did you assign each sprint to be?
5. Did you deviate from the Agile methodology at all? If yes, what is your reasoning for this?
6. How do you ensure that after each issue/milestone that security has been verified? How would you identify such issues in an ideal environment?

Acceptance Criteria

1. The attached documentation questions are answered in a new wiki page titled Development FAQ: Authentication
2. The new wiki page is added to the wiki index on the home page of the wiki

Questions

1. Provide a link to the test cases you generated for this activity.
2. How do you ensure that users that navigate to the protected pages cannot bypass authentication requirements?
3. How do you protect against session fixation?
4. How do you ensure that if your database gets stolen passwords aren’t exposed?
5. How do you prevent password brute force?
6. How do you prevent username enumeration?
7. What happens if your sessionID is predictable, how do you prevent that?

Acceptance Criteria

1. Database schemas are created according to the Unified Modeling Language (UML) (see link in resources)
2. Database schemas are stored in the directory /docs/database-schemas/
3. Database schemas are well-defined and include each application component

Resources:

• Database schema (entity relationship diagram) guide: https://www.visual-paradigm.com/VPGallery/datamodeling/EntityRelationshipDiagram.html

Acceptance Criteria

1. Current codebase has (near) complete code coverage with unit tests.

Acceptance Criteria

1. Home page must display all videos from all users uploaded via local file or URL
2. Home page must be designed according to previously-made mockups

Acceptance Criteria

1. Application is run using Apache in a Docker container
2. Apache is fully configured through Docker Compose (see link in resources)
3. Apache serves application on port 80
4. Application contains a simple index page displaying Hello World

Resources:

• Docker Compose documentation: https://docs.docker.com/compose/

Acceptance Criteria

1. test_get_video_list in test_video.py should check the last match, not the first. This will be the video added by the test.

Acceptance Criteria

1. User must be able to perform SQL injection while receiving only a success or failure message as output (no query or database results).
2. Test must be created to demonstrate this vulnerability automatically.
3. Video must be created to demonstrate this vulnerability manually.
4. Video must be stored in /docs/vulnerabilities/sql-injection/.

Acceptance Criteria

1. Middleware must ensure unauthenticated users cannot access ANY page unless the page is whitelisted to be publicly accessible (deny by default).
2. The only whitelisted page must be the home (account creation/login) page.

Notes

We must decide if we want to put the video files behind authentication. Serving them statically from NGINX would bypass our authentication, so it may be necessary to serve them via Python after all.

Acceptance Criteria

1. Appropriate sprints exist to cover initial design epic
2. Created sprints contain all necessary stories for their completion

Acceptance Criteria

1. Application server must run Python.
2. Application server must be able to connect to the database.
3. Application server must be accessible by NGINX.
4. Application server must not be exposed to the external network.

Additional:

1. Functions must exist to create users, log users in, and log users out.
2. User creation must insert a user ID (GUID), username, and hashed password into the database.
3. User creation must automatically log the user in.
4. User login must insert a session ID (GUID) into the database and send that ID to the client.
5. User logout must remove the session ID from the database.

Acceptance Criteria

1. The attached documentation questions are answered in a new wiki page titled Development FAQ: SQL injection
2. The new wiki page is added to the wiki index on the home page of the wiki

Questions

1. How would you fix your code so that these issues were no longer present?
2. What are the limitations, if any that, of the SQL injection issues you've included?

Acceptance Criteria

1. Functions must exist to create users, log users in, and log users out.
2. User creation must insert a user ID (GUID), username, and hashed password into the database.
3. User creation must automatically log the user in.
4. User login must insert a session ID (GUID) into the database and send that ID to the client.
5. User logout must remove the session ID from the database.