diff --git a/output/info202_labs.html b/output/info202_labs.html index cd527b5..6ea51ed 100644 --- a/output/info202_labs.html +++ b/output/info202_labs.html @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:9d744fd8c051158e914dc0c9106904263f8b4553b3e51673513a77f7a17cf16d -size 4787098 +oid sha256:3f404cc692b80b82c8e466535f840427f2ccbcced9d922abfe4c9fe4264715bb +size 4784276 diff --git a/tiddlers/content/labs/lab11/_Labs_11_Allow List for Static Assets.md b/tiddlers/content/labs/lab11/_Labs_11_Allow List for Static Assets.md new file mode 100644 index 0000000..1d9e204 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Allow List for Static Assets.md @@ -0,0 +1,49 @@ +Jooby makes it very easy for us to create an allow list (formerly known as a white list) for the URLs that it is allowed to serve. Jooby will return a 404 error for any URL that isn't explicitly allowed. + +The API paths are already allowed simply because we have listed all of the URLs that we need in our modules and Jooby will reject all others. + +The `StaticAssetModule` is the primary problem since it will serve anything that is in the <> folder. If a malicious user can somehow get a file into this folder then our web server will happily serve it. + +An allow list includes **only** the files that are allowed to be served. Anything that is not in the list will be rejected with a 404 response. + +Expand the assets module to explicitly list all of the files that your AJAX client is using. + +The result should look something like: + +```java +// home page +assets("/", Paths.get("static/index.html")); + +// html files +assets("/index.html", Paths.get("static/index.html")); +assets("/signin.html", Paths.get("static/signin.html")); +// ... and the rest of the HTML files + +// css files +assets("/css/style.css", Paths.get("static/css/style.css")); +// ... and the rest of the CSS files + +// JavaScript files +assets("/js/data-store.js", Paths.get("static/js/session-store.js")); +assets("/js/navigation.js", Paths.get("static/js/navigation.js")); +assets("/js/customer.js", Paths.get("static/js/signin.js")); +// ... and the rest of the JavaScript files + +// external JavaScript files +assets("/js/external/vue.global.js", Paths.get("static/js/external/vue.global.js")); +assets("/js/external/vuex.global.js", Paths.get("static/js/external/vuex.global.js")); +assets("/js/external/vuex-persistedstate.js", Paths.get("static/js/external/vuex-persistedstate.js")); +assets("/js/external/axios.js", Paths.get("static/js/external/axios.js")); + +// ... and any images that you have added, if any +``` + +Adapt to suit your file names. You need to list every single file that your client is using. While this is a little bit tedious it does add a lot of protection to the web site. + +Comment out the existing `assets` line since it is dangerous. + +You have most likely received a phishing email that contains a link to a random web site in another country that appears to be hosted by a small business. This is because the maintainers of the site for that business did not use an allow list for their files and an attacker has found a way to upload their own pages to the site which they are now using for phishing scams. + +The attacker could just as easily (and may already have) uploaded a page that downloads sensitive data from the site. + +Restart and test the application to make sure you didn't break anything. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Allow List for Static Assets.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Allow List for Static Assets.md.meta new file mode 100644 index 0000000..ee092e9 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Allow List for Static Assets.md.meta @@ -0,0 +1,4 @@ +section: 3 +tags: lab lab11 +title: /Labs/11/Allow List for Static Assets +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Create the Server Certificate.md b/tiddlers/content/labs/lab11/_Labs_11_Create the Server Certificate.md new file mode 100644 index 0000000..deff54d --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Create the Server Certificate.md @@ -0,0 +1,62 @@ +1. We can now create certificates that are signed by the mkcert CA. We need to create a certificate for the web server that hosts the web service. The server is running on the `localhost` host, so we need to create a certificate for that host. Run the following command. + + **Windows** + ```plaintext + $env:CAROOT = pwd; .\mkcert.exe -pkcs12 localhost + ``` + + **Linux** + ```plaintext + CAROOT=$(pwd) ./mkcert -pkcs12 localhost + ``` + + **Mac** + ```plaintext + CAROOT=$(pwd) ./mkcert -pkcs12 localhost + ``` + + PKCS12 is a package format for X.509 certificates that allows us to bundle the certificate and the private key together into a single encrypted file. + +1. You should see a new file in the `mkcert` folder named `localhost.p12`. + + As mentioned, this is a PKCS12 file that contains both the certificate and the private key. Although TLS uses X.509 certificates which can be used for public key (asymmetric) encryption, TLS uses symmetric encryption. The client and server perform a handshake to negotiate a shared session key which is then used by both sides for encrypting and decrypting the messages. The private key that is generated is used as part of the handshake but is not used for the encryption of HTTP messages. + +1. Copy the `localhost.p12` file into the `resources` folder of your NetBeans project. You might be able to drag and drop from the file manager into the <> folder in the projects pane (this usually works on Windows and Linux. Macs are always a problem). If the drag and drop doesn't work, then use the `openProjectFolder` Gradle task to open the project folder, and then navigate to <>. + +1. We need to create the configuration file for Jooby. Right click the <> source folder in the project pane and select < Other > Other > Empty File">>. + + Name the file `application.conf`. + +1. We need to tell Jooby where to find the certificate and key so add the following to the `application.conf` file. + + ```plaintext + application.tmpdir: build/tmp + + server { + + port : 8085, + securePort: 8443, + + ssl { + type: PKCS12, + cert: localhost.p12, + password: changeit + } + } + ``` + + This also sets the port that will be used for both HTTP and HTTPS connections, and defines a temporary directory that Jooby will use to cache the keys while the server is running. The password is the default password that mkcert used to encrypt the PKCS12 file. + +1. The `application.conf` file is now providing the server options, so comment out the `setServerOptions` call in the the `Server` class since it will override the settings in the configuration file. + +1. Run your application. You should now see two URLs being displayed in the output console when Jooby starts. Click the one that starts with `https://`. + + You should see the padlock icon in the browser's location bar to indicate that the connection is encrypted. Your web pages should still work as per normal. + +Note that we did not need to write any JavaScript or Java code to encrypt the HTTP request. We have added the encryption at a layer below where our application resides --- the browser and the web server are doing all of the hard work for us --- our application should not even be aware that the encryption is taking place. + +Network sniffing is a significant threat as it is very easy to do. A malicious attacker does not even need to be inside a building in order to sniff a network. There are small and inconspicuous devices that can be plugged into a wall socket, or dropped somewhere out of the way that can capture and re-transmit data from wireless networks to a malicious attacker. There are equivalents for wired networks too. See the following article for an example: + +https://www.wired.com/2012/03/pwnie/ + +Note that that article is now more than 10 years old --- things have gotten a lot smaller and less obtrusive since then. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Create the Server Certificate.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Create the Server Certificate.md.meta new file mode 100644 index 0000000..5828ddd --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Create the Server Certificate.md.meta @@ -0,0 +1,4 @@ +section: 6.2 +tags: lab lab11 +title: /Labs/11/Create the Server Certificate +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Generic 500 Error Page.md b/tiddlers/content/labs/lab11/_Labs_11_Generic 500 Error Page.md new file mode 100644 index 0000000..51d276c --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Generic 500 Error Page.md @@ -0,0 +1,48 @@ +When an unhandled exception occurs on the server, Jooby sends the error message to the client. You can see this yourself: + +1. Start your server, but don't start H2. + +1. Open the sign in page. + +1. Open the browser's dev tools, and switch to the <> tab. + +1. Try to sign in. Wait for the 500 response (it will take a few seconds since the server will need to wait for the database connection to time out). + +1. Select the request in the Network tab of the browser dev tools and look in the <> tab. You will see something like: + +

Server Error

+
+

message: org.h2.jdbc.JdbcSQLNonTransientConnectionException: Connection is broken: "java.net.ConnectException: + Connection refused (Connection refused): localhost" [90067-200]

