Don't like this style? Click here to change it! blue.css
LOGIN:
Welcome .... Click here to logout
Project 1 Turn-In Day
Alright goals:
Project Swap
Hacking/QC project (deliverable 1.5) guidelines
Personal-Growth Questions
Turn-In Instructions
Guidance/Q&A on "forking" your project (one version for portfolios and one version for the hackers)
Guidelines for the final project (deliverable 2)
Project 1.5 Internal Pentesting
Let's all partner up in the room.
So this is a light paradigm shifting project. You each made
a somewhat meaningful set of stacks. Many of you are sure you're full
of security holes. As we pivot to the security half of the
class this will be a little exercise in quality assurance.
Here is some guidance:
Use the stack you're most proud of (or most scared of)
You will swap codebases with a partner. You are on the same team.
The goal is to give them a write-up of what they need to fix.
If you discover some true vulnerabilities then write them up and maybe
take some screen shots of a working exploit of some kind.
Examples of working exploits include gaining access to
data/abilities your account shouldn't have access to; code injection;
deleting/editing/accessing the database directly; ability to take down or deface the site
Your hacking skills might be weak or their security strong.
In that case you might think you don't have much to say.
If you can't make an exploit then write-up what you tried and how they protected against it.
Also you can add advice about their code quality to help code maintenance or usability.
Give your write-up to your partner and me on November 4th.
Project 1 Growth Report
Part 1:I need the URLs of whichever hosted projects you got done, a copy of the codebase(s), a copy of your firebase security rules if you used firebase, and a run-down of any instructions for using your app you'd like to give me.
Part 2: I need you to write up and send me a personal growth report with answers to the following questions:
Describe the timeline of the project:HOW MANY HOURS DID YOU SPEND, when did you start, bottlenecks you faced, etc.
How did you meaningfully grow as a developer from the project (if you did)?
Were there any "A-HA" insights that you'll carry with you into future work?
If you collaborated with other folks in the class what was that like?
Are you proud enough of the work that you'd use it in a job interview/portfolio? If not, what would you change to make it that way?
Rate your sense of mastery on a scale of 1-10 and give a little flavor for each of our mastery tasks for this project:
You can host a website using static files on a CDN.
You can display data read from a database dynamically.
You can write data to a database (and have other users see it).
You can design your database (or API services) to give you what you need on the screen you need it.
Given an array of JSON objects display them each in a template and let a user interact with any particular object.
You can setup OAuth and passwords with email resets for your users.
Each person has their own personal to-do list not a global one.
You can manage client-side "routing", "deep-linking", and display different screens based on the user's choices.
Get this to me ASAP via an email to andynovo@udel.edu, I'll look at the date stamps.
Forking Guide
Take a moment to get a backup URL going
Firebase Version
I'm presuming you are using a static host (firebase hosting or github pages or apache/nginx) and rtdb as your backend.
If you're using the _/init trick it's as simple as:
Make a new project
Export the DB from the old one
Import the DB into the new one
Make a new folder on the command line
firebase init
Copy the static files into public
deploy
If you are copying from codepen and not using the _/init trick then also:
Get the json object from the new db and swap that out.
For the DB you can export the JSON at root and import it at root.
Non-Firebase Version
I'd say cp -r yourcode forkedcode (copy your directory of code to someplace else) and
adjust the port number.
If you did the reverse proxy work you'll need to add some more rules.
Note: for particularly critical flaws they might be able to affect your whole server.
It's up to the good nature of the pen-tester not to.