Securing Server and Database and Sessions and Cookies - Oktane 2020
Series Sections:
- Section 1 - The Client and The Data Flow
- Section 2 - Passwords and The Client-Server Relationship
- Section 3 - Securing Server and Database and Sessions and Cookies
- Section 4 - CSRF Attacks and OpenID Connect
Part 3: Securing Server & Database and Sessions & Cookies
How does secure communication between our server and our Database? We already discussed how the client and can securely send data to the server but how do we securely send data from the server to the Database?
Avoid SQL Injection! What is SQL Injection you ask? SQL is a coding language used to speak to the Database and if it is not written properly a malicious user can enter characters in our VikingsFan Login form to hijack the existing SQL and break into our website. If that happened the inhabitants of Valhalla would not be happy campers.
For a sign-in page the SQL might look like this:
In the above simple example, we are using a combination of single and double quotes to find a user with a matching username and password. When the values are concatenated they would look like this (see image below):
note: This is how the authentication works - if we find a user with a matching username and password, we can let them into our website
But a hacker could enter characters in your form to hijack your SQL code (or SQL inject your code). Here is an example of what that would look like:
In the example above the SQL has been altered to set the username and password to always be true (0 will always be equal to 0 so the username and password will be true) and with this simple modification to the SQL the user has gained access to our website. If the Vikings app developers don’t code our app to protect against SQL injection, this small mistake could have catastrophic results. Ragnar would be angry!
Sessions and Cookies
Let’s move our discussion to use Session and Cookies. If you don’t know what each of these is you might be surprised that you have been using them a lot.
What if we didn’t use Sessions and Cookies?
If you log into Facebook, you need to enter your username and password. But without Sessions, if you clicked a link on your Facebook page to access another internal Facebook page you would have to log in again. Every page you want to access on Facebook you would have to re-authenticate. This obviously would lead to a terrible website experience. Sessions are created once we authenticate and they let us access other internal pages freely without having to re-authenticate every time.
Vegas Baby!
To use an analogy to explain how session work let’s say I’m in Las Vegas and I’m checking into the Wynn Resorts hotel. I provide my driver’s license and credit card and the receptionist authenticates that I am who I say I am and then that receptionist creates my profile.
After my profile is created the receptionist hands me two room keys.
Now that I have these room keys I don’t have to re-authenticate every time. I can access my room, the spa, the weight room, the VIP room… Awesome!
How long can I use these cards?
As long as my stay is valid. As long as my session doesn’t expire.
What is stored in my Wynn room key?
The movies, room service, and dry cleaning I ordered aren’t stored on the cards. That is stored at the front desk in my hotel customer profile. The cards I am holding are like the Cookie which the web uses. A cookie is just a string of characters that is only valid for my profile. The profile that the receptionist creates is like a web Session.
Cookies and our app
As soon as a user logs into our Vikings app, our server will send them a cookie and that cookie is saved inside the user’s browser session.
Remember that anytime a user is on our Vikings site and they click on a link that will fire off a HTTP request that will communicate with our server. And all we need to do is store the session in the header and the stored cookie in the client will get sent to the server in the HTTP request.
We need to make sure we safely handle that cookie
When dealing with cookies you need to be aware of a few security situations.
Make sure to set the following Cookie flags
- When you tag a cookie with the HttpOnly flag, it tells the browser that this particular cookie should only be accessed by the server. Any attempt to access the cookie from client script is strictly forbidden
- Browsers which support the secure flag will only send cookies with the secure flag when the request is going to an HTTPS page
- A session configuration that uses no persistent storage for caches, cookies, or credentials
- Whatever site that provided the cookie is the site that needs the cookie
Series Sections:
- Section 1 - The Client and The Data Flow
- Section 2 - Passwords and The Client-Server Relationship
- Section 3 - Securing Server and Database and Sessions and Cookies
- Section 4 - CSRF Attacks and OpenID Connect
.cloudlicense### Cloud Licensing Providers we support.