+

status code: 500

+ + As you can see, there is some useful information in here for malicious users: + + * They can see that the service is using H2. + + * They can see that the database is running on the same server as the service (localhost). + + This might be enough information for them to find the H2 database file if they can find a path traversal or command injection flaw to exploit. We will encrypt the database in the next lab so they still have a lot of work to do even if they do manage to get hold of the file. + +
+We should create a generic error page for the `500 / Server Error` status which is the response that is used when the server has an unhandled exception. + +1. Create an HTML file in your <> folder named `500`. + +1. Add a hard-coded message in the file that states that the server had a problem. The message should be very generic, and not give away any information that might be useful to malicious users. + +1. Add the following to the `Server` class constructor: + + ```java + error(StatusCode.SERVER_ERROR, (ctx, cause, code) -> { + ctx.getRouter().getLog().error(cause.getMessage(), cause); + ctx.send(Paths.get("static/500.html")); + }); + ``` + + This will cause your 500 page to be sent to the client any time a 500 error occurs (such as when the server has an unhandled exception). This code is overriding the default error handler for Jooby, so we also need to log the error since Jooby isn't doing it for us anymore --- you never want to be in a situation where you have silent errors (where things are crashing, but you are not seeing any details of the problem in your logs). + +1. Restart your server and repeat the sign in again. You should see your error page in the preview tab rather than the Jooby one. + +
+You can use this process to replace any error page. The `404 / Not Found` page is one that a lot of web sites replace with something that fits into their style since it is quite a common error. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Generic 500 Error Page.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Generic 500 Error Page.md.meta new file mode 100644 index 0000000..839f76b --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Generic 500 Error Page.md.meta @@ -0,0 +1,4 @@ +section: 2 +tags: lab lab11 +title: /Labs/11/Generic 500 Error Page +type: text/x-markdown diff --git a/tiddlers/content/labs/lab11/_Labs_11_Install mkcert CA Certificate.md b/tiddlers/content/labs/lab11/_Labs_11_Install mkcert CA Certificate.md new file mode 100644 index 0000000..c0fa9fe --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Install mkcert CA Certificate.md @@ -0,0 +1,94 @@ +
<>If you are using the Linux lab desktop machines then you should skip to step 9 --- most of these instructions are about installing mkcert on your own computers --- it has already been installed on the Linux lab machines so skip ahead.
+ +1. Download a copy of `mkcert` from: + + https://github.com/FiloSottile/mkcert/releases + + * Windows users should download `mkcert-v1.4.4-windows-amd64.exe` + * Linux users should download `mkcert-v1.4.4-linux-amd64`. + + **NOTE**: `mkcert` is already installed on the Linux lab machines --- you don't need to install it yourself. + * Mac (Intel CPU) should download `mkcert-v1.4.4-darwin-amd64` + * Mac (M1 ARM CPU) should download `mkcert-v1.4.4-darwin-arm64 +` from the labs section of Blackboard. We have created a build for your CPU, but we don't have an M1 Mac to test it with. If you do get this working on an M1 then let us know. + +1. Create an `mkcert` folder in your <> folder. Copy the `mkcert` file that you downloaded into this folder. + +1. Rename the file that you copied to `mkcert` to make it easier to type into a terminal since `mkcert` is a terminal application. + +1. Open the <> folder in a terminal. + +1. Generate and install the CA certificate using the following command. + + **Windows Users (via PowerShell)** + ```plaintext + $env:CAROOT = pwd; $env:TRUST_STORES = 'system'; .\mkcert.exe -install + ``` + + **Mac Users** + ```plaintext + chmod u+x mkcert + CAROOT=$(pwd) TRUST_STORES=system ./mkcert -install + ``` + Mac users may need to jump through the usual hoops with the Security & Privacy settings to run the command. + + **Linux Users** + ```plaintext + chmod u+x mkcert + CAROOT=$(pwd) TRUST_STORES=system,nss ./mkcert -install + ``` + + The `chmod` command is needed (Mac/Linux only) since the file is not currently executable. This adds the executable mode to the file. + + Leave the terminal window open since we will be using it again very soon. + +1. You should see two new files in the `mkcert` folder. These are the new CA certificate and the private key for the certificate. + +1. Restart your web browser so that it will pick up the new CA certificate. + +1. You can check if the new CA certificate has been added to your system as follows: + + **Windows** + + Run `certmgr.msc`. You should see the mkcert certificate under < Certificates">>. + + Note that Firefox is not currently supported by mkcert under Windows, so you will need to use Chrome (or one of the Chrome derivatives) for the remainder of this exercise. + + **Linux** + + ```plaintext + ls -l /etc/ssl/certs/mkcert* + ``` + + **Mac** + + Use the 'Keychain Access' application. Search for `mkcert`. + +9. You can check that your browser is picking up the CA certificate. + + **Chrome** + + Enter the following into the location bar: + + ```plaintext + chrome://settings/certificates + ``` + Look in the <> tab. You should find `org-mkcert development CA` in the list. + + **Vivaldi** + + Click the padlock to the left of the URL in the browser and click <> --- it is likely already selected, but click it again to get to the main security settings. Then click < Manage Certificates > Authorities">>. + + You should find `org-mkcert development CA` in the list. + + **Firefox** + + Enter the following into the location bar: + + ```plaintext + about:certificate + ``` + + Then click the <> tab. You should see an entry that starts with `mkcert` in the list. + + <> Note that `mkcert` does not currently support Firefox on Windows --- use Chrome, or a Chrome derivative if you are a Windows user. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Install mkcert CA Certificate.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Install mkcert CA Certificate.md.meta new file mode 100644 index 0000000..723037e --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Install mkcert CA Certificate.md.meta @@ -0,0 +1,4 @@ +section: 6.1 +tags: lab lab11 +title: /Labs/11/Install mkcert CA Certificate +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Introduction.md b/tiddlers/content/labs/lab11/_Labs_11_Introduction.md new file mode 100644 index 0000000..b376c40 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Introduction.md @@ -0,0 +1,38 @@ +As mentioned in recent lectures, we should not be leaving security to the end of our project development. We are doing this in INFO202 because we need to teach you how to build systems before we can talk about securing those systems. We are doing things backwards. To ensure that we create a system that is as secure as we can reasonably make it we need to be considering security right at the first stages of the analysis and design of the system. + +There are a many things that we need to do to secure our system: + +**Web client and service** + +* Add a generic error page. +* Add transport encryption (HTTPS) to our web server. +* Check for XSS vulnerabilities. +* Create an allow-list for all of the files that make up our AJAX client. +* Ensure that the user does not have the opportunity to manipulate the price of the products they are purchasing. +* Prevent any sensitive customer data from being stored in the session storage. + +**Database** + +* Check for and mitigate SQL injections in the JDBI DAOs. +* Check for dangerous use of the `merge` statement in JDBI DAOs. +* Salt and hash the customer's passwords. +* Create and use accounts with appropriate privileges to interact with the database. +* Encrypt the database files. + + + +This lab will focus on securing the web client and service. Next week's lab will focus on securing the database. + +## Don't use your milestone 1 project for this lab + +We don't want to break anything just prior to the deadline. + +Use the CSR version of the student system for this lab. + +## Milestone 2 is due on Friday @ 5pm + +See the following Blackboard section for submission instructions: + +< Project > Submission Instructions">> + +We will be marking milestone 2 in the labs next week, so make sure you show up. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Introduction.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Introduction.md.meta new file mode 100644 index 0000000..b49d564 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Introduction.md.meta @@ -0,0 +1,4 @@ +section: 1 +tags: lab lab11 +title: /Labs/11/Introduction +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Lab 11_ Securing the Web Application.tid b/tiddlers/content/labs/lab11/_Labs_11_Lab 11_ Securing the Web Application.tid new file mode 100644 index 0000000..6ea9ba2 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Lab 11_ Securing the Web Application.tid @@ -0,0 +1,9 @@ +tags: lab lab11 toc +title: /Labs/11/Lab 11: Securing the Web Application +type: text/vnd.tiddlywiki + +!! Contents +<$set name="path" value="/Labs/11/"> +<$macrocall $name="contents-tree" path=<> /> +
<$macrocall $name="openByPath" path=<> />
+ diff --git a/tiddlers/content/labs/lab11/_Labs_11_Milestone 2 Authentication Bonus Task.md b/tiddlers/content/labs/lab11/_Labs_11_Milestone 2 Authentication Bonus Task.md new file mode 100644 index 0000000..3a53050 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Milestone 2 Authentication Bonus Task.md @@ -0,0 +1,7 @@ +At that moment there is no authentication in your milestone 2 project --- nothing is checking the password. + +We have added a reference section that explains how to add basic access authentication tokens to the HTTP headers: + +<> + +Note that this is a **bonus** task --- you can still get full marks without implementing it. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Milestone 2 Authentication Bonus Task.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Milestone 2 Authentication Bonus Task.md.meta new file mode 100644 index 0000000..f81da46 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Milestone 2 Authentication Bonus Task.md.meta @@ -0,0 +1,4 @@ +section: 8 +tags: lab lab11 +title: /Labs/11/Milestone 2 Authentication Bonus Task +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Milestone 3 is Due on Friday at 5pm.md b/tiddlers/content/labs/lab11/_Labs_11_Milestone 3 is Due on Friday at 5pm.md deleted file mode 100644 index db64d9f..0000000 --- a/tiddlers/content/labs/lab11/_Labs_11_Milestone 3 is Due on Friday at 5pm.md +++ /dev/null @@ -1,11 +0,0 @@ -The submission instructions are on Blackboard at < Project > Submission Instructions">> - -This week's lab tasks are intentionally small to give you a chance to complete milestone 3. - -We will probably have to mark milestones 2 and 3 offline given we may not have enough time to do this in the labs if we are ever able to get back into the labs this semester. As such: - -* Please make sure you create and push a milestone 3 tag as described in the instructions on Blackboard. It is important that we can easily identify the version of the project that you intend to be marked. - -* Create a file in the root of your project named <> which lists any bonus tasks that you have implemented. - -Note that this is not the final lab in INFO202. There will be two more labs, both of which will cover examining and fixing the known security vulnerabilities that your system currently contains. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Milestone 3 is Due on Friday at 5pm.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Milestone 3 is Due on Friday at 5pm.md.meta deleted file mode 100644 index 5a98786..0000000 --- a/tiddlers/content/labs/lab11/_Labs_11_Milestone 3 is Due on Friday at 5pm.md.meta +++ /dev/null @@ -1,6 +0,0 @@ -created: 20200702091026430 -modified: 20200707005526287 -section: 1 -tags: lab lab11 hidden -title: $:/Labs/11/Milestone 3 is Due on Friday at 5pm -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Removing Sensitive Customer Data from the Session Storage.md b/tiddlers/content/labs/lab11/_Labs_11_Removing Sensitive Customer Data from the Session Storage.md new file mode 100644 index 0000000..71dc785 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Removing Sensitive Customer Data from the Session Storage.md @@ -0,0 +1,7 @@ +There is too much customer data being stored in the browser’s session storage, some of which is sensitive (password, and addresses). We only really need the customer's username and first name on the client side. + +The session storage data expires when the user signs out, or the last browser tab for our application is closed, but if the user forgets to sign out or close their tabs, or someone sneaks a peak while they are away from their computer then it is all there to see. + +It can also be stolen via XSS attacks. + +It is easy for us to prevent these details from being sent to the client. In the GET `/api/customer/{username}` operation in `CustomerModule`, just set any sensitive fields to `null` before sending the customer to the client. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Removing Sensitive Customer Data from the Session Storage.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Removing Sensitive Customer Data from the Session Storage.md.meta new file mode 100644 index 0000000..c8e6544 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Removing Sensitive Customer Data from the Session Storage.md.meta @@ -0,0 +1,4 @@ +section: 7 +tags: lab lab11 +title: /Labs/11/Removing Sensitive Customer Data from the Session Storage +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_Testing the HTTPS Encryption.md b/tiddlers/content/labs/lab11/_Labs_11_Testing the HTTPS Encryption.md new file mode 100644 index 0000000..5cc6d62 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Testing the HTTPS Encryption.md @@ -0,0 +1,28 @@ +
<>This section can only be done while using the Linux desktop. There is no functional equivalent of tcpflow for Windows or Mac --- there are versions of tcpflow for Mac and Windows floating around, but they can't be used for capturing the network traffic which makes them useless for our purposes. The httpcat program is effectively a man-in-the-middle proxy, so always has access to the unencrypted version of the traffic which also makes it useless for testing if HTTPS is working. + +1. We should check that the HTTP communication is actually being encrypted. You can run a network sniffer to check this. Open a terminal and run the following command: + + ```sh + tcpflow port 8080 + ``` + If your server is not running on port `8080` then change the number to match your port. + + This network sniffer will only monitor traffic on `localhost` and can not be used to monitor regular network traffic. It would make the ITS security staff very grumpy if we let you do that. + + This terminal will be monitoring the normal unencrypted HTTP traffic that your server is seeing. + +1. Open another terminal and run the following command: + + ```sh + tcpflow port 8443 + ``` + + This terminal will be monitoring the encrypted HTTPS traffic that your server is seeing. + +1. Open the normal `http://` link in a browser, and register a new customer account through your web application. + + Look in the first terminal. Note that the customer's details including their password are displayed in clear text in the `tcpflow` output. Clearly, there isn't much in the way on encryption going on here --- everything is there to be seen by a malicious party who is sniffing the network. + +1. Repeat the process using the `https://` link, and check the second terminal. You should only see gibberish in the `tcpflow` output. A network sniffer will still have access to the data travelling over the network, but it is now encrypted, and useless to a malicious party. + +1. You can hit < c">> to stop `tcpflow`, and then exit both terminals. diff --git a/tiddlers/content/labs/lab11/_Labs_11_Testing the HTTPS Encryption.md.meta b/tiddlers/content/labs/lab11/_Labs_11_Testing the HTTPS Encryption.md.meta new file mode 100644 index 0000000..cc710a8 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_Testing the HTTPS Encryption.md.meta @@ -0,0 +1,4 @@ +section: 6.3 +tags: lab lab11 +title: /Labs/11/Testing the HTTPS Encryption +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_The Sale Price.md b/tiddlers/content/labs/lab11/_Labs_11_The Sale Price.md new file mode 100644 index 0000000..2bd552b --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_The Sale Price.md @@ -0,0 +1,5 @@ +The sale price that is being stored in the final sale that is added to the database is coming from the client side. Remember rule 11 --- don't trust the client. A sneaky user could edit the cart details in the web browser using the browser's developer tools and give themselves a discount. + +Note that our system does not currently have features for properly dealing with sales and discounts. As such, our only option is to use the product's list price as the sale price. + +Modify the code in the sale module so that it loads the correct list price from the database and inserts it into the sale price for each sale item. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_The Sale Price.md.meta b/tiddlers/content/labs/lab11/_Labs_11_The Sale Price.md.meta new file mode 100644 index 0000000..db21870 --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_The Sale Price.md.meta @@ -0,0 +1,4 @@ +section: 4 +tags: lab lab11 +title: /Labs/11/The Sale Price +type: text/x-markdown \ No newline at end of file diff --git "a/tiddlers/content/labs/lab11/_Labs_11_Transport Encryption \050HTTPS\051.md" "b/tiddlers/content/labs/lab11/_Labs_11_Transport Encryption \050HTTPS\051.md" new file mode 100644 index 0000000..d98030b --- /dev/null +++ "b/tiddlers/content/labs/lab11/_Labs_11_Transport Encryption \050HTTPS\051.md" @@ -0,0 +1,9 @@ +Our web application is using plain HTTP. We need to be using transport encryption to protect the customer's details as they are travelling over the network. This is even more important since we are using Basic Access Authentication (or would be if you implemented the authentication bonus task), which means our authentication token is susceptible to hijacking via network sniffing --- any time you are using token-based authentication, you need to also be using transport encryption (there are some exceptions to this rule, but in general, authentication tokens need to be protected). + +In order to use TLS (Transport Layer Security) we need to create an X.509 certificate that will be used to encrypt the HTTP messages. HTTP that is encrypted via TLS is commonly known as 'HTTPS'. Note that TLS is an evolution of SSL (Secure Sockets Layer) which has been deprecated for many years, but people still regularly refer to TLS as SSL. + +The traditional way to do this during development is to create and use a 'self-signed' certificate. Once we are ready to deploy the completed system to a production server we would obtain and use a certificate that is signed by a recognised CA (Certificate Authority) and use this instead of the self-signed certificate. However, browsers, server software, and libraries are becoming more picky about the certificates that they are willing to use, so using self-signed certificates is no longer a valid option. Our only remaining option is to create and use a certificate that is signed by a CA key that is trusted by the operating system and web browsers. + +Luckily, we can create our own CA certificate and signing key and register the certificate with the operating system and browsers. We can then use this CA key to sign any other certificates that we create. These signed certificates will then be trusted by the web browsers and server software, and everything should work. The process of doing all of this can be a bit tricky, but there is a tool called `mkcert` that does most of the work for us. You can read more about mkcert at: + +https://blog.filippo.io/mkcert-valid-https-certificates-for-localhost/ diff --git "a/tiddlers/content/labs/lab11/_Labs_11_Transport Encryption \050HTTPS\051.md.meta" "b/tiddlers/content/labs/lab11/_Labs_11_Transport Encryption \050HTTPS\051.md.meta" new file mode 100644 index 0000000..0278a4b --- /dev/null +++ "b/tiddlers/content/labs/lab11/_Labs_11_Transport Encryption \050HTTPS\051.md.meta" @@ -0,0 +1,5 @@ +section: 6 +tags: lab lab11 +title: /Labs/11/Transport Encryption (HTTPS) +todo: Look at using PKCS #12 files rather than PEM. Jooby 2 supports them, they are encrypted so they are more secure, and it will shorten the JDBC over TLS section in lab 13 since we don't have to cover it all again. +type: text/x-markdown \ No newline at end of file diff --git "a/tiddlers/content/labs/lab11/_Labs_11_Uninstalling the CA Certificate \050Optional\051.md" "b/tiddlers/content/labs/lab11/_Labs_11_Uninstalling the CA Certificate \050Optional\051.md" new file mode 100644 index 0000000..d2b246b --- /dev/null +++ "b/tiddlers/content/labs/lab11/_Labs_11_Uninstalling the CA Certificate \050Optional\051.md" @@ -0,0 +1,18 @@ +The mkcert CA certificate is now persistently stored on your system. There is no real downside to keeping it and chances are you are going to be using it again at some point in the near future since mkcert is now the only real solution to creating HTTPS certificates for testing and development purposes. Also, the `localhost.p12` certificate that your server is now using will only continue to work while the mkcert CA certificate is installed. + +If you do decide that you want to remove the mkcert CA certificate from your computer then run the following command in a terminal from the <> folder: + +**Windows (PowerShell)** +```plaintext +$env:CAROOT = pwd; $env:TRUST_STORES = 'system'; .\mkcert.exe -uninstall +``` + +**Mac** +```plaintext +CAROOT=$(pwd) TRUST_STORES=system ./mkcert -uninstall +``` + +**Linux** +```plaintext +CAROOT=$(pwd) TRUST_STORES=system,nss ./mkcert -uninstall +``` diff --git "a/tiddlers/content/labs/lab11/_Labs_11_Uninstalling the CA Certificate \050Optional\051.md.meta" "b/tiddlers/content/labs/lab11/_Labs_11_Uninstalling the CA Certificate \050Optional\051.md.meta" new file mode 100644 index 0000000..a3e9cb3 --- /dev/null +++ "b/tiddlers/content/labs/lab11/_Labs_11_Uninstalling the CA Certificate \050Optional\051.md.meta" @@ -0,0 +1,4 @@ +section: 6.4 +tags: lab lab11 +title: /Labs/11/Uninstalling the CA Certificate (Optional) +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_XSS Vulnerabilities.md b/tiddlers/content/labs/lab11/_Labs_11_XSS Vulnerabilities.md new file mode 100644 index 0000000..33d603e --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_XSS Vulnerabilities.md @@ -0,0 +1,21 @@ +AJAX templating techniques such as those that Vue is using (when you use the double braces to insert content into a page) have a natural resilience to XSS injection since they operate directly on the browser's document domain model using the functions provided by the DOM (Document Object Model) API rather than concatenation. AJAX clients are still susceptible to XSS flaws though, so we need to test just how vulnerable our users are. + +We can quickly test this by creating a customer and a product that are primarily made up of ` +``` + +Insert this into any column that is a `varchar` (enter valid values for other columns). Enter normal values (not script tags) for any values that will be used as path parameters in web service operations (such as the product ID, category, and username) since the '/' character in the closing script tag will be interpreted as a path separator, and break your service calls. + +We are using a number (111) to avoid any weird escaping of quote marks that may occur. + +Add a customer and a product to your database where all of the string values use the above script tag. + +Add the customer via the register page since the password hashing will only be done if we create a customer properly. For the products, you can use the H2 console by querying the table, and then hitting the <> button that appears at the bottom of the result. + +Once you have done this, test your entire web application. If you see any alert boxes with the 111 number appear then we have problems since we have a vector for malicious users to insert JavaScript that our client will execute. As mentioned, Vue is fairly immune to XSS attacks, so you should **not** be seeing any alerts. + +Repeat the test with the older SSR version of the project. JSP is very much **not** resilient to XSS injection --- we would expect to see some alerts here. \ No newline at end of file diff --git a/tiddlers/content/labs/lab11/_Labs_11_XSS Vulnerabilities.md.meta b/tiddlers/content/labs/lab11/_Labs_11_XSS Vulnerabilities.md.meta new file mode 100644 index 0000000..e0464df --- /dev/null +++ b/tiddlers/content/labs/lab11/_Labs_11_XSS Vulnerabilities.md.meta @@ -0,0 +1,4 @@ +section: 5 +tags: lab lab11 +title: /Labs/11/XSS Vulnerabilities +type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/$__Labs_13_Testing the HTTPS Encryption.md b/tiddlers/content/labs/lab13/$__Labs_13_Testing the HTTPS Encryption.md deleted file mode 100644 index b91a9ba..0000000 --- a/tiddlers/content/labs/lab13/$__Labs_13_Testing the HTTPS Encryption.md +++ /dev/null @@ -1,28 +0,0 @@ -NOTE THAT THIS WAS MOVED OUT OF THE PREVIOUS SECTION DUE TO LOCKDOWN AND LACK OF NETWORK SNIFFERS. - -1. We should check that the HTTP communication is actually being encrypted. You can run a network sniffer to check this. Open a terminal and run the following command: - - ```sh - tcpflow port 8080 - ``` - If your server is not running on port `8080` then change the number to match your port. - - This network sniffer will only monitor traffic on `localhost` and can not be used to monitor regular network traffic. It would make the ITS security staff very grumpy if we let you do that. - - This terminal will be monitoring the normal unencrypted HTTP traffic that your server is seeing. - -1. Open another terminal and run the following command: - - ```sh - tcpflow port 8443 - ``` - - This terminal will be monitoring the encrypted HTTPS traffic that your server is seeing. - -1. Open the normal `http://` link in a browser, and register a new customer account through your web application. - - Look in the first terminal. Note that the customer's details including their password are displayed in clear text in the `tcpflow` output. Clearly, there isn't much in the way on encryption going on here --- everything is there to be seen by a malicious party who is sniffing the network. - -1. Repeat the process using the `https://` link, and check the second terminal. You should only see gibberish in the `tcpflow` output. A network sniffer will still have access to the data travelling over the network, but it is now encrypted, and useless to a malicious party. - -1. You can hit < c">> to stop `tcpflow`, and then exit both terminals. diff --git a/tiddlers/content/labs/lab13/$__Labs_13_Testing the HTTPS Encryption.md.meta b/tiddlers/content/labs/lab13/$__Labs_13_Testing the HTTPS Encryption.md.meta deleted file mode 100644 index da44f9b..0000000 --- a/tiddlers/content/labs/lab13/$__Labs_13_Testing the HTTPS Encryption.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 6.3 -tags: lab lab13 hidden -title: $:/Labs/13/Testing the HTTPS Encryption -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Allow List for Static Assets.md b/tiddlers/content/labs/lab13/_Labs_13_Allow List for Static Assets.md deleted file mode 100644 index 9ab0c1a..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Allow List for Static Assets.md +++ /dev/null @@ -1,50 +0,0 @@ -Jooby makes it very easy for us to create an allow list (formerly known as a white list) for the URLs that it is allowed to serve. Jooby will return a 404 error for any URL that isn't explicitly allowed. - -The API paths are already allowed simply because we have listed all of the URLs that we need in our modules and Jooby will reject all others. - -The `StaticAssetModule` is the primary problem since it will serve anything that is in the <> folder. If a malicious user can somehow get a file into this folder then our web server will happily serve it. - -An allow list includes **only** the files that are allowed to be served. Anything that is not in the list will be rejected. - -Expand the assets module to explicitly list all of the files that your AJAX client is using. - -The result should look something like: - -```java -// home page -assets("/", Paths.get("static/index.html")); - -// html files -assets("/index.html", Paths.get("static/index.html")); -assets("/signin.html", Paths.get("static/signin.html")); -// ... and the rest of the HTML files - -// css files -assets("/css/style.css", Paths.get("static/css/style.css")); -// ... and the rest of the CSS files - -// JavaScript files -assets("/js/data-store.js", Paths.get("static/js/data-store.js")); -assets("/js/authentication.js", Paths.get("static/js/authentication.js")); -assets("/js/navigation.js", Paths.get("static/js/navigation.js")); -assets("/js/customer.js", Paths.get("static/js/customer.js")); -// ... and the rest of the JavaScript files - -// external JavaScript files -assets("/js/external/vue.global.js", Paths.get("static/js/external/vue.global.js")); -assets("/js/external/vuex.global.js", Paths.get("static/js/external/vuex.global.js")); -assets("/js/external/vuex-persistedstate.js", Paths.get("static/js/external/vuex-persistedstate.js")); -assets("/js/external/axios.js", Paths.get("static/js/external/axios.js")); - -// ... and any images that you have added -``` - -You need to list every single file that your client is using. While this is a little bit tedious it does add a lot of protection to the web site. - -Comment out the existing `assets` line since it is dangerous. - -You have most likely received a phishing email that contains a link to a random web site in another country that appears to be hosted by a small business. This is because the maintainers of the site for that business did not use an allow list for their files, and an attacker has found a way to upload their own pages to the site which they are now using for phishing scams. - -The attacker could just as easily (and may already have) uploaded a page that downloads sensitive data from the site. - -Restart and test the application to make sure you didn't break anything. \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Allow List for Static Assets.md.meta b/tiddlers/content/labs/lab13/_Labs_13_Allow List for Static Assets.md.meta deleted file mode 100644 index e959ca4..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Allow List for Static Assets.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 3 -tags: lab lab13 hidden -title: $:/Labs/13/Allow List for Static Assets -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Create the Server Certificate.md b/tiddlers/content/labs/lab13/_Labs_13_Create the Server Certificate.md deleted file mode 100644 index dae0c32..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Create the Server Certificate.md +++ /dev/null @@ -1,60 +0,0 @@ -1. We can now create certificates that are signed by the mkcert CA. We need to create a certificate for the web server that hosts the web service. The server is running on the `localhost` host, so we need to create a certificate for that host. Run the following command. - - **Windows** - ```plaintext - $env:CAROOT = pwd; .\mkcert.exe -pkcs12 localhost - ``` - - **Linux** - ```plaintext - CAROOT=$(pwd) ./mkcert -pkcs12 localhost - ``` - - **Mac** - ```plaintext - CAROOT=$(pwd) ./mkcert -pkcs12 localhost - ``` - - PKCS12 is a package format for X.509 certificates that allows us to bundle the certificate and the private key together into a single encrypted file. - -1. You should see a new file in the `mkcert` folder named `localhost.p12`. - - As mentioned, this is a PKCS12 file that contains both the certificate and the private key. Although TLS uses X.509 certificates which can be used for public key (asymmetric) encryption, TLS uses symmetric encryption. The client and server perform a handshake to negotiate a shared session key which is then used by both sides for encrypting and decrypting the messages. The private key that is generated is used as part of the handshake but is not used for the encryption of HTTP messages. - -1. Copy the `localhost.p12` file into the `resources` folder of your NetBeans project. You might be able to drag and drop from the file manager into the <> folder in the projects pane (this usually works on Windows and Linux. Macs are always a problem). If the drag and drop doesn't work, then use the `openProjectFolder` Gradle task to open the project folder, and then navigate to <>. - -1. We need to create the configuration file for Jooby. Right click the <> source folder in the project pane and select < Other > Other > Empty File">>. - - Name the file `application.conf`. - -1. We need to tell Jooby where to find the certificate and key so add the following to the `application.conf` file. - - ```plaintext - application.tmpdir: build/tmp - - server { - - port : 8080, - securePort: 8443, - - ssl { - type: PKCS12, - cert: localhost.p12, - password: changeit - } - } - ``` - - This also sets the port that will be used for both HTTP and HTTPS connections, and defines a temporary directory that Jooby will use to cache the keys while the server is running. The password is the default password that mkcert used to encrypt the PKCS12 file. - -1. The `application.conf` file is now providing the server options, so comment out the `setServerOptions` call in the the `Server` class since it will override the settings in the configuration file. - -1. Run your application. You should now see two URLs being displayed in the output console when Jooby starts. Click the one that starts with `https://`. - - You should see the padlock icon in the browser's location bar to indicate that the connection is encrypted. Your web pages should still work as per normal. - -Note that we did not need to write any JavaScript or Java code to encrypt the HTTP request. We have added the encryption at a layer below where our application resides --- the browser and the web server are doing all of the hard work for us --- our application should not even be aware that the encryption is taking place. - -Network sniffing is a significant threat as it is very easy to do. A malicious attacker does not even need to be inside a building in order to sniff a network. There are small and inconspicuous devices that can be plugged into a wall socket, or dropped somewhere out of the way that can capture and re-transmit data from wireless networks to a malicious attacker. There are equivalents for wired networks too. See the following article for an example: - -https://www.wired.com/2012/03/pwnie/ \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Create the Server Certificate.md.meta b/tiddlers/content/labs/lab13/_Labs_13_Create the Server Certificate.md.meta deleted file mode 100644 index 742e41e..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Create the Server Certificate.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 6.2 -tags: lab lab13 hidden -title: $:/Labs/13/Create the Server Certificate -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Generic 500 Error Page.md b/tiddlers/content/labs/lab13/_Labs_13_Generic 500 Error Page.md deleted file mode 100644 index bc01f60..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Generic 500 Error Page.md +++ /dev/null @@ -1,48 +0,0 @@ -When an unhandled exception occurs on the server, Jooby sends the error message to the client. You can see this yourself: - -1. Start your server, but don't start H2. - -1. Open the sign in page. - -1. Open the browser's dev tools, and switch to the <> tab. - -1. Try to sign in. Wait for the 500 response (it will take a few seconds since the server will need to wait for the database connection to time out). - -1. Select the request in the Network tab of the browser dev tools and look in the <> tab. You will see something like: - -

