CS 253 Web Dev

Levels of Adressing

• Physical (link layer) addresses. This is the lowest level of address, and its format is fundamentally dependent on the underlying network hardware. For example, Ethernet and WiFi use a 48-bit globally unique address that is hard-wired into each network interface card (the Media Access Control (MAC) address, or NIC (network interface card) address - both terms are used). 48-bit numbers allows over 28 quadrillion possible combinations.

• IP addresses. The next level of addressing is the IP address - commonly mapped using the domain name system (DNS) to a more readable domain name. Currently, IP addresses are usually four bytes long,
  which on the face of it permits over four billion hosts. In practice many of them are unusable and they are running out - hence the expansion to 16 bytes (128 bits) in version 6. Commonly, it is assumed that IP addresses belong to hosts (i.e. computers). Strictly they belong to network interfaces (and so do MAC/ NIC addresses). So if you have a machine (computer or increasingly other things too) that is connected to two networks (e.g. a small LAN and an Internet connection) it will have two IP addresses; anything with wireless as well will have more - e.g. BlueTooth + WiFi + wired (directly or via USB) means three MAC/NIC addresses and IP addresses (potentially, if the interfaces are active). As an exercise, count up the IP addresses you are using - for my family it's currently >50 which is probably not that unusual (and we don't have smart plugs and lamps everywhere). Initially, IP was intended as a protocol for communicating between networks - hence the name - and not internally within them. It was developed at a time when there were multiple competing network protocols that needed to talk to each other.

• Port addresses. The highest level of address is a port, which identifies a specific application, rather than a host (or network interface). Commonly, we are interested in communication between applications, not just machines. If we only had IP addresses, we would have no way of telling which data was meant for a web browser, which for an email client etc - they all come over the same connection. Ports are 16-bit numbers, and the combination of a port and an IP address (or a host name) is sometimes (though not strictly correctly) called a socket - a fundamental concept in networking we will study immediately after this chapter.

DNS

Usually, IP addresses are not very convenient - so we use 'readable' host names. These are associated with IP addresses by the Domain Name System (DNS) which is a global database of name-IP pairs. DNS is essentially a hierarchical distributed database of mappings between host names and host IP addresses. SU, like many large organisations, runs its own DNS server(s). They will try to resolve host names into IP addresses - if they fail, they will pass the name onto the next-higher machine in the DNS hierarchy, to see if it can resolve the name, and so on, until a match is found (or it is established that none exists).

Authoritative and caching - SU's name servers are authoritative for host names ending '.swansea.ac.uk' and '.swan.ac.uk' (meaning you can assume what they say is guaranteed always true) and caching for things that may have been looked up recently and are stored in their internal cache (which means they may eventually become out of date). Anything they can't resolve gets passed up to the next 'level'. Swansea's DNS servers include 137.44.100.226, 137.44.1.20. A handy one to know is Google - 8.8.8.8 and 8.8.4.4 both of which are offered as a public service.

Root Servers - There are 13 global root server names each of which is mapped by a system called anycasting to one of many actual, physical servers. These root servers each hold a copy of all maps between host names and IP addresses but, in general, it's expected that the vast majority of requests are handled by servers lower down in the hierarchy so relatively few requests go all the way to route servers.

Client Socket

 import java.net.*;
 import java.io.*;
 ...
 Socket s = new Socket("this.doesnt.exist.com", 1024);
     BufferedReader in = new BufferedReader(new
        InputStreamReader(s.getInputStream()));
     PrintStream out = 
        new PrintStream(s.getOutputStream());

Server Socket

import java.net.*;
SeverSocket sSoc = new ServerSocket(1024);
Socket in = sSoc.accept();

Thread

A separate, simultaneous, "execution sequence" (I'm avoiding saying process because that's a more 'heavy duty' thing) that allows you to do more than one thing at once.

Java provides a Thread class which includes all the 'machinery' necessary to start up and manage threads. All you need to do is:

• Create a class that extends Thread.

• Ensure that the class has a method with the signature public void run() which contains the code you want to run in the thread.
  Create an object of that class - e.g. we will do something like: FibThread fibT = new FibThread(inSoc);

• Start the thread by calling the Thread class' start() method (e.g. fibT.start();) which, in turn, calls the run() method you wrote.

This works - and it's what we will do because it's easy - but:

• Style. We are extending a class that does threading to create a class that does something completely different.

• Extend something else? What if you want to extend some other class because you need it's functionality?

