Concluding Fall Term
As the first term of my capstone project comes to an end, I am feeling good about my progress so far and looking forward to continuing development next term.
Current State of the Project
As I have completed the second progress report for my project, I believe my project is set up well for continuing development. I have created thorough requirements and design documents which will help guide development. I also have the initial implementation of the project, as well as the first vulnerability exploit completed. As the project exists now, there is a database hosted on Google Cloud, connected to (a currently local implementation of) a simple website which contains two webpages: the home page and the log in page. The home page is very simple, as the purpose is just to show that the website is connected to the database properly. The page contains basic information of my project as well as displaying the database’s Users table, which holds all user credentials. The user credentials can be used for the first vulnerability exploit on the log in page, which focuses on SQL Injection. The log in page currently has a popup with the response for each log in attempt, and if successful, the popup greets the user by name.
Implementing the SQL Injection attack was an enjoyable experience for me and increased my confidence on moving forward with development of the project. While I did reference my design document for this implementation, I ended up adjusting the attack from what was planned in the design document, to better fit the implementation of the webpage. I had initially planned for the SQL Injection attack to attempt to access all user credentials from the Users table, but once I had the basic log in page implemented, I opted to pivot this to an alternative attack.
Adjusting Plans
The attack utilizes SQL Injection to Bypass Authentication and attempt to log in without a valid password. I adjusted based on how the log in page was implemented: the user enters their username and password, which is sent by the web application to the server. The server looks up the user in the database and if they are found with the correct username and password, the server responds with their first name and last name, which the web application displays to the user in a greeting confirming their successful log in. With that being implemented, I found that an Authentication Bypass attack using SQL Injection would be a better approach for the first vulnerability. Adjusting my plan allowed for a more straightforward exploitation for the first vulnerability, while still addressing SQL Injection.
Adjusting my plans also increased my confidence in the flexibility of my design document. I attempted to factor in the unknowns of the details of implementation of the vulnerabilities by emphasizing the nuanced nature of these attacks and noting that approaches may deviate from what was outlined. I also included more vulnerabilities than I will likely have time to implement, which could allow me to drop a vulnerability that ends up being unrealistic to implement, and easily pivot to one of the other vulnerabilities noted in my document. By overplanning in my design document, I not only have flexibility in my approach to implementation, but a guideline on moving forward should I continue development beyond my time in school, which I hope to.
Continuing Development
With the base web application, database, and first vulnerability exploit complete, I am looking forward to continuing development on my project. The next vulnerability I plan to address is Path Traversal, which will require implementing a Products page and adding a file system of “product files” to be accessed by the Products webpage. My plan right now is for the attack to focus on attempting to access a file in a different directory, and the defense will focus on user input validation to ensure that website users cannot access unintended files through the Products page. While not completely necessary for the attack, this may also be a good time to implement the Access Control System, considering only users of a certain type ought to be able to access the Products page. With each vulnerability to be addressed, the process will be similar: implement an attack surface, perform an attack, implement toggleable defenses, and write a vulnerability report of the process.
Project Vision
With the initial versions of the project implemented, I have a more clear vision of what I hope for the future of this project. As I continue development by adding additional webpages, vulnerabilities, and vulnerability reports, I will be considering my end goal. I want to create a web application that someone would actually use to practice or learn about penetration testing and web security. Ideally, the end result would be something which a user of any experience level could utilize, which is worthy of being added to OWASP’s Vulnerable Web Applications Directory. As development continues I plan to perform usability tests on my web application with users of different experience levels, including complete novices and folks who may have a bit more experience. This will help inform me of any User Interface issues as well as increasing the likelihood that real people might use my web application and find it useful. If I am able to create a project that people will actually use, this will not only be personally rewarding to me but would also be a great project to include on my resume as I look for work in the computer science field.
Thanks for reading my post!
If you are interested in my project and want to be part of it, consider volunteering for user testing!
~ Cassidy Williams ~