-
Notifications
You must be signed in to change notification settings - Fork 20
Curse content description
Development starts, we create the project structure. An old, know vulnerable version of the framework is used.
We add a dependency checker tool to alert us of vulnerable components.
Framework, and other vulnerable dependencies get updated to patched versions, of exceptions are added for not-patched ones.
A form to add listings is created. Raw SQL is used, concatenating the code with the user provided input.
We write a simple sql code fuzzer in a helper library to be used in unit tests.
We sanitize the input ourselves by escaping ', replacing it with \'.
We add a SAST tool to review our code.
We use prepared statements to delegate the escaping of the input to the SQL engine.
We use an ORM for extra safety.
We create a signup form to take users in. Password is stored in plain text.
We encrypt the passwords using a non-salted hashing algorithm.
We use a rainbow table to crack the passwords using brute-force.
We use bcrypt instead.
We add a login form letting the user sign in. The session is the user ID base64 encoded.
We add a random value to the session, still storing the user ID.
Use a random unique value in the session, properly encrypt it, remove user info from it.
We let the user log out. On logout, we clean the session cookie, but we don't remove it from server side.
We add a unit test that logs the user in, stores the session value, logs out, re-insert the stored value in the cookiejar and re-tries to access an authentication required page.
Delete session data from server side on logout.
Add a password change functionality. We don't invalidate sessions on password change.
We add a unit test that logs the user in, stores the session value, changes the password, re-insert the stored value in the cookiejar and re-tries to access an authentication required page.
We destroy the session on password change time.
We let the user delete it's account. We don't invalidate the session on user delete.
We add a unit test that logs the user in, stores the session value, deletes the account, re-insert the stored value in the cookiejar and re-tries to access an authentication required page.
We add a requirement for authentication to the listing creation form.
We fire BURP/ZAP test for CSRF.
We add CSRF check
We add a user profile page, displaying user information. User info is inserted in the page directly, allowing for XSS.
We fire BURP/ZAP test for XSS.
We pass the values to the html in safer ways defined by the templating language.
We add the ability to change own listings. We check for user to be authenticated, but not that user is owner of the listing.
We add a unit test that adds 2 listings and 2 users, one owned by each. We test that each user can access it's own listing, but is not able to access other user's listing.
We add access control to check that the user is allowed to edit the listing.
We add an API to allow users to mass upload listings trough XML. We don't disallow external entities in the XML parser.
We fire ZAP/BURP to test for XSS.
We configure XML parsers to be safe.
We add an API endpoint to read the listings posted. We serialize the whole user object, exposing private user data and password hashes.
We add a unit test that checks that only expected data ends up in the serialized object.
We serialize only the data we require.