ServerSocket sSoc = new ServerSocket(2001);
            //This is a 'real' while(true) loop
            while(true) {
                Socket inSoc = sSoc.accept();
                Thread fibT = new Thread(new FibThread(inSoc));
                fibT.start();
            }

Readers and Writers Problem

Synchronised Method

public class SynchronizedCounter {
    private int c = 0;

    public synchronized void inc() {
        c++;
    }

    public synchronized void dec() {
        c--;
    }

    public synchronized int value() {
        return c;
    }
}

If we create an object of this class, say:

SynchronizedCounter count1 = new SynchronizedCounter();

If we have multiple different threads in our code, then only one of those threads can be executing methods belonging to count1 at any one time. That is, they are mutually exclusive (we use the term MUTEX).

KEY POINT - for this to work it needs some kind of shared object - if you try to do it without a shared object between all those threads you are trying to control, it will not work.

Synchronised Block

synchronized(listOfConnectedClients) {
        //do things to the list of connected clients
}

Fortunately, we can also synchronize a block of code, and we can say which object is locked when we do it.

There can only be one thread executing code within a synchronized block parameterized by, in this case, listOfConnectedClients (i.e. some object). All other threads will have to wait until the currently executing thread exits the synchronized block.

In this case, we would want to prevent more than one thread making changes to the data at any one time. Synchronizing a method in each thread does not help us, because each thread will have its own separate object accessing the list - and synchronizing methods only stops us executing other synchronized methods for that same object at the same time - not in different ones.

Read-Write Locks

ReadWriteLock lock = new ReentrantReadWriteLock();
...
lock.readLock().lock();
//Other reads can still happen:
//1. Other code can enter this section *provided* no other code is in the corresponding *writelock* section - below
//2. Other code can enter other sections protected by the same read lock (again provided no code is in a write lock section)
lock.readLock().unlock();
...
lock.writeLock().lock();
//Nothing else can happen here - no other writes, and no reads:
//1. No other code can enter this section
//2. No other code can enter any other section protected by the same write lock
//3. No other code can enter any other section protected by the same *read* lock either - so no need to use both the read and write locks at the same time: write is enough
lock.writeLock().unlock();
...

HTTP Operations

• GET - used to retrieve data (generally parameterised in some way to say what data).

• POST - used to upload new content, and typically what happens when you upload data from a web form.

• PUT - used to update content. Typically, web browsers don't directly generate this (but they can - and we will - by using Javascript).

• DELETE - used to delete content. Again not usually generated by browsers except using Javascript.

HTTP Responses

• Begins with 1 - information

• Begins with 2 - success - obviously 200 (OK) is one of these, but you might also see 201 (Created) in response to a POST operation; or 204 (No Content) when something works but doesn't return any data.

• Begins with 3 - redirection - you need to do something more to get what you want (e.g. the data has moved and the response tells you where).

• Begins with 4 - your fault - you (the user of the service) have done something wrong. The usual one is 404 (Not Found) - but also 401 (Not Authorised) and others.

• Begins with 5 - our fault - i.e. server error. You may have seen 502 (Bad Gateway) when using csautograder.

• There are also unofficial ones.

SOAP

Web services that work by passing chunks of XML back and forward, which contain details of what methods we want to call, parameters, and results. With this, the data we pass, and how we pass that data are separate. Usually, we use HTTP but we could use any other data transport mechanism - FTP, SFTP, whatever we wanted to.

SOAP vs REST

Tightly Coupled

You create a fairly large set of methods in your API all of which get specific information.

E.g. you might have separate methods for rainfall and temperature, and you might parameterise them in some detail (location, time).

This is the 'traditional' approach.

Loosely Coupled

You have many fewer operations all of which provide more information. For example you might not supply as many parameters, and you might return more data.

REST Service

@RestController
public class Hello {

    private String name = "lemon";

    @GetMapping("/")
    public String getName() {
        return "hello " + name;
    }

    @PostMapping("/")
    public void setName(@RequestBody String name) {
        this.name = name;
    }
}

Path Parameters