Server Error

-
-

message: org.h2.jdbc.JdbcSQLNonTransientConnectionException: Connection is broken: "java.net.ConnectException: - Connection refused (Connection refused): localhost" [90067-200]

-

status code: 500

- - As you can see, there is some useful information in here for malicious users: - - * They can see that the service is using H2. - - * They can see that the database is running on the same server as the service (localhost). - - This might be enough information for them to find the H2 database file if they can find a path traversal or command injection flaw to exploit. We encrypted the database in the last lab so they still have a lot of work to do even if they do manage to get hold of the file. - -
-We should create a generic error page for the `500 / Server Error` status which is the response that is used when the server has an unhandled exception. - -1. Create an HTML file in your <> folder named `500`. - -1. Add a hard-coded message in the file that states that the server had a problem. The message should be very generic, and not give away any information that might be useful to malicious users. - -1. Add the following to the `Server` class constructor: - - ```java - error(StatusCode.SERVER_ERROR, (ctx, cause, code) -> { - ctx.getRouter().getLog().error(cause.getMessage(), cause); - ctx.send(Paths.get("static/500.html")); - }); - ``` - - This will cause your 500 page to be sent to the client any time a 500 error occurs (such as when the server has an unhandled exception). This code is overriding the default error handler for Jooby, so we also need to log the error since Jooby isn't doing it for us anymore --- you never want to be in a situation where you have silent errors (where things are crashing, but you are not seeing any details of the problem in your logs). - -1. Restart your server and repeat the sign in again. You should see your error page in the preview tab rather than the Jooby one. - -
-You can use this process to replace any error page. The `404 / Not Found` page is one that a lot of web sites replace with something that fits into their style since it is quite a common error. \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Generic 500 Error Page.md.meta b/tiddlers/content/labs/lab13/_Labs_13_Generic 500 Error Page.md.meta deleted file mode 100644 index 22c5f5e..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Generic 500 Error Page.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 2 -tags: lab lab13 hidden -title: $:/Labs/13/Generic 500 Error Page -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Install mkcert CA Certificate.md b/tiddlers/content/labs/lab13/_Labs_13_Install mkcert CA Certificate.md deleted file mode 100644 index fb6278e..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Install mkcert CA Certificate.md +++ /dev/null @@ -1,68 +0,0 @@ -1. Download a copy of `mkcert` from: - - https://github.com/FiloSottile/mkcert/releases - - * Windows users should download `mkcert-v1.4.3-windows-amd64.exe` - * Linux users should download `mkcert-v1.4.3-linux-amd64` - * Mac (Intel CPU) should download `mkcert-v1.4.3-darwin-amd64` - * Mac (M1 ARM CPU) should download `mkcert-v1.4.3-darwin-m1` from the labs section of Blackboard. We have created a build for your CPU, but we don't have an M1 Mac to test it with. If you do get this working on an M1 then let us know. - -1. Create an `mkcert` folder in your <> folder. Copy the `mkcert` file that you downloaded into this folder. - -1. Rename the file that you copied to `mkcert` to make it easier to type into a terminal since `mkcert` is a terminal application. - -1. Open the <> folder in a terminal. - -1. Generate and install the CA certificate using the following command. - - **Windows Users (via PowerShell)** - ```plaintext - $env:CAROOT = pwd; $env:TRUST_STORES = 'system'; .\mkcert.exe -install - ``` - - **Mac Users** - ```plaintext - chmod u+x mkcert - CAROOT=$(pwd) TRUST_STORES=system ./mkcert -install - ``` - Mac users may need to jump through the usual hoops with the Security & Privacy settings to run the command. - - **Linux Users** - ```plaintext - chmod u+x mkcert - CAROOT=$(pwd) TRUST_STORES=system,nss ./mkcert -install - ``` - - The `chmod` command is needed (Mac/Linux only) since the file is not currently executable. This adds the executable mode to the file. - - Leave the terminal window open since we will be using it again very soon. - -1. You should see two new files in the `mkcert` folder. These are the new CA certificate and the private key for the certificate. - -1. Restart your web browser so that it will pick up the new CA certificate. - -1. You can check if the new CA certificate has been added to your system as follows: - - **Windows** - - Run `certmgr.msc`. You should see the mkcert certificate under < Certificates">>. - - Note that Firefox is not currently supported by mkcert under Windows, so you will need to use Chrome (or one of the Chrome derivatives) for the remainder of this exercise. - - **Linux** - - ```plaintext - ls -l /etc/ssl/certs/mkcert* - ``` - - You can also check the certificates in Chrome by entering the following into the location bar: - - ```plaintext - chrome://settings/certificates - ``` - Look in the <> tab. You should find `org-mkcert development CA` in the list. - - **Mac** - - Use the 'Keychain Access' application. Search for `mkcert`. - \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Install mkcert CA Certificate.md.meta b/tiddlers/content/labs/lab13/_Labs_13_Install mkcert CA Certificate.md.meta deleted file mode 100644 index 7fb25a1..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Install mkcert CA Certificate.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 6.1 -tags: lab lab13 hidden -title: $:/Labs/13/Install mkcert CA Certificate -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Introduction.md b/tiddlers/content/labs/lab13/_Labs_13_Introduction.md deleted file mode 100644 index 85e88c8..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Introduction.md +++ /dev/null @@ -1,11 +0,0 @@ -Last week, we worked on finding and fixing security flaws in the database. This week we will do the same with the web client and web service. We need to address the following problems: - -* Add generic error pages. -* Create an *allow list* for all of the files that make up our AJAX client. -* Ensure that the user does not have the opportunity to manipulate the price of the products they are purchasing. -* Check for XSS vulnerabilities. -* Add transport encryption (HTTPS) to our web server. -* Prevent any sensitive customer data from being stored in the session storage. - -We will also show you how to package up your application into a standalone system that can be used by customers to evaluate your system. This is not security related, but is a topic that is useful to know. - diff --git a/tiddlers/content/labs/lab13/_Labs_13_Introduction.md.meta b/tiddlers/content/labs/lab13/_Labs_13_Introduction.md.meta deleted file mode 100644 index 2eab1f5..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Introduction.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 1 -tags: lab lab13 hidden -title: $:/Labs/13/Introduction -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Lab 13_ Securing the Web Application.tid b/tiddlers/content/labs/lab13/_Labs_13_Lab 13_ Securing the Web Application.tid deleted file mode 100644 index 34b050a..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Lab 13_ Securing the Web Application.tid +++ /dev/null @@ -1,11 +0,0 @@ -created: 20200702091026430 -modified: 20200707005526287 -tags: lab lab13 toc hidden -title: $:/Labs/13/Lab 13: Securing the Web Application -type: text/vnd.tiddlywiki - -!! Contents -<$set name="path" value="/Labs/13/"> -<$macrocall $name="contents-tree" path=<> /> -
<$macrocall $name="openByPath" path=<> />
- diff --git a/tiddlers/content/labs/lab13/_Labs_13_Packaging a Release of the Application.md b/tiddlers/content/labs/lab13/_Labs_13_Packaging a Release of the Application.md deleted file mode 100644 index 7100ac5..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Packaging a Release of the Application.md +++ /dev/null @@ -1,51 +0,0 @@ -At the moment you are pretty reliant on NetBeans to run your application. In this section we will show you how to create an executable package that does not need NetBeans. Note that this relates to the topics covered in the release engineering lectures (lectures 23 & 24) --- we are showing you the bare minimum that you need to know to create a deployable build in this section. We will focus on the product administration system from milestone 2 --- deploying web services/applications is another topic entirely that is covered in INFO303 (semester 1). - -We are already using the `application` Gradle plugin that allows us to create executable Java applications. You can see where this is declared in `plugins` section at the top of the `build.gradle` file. - -1. The first thing that we need to do is to make Gradle generate compiled code that is compatible with Java 8. Java 8 is still very prevalent, and is currently the default version on the Linux machines in lab 3.27. Add the following to the bottom of your `build.gradle` file: - - ```gradle - compileJava { - sourceCompatibility = '1.8' - targetCompatibility = '1.8' - } - ``` - Java is mostly backwards compatible (there are some exceptions, but they do not affect us), so code compiled for Java 8 will work on more recent versions of Java. - -1. Select the root of the project in the projects pane. - -1. In the navigator pane, find the < assembleDist">> Gradle task. Double click it to execute the task. - -1. You can find the distribution in the files pane under <>. There will be a Zip and a Tar version which are both archives that contain the complete distribution that you can give to your end users. - -Let's look at how to use the distribution: - -1. Right-click the `distributions` folder and select <>. - -1. Double click the Zip file to open it. - -1. Copy and paste the project folder that is inside the Zip file to another location in your home folder. - -1. Poke around in the extracted folder. You will see a large number of JAR files in the `lib` folder. The `bin` folder contains startup scripts that should work in Windows (the `.bat`) file, or Linux and macOS (the file with no extension). - -1. Start H2 if you haven't already done so. We will discuss how to package/deploy the database at the end of this section. - -1. Try double clicking the Linux startup script. Sometimes the system file managers are configured to not allow scripts to be executed, so you might need to run the script from the command line. Right click the background of the file manager and select <>. Run the file using: - - ``` - ./info202_project - ``` - - You should see your Swing GUI appear since that is the main class that is currently configured as the default (via the `mainClassName` property in `build.gradle`). NetBeans is not involved here at all. So long as the user's computer has a recent version of Java (version 8 or better) installed on it, then everything should work fine. - -Systems that have a database like our system are a bit more complicated since the database also needs to be packaged and deployed. How you deal with databases depends on several factors: - -* Which DBMS your system is using. Larger systems like MySQL, Oracle, and Postgres need to be installed on a server and properly configured for the environment and requirements of the system. Smaller databases like H2 that don't require installation or significant configuration can be packaged along with the application, or packaged separately. - - The H2 packages that we gave you on Blackboard are a reasonable representation of what is needed to deploy and run H2. - -* Are multiple clients connecting to the database? In this case you will need to install the database on a server and configure the clients to use that database. If not then you may be able to embed the database directly into the application. H2 can be used in an embedded mode. Another light-weight database that is often used in an embedded mode is SQLite (https://www.sqlite.org/). - -* The database itself either needs to be deployed into the DBMS or created from the schema along with any initial data that needs to be added to the database. Most DBMSs have mechanism that allows you to send SQL statements to them via scripts, or you can create a small program that can be used to create and propagate the database. There are many ways to do this including the manual approach that we have been using in INFO202 where we use the management console to interact with the database. - - We did use an automated mechanism to create the testing database in lab 7 by calling the `runScript` command from the database's `INIT` parameter in the JDBC connection string. We **don't** recommend that you use the `INIT` parameter like this for setting up a production database unless it is guaranteed to be a one-shot operation. Using the `INIT` parameter to connect to a production database is dangerous since the schema file may include SQL statements that will destroy or contaminate the database. \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Packaging a Release of the Application.md.meta b/tiddlers/content/labs/lab13/_Labs_13_Packaging a Release of the Application.md.meta deleted file mode 100644 index 12334b6..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Packaging a Release of the Application.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 8 -tags: lab lab13 hidden -title: $:/Labs/13/Packaging a Release of the Application -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Removing Sensitive Customer Data from the Session Storage.md b/tiddlers/content/labs/lab13/_Labs_13_Removing Sensitive Customer Data from the Session Storage.md deleted file mode 100644 index 71dc785..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Removing Sensitive Customer Data from the Session Storage.md +++ /dev/null @@ -1,7 +0,0 @@ -There is too much customer data being stored in the browser’s session storage, some of which is sensitive (password, and addresses). We only really need the customer's username and first name on the client side. - -The session storage data expires when the user signs out, or the last browser tab for our application is closed, but if the user forgets to sign out or close their tabs, or someone sneaks a peak while they are away from their computer then it is all there to see. - -It can also be stolen via XSS attacks. - -It is easy for us to prevent these details from being sent to the client. In the GET `/api/customer/{username}` operation in `CustomerModule`, just set any sensitive fields to `null` before sending the customer to the client. \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_Removing Sensitive Customer Data from the Session Storage.md.meta b/tiddlers/content/labs/lab13/_Labs_13_Removing Sensitive Customer Data from the Session Storage.md.meta deleted file mode 100644 index 7ed0e50..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_Removing Sensitive Customer Data from the Session Storage.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 7 -tags: lab lab13 hidden -title: $:/Labs/13/Removing Sensitive Customer Data from the Session Storage -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_The Sale Price.md b/tiddlers/content/labs/lab13/_Labs_13_The Sale Price.md deleted file mode 100644 index 3bb6db5..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_The Sale Price.md +++ /dev/null @@ -1,5 +0,0 @@ -The sale price that is being stored in the final sale that is added to the database is coming from the client side. Remember rule 11 -- don't trust the client. A sneaky user could edit the cart details in the web browser using the browser's developer tools and give themselves a large discount. - -Note that our system does not currently have features for properly dealing with sales and discounts. As such, our only option is to use the product's list price as the sale price. - -Modify the code in the sale module so that it loads the correct list price from the database and inserts it into the sale price for each sale item. \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_The Sale Price.md.meta b/tiddlers/content/labs/lab13/_Labs_13_The Sale Price.md.meta deleted file mode 100644 index ab1e6c6..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_The Sale Price.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 4 -tags: lab lab13 hidden -title: $:/Labs/13/The Sale Price -type: text/x-markdown \ No newline at end of file diff --git "a/tiddlers/content/labs/lab13/_Labs_13_Transport Encryption \050HTTPS\051.md" "b/tiddlers/content/labs/lab13/_Labs_13_Transport Encryption \050HTTPS\051.md" deleted file mode 100644 index d98030b..0000000 --- "a/tiddlers/content/labs/lab13/_Labs_13_Transport Encryption \050HTTPS\051.md" +++ /dev/null @@ -1,9 +0,0 @@ -Our web application is using plain HTTP. We need to be using transport encryption to protect the customer's details as they are travelling over the network. This is even more important since we are using Basic Access Authentication (or would be if you implemented the authentication bonus task), which means our authentication token is susceptible to hijacking via network sniffing --- any time you are using token-based authentication, you need to also be using transport encryption (there are some exceptions to this rule, but in general, authentication tokens need to be protected). - -In order to use TLS (Transport Layer Security) we need to create an X.509 certificate that will be used to encrypt the HTTP messages. HTTP that is encrypted via TLS is commonly known as 'HTTPS'. Note that TLS is an evolution of SSL (Secure Sockets Layer) which has been deprecated for many years, but people still regularly refer to TLS as SSL. - -The traditional way to do this during development is to create and use a 'self-signed' certificate. Once we are ready to deploy the completed system to a production server we would obtain and use a certificate that is signed by a recognised CA (Certificate Authority) and use this instead of the self-signed certificate. However, browsers, server software, and libraries are becoming more picky about the certificates that they are willing to use, so using self-signed certificates is no longer a valid option. Our only remaining option is to create and use a certificate that is signed by a CA key that is trusted by the operating system and web browsers. - -Luckily, we can create our own CA certificate and signing key and register the certificate with the operating system and browsers. We can then use this CA key to sign any other certificates that we create. These signed certificates will then be trusted by the web browsers and server software, and everything should work. The process of doing all of this can be a bit tricky, but there is a tool called `mkcert` that does most of the work for us. You can read more about mkcert at: - -https://blog.filippo.io/mkcert-valid-https-certificates-for-localhost/ diff --git "a/tiddlers/content/labs/lab13/_Labs_13_Transport Encryption \050HTTPS\051.md.meta" "b/tiddlers/content/labs/lab13/_Labs_13_Transport Encryption \050HTTPS\051.md.meta" deleted file mode 100644 index de8758c..0000000 --- "a/tiddlers/content/labs/lab13/_Labs_13_Transport Encryption \050HTTPS\051.md.meta" +++ /dev/null @@ -1,5 +0,0 @@ -section: 6 -tags: lab lab13 hidden -title: $:/Labs/13/Transport Encryption (HTTPS) -todo: Look at using PKCS #12 files rather than PEM. Jooby 2 supports them, they are encrypted so they are more secure, and it will shorten the JDBC over TLS section in lab 13 since we don't have to cover it all again. -type: text/x-markdown \ No newline at end of file diff --git "a/tiddlers/content/labs/lab13/_Labs_13_Uninstalling the CA Certificate \050Optional\051.md" "b/tiddlers/content/labs/lab13/_Labs_13_Uninstalling the CA Certificate \050Optional\051.md" deleted file mode 100644 index d2b246b..0000000 --- "a/tiddlers/content/labs/lab13/_Labs_13_Uninstalling the CA Certificate \050Optional\051.md" +++ /dev/null @@ -1,18 +0,0 @@ -The mkcert CA certificate is now persistently stored on your system. There is no real downside to keeping it and chances are you are going to be using it again at some point in the near future since mkcert is now the only real solution to creating HTTPS certificates for testing and development purposes. Also, the `localhost.p12` certificate that your server is now using will only continue to work while the mkcert CA certificate is installed. - -If you do decide that you want to remove the mkcert CA certificate from your computer then run the following command in a terminal from the <> folder: - -**Windows (PowerShell)** -```plaintext -$env:CAROOT = pwd; $env:TRUST_STORES = 'system'; .\mkcert.exe -uninstall -``` - -**Mac** -```plaintext -CAROOT=$(pwd) TRUST_STORES=system ./mkcert -uninstall -``` - -**Linux** -```plaintext -CAROOT=$(pwd) TRUST_STORES=system,nss ./mkcert -uninstall -``` diff --git "a/tiddlers/content/labs/lab13/_Labs_13_Uninstalling the CA Certificate \050Optional\051.md.meta" "b/tiddlers/content/labs/lab13/_Labs_13_Uninstalling the CA Certificate \050Optional\051.md.meta" deleted file mode 100644 index 5c9f9a1..0000000 --- "a/tiddlers/content/labs/lab13/_Labs_13_Uninstalling the CA Certificate \050Optional\051.md.meta" +++ /dev/null @@ -1,4 +0,0 @@ -section: 6.3 -tags: lab lab13 hidden -title: $:/Labs/13/Uninstalling the CA Certificate (Optional) -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_XSS Vulnerabilities.md b/tiddlers/content/labs/lab13/_Labs_13_XSS Vulnerabilities.md deleted file mode 100644 index 0c4ec20..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_XSS Vulnerabilities.md +++ /dev/null @@ -1,19 +0,0 @@ -AJAX templating techniques such as those that Vue is using (when you use the double braces to insert content into a page) have a natural resilience to XSS injection since they operate directly on the browser's document domain model using the functions provided by the DOM (Document Object Model) API rather than concatenation. AJAX clients are still susceptible to XSS flaws though, so we need to test just how vulnerable our users are. - -We can quickly test this by creating a customer and a product that are primarily made up of ` -``` - -Insert this into any column that is a `varchar` (enter valid values for other columns). Enter normal values (not script tags) for any values that will be used as path parameters in web service operations (such as the product ID, category, and username) since the '/' character in the closing script tag will be interpreted as a path separator, and break your service calls. - -We are using a number (111) to avoid any weird escaping of quote marks that may occur. - -Add a customer and a product to your database where all of the string values use the above script tag. - -Add the customer via the register page since the password hashing will only be done if we create a customer properly. For the products, you can use the H2 console by querying the table, and then hitting the <> button that appears at the bottom of the result. - -Once you have done this, test your entire web application. If you see any alert boxes with the 111 number appear then we have problems since we have a vector for malicious users to insert JavaScript that our client will execute. As mentioned, Vue is fairly immune to XSS attacks, so you should **not** be seeing any alerts. \ No newline at end of file diff --git a/tiddlers/content/labs/lab13/_Labs_13_XSS Vulnerabilities.md.meta b/tiddlers/content/labs/lab13/_Labs_13_XSS Vulnerabilities.md.meta deleted file mode 100644 index cebe468..0000000 --- a/tiddlers/content/labs/lab13/_Labs_13_XSS Vulnerabilities.md.meta +++ /dev/null @@ -1,4 +0,0 @@ -section: 5 -tags: lab lab13 hidden -title: $:/Labs/13/XSS Vulnerabilities -type: text/x-markdown \ No newline at end of file diff --git a/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md b/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md index 431e5bc..c41ec40 100644 --- a/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md +++ b/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md @@ -36,7 +36,7 @@ } ``` -1. Make your existing `CustomerDAO` interface extend this interface. Your existing DAO implementations should already be providing the `validateCredentials` method so you don't need to do anything else to any of the other DAO classes. +1. Make your existing `CustomerDAO` interface extend this interface. Your existing DAO implementations should already have an equivalent of the `validateCredentials` method (a method that takes a `username` and `password` and returns a `Boolean`) --- rename the `validateCredentials` method to match your method name. ## BasicAccessAuth Class @@ -174,6 +174,8 @@ } ``` + + Modify the line of code that calls `validateCredentials` (which is likely showing an error at the moment) to use your method name. 1. Add the following to the `Server` class to add the `BasicAccessAuth` filter to the filter chain: @@ -231,14 +233,14 @@ ``` This code provides a `createToken` function that can be used to create the BAA token from the username and password entered by the user and store it in the data store. The token is retrieved from the data store in the `computed` section, and added as a default header to Axios in the `mounted` section so that all HTTP requests will include the token. -2. This module needs to be imported into `product-list.js`, `customer.js`, and `cart.js`. Add the following to the bottom of each file, just above the `app.mount` call: +2. This module needs to be imported into `view-products.js` and the other page controller JS files (you don't need to do this for the create-account, navigation or data store files). Add the following to the bottom of each file, just above the `app.mount` call: ```javascript // import authentication module import { BasicAccessAuthentication } from './authentication.js'; ``` -1. Add the `BasicAccessAuthentication` module to the `mixins` array of `product-list.js`, `customer.js`, and `cart.js`: +1. Add the `BasicAccessAuthentication` module to the `mixins` array of each of the controllers: ```javascript mixins: [BasicAccessAuthentication] diff --git a/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md.meta b/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md.meta index f883bb7..459b805 100644 --- a/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md.meta +++ b/tiddlers/content/reference/Web/_Reference_Web_HTTP Authentication.md.meta @@ -1,3 +1,3 @@ -tags: reference hidden -title: $:/Reference/Web/HTTP Authentication +tags: reference +title: /Reference/Web/HTTP Authentication type: text/x-markdown \ No newline at end of file