How to read a specification
Here’s what Prof Eddy wrote.
1) The program should display a welcome message and prompt the user for a username. Create a simulated buffer overflow condition by allowing a user to input more data than the size of the allocated memory (causing the program to crash).
2) Implement input validation to mitigate the simulated overflow vulnerability. Check that the username entered has a minimum length of 8 characters and a maximum of 25 characters. If the user enters a username length outside those limits, return an error message and prompt the user to re-enter the username.
Also, recall that Prof Eddy supplied a video accompanying the spec, which gave a clear example of one way to simulate the error.
- Your program should display a welcome message and prompt for a username. Simple.
- There’s no mention of password or any other input. Just username. No need to prompt for multiple usernames, passwords, mother’s maiden name, last four digits of your SSN, color of the sky, or anything else.
- If input exceeds size of allocated memory, simulate a buffer overflow error! (I know, this is a little kludgey, but it is what it is, and we should all understand it is to illustrate a point.) There are many ways to do this; the video shows you a very simple one. Some of you got creative (in a positive way) and that’s OK; others didn’t simulate an error at all (insert sad-face emoji here).
- The specification isn’t as explicit as it might be in this case, but for best comparison between vulnerable and fixed code, generally it’s best to keep as many things constant as possible. So since you were asked to permit usernames of length 8-25 characters, this should have (implicitly) been a constraint for program #1, with usernames with fewer than eight characters rejected normally, and usernames with more than 25 characters generating an error.
- Ideally, the preallocated structure that should have been used in program #1 should have been left in place, and input validation should have ensured that nothing bigger than that structure would be accepted as input. (I did not deduct points if that preallocated structure was removed in program #2.)
In summary, please read assignment specifications carefully, and think how best to demonstrate that you did indeed fix something that was broken! While most folks did OK, some folks didn’t satisfy basic requirements, and some folks made extra work for themselves.
As we gain more experience, I will be a little more strict about how assignments are graded viz. with regard to specification.