Secure Your Web Application With OWASP

Implement the Transport Layer

Now we have reached sensitive data exposure, the third in our top ten. Remember, the OWASP bases its numbering system on how often the types of attack happen in relation to all data breaches that have occurred over the last few years. This is a commonly used attack, and compliance laws mandate the protection of PII, a class of sensitive data. GDPR can fine a company that mishandles the PII of an EU resident. Securing this data requires adherence to secure coding in the transport layer and while it is on the database. We will first start with securing transport layer data transmission.

To understand the transport layer, you will need to understand the Secure Sockets Layer/ Transport Layer Security (SSL/TLS) model.  You use SSL/TLS when running a web application on a browser. Your browser uses the Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) to deliver web pages and the Transmission Control Protocol/Internet Protocol (TCP/IP) network protocol to deliver them.

Clear as mud?

Okay. So you put a URL in the browser address bar and hit enter.

Your browser will initiate a TCP connection that will send a GET or POST request to connect with the web server associated with the domain name or IP address.

If the web server chooses to establish the TCP connection with the browser, a response with the status code and the requested file (typically the index.html file for the web page) and data transmission can begin.

This brings us to the first vulnerability. An HTTP URL is subject to an attack because it is unencrypted.

Great question...

A Man-In-The-Middle (MITM) Attack

Let’s say you decided to go to your favorite spot for a cup of Jane and use the free Wi-Fi to surf some sites. Unbeknownst to you, a very bored hacker has decided to use a network sniffer that records the TCP transmissions on the network right on the hacker's computer.

You are surfing and logging onto an HTTP site to send some blog posts. Guess what? The hacker now has access to your credentials and blog content that was transmitted because it was not encrypted!

This is a leading cause of session hijacking. If a hacker is able to break into the network, a MITM is the next move.

The man is now in the middle of your communication, and picks up everything you’re sending.  

The Man can also grab the data being transmitted to you so you never see it!

Data theft and session hijacking are only a few things a hacker can do once in your network. Either way, if the data is sent on HTTP and is plaintext, it takes little effort to interpret the data.

HTTPS Everywhere!!!

HTTPS is a secure version of HTTP that uses TLS to encrypt all data transmission.  If you had been blogging on a site running HTTPS, the hacker would have just ended up with some encrypted gibberish!!

 The rule of thumb is, if you need to authenticate with a password anywhere on the site, use HTTPS to protect the password as it is transmitted through the network.

So let’s go back to your web application.

Here it is:

Use TLS to ensure that all data transported to the web from the browser is encrypted to avoid a lot of headaches later on!  Let’s take a look at how you can do that.

First, obtain an SSL certificate and add it to your codebase. This certificate is required to encrypt the data in transmission.

To be clear, there are two steps to integrating  HTTPS to your site:

1. Generate an SSL certificate.

2. Code your pages to HTTPS.

Here Are a Few Ideas to Get You Started

Node.js is a popular platform to create a web server for your web application; however, it uses HTTP by default for data transmission.  Now that you just learned about how to start encrypting data, what is the next step?

Suffice to say, using the HTTPS module on Node.js for your web server is just as easy as making an HTTP server!

To start an HTTP server on Node.js, it looks like this:

var http = require('http');

http.createServer(function (req, res) {

}).listen(8080);

All you have to do is add an S and you can now start an HTTPS server just as easily (with an SSL certificate set up, of course)

var https = require('https');

https.createServer(function (req, res) {

}).listen(8080);

ASP.NET has a module called SecureWebPageModule, which can be added to the web.config with the following addition.

<secureWebPages enabled="true">. [RequireHttps]  can also be used in the AccountController.cs file.  Lastly, ASP. NET core supports URL Rewriting Middleware.

With Ruby on Rails, you can run an NGINX web server using HTTPS, and create your certificate there.

• On production.rb file set  config.force_ssl = true

• On application.rb will have the line  config.force_ssl = (ENV[ENABLE_HTTPS”] == “yes”)

• Use Rack middleware to force SSL by integrating the rack-ssl gem.

Regardless of the language you are using, make sure that your login page and all subsequent web pages that are part of the session use HTTPS.

What Is the Deal With GET vs POST?

When setting up your TCP connections in your requests, there are a few rules in secure coding.  When do I use a GET and when do I use a POST. You’re probably wondering what I’m talking about.  Let me break this down.

A GET request looks like this:

GET /index.html HTTP:1.1
Header:
Body:

As you can see, it holds its parameters in the URL, and gets cached in the browser.

It's best to use a GET request when you are retrieving information. This means that you can query the database, but not make any changes to it.

A POST request looks like this:

POST https://securesite.com/resetpassword.php
Header:
Body: password=password123 (encrypted)

POST requests are used to make changes to the database so they need to be passed with encryption through TLS.  

It does not save a cache on the browser, and it holds the parameters in the body of the request, making it tougher to hijack.

How can you make sure that your GET and POST requests are not vulnerable to exposure?

I’m not a huge fan of using third party components; however, you need to ensure that you are using HTTPS for all of your GET and POST requests.

So let’s talk a little bit about default browser security. The Cross-Origin Resource Sharing (CORS) in shining armor. 

Your browser provides some security to your GET and POST requests by default.  When a request is made, it will only permit if it has the same origin.

This means that it should have the same domain, port, hosts, and schemes, so it is well restricted. This restriction is not always helpful if the requests require transmission to a different port or domain. When this happens, the web application is left exposed to a CSRF attack.

Here are some rules:

1. Only use GET for retrieving information.

2. Use POST for information that will be manipulated.

3. All POST requests should use HTTPS/SSL to ensure the body is encrypted (if you absolutely have to use HTTP, use it with GET).

4. Vet any third party modules you use for creating GET/POST requests and use HTTPS for all of them!

5. Use CORs if you are going outside the domain.

Let’s Recap!

Some of the key lessons to take from this chapter are:

• Use HTTPs for your entire site, even if it doesn’t have sensitive data.

• Use GET requests for retrieving information, and POST for changing information.

• Secure your cookies to be transmitted through the header, and via HTTPS.

• Secure your sessions by adding an expiration date, securing the ID, and not putting that ID in the URL.

• Using encryption in the transport layer can prevent MITM attacks!