CS375: Software Engineering - Securing Your Software (100 Points)

Assignment Goals

The goals of this assignment are:
  1. To identify and remediate a vulnerable dependency in your project using automated tooling
  2. To find and fix an injection-class vulnerability using a parameterized query
  3. To add an access-control check so that a user can only act on their own resources
  4. To remove a hardcoded secret from source control and load it from the environment instead
  5. To document each fix as a clear before/after so that a reviewer can verify the improvement

Background Reading and References

Please refer to the following readings and examples offering templates to help get you started:

The Assignment

In this assignment, you will make four concrete security improvements to your team project. Each one corresponds to a category from the OWASP Top 10 and to a defense you practiced in the Secure Software Engineering activity. The point is not to make your project “perfectly secure” – no software is – but to practice reaching for the right defense deliberately, and to document your work so a reviewer can verify it.

If your project genuinely does not contain one of these vulnerability classes (for example, it has no database), you may instead introduce a small, clearly-labeled example in a branch and fix it there, or apply the fix to one of the course’s example projects (the databases example or the JWT/MVC example). State clearly in your writeup which approach you took.

What to Do

For each of the four tasks below, capture a before/after: a short code snippet, a diff, or a screenshot showing the vulnerable state and the fixed state.

  1. Remediate a vulnerable dependency (OWASP A06). Enable GitHub Dependabot on your repository, or run npm audit (or your language’s equivalent, such as pip-audit or mvn dependency-check). Pick one flagged dependency, update or replace it, and confirm your project still builds and its tests still pass. In your writeup, cite the advisory (CVE) and its severity. Recall the real supply-chain incident described in the activity: this course’s own website had to replace a compromised polyfill.io dependency.

  2. Fix an injection vulnerability (OWASP A03). Find a place where untrusted input is concatenated into a query or command, and convert it to a parameterized query (prepared statement), as practiced in the databases activity. Explain the root cause in one or two sentences, and note why simply rejecting suspicious characters (input validation alone) is a fragile defense compared to parameterization.

  3. Add an access-control check (OWASP A01). Find a route or action where a logged-in user could act on a resource they do not own (the classic example from the MVC activity: deleting or reading someone else’s note). Add an ownership/authorization check in the appropriate layer. In your writeup, distinguish authentication (who you are) from authorization (what you may do). Add a test showing that a different user is denied.

  4. Remove a hardcoded secret (OWASP A02/A05). Find a secret in your source – an API key, a database password, or a JWT_SECRET like the one in the MVC example – and move it to an environment variable (a .env file, excluded via .gitignore) or to your CI’s secrets store (GitHub Actions secrets.*, as used in the CI/CD activity). Explain the risk of committing a secret to a repository (CWE-798) and what you would do if a secret were leaked.

Deliverable

Submit a short report (in your project repository, linked from your project website) with the four before/after entries. For each, name the OWASP category and, where you can, the CWE identifier, and connect the fix to a threat from the STRIDE threat model you built in the activity. Ensure your project still builds and its test suite (including any new test from task 3) passes.

Going Further

Students specializing in cybersecurity can extend this work into a full, professional security engagement in the Security Capstone: a complete STRIDE threat model, automated static analysis and dependency scanning wired into CI, a methodology-driven penetration test, and a security report validated against the OWASP Application Security Verification Standard.

Submission

In your submission, please include answers to any questions asked on the assignment page, as well as the questions listed below, in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in a separate document prepared using a word processor or typesetting program such as LaTeX. This document should include specific instructions on how to build and run your code, and a description of each code module or function that you created suitable for re-use by a colleague. In your README, please include answers to the following questions:
  • Describe what you did, how you did it, what challenges you encountered, and how you solved them.
  • Please answer any questions found throughout the narrative of this assignment.
  • If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
  • Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
  • Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
  • Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
  • Using the grading specifications on this page, discuss briefly the grade you would give yourself and why. Discuss each item in the grading specification.
  • Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).

Assignment Rubric

Description Pre-Emerging (< 50%) Beginning (50%) Progressing (85%) Proficient (100%)
Dependency Remediation (OWASP A06) (20%) No dependency scan was run, or no evidence of scanning is provided A dependency scan (Dependabot, npm audit, or equivalent) was run and its output is included, but no flagged dependency was remediated A dependency scan was run and at least one flagged dependency was updated or replaced, with the advisory referenced A dependency scan was run, at least one flagged dependency was remediated with the CVE/advisory and severity cited, and the project still builds and passes its tests after the change
Injection Fix (OWASP A03) (25%) No injection-class issue is identified or the change does not address one An injection-class issue is identified but the fix is incomplete or still concatenates untrusted input into executable code One injection-class issue is fixed by parameterizing the query (or equivalent encoding/escaping), with a brief explanation of the root cause One injection-class issue is fixed with a parameterized query (or appropriate output encoding), the root cause is explained, and the writeup notes why input validation alone would be insufficient
Access-Control Fix (OWASP A01) (25%) No authorization concern is identified or addressed An authorization concern is identified but the added check is missing, incorrect, or enforced in the wrong layer An ownership/authorization check is added so a user can only act on their own resources, enforced in an appropriate layer An ownership/authorization check is added and enforced in the correct layer, distinguishes authentication from authorization in the writeup, and is covered by a test demonstrating that another user is denied
Secrets Management (OWASP A02/A05) (20%) A secret remains hardcoded in source, or no secret handling is addressed A hardcoded secret is identified but is not fully removed from source or from version-control history A hardcoded secret is moved to an environment variable or secrets store and excluded via .gitignore A hardcoded secret is moved out of source, excluded from version control, loaded from the environment (or CI secrets), and the writeup explains the risk of committing secrets and what to do if one is leaked
Before/After Writeup (10%) No writeup, or the writeup does not let a reviewer understand what changed The writeup lists changes but without clear before/after evidence Each fix has a clear before/after (code snippet, screenshot, or diff) that a reviewer can follow Each fix has a clear before/after with the vulnerability category (OWASP/CWE) named, and the writeup connects each fix to a threat from your STRIDE model

Please refer to the Style Guide for code quality examples and guidelines.