Download CS 142 Final Examination: Winter Quarter 2022 and more Exams Data Communication Systems and Computer Networks in PDF only on Docsity!
CS 142 Final Examination
Winter Quarter 2022
You have 3 hours (180 minutes) for this examination; the number of points for each
question indicates roughly how many minutes you should spend on that question. Make
sure you print your name and sign the Honor Code below. During the examination you
may consult two double-sided pages of notes; all other sources of information, including
laptops, cell phones, etc. are prohibited.
I acknowledge and accept the Stanford University Honor Code. I have neither given nor received aid in answering the questions on this examination.
(Signature)
(Print your name, legibly!) [email protected] (SUID - Stanford email account for grading database key) Problem #1 #2 #3 #4 #5 #6 #7 #8 #9 # Points 12 12 12 12 10 16 10 12 16 10 Problem #11 #12 #13 #14 #15 Total Points 10 15 12 11 10 180
The “same origin property” allows browsers to isolate cookies from different websites. Websites at different locations (i.e. hostname and port number) on the Internet can be assured that their cookies aren't accessible to the other locations. In addition to protecting cookie access at different locations, the “same origin property” also includes the scheme in the origin definition. Thus, a single website supporting different access protocols like HTTP and HTTPS might require multiple cookies, with one per location/protocol pair. A. A website could choose to hand out the same cookie for both HTTP and HTTPS and not have to worry about different cookie values. Explain the advantage for the backend engineer of having the same cookie for both protocols. If a website used the same cookie for both HTTP and HTTPS protocols, this would be convenient for backend engineers because they would only have to worry about one cookie’s values that would point to the session state. Using something like express-session would mean that each of the protocols would have its own session state object for the same user. Having the same cookie would give one session state shared across the protocols . B. Explain why having the same cookie value won't be a good idea and the website should use different values. Having the same cookie value for both HTTP and HTTPS is dangerous because an adversary could carry out a “Session Hijacking” attack. An adversary could steal your cookie from the website supported by HTTP by implementing a “man-in-the-middle attack”, where they simply read your cookie from an unencrypted connection. They can then use it to impersonate you even in areas of the website supported by HTTPS.
A. When using the MVC (model, view, controller) decomposition for view construction, all three MVC components must be present for the view to be rendered. When the rendering is done in the browser as we did for our React.js photoApp, we end up fetching the components from the web server. What can you say about the order that the components are fetched? In React.js, each component contains both the view and the controller. In our photoApp we load the webpack JavaScript bundle that contains all the React.js components with a single script tag when the page is first loaded. Once the components are mounted we fetch the model data of the view. Given this, the view and controller are fetched at the same time (in the JS bundle), and the model data is fetched later using API calls to the REST endpoint. B. If we consider the most optimal solution for fetching the model data of MVC components, it would be to launch a single request that specified all the model data needed for the currently rendered MVC components. Explain why GraphQL is superior to REST APIs in achieving this optimal approach. REST API exports model data as collections of resources with an HTTP GET request used to fetch a single resource. A web application with model data from multiple resources would thus require multiple GET requests, one for each different resource. GraphQL's ability to submit a query that specifies properties for multiple resources would allow fetching the same amount of data in a single HTTP request, achieving the optional solution whereas REST APIs can not.
The Domain Name System (DNS) is the system used by browsers that allow URLs to contain hostnames (e.g. www.stanford.edu) rather than the actual IP address of the web server (e.g 146.75.94.133). Although a Content Distribution Network (CDN) is not a browser, it also utilizes the DNS system. Describe how a CDN uses DNS. Unlike a browser that uses a DNS client to map the hostname in URLs to IP addresses, CDN implements a DNS server that maps the hostname in the URLs given to CDN clients to the IP address of a geographically nearby web server. Using this approach, a CDN can have the same URL connect to a server near the browser.
We saw in class that code injection attacks can happen both in the browser and in the web server. Although these are very different environments potentially located on different continents, an attack in one location can be used to set up an attack in the other location. For each of the scenarios below, describe how an attack would work. A. A code injection attack in a browser leads to a code injection attack on the server. An adversary can first stage a reflected cross-site scripting (XSS) attack, in order to send a malicious request to the server while making it look like it's coming from a legitimate user. The malicious request payload could then trigger a SQL injection attack, thus (as an example) erasing the website's production database. B. A code injection attack on the server leads to a code injection attack in the browser. An adversary can first leverage a SQL injection attack to store some malicious HTML code in the database (e.g., replace Taylor Swift's Twitter biography with a Message authentication codes (MACs) are normally generated on the server and sent to the client's browser. Consider modifying our Photo App to compute a MAC of each of the images stored in our system. We would then transfer an image's MAC along with the image to our web app frontend. What use, if anything, could our JavaScript code in the front end make with these image MACs? Explain your answer? A MAC generated on the server uses a secret key known only to the server. Without this key, the JavaScript code in the front end can't do much with MAC. It looks to the frontend like a random sequence of bits that is passed along with each image. There isn't much use the frontend can make of it. It also does not make sense to make the frontend know the secret key, since then anyone who can run the frontend can find the key and use it to forge more MACs.
In language environments with threads like Java and C++ there is usually a "sleep" function call that will pause the thread's execution for some amount of time. For example, the function: function test(x) { console.log("A"); let p = sleep(x); console.log("B"); } test(10); would output A followed by B 10 seconds later. A. In JavaScript, you could write a "sleep" function that simply looped reading the time until time had advanced "x" seconds. The above function would have the same A followed by B 10 seconds later functionality. Explain why this wouldn't be considered an acceptable way to implement sleep in JavaScript. JavaScript is single-threaded. Having a sleep function loop for 10 seconds will block execution for 10 seconds, which is an undesired behavior. The web app would not be able to process during that 10 seconds any user input that used events. B. JavaScript has promises to deal with this problem. Assume the "sleep" in the above code is a JavaScript function that returns a promise that is resolved in "x" seconds. Explain why the promise version would no longer exhibit the expected behavior (i.e. A followed by B in 10 seconds) and show what changes would need to be made to have the JavaScript work. Note that test is not declared to be an async function so await is not available. If sleep returns a promise the above function would log 'A', create and return the promise, and then log 'B'. The creating and returning the promise will be fast so ';A" and "B" will have 0 seconds between then regardless of the number passed to sleep. To fix this we need to wait until the promise resolves to do log the 'B'. Like: function test(x) { console.log("A"); let p = sleep(x); p.then(() => { console.log("B"); }); }
The Express.js session module we used in our web server generated a cookie that contains a pointer to the session state stored in the web server's memory. The session state of the photo app was quite small in size so we could replace the pointer with the state itself. Assume we keep security used to protect the pointer and have it protect the session state. Would the approach of keeping the session state in the cookie better scale to a large number of users, compared to the original pointer-based approach? Justify your answer. The approach of keeping the session state in the cookie scale to a large number of users is better than the original approach. With a pointer in the cookie, we have to store the session object in some session store. As the number of users and hence the number of session objects gets large, this session store will be large. On the other hand, if we store the session state directly in the cookie, we don't need this session store anymore and need not worry about the amount of space it uses. By storing the session state in the cookie, we get the user's browser to store the session state for us.
Cryptography has been helpful for addressing some of the attacks that web applications face. For each of the following attack types, state if cryptography could be helpful and if so, how. A. Network Attacks Encryption of the HTTP traffic between the browsers and web server can defeat eavesdropper or man-in-the-middle type network attacks. B. Session Attacks Encrypting the HTTP traffic also prevents eavesdroppers from stealing session cookies to do session attacks. MACs can also been used to prevent the forging of session cookies. C. Code Injection Attacks Unencrypted HTTP makes it easy for a man-in-middle network attack to inject script tags into the HTML being fetched into the browser. Encrypting prevent this kind of attack.
The concept of a “ done callback ” function is widely used in JavaScript library interfaces. Rather than returning a value directly, the library routine will call the provided callback function at some later time with the requested value. For example: fs.readFile(fileName, doneCallback); On the other hand, if the library routine has multiple different kinds of things it can return at different times, it can accept multiple callbacks. For example: routine(args, doneCallback1, doneCallback2, doneCallback3, …); where the different callback functions are used to return the different values. Things get complicated if there are many different return values that the caller may or may not be interested in. Explain the mechanism in Node.js that allows this kind of library interface to be more cleanly implemented. Describe how it works better than the multiple callback method. Node.js primarily uses the event listener pattern (sometimes also called the observer pattern). Under this pattern, each interested party can "subscribe"/"listen" to only those "events" that it is interested in, where each event can hold a value. As an example, routine(args, callback1, callback2); could be rewritten as: const emitter = routine(args); emitter.on('event1', callback1); emitter.on('event2', callback2); Compared to a multiple-callback approach, the event listener pattern has several advantages:
- Rather than having to specify every argument for routine(), the caller only needs to specify callbacks for the events that it is interested in.
- Rather than relying on the position of each argument, the event listener pattern allows the caller to identify each callback function by a string (the name of the event). This is less error-prone for the programmer, and simplifies refactoring when the maintainer of the library inevitably wishes to add a new event or remove an existing one.
- The event listener pattern naturally allows multiple callbacks for a single event, so several parties could listen on any set of events of interest to them on the same emitter. An alternative to the traditional event listener pattern is using an "options" object to specify callbacks. This carries the same advantages 1 and 2 as event listeners, but not advantage 3. Example: routine(args, { event1: callback1, event2: callback2 }); However, this approach is less commonly seen in Node.js.
The single-threaded nature of the JavaScript runtime in Node.js means that no two HTTP requests can be executing JavaScript at the same time. In spite of this limitation, Node.js can maintain multiple requests being processed at the same time by the MongoDB database. Explain how this is possible without concurrent JavaScript execution? Although JavaScript functions never execute concurrently, HTTP request processing is broken in many functions and many requests can be between different processing functions at the same time. Since some of these processing functions are "start database request" multiple database requests can be active at one time. Node.js has support for event and event queue. When a request is sent to MongoDB, the request won’t be blocking. Instead, we first send out the request, and while waiting for the request to be processed by MongoDB we can run other code. When the request to MongoDB comes back, an event of executing its callback function will be added to event queue and then executed in order. Therefore, it is possible for our server to maintain multiple requests being processed by MongoDB at the same time.
