soulo-brett-CS

“Why did you choose your project, and has it met your expectations thus far?”

I chose my project mainly because it is a security research project, and my focus and interest has been in security during my time at OSU recently, especially this last year. I saw how it could be similar to one of my favorite projects that we did in a previous security course, called the Damn Vulnerable Web Application (DVWA). This project gave us the opportunity to build something similar, but from the ground up and how we wanted.

“Did you initially have doubts about your ability to complete the project? How do you feel now?”

Going into this term, we hadn’t really started much development at all, and I was a bit anxious and overwhelmed to get started because I was not familiar with the tech stack we are using, primarily Vue.js and Flask. I was able to find my niche within the backend, mostly in our server and database. Flask was pretty straight forward once I got going, and I had a good idea on the vulnerabilities I wanted to develop.

My experience with the DVWA project in a past course helped tremendously going in and throughout the project. I had a good idea about the OWASP ‘Top Ten Web Application Security Risks’, and had testing/hacking experience with most of them.

“What is the most interesting thing about your project and why?”

I had a handful of vulnerabilities I knew I wanted to implement, such as Brute-force hacking, Cross Site Scripting (XSS), CSRF, and SQL Injection. Accomplishing both developing and exploiting these has been the most fun and interesting part of the project for me so far.

We have managed to get these implemented on our site, through using Pinia (which is a store library for Vue) for state control, which are represented as toggles on the nav bar of our site that pop up under the ‘Vulnerabilities button’ – which when selected will change the API endpoints that are being called shown below on our homepage of our web app.

We have been able to build and design an almost fully functional faux banking web app, that implements both secure and insecure versions built out for each vulnerability. The bulk of this so far has been on the backend, specifically in the server.py code I mentioned above, that has been my main contribution for the project thus far. To make the exploits more easy to test throughout development, I have taken advantage of an extension if VS Code called Thunder Client. Leveraging this this tool, I don’t have to wait on the frontend working to be able to develop and test the vulnerable endpoints that I’ve worked on.

Here is an example of a SQL injection being tested with Thunder client which is simulating a POST request to the web page, with the malicious script included in the JSON body as shown in the left pane, and the response shown in the right pane. This is all being tested on our sql injection vulnerable endpoint, where the malicious user is able to easily enter a SQL query in the login user box, and gets all the database values returned to them, including the users login and password credentials, because of lack on sanitizing or checking user input.

Reflection on 462

Overall, the experience with this project has really boosted my confidence as a software engineer, and someone who can contribute as a solid team member to a code base.

As I get closer to graduation, I can see with more clarity both the strengths and weaknesses that I have when looking for job opportunities. From a project and security standpoint, I think I am in a decent spot compared to many. The main issue I am facing is putting aside time for LeetCode, and until I do that for a while, I likely won’t be able to make it through the tough coding interviews that most companies administer during the interview process. One day at a time.

– Brett

This term of 462 has been more focused on the actual building of our project, rather than the research and decisions on what technologies we will use, which was our focus in 461. Fortunately for us, (at least for the most part) we have been able to stick with our choices on technologies for our full-stack Security Research project.

We went into the term knowing that we would be using Vue.js for the main building block of our front-end web app, MySQL for our database, and Python’s flask for our server-side functionality and the bulk of the remainder of our backend development.

Going into this term, I actually lacked experience with most of the technologies we are implementing, so at the start, I was a bit apprehensive about learning them and hitting the ground running. Vue, being the robust framework that it is, is still not something I would say I’m overly confident in using still.

I didn’t take Web Development at OSU; instead, I took a few Web Dev courses at CC before transferring, which focused mostly on classic “vanilla” JavaScript, HTML, and CSS. Considering this, I think it has added to the challenge of picking up Vue. Fortunately, a couple of my team members have more experience with it, so that has become their focus.

I had never used Flask either, but I found that I was able to pick it up efficiently since it seems to be more straightforward in many ways and comes with tons of crucial libraries and modules that we have depended on. I would say that Flask is probably my favorite new technology that I’ve used for our project.

I have been mainly focused on the backend development of our project so far, primarily determining how to set up our server routes, aka API endpoints, so that each page they lead to will give an insecure and a secure version of each vulnerability we are exploiting. Some of the libraries and modules we have made use of for this part of the development have been crucial.