@GetMapping("/", "some/path/{colour}")
public String lemon(@PathVariable("colour") String colour) {...

Used for identifying data based on heirarchy.

Query Parameters

public String lemon(@RequestParam String colour) {...

Used to filter data

Form Parameters

    @PutMapping(value="/simple-form", consumes= MediaType.APPLICATION_FORM_URLENCODED_VALUE)
    public void formPutDemo(@RequestParam String val1, @RequestParam String val2) {
        demo1 = val1;
        demo2 = val2;
    }

Produces

To specify the output type of a method, you add the 'produces' attribute. For example:

    @GetMapping(value="/{type}", produces=MediaType.APPLICATION_JSON_VALUE)
    public String demoParam(@PathVariable("type") String type) {

This says that this method, which has a single path parameter generates JSON output. Note that because there are now two parameters for the @GetMapping annotation, we need to label them - previously we just would have said e.g. @GetMapping("/{type}") - now we specify the path with value and the output type with produces.

Applies to the data in the body of the response to a request - if there is no body (e.g. you are just returning some HTTP code - maybe OK to say that an operation worked) - produces doesn't do anything.

Self Links

public class Star extends RepresentationModel<Star> {
    private String name;
    private int numPlanets;

    public Star(final String name, final int numPlanets) {
        setName(name);
        setNumPlanets(numPlanets);
	this.add(linkTo(StarResource.class).slash("name").slash(name).withSelfRel());
    }
...

{
  "name": "Sun",
  "numPlanets": 8,
  "_links": {
    "self": {
      "href": "http://localhost:8080/name/Sun"
    }
  }
}

Useful for finding direct links to information you find via filtering.

JQuery

$('#btnfruit').click(function() {
	$('#fruit').html('orange');
});

Clicking the button changes the text in the div from 'pineapple' to 'orange'. It does this by calling an anonymous function in response to the click event for the element with ID btnfruit, which in turns replaces the HTML content of the element with ID fruit.

The '#' in front of the name indicates that we are referencing the id property of the HTML element - if we used a '.' we would be referencing the class.

AJAX

Using jQuery and Javascript to generate HTTP calls to our service.

‘Asynchronous Javascript And XML’

Involves using Javascript to contact servers in the background ('asynchronous') to transfer data and update parts of a page without reloading it completely. (Like Google maps)

Secure Transmission

Ensures content cannot be intercepted (read, changed, deleted, replaced) in transit.

This is mainly handled today by using HTTPS - secure HTTP.

This protects against interception of data.

Secure Access

does the person attempting to access a service actually have authorisation to do so?

The majority of actual attacks are made via 'legitimate' channels, 'legitimate' meaning that someone is actually openly attempting to communicate with some service: not that they are trying to sneak malware into some intermediate network node to eavesdrop on data.

Authentication

• Basic - this is an established authentication protocol which is simple to understand but not hugely efficient. In Basic authentication, the 'credentials' needed are sent with every request. A drawback of this is that the credentials are sent in plain text (strictly not 'plain' text but the easy to decode format BASE64 which is not meant to secure data in any way). So you need to be using HTTPS.

• Basic Non-Pre-Emptive - as above but we don't send the credentials every time. Only when the server refuses a request. The way this works normally is the server responds with a 401 error ('not authorised') to any requests that need authentication, and the client then automatically re-sends with credentials. Done properly this is seamless . Again needs HTTPS. An advantage is that credentials - although still plain text -are not sent so often.

• Digest - a more complex scheme that in theory at least does not need HTTPS because passwords etc. are not sent in plain text (though more likely to be used with HTTPS to enhance security rather than to avoid needing it).

Realm

A sub-part of a domain (could be a whole one, or a domain could have several). As we'll see, strings representing realms will form part of authentication schemes - commonly these strings represent URI paths.

For example, given www.myuniversity.ac.uk Links to an external site. with major sub-parts for staff and students, '/staff' might be one and '/students' another.

Basic Authentication

Relies on the client always sending a specific header as part of a request:

Authentication: Basic authenticationstring

where authenticationstring is a Base64 encoded string consisting of username:password (i.e. the username followed by a :, and then a password - this means usernames cannot contain ':'.

If the authentication credentials are correct, then the request resource is sent in response. If the credentials are not correct - or missing - then the response should be a 401 code ('unauthorised') and the response should include this header:

WWW-Authenticate: Basic realm="name of the realm", charset="UTF-8"

which essentially tells the client that it needs to authenticate, and for what realm, and that it needs to use the standard 8-bit character set for usernames and passwords.

Digest Authentication

• A client makes a request of a service without attempting to authenticate

• The service responds with a 401 Not Authorised error but it includes information that will allow the client to attempt it again in a secure way

• The key part of that information is an arbitrary (but usually pretty long) number that need only be used once.

• The client then computes a value using MD5 based on the username, password, realm, the URI it's trying to contact, the HTTP method being used, as well as the use-once number the server sent it. The calculation of this is in several stages but the key point is that it's tricky to fake the result without knowing all the information and it's relatively tricky to reverse engineer the password and username from it.

• This means it's relatively safe to send the information over HTTP - although it's probably fairer to say it makes you less worried about sending it over HTTPS.

STRIDE

• Spoofing - it is possible for someone to pose as someone else? That is, what information do they need to do that, and can they plausibly get it?

• Tampering - can you change any data maliciously?

• Repudiation - can you do something malicious and then successfully deny it was you? Either so people really believe it wasn't you; or ('plausible deniability') they may suspect it was you, but be unable to prove it.

• Information disclosure - can you access and read information that you should not have access to. For example in the SQL injection example, entering bob' or 1=1 -- would return all rows where either the name was 'bob' or 1 was equal to 1 - i.e. all of them.

• Denial of service - can you deny others use of a service? This is usually characterised by an attack that 'overloads' or 'overwhelms' a service, by many attempting to use it at once. But it's more general too.

• Elevation of privilege - can you can access to a level of privilege that you should not have.

Severity = impact * likelihood

DREAD

• Damage potential - how bad could it be? What is at risk? Usually for example an Elevation of privilege attack would score very high.

• Reproducibility - what do you need to be true to get it to get to work? This isn't how hard it is - it's what conditions are necessary for it to be exploited. Are they uncommon?

• Exploitability - this is "how hard is it"? Do I just need some toolkit I can download off the internet? Or do I need some seriously-advanced skills for this?

• Affected users - what % of the users of the system are going to be affected?

• Discoverability - how likely is it to be found? This is another controversial one that many will also always score high, because (a) there's a high chance that if someone does find it they will tell everyone; or, conversely (b) that someone will find it, and quietly exploit it for their own gain.

Security Options

• Ignore it - not usually a good idea. The aim is that, especially if it's not that serious, that nobody will find it (especially if you don't make any fuss about it). The intention would be to fix it in a later release.

• Warn people - which is also risky. If you do this a lot, people will start to ignore you. You are also telling people how to exploit it by doing this.

• Remove the issue - this is not the same as fixing it. It's when a system that's affected is de-activated/and or removed from a system.

• Fix it - obviously the best solution but see the points above. It will need time and resources, which may conflict with, say, a delivery schedule.

XML

• Start with version statement. They must always start with a statement of the version of XML in use. Typically: <?xml version = "1.0"?>.

• Case sensitive. Unlike HTML elements, XML elements are case sensitive.

• Elements must match. Again unlike (some) HTML elements, all opening elements in XML must be matched by a corresponding closing element.

• Empty elements. In the event that an element is empty, it can be abbreviated. For example, <level></level> can be written <level/>.

• Nested elements. All opening and closing elements must be properly nested.

• Root element. The entire contents of an XML document must be within a single opening and closing root element pair.

• Literal data. Sometimes you wish to represent data in an uninterpreted form. To do this, surround such data with the sequences <![CDATA[ and ]]>.

• Special characters. The characters &, <, >, " and ' are special, and must be written in the following form within a document: &amp;, &lt;, &gt;, &quot; and &apos. (Strictly, only the first two must always be written in this form: the others need only be used if the data is otherwise ambiguous.)

• Comments. Comments are written between the following (slightly irritating) tags: <!-- and -->.

Long Polling

Essentially a hack to get around the issue with polling. Instead of making a call every now and again essentially saying "Any data? No? OK I'll drop the connection", connects and stays open waiting until there is data.

Once some data has been retrieved, the connection will close - so you need to immediately re-open it. This is an established approach but it's definitely a work around.

WebSockets

A two-way communication channel from server to client and back. It's basically an "upgrade" of HTTP from our point of view (and the word "upgrade" will appear in the protocol).

Body Parameters

Used for sending srtuctured data (JSON, XML), or blocks of text, binary data etc.

Optional

Allows us to specify something that may or may not be present.

To use this:

• where you would have returned a piece of data x just return Optional.of(x);

• where you would have returned null, just return Optional.empty().

• where you would have returned a piece of data x that might be null, just return Optional.ofNullable(x);

To do something with this, you can use ifPresent - which checks to see if data is present in the Optional - and get - which gets that data.