Don’t Be Evil

  1. (2 points.) Recall that it’s possible to change the HTML, and even CSS, of a web page via Chrome’s Developer Tools. But, in no more than three sentences, why is that not considered “hacking”? Put another way, why is that not considered a threat to the website?

  2. (2 points.) Suppose that a website has a secret (i.e., undocumented) feature that allows some users (e.g., administrators) to access a form like:

    <form action="/secret" method="post">
        <input autofocus name="username" placeholder="Username" required type="text">
        <input type="submit">
    </form>
    

    And suppose that the website has this route:

    @app.route("/secret", methods=["POST"])
    def secret():
        rows = db.execute("SELECT id FROM users WHERE username = ?", request.form.get("username"))
        if len(rows) == 1:
            session["user_id"] = rows[0]["id"]
        return redirect("/")
    

    In no more than three sentences, what does this secret feature allow those users to do?

  3. (3 points.) Among HTTP methods, GET is considered “safe” only insofar as “the convention has been established that [it] SHOULD NOT have the significance of taking an action other than retrieval,” per RFC 2616, the original specification for HTTP. Put another way, GET is “safe” so long as it’s “essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result,” per RFC 7231, a more recent specification for HTTP.

    It’s for this reason that Problem Set 9 prescribed that you use POST instead for buying (and selling) stocks. Suppose that you instead used GET and that your website lives at www.example.com. An adversary could then have a link like

    <a href="https://www.example.com/buy?shares=1&symbol=NFLX">mwah ha ha</a>
    

    in their website (or even an email) that, when clicked, would trick a user into buying one share of Netflix on your website if they’re already logged into your website, as in another tab! Or, worse, an adversary could simply have a link like

    <img alt="mwah ha ha" src="https://www.example.com/buy?shares=1&symbol=NFLX">
    

    in their website (or even an email). Even though that URL wouldn’t actually return an image, the user’s browser would still try to GET it, even without the user clicking anything, at which point the stock would be bought!

    Otherwise known as cross-site request forgeries (CSRF), similar attacks are unfortunately possible with POST as well. Even though your implementation of Problem Set 9 used POST for buying (and selling) stocks, how, in no more than three sentences, might an adversary trick a user into buying a stock on your website?

  4. (3 points.) Take a few minutes to read Reflections on Trusting Trust,* a famous lecture by Ken Thompson, who won the Turing Award (the “Nobel Prize of Computing”) for his “implementation of the UNIX operating system” (which is similar to Linux, the operating system underlying CS50 IDE).

    In no more than three sentences, why is it not safe to trust code (or even a compiler!) that you did not totally create yourself?

    * Note that the boldfaced captions for Figure 2.1 and Figure 2.2 are incorrect: when Thompson refers to Figure 2.1, he means the topmost figure in the righthand column of page 762; when Thompson refers to Figure 2.2, he means the middle figure in the righthand column of page 762; when Thompson refers to Figure 2.3, he means the bottommost figure in the righthand column of page 762. Also note, per asciichart.com, that the ASCII code for a “vertical tab” (aka VT) is 11 in decimal.