Homework 2: Dynamic Web App
homework代做 | security | network代做 | 代写sql | database – 这是利用javascript进行训练的代写, 对web app的开发流程进行训练解析, 是有一定代表意义的security/Network/network/javascript/app/Objective/html/sql/database等代写方向, 该题目是值得借鉴的lab代写的题目
####### This assignment is significantly more difficult than homework 1. Start early.
After HW1, your server can host a static front end and a dynamic API. Now, you'll write a
dynamic front end where users can share data, and images, with each other. As you do this,
there are many security concerns that will arise since you cannot trust that every user will
act in good faith (NEVER trust your users).
For this HW, you'll modify your index. html by adding the provided HTML form and hosting it
at the root path "/". If you created a custom page, you can add the form to your page. You
may also modify the inputs as much as youd like as long as it still contains the required
functionality (eg. The form must upload an image and at least one other value).
< form action ="/image-upload" id ="image-form" method ="post" enctype ="multipart/form-data" >
< label for ="image-form-comment" >Comment: </ label >
< textarea id ="image-form-comment" name ="comment" cols ="40" rows ="6" ></ textarea >
< br />
< label for ="form-file" >Image: </ label >
< input id ="form-file" type ="file" name ="upload" >
< input type ="submit" value ="Post" >
</ form >
Learning Objective 1: Text Form and Your First HTML Template
Handle requests sent via the form by storing and displaying the comments your users
submit. To test this objective, you may submit the form without choosing a file to upload.
When a submission is made, parse the multipart request to find the comment, store the
comment on your server, and display all submitted comments on your home page.
All uploaded comments must be stored in your database and persist through a server
restart. You must use a database that runs as a separate service started by
docker-compose. Running a database in the same container as your app (eg. using SQLite,
MongoDB), or using files to store persistent data is not allowed. Using any database that
runs outside of your Docker containers (eg. Using MongoDB Atlas) is not allowed. The goal
is for you to gain experience working with multiple containers through docker-compose.
All comments submitted via this form must be displayed on your home page. You should
convert the HTML of your home page to a template to accomplish this. Use your template to
add all of the stored form submissions to the page in any format. This will allow you to
generate dynamic content for your users by programmatically writing HTML.
When the form is submitted, respond with a redirect to your home page.
Security : You must escape any HTML in the users’ submissions. Since your users can submit any text they want, a malicious user could submit HTML tags that attack other users. You cannot allow this. You must escape any submitted HTML so it displays as plain text instead of being rendered by the browser. Security : If you are using a sql database, you must protect against SQL injection attacks.
Testing Procedure
*If the testing procedure for Learning Objective 2 is successful, this procedure may be skipped since it is a subset of that functionality.
- Start your server using docker-compose up
- Open a browser and navigate to http://localhost:8080/
- Find the form and submit it several times with text, but without an image, including at least once with text including HTML
- Verify that with each submission, the browser is redirected to the home page (This must happen with a 300-level response code. Do not respond to the form with your HTML)
- Verify that all of the submitted data is displayed somewhere on the home page
- Restart the server using docker-compose restart
- Refresh the page and verify that all the comments persist
- Look through the code and verify that a database running via docker-compose is being used for the persistent storage
- Security : Verify that the submitted HTML displays as text and is not rendered as HTML
- Security : Look through the code to verify that prepared statements are being used to protect against SQL injection attacks [If SQL is being used]
Learning Objective 2: Image Uploads
Enable users to upload images, in addition to their comments, using the form. After this objective, your app will effectively be an imageboard site. You must display all images and captions uploaded through this form on your home page. Use your template to add all of the stored images and captions to the page in any format of your choosing, as long as the captions are clearly associated with their corresponding images. To display the images, add their paths to elements in your HTML. You shouldn’t embed the images themselves in your HTML. When an image is uploaded, your server will save the image as a file, and also store the corresponding caption in a way that associates it with the image. It is recommended that you devise a naming convention for the image files instead of using the names submitted by your users. Naming the images "image1.jpg", "image2.jpg", "image3.jpg", etc is fine. It is ok if your site only handles .jpg images and assumes that every file upload is a .jpg file.
Your uploads must persist through a server restart. You should store your images in files (It’s generally bad practice to store large files in a database), and store the filenames in your database. Since your images are stored in files, they will already persist through a restart. In your database, you should store the comments along with the file paths to their associated images. Note: You may need to set up your buffer to complete this objective depending on which browser/version used during testing. Some browsers (Chrome) will send the headers of an HTTP request before sending the body so you will only read the headers the first time you read from the TCP socket. You need to read again to receive the bytes of the image. Security : Don’t allow the user to request arbitrary files on your server machine. Starting with this objective, you will be hosting content at paths that cannot be hardcoded since you dont know what images will be uploaded to your site. Even if you replace the file names with your own naming convention (eg. "image1.jpg" "image2.jpg") you still don’t know how many images will be uploaded. This means that you must accept some variable from the user that you will use to read, and send, a file from your server. You must ensure that an attacker cannot use this variable to access files that you dont want them to access. (In this course, it is sufficient to not allow any ‘/’ characters in the file path.) Security : Set the "X-Content-Type-Options: nosniff" header on each response containing a user uploaded image. This will prevent attackers from uploading content that is not an image using this form.
Testing Procedure
- Start your server using docker-compose up
- Open a browser and navigate to http://localhost:8080/
- Upload one of the images from the HW1 sample site along with a caption (Only these provided images will be used to test this objective)
- Verify that the browser is redirected to the home page and the image and caption are displayed
- Upload a second image from the HW1 sample site with a different caption
- Verify that: a. The browser is redirected to the home page b. Both images and captions are displayed c. Each caption is clearly associated with the correct image
- Restart the server using docker-compose restart
- Refresh the page and verify that all comments and images persist
- Look through the code and verify that a database running via docker-compose is being used for the persistent storage
- Security : Verify that ‘/’ characters are not allowed in the requested filename (Using Postman)
- Security : Verify that submitted HTML displays as text and is not rendered as HTML
- Security : Verify that the "X-Content-Type-Options: nosniff" header is set on each image response
- Security : Look through the code to verify that prepared statements are being used to protect against SQL injection attacks [If SQL is being used]
Application Objective 1: Large Image Uploads
Use proper buffering for the image uploads to ensure that your server can handle very large files. Your server must also function correctly when images containing "\r\n" and "\r\n\r\n" are uploaded. If your server fails on either of these, you will earn a 1 for the objectives and it will not be considered complete even if you have proper buffering.
Testing Procedure
- Follow the testing procedures of Learning Objective 2 with .jpg images large enough to overflow your TCP buffer. A variety of images will be used for testing including images containing the byte sequences "\r\n" and "\r\n\r\n"
- Check the submitted code to ensure a very large TCP buffer was not used
Application Objective 2: XSRF Tokens
Add randomly generated XSRF tokens to your form. If a form submission is received that does not contain one of your tokens, do not save the submitted data and respond with a 403 Forbidden response notifying the user that their submission was rejected. Each time you receive a request [for the path "/"], you should generate a new token and add it to the HTML of the form in a hidden input. Whenever a form submission is received, it is ok to accept it if it contains any of your tokens. You don’t have to check if it was the token you issued to that user (We don’t have a reliable way to check the user until we have authentication. IP addresses can change). Tokens must be a minimum of 8 randomly generated characters.
Testing Procedure
- Start your server using docker-compose up
- Open a browser and navigate to http://localhost:8080/
- Inspect the HTML of one of the forms and verify that there is a XSRF token included somewhere as part of the form
- Refresh the page and verify that the token is different
- Delete the token a. Submit the form b. Verify that the response from the server has a code of 403 and the browser displays a message that the request was rejected c. Navigate to the home page and verify that the submitted data does not appear on the page
- Modify the token again, but instead of deleting it, append extra characters to the end of the token a. Submit the form b. Verify that the response from the server has a code of 403 and the browser displays a message that the request was rejected c. Navigate to the home page and verify that the submitted data does not appear on the page
Application Objective 3: Polling
Utilize polling, AJAX, and front-end javascript to allow users to see new posts without having to reload the page. You have much freedom in your design for this objective, as long as new posts can be seen without a reload. Note: You can still require a refresh/redirect when uploading an image.
Testing Procedure
- Start your server using docker-compose up
- Open a browser and navigate to http://localhost:8080/
- Open a second window and navigate to http://localhost:8080/ and open the network tab in dev tools
- Upload an image with comment in the first window
- Verify that the post appears in the second window without taking any action
- Verify in the network tab that the page did not reload (eg. Do not write JavaScript that reloads the page. You must use AJAX and polling)
Submission
Submit all files for your server to Auto lab in a. zip file (A .rar or .tar file is not a .zip file!). Be sure to include: A Dockerfile in the root directory A docker-compose file in the root directory that exposes your app on port 8080 All of the static files you need to serve (HTML/CSS/JavaScript/images) It is strongly recommended that you download and test your submission after submitting. To do this, download your zip file into a new directory, unzip your zip file, enter the directory where the files were unzipped, run docker-compose up, then navigate to localhost:8080 in your browser. This simulates exactly what the TAs will do during grading. If you have any Docker or docker-compose issues during grading, your grade for each objective may be limited to a 1/3.
Grading
Each objective will be scored on a 0-3 scale as follows: 3 (Complete) Clearly correct. Following the testing procedure results in all expected behavior 2 (Complete) Mostly correct, but with some minor issues. Following the testing procedure does not give the exact expected results 1 (Incomplete) Clearly incorrect, but an honest attempt was made to complete the objective. Following the testing procedure gives completely incorrect results or no results at all. This includes issues running Docker or docker-compose even if the code for the objective is correct 0 (Incomplete) No attempt to complete the objective or violation of the assignment (Ex. Using an HTTP library) -or- a security risk was found while testing the objective Note that for your final grade there is no difference between a 2 and 3, or a 0 and a 1. The numeric score is meant to give you more feedback on your work. 3 Objective Complete 2 Objective Complete 1 Objective Not Complete 0 Objective Not Complete