Evaluating Our Backend Tools: Pros and Cons

Flask
Pros: Flask is lightweight and flexible, making it ideal for setting up API endpoints and handling HTTP requests/responses with minimal overhead.
Cons: Its minimalistic design means we have to add several extensions (like Flask_SQLAlchemy and Flask_JWT_Extended) to cover additional features, which can sometimes complicate the overall setup.

Flask_SQLAlchemy
Pros: This ORM simplifies our database interactions by allowing us to work with Python objects instead of writing raw SQL. This abstraction not only speeds up development but also reduces the risk of SQL injection attacks.
Cons: However, the abstraction can sometimes hide the underlying SQL, making it harder to optimize or troubleshoot complex queries.

Flask_JWT_Extended
Pros: Handling authentication is more straightforward with JWTs, and this library integrates well with Flask to create, manage, and verify tokens securely.
Cons: The security of JWTs depends heavily on proper configuration – issues like improper token expiration settings or weak secret keys can introduce vulnerabilities if not carefully managed.

CSRFProtect (from Flask-WTF)
Pros: This module adds a crucial layer of security against Cross-Site Request Forgery attacks by protecting our endpoints.
Cons: It can add extra complexity during testing and debugging if not set up correctly, as it may interfere with legitimate requests unless exemptions are carefully managed.

Flask_Limiter
Pros: Implementing rate-limiting with Flask_Limiter helps defend against brute-force attacks by controlling the number of requests a user can make in a given time frame.
Cons: If the limits are too strict, they could negatively affect user experience by slowing down or blocking legitimate usage.

bcrypt
Pros: bcrypt is excellent for securely hashing passwords, thanks to its computational intensity which makes brute-force attacks difficult.
Cons: The downside is that this same computational overhead can result in slower authentication processes compared to simpler, less secure methods.

Git & Continuous Integration

I feel it is well worth mentioning that one of my favorite aspects of this project has been using Git and Continuous Integration (CI) in a legitimate full-stack project, especially with our team. This is my first time working professionally with these tools in this context, and it has been incredibly rewarding. Some real-world experience with Git for repo branch management has been truly invaluable.

The ability to track our progress, collaborate seamlessly, and automate builds has added a layer of accountability and efficiency to our development process. The sense of accomplishment that comes with seeing everything come together with CI has definitely been a highlight of this term’s work.

– Brett Sullivan

Above image represents how I feel almost 4 years into my CS degree, after a grueling fall term so far (mainly due to Defense Against the Dark Arts).

Senior Software Engineering (CS-461)

The first term of my Senior Software Engineering Project class (461) has been a good experience overall, and much less intense than I had expected it to be. Some things that I think have contributed most to this are as follows:

• An awesome and approachable hands-on professor.
• A well designed and thought out course.
• Building a CyberSecurity related project that I am somewhat passionate about.
• A solid and diverse project group that each brings a unique set of skills to the table.
• Likely the fact that it is not an industry partnered project, so probably not as intense as those can be.
• The first term in this course sequence being more about planning and design than actual building.

These factors, along with others, have provided a good experience with 461, and looking back on hearing some horror stories about the difficulty of the sequence from some past students, I wish I wouldn’t have spent so much time in fear and worry about this course.

Defense Against the Dark Arts (CS-373)

As you can maybe guess by now, this hasn’t exactly been the case for CS373. I will attempt to focus on the positive here for this course, as there is plenty of that. The course it not what I expected after taking my previous and first cybersecurity course last term in CS370. We are covering many different areas that may or may not have to do with security.

One takeaway so far has been that this class could likely be classified as a low-level systems class. The reason I say this is because the majority of our weekly labs and homework have been working in a virtual environment, whether that we a Kali Linux of some Windows OS variation, and we are dealing with a heavy amount of both assembly and operating systems stuff. Some major benefits here have been getting better with systems overall, not being so dependent on my local machine and it’s tools, and getting a TON of terminal experience. I view these all as important skills to improve on, and am doing my best to focus on the positives here.

For our final few weeks in 373, we have some higher-level concepts to focus on, such as network and firewall areas. The exception to this being in week 7 we will be using actual hardware that we ordered for a lab, so that should get interesting. Hopefully in a few weeks I can say I made it through the other side of this challenging course as a more experienced cybersecurity focused CS major with another couple notches on my belt.