Security and Web

A small security point 🔒¶

What difference between

HTTP and HTTPS ❓
Yes yes it’s the S of Secure 😓

Roughly:

Wrapping the HTTP protocol in an encryption layer
to guarantee user security

HTTP a not safe thing?¶

So yes basic HTTP is not secure

It’s not very serious in many cases
But modern browsers are starting to be very strict on the subject

The risk of HTTP¶

The principle is therefore to enclose the HTTP request and the information it contains
in an encrypted message

Encryption principles¶

In practice encryption works with a public key/private key system

Certification Authority (CA)¶

Trusted third party
who will generate certificates allowing encryption and authentication of correspondents’ identity

Possible to generate your own certificates yourself but they are not considered valid by standard clients (knowing that web browsers have a list of trusted CAs)

Open source software mainly uses the OpenSSL library

To generate certificates for free there is the Let’s Encrypt initiative

in practice, a certificate is valid for a finite duration, of the order of 1 year, so it must be renewed regularly

And now is it finished?¶

Cookies 🍪¶

Let’s take a snack break 🤤

It’s part of these little hidden things in HTTP headers

Concretely what is it?¶

An 🍪 HTTP is data that a server sends to a client

stored on the client (in the browser)
and sent back to the server at each new request

What interest?¶

Cookies are there to enrich HTTP.

The problem¶

HTTP = stateless protocol

Basically impossible for an HTTP server to know if two requests come from the same client or not 😵‍💫

How to stay authenticated then?

The solution¶

Cookies 🍪 because it leaves crumbs

Concretely we will be able to store:

A session ID, user preferences (light/dark theme, language, ...)

Setting cookies¶

Nothing simpler, in the server response header just add

Set-Cookie: <name>=<value>; <attributes...>

Cookie Attributes

Expires: lifetime (date/time)
Max-Age: lifetime (seconds)
Domain: domain names for which the cookie is sent back
Path: particular path for which the cookie is sent back
Secure: if set, we only send the cookie on https, and not http
HttpOnly: if set, we cannot access the cookie via JavaScript
SameSite: defines if we send the cookie in cross-site requests

For example, go to https://www.mat.minesparis.psl.eu and find the PHPSESSID cookie

The sordid details¶

more details here on MDN, notably

and Third-Party Cookies ?

Finally regarding SameSite, a rather thorny subject, that of third-party cookies; what is it about?

You go to https://the-shop.com which puts a cookie on you
a little later you consult https://other-site.com
which makes an indirect request (e.g. a fetch() or an <img>) to https://the-shop.com
should we send the first cookie?

Some rules to follow¶

https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies

Internet users must be informed and give their consent before the deposit of certain cookies
- ❌ Advertising tracking / social networks
- ✔️ Cookie to say we refuse cookies example, shopping cart, authentication, ...
Collect consent
- Refuse button as visible as the accepted one
- Possibility to choose cookies
- Ease of withdrawal of consent

let’s go to the python/cookies folder of the course

run this code on your computer and look for cookies in the headers

note that on Chrome, you can also inspect cookies in the browser via
DevTools > Application > Cookies

You see too much?

if you join the server on localhost, you might see a lot..
well, much more than what the server puts itself
how do you think this happens?

HTTP + 🍪 sufficient to do everything?¶

But why?¶

HTTP operation very rigid: question/answer oriented
Impossible for the server to be at the origin of the exchange: quite limiting actually 😮‍💨

forces Patrick to always ask if there is anything new for him...

Websocket¶

In 2011, revolution: arrival of Websocket 🤯

connexion bidirectionnelle entre un client et le serveur
on parle de connexion full-duplex
permet au serveur de pousser des informations vers le client sans que ce dernier n’ait rien demandé 😲

son petit nom: ws (ou wss pour le sécurisé)

Comment ça marche¶

Very simply actually!

First step we establish a connection to a WebSocket server
via
ws://mon-super-server.com or wss://mon-super-server.com

Once the connection is established

We must simply put ourselves in a listening state for particular events

Four types of events

onopen 📖, onclose 📕, onerror 🚨, onmessage 📥

And at each event we will come to associate an action

For example :¶

See in the python/websockets folder:

the “ping-pong” protocol (actually “ping-gnip”):

ws-server.py: a WebSocket server in Python
ws-client.py: a WebSocket client in Python
ws-client.js: a WebSocket client in JavaScript

it works but it has little interest
let’s say it has the merit of showing how it works

the “countdown” protocol, same logic:

python ws-server2.py for the server
python ws-client2.py 3 will last 3 seconds
node ws-client2.js 3 same but in JS

this time it’s more interesting, the client sends to the server a number of seconds, and the server responds by counting down to 0

⚠️ You see the keyword await that you don’t know in Python 🐍
It’s related to asynchronous programming. For more details I encourage you to take a tour on the Mooc

Python: from fundamentals to advanced language concepts