search

North-Seattle-College / ad440-winter2021-thursday-repo

NSC AD 440 Winter 2021 Thursday cohort practicum repo
Apache License 2.0
2 stars 27 forks source link

SQL injection DELETE test for /users/{user_id} #228

Closed AllisonBC closed 3 years ago

AllisonBC commented 3 years ago

Closes #200

Creates GitHub action for SQL injection test for HTTP method DELETE to delete /users/{user_id} (from HttpTriggerAPIUsersId api)

What it does:

  1. Create test users: one to delete and one to attempt an SQL injection. Retrieve the new userId's for both
  2. Attempt DELETE and UPDATE injection
  3. Check for injection attack success NOTE: Because of the known bug with GET requests and Redis caching for users/userId (described more in comments below) I currently (for testing purposes) have this test set to continue to run, but rather show an error message with the email values if the emails don't match. Once the bug is corrected, the test should be changed to fail in the case of email values not matching.
  4. Delete results file

To test: I tested this task in a fork. (Screenshots to follow) image

Time Spent: Date Description Time
2/20 Watch tutorials on SQL injection 2 hrs
2/22 SQL injection article and example research 2 hrs
2/26 Review class lecture 2 hrs
2/26 Code Development Attempt 2 hrs
3/1 Code Development 1 hrs
3/3 Code Development and Research Github Actions 4 hrs
2/20- 3/4 Record keeping 1 hrs
3/5 Troubleshooting and speak with Farhad 1 hrs
AllisonBC commented 3 years ago

I am experiencing a bug in testing this feature-- the properties of users being created by the other running injection tests appear to interfere with this test, somehow.

During testing I receive as output an email generated from a different injection test. When navigating to the webpage I have noticed a lag period where the details of a query via userId are all off by one, then self-corrects after an additional GET request with the same userId.

AllisonBC commented 3 years ago

I spoke with Farhad and learned that there's an error (which Erica is already working on) involving how the Redis cache is implemented in the users/userId function GET method. Until that's fixed, this feature/action will continue to fail as I'm unable to check the results of this injection attempt.

The effect of this error can also be seen in Farhad's feature PR215 in the 10th line of the sample run, the userId retrieved is 1100, not 1101 as referenced in the previous